Zenn
🕌

AWS Well-Architectedに基づく設計実践：基本から詳細まで徹底カバー

2025/02/07に公開
AWS
インフラ
設計
エンジニア
wellarchitected
tech

以下では、基本設計と詳細設計の両方をまとめています。大きく6つの視点（運用優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）に分け、まずは基本設計の要点を整理し、その後に詳細設計で押さえるべき細部を付け加える形にしました。両フェーズを通して確認すれば、AWS上でのシステムアーキテクチャ全体像をより具体的かつ確実に設計・実装できます。

1. 運用優秀性 (Operational Excellence)

1-1. 基本設計

  • モニタリング設計

    • CloudWatchメトリクス：CPU、メモリ、カスタムメトリクス等をサービスごとに選定。
    • アラーム閾値：CPU使用率80%など、通知先SNS/Slackを事前に決める。
    • ログ運用：CloudWatch Logsに送るログ種別と保持期間を検討。外部解析基盤やカスタムメトリクス生成も考慮。

  • 運用ダッシュボード

    • CloudWatch Dashboard：主要KPIや稼働状況を可視化。
    • 異常時リカバリ：ダッシュボードからのワンクリック操作(Lambdaなど)で対処できる仕組みを盛り込む。

  • ログと可観測性

    • 構造化ログ：標準出力／標準エラーへの書き出し。コンテナならFluent Bit等で集約。
    • 分散トレーシング：AWS X-RayやOpenTelemetryを活用してサービス間の可観測性を高め、トレースIDで問題を追跡可能に。

  • 運用ツール統合

    • AWS Systems Manager (SSM)：Run Command、Parameter Store、Secrets Manager、Automationドキュメントで運用のコード化と自動化を進める。
    • No human error：人的ミス削減の仕組み（手順の自動化、集中管理）を具体化。

  • デプロイ/リリース手法

    • ECS：ローリングアップデート、ブルーグリーン、カナリアなど適切な手法を選択。最小稼働タスク数と同時更新数を設定し、無停止リリースやロールバックに備える。
    • Lambda：バージョン＆エイリアスでカナリアデプロイ、API Gatewayのステージ構成など、サービス固有設定を詰める。

1-2. 詳細設計

  • CloudWatchアラームの具体化

    • CPU 80%が5分続いたらスケールアウト、95%が10分続いたら緊急通知、などしきい値と連続データポイント数を明示。
    • CloudWatch Anomaly Detectionやカスタムメトリクス（例：キュー長）のアラーム設定も検討。

  • ダッシュボードと運用ツール実装

    • CloudWatchダッシュボードをJSON定義化し、Terraform/CloudFormationで構築漏れを防止。
    • AWS Systems Manager Automationで「EC2再起動」などをワンクリック化し、運用効率を高める。

  • 通知とチケット連携

    • SNS→Slack/Teams/PagerDutyへの通知フローを整備。
    • 必要に応じ、Lambda経由でフォーマット変換し、自動チケット起票(JIRA/ServiceNowなど)も実装可能に。

  • デプロイパイプライン実装

    • CodePipeline + CodeBuild + CodeDeploy/ECSなどでCI/CD構築。Blue/Greenデプロイのトラフィックシフト割合、失敗時ロールバック設定を明確化。
    • LambdaはAWS SAMやServerless Frameworkでリリースをコード化し、カナリアリリースのウェイト時間や評価基準も設定。

  • インフラ変更管理

    • GitリポジトリでInfrastructure as Codeを管理し、Pull Requestレビュー→mainマージで自動適用の運用ガイドライン。
    • 変更失敗時のロールバック手順(CloudFormationスタックロールバック、Terraform state管理)も定義。

2. セキュリティ (Security)

