事例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への移行を検討し、人的ミスと運用負荷を低減する。

本稿は、AWS Eventが2025年12月6日に公開したAWS re:Invent 2025 - Architecture lessons: Three failures and how to prevent them (DEV341)を基に作成しました。