.png&w=3840&q=75)
「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？
はじめに
こんにちは。清水（@isaoshimizu）です。今回は、2025年10月27日に公開された記事
"Multi-Cloud" and "Return to On-Prem" Aren't your silver bullets: A reality check after the AWS outage （日本語訳：“マルチクラウド”や“オンプレ回帰”は銀の弾丸ではない――AWS障害後のリアリティチェック）を読みました。
日本時間の2025年10月20日、AWSで障害が発生しました。この障害は規模が大きく、影響範囲も広かったため、記憶に残っている方も多いのではないでしょうか。
今回の障害は、DynamoDBにおけるエンドポイントの名前解決に問題が発生したことをきっかけに、EC2やNLB、サポート窓口のAWS Supportなどにも影響が波及し、AWSを利用する多くの商用サービスに影響を及ぼしました。
こうした大規模なクラウド障害を経験すると、「マルチクラウドにしたほうがよいのでは」「オンプレを利用しておけばよかった」といった声を目にすることがあります。記事では、これらの選択肢が本当に解決策になり得るのか、“銀の弾丸”（万能の解決策）になり得るのかについて解説しています。今回の#も読では、この記事の内容と私の考えを紹介します。
マルチクラウドは多くの組織にとって解決策にはならない
記事では、以下の理由から「マルチクラウドは多くの組織にとって解決策にはならない」と説明しています。
クラウド各社の機能にはそれほど互換性がない
まず記事では、AWSのSQS、Azure Service Bus、Google CloudのPub/Subにおいて、API・保証・動作のいずれにも違いがあると指摘しています。他にも各社のKey-Value Store、サーバーレス、シークレットマネージャーなどのサービスについても言及しており、各社で違いがある中、併用して運用する難しさを挙げています。
確かに、クラウド各社はさまざまな機能を提供していますが、完全に同一のものは少なく、微妙な差異を埋めるにはアプリケーション側で追加の実装や抽象化が必要になります。
アプリケーションからクラウドの機能を使う場合、クラウドのライブラリを利用するケースが多く、クラウド各社のSDKをインポートし、それらの機能差を意識した実装はどうしても複雑になりがちです。結果として、メンテナンス性の高いコードを実装する難易度も上がるでしょう。
また、片方のクラウドのみが提供している機能を使いたくても、もう片方がその機能を持っていない場合は、機能を持っていない側に合わせなければいけないケースもあり得ます（逆のパターンもあり得るとは思います）。特に、権限管理やセキュリティに関わるサービスはクラウドごとに異なるため、それぞれの特徴や機能差を理解せずに併用すれば、セキュリティホールにつながるかもしれません。
目に見えるコストと隠れたコストがある
記事では、マルチクラウドで重複した機能を利用することでコストが増加する点にも言及しています。例えば、コンピュートリソースを各クラウドに持たせる場合は、それぞれのクラウドにKubernetesのクラスタを用意する必要があるかもしれません。データベースサーバーをどちらのクラウドに置くか、あるいは両方に置くかによってもコストは変わり、実装の複雑性にも影響します。
そして、クラウドごとに異なる機能・セキュリティ対策・料金体系を理解するための学習コストや人材育成コストも発生します。Infrastructure as Codeを実現する際にも、クラウド独自の機能とパラメーターの意味や挙動を理解するのに学習コストがかかります。
デプロイ基盤を各クラウドに対応させる必要性も生じます。開発したアプリケーションを各クラウドへ並列にデプロイするための仕組みや、リバート（切り戻し）の手順などを踏まえると構成は複雑化し、トラブルにつながる可能性もあります。こうした部分にも抽象化レイヤーが必要になるかもしれません。
クラウド間のネットワークトラフィックもコスト増につながります。通常、同一クラウド内のネットワークトラフィックは無料ですが、クラウド間通信ではインターネット経由になるため有料です。マルチクラウドではクラウド間のデータ転送が発生するため、このコストを考慮する必要があります。
復旧に関する誤解
マルチクラウドにすれば、自動的に復旧するわけではありません。マルチクラウドよりも、マルチリージョンのほうが効果的なケースがあります。リージョンに依存しない中央集権的な機能が障害を受けた場合は、マルチリージョンでも対策にはなりませんが、こうしたケースはまれです。
また、アプリケーションをマルチクラウドに対応させても、片側のクラウドに障害が起きた際にうまく切り離せるかどうかは別問題です。障害の検知と切り離しの条件設定は難易度が高く、それを自動化するのは容易ではありません。先に言及したデプロイ基盤も影響を受けることが想像できます。
オンプレのままだったらよかったのか
オンプレのデータセンターを構築・運用するには、莫大なコストがかかります。新しいサーバーや機器を導入するにも様々な検証が必要となるでしょう。物理的なセキュリティ対策や冗長性を備えたネットワーク構成、電力インフラの運用なども欠かせません。冗長構成を考える箇所が多岐にわたるため、抜け漏れなく障害に備えた運用をするのは難易度が非常に高く、物理的コストも人的コストも大きな負担となります。
マルチクラウドが望ましいケース
何らかの理由によって利用したいリージョンが限定されている場合、特定のクラウドでしかそのリージョンが提供されていないことがあります。地理的にデータ保管場所が規定されている場合はマルチクラウドが有効となるでしょう。M&Aなどでインフラを引き継いだときは一時的にマルチクラウドにせざるを得ない場合があります。
あるクラウドの特定サービスのみを利用したい場合も同様です。例えばAmazon S3のオブジェクトストレージの機能や堅牢性を重視して、AWS以外のクラウドから同サービスのみを利用するケースは十分にあり得ます。このように部分的な利用によってメリットを得られるケースはあり、サービスの形態によっては有力な選択肢となるでしょう。
単一のクラウドで調達できるサーバーの台数に限界がある場合にマルチクラウドを活用するケースも考えられますが、この場合においてはマルチリージョンのほうが好ましいです。しかし、地理的な制約によって単一クラウドではリソースが賄えない場合は、マルチクラウドを選択するという手もあるでしょう。
オンプレが望ましいケース
オンプレは、法的な要件がある場合、政府や防衛など極めて機密性の高いシステムを扱う場合、レガシーなシステムでクラウド移行が困難な場合、特殊なハードウェアや仮想化できない機器などを利用する場合には有効でしょう。
私の経験では、かつてはクラウドよりもオンプレのサーバーやストレージのほうが性能が高いケースにおいては、オンプレを活用したことがありました。しかし時代の変化によってクラウドの性能も十分に向上しており、現在ではあまり有効ではないかもしれません。
オンプレとクラウドのハイブリッド構成が有効なケースもあります。オンプレからクラウドへの移行中は一時的にハイブリッド構成が必要になります。クラウドをメインにしつつ専用線でオンプレと接続し、オンプレでしか使えないハードウェアを利用するハイブリッド構成も有効でしょう。
クラウド利用において考慮すべきこと
単一のゾーンやリージョンのみを利用する構成は、耐障害性の観点で課題があります。リージョン単位で障害の影響を受けることは少ないですが、絶対に起きないとはいえません。また、リージョンに比べ、ゾーンの障害のほうが発生する確率は高いでしょう。
複数のゾーンやリージョンを併用することで、障害発生時の影響を最小限にできます。その分かかるコストと万が一の障害発生による損失を十分に考慮し、複数ゾーン／リージョン構成が必要かを検討することが大事です。クラウドの障害対策のためにマルチクラウドを検討する場合は、これらを十分に検討したうえで最適な構成を選びましょう。
まとめ
記事を読み、マルチクラウドやオンプレを選択する意味を改めて考えるきっかけになりました。私自身は、オンプレ／クラウドのみ、マルチクラウド、ハイブリッドと、あらゆる構成のシステムを本番運用した経験がありますが、いずれも明確な選定基準があり、それぞれの長所・短所を理解したうえで運用していました。
数年に一度のレベルで大規模なクラウド障害が発生したとしても、様々な観点から冷静な判断が必要です。マルチクラウドやオンプレが必ずしも悪いわけではありません。重要なのは、運用するシステムやサービスにとって最適な構成は何かを定期的に見直し、障害による損失と運用コストが見合っているかを見極めることでしょう。