2-1. 基本設計

  • アクセス制御とIAM設計

    • 最小権限：Lambdaごと/サービスごとに実行ロールを個別化し、不必要なリソース操作権限を与えない。
    • 管理者IAMロール：権限範囲やElevated権限取得プロセスを明文化。

  • ネットワークセキュリティ

    • VPC/SG/NACL：原則許可制で最小範囲のCIDRに限定。
    • Kubernetes利用時：ネットワークポリシーでPod間通信を制御し、最小限に抑える。

  • 暗号化と鍵管理

    • S3暗号化：デフォルト暗号化オン＋KMSのCMKを必要に応じ使用。
    • EBS暗号化：アカウント全体で自動暗号化を有効にして常に暗号化ボリュームを使用。
    • KMSキーの管理：ローテーション設定やキーにアクセスできるIAMを明確化。

  • 機密情報の扱い

    • Secrets Manager/Parameter Store：パスワードやAPIキーを安全に管理し、コードにハードコードしない。
    • コンテナへの注入：タスク定義でSecrets Managerから環境変数に注入し、平文を残さない。

  • 脆弱性管理

    • イメージスキャン：ECRのスキャンや重大脆弱性検出時の通知フローを整備。
    • ランタイム脅威検出：Amazon GuardDutyを活用し、不審挙動を検知。

  • 監査ログとトレイル

    • CloudTrail：全リージョン有効化し、セキュアなS3へ集約。
    • AWS Config：リソース構成の変更履歴を記録して追跡可能に。
    • 改ざん防止：S3バケットのObject Lockや厳格なアクセス制限を検討。

2-2. 詳細設計

  • IAMポリシー定義と付与

    • JSONポリシーをサービスごとに精密化(特定AMI閲覧のみ許可、S3バケット単位でARN指定など)。
    • IAM Access Analyzerで余計な権限がないか検証。

  • セキュリティグループ/NACL設定

    • SGルールはインバウンド・アウトバウンドを全てリストアップし、ポート/プロトコル/範囲を明記。
    • NACLは補助的に使いつつ、Terraform/CloudFormationテンプレートに落とし込む。

  • Webアプリケーションファイアウォール (WAF)

    • AWSマネージドルール＋カスタムルール(IPブロックリスト、レート制限等)を具体的に設定。
    • WAFログをCloudWatch Logs等に蓄積し、SQLインジェクション試行など重大ルールのアラート化を検討。

  • 脅威検出サービス

    • GuardDutyやSecurity HubのFinding通知フローをEventBridge＋SNS/Chatbotで整備。
    • EKS Runtime MonitoringやInspectorレポートを統合監視して、脆弱性を早期発見。

  • 証跡と監査ログ

    • CloudTrailログはS3に保存→Athenaでクエリ可能にし、Glueテーブルを定義。
    • CloudTrail Insightsで異常API検出を有効化。Flow Logs/ELBログなども必要に応じて保存。

  • データ暗号化設定

    • S3 SSE-KMS設定、EBSのEncrypted: True、RDSのStorageEncryptedなどをパラメータで明記。
    • ALBやCloudFrontのTLS1.2以上強制、ACM証明書管理などエンドツーエンドで暗号化を徹底。
    • コンプライアンス(PCI DSS/HIPAA)があれば追加ログ・キーローテーション運用を明文化。

3. 信頼性 (Reliability)

3-1. 基本設計

  • Auto Scalingポリシー設計

    • EC2 ASG：最小・最大・desired台数やターゲット追跡ポリシー(CPU 50%など)を設定。
    • ECS：CPU利用率やカスタムメトリクスによるAuto Scalingをサービス単位で定義。
    • EKS：HPAでDeploymentをスケール、複数Podを常に稼働する構成に。

  • ヘルスチェックとフェイルオーバー

    • ELBヘルスチェック：URL・間隔・閾値で不健康インスタンスを自動切り離し。
    • Route 53：フェイルオーバー切り替え条件を設定。
    • Kubernetes Probes：Readiness/LivenessでPodの状態を制御。

  • バックアップとリストア手順

    • RDS：日次スナップショット＋トランザクションログ、EFSはAWS Backup、DynamoDBはPITR等を有効化。
    • 定期リストア検証：災害対策にS3別リージョンコピーも導入。

  • 障害対応フロー

    • アラーム通知：CloudWatch→SNS→オンコール連絡。重大障害は自動的に特定メンバーへ。
    • ランブック(手順書)：オートヒーリング失敗時の手動介入手順を定義。

  • コンテナ/サーバーレスの信頼性設計

    • ECS：Cluster Auto ScalingやEC2キャパシティプロバイダでノードを自動増減。
    • EKS：Cluster AutoScalerやKarpenter導入、Node Problem Detector等で問題ノードを自動隔離。
    • Lambda：SQS/EventBridgeリトライやDLQを設定し、Step Functionsはエラーハンドリング(Catch/Retry)をコード化。

