AWS Certified Solutions Architect Professional
最終確認：2026年5月
SAP-C02 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
初日から一貫したガードレール、ログ記録、IDを備えた100以上のアカウントを持つAWS環境を構築する。
ランディングゾーンとしてAWS Control Towerを使用する。Account Factoryがアカウントをプロビジョニングし、必須および強く推奨されるガードレールがベースラインを適用する。集中型ログアーカイブと監査アカウントが自動的に作成される。
理由: Control Towerは、Well-Architectedなマルチアカウントパターンをコード化する。Organizationsのみでゼロから構築すると、同じ基盤を手動で再現することになる。
すべてのAWSアカウントでControl Towerのデフォルトを超えるカスタムガードレールとリソースを追加する必要がある。
Customizations for AWS Control Tower (CfCT) を使用する。CloudFormationテンプレートとSCPのパイプラインをStackSets経由でOUにデプロイする。
理由: CfCTはControl Towerのライフサイクルを壊すことなく拡張する。カスタムConfigルール、セキュリティベースライン、ネットワーキングなど、すべてがバージョン管理され、再実行可能である。
300のアカウント全体でS3 KMS暗号化を適用し、非準拠のバケットを15分未満で自動修復する。
委任管理者を通じてAWS Configの組織全体のコンフォーマンスパックを導入する。自動修復のためにConfigルールとSSM Automationドキュメントを使用する。
理由: コンフォーマンスパックは、1つのアカウントから組織全体にConfigルールと修復をデプロイする。アカウントごとのLambdaまたはSCPのみのアプローチでは、リアルタイム検出か修復のどちらかが欠落する。
すべてのAWSアカウントのCloudTrailログを7年間保持し、改ざん防止を保証する。セキュリティチームのみが読み取り可能とする。
専用のログ記録アカウントのS3バケットに配信される組織トレイルを使用する。7年間の保持期間を持つコンプライアンスモードのObject Lockを適用する。バケットアクセスをセキュリティIAMロールに制限するSCPを設定する。
理由: コンプライアンスモードのObject Lockは、rootユーザーによる削除もブロックする。組織トレイルはすべてのアカウントから自動的に収集する。専用のログ記録アカウントは、影響範囲を隔離する。
150のアカウントをSAML経由で企業ADにフェデレートし、ADグループごとにアクセス許可を割り当てる。
外部SAML 2.0 IdPを使用するIAM Identity Centerを設定する。SCIMプロビジョニングを通じて権限セットをADグループにマッピングする。グループ経由でアカウントを割り当てる。
理由: Identity Centerは、すべての組織アカウントにわたるフェデレーションを一元化する。権限セットはアカウント間で再利用可能であり、SCIMはユーザー/グループの状態を同期させる。
ユーザーのコストセンターでタグ付けされたリソースへのアクセスを許可し、数千人のユーザーに拡張する。
Identity Centerの属性ベースのアクセスコントロール (ABAC) を使用する。SAML経由でAD属性を渡し、権限セットで`aws:PrincipalTag/CostCenter`を`aws:ResourceTag/CostCenter`と照合する。
理由: ABACはユーザーごとのポリシー変更なしでスケーリングする。新しいコストセンターの追加は単なるタグであり、IAMの書き換えは不要である。
CI/CDアカウントが50のワークロードアカウントでデプロイロールを引き受け、CloudFormationを実行する。
各ワークロードアカウントにIAMロールを作成し、CI/CDアカウントプリンシパルを許可する信頼ポリシーを設定する。CI/CDはSTS AssumeRole経由でロールを引き受ける。サードパーティツールが開始する場合は外部IDを使用する。
理由: 外部IDはConfused Deputy問題を防止する。ロールチェーンは、ロールがより長い期間を許可しても、セッションを1時間に厳密に制限する。
中央ネットワークチームがVPCを所有し、30のスポークアカウントが共有サブネットにワークロードをデプロイする。
AWS RAMを使用してサブネットを参加者アカウントと共有する。参加者はVPCを所有することなくリソースを起動でき、中央チームはルートテーブルとNATの制御を維持する。
理由: 共有VPCは、アカウントごとのVPCの乱立とIPAMの重複を排除する。参加者はVPCを削除したりルーティングを変更したりできない。
5つのリージョンとオンプレミス間でVPCを接続し、決定論的ルーティングと中央検査を実現する。
各リージョンにTransit Gatewayをデプロイする。リージョン間はTGWピアリングを使用する。TGWルートテーブル経由で到達可能なアプライアンスを備えた検査VPCを構築する。
理由: TGWピアリングは、リージョン間VPN/ピアリングのフルメッシュを回避する。アタッチメントごとのルートテーブルにより、セキュリティは他のフローを中断することなく特定のフローを検査できる。
TGWピアリングを超えて、ポリシー駆動型ルーティングによりリージョンとブランチサイトを横断するグローバルプライベートネットワークを構築する。
AWS Cloud WANを使用する。JSON形式のコアネットワークポリシーで、セグメント、リージョン、アタッチメント、共有を宣言的に定義する。
理由: Cloud WANは、ハブ・アンド・スポークのTGW設計を単一のマネージドグローバルバックボーンに置き換える。セグメントはリージョン間で論理的な分離を提供する。
オンプレミスDCがAWSへの10 Gbpsリンクを必要とし、リンク障害に対する回復力があり、インターネットに公開されないようにする。
異なるDXロケーションに2つのDirect Connect接続を設置する。それぞれにDirect Connect Gateway → TGWに終端するプライベートVIFを設定する。BGPフェイルオーバーを接続間で設定する。
理由: 単一のDXは単一障害点となる。異なるDXロケーションはサイト全体の障害から保護する。DX Gatewayは、1つのVIFで複数のリージョン/VPCに到達できるようにする。
Direct Connectリンクをプライマリとし、自動VPNフェイルオーバーが必要。
DXゲートウェイと同じTGWにSite-to-Site VPNをアタッチする。AWSはDX BGPルートを優先し、DX BGPが撤回された場合にVPNが引き継ぐ。
理由: BGPルートの優先順位により、フェイルオーバーが自動的に行われる。事前にプロビジョニングされたVPNは、停止中のプロビジョニング遅延を回避する。
規制当局がオンプレミスとAWS間のDirect Connect経由でのレイヤー2暗号化を要求する。
専用の10 Gbpsまたは100 Gbps接続でMACsec付きDirect Connectを使用する。両端で事前共有キーを設定する。
理由: IPsecはレイヤー3で動作するが、MACsecはレイヤー2でラインレート暗号化を行い、物理リンク暗号化を義務付ける規制当局の要件を満たす。
VPC間のEast-westトラフィックはステートフルインスペクションを通過する必要がある。
AWS Network Firewallを備えた集中型検査VPCを構築する。TGWルートテーブルは、クロスVPCトラフィックが宛先に到達する前にファイアウォールVPCを通過するようにルーティングする。
理由: Network Firewallは、ステートフルインスペクションのためのマネージドSuricataルールエンジンである。集中化により、VPCごとのファイアウォールの乱立を回避する。
組織内のすべてのアカウントで、WAFとNetwork Firewallのベースライン設定を自動的に適用する。
委任管理者を持つAWS Firewall Managerを使用する。WAF、Shield Advanced、Network Firewall、セキュリティグループのポリシーを組織全体に適用する。
理由: Firewall Managerは、新しいリソースにポリシーを自動的にアタッチする。これがないと、アカウントが追加されるたびに各アカウントがベースラインから逸脱する。
100以上のアカウントからのSecurity Hubの検出結果を1つのペインで一元化する。
Security Hubの委任管理者を設定する。集約リージョンは、すべてのメンバーアカウントとすべての有効なリージョンからの検出結果を1つのコンソールに集約する。
理由: 集約がないと、検出結果はアカウント/リージョンごとに残る。委任管理者は、セキュリティ運用に管理アカウントを使用することを避ける。
組織全体でGuardDutyを有効にし、中央監視とアカウントごとの請求可視性を実現する。
委任管理者を持つGuardDutyを使用する。組織統合を通じて新規アカウントでの自動有効化を設定する。検出結果は管理者アカウントに集約される。
理由: 自動有効化により、新たに作成されたアカウントが監視されないというギャップを埋める。
200のアカウントのすべてのS3バケットでPIIの継続的な検出を行う。
委任管理者を持つMacieを使用する。組織全体で自動有効化を設定する。検出結果はSecurity Hubに流れ、一元的にレビューされる。
理由: Macieは明示的な設定なしではアカウント間で読み取ることができない。組織レベルの設定により、すべてのバケットが対象範囲に含まれることを保証する。
アカウント間のCloudTrailとVPC Flow Logsを関連付けることで、GuardDutyの検出結果を調査する。
専用のセキュリティアカウントにAmazon Detectiveの委任管理者を設定する。メンバーアカウントは行動グラフに貢献する。
理由: DetectiveはVPC Flow Logs、CloudTrail、GuardDutyから行動グラフを自動的に構築する。委任管理者（管理アカウントではない）はAWSのベストプラクティスに従う。
組織内のリソースが外部アカウントと共有されていることを検出する。
組織を信頼ゾーンとし、セキュリティアカウントに委任されたIAM Access Analyzerを使用する。S3、IAMロール、KMSキー、Lambda、SQS、Secretsにおけるクロスアカウントアクセスの検出結果を提供する。
理由: Access Analyzerはパターンマッチングではなく形式検証を使用する。組織レベルの信頼ゾーンは、兄弟アカウントを信頼済みとして扱う。
ワークロードパターンが一致しない50のアカウント全体で、Savings Planの利用率を最大化する。
Organizationsの統合請求で、Savings PlansとRIの共有を有効にする。支払人アカウントで購入されたプランは組織全体で共有される。
理由: 共有により、あるアカウントの未使用容量が別の需要を相殺するように使用量をプールする。コスト配分隔離の場合のみ共有を無効にする。
アプリケーションチームがIAM管理者権限なしで、承認されたインフラストラクチャ（VPC、RDS）をセルフサービスで利用できるようにする。
AWS Service Catalogのポートフォリオを使用する。制約付きの事前承認済みCloudFormation製品を作成する。Organizations経由でポートフォリオをアカウント間で共有する。
理由: ガードレール付きのセルフサービスを提供する。制約ポリシーは複雑さ（インスタンスタイプ、タグ）を隠し、製品は起動するIAMスコープを保持する。
組織全体で必須の`CostCenter`と`Environment`タグを一貫して適用する。
OUにアタッチされたOrganizationsのタグポリシーを使用する。許可された値と大文字/小文字の区別を定義する。`required-tags` Configルールと組み合わせて適用する。
理由: タグポリシーは検証を行い、Configルールは非準拠を検出する。SCPはタグが不足しているリソースの作成を拒否できる。
メンバーアカウントでのrootユーザーアクションを防止する（コンプライアンス要件）。
`aws:PrincipalArn`が`arn:aws:iam::*:root`に一致する場合、すべてのアクションを拒否するSCPを設定する。
理由: SCPはrootユーザーにも適用される。IAMはrootユーザーを拒否できない。アカウント回復以外でrootアクションが必要となることはないはずである。
一貫した保持期間を持つAWS Backupプランをすべてのアカウントで義務付ける。
OUにアタッチされたOrganizationsのバックアップポリシーを使用する。プランと選択基準を定義し、対象リソースに自動的に適用する。
理由: アカウントごとのBackupプランの重複は逸脱につながる。組織ポリシーは単一の真実の源を強制する。
100以上のVPCそれぞれにNAT Gatewayがあり、コストがかさんでいる。 egressポイントを一元化したい。
NAT Gatewayを持つ集中型Egress VPCを構築する。スポークVPCは0.0.0.0/0 → TGW → Egress VPC → NATというルーティングを行う。
理由: NATを1つにすることで、100個の場合と比較してコストを劇的に削減できる。TGWのリージョン間データ転送ルールが適用されるため、リージョン間トラフィックについては慎重に設計する必要がある。
VPC内のEC2がオンプレミスホスト名を解決する必要があり、オンプレミスはVPCのプライベートDNSを解決する必要がある。
Route 53 Resolverのインバウンドおよびアウトバウンドエンドポイントを使用する。`corp.local`クエリをオンプレミスに転送するフォワーディングルールを設定し、オンプレミスDNSは`*.compute.internal`をインバウンドエンドポイントに転送する。
理由: Resolverエンドポイントは2つのAZにあるHA ENIである。条件付き転送により、DNSをインターネットに公開することなく双方向の解決が可能になる。
内部サービスが複数のアカウントの複数のVPCからDNS解決可能である必要がある。
クロスアカウントVPC関連付けを介して、複数のアカウントのVPCに関連付けられたRoute 53プライベートホストゾーンを使用する。
理由: クロスアカウント関連付けを介して共有される単一のPHZは、乖離するVPCごとの重複よりも優れている。
Windowsワークロードがオンプレミスフォレストとの信頼関係を持つ完全なADを必要とする。
AWS Managed Microsoft ADを使用する。DX/VPN経由でオンプレミスADとの双方向フォレスト信頼関係を確立する。
理由: Managed ADは本物のMicrosoft ADである（2つのAZにDC、スキーマ拡張可能）。AD Connectorはプロキシするだけであり、Simple ADは信頼関係をサポートしない。
AWS内のアプリケーションが、IDをレプリケートすることなく既存のオンプレミスADに対して認証する必要がある。
AD Connectorを使用する。DX/VPN経由でVPCからオンプレミスADへのプロキシとして機能する。
理由: ディレクトリデータはオンプレミスから出ず、認証リクエストが通過する。レイテンシーはリンクに依存する。
低レイテンシーのワークロードが特定のデータセンターで実行される必要があり、AWS API経由で管理される。
AWS Outpostsラック/サーバーを使用する。同じAWS API（EC2、EBS、ECS、EKS、RDSの一部）がオンプレミスで実行される。親リージョンに接続される。
理由: オンプレミスシステムへのサブミリ秒のローカルレイテンシー、またはLocal Zonesがカバーしない地域でのデータレジデンシーが必要な場合に使用する。単一AZであるため、HAのために2つのOutpostsをペアにする。
親リージョンから遠い都市圏のエンドユーザーへのレイテンシーを削減する。
AWS Local Zonesを使用する。人口集中地の近くにコンピュート、ストレージをデプロイする。コントロールプレーンのためにデータプレーンは親リージョンにルーティングされる。
理由: Local Zonesは主要都市の近くにEC2/EBS/RDS/ELBをホストする。フルDC所有が不要な場合、Outpostsよりも安価である。
アプリケーションが5Gモバイルユーザーに対して1桁ミリ秒のレイテンシーを必要とする。
キャリア5Gネットワーク内のAWS Wavelength Zoneを使用する。キャリアエッジにEC2/EBSをデプロイし、トラフィックはモバイルプロバイダーのネットワーク上に留まる。
理由: AR/VR、リアルタイム推論、ゲームなどの5Gユースケースで、パブリックインターネットのホップを完全に排除する。
コンプライアンス監査人が組織全体のリソースの現在の設定を必要としている。
監査アカウントにAWS Configアグリゲーターを配置し、すべてのリージョンにわたる組織全体をスコープとする。
理由: Configアグリゲーターは、読み取り専用の組織全体のビューである。アグリゲーターはメンバーアカウントでConfigを有効にするものではなく、それは別途行う必要がある。
50のアカウントからのCloudWatch LogsをSIEM取り込みのために1つのS3アーカイブに保存する必要がある。
各アカウントのサブスクリプションフィルター → クロスアカウントKinesis Data Stream / Firehose → ログ記録アカウントのS3というフローにする。
理由: サブスクリプションフィルターにより、ロググループがリアルタイムでプッシュできるようになる。Firehoseはバッチ処理、圧縮、S3パーティショニングを処理する。
組織全体でSOC 2、PCI、HIPAAの証拠レポートを継続的に生成する。
AWS Audit Managerを使用する。事前に構築されたフレームワークがコントロールとAWS証拠（Config、CloudTrail、Security Hub）をマッピングする。セキュリティアカウントに委任管理者を配置する。
理由: Audit Managerはコントロールごとに証拠を自動的に収集する。これにより、監査サイクルごとに何百時間もの手動スクリーンショット収集作業を削減できる。
組織内の既存および将来のすべてのアカウントにベースラインIAMロールをデプロイする。
サービスマネージド権限と新規アカウントへの自動デプロイ機能を備えたCloudFormation StackSetsを使用する。組織全体または特定のOUをターゲットにする。
理由: セルフマネージドStackSetsは各アカウントにIAMを必要とする。サービスマネージドは組織の権限を活用し、Organizationsのデフォルトである。
数ヶ月間StackSetsを実行した後、手動変更がドリフトを引き起こしている疑いがある。
StackSetでドリフト検出を開始する。リソースを変更せずにスタックインスタンスごとの結果を確認する。
理由: ドリフト検出は、ライブのリソース設定とテンプレートを比較する。「修正」するためにStackSetsを再デプロイすると、意図しない変更が発生する可能性がある。
変動が激しくバースト性のあるデータベースワークロードで、容量が数分で10倍に変動する。
Aurora Serverless v2を使用する。最小/最大ACUを設定し、Auroraは接続を切断することなく数秒でスケーリングする。
理由: v2は既存のインスタンスに容量を追加することでスケーリングし、フェイルオーバーは発生しない。プロビジョニングされたAuroraはここまで高速なスケーリングはできず、Serverless v1はスケーリングが遅く、接続を一時停止する。
グローバルアプリケーションで、リージョン間DBフェイルオーバーに対して<1秒のRPOと<1分のRTOを必要とする。
Aurora Global Databaseを使用する。ストレージベースのレプリケーションで、一般的なレプリケーションラグは1秒未満である。数秒でセカンダリを昇格できる。
理由: Global DBはトランザクションではなくページを転送するため、リージョン間でサブ秒の速度を実現する。論理レプリケーションによるリージョン間リードレプリカはこれに匹敵しない。
フルコピーの費用をかけずに、テスト用に本番データベースを再現する。
Auroraクローニングを使用する。Copy-on-write方式で、最初のクローンは無料で、変更されたページのみが課金される。
理由: クローンはポイントインタイムで瞬時に隔離される。スナップショット+復元は数時間かかり、すぐに全ストレージの費用が発生する。
論理エラー（本番環境でのDROP TABLEなど）から数分で復旧し、数時間かけないようにする。
Aurora MySQL Backtrackを使用する。バックアップから復元することなく、クラスターをその場で以前の時点に巻き戻す。
理由: Backtrackはその場で高速に実行される。PITRによる復元は新しいクラスターを作成するため、より遅く、アプリケーションの切り替えが必要となる。
レポートクエリを、より大きなメモリを持つ特定のリーダーインスタンスにルーティングする。
Auroraカスタムエンドポイントを使用する。リーダーのサブセット（より大きなもの）を指すエンドポイントを定義する。
理由: デフォルトのリーダーエンドポイントはすべてのリーダーをラウンドロビンする。カスタムエンドポイントはワークロードタイプによってクラスターをパーティショニングする。
DynamoDBテーブルでホットパーティションのスパイクが発生し、一部の読み取り/書き込みがスロットリングされる。
Auto Scalingとアダプティブキャパシティ（自動）でプロビジョニングする。単一のキーがホットスポットである場合は、パーティションキーを再設計する。
理由: アダプティブキャパシティは、アクションなしでパーティション間でスループットを再割り当てする。しかし、単一のキーがホットな場合は、スキーマの再設計（複合キー、書き込みシャーディング）のみが役立つ。
すべてのDynamoDB書き込みでサイドエフェクトを発生させ、検索インデックス作成のためにOpenSearchにプッシュする。
DynamoDB StreamsとLambdaトリガーを使用する。Lambdaがストリームレコードをバッチ処理し、OpenSearchに書き込む。
理由: Streamsは項目レベルの変更を24時間キャプチャする。ネイティブトリガーモデルであり、より長い保持期間/分析のためにKinesis Data Streamsアダプターも存在する。
複数のDynamoDB項目にわたる2段階書き込みがアトミックである必要がある。
TransactWriteItems / TransactGetItemsを使用する。最大100項目にわたってACIDセマンティクスを提供する。
理由: ネイティブトランザクションは分散SAGAの複雑さを回避する。コストは項目あたり通常の容量の2倍であるため、アトミック性が必要な場合にのみ使用する。
自己ホスト型MongoDBクラスターをマネージドサービスに移行し、APIを維持する。
Amazon DocumentDBを使用する。MongoDB互換APIである。移行にはmongodump/mongorestoreまたはDMSを使用する。
理由: DocumentDBはMongoDB 4.0/5.0とAPI互換性がある（ほとんどの演算子に対応するが、すべてではない）。コミットする前にドライバー/機能の互換性を確認する。
レコメンデーションエンジンが1億ノードのソーシャルグラフを横断する必要がある。
Amazon Neptuneを使用する。プロパティグラフ（Gremlin）またはRDF（SPARQL）を使用する。
理由: 目的別に構築されたグラフDBである。DynamoDBやRDSで関係をモデル化することも可能だが、ホップの深さが増すにつれてクエリパフォーマンスが低下する。
IoTフリートが秒間1000万の時系列データポイントを混合頻度の保持期間で放出する。
Amazon Timestreamを使用する。メモリストア（最近のデータ）、マグネティックストア（履歴データ）という自動階層化を行う。
理由: 目的別に構築された時系列データベースであり、このレートでDynamoDB/RDSをスケーリングするとコストがかかりすぎる。組み込みの保持期間階層化によりストレージコストが削減される。
銀行の台帳で、すべてのレコード変更の暗号化による検証が必要。
Amazon QLDBを使用する。不変で暗号的に検証可能なジャーナルである。証明のためにSHA-256ダイジェストエクスポートを使用する。
理由: QLDBは目的別に構築された台帳である。DynamoDB Streamsは変更履歴を提供するが、組み込みの暗号化チェーンは提供しない。
予測不能なピークがあり、ハンズオフな運用が可能なログ分析ワークロード。
Amazon OpenSearch Serverlessを使用する。コンピューティングとストレージが分離されており、OCUが自動スケーリングする。
理由: クラスターのサイジングやシャード管理が不要。予測可能で継続的なワークロードの場合は、プロビジョニングされたドメインの方が安価である。
ペタバイト規模の分析で、弾力性のあるコンピューティングとチーム間でのデータ共有が必要。
マネージドストレージを備えたRedshift RA3ノードを使用する。クラスター間データ共有（コピーなし）を行う。
理由: RA3はコンピューティングとストレージを分離し、それぞれを独立してスケーリングできる。データ共有により、チームのクラスター間でのETLが不要になる。
既存のRedshiftクラスターとS3データレイクがある。RedshiftからS3をクエリするか、Athenaを使用するか？
クラスターテーブルとS3データの結合が必要な場合はRedshift Spectrumを使用する。S3のみで完全にサーバーレスなアドホッククエリが必要な場合はAthenaを使用する。
理由: SpectrumはRedshiftのコンピューティングを介してS3クエリを実行する。AthenaはスキャンされたTBごとに課金される。主要なデータが存在する場所に基づいて選択する。
異なるチームが同じGlue Catalogテーブルに対して異なる行/列の可視性を必要とする。
行レベル、列レベル、セルレベルのフィルターを備えたAWS Lake Formationを使用する。LFタグを通じてアクセス許可を付与する。
理由: IAM/S3ポリシーでは行レベルの制御はできない。Lake FormationはGlue CatalogメタデータとAthena/Redshift Spectrum/EMRコンシューマーを通じてきめ細かいアクセスを強制する。
Glueジョブが毎日増分データを処理し、昨日のファイルを再処理してはならない。
Glueジョブブックマークを使用する。処理済みのS3キー/DB行を追跡し、最後の成功したチェックポイントから再開する。
理由: ブックマークは手動での状態追跡なしで重複処理を回避する。完全に再処理する場合は無効にする。
イベントストリーミングのためにマネージドKafkaとKinesis Data Streamsのどちらを選択するか。
既存のKafkaクライアント/エコシステムがある場合はMSKを使用する。Lambdaトリガー、Firehose、KCLといった密接なAWS統合とサーバーレスオプションが必要な場合はKinesisを使用する。
理由: どちらも耐久性のあるストリームを提供し、リプレイが可能である。MSKはKafka APIとエコシステムを保持する。Kinesisは小規模なストリームでコストが低く、ネイティブに統合される。
可変的なKafkaスループットで、ハンズオフなクラスター管理が必要。
MSK Serverlessを使用する。パーティションとスループットを自動スケーリングし、パーティションとデータごとに課金される。
理由: ブローカーのサイジングが不要。継続的に高スループットを必要とする場合は、プロビジョニングされたMSKの方が安価である。
グルーLambdaを書かずにSQS → フィルター → Step Functionsを連携させる。
EventBridge Pipesを使用する。ソース → オプションのフィルター → オプションのエンリッチメント → ターゲットというフローである。
理由: 一般的なLambdaをグルーとして置き換える。コード、コスト、運用上の表面積を削減する。
ソースから再放出することなく、先週のイベントを新しいコンシューマーで再生する。
EventBridgeのアーカイブとリプレイを使用する。アーカイブは一致したイベントをキャプチャし、後でターゲットにリプレイする。
理由: 組み込みのリプレイ機能により、別のイベントストアが不要になる。インシデントからの復旧や新しいコンシューマーのオンボーディングに役立つ。
数百のプロデューサーがイベントを生成し、コンシューマーは型付きバインディングを必要とする。
自動検出機能を備えたEventBridge Schema Registryを使用する。強力な型付けのコードバインディング（Java、Python、TypeScript）を生成する。
理由: 検出機能は観測されたイベントからスキーマを学習する。バインディングはコンパイル時の安全性を提供する。
高ボリュームの短いワークフロー（秒間10万以上）をサブ秒課金でオーケストレーションする。
Step Functions Expressワークフローを使用する。実行ミリ秒ごとの課金で、最大5分間実行可能。
理由: 標準ワークフローは耐久性があり履歴が追跡され、状態遷移ごとに課金される。Expressは監査証跡と引き換えに、短命なフローのコストを削減する。
1000万個のS3オブジェクトをStep Functionを通じて並列処理する。
Distributed Map状態を使用する。最大10,000の並列子実行が可能で、S3から直接ソースを読み込む。
理由: Inline Mapは40並列に制限される。Distributed Mapはサービスクォータに達することなく、S3バケットサイズのジョブまでスケールする。
FIFOキューが秒間300メッセージを超えるスループットを必要とする。
高スループットモードが有効なSQS FIFOを使用する。リージョンあたりAPIごとに最大70,000メッセージ/秒に対応し、`MessageGroupId`でパーティショニングする。
理由: 標準FIFOはバッチ処理なしでは300メッセージ/秒に制限される。高スループットモードはグループIDで順序付けをパーティショニングする。
複数のコンシューマーがそれぞれ同じKinesisストリームでフル読み取りスループットを必要とする。
Enhanced Fan-Out (EFO) を使用する。各コンシューマーはHTTP/2プッシュを介して、専用の2 MB/秒/シャードパイプを受け取る。
理由: デフォルトのポーリングでは、2 MB/秒/シャードの制限がコンシューマー間で共有される。EFOは高コストと引き換えに競合を排除する。
FirehoseからS3へデータを転送する際、パーティショニングが取り込み時間でなくイベント時間で行われるため、データレイククエリのスキャンが多すぎる。
Firehoseの動的パーティショニングを使用する。JSONからイベント時間/テナントIDを抽出し、S3プレフィックス`year=YYYY/month=MM/tenant=X/`に書き込む。
理由: イベント時間に基づくAthena/Spectrumパーティションプルーニングは、スキャンコストとレイテンシーを大幅に削減する。
モバイル/ウェブクライアントがリアルタイム更新と選択的なフィールドフェッチを必要とする。
サブスクリプション付きのAWS AppSync（GraphQL）を使用する。WebSocketをバックエンドとする。
理由: GraphQLクライアントは要求されたフィールドのみをフェッチし、差分を購読する。REST/HTTP API Gatewayは過剰なフェッチとポーリングを強制する。
内部APIがパブリックインターネットからアクセスできないようにする必要がある。
インターフェースVPCエンドポイント経由でAPI Gatewayプライベートエンドポイントを使用する。リソースポリシーで特定のVPCに制限する。
理由: プライベートAPIはVPCおよび接続されたネットワークからのみ到達可能である。パブリックAPIは安全のためWAFと認証が必要となる。
S3オリジンをロックダウンし、CloudFrontのみが読み取れるようにする。
Origin Access Control (OAC) を使用する。従来のOAIに代わり、SSE-KMSとすべてのS3機能をサポートする。
理由: OAIはSSE-KMSオブジェクトをサポートしない。AWSはすべての新しいディストリビューションでOACを推奨している。
S3にある特定の有料ビデオへのアクセスを時間制限する。
CloudFront署名付きURL（URLごと）または署名付きCookie（複数のURL）を使用する。信頼されたキーグループがリクエストに署名する。
理由: S3の署名付きURLはCloudFrontのキャッシュをバイパスする。CloudFrontの署名付きURLはエッジでキャッシュし、かつアクセスを制限する。
軽量なビューワーリクエスト変換：ヘッダーの書き換え、リダイレクト、A/Bルーティング。
CloudFront Functionsを使用する。JSでサブミリ秒の実行が可能で、すべてのエッジPOPで利用できる。
理由: Lambda@Edgeはリージョンエッジで完全なNode/Pythonを実行するため、より重く高価である。Functionsはシンプルな操作で10倍安価である。
EKSで強力な分離を伴う信頼できないマルチテナントワークロードを実行する。
EKS Fargateのポッドごとの分離を使用する。各ポッドは専用のマイクロVMで実行される。
理由: マネージドノードグループはカーネルを共有するため、特権昇格がテナント間で発生する可能性がある。Fargateのカーネル分離はEKSで最も強力である。
EKSクラスターのオートスケーリングのレイテンシーが遅すぎる。ノードグループのインスタンスタイプが乱立している。
Karpenterを使用する。保留中のポッド要件に基づいて、インスタンスタイプをジャストインタイムでプロビジョニングする。
理由: Cluster Autoscalerは事前に定義されたASGをスケーリングするため、遅く、制限がある。Karpenterは任意のEC2を数秒で多様化してスケーリングする。
EKSポッドが最小権限IAMを必要とする（ノードインスタンスロールの共有を避ける）。
OIDCプロバイダー経由でIAM Roles for Service Accounts (IRSA) を使用する。ServiceAccountにロールARNをアノテーションする。
理由: EKS Pod Identityはより新しい代替手段であり、信頼モデルがよりシンプルである。IRSAは成熟しており、リージョン間で動作する。
ECS-on-EC2タスクの開始にスケールアウト時に5〜7分かかる。60秒未満で開始したい。
ECS Capacity Providerと、`CapacityProviderReservation`のターゲットを約80%とするマネージドスケーリングを使用する。アイドルバッファを維持する。
理由: 予約されたバッファにより、新しいタスクは既存の容量に即座に着陸し、ASGが代替インスタンスを起動する間もサービスが継続される。
LambdaがSQSによってトリガーされるが、メッセージの5%しか一致せず、無駄な呼び出しが発生している。
フィルター条件付きのイベントソースマッピングを使用する。Lambdaは一致するメッセージに対してのみ呼び出される。
理由: Lambda前のフィルターにより、無関係なメッセージに対する呼び出しごとのコストを回避できる。SQS、Kinesis、DynamoDB、MQ、Kafkaでフィルターがサポートされている。
本番アプリケーションが運用オーバーヘッドの低いLLMエンドポイントを必要とする。
マネージド基盤モデル（Claude、Llama、Titan）にはAmazon Bedrockを使用する。カスタムモデルや厳密にチューニングされたオープンウェイトモデルをホストする必要がある場合にのみSageMakerを使用する。
理由: BedrockはAPIのみでインフラ不要。SageMakerは完全なMLプラットフォームであり、トレーニング/ファインチューニングのライフサイクルを自分で管理する場合に選択する。
モデルをトレーニングすることなく、ビジョン/NLP向けのマネージドAIを選択する。
Rekognition（画像/動画のラベル、顔、コンテンツモデレーション）、Comprehend（感情、エンティティ、言語、PII検出）を使用する。Translate、Polly、Transcribeも選択肢。
理由: 事前トレーニング済みのAWS AIサービスは、一般的なタスクのMLライフサイクル全体をスキップできる。既成のものが合わない場合にのみSageMakerを使用する。
ウェブアプリがメール/パスワード、Google、Apple、SAMLエンタープライズSSOをサポートする。
ホストされたUIを持つCognitoユーザープールを使用する。OIDCおよびSAML IdPを設定する。アプリケーションはCognito JWTを受け取る。
理由: ユーザープールはIdPを1つのトークンに集約する。IDプールはAWS認証情報との間でトークンを交換するだけであり、認証ではなくAWS APIアクセス用である。
DynamoDB Global Tablesで、2つのリージョンで同じキーへの同時書き込みが発生する。
タイムスタンプによるLast-writer-wins方式を使用する。アプリケーションは冪等な書き込みを設計するか、書き込みをリージョンごとにパーティショニングする。
理由: GTレプリケーションは非同期のマルチマスターである。競合解決はタイムスタンプベースであり、アプリケーションは結果整合性を許容する必要がある。
組織全体でEC2フリートが過剰にプロビジョニングされている。自動化された適切なサイジングの推奨が必要。
組織レベルでAWS Compute Optimizerを有効にする。利用率ウィンドウに対して推奨事項をレビューし、追跡のためにS3にエクスポートする。
理由: Compute OptimizerはCloudWatchメトリクスでMLを使用する。手動での適切なサイジングでは、ワークロード形状のシグナルを見逃す。
予期せぬコストの急増を月末ではなく数時間以内に捕捉する。
AWS Cost Anomaly Detectionを使用する。MLがサービスごと/アカウントごとの支出を監視し、しきい値を超えた場合にSNS/メールでアラートを送信する。
理由: 予算は計画されたしきい値で発動する。異常検出は、予期せぬ事態（キーの侵害、暴走するトレーニングジョブ）を数日/数週間早く捕捉する。
アカウントが月次予算の100%に達した場合、不要なリソースを自動的に停止する。
AWS Budgetアクションを使用する。制限的なIAMポリシーを適用し、SNS経由でLambdaをトリガーして不要なEC2/RDSを停止させる。
理由: 予算アクションは「アラートのみ」から「強制」に移行する。Cost Anomaly Detectionと組み合わせて、予算外の支出を捕捉する。
組織全体のS3コスト最適化機会を可視化する。
高度なメトリクスと組織全体のスコープを持つS3 Storage Lensを使用する。コールドティア候補、ITティア機会、放棄されたマルチパートアップロードを表面化する。
理由: 無料ティアは基本的なメトリクスをカバーし、アドバンストティアはレプリケーション、アクティビティ、最適化の推奨事項を表示する。監査/セキュリティアカウントに一元化される。
削除操作にもかかわらずS3の請求額が増え続けている。
7日後に「未完了のマルチパートアップロード」を中止するライフサイクルルールを設定する。`s3api list-multipart-uploads`で検査する。
理由: 失敗したアップロードは、ストレージとして課金されるがコンソールリストには表示されない部分を残す。よくあるコストリークである。
ほとんどが四半期に一度しかアクセスされないコールドアーカイブデータ。
S3 Glacier Flexible Retrieval（1〜12時間で復元）を使用する。「まったくアクセスされない」場合はDeep Archive（12時間で復元、最低コスト）を使用する。
理由: Standard-IAはミリ秒単位のアクセスを維持するが、Glacierティアはアクセス時間と引き換えに約80〜95%のコスト削減を実現する。
S3とDynamoDBトラフィックのNAT Gatewayからのエグレスコストを削減する。
S3とDynamoDB用のGateway VPCエンドポイント（無料）を使用する。エンドポイント経由でトラフィックをルーティングし、NATをバイパスする。
理由: NATはGBごとに課金されるが、Gatewayエンドポイントは無料である。他のAWSサービスの場合、インターフェースエンドポイントはコストを削減するが、排除はしない。
AZ間でチャットが多いワークロードで、データ転送コストが請求の大部分を占めている。
可能であれば、マイクロサービスを同じAZに配置する。AZアフィニティルーティングを備えたVPC Latticeまたはサービスメッシュを使用する。
理由: AZ間の転送は双方向で$0.01/GBかかる。マイクロサービスのチャットが大規模になると積み重なる。99.95%で十分な場合は、コストのために一部のHAをトレードオフする。
インターネットへのエグレストラフィックが最大の単一費用項目である。
すべてをCloudFrontでフロントエンドにする。CloudFrontからインターネットへのエグレスは、直接EC2/ALBからのエグレスよりも安価である。
理由: CloudFrontのエグレス料金は階層化されており、リージョンのエグレスよりも大幅に安い。キャッシングによりオリジンのエグレスもさらに削減される。
Compute Savings Plan、EC2 Instance Savings Plan、Reserved Instancesのいずれかを選択する。
Compute SP: 最も柔軟（任意のリージョン、ファミリー、OS）だが割引率はわずかに低い。EC2 Instance SP: ファミリーがリージョンにロックされるが割引率は高い。RI: 容量予約が必要な稀なケース。
理由: Compute SPはLambda + Fargate + EC2をカバーする。RIは容量予約が重要な場合にのみSPに勝るが、ほとんどの場合SPが有利である。
ステートレスなバッチフリートがSpotで実行されているが、中断率が高すぎる。
多くのインスタンスタイプとAZにわたって容量最適化戦略を持つSpot Fleetを使用する。
理由: 最低価格戦略は単一のプールに集中するため中断率が高い。容量最適化は利用可能な容量が最も深いプールを選択する。
書き換えなしでステートレスなウェブ層のコンピューティングコストを約20%削減する。
Graviton（ARM）に移行する — `c7g`、`m7g`、Lambda ARM、Aurora Graviton。コンパイルされたバイナリの互換性テストを行う。
理由: Gravitonはほとんどのワークロードで約20%優れた価格性能を提供する。Java/Python/Nodeは「そのまま動作する」が、ネイティブコードは再コンパイルが必要な場合がある。
長期間実行されるが中断耐性のあるFargateサービスのコストを削減する。
容量プロバイダー戦略を介してFargate Spotを使用する。HAタスクのためにSpotとオンデマンドを混合する。
理由: Fargate Spotは70%程度安価である。タスクは終了前に2分間の警告を受けるため、優雅なドレインと組み合わせる。
CloudWatch Logsのストレージコストが月ごとに増加している。
ロググループごとに保持期間を設定する（デフォルトは無期限）。長期保存の場合はS3にエクスポートし、CWから削除する。Logs Infrequent Accessクラスを使用する。
理由: CW Logsは取り込みとストレージで$0.03/GBが永続的にかかる。S3 Standard-IAはアーカイブアクセスの場合$0.0125/GBでより安価である。
断片化したモニタリングを、サービス全体にわたる統合された可観測性に置き換える。
サービスマップにはCloudWatch ServiceLens、トレースにはX-Ray、アドホックにはCloudWatch Logs Insights、ECS/EKSにはContainer Insights、ブラウザにはRUM、カナリアにはSyntheticsを使用する。
理由: AWSネイティブスタックはホストごとのエージェントを不要にする。移植性のためにOpenTelemetry SDKと組み合わせる。
5つのアカウントにわたるサービス間のリクエストをトレースする。
X-Rayのクロスアカウント可観測性を使用する。ソースアカウントはOAMを通じて中央監視アカウントとトレースを共有する。
理由: OAMがないと、トレースはアカウントごとに断片化する。クロスアカウント集約は、リクエストパスのビューを一元化する。
複数のアカウントからのメトリクス、ログ、トレースを1つのCloudWatchコンソールで表示する。
CloudWatch Observability Access Manager (OAM) を使用する。ソースアカウントをシンクとリンクを介して監視アカウントにリンクする。
理由: OAMは、標準的なマルチアカウント可観測性ファブリックである。アカウントごとのコンソールホッピングを不要にする。
Auroraクラスターの遅延の原因を、待機イベントごとに上位SQLを特定して突き止める。
クラスターでPerformance Insightsを有効にする。クエリログをダンプすることなく、負荷と待機分析によって上位SQLを特定する。
理由: PIは低オーバーヘッドで待機イベントをサンプリングする。CloudWatchメトリクスは何か遅いことを伝えるが、PIは何が遅いかを伝える。
アラーム閾値を設定することなく、DynamoDB / RDS / Lambda / ECSの異常を自動検出する。
Amazon DevOps Guruを使用する。運用メトリクスと相関イベントに基づくMLベースの異常検出を行う。
理由: 静的な閾値では稀なモードを見逃す。DevOps Guruはベースラインを学習し、正常からの逸脱をアラートする。
インスタンスごとのスクリプトなしで、5,000台のEC2インスタンスをスケジュールに従ってパッチ適用する。
SSM Patch Managerをパッチベースラインとメンテナンスウィンドウと組み合わせて使用する。タグベースのターゲティングで、N日後にセキュリティパッチを自動承認する。
理由: Patch Managerはパッチライフサイクル全体を一元化する。手動で管理されたスクリプトはドリフトし、新しいインスタンスを見逃す。
Configルールの障害（例：開いているSG）を人間の承認なしで自動修復する。
Configの修復アクションでSSM Automationドキュメントを呼び出す。`AWS-DisablePublicAccessForSecurityGroup`などの既成のドキュメントを使用する。
理由: Configが検出し、SSM Automationが実行する。SNS → 人間 → チケットよりも密なループである。
AMI/コンテナイメージのゴールデンパイプラインを再現可能かつ常にパッチ適用済みにする必要がある。
EC2 Image Builderパイプラインを使用する。ソースAMI → レシピ（コンポーネント） → テスト → リージョン/アカウントへの配布というフロー。
理由: アドホックなPackerスクリプトをマネージドライフサイクルに置き換える。毎月のパッチ更新のために再構築をスケジュールする。
EC2、ECRイメージ、Lambdaにわたる継続的なCVEスキャン。
組織全体で有効化されたAmazon Inspector v2を使用する。検出結果はSecurity Hubに流れる。
理由: Inspector v2はEC2 + コンテナイメージ + Lambdaの依存関係を1つのサービスでカバーする。手動でのCVEマッチングは大規模では不可能である。
多層アプリケーションが1時間のRTOと15分のRPOを満たせることを検証する。
AWS Resilience Hubを使用する。ポリシーを定義 → アプリケーションを評価 → 推奨事項 + 自動化されたランブック。
理由: Resilience HubはRTO/RPOの主張を具体的なテストで形式化する。手動のDRランブックはドリフトする。
自動スケーリングとフェイルオーバーが想定される障害ではなく、実際の障害下で動作することをテストする。
AWS Fault Injection Service (FIS) を使用する。テンプレート化された実験 — インスタンスの停止、APIのスロットリング、レイテンシーの注入。ゲームデー中に実行する。
理由: サービスとしてのカオスエンジニアリングである。実際の障害は脆い仮定を露呈させ、ランブックを読むだけでは不十分である。
マルチリージョンフェイルオーバー — 自動化されたレディネスチェックとゾーン避難。
Route 53 Application Recovery Controllerを使用する。セルベースのフェイルオーバーのためのレディネスチェックとルーティングコントロール。
理由: 通常のRoute 53ヘルスチェックはエンドポイントを評価する。ARCは明示的で監査可能なフェイルオーバーのためにアクティブ/スタンバイコントロールプレーンを追加する。
ロールバック機能を備えたRDSメジャーバージョンアップグレードを行う。
RDS Blue/Green Deploymentsを使用する。新しいバージョンでグリーンクローンを立ち上げ、binlogをリプレイし、1分未満で切り替える。
理由: インプレースでのメジャーアップグレードは不可逆である。Blue/Greenは切り替えが成功するまで古いDBを稼働状態に保つ。
自動ロールバックにより、不良デプロイの影響範囲を削減する。
カナリア設定（例: `CodeDeployDefault.ECSCanary10Percent5Minutes`）のCodeDeployを使用する。CloudWatchアラームがロールバックをトリガーする。
理由: カナリアは10%のサービスを5分間のみ停止する。一斉デプロイは最大の影響範囲となり、ローリングデプロイは展開するがトラフィックベースのゲートはない。
Lambda関数がメモリ過剰にプロビジョニングされている。
Lambda用のCompute Optimizerを使用する。呼び出しプロファイルからメモリチューニングの推奨事項を取得する。
理由: AWS Lambda Power Tuningステートマシンは代替手段だが、Compute Optimizerはハンズオフである。
観測されたCloudTrailアクティビティから最小権限のIAMポリシーを生成する。
IAM Access Analyzerのポリシー生成機能を使用する。ロールのCloudTrailを分析し、使用されたアクションのみのポリシーを出力する。
理由: 手動で`iam:Get*`などを探すよりも優れている。生成されたポリシーを開始点として使用し、レビューを行う。
EC2からRDSへの接続が失敗している。パケットキャプチャなしで原因を特定する。
VPC Reachability Analyzerを使用する。ルートテーブル、SG、NACL、NAT、ピアリングの静的分析を行う。ブロックしている要素を返す。
理由: tcpdumpよりも高速である。特定の構成（どのSGルール、どのNACL拒否）を特定する。
インターネットから内部リソースに到達できるパスを監査する。
VPC Network Access Analyzerを使用する。禁止されたパス（例: インターネット → DB層）を記述するスコープ式を定義する。一致するパスを返す。
理由: Reachability Analyzerはポイントツーポイントだが、Network Access Analyzerはスコープ全体のコンプライアンスを対象とする。
組織全体のコストについて迅速な改善点を見つける。
Trusted Advisorのコスト最適化チェック（Business/Enterpriseサポートが必要）を使用する。アイドル状態のELB、低利用率のEC2、未使用のEIP、RI利用率など。
理由: TAの無料ティアは限定的であり、Business+で全てのチェックが利用可能になる。委任管理者を持つ組織ビューでは集約された検出結果が表示される。
LambdaからRDSへの接続ストームがDB接続を使い果たしている。
RDS Proxyを使用する。LambdaとRDS/Aurora間の接続プールを行う。フェイルオーバーが高速化される（約66%削減）。
理由: Lambdaの同時実行数により、最悪の場合、呼び出しごとに1つの接続が作成される。Proxyは小さなプールに多重化する。
ロングテールコンテンツのオリジンでのキャッシュミス率が高く、オリジンに負荷がかかっている。
オリジンに近いリージョンにCloudFront Origin Shieldを使用する。オリジンに到達する前に、エッジ間でリクエストを重複排除する。
理由: Origin Shieldがないと、各POPが個別にオリジンにミスする。Shieldはオリジンへのヒット率を約70%削減する。
200台のオンプレミスサーバーを最小限のダウンタイムでEC2にリフト＆シフトする。
AWS Application Migration Service (MGN) を使用する。継続的なブロックレベルレプリケーションにより、サーバーごとの切り替えを数分で完了する。
理由: MGNはAWSが推奨するリホストツールである（SMS + CloudEndureを置き換えた）。サーバーごとの切り替えにより、ウェーブベースの移行が可能になる。
オンプレミスのOracleをAurora PostgreSQLに最小限のダウンタイムで移行する。
スキーマ変換ツール（SCT）を使用してスキーマとプロシージャを書き換え、AWS DMSを使用してフルロードとCDCを実行する。
理由: SCTはコードの問題に対処し、DMSはデータの問題に対処する。CDCは切り替えまでソースを同期状態に保つ。
すべてのオンプレミスデータベースを検出し、移行の複雑さを評価する。
AWS DMS Fleet Advisorを使用する。大規模な異種フリートのインベントリと評価を行う。
理由: Fleet Advisorは、DMSジョブを起動する前に、検出とサイジングを1つのワークフローに統合する。
500個のアプリケーションを移行戦略のために分類する。
7つのRフレームワークを使用する：Retire（廃止）、Retain（オンプレミスに保持）、Relocate（VMware Cloudにリフト）、Rehost（MGN）、Replatform（自己管理DBの代わりにRDS）、Repurchase（ドロップ＆SaaS）、Refactor（マイクロサービス）。
理由: 大規模なポートフォリオではこれら7つすべてが混在する。早期にアプリケーションごとにマッピングすることで、画一的な移行の負債を回避できる。
ウェーブを開始する前に、依存関係を含む移行インベントリを構築する。
AWS Application Discovery Serviceを使用する。エージェントレス（vCenterスキャン）またはエージェントベース（サーバーごと）で実行する。依存関係マップを出力する。
理由: 依存関係マッピングがないと、ウェーブ計画で密接な結合を見落とす。Discoveryはそれらを自動的に表面化する。
MGN、DMS、手動にわたる数百の進行中のサーバー+DB移行を追跡する。
AWS Migration Hubを単一のペインとして使用する。MGN、DMS、Refactor Spacesからのステータスを集約する。
理由: ツールごとのコンソールではステータスが断片化する。Migration Hubは統合し、ポートフォリオレポートをサポートする。
使用可能なWAN帯域幅がないリモートサイトから100 TBを移動する。
AWS Snowball Edge Storage Optimizedを使用する。デバイスを発送し、ローカルでコピーし、AWSに返送する。80 TBを超える場合は複数のデバイスを並行して使用する。
理由: Snowmobile (45 PB) はエクサバイト規模向け、Snowcone (8 TB) は小規模向けである。Edgeはペタバイト規模の主力製品である。
オンプレミスのNFSからS3への継続的なデータレプリケーションを帯域幅キャップ付きで行う。
AWS DataSyncエージェントを使用する。スケジュールされたタスク、タスクごとの帯域幅スロットル、整合性確認のための検証モード。
理由: DataSyncは目的別に構築されており、WAN経由の自己管理rsyncよりも10倍高速である。Snowballはオフラインだが、DataSyncはオンラインである。
オンプレミスアプリがNFS/SMBを期待しているが、データはS3に保存される必要がある。
Storage GatewayのFile Gatewayを使用する。ローカルキャッシュとS3バックエンドを持ち、S3 APIからもオブジェクトにアクセスできる。
理由: Volume GatewayはiSCSIを公開し、Tape GatewayはVTLをエミュレートする。File GatewayはNASとS3間のブリッジである。
VMwareを多用する企業が、vSphere/NSXのツール変更なしでAWS側の容量を求める。
AWS上のVMware Cloudを使用する。ベアメタルAWSホスト上で同じvSphereスタックを実行する。ライブマイグレーションにはHCXを使用する。
理由: 運用ツールを維持できる。リファクタリング前の橋渡しとなる。その後、徐々にネイティブAWSサービスにリプラットフォームする。
既存のJava/.NETモノリスを書き換えなしでコンテナ化する。
AWS App2Container CLIを使用する。実行中のアプリケーションを検査し、コンテナアーティファクトとECS/EKSマニフェストを生成する。
理由: A2Cは実行時設定（環境変数、ポート、依存関係）を動作するイメージにキャプチャする。手動でのコンテナ化では、自明でない依存関係を見落とす。
COBOLメインフレームのモダナイゼーション — Javaマイクロサービスに変換する。
AWS Mainframe ModernizationサービスをBlu Age（リファクタリング）またはMicro Focus（リプラットフォーム）と組み合わせて使用する。ランタイムエミュレーションへの許容度に基づいて選択する。
理由: リファクタリングはクラウドネイティブパターンを可能にする。リプラットフォームは高速だがメインフレームをエミュレートする。どちらもメインフレームのライセンスコストを削減する。
開発を凍結せずに18ヶ月かけてモノリスを分解する。
Strangler Figパターンを使用する。API Gateway/ALBでモノリスをフロントエンドにし、切り出された特定のエンドポイントを新しいマイクロサービスにルーティングする。
理由: ビッグバンリライトは通常失敗する。Stranglerパターンはルートごとに切り替えを分離し、移行中もモノリスを機能させ続ける。
ルーティングプレーンを自分で管理することなく、マイクロサービスを段階的に抽出したい。
AWS Migration Hub Refactor Spacesを使用する。API GatewayとVPC上に構築された、マネージドされたアプリケーション/ルート/サービス抽象化である。
理由: Strangler Figの配管を自分で記述する手間を省く。段階的な抽出のために、事前に構築されたルーティングとVPC接続を提供する。
EC2上の自己管理PostgreSQLをマネージド運用のためRDSに移行する。
CDCによるDMSを使用して切り替えを行う。OSアクセスやベンダー固有の拡張機能が必要な場合にのみRDS Customを使用する。
理由: RDSはバックアップ/パッチ/HAを処理する。RDS Customはレガシーなニーズに対応するためのエスケープハッチだが、運用負担を再導入する。
パフォーマンスとコストのためにRDS MySQLからAurora MySQLに移行する。
RDSからAuroraリードレプリカを作成し、その後昇格させる。バージョンずれが問題となる場合は、ゼロダウンタイムでDMSを使用する。
理由: リードレプリカパスはエンジン内で最もシンプルである。DMSはバージョン間の違いや異種間の移行を処理する。
企業がAWS移行の資金とベストプラクティスフレームワークを求めている。
AWS Migration Acceleration Program (MAP) を使用する。フェーズ：評価（MRA）、動員（MAPパートナー＋ツール）、移行＆モダナイゼーション。
理由: MAPは資金と構造化された方法論を提供する。MAPをスキップすると両方を逃すことになる。
エグゼクティブスポンサー向けに、移行前のコスト見積もりを作成する。
AWS料金計算ツール（設計された設定）とMigration Evaluator（オンプレミスインベントリに基づくデータ駆動型）を使用する。
理由: 料金計算ツールは「もしも」の料金を提供する。Migration EvaluatorはvSphere/Hyper-Vデータを取り込み、実際の節約を予測する。
自己ホスト型SFTPサーバーを廃止し、ベンダーパートナーはSFTPを使い続ける必要がある。
S3またはEFSをバックエンドとするAWS Transfer Family（SFTP/FTPS/FTP）を使用する。
理由: マネージドプロトコルサービスである。IAMマップされたユーザー、VPC専用エンドポイント。EC2でSSHデーモンを運用する手間を省く。
AD統合を伴うWindowsファイル共有をリフト＆シフトする。
Amazon FSx for Windows File Serverを使用する。ADに参加させ、SMBを使用し、オンプレミスからのオンライン同期にはDataSync、大量データにはSnowballを使用する。
理由: FSx for WindowsはADネイティブなランディングゾーンである。EFSはLinux専用であり、S3にはSMBセマンティクスがない。
NetApp ONTAPのすべての機能（スナップショット、FlexClone）を維持したまま、NetApp ONTAPワークロードを移行する。
Amazon FSx for NetApp ONTAPを使用する。ネイティブONTAP API、マルチプロトコルNFS+SMB、オンプレミスからのSnapMirrorレプリケーションをサポートする。
理由: 他のFSxフレーバーはONTAP固有の機能を公開しない。バックアップ/レプリケーションを再設計することなくNetAppをリフト＆シフトする。
DNSベースの切り替えは、DNSキャッシュの残留リスクがある。
CloudFront / ALB / Global Acceleratorの背後で切り替えを行う。パブリックDNSを変更せずにバックエンドを切り替える。
理由: キャッシュはTTLを尊重するが、クライアント/ファイアウォールは積極的にキャッシュする。安定したパブリックアドレスはDNSの残留から隔離する。
リスク管理のために、オンプレミスからAWSへのトラフィックを段階的に移行する。
Route 53の重み付けルーティングを使用する。1%からAWSにトラフィックを流し始め、徐々に増やしていく。自動フェイルバックのためにヘルスチェックを設定する。
理由: 重み付けルーティングはDNS層でのカナリアスタイルの移行を可能にする。ARCはより重要度の高い切り替えのために明示的なゲートを追加する。
移行されたワークロード全体でWindows / Oracle / SQL ServerのBYOLライセンスを追跡する。
AWS License Managerを使用する。ルールを定義し、起動時に強制し、RAM経由で組織全体で共有する。
理由: BYOLの非準拠は高価である。License Managerは偶発的な過剰デプロイメントを防止する。
移行後、開発/テスト用のRDSインスタンスが夜間に過剰にプロビジョニングされている。
開発/テスト環境を、低い最小ACUを持つAurora Serverless v2に移行する。アイドル時に自動でスケールダウンする。
理由: インスタンススケジューラの複雑さなしに、夜間のアイドルコストを節約できる。
移行中にEKSと同じツールでオンプレミスKubernetesを実行する。
オンプレミスハードウェア上のEKS Anywhereを使用する。同じKubernetesバージョン、ECR、AWS Outposts統合を利用する。
理由: 一貫したコントロールプレーンはオペレーターのスキルドリフトを減らす。EKSへの移行はワークロードの移動であり、ツールの書き換えではない。
