本記事は、2025年11月に開催されたクラウドネイティブ技術のカンファレンス「KubeCon + CloudNativeCon North America 2025」におけるセッションの内容を紹介する。対象となるのは、Amazon Web Services（AWS）の費用最適化を専門とするコンサルティング企業The Duckbill Groupのチーフクラウドエコノミストであるコーリー・クイン氏のセッションだ。

　ベンダーに依存しないシステムを構築しようとすると、特定のクラウドサービスに特化した便利なマネージドサービスの利用を意図的に避けることになる。データベースや監視ツール、シークレット（機密情報）管理などを全てオープンソースソフトウェア（OSS）を用いて自前で構築、運用するという道を選ぶわけだ。

　その結果、インフラの可用性確保から障害への対処、バックアップ体制の構築まで、全ての責任と運用負荷が自社のIT部門に重くのしかかる。これは、クラウドサービスがもたらす最大の恩恵である「運用負荷の軽減」を自ら放棄する行為に等しい。オンプレミスシステム構成以上の高い費用を支払いながら、午前3時に発生したデータベースのクラッシュ処理に自社のエンジニアがたたき起こされることになる。クイン氏の言葉を借りれば、巨額を投入して「質の悪いデータセンター」を構築しているようなものだ。

マルチクラウドが招く「2倍の障害点」

　単一のクラウドベンダーへの依存を嫌い、可用性を高める目的で複数のクラウドベンダーのサービスを利用する「アクティブ・アクティブ構成」を採用するケースも散見される。しかし、このマルチクラウド戦略はリスクを減らすどころか倍増させる要因になり得る。

　AWSとMicrosoft Azureの両方でシステムを稼働させた場合、どちらか一方のクラウドサービスに障害が発生しただけで、自社のサービスも巻き添えを食うことになる。単一障害点を排除したつもりが、実際には2つの単一障害点を作り出しているに過ぎない。

　異なる2つのクラウドサービス間で、ID・アクセス管理システム（IAM）の概念やネットワークの挙動、特有の障害パターンを完全に把握し、横断的に処理できるエンジニアはまれだ。障害発生時、普段使い慣れていないクラウドサービスの設定によるエラーを夜間に調査することは、原因究明を極めて困難にし、サービスの復旧時間を大幅に長期化させる。

最大のロックインは「チームの知識」

　インフラのポータビリティを確保したとしても、エンジニアの知識を簡単に移行できるわけではない。特定のクラウドサービスで培ったネットワークの癖や、障害時の挙動に関するトラブルシューティングのノウハウは、別のクラウドサービスに移行した瞬間、役に立たなくなってしまう可能性がある。

　真のベンダーロックインは、インフラの仕様や契約条件ではなく、そのシステム構成で長年トラブルシューティングを担当してきたチームの深い知識と経験によって引き起こされている。移行に伴う学習にかかる手間や人員の消費と、一時的な運用能力の低下は、企業にとって計り知れない損失を生む。

運用負荷の軽減こそがクラウドの真価

　クイン氏は、「ポータビリティのための過剰な抽象化を直ちに捨て去るべきだ」と主張する。自社の要件に最も適合するクラウドサービスを1つ選び、そのマネージドサービスを活用することを推奨している。Google Cloudを利用し、ソースコード共有サービス「GitHub」を活用するといったように、特定の用途において最適な手段を選択することは「マルチクラウド」ではなく、単なる「適材適所」だ。

　IT部門の限られた人員と予算は、インフラの保守や抽象化レイヤーの維持ではなく、自社のビジネス価値を生み出す中核業務に注がれるべきだ。最終的な目標は、どのクラウドサービスでも動くというポータビリティを確保することではなく、不要なインフラ運用から解放され、エンジニアが十分な睡眠をとれる健全な労働条件を構築することに他ならない。

　クラウド戦略において、非現実的なポータビリティを追い求めることは、貴重な人員の浪費につながる。自社のシステムと運用チームの現状を正しく把握し、クラウドサービスが提供する利点を最大限に引き出す現実的なインフラ設計が、今後のビジネス成長の鍵を握る。

本稿は、CNCFが2025年11月25日に公開した動画「The Myth of Portability: Why Your Cloud Native App Is Married To Your Provider - Corey Quinn」を基に作成しました。