Well-Architected Review でよく見つかる指摘事項 - 現場のエンジニアが見落とす 5 つの設計ミス
AWS Well-Architected Review で繰り返し指摘される設計上の問題を、シングル AZ 配置、バックアップ未設定、ログの未活用、コスト最適化の放置、セキュリティグループの過剰許可の 5 つに絞って解説します。
Well-Architected Review とは何か
AWS Well-Architected Review は、AWS のソリューションアーキテクトまたは認定パートナーが、顧客のワークロードを 6 つの柱 (運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性) の観点からレビューするプログラムです。持続可能性は 2021 年 12 月に追加された最も新しい柱です。Well-Architected Tool を使えば、セルフサービスでレビューを実施することもできます。レビューは質問形式で進行し、各質問に対する回答から「高リスク」「中リスク」の問題が特定されます。指摘される問題にはパターンがあり、その多くは特定のサービスに固有の難問ではなく、設計時の初期設定をそのまま残したことが原因です。以下に、レビューでよく見つかる代表的な 5 つの指摘事項を紹介します。これらは技術的に高度な問題ではなく、「知っていれば避けられる」基本的な設計ミスです。
指摘 1: シングル AZ 配置 - 信頼性の柱でよく見つかる問題
本番環境のワークロードがシングル AZ に配置されているケースは、信頼性の柱でよく指摘される問題です。EC2 インスタンスが 1 つの AZ にしか存在しない、RDS がシングル AZ 配置になっている、ロードバランサーが一部の AZ のサブネットにしか関連付けられていない、といったパターンです。Application Load Balancer は作成時に 2 つ以上の AZ のサブネットを指定する必要があるため (公式ドキュメント記載の要件・2026 年 8 月時点)、ロードバランサー側の問題は「後から使い始めた AZ のサブネットをロードバランサーに追加していない」「その AZ のターゲットが登録されていない」という形で現れます。シングル AZ 配置では、その AZ に障害が発生するとサービスが完全に停止します。AZ 障害の発生頻度を AWS が公表しているわけではありませんが、単一の AZ で完結した構成は「1 つの AZ の不調がそのまま全断になる」という構造的なリスクを抱えます。複数 AZ に分散していれば一部の容量が落ちるだけで済んだ事象が、シングル AZ ではサービス全停止として現れます。修正は比較的簡単です。Auto Scaling Group のサブネットに複数の AZ を指定し、RDS をマルチ AZ 配置に変更し、ロードバランサーに複数の AZ のサブネットを関連付けるだけです。マルチ AZ 配置のコスト増は配置方式で変わります。RDS のマルチ AZ DB インスタンス配置はスタンバイ 1 台が加わる 2 台構成なのでインスタンス料金は約 2 倍、読み取り可能なスタンバイ 2 台を持つマルチ AZ DB クラスター配置は 3 台構成なので約 3 倍が目安です (2026 年 8 月時点・公式ドキュメント記載の構成)。いずれにしてもサービス停止による損失と比較すれば合理的な投資です。開発・テスト環境はシングル AZ で構いませんが、本番環境は必ずマルチ AZ にしてください。
指摘 2: バックアップ未設定 - データ損失のリスク
EBS ボリュームのスナップショットが取得されていない、RDS の自動バックアップが無効になっている、DynamoDB のポイントインタイムリカバリ (PITR) が無効になっている、といったバックアップの欠如も、よく見つかる指摘です。S3 の 11 ナインの耐久性に安心して、バックアップを怠るケースもあります。しかし、S3 の耐久性は物理的なデータ損失に対するものであり、誤削除や悪意のある削除からは保護しません。S3 のバージョニングを有効にしていなければ、削除されたオブジェクトは復元できません。AWS Backup を使えば、EC2、EBS、RDS、DynamoDB、EFS、S3 のバックアップを一元管理できます。バックアップポリシーを定義し、スケジュールに従って自動的にバックアップを取得し、保持期間に従って古いバックアップを自動削除します。バックアップの取得だけでなく、定期的なリストアテストも重要です。バックアップが存在しても、リストア手順が確立されていなければ、障害時に復旧できません。
指摘 3: セキュリティグループの 0.0.0.0/0 許可
セキュリティグループのインバウンドルールで 0.0.0.0/0 (すべての IP アドレス) からのアクセスを許可しているケースは、セキュリティの柱で代表的な指摘です。特に、SSH (ポート 22) や RDP (ポート 3389) を 0.0.0.0/0 に開放しているケースは高リスクです。インターネット上のボットは、開放されたポート 22 や 3389 を常にスキャンしており、ブルートフォース攻撃を自動的に実行します。対策は、SSH/RDP のアクセス元を特定の IP アドレスに限定するか、Systems Manager Session Manager を使用して SSH/RDP を完全に排除することです。Session Manager は、IAM 認証でインスタンスにアクセスでき、セキュリティグループでポートを開放する必要がありません。Web サーバーの場合、HTTP (80) と HTTPS (443) を 0.0.0.0/0 に開放するのは正当ですが、ALB の背後に配置し、EC2 インスタンスのセキュリティグループは ALB のセキュリティグループからのアクセスのみを許可する設計が推奨されます。
指摘 4: コスト最適化の放置 - 使っていないリソースの放置
開発・テスト用に起動したリソースが放置され、不要なコストが発生し続けているケースは、コスト最適化の柱でよく見つかる指摘です (以下の料金は 2026 年 8 月時点・バージニア北部と東京の値)。典型的なパターンは、停止し忘れた EC2 インスタンス、アタッチされていない EBS ボリューム、使われていないパブリック IPv4 アドレス、トラフィックのない NAT Gateway です。パブリック IPv4 アドレスは 2024 年 2 月 1 日以降、サービスにアタッチされているかどうかを問わず 1 時間あたり 0.005 USD が課金されます。未アタッチの Elastic IP だけを探して終わりにせず、停止したままの EC2 インスタンスや使っていないロードバランサー・NAT Gateway が保持しているパブリック IPv4 も棚卸しの対象にしてください。NAT Gateway は 1 時間あたりバージニア北部で 0.045 USD、東京で 0.062 USD に加えてデータ処理料金がかかるため、トラフィックが流れていなくても置いておくだけで月額が積み上がります。AWS Trusted Advisor のコスト最適化チェックは、これらの無駄なリソースを自動的に検出します。Cost Explorer の「使用率が低いリソース」レポートも有効です。もう一つよく見つかる指摘は、Savings Plans や Reserved Instances を活用していないケースです。AWS は Savings Plans について、オンデマンド料金と比較して最大 72% の削減になると説明しています (2026 年 8 月時点)。稼働時間が読める本番環境のワークロードをオンデマンド料金のまま動かし続けることは、この割引分をそのまま取り逃していることになります。Cost Explorer の Savings Plans 推奨機能で、最適なコミットメント額を確認してください。
指摘 5: ログとモニタリングの不備
CloudTrail が有効化されていない、CloudWatch アラームが設定されていない、アプリケーションログが構造化されていない、といったログとモニタリングの不備は、運用上の優秀性の柱でよく見つかる指摘です。CloudTrail はデフォルトで管理イベントを記録しますが、S3 への配信 (証跡の作成) を設定していなければ、90 日を超えたイベントは失われます。本番環境では、必ず証跡を作成し、S3 にログを長期保存してください。CloudWatch アラームが設定されていないと、障害の検知が遅れます。最低限、CPU 使用率、メモリ使用率 (カスタムメトリクス)、ディスク使用率、ELB の 5xx エラー率、RDS の接続数にアラームを設定してください。アプリケーションログは、JSON 形式で構造化し、CloudWatch Logs に送信することで、CloudWatch Logs Insights で SQL ライクなクエリで分析できます。非構造化のテキストログは、障害調査時に grep で検索するしかなく、大規模な環境では実用的ではありません。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。