Undifferentiated Heavy Lifting の本質 - AWS が解決する問題と解決しない問題の境界線
AWS が繰り返し使う Undifferentiated Heavy Lifting というフレーズの真意を掘り下げ、マネージドサービスの責任境界、共有責任モデルの実態、フルマネージドの幻想と現実を解説します。
差別化につながらない重労働とは何か
Undifferentiated Heavy Lifting は、AWS のマーケティングや技術講演で頻繁に登場するフレーズです。2006 年に Jeff Bezos が MIT での講演で紹介したこの概念は、「どの企業がやっても同じ結果になる、差別化につながらない重労働」を意味します。サーバーのラッキング、ネットワークケーブルの配線、OS のパッチ適用、ストレージの容量管理、データセンターの空調管理。これらの作業は事業を運営するために不可欠ですが、どれだけ上手にやっても顧客がその企業を選ぶ理由にはなりません。AWS の提案は明快です。差別化につながらない重労働は AWS に任せ、企業は自社の競争優位性を生む活動に集中すべきだ、と。この提案自体は正しいのですが、実際にどこまでを AWS に任せられるのか、その境界線は思ったほど明確ではありません。
共有責任モデルの実態
AWS の共有責任モデルは、セキュリティの責任を「クラウドのセキュリティ」(AWS の責任) と「クラウド内のセキュリティ」(顧客の責任) に分けます。AWS はインフラストラクチャの物理的なセキュリティ、ハイパーバイザー、ネットワークの基盤を保護します。顧客はゲスト OS の設定、アプリケーションのセキュリティ、データの暗号化、IAM の設定を管理します。この分担は概念としては明快ですが、実務では境界が曖昧になるケースが頻繁に発生します。RDS を例に取ります。RDS は「フルマネージド」なリレーショナルデータベースサービスです。AWS がデータベースエンジンのインストール、パッチ適用、バックアップの自動化、フェイルオーバーを管理します。しかし、バックアップが自動で取られていても、リストアのテストは顧客の責任です。バックアップが正常に復元できることを定期的に検証しなければ、いざというときに復旧できない可能性があります。パラメータグループの設定、スロークエリの最適化、接続数の管理、暗号化の有効化もすべて顧客側の作業です。
マネージドの 4 段階 - 抽象度と制約のトレードオフ
AWS のサービスは、顧客が管理する範囲に応じて大きく 4 段階に分類できます。第一段階は EC2 に代表される IaaS です。仮想マシンが提供され、OS から上のすべてを顧客が管理します。自由度は最大ですが、OS のパッチ適用、ミドルウェアの設定、スケーリングの設計もすべて自分で行います。第二段階は ECS や EKS に代表されるコンテナマネージドです。コンテナのオーケストレーションは AWS が管理しますが、コンテナイメージの構築、アプリケーションの設定、ネットワーキングの設計は顧客の責任です。Fargate を使えばサーバーの管理からも解放されますが、コンテナの設計自体は変わりません。第三段階は Lambda に代表されるサーバーレスです。インフラの管理はほぼ完全に AWS に委ねられ、顧客はコードだけに集中できます。ただし、実行時間の上限 (15 分)、メモリの上限、コールドスタートのレイテンシといった制約を受け入れる必要があります。第四段階は Bedrock に代表されるモデルマネージドです。基盤モデルの学習、ホスティング、スケーリングをすべて AWS が管理し、顧客は API を呼び出すだけです。しかし、モデルの選択、プロンプトの設計、出力の品質管理は顧客の責任です。抽象度が上がるほど AWS が引き受ける範囲は広がりますが、同時に顧客が受け入れる制約も増えます。この制約が自分のユースケースに合わない場合、より低い抽象度のサービスを選ぶ必要があります。
フルマネージドの幻想 - 運用の自動化と設計の自動化は違う
マネージドサービスに対する最も危険な誤解は、「マネージドだから設計を考えなくてよい」という思い込みです。DynamoDB は「フルマネージド」な NoSQL データベースですが、パーティションキーの設計を間違えればホットパーティションが発生し、プロビジョンドキャパシティを超えるリクエストがスロットリングされます。テーブル設計、アクセスパターンの分析、GSI (グローバルセカンダリインデックス) の設計は、すべて顧客の責任です。Aurora は「フルマネージド」なリレーショナルデータベースですが、クエリの実行計画の最適化、インデックス設計、コネクションプーリングの設定は顧客が行います。Aurora がマネージドしているのは、レプリケーション、フェイルオーバー、ストレージの自動拡張といったインフラ層の運用です。Lambda は「サーバーレス」ですが、関数のメモリ設定がパフォーマンスとコストに直結します。コールドスタートを最小化するためのアーキテクチャ設計、同時実行数の制御、エラーハンドリングの設計は顧客の仕事です。つまり、マネージドサービスが自動化するのは「運用」であって「設計」ではありません。サーバーのプロビジョニング、パッチ適用、バックアップ、スケーリングといった運用タスクは AWS が引き受けますが、そのサービスをどう使うかという設計の責任は常に顧客にあります。
境界線の見極め方 - サービス評価のチェックリスト
新しいマネージドサービスを評価するとき、「何を引き受けてくれるか」だけでなく「何を引き受けてくれないか」を確認することが重要です。以下の観点で整理します。可用性について、SLA は何パーセントか、SLA を下回った場合の補償はサービスクレジットだけか、マルチ AZ やマルチリージョンの構成は自動か手動か。バックアップについて、自動バックアップの頻度と保持期間はどれくらいか、ポイントインタイムリカバリは可能か、リストアのテストは誰が行うか。セキュリティについて、保存時の暗号化はデフォルトで有効か、転送中の暗号化は強制されるか、アクセス制御の粒度はどこまで細かいか。スケーリングについて、自動スケーリングの上限はあるか、スケーリング時にダウンタイムは発生するか、スケールダウンの制約はあるか。モニタリングについて、どのメトリクスが標準で提供されるか、カスタムメトリクスの追加は可能か、アラートの設定は誰が行うか。これらの質問に対する回答が「顧客の責任」である項目が、マネージドサービスを使っていても自分で設計・運用すべき範囲です。 クラウドの運用設計を深く理解するには関連書籍 (Amazon) も参考になります。
まとめ
Undifferentiated Heavy Lifting の概念は、AWS が引き受ける責任の範囲を理解する出発点です。共有責任モデルは概念としては明快ですが、実務では境界が曖昧になるケースが多く、マネージドサービスの抽象度が上がるほど AWS の責任範囲は広がる一方で制約も増えます。最も重要な認識は、マネージドサービスが自動化するのは運用であって設計ではないということです。サービスの選定時には「何を引き受けてくれないか」を明確にし、自分の責任範囲を正確に把握することが、マネージドサービスを活用する上での本質的なスキルです。