AWS Certified Solutions Architect Associate
最終確認：2026年5月
SAA-C03 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
Web、アプリケーション、DBの3層アプリケーション。DBはいかなる状況でもインターネットからアクセスできないようにする必要があります。
Web層にはパブリックサブネット (ALB)。アプリケーション層とDB層にはプライベートサブネット。DBのセキュリティグループは、アプリケーション層のセキュリティグループからのトラフィックのみを許可します（CIDR範囲からではない）。
理由: サブネットのルーティングテーブルが到達可能性を強制し、セキュリティグループ間の参照はSG層で最小特権をエンコードし、IPアドレスの変更後も有効です。
EC2インスタンスがS3にアクセスする必要があります。組み込みの認証情報は避けてください。
インスタンスプロファイル経由でIAMロールをアタッチします。SDKはIMDSv2から一時的な認証情報を取得します。
理由: インスタンス上の長期的なアクセスキーは、認証情報漏洩の主な原因です。ロールは自動的にローテーションされ、永続化されません。
EC2インスタンスメタデータを読み取ろうとするSSRF攻撃をブロックします。
インスタンス起動時にIMDSv2 (`HttpTokens=required`) を強制します。IMDSv1の認証されていないリクエストを拒否します。
理由: IMDSv2はメタデータエンドポイントが応答する前にPUT経由でセッショントークンを必要とします。GETのみを行うSSRF攻撃はブロックされます。
アカウントAのサービスAがアカウントBのLambdaを呼び出します。最小特権で設定します。
ターゲットLambdaのリソースベースポリシーで、アカウントAのロールプリンシパルに`lambda:InvokeFunction`を許可します。呼び出し元は自身のロールを引き受けて直接呼び出します — ロールチェーンは不要です。
理由: リソースポリシーは、サービスが前面に出るリソース（Lambda、S3、SNS、SQS、KMS）にとって最もシンプルなクロスアカウントパターンです。
他のAWSアカウントが中央のS3バケットにアップロードする必要があります。
バケットポリシーで外部アカウントのプリンシパルに`s3:PutObject`を許可します。バケット所有者がオブジェクトの制御を維持できるように`bucket-owner-full-control` ACL要件を追加します。
理由: `bucket-owner-full-control`（または`BucketOwnerEnforced`オブジェクト所有権）がないと、アップロードされたオブジェクトは書き込み元アカウントが所有します。
組織内のS3バケットが公開されるのを防ぎます。
アカウントレベルでS3ブロックパブリックアクセスを有効にし（SCPs経由でOrganizations全体に適用）、バケットレベルのACLとポリシーを上書きします。
理由: アカウントレベルの設定は、バケットごとの設定よりも優先されます — 偶発的な誤設定に対する防御です。
開発者はIAMロールを自己提供できますが、定義された最大権限セットを超えて付与することはできません。
開発者プリンシパルに権限境界を設定します。有効な権限は、IDポリシーと境界の積集合になります。
理由: SCPはアカウント/OUレベルで適用されます。境界は個々のプリンシパルをスコープします。委任された管理パターンには境界を使用します。
データレジデンシーコンプライアンスのため、OUを特定のRegionに制限します。
Organizationsで、`aws:RequestedRegion`が許可リストに含まれていないすべてのアクションを拒否するサービスコントロールポリシー (SCP) を作成します。
理由: SCPは、アカウント自体が許可するアクションを拒否できる唯一のメカニズムです。IAMは、アカウントルートが許可できるものを拒否することはできません。
複数のAWSアカウントにわたる従業員のシングルサインオンを、企業のIdPと統合します。
企業のIdPへのSAML/OIDCフェデレーションを備えたAWS IAM Identity Center（旧AWS SSO）を使用します。権限セットはメンバーアカウントのロールにマッピングされます。
理由: Identity Centerは、マルチアカウントの従業員ID管理の標準的な方法です。Cognitoはアプリケーションのエンドユーザー向けであり、従業員向けではありません。
Cognito User PoolとIdentity Poolのどちらかを選択します。
User Pool = アプリケーションユーザーのサインアップ/サインイン/JWT発行。Identity Pool = トークンを一時的なAWS認証情報と交換します。ほとんどのアプリは両方を使用します。User Poolが認証し、Identity PoolがAWSアクセスを認可します。
Cognitoサインインにカスタム検証ステップを追加します（例: メールドメインの許可リスト）。
Lambdaトリガー（Pre Sign-up、Pre Authentication、Define/Create/Verify Auth Challenge）を使用し、Lambda内で検証または拒否します。
キーのローテーション、削除、キーごとの監査ログを完全に制御する必要があります。
カスタマーマネージドKMSキー (CMK) を使用します。AWSマネージドキー (`aws/<service>`) はよりシンプルですが、キーポリシーの制御や個別のキー使用状況の可視性を提供しません。
理由: CMKを使用すると、CloudTrailでキーごとにアクセスをスコープ設定し、クロスアカウント利用のキーポリシーを設定し、無効化/削除スケジュールを設定できます。
アカウントBがアカウントAのCMKで暗号化されたS3オブジェクトを復号化する必要があります。
CMKのキーポリシーでアカウントBのプリンシパルに`kms:Decrypt`を許可します。アカウントBのIAMもキーARNに対して`kms:Decrypt`が必要です。両方の設定が必要です。
理由: KMSのクロスアカウントアクセスには、キーポリシーと呼び出し元のIAM IDの両方で明示的な許可が必要です（ほとんどのリソースポリシーとは異なります）。
`us-east-1`でデータを暗号化し、レプリケーション後に`us-west-2`で再暗号化せずに復号化します。
KMSマルチリージョンキーを使用します。一方のRegionにプライマリ、もう一方にレプリカがあり、両方とも同じキーマテリアルとIDを持ちます。
理由: クロスRegionのフェイルオーバーやDRの際に、暗号文の再ラップ処理を回避します。
オブジェクトごとのKMS API呼び出しによるコストが支配的にならないように、大きなオブジェクトを暗号化します。
エンベロープ暗号化を使用します。KMSがデータキーを生成し（API呼び出し1回）、そのデータキーを使用してペイロードをローカルで暗号化し、暗号化されたデータキーを暗号文とともに保存します。
理由: KMSはリクエストごとにレート制限があり、料金が発生します。エンベロープパターンは、数KBを超えるデータを暗号化する標準的な方法です。
Secrets ManagerとSSM Parameter Store SecureStringのどちらかを選択します。
自動ローテーション、クロスアカウント共有、大きなシークレットを伴うDB認証情報 → Secrets Manager。設定フラグ、アプリ設定、シンプルなシークレット、最低コスト → SSM Parameter Store。
理由: Secrets ManagerにはRDS/Aurora/DocumentDB/Redshift向けの組み込みローテーションLambdaがありますが、Parameter Storeにはネイティブのローテーション機能がなく、スタンダードティアでは無料です。
RDSパスワードを30日ごとに自動的にローテーションします。
マネージドローテーションを備えたSecrets Managerを使用します。組み込みのLambdaテンプレートがRDSエンドポイントに対するシングルユーザーローテーションを処理します。アプリは接続時にシークレットを取得し（キャッシュされます）、アプリの再デプロイは不要です。
正当なスパイクをブロックせずに、レイヤー7 HTTPフラッド攻撃を軽減します。
ALBまたはCloudFront上でAWS WAFレートベースルール（例: IPアドレスあたり5分間に2000リクエスト）を使用します。既知の不正なIPアドレスにはマネージドルールグループと組み合わせます。
理由: WAFレートルールは送信元IPアドレスごとに追跡し、しきい値を超えると自動的にブロックし、期間が過ぎると解除します。
ミッションクリティカルなアプリケーションには、DDoSコスト保護と24時間365日のSRTサポートが必要です。
CloudFront / ALB / NLB / Global Accelerator上でAWS Shield Advancedを使用します。これにはコスト保護（攻撃中のスケーリング費用に対する返金）とShield Response Teamへのアクセスが含まれます。
理由: Shield Standardは自動的で無料ですが、Advancedは保護とSLAを追加します。CloudFrontは常に推奨されるフロントドアです。
セキュリティグループとNACLのどちらを選択します。
ステートフル、ENIにアタッチ、許可のみ → セキュリティグループ（デフォルト）。ステートレス、サブネットレベル、許可＋明示的な拒否 → NACL。NACLは包括的な拒否ルール（IP範囲のブロック）に使用し、その他すべてにはSGを使用します。
理由: NACLはインバウンドとアウトバウンドを個別に評価します。SGは戻りトラフィックを自動的に許可します。
プライベートサブネット内のEC2がNATエグレスコストなしでS3/DynamoDBに到達する必要があります。
S3およびDynamoDB用のVPCゲートウェイエンドポイントを使用します。無料で、ルーティングテーブルエントリがあり、NATは不要です。
理由: ゲートウェイエンドポイントはS3/DynamoDB専用です。NATのデータ処理料金を節約し、トラフィックをAWSバックボーン上に保持します。
プライベートサブネットがAWSサービスAPI（KMS、Secrets Manager、ECRなど）にプライベートに到達する必要があります。
サービスごとにVPCインターフェースエンドポイント (PrivateLink) を使用します。VPC内にENIが作成され、時間単位およびGB単位で課金されます。
理由: インターフェースエンドポイントはほぼすべてのAWSサービスで機能します。サービスコールに対するNATエグレスを排除するために使用します。
SaaSプロバイダーが、VPCピアリングや顧客ルーティングの維持なしに、VPC内サービスを顧客アカウントにプライベートに公開します。
NLBによってバックアップされたAWS PrivateLinkエンドポイントサービスを使用します。顧客はインターフェースエンドポイントを作成して消費します。
理由: CIDRの重複に関する懸念がなく、ピアリングメッシュも不要で、一方通行の公開です（プロバイダーは顧客のトラフィックを見ません）。
ハブ＆スポークトポロジーで、複数のアカウントとオンプレミスにある30以上のVPCを接続します。
AWS Transit Gatewayを使用します。VPCごとに1つのアタッチメント。ルーティングテーブルでトラフィックをセグメント化します。
理由: フルメッシュのピアリングにはN×(N-1)/2の接続が必要です。TGWは線形にスケールし、RAMを介したクロスアカウントをサポートします。
予測可能な帯域幅、低レイテンシー、暗号化が必要なハイブリッド接続。
Direct Connectと、DX上のSite-to-Site VPN（MACsecまたはIPsec）を使用します。DX単独では暗号化されていません。DX上のVPNはプライベートで暗号化されており、低ジッターです。
理由: インターネット経由のプレーンなVPNは安価ですが、レイテンシーが変動します。DX単独は高速ですが、リンク層でプレーンテキストです。
VPCフローログ、DNS、CloudTrail、EKS監査、S3データイベントにわたる継続的な脅威検出。
Amazon GuardDutyを使用します。Organizationsの委任された管理者を通じて組織全体で展開します。
理由: マネージド脅威検出サービスです。検知結果はSecurity HubまたはEventBridgeに送信され、応答の自動化に利用できます。
S3バケット内のPII / PHIを検出・分類します。
Amazon Macieを使用します。MLベースの機密データ検出サービスで、S3にスコープされ、Security Hubと統合されます。
EC2、ECRイメージ、Lambda関数の継続的なCVEスキャン。
Amazon Inspector v2を使用します。Systems Managerエージェント経由でリソースを自動的に検出し、公開されているCVEに対してスキャンします。
GuardDuty、Inspector、Macie、IAM Access Analyzerからの検出結果を1つのダッシュボードに集約します。
AWS Security Hubを使用します。AWS Foundational Security Best PracticesとCIS標準に準拠したCSPMです。
すべてのEBSボリュームが暗号化されていることを強制し、非準拠リソースを自動的に修復します。
AWS Configルール（マネージド`encrypted-volumes`）と、Configの修復アクションを通じてトリガーされるSystems Manager Automationランブックを組み合わせて修復します。
組織内のすべてのアカウントにわたる単一の改ざん防止監査ログ。
ログファイル検証を有効にしたOrganizationsのトレイルを使用し、削除を拒否するバケットポリシーを持つ中央S3バケットに書き込みます。
理由: 組織トレイルは、すべてのメンバーアカウント（現在および将来の）で自動的に有効になります。検証ハッシュはログが変更されていないことを証明します。
複数の部門が、共有S3バケット内の異なるプレフィックスに対してスコープされたアクセスを必要とします。
S3 Access Pointsを使用します — 部門ごとに1つずつ、それぞれが独自のアクセスポリシーと（オプションで）VPC制限を持ちます。
理由: 複雑なバケットポリシーよりもクリーンです。Access Pointsは独自のARNとDNS名を持ちます。
PCI DSSワークロード — 非PCIアカウントからの厳格な分離。
Organizations OU内に専用のAWSアカウントを置き、サービス/Regionアクセスを制限するSCPを設定します。VPC、KMSキー、IAMロールを分離します。エグレス検査にはNetwork FirewallまたはGWLBを使用します。
理由: アカウント境界は、AWSにおける最も強力な爆発半径分離です。
ALBとCloudFrontに`*.example.com`用の公開TLS証明書を使用します。自動的に更新されます。
Route 53でDNS検証を行うAWS Certificate Manager (ACM) のパブリック証明書を使用します。有効期限の60日前に自動更新されます。
理由: AWS統合サービスでの利用は無料です。Eメール検証も可能ですが、自動化にはDNS検証が推奨されます。
1分未満のフェイルオーバーを伴う本番RDSデータベース。
RDS Multi-AZデプロイメント（またはMulti-AZ DB Cluster）を使用します。スタンバイへの同期レプリケーション、DNSエンドポイント切り替えによる自動フェイルオーバーが行われます。
理由: Multi-AZはHA用であり、リードスケーリング用ではありません。リードレプリカはリードスケーリング用（非同期で潜在的なラグがある）です。
新しいMySQL/PostgreSQLワークロード向けにAuroraとRDSのどちらを選択します。
高いスループット、高速フェイルオーバー、最大15のリードレプリカ、Global Database、Serverless v2が必要な場合はAurora。古いエンジン（MariaDB、Oracle、SQL Server）またはよりシンプル/安価なデプロイメントの場合はRDS。
理由: Auroraのストレージはレプリカ間で共有されます（ストレージからのレプリカラグがありません）。フェイルオーバーは通常30秒未満です。
レプリケーションラグ1秒未満、RTO1分未満のアクティブ-パッシブマルチリージョンデータベース。
Aurora Global Databaseを使用します。最大5つのセカンダリRegionへのストレージレベルレプリケーションが行われ、災害時にはセカンダリをプライマリに昇格させます。
理由: レプリケーションには専用のインフラストラクチャが使用され、クロスRegionのラグは通常1秒未満です。リモートRegionのリードレプリカは低レイテンシーのローカルリードを提供します。
アイドル期間のある、変動的で予測不可能なデータベース負荷。
Aurora Serverless v2を使用します。0.5 ACU単位でスケールし、スケールイベントは1秒未満で、完全な一時停止はありませんが非常に低い最小値で動作します。
理由: v2はスケールイベント中も接続を維持します（v1とは異なります）。ACU秒単位で課金されます。
3つ以上のRegionで1桁ミリ秒の読み書きを、last-writer-winsレプリケーションで実現します。
DynamoDB Global Tablesを使用します。last-writer-wins競合解決によるマルチアクティブレプリケーションが行われます。
理由: すべてのRegionでアクティブ-アクティブです。リーダーは存在しません。アプリケーションレベルの競合許容が許容される場合に使用します。
誤って削除した後、過去35日間の特定の時点にDynamoDBテーブルを復元します。
Point-in-Time Recovery (PITR) を有効にします。復元すると、選択した秒数で新しいテーブルが作成されます。
プライマリRegionにトラフィックをルーティングし、ヘルスチェック失敗時にセカンダリにフェイルオーバーします。
Route 53フェイルオーバールーティングポリシーを使用します。プライマリエンドポイントのアクティブヘルスチェックが失敗した場合、セカンダリレコードがサービスを提供します。
理由: アプリケーション層のヘルスチェック（HTTPパス）は、TCPプローブでは見逃される部分的な障害を検出します。
各ユーザーを、最も低レイテンシーで健全なRegionに送ります。
Route 53レイテンシーベースルーティングを使用します。各エンドポイントのヘルスチェックを行い、Route 53はクエリごとに最も低レイテンシーで健全な応答を返します。
カナリアリリース：トラフィックの10%をv2に、90%をv1に送ります。
Route 53加重ルーティングを使用します。同じ名前で異なるターゲットを持つ2つのレコードを作成し、それぞれ10と90の重みを割り当てます。
EC2インスタンスの初期化に3分かかり、トラフィックのスパイク時にスケールアウトが遅すぎます。
Auto Scaling warm poolを使用します。事前に初期化されたインスタンスを停止状態（安価）で維持し、数秒で起動できるようにします。
理由: コールド起動とブートストラップがボトルネックです。ウォームプールはその作業をクリティカルパスから外します。
スケールイン時に、インフライトの作業をドレインし、インスタンスが終了する前にログを永続化します。
`Terminating:Wait`にAuto Scalingライフサイクルフックを使用します。フックはSNS/EventBridgeに発行し、ハンドラーがドレインを完了して`complete-lifecycle-action`を呼び出します。
中断を許容する非クリティカルなフリートのコンピューティングコストを削減します。
混合インスタンスポリシーを持つASGを使用します。オンデマンドでベース容量を確保し、追加容量をSpotインスタンスで提供し、複数のインスタンスタイプとAZで多様化します。
理由: インスタンスタイプを多様化することで、単一プールと比較してSpotインスタンスの中断リスクが低減します。
ALBとNLBのどちらを選択します。
HTTP/HTTPS、パス/ホストルーティング、WAF統合、OIDC認証 → ALB。極端なスケールでのTCP/UDP/TLS、AZごとの静的IP、最低レイテンシー、クライアント送信元IPの保持 → NLB。
VPC間トラフィック検査のために、サードパーティのセキュリティアプライアンスフリートをインラインで挿入します。
Gateway Load Balancer (GWLB) を使用し、アプライアンスフリートをターゲットとします。GENEVE経由でトラフィックをカプセル化し、ルーティング経由で透過的に挿入します。
処理に失敗し続けて再キューイングされるポイズンメッセージ。
SQS Dead-Letter Queueを使用します。ソースキューに`maxReceiveCount`を設定し、このカウントを超えるメッセージは検査のためにDLQに移動します。
メッセージグループごとに厳密な順序付けと、一回限りの処理。
コンテンツベースの重複排除または明示的な`MessageDeduplicationId`を持つSQS FIFOキューを使用します。並行して順序付けられたグループには`MessageGroupId`を使用します。
理由: 標準SQSは少なくとも1回の処理で順序保証はありません。FIFOは、高スループットモードを使用しない限り、スループットが低くなります。
非同期Lambdaがダウンストリームのタイムアウトで失敗した場合、失敗したイベントをキャプチャしてリプレイします。
Lambda Destinationsを使用します。失敗時の送信先をSQS / SNS / EventBridge / 別のLambdaに設定します。成功時の送信先もサポートされます。
理由: 関数のDLQよりもクリーンです。デスティネーションは完全なイベントと応答ペイロードを受け取りますが、DLQはトリガーイベントのみを受け取ります。
マルチステップワークフローで、タスクごとの指数バックオフとエラーキャッチを伴う再試行が必要です。
AWS Step Functions Standardワークフローを使用します。`IntervalSeconds`、`MaxAttempts`、`BackoffRate`を持つ`Retry`ブロックを設定します。`Catch`ブロックは特定のエラーをリカバリスステートにルーティングします。
CloudFrontオリジン（S3またはALB）が失敗した場合、DNS変更なしでセカンダリオリジンにフォールバックします。
プライマリとセカンダリを持つCloudFrontオリジングループを使用します。フェイルオーバー基準（4xx/5xxコード）を設定します。CloudFrontはセカンダリに対して再試行します。
EBS、RDS、DynamoDB、EFS、FSx全体で、1つの保持ポリシーを使用してバックアップを一元化します。
AWS Backupを使用し、バックアッププランとタグによるリソース選択を行います。クロスアカウント/クロスRegionコピーがサポートされます。Vault Lockはコンプライアンス上の不変性を実現します。
ランサムウェア対策バックアップ：管理者でさえ保持期間前に削除できません。
コンプライアンスモードのAWS Backup Vault Lockを使用します。WORM（一度書き込んだら読み取り専用）を強制し、rootユーザーでさえ保持期間を短縮することはできません。
RPO/RTO要件に応じてDRパターンを選択します。
バックアップ＆リストア: RPO数時間、RTO数時間、最も安価。パイロットライト: RPO数分、RTO数十分。ウォームスタンバイ: RPO数秒、RTO数分。マルチサイトアクティブ-アクティブ: RPOほぼゼロ、RTO数秒、最も高価。
RPO15分未満で、DRのために重要なバケットをクロスRegionレプリケーションします。
S3 Replication Time Control (RTC) を使用したS3 Cross-Region Replication (CRR) を使用します。99.99%のオブジェクトが15分以内にレプリケーションされます。
理由: 標準CRRはベストエフォート型です。RTCはSLAとCloudWatchでのレプリケーションメトリクスを追加します。
S3オブジェクトを誤削除やランサムウェアによる上書きから保護します。
重要なバケットでS3バージョン管理、MFA Delete、オブジェクトロック（ガバナンスまたはコンプライアンスモード）を有効にします。
理由: バージョン管理は上書き/削除を保持し、オブジェクトロックは保持期間前の削除をブロックし、MFA Deleteは永続的な削除のために第2要素を追加します。
グローバルアプリケーションで、2つのRegion間でRTOゼロのフェイルオーバーが必要です。
Region間でアクティブ-アクティブ構成にします。イングレはGlobal AcceleratorまたはRoute 53のレイテンシーベースルーティング、データはDynamoDB Global Tables / Aurora Global Database、オブジェクトストアはクロスRegionレプリケーションを使用します。
TCP/UDPトラフィックを、低ジッターで最も近い健全なRegionにルーティングし、静的なエニーキャストIPを使用します。
AWS Global Acceleratorを使用します。2つのエニーキャストIPを持ち、AWSバックボーンを介して最も近いエンドポイントにルーティングします。
理由: 非HTTPトラフィックの場合、Route 53のレイテンシーベースルーティングよりも優れています。フェイルオーバーが高速（エニーキャスト）で、静的IPアドレスによる許可リスト設定が可能です。
LambdaがSQSからの注文を処理します — メッセージが二重に配信される可能性があります。
べき等性を確保します。リクエストハッシュをTTL付きでDynamoDBに保存し、再試行ごとにPUT-IfNotExistsを使用します。または、重複排除付きのFIFOキューを使用します。
意図的なPodの退避（ノードドレイン、クラスターオートスケーラー）により、デプロイメントのすべてのレプリカが停止します。
`minAvailable`または`maxUnavailable`を指定するKubernetes PodDisruptionBudgetを使用します。クラスターは意図的な中断中にこれを尊重します。
S3ストレージクラスを選択します。
頻繁なアクセス → Standard。アクセスパターンが不明 → Intelligent-Tiering。30日以上アクセスが少ない → Standard-IA。単一AZ許容、アクセスが少ない → One Zone-IA。アーカイブ、ミリ秒単位の取得 → Glacier Instant。アーカイブ、数分で取得 → Glacier Flexible。アーカイブ、数時間で取得、最も安価 → Glacier Deep Archive。
アクセスパターンが予測不可能で、コストを自動最適化する混合アクセスバケット。
S3 Intelligent-Tieringを使用します。アクセスを監視し、オブジェクトをティア間（Frequent / Infrequent / Archive Instant / Archive / Deep Archive）で自動的に移動させます。取得料金はかかりません。
理由: オブジェクトごとのわずかな監視料金がかかりますが、間違った推測をするよりも安価です。不明なパターンにはデフォルトで推奨されます。
インターネット経由で大きなオブジェクト（100MB超）を信頼性高く高速にアップロードします。
S3 Multipart Upload（並列パーツ）とS3 Transfer Acceleration（CloudFrontエッジでの取り込み）を組み合わせます。
理由: 並列パーツは帯域幅を飽和させ、Transfer AccelerationはWANホップをAWSバックボーンにオフロードします。
EBSボリュームタイプを選択します。
汎用、デフォルト → gp3（3000ベースラインIOPS、125MB/秒、調整可能）。高IOPSデータベース → io2 Block Express。ビッグデータシーケンシャルスループット → st1。コールドアーカイブ → sc1。ブートボリューム → gp3。
理由: gp3はIOPS/スループットをサイズから分離し、同等性能のgp2より安価です。
複数のEC2インスタンスが同じブロックボリュームを読み書きする必要があります。
io2 / io1（Nitroインスタンスのみ）でEBS Multi-Attachを使用します。同じAZ内の最大16インスタンスに同時アタッチが可能です。
理由: アプリケーションは書き込みを調整する必要があります（クラスターファイルシステム）。共有ファイルアクセスにはEFSがデフォルトですが、Multi-Attachはブロックストレージを必要とするクラスターDB用です。
共有ファイルシステムを選択します。
POSIX準拠のLinux NFS、マルチAZ、自動スケーリング → EFS。Windows SMB / AD統合 → FSx for Windows。HPC、Lustre、S3リンク → FSx for Lustre。NetApp ONTAP機能（スナップショット、NetAppツール） → FSx for ONTAP。ZFS → FSx for OpenZFS。
EFS — スループットモードを選択します。
変動するワークロード、サイズに応じてスケーリング → バースティング。予測可能な高スループット → プロビジョンド。バーストに敏感だが弾力的な費用を望む → Elastic（新規ファイルシステムのデフォルト、自動的にスケーリング）。
S3 / Glacierと統合するオンプレミスのファイル/ブロック/テープバックアップ。
AWS Storage Gatewayを使用します: File Gateway (NFS/SMB → S3)、Volume Gateway (iSCSI → S3 + EBSスナップショット)、Tape Gateway (VTL → Glacier)。
静的アセットとAPIレスポンスをグローバルユーザーに提供し、オリジン負荷を軽減します。
適切なキャッシュポリシーを持つCloudFrontを使用します。静的コンテンツには長いTTLを設定し、キャッシュキーには必須ヘッダー/クエリ文字列のみを含めます。カーディナリティの高いオリジンにはOrigin Shieldを使用します。
理由: キャッシュヒット率がパフォーマンスとコストの両方を左右します。誤ったキャッシュキー（例: すべてのヘッダーを含める）はヒット率を著しく低下させます。
エッジでリクエスト/レスポンスを操作します。
軽量、ビューワーサイド、ミリ秒未満の処理（ヘッダー書き換え、リダイレクト、A/Bテスト）→ CloudFront Functions。より重い処理、Node.js / Python、長いコンピューティング時間、ネットワークアクセス → Lambda@Edge。
ElastiCache RedisとMemcachedのどちらを選択します。
レプリケーション、永続性、pub/sub、ソート済みセット、Multi-AZフェイルオーバー → Redis。マルチスレッド、シンプルなキー/値、水平シャーディングのみ → Memcached。
Redisセッションストアには、AZ間での自動フェイルオーバーを伴うHAが必要です。
Multi-AZと自動フェイルオーバーが有効なElastiCache for Redisレプリケーショングループを使用します。プライマリは1つのAZに、レプリカは他のAZに配置します。
アプリケーション変更なしでDynamoDBの読み取りレイテンシーをマイクロ秒単位にします。
DynamoDB Accelerator (DAX) を使用します。VPC内マネージドキャッシュで、同じDynamoDB SDKを使用し、透過的なリードスルーが可能です。
理由: ElastiCacheはアプリケーションレベルのキャッシュロジックが必要です。DAXはDynamoDBのドロップインソリューションです。
キャッシュ戦略を選択します。
レイジーローディング（キャッシュミス → フェッチ＋投入）：シンプルで、リクエストされたものだけをキャッシュします。ライトスルー（更新時にキャッシュ＋DBに書き込み）：キャッシュは常に最新ですが、追加の書き込みが発生します。TTL：どちらのパターンでも古さを制限します。
コンピューティングプラットフォームを選択します。
15分未満のイベント駆動型、1秒未満のスケール、インフラ管理不要 → Lambda。長時間稼働するコンテナ、ノード管理不要 → Fargate。カスタムカーネル、GPU、永続状態、最も安価な継続的利用 → EC2。
Lambda Javaのコールドスタートがp99レイテンシーを悪化させています。
Lambda SnapStart (Java, Python, .NET) を使用します。初期化されたランタイムのスナップショットが呼び出し時に復元され、コールドスタートが最大10倍高速になります。
予測可能なバースト負荷があり、コールドスタートは許容できません。
プロビジョニング済み同時実行を使用します。任意の処理能力で呼び出し準備ができた事前ウォームアップ環境です。Application Auto Scalingと組み合わせて、スケジュールされたスケールアップを行います。
理由: オンデマンドよりもコストはかかりますが、コールドスタートを排除します。プロビジョニング済み同時実行の利用率が自然に高く維持される定常的なトラフィックには必要ありません。
API Gatewayタイプを選択します。
フル機能セット（リクエスト検証、変換、APIキー、使用プラン）→ REST API。低コスト、低レイテンシー、JWT/OIDCネイティブ、よりシンプル → HTTP API。リアルタイム双方向 → WebSocket API。
モバイル/ウェブアプリケーションが、DynamoDB / Lambdaをバックエンドとするリアルタイムサブスクリプション付きのGraphQLを必要とします。
AWS AppSyncを使用します。マネージドGraphQL、WebSocketサブスクリプション、Cognito / IAM / Lambdaオーソライザーによるきめ細かい認証認可を提供します。
Kinesis Data Streams、Firehose、Managed Service for Apache Flink、MSKのどれを選択します。
カスタムコンシューマ、ミリ秒単位のレイテンシー、リプレイ、マルチコンシューマファンアウト → Data Streams。S3/Redshift/OpenSearchへのバッファリング付き配信のみ → Firehose。ストリーム処理（ウィンドウ、結合）→ Managed Service for Apache Flink。Kafka互換 → MSK。
Athenaクエリがテラバイト単位でスキャンし、コスト/時間が過剰です。
クエリ述語（日付、Region）でデータをパーティション分割します。Parquet/ORCカラム型フォーマットに変換します。カタログへのラウンドトリップを避けるためにパーティションプロジェクションを使用します。
理由: AthenaはスキャンされたTBごとに課金されます。カラム型＋パーティション分割により、コストが10〜100倍削減されることがよくあります。
データをロードせずに、S3に保存されているデータをRedshiftからクエリします。
Redshift Spectrumを使用します。Glue Data Catalog上の外部スキーマを使用し、SpectrumノードがS3をスキャンし、結果をクラスターにストリームします。
DynamoDBキャパシティモードを選択します。
予測不能/スパイク的/新規ワークロード → On-demand。安定、予測可能、ホット — そしてコスト重視 → オートスケーリング付きプロビジョンド。モード切り替えは24時間に1回まで。
パーティションキーではない属性でDynamoDBをクエリします。
異なるパーティションキーでのクエリにはGlobal Secondary Index (GSI) を使用します。同じパーティションキーの代替ソートキーにはLocal Secondary Index (LSI) を使用します（LSIはテーブル作成時に作成する必要があります）。
DynamoDBセッションテーブルが際限なく増大し、セッションが24時間後に期限切れになります。
数値エポック属性にDynamoDB TTLを使用します。DynamoDBは期限切れアイテムを非同期で削除し、書き込みキャパシティは課金されません。
HPCワークロードには可能な限り低いノード間レイテンシーが必要です。
クラスター配置グループを使用します。同じAZ内の同じ物理ラックにインスタンスを配置します。単一フローで最大10 Gbps。
理由: Spread配置 → 最大の分離（HA）。Partition配置 → ビッグデータ（Hadoop、Cassandra）。Cluster配置 → 最も低いレイテンシー。
24時間365日稼働するフリートのEC2購入オプションを選択します。
Compute Savings Plan（1年または3年）— 定価から66%割引、インスタンスファミリー、サイズ、OS、テナンシー、Regionをまたいで柔軟に利用できます。キャパシティ予約が必要な場合にのみRIsを使用します。
理由: ほとんどのコストのみのユースケースでは、Savings PlansがRIsを凌駕します（より柔軟で、同じ割引率）。
Compute Savings Plan、EC2 Instance Savings Plan、SageMaker Savings Planのどれを選択します。
Compute SP: 最大の柔軟性（EC2、Fargate、Lambdaをカバー）— 最適なデフォルト。EC2 Instance SP: ファミリーロック付きで、より深い割引。SageMaker SP: SageMaker専用。
中断許容ワークロードのコスト削減にSpotインスタンスを使用します。
ASG混合インスタンスポリシーとキャパシティ最適化割り当て戦略、複数のインスタンスタイプを組み合わせてSpotインスタンスを使用します。インスタンスメタデータ経由で2分間の割り込み通知を処理します。
理由: キャパシティ最適化は、再利用される可能性が最も低いプールを選択します。複数のタイプを使用することで、プールリスクが分散されます。
移行後に未使用のReserved Instancesが残りました。
Reserved Instance Marketplaceで販売します（標準RIsのみ）。または、Convertible RIsを使用して異なるファミリーに変換します。
理由: Convertible RIsは、スワップする権利と引き換えにわずかに割引率が低くなります。
アーキテクチャの書き換えなしでコンピューティングコストを削減します。
Graviton (ARM64) インスタンスに移行します。多くのワークロードで約20%安価、約40%優れた価格性能を実現します。マルチアーキテクチャコンテナイメージまたは再コンパイルされたバイナリが必要です。
ランタイムがARMをサポートするLambda関数。
アーキテクチャを`arm64` (Graviton) に設定します。x86よりも1msあたり20%安価で、しばしば高速です。アーキテクチャ互換のネイティブ依存関係が必要です。
Lambdaのコストが高すぎます。ランタイムがCPUバウンドです。
メモリを増やします（CPUとネットワークも比例してスケーリングされます）。Lambda Power Tuning（Step Functionsツール）を使用して最適なポイントを見つけます。多くの場合、メモリを増やすと高速になり、かつ安価になります。
ログや古いオブジェクトがS3 Standardに蓄積されています。
S3ライフサイクルルールを設定します: 30日後にIAに、90日後にGlacier Flexibleに、180日後にDeep Archiveに移行し、保持期間後に期限切れにします。不明なパターンにはIntelligent-Tieringと組み合わせます。
アカウント全体のS3利用状況を可視化し、最適化候補を見つけます。
S3 Storage Lensを使用します。利用状況、アクティビティ、コスト削減の推奨事項を提供する組織全体のダッシュボードです。プレフィックスレベルの内訳にはAdvancedメトリクスティアを使用します。
NAT Gatewayのデータ処理料金が請求の大部分を占めています。
AWSサービストラフィックをVPCエンドポイント（S3/DynamoDBにはゲートウェイ、その他すべてにはインターフェース）に置き換えます。インターネットエグレスが必要なワークロードは、必要な場合にのみパブリックサブネットに移動します。
理由: NAT Gatewayは、AWSサービストラフィックでも処理されたGBごとに課金されます。エンドポイントはそのパスを排除します。
データ転送コストを削減します。
同じAZ、同じVPC = 無料。クロスAZ = $0.01/GB（双方向）。クロスRegion = 高価。インターネットへのエグレス = 最も高価ですが、キャッシュ可能なコンテンツの場合はCloudFront経由で無料になります。可能な限り常にCloudFront経由でエグレスします。
CloudWatch Logsのコストが急増しています。
明示的な保持期間を設定します（デフォルトは「期限なし」）。古いログはS3 + Glacierにエクスポートします。Logs Insightsはウォームデータのみに使用します。エージェントでフィルタリングします（本番環境でデバッグログを送信しない）。
EC2、Auto Scalingグループ、EBS、Lambda全体で適切なサイジングの候補を見つけます。
AWS Compute Optimizerを使用します。CloudWatchメトリクスとMLを読み取り、スケールダウンやファミリー変更を推奨します。組織全体でのオプトインで無料です。
予期せぬ費用スパイクをプロアクティブに検出します。
AWS Cost Anomaly Detection（Cost Explorer内）を使用します。MLベースでサービスごと、リンクされたアカウントごと、コストカテゴリごとに監視します。SNS / メール経由でアラートを送信します。
サンドボックスアカウントでの費用暴走を停止します。
AWS Budgetsにアクションを設定します。80%しきい値でSNS通知を実行し、100%でBudgetsアクション経由で拒否SCP / IAMポリシーをアタッチします。
別のアカウントなしで、チームまたは製品ごとに費用をチャージバックします。
コスト配分タグを使用します。請求コンソールでユーザー定義タグを有効にし、Cost Explorer + CURで表示します。`aws:CreatedBy`と組み合わせてID属性を付与します。
開発/テストEC2インスタンスが24時間稼働していますが、実際には9時から17時までしか使用されていません。
AWS Instance Scheduler（CloudFormationデプロイされたLambda）を使用します。インスタンスにスケジュール名をタグ付けし、cronのような開始/停止を実行します。または、開発用ASGで`aws:autoscaling:scheduledActions`を使用します。
理由: オフピーク時間の停止により、開発コンピューティング費用を約70%削減できます。
開発用RDSインスタンスが夜間/週末にアイドル状態です。
RDSインスタンスを停止します（シングルAZ; 最長7日間、その後自動起動）。または、最小ACUが0.5のAurora Serverless v2を使用します（完全停止はしませんが、アイドル時のコストは最小限です）。
コンテナフリートのコスト最適化。
安定した高利用率 → ECS on EC2（Spot/Savings Plansと併用）— 最も安価。スパイク的/短命/ノード管理不要 → Fargate。Fargate Spotは、中断許容ワークロードの場合、Fargateより70%安価です。
S3 / EC2からインターネットへのエグレスを削減します。
CloudFrontを前面に配置します。オリジンからエッジへの転送は無料です。エッジからユーザーへの転送は、スケールではEC2/S3からの直接エグレスよりも安価です。圧縮と適切なTTLを有効にします。
オンプレミスNFSからS3に100TBを移行します。
オンプレミスにAWS DataSyncエージェントをデプロイし、S3へのスケジュール転送を行います。暗号化され、整合性チェックされ、レート制限されます。100TB以上または低帯域幅の場合はSnowball Edgeを使用します。
オンプレミスからAWSへ1PBを超えるデータを移動します。オンライン転送には帯域幅が遅すぎます。
AWS Snowファミリーを使用します。一般的な場合はSnowball Edge Storage Optimized (80 TB) を使用し、数百TBの場合は複数のデバイスを並行して使用します。Snowmobileは廃止されました — ペタバイト規模には複数のSnowballを使用します。
本番RDS / ElastiCache / OpenSearch / Redshiftが24時間365日稼働しています。
マネージドデータベースにはReserved Instancesを使用します（これらのサービスにはSavings Plan相当のものはありません）。1年または3年契約で、部分前払いが通常、最適な正味現在価値（NPV）を提供します。
アカウント全体で簡単かつ低労力でコストを削減できる項目を見つけます。
AWS Trusted Advisorのコストチェックを使用します: アイドル状態のロードバランサー、低利用率EC2、未アタッチEBS、利用不足RDS、アイドルRedshift。無料ティアでは制限がありますが、ビジネス/エンタープライズサポートで全機能を利用できます。
