「完璧な設計」なのに3000万円溶けた AWSの失敗事例から学ぶ3つの教訓：AWS re:Inventで紹介した「あの失敗」を日本語でレポート

設計図上では完璧に見えたクラウド環境が、本番運用で火を噴いた。アップデート強行で多額の損失、無駄になった開発環境――。AWSのイベントで明かされた「生々しい失敗事例」と、そこから得られる教訓を共有する。

[TechTargetジャパン]

　「全てのアーキテクチャは、現実に直面するまでは完璧に見える」。

　2025年12月、米ラスベガスで開催されたAWS（Amazon Web Services）の年次イベント「AWS re:Invent 2025」。ITサービス企業DXC Technologyのブルーノ・マランゴニ氏（LATAMシニアソリューションアーキテクト）は、聴衆に向かってそう切り出した。本稿では、同氏が共有した中南米の企業における3つの失敗事例と教訓を紹介する。

その障害は「人災」それとも「技術的負債」？

併せて読みたいお薦め記事

IaaSの大規模障害の影響を抑えるには

• AWSの障害で露呈した“企業の事業継続計画の盲点”
• クラウド障害は避けられない　それでも“事業を止めないシステム”を構築するには

事例1．可用性とスケーラビリティ（ブラジルの企業が運営するEC（電子商取引）アプリケーション）

　この企業はiPhoneをはじめとした大手携帯キャリア2社の販売代行を担ってきたが、ブラックフライデーなどのピーク時にECアプリケーション（以下、ECアプリ）がダウンする問題を抱えていた。同ECアプリは平均3000件/日程度のトラフィックがある。

　調査の結果、同社は「プレゼンテーション層」「アプリケーション層」「データ層」の3層構造に分けたアーキテクチャにロードバランサーを追加した一般的なWebアプリケーションの構成を採用していた。しかし、主に以下の問題を抱えていた。

• 手動スケーリング（拡張）
  • キャンペーンなどの繁忙期に手動で仮想マシンサービス「Amazon Elastic Compute Cloud」（EC2）インスタンスを追加していた。
• Availability Zone（AZ）間での偏り
  • 5つのEC2インスタンスが1つのAZに集中、もう1つは1台のみと、特定のAZ間でインスタンスの配置に偏りが発生していた。
• データベースの配置
  • データベースがプレゼンテーション層、データ層と異なるAZに配置されていたため、AZ間で通信レイテンシが約20ミリ秒発生し、顧客体験を損ねていた。
• キャッシュ戦略がない
  • 画像のキャッシュ化をしていなかったため、ユーザーが商品ページにアクセスするたびにデータベースやストレージから画像を取得する仕様になっていた。
• EC2ゴールデンイメージ未使用
  • EC2インスタンスで「ゴールデンイメージ」（Amazon Machine Image：AMI）を使っておらず、新規インスタンスを追加する際に毎回手動でOS、ソフトウェア、依存関係をインストール、設定していた。

　そこでマランゴニ氏のチームは以下を実施した。

• 「Auto Scaling」（コンピューティングリソースやストレージを自動的に増やせる機能）の導入。
• AZ間でのインスタンスの分散。
• EC2のゴールデンイメージ化実施。
• キャッシュの導入
  • プレゼンテーション層とデータ層へキャッシュサービス（クラウドストレージにある重要なデータや頻繁にアクセスするデータを、クラウドサービス内のメモリにキャッシュ（一時保管）する機能）の追加。
• データベースをプレゼンテーション層、アプリケーション層と同一AZに再配置し、レイテンシを約80ミリ秒削減した。
• ブラックフライデーに備え、より可用性を考慮した設計にした。

　マランゴニ氏は「可用性は単なるチェックボックスではなく、アーキテクチャ上の決定事項でありトレードオフだ」と強調する。

事例2．セキュリティ運用の断絶で3000万円の損害（大手銀行）

　同行では、ミッションクリティカルな顧客サービス基盤として「Amazon Elastic Kubernetes Service」（Amazon EKS）を利用し、AWSのセキュリティサービス「AWS Security Hub」による監視を行っていた。さらに、セキュリティ推進団体Center for Internet Security（CIS）準拠のセキュリティチェックが有効になっていた。

　AWS Security HubはEKSのバージョン更新を促すアラートを発し続けていたが、プラットフォームチームはこれを無視し、セキュリティチームとの連携を怠っていた。業を煮やしたセキュリティチームが強制的にアップデートを適用したところ、互換性の問題でアプリケーションがダウンした。

　EKSは一度アップグレードするとダウングレードができない仕様であるため、システム復旧にはAWSパートナーの介入が必要となった。結果として6時間のダウンタイムと120万レアル（約3382万円）の損失を招いた。この事例は、ガバナンスやツールが整っていても、チーム間のコミュニケーションやDevSecOps（開発、運用、セキュリティの融合）が機能しなければアーキテクチャは破綻することを示している。

事例3．コスト管理とマルチアカウント戦略の欠如（クラウド移行中の企業）

　クラウド移行を進めていたある企業では、全ワークロードの70%が開発環境と品質保証（QA）環境で占められていた。それにもかかわらず、EC2、EKS、ECSをはじめとした全クラウドリソースが本番環境と同様に24時間365日、常に動作していた。さらに、開発環境、QA環境にまで、過剰な可用性や冗長性を持たせていた。

　この結果、月額6万レアル（約169万円）、年間で2000万円以上を浪費している状態だった。

　マランゴニ氏のチームは、開発時間外はクラウドリソースを自動でシャットダウンするポリシーや適切なサイジングを適用することで、月額6万レアルのコスト削減を実現した。マランゴニ氏は「クラウドが弾力的（Elastic）であるなら、コストもまた弾力的であるべきだ」と締めくくった。

IT部門が取るべきアクション

• アラート対応プロセスの見直し
  • AWS Security Hubや監視ツールのアラートが、担当者レベルで「無視」または「抑制」されていないか、組織的な棚卸しを進める。
• 開発環境のコスト管理
  • 「開発だから」と放置されているインスタンスがないか確認し、自動停止ポリシーを適用することで、即座にコスト削減効果を出せる可能性がある。
• スケーリングの自動化を検証する
  • 手動でのスケール対応が残っているシステムについては、ゴールデンイメージ化とAuto Scalingへの移行を検討し、人的ミスと運用負荷を低減する。