Well-Architected Review で最も多い指摘事項 - 現場のエンジニアが見落とす 5 つの設計ミス
AWS Well-Architected Review で繰り返し指摘される設計上の問題を、シングル AZ 配置、バックアップ未設定、ログの未活用、コスト最適化の放置、セキュリティグループの過剰許可の 5 つに絞って解説します。
Well-Architected Review とは何か
AWS Well-Architected Review は、AWS のソリューションアーキテクトまたは認定パートナーが、顧客のワークロードを 6 つの柱 (運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性) の観点からレビューするプログラムです。Well-Architected Tool を使えば、セルフサービスでレビューを実施することもできます。レビューは質問形式で進行し、各質問に対する回答から「高リスク」「中リスク」の問題が特定されます。AWS のソリューションアーキテクトが数千件のレビューを実施した経験から、繰り返し指摘される問題にはパターンがあります。以下に、最も頻度の高い 5 つの指摘事項を紹介します。これらは技術的に高度な問題ではなく、「知っていれば避けられる」基本的な設計ミスです。
指摘 1: シングル AZ 配置 - 最も多い信頼性の問題
本番環境のワークロードがシングル AZ に配置されているケースは、Well-Architected Review で最も頻繁に指摘される問題です。EC2 インスタンスが 1 つの AZ にしか存在しない、RDS がシングル AZ 配置になっている、ELB が 1 つの AZ のサブネットにしか関連付けられていない、といったパターンです。シングル AZ 配置では、その AZ に障害が発生するとサービスが完全に停止します。AWS の AZ 障害は年に数回発生しており、決して稀なイベントではありません。修正は比較的簡単です。Auto Scaling Group のサブネットに複数の AZ を指定し、RDS をマルチ AZ 配置に変更し、ELB に複数の AZ のサブネットを関連付けるだけです。マルチ AZ 配置のコスト増は、RDS の場合で約 2 倍ですが、サービス停止による損失と比較すれば合理的な投資です。開発・テスト環境はシングル AZ で構いませんが、本番環境は必ずマルチ AZ にしてください。
指摘 2: バックアップ未設定 - データ損失のリスク
EBS ボリュームのスナップショットが取得されていない、RDS の自動バックアップが無効になっている、DynamoDB のポイントインタイムリカバリ (PITR) が無効になっている、といったバックアップの欠如は 2 番目に多い指摘です。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: コスト最適化の放置 - 使っていないリソースの放置
開発・テスト用に起動したリソースが放置され、不要なコストが発生し続けているケースは、コスト最適化の柱で最も多い指摘です。典型的なパターンは、停止し忘れた EC2 インスタンス、アタッチされていない EBS ボリューム、使用されていない Elastic IP アドレス (未アタッチの EIP は 1 時間あたり 0.005 USD が課金)、トラフィックのない NAT Gateway (1 時間あたり 0.045 USD + データ処理料金) です。AWS Trusted Advisor のコスト最適化チェックは、これらの無駄なリソースを自動的に検出します。Cost Explorer の「使用率が低いリソース」レポートも有効です。もう一つの多い指摘は、Savings Plans や Reserved Instances を活用していないケースです。安定した本番環境のワークロードをオンデマンド料金で運用し続けると、Savings Plans と比較して 30〜60% 多く支払うことになります。Cost Explorer の Savings Plans 推奨機能で、最適なコミットメント額を確認してください。
指摘 5: ログとモニタリングの不備
CloudTrail が有効化されていない、CloudWatch アラームが設定されていない、アプリケーションログが構造化されていない、といったログとモニタリングの不備は、運用上の優秀性の柱で最も多い指摘です。CloudTrail はデフォルトで管理イベントを記録しますが、S3 への配信 (証跡の作成) を設定していなければ、90 日を超えたイベントは失われます。本番環境では、必ず証跡を作成し、S3 にログを長期保存してください。CloudWatch アラームが設定されていないと、障害の検知が遅れます。最低限、CPU 使用率、メモリ使用率 (カスタムメトリクス)、ディスク使用率、ELB の 5xx エラー率、RDS の接続数にアラームを設定してください。アプリケーションログは、JSON 形式で構造化し、CloudWatch Logs に送信することで、CloudWatch Logs Insights で SQL ライクなクエリで分析できます。非構造化のテキストログは、障害調査時に grep で検索するしかなく、大規模な環境では実用的ではありません。Well-Architected の設計原則を体系的に学ぶには、専門書籍 (Amazon)が参考になります。