3-2. 詳細設計

  • リソース冗長構成実装

    • Multi-AZ RDSで自動フェイルオーバーが有効か、Auto ScalingがAZをまたいで動くかをテンプレートレベルで確認。
    • EKSワーカーノードを複数サブネットに配置し、AZ障害時でも稼働が維持される構成に。

  • フォールトインジェクションテスト

    • AZ障害を意図的に起こして冗長化機能が正しく動くか検証。
    • 自動フェイルオーバーのトリガー条件(RDSなど)を理解し、必要なら微調整。

  • 運用シナリオ別手順

    • 「Webサーバ全停止」「DBインスタンス破損」など想定シナリオごとのランブックをドラフト化。
    • Auroraリーダープロモートやフェイルオーバー手順を明文化し、運用チームに引き継ぎ。

  • 可用性テスト計画

    • バックアップ→リストアのテスト、フェイルオーバー時間測定、Auto Scaling挙動の負荷テストを実施。
    • 本番稼働後も定期的にテストし、設計が実際の障害時に機能するかを検証し続ける。

  • 耐障害性のコードへの組み込み

    • アプリケーションでリトライ(Exponential backoff)、サーキットブレーカー、DLQなどを実装。
    • コンテナのSIGTERMハンドリングやGraceful Shutdownタイムを設定し、ローリング更新時の中断に備える。

4. パフォーマンス効率 (Performance Efficiency)

4-1. 基本設計

  • 容量プランニングとリソース選定

    • インスタンスタイプ・スペックを事前見積（Web/AP：c6i.large、DB：r6g.xlarge等）。
    • EBS gp3かio2か要件に応じて決定し、AWSのサービス上限(Lambdaメモリ等)もチェック。

  • キャッシュ層の設計

    • ElastiCache：Redis/Memcachedで頻繁アクセスデータをキャッシュ、TTLやキー戦略を決定。
    • CloudFront：静的コンテンツをキャッシュし、TTLやBehaviorsを具体化。APIキャッシュも検討。

  • アプリケーション性能設計

    • 非同期化/並列化でレスポンス高速化、DBクエリ最適化(CQRSやインデックス)などを適用。
    • 適切なデータストア選択(NoSQL, DWH)やアーキテクチャパターンでスケーラビリティを確保。

  • 性能テスト計画

    • 本番相当環境でJMeter/Locust等を使った負荷テストを実施し、ボトルネックを洗い出す。
    • 目標スループット/レスポンスタイムに達しない場合の対策基準をあらかじめ定義。

  • コンテナ/サーバーレスの性能チューニング

    • EKS/ECS：requests/limits設定、重要サービスに十分なリソースを割り当て。
    • Lambda：メモリサイズを試算し、コールドスタートが問題になればProvisioned Concurrencyを検討。

4-2. 詳細設計

  • ミドルウェア/DBチューニング

    • RDSパラメータグループ(innodb_buffer_pool_size等)やアプリ側のスレッド/コネクションプール、OSカーネルパラメータ(ulimit等)を具体的に設定。
    • Lambda環境変数でAWS SDKコネクション数を制御するなど、ソフトウェアレベルで最適化。

  • Auto Scaling調整

    • スケールアウト/インのしきい値やクールダウンを細かく調整し、スパイク対応と過剰スケールを両立。
    • Scheduled Actionsで昼ピークはスケールインしないなど時間帯考慮を実装。API GatewayにはUsage Plan/スロットリングを設定。

  • 性能テストと結果反映

    • テストで発覚したボトルネック(クエリ遅延やGC問題)に対応し、設計パラメータを見直す。
    • モニタリング結果で継続的にチューニングを行う運用体制を設計書に含める。

  • キャッシュヒット率向上

    • CloudFrontのキャッシュキー設定(不要クエリパラメータ除外)やCache-Controlヘッダ制御(Lambda@Edgeなど)で効率化。
    • ElastiCacheのTTL設定を最適化し、人気データのキャッシュヒット率を高める。

  • データ圧縮と転送効率

    • APIレスポンスのgzip/静的ファイルの圧縮配信、protobuf/Avroなどのバイナリプロトコル検討。
    • 具体的な圧縮レベルやパケットサイズ、Lambdaの不要ライブラリ削除でコールドスタート短縮も考慮。

  • コンテナイメージと起動時間

    • Dockerイメージサイズをアルパイン/Distrolessやマルチステージビルドで削減。
    • ECRを利用し、リージョン内で並列Pull可能にしてスケールアウトを素早く。
    • Lambdaは不要ライブラリを排除し、起動遅延を最小化。

5. コスト最適化 (Cost Optimization)

5-1. 基本設計

  • リソース効率の見直し

    • 過剰な冗長構成を排除し、開発/検証環境ではAuto Scalingしきい値・手動停止手順を整えて無駄を削減。

  • ログ・データのライフサイクル

    • CloudWatch Logsの保持期間を適切に設定(無期限にしない)。
    • S3はアクセス頻度に応じてGlacierへ移行、最終的に削除するライフサイクルルールも設定。

  • タグとコスト配分

    • 統一タグ付与(例: Project, Environment)をCloudFormation/Terraformで自動化し、後のコスト分析を容易に。

  • コストモニタリング設計

    • AWS Budgets, Cost Anomaly Detectionで予算超過や急な増加を通知。
    • Trusted Advisorを定期レポートし、低利用EC2などを検知する仕組みを導入。

  • Reserved/Spot計画

    • 安定稼働リソースにリザーブドインスタンスやSavings Planを適用。
    • 非本番はスポット活用を優先し、スポット中断時の再実行戦略を整える。

5-2. 詳細設計

  • コストダッシュボードとアラート実装

    • AWS Budgetsのしきい値設定(例: 月予算80%超えで通知)。
    • LambdaでCost Explorerレポートを定期生成・送信する仕組みを記述。

  • 無駄リソース自動検出

    • Trusted Advisorを週次でAPI実行→結果をLambdaで集約し通知。
    • Compute Optimizerも有効化し、提案されたダウンサイジングを検討する運用プロセスを設定。

  • スケジュール最適化

    • Instance SchedulerやEventBridge+Lambdaで開発環境を夜間停止。
    • ECSのDesiredタスク数やEKSノード数を夜間に0～最小へスケールダウンするスクリプトを詳細化。

  • Reserved/Spot管理

    • 運用開始後数ヶ月でRI/Savings Plansを買う時期を決める。
    • スポット利用部分は中断通知→Drain処理→再実行を自動化し、ユーザー影響を最小化。

  • ライセンスコスト最適化

    • Windows/SQL ServerなどはBYOLかライセンス込みか比較検討し、最適なAMI/インスタンスタイプを選ぶ。
    • 選択理由を設計書に残し、将来見直しやすくしておく。

6. 持続可能性 (Sustainability)

6-1. 基本設計

  • 未使用リソースの排除

    • 過剰なマイクロサービス分割や使う予定のないサーバーを置かない。最小構成で開始し、必要時に追加する。

  • エネルギー効率指標の組み込み

    • CloudWatchなどでCPU/メモリ使用率を継続監視し、低利用リソースはダウンサイジング。
    • PDCAを回してムダをなくす。

  • グリーンエネルギー活用

    • リージョン選択時に再生可能エネルギー比率を考慮できるなら検討。
    • 東京リージョンのみ利用など制約がある場合は将来的選択肢としてメモ。

  • 将来の改善余地

    • EC2→Fargate、RDB→Serverless Auroraなど移行しやすい疎結合構成を意識し、モジュール化を進める。

6-2. 詳細設計

  • カーボンフットプリント監視

    • AWS提供のカーボンフットプリントツールを四半期ごとにレビューし、Graviton移行等で省エネ対策を検討。
    • レビュー担当/プロセスを設計段階で決めておき、形骸化を防ぐ。

  • 利用率レポート

    • CloudWatchメトリクスを週次や月次で集計し、CPU20%未満のEC2を自動タグ付け→統合・停止候補リスト作成など自動化。
    • LambdaスクリプトでレポートをSlackに通知し、チームで改善アクションを回す。

  • ガベージコレクション

    • 未使用Elastic IPや古いEBSスナップショットを定期検出・削除。
    • 事前承認フロー（Slack通知→承認後にLambdaで削除）を組み、誤削除リスクを最小化。

  • 継続的改善の文化定着

    • 運用会議で環境効率レポートを定期レビューし、改善タスクを洗い出す。
    • 最新クラウド技術のキャッチアップ担当を置き、今後もサステナビリティ最適化を進める。

まとめと次のステップ

  • 基本設計では、アーキテクチャの方針・構成要素・実現パターンを中程度の詳細度で策定。
  • 詳細設計では、それをさらに具体化（AWSリソースの設定値、パラメータ、スクリプト、IaC定義など）し、実装や運用時に迷わないレベルまで落とし込む。
  • 両フェーズを通じて、運用優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性の6項目を網羅することで、安心かつ柔軟で拡張性の高いクラウド基盤を構築できる。

大枠で方針を固めたら、あとは実際にAWSリソースを作りつつテストを行い、必要に応じて微調整していきましょう。これらを体系立てて進めることで、最終的に高品質なシステムを自信を持ってリリース・運用できます。

Discussion