以下は、問題1の整理・解説です。
■ 問題文
ある企業には、データ層が単一の AWS リージョンにデプロイされている重要なアプリケーションがあります。データ層は Amazon DynamoDB のテーブルと Amazon Aurora MySQL DB クラスターを使用しています。現在の Aurora MySQL エンジンのバージョンは、グローバルデータベースをサポートしています。アプリケーション層はすでに 2 つのリージョンにデプロイされています。
同社のポリシーでは、重要なアプリケーションにはアプリケーション層コンポーネントとデータ層コンポーネントを 2 つのリージョンにまたがってデプロイする必要があります。RTO と RPO はそれぞれ数分以内である必要があります。ソリューションアーキテクトは、データ層を会社のポリシーに準拠させるためのソリューションを推奨する必要があります。
これらの要件を満たす手順の組み合わせを選択してください。(2 つ選択)
■ 選択肢
- A. Aurora MySQL DB クラスターに別のリージョンを追加します。
- B. Aurora MySQL DB クラスターの各テーブルに別のリージョンを追加します。
- C. DynamoDB テーブルと Aurora MySQL DB クラスターのスケジュールされたクロスリージョンバックアップを設定します。
- D. 別のリージョンを構成に追加して、既存の DynamoDB テーブルをグローバルテーブルに変換します。
- E. Amazon Route 53 Application Recovery Controller を使用して、セカンダリリージョンへのデータベースのバックアップとリカバリを自動化します。
■ 問題文の要件の概要
- 単一リージョンにある Aurora MySQL と DynamoDB を、マルチリージョン化する必要あり
- RTO（復旧時間）と RPO（目標復旧時点）ともに数分以内
- データ層をもう一つのリージョンに拡張して可用性を確保する
✅ 正解の選択肢と解説
- 正解：A と D
A. Aurora MySQL DB クラスターに別のリージョンを追加
- Aurora Global Database により、Aurora MySQL クラスターをマルチリージョン構成にできる。
- 非同期レプリケーションによって、1 秒未満のレイテンシで別リージョンへ複製。
- フェイルオーバーを手動で数分以内に実施可能 → RTO・RPO を満たす。
D. DynamoDB をグローバルテーブルに変換
- DynamoDB Global Tables により、各リージョンに自動で非同期複製される。
- 各リージョンがローカル書き込み可能 → 低レイテンシで継続運用可。
- リージョン障害時もすぐに別リージョンへ切り替え可能。
❌ 不正解の選択肢の理由
B. Aurora DB のテーブル単位でリージョン追加
- Aurora Global Database はクラスター単位で構成される。テーブル単位のリージョン追加はできない。
- Aurora のスコープを誤解している。
C. スケジュールされたクロスリージョンバックアップ
- バックアップは手動リストアが必要で、復旧に数分以上かかる → RTO・RPO 要件を満たせない。
- バックアップは耐障害性にはなるが「即時切り替え」はできない。
E. Route 53 Application Recovery Controller の使用
- ARC はトラフィックのルーティング制御のみを行う。
- データベースのレプリケーションやバックアップは提供しない → 単独では不十分。
🎯 SAP試験で押さえておくべきポイント
| 要件 | 対応サービス | 備考 |
|---|---|---|
| マルチリージョン Aurora 構成 | Aurora Global Database | Aurora MySQL / PostgreSQL で使用可 |
| マルチリージョン DynamoDB | DynamoDB Global Tables | 自動非同期複製、各リージョン書き込み可能 |
| バックアップ復元型 DR | AWS Backup | RTO・RPO が緩い場合に有効 |
| ルーティング制御 | Route 53 ARC | トラフィックの切替、フェイルオーバー制御 |
| テーブル単位構成 | ❌ 不可 | Aurora はクラスター単位で管理される |
✅ まとめ
数分以内の RTO/RPO 要件を満たすには、「リアルタイムなマルチリージョンレプリケーション」を活用する必要がある。
Aurora Global Database と DynamoDB Global Tables の組み合わせは SAP 試験でも頻出のパターンです。高可用性・耐障害性設計では、どのサービスがネイティブにマルチリージョン対応しているかを常に意識しましょう。
次の問題があれば、また貼り付けてください！
以下に、問題2の内容を指定のフォーマットで整理しました。
■ 問題文
ある企業は、AWS Step Functions を使用して、機械学習モデルの夜間の再トレーニングを自動化しました。ワークフローは、AWS Lambda を使用する複数のステップで構成されています。各ステップはさまざまな理由で失敗する可能性があり、失敗するとワークフロー全体の失敗を引き起こします。
調査の結果、同社が失敗に気付かずに、再トレーニングが毎晩連続で失敗していたことが判明しました。ソリューションアーキテクトは、再トレーニングプロセスのあらゆる種類の失敗に対して通知が送信されるようにワークフローを改善する必要があります。
これらの要件を満たす最適な手順の組み合わせを選択してください。(3 つ選択)
■ 選択肢
- A. Amazon Simple Notification Service (Amazon SNS) トピックを作成し、チームのメーリングリストをターゲットとする 「Email」 タイプのサブスクリプションを設定します。
- B. 入力引数を SNS トピックに転送する「Email」という名前のタスクを作成します。
- C. “ErrorEquals”: [“States.ALL”] および “Next”: “Email” のステートメントを持つすべての Task、Map、および Parallel 状態に Catch フィールドを追加します。
- D. Amazon Simple Email Service (Amazon SES) に新しいメールアドレスを追加します。メールアドレスを確認します。
- E. 入力引数を SES メールアドレスに転送する「Email」という名前のタスクを作成します。
- F. “ErrorEquals”: [“States.Runtime”] および “Next”: “Email” のステートメントを持つすべての Task、Map、および Parallel 状態に Catch フィールドを追加します。
■ 問題文の要件の概要
- 目的: 毎晩自動実行されるML再トレーニング処理において、あらゆる失敗に対して通知を送る必要がある。
- 背景: 失敗が検知されず連続して発生していた。
- 制約: 通知漏れがなく、エラーを確実に検知・通知できること。
✅ 正解の選択肢と解説
- 正解：A, B, C
A. SNSトピックを作成し、メールサブスクリプションを設定
- 通知処理を行うには Amazon SNS が最も適しており、メールグループへの通知に使える。
- 運用負荷が少なく、失敗時に即時配信できる。
B. 「Email」タスクでSNSにメッセージ送信
- ワークフロー内に SNS 通知処理を統合するためのタスク設計。
- エラーキャッチ後にこのタスクに遷移させることで、動的な通知内容送信が可能。
C. "ErrorEquals": ["States.ALL"] によるCatchハンドリング追加
- 全種類のエラーを確実に捕捉するには
"States.ALL"を使用する必要がある。 "Next": "Email"によって通知タスクへ確実に遷移させる。
❌ 不正解の選択肢の理由
D. Amazon SES にメールアドレスを追加
- SES は通知用途に不向き。マーケティングや大量送信向け。
- メールアドレスの検証など手間が多く、即時通知や簡易運用には不適。
E. SES に転送するタスクを作成
- Step Functions から直接 SES を呼び出す統合は存在しない。
- Lambda 経由でのAPI呼び出しが必要となり、構成が複雑・冗長になる。
F. "States.Runtime" に限定したCatchを使う
- Runtime エラーのみに限定されるため、全ての障害（タイムアウト、アクセス権限ミスなど）をカバーできない。
"States.ALL"が推奨。
🎯 SAP試験で押さえておくべきポイント
- Step Functions のエラーハンドリング:
"Catch"フィールドで"States.ALL"を指定することで、包括的に全エラーを検知可能。"States.Runtime"は限定的な用途（実行時のみ）なので通知目的には不十分。
- 通知には SNS を使用:
- メール通知は Amazon SNS + Email サブスクリプションが基本。
- SES はマーケティング/大量送信向けであり通知には非推奨。
- 通知タスクの設計:
- 通知タスク（例:
Email）を作成してワークフロー内に組み込む。 - Catch から Next で通知タスクへ遷移させる構成は非常に重要。
- 通知タスク（例:
必要であれば図解やJSONのテンプレートも提供できます。次の問題も準備ができたらお送りください。
以下は、提供された問題文と選択肢に基づいて整理した出力です。
■ 問題文（編集せずに出力）
ある企業は AWS Organizations を使用して 1,000 を超える AWS アカウントを管理しています。同社は新しい開発者組織を作成しました。新しい開発者組織に移行する必要がある開発者メンバーアカウントは 540 件あります。すべてのアカウントは、各アカウントがスタンドアロンアカウントとして運用できるように、すべての必要な情報が設定されています。
すべての開発者アカウントを新しい開発者組織に移行する最適な手順の組み合わせを選択してください。(3 つ選択)
■ 選択肢（編集せずに出力）
- A. 古い組織の管理アカウントから Organizations API の MoveAccount オペレーションを呼び出して、開発者アカウントを新しい開発者組織に移行します。
- B. 管理アカウントから、Organizations API の RemoveAccountFromOrganization オペレーションを使用して、古い組織から各開発者アカウントを削除します。
- C. 各開発者アカウントから、Organizations API の RemoveAccountFromOrganization オペレーションを使用して、古い組織からアカウントを削除します。
- D. 新しい開発者組織の管理アカウントにサインインし、開発者アカウントの移行のターゲットとして機能するプレースホルダーメンバーアカウントを作成します。
- E. 新しい開発者組織の管理アカウントから Organizations API の InviteAccountToOrganization オペレーションを呼び出して、開発者アカウントに招待状を送信します。
- F. 各開発者に自分のアカウントにサインインして、新しい開発者組織への参加を確認してもらいます。
■ 問題文の要件の概要
- 既存の AWS Organizations 管理下にある540の開発者アカウントを別の新しい開発者用組織に移行したい
- 各アカウントはすでにスタンドアロン運用可能
- **最適な移行フロー（3手順）**を選択
✅ 正解の選択肢と解説
- B. 管理アカウントから RemoveAccountFromOrganization を使う
- 組織からアカウントを外すには、古い組織の管理アカウントが API を実行する必要がある
- 各アカウントが事前に支払い・連絡先設定済みであることが前提条件
- E. 新しい組織から InviteAccountToOrganization を送信
- 新組織の管理アカウントが招待の送信者となる
- 招待は Organizations 間の標準的な移行プロセス
- F. 開発者自身が新しい組織への招待を承諾
- 各アカウントのオーナーがログインして招待を承諾しなければ、参加が完了しない
❌ 不正解の選択肢の理由
- A. MoveAccount API を使う
MoveAccountは同じ組織内のOU間移動にしか使えず、組織間では使用不可
- C. メンバーアカウントから RemoveAccountFromOrganization を呼び出す
- このAPIは管理アカウントのみが使用可能。メンバーアカウントに権限はない
- D. プレースホルダーアカウントを作成する
- 移行先の受け皿として既存アカウントの代用は不可能
- 招待による移行プロセスにプレースホルダーは無意味
■ SAP試験で押さえておくべきポイント
- Organizations 間のアカウント移行は以下の3ステップ
- RemoveAccountFromOrganization（管理アカウントが実行）
- InviteAccountToOrganization（新組織の管理アカウントが実行）
- 招待を受けたアカウントが自分で承諾
MoveAccountは同一組織内の構造変更にのみ使用できる（OU間移動）- API権限の実行主体（管理アカウントのみ可能／不可）をしっかり区別する
- プレースホルダーアカウントの作成は既存アカウントの移行には不要
次の問題があれば、引き続き同様の形式で対応いたします。
以下は、問題4に関する情報を指定のフォーマットで整理した内容です。
■ 問題文（編集せずに出力）
ある企業が AWS Organizations の構造を設計しています。同社は、組織全体にタグを適用するプロセスを標準化したいと考えています。同社は、ユーザーが新しいリソースを作成するときに、特定の値を持つタグを必要とします。同社の各 OU は、固有のタグ値を持ちます。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. SCP を使用して、必要なタグを持たないリソースの作成を拒否します。会社が各 OU に割り当てたタグ値を含むタグポリシーを作成します。タグポリシーを OU にアタッチします。
- B. SCP を使用して、必要なタグを持たないリソースの作成を拒否します。会社が各 OU に割り当てたタグ値を含むタグポリシーを作成します。タグポリシーを組織の管理アカウントにアタッチします。
- C. SCP を使用して、リソースに必要なタグがある場合にのみ、リソースの作成を許可します。会社が各 OU に割り当てたタグ値を含むタグポリシーを作成します。タグポリシーを OU にアタッチします。
- D. SCP を使用して、必要なタグを持たないリソースの作成を拒否します。タグのリストを定義します。SCP を OU にアタッチします。
■ 問題文の要件の概要
- 組織全体でタグ付けの標準化が必要
- OU（組織単位）ごとに異なるタグ値を強制
- タグがないリソース作成をブロックする仕組み
- タグキーだけでなく、タグ値のバリデーションも必要
✅ 正解の選択肢と解説
- 正解：A
A. SCP とタグポリシーを OU 単位で適用
- SCP（サービスコントロールポリシー）で「タグが無いリソースの作成」を明示的に拒否
- タグポリシーで「特定タグキーに対する許可タグ値」を制限可能
- OUごとに異なるタグ値を求めるには、タグポリシーをOU単位で適用する必要がある
- SCP とタグポリシーの組み合わせで、タグ付与の必須化 + タグ値の正当性チェックを実現できる
❌ 不正解の選択肢の理由
B. タグポリシーを管理アカウントにアタッチ
- 管理アカウントにタグポリシーをアタッチするとすべてのOUに同一ポリシーが適用されてしまう
- 要件である「OUごとに異なるタグ値の強制」が実現できない
C. SCP でタグ存在時に作成を許可する
- SCP は “許可”条件でタグ値を評価することはできない
- SCP の評価はリクエスト時であり、タグがまだ存在しないため、条件として機能しない
D. タグのリストのみ SCP で定義
- SCP 単体では タグキーの存在有無は制御可能だが、タグ値の検証はできない
- タグ値を強制するにはタグポリシーとの併用が必須
■ SAP試験で押さえておくべきポイント
- SCP（Service Control Policy）：
- AWS Organizationsでのリソース操作制限に使用
"Condition"で"aws:RequestTag"を使ってタグがないリソース作成を拒否できる- ただしタグ値のバリデーションまでは対応できない
- タグポリシー（Tag Policies）：
- OU 単位で適用可能
- 指定されたタグキー・タグ値以外のリソース作成を制限できる
- OUごとに異なるタグルールを適用可能
- タグ制約設計の基本戦略：
- タグキーの存在チェック → SCP
- タグ値の妥当性チェック → タグポリシー
- OUレベルで異なるタグルール → OUにポリシーを割り当てる
次の問題があれば、同様に対応いたします。どうぞお送りください。
以下は、問題5の内容を指定のフォーマットで整理したものです。
■ 問題文（編集せずに出力）
ある企業では、Amazon S3 バケット内に数百万のオブジェクトがあります。オブジェクトは S3 標準ストレージクラスにあります。すべての S3 オブジェクトは頻繁にアクセスされます。オブジェクトにアクセスするユーザーとアプリケーションの数は急速に増加しています。オブジェクトは、AWS KMS キーによるサーバー側の暗号化 (SSE-KMS) で暗号化されます。
ソリューションアーキテクトは、会社の毎月の AWS 請求書を確認し、Amazon S3 からのリクエスト数が多いため、AWS KMS コストが増加していることに気付きました。ソリューションアーキテクトは、アプリケーションへの変更を最小限に抑えてコストを最適化する必要があります。
運用上のオーバーヘッドを最小限に抑えてこれらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. 新しい S3 バケットを作成し、暗号化タイプとして、お客様が用意したキーによるサーバー側の暗号化 (SSE-C) を使用します。既存のオブジェクトを新しい S3 バケットにコピーします。SSE-C を指定します。
- B. 新しい S3 バケットを作成し 暗号化タイプとして Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) を使用します。S3 バッチ操作を使用して、既存のオブジェクトを新しい S3 バケットにコピーします。SSE-S3 を指定します。
- C. AWS CloudHSM を使用して暗号化キーを保存します。新しい S3 バケットを作成します。S3 バッチ操作を使用して、既存のオブジェクトを新しい S3 バケットにコピーします。CloudHSM のキーを使用してオブジェクトを暗号化します。
- D. S3 バケットに S3 Intelligent-Tiering ストレージクラスを使用します。S3 Intelligent-Tiering アーカイブ設定を作成して、90 日間アクセスされなかったオブジェクトを S3 Glacier Deep Archive に移行します。
■ 問題文の要件の概要
- S3オブジェクトは頻繁にアクセスされている
- 暗号化方式は現在 SSE-KMS（AWS KMS使用）
- KMS APIリクエストのコストが高騰している
- アプリケーション変更は最小限にしたい
- 運用オーバーヘッドも抑えたい
✅ 正解の選択肢と解説
- 正解：B
B. SSE-S3 を使った新バケットにバッチコピー
- SSE-KMS はリクエストごとに KMS を呼び出すため、アクセス頻度が高い場合に KMS料金が急増
- SSE-S3（Amazon S3 マネージドキー）を使えば、KMS 呼び出し不要 → リクエスト課金なし
- S3 バッチオペレーションで一括コピーすれば、アプリケーション修正なしで暗号化方式を移行可能
- SSE-S3 は AWS によるキー管理で、追加コストなし・運用負荷も低い
❌ 不正解の選択肢の理由
A. SSE-C（顧客提供キー）を使用
- 毎回リクエストでクライアント側がキーを提供する必要あり
- 頻繁なアクセスには運用負荷が大きすぎる
- セキュリティ維持は可能だが、現実的ではなくアプリ側の実装変更も必要
C. CloudHSM を使用
- CloudHSM はセキュリティレベルは非常に高いが、コストも非常に高い
- 専用の HSM クラスタ構成が必要で、構成・保守の複雑さも大きい
- コスト削減という要件に反する
D. Intelligent-Tiering でアーカイブに移動
- KMS の呼び出しコストに影響しない
- ストレージ保管料は減らせる可能性があるが、リクエスト課金は変わらず
- 頻繁にアクセスされているという要件とも矛盾
■ SAP試験で押さえておくべきポイント
- **SSE-KMS（KMSキー）**は、KMS API リクエストごとに課金されるため、アクセス数が多いとコストが増大
- SSE-S3（S3管理キー）は追加課金なし → 頻繁アクセスされる S3 オブジェクト向けに最もコスト効率が良い暗号化方式
- 暗号化の変更は S3 バッチ操作で一括対応可能 → アプリ修正不要
- SSE-C や CloudHSM はセキュリティ強化用途であり、コスト削減や簡易運用とは相性が悪い
次の問題があれば、引き続き同様に分析いたします。お気軽にお送りください。
以下は、問題6の内容を指定のフォーマットで整理したものです。
■ 問題文（編集せずに出力）
ある大企業は、数百の AWS アカウントにまたがる VPC でワークロードを実行しています。各 VPC は、複数のアベイラビリティーゾーンにまたがるパブリックサブネットとプライベートサブネットで構成されています。NAT ゲートウェイはパブリックサブネットにデプロイされ、プライベートサブネットからインターネットへのアウトバウンド接続を許可します。
ソリューションアーキテクトはハブアンドスポーク設計に取り組んでいます。スポーク VPC 内のすべてのプライベートサブネットは、egress VPC を介してインターネットにトラフィックをルーティングする必要があります。ソリューションアーキテクトは、すでに中央の AWS アカウントの egress VPC に NAT ゲートウェイをデプロイしています。
これらの要件を満たすために、ソリューションアーキテクトが取るべき追加の手順を選択してください。
■ 選択肢（編集せずに出力）
- A. egress VPC とスポーク VPC の間にピアリング接続を作成します。インターネットへのアクセスを許可するために必要なルーティングを構成します。
- B. Transit Gateway を作成し、既存の AWS アカウントと共有します。既存の VPC を Transit Gateway にアタッチします。インターネットへのアクセスを許可するために必要なルーティングを構成します。
- C. すべてのアカウントに Transit Gateway を作成します。Transit Gateway に NAT ゲートウェイをアタッチします。インターネットへのアクセスを許可するために必要なルーティングを構成します。
- D. egress VPC とスポーク VPC の間に AWS PrivateLink 接続を作成します。インターネットへのアクセスを許可するために必要なルーティングを構成します。
■ 問題文の要件の概要
- 数百の AWS アカウントにまたがる VPC
- 各スポーク VPC から、中央の egress VPC に集約し NAT ゲートウェイ経由でインターネットに接続
- ハブアンドスポーク設計
- 拡張性とルート管理の簡素化が求められる
✅ 正解の選択肢と解説
- 正解：B
B. Transit Gateway を使用して各スポーク VPC を接続
- Transit Gateway はハブとして機能し、複数 VPC を集約・接続可能
- 各スポーク VPC を Transit Gateway にアタッチし、デフォルトルート (0.0.0.0/0) を Transit Gateway 宛てに設定
- Transit Gateway のルートテーブルで egress VPC の NAT ゲートウェイサブネットに転送する設定をすれば、一元管理されたインターネットアクセス構成を実現
- スケーラブルかつ推移的ルーティングが可能な唯一の構成
❌ 不正解の選択肢の理由
A. VPC ピアリング接続
- ピアリングは 推移的ルーティング非対応
- 数百 VPC を個別に接続する必要があり、接続数やルート管理が爆発的に複雑化
- egress VPC 経由でトラフィック集約ができない
C. 各アカウントに個別 Transit Gateway 作成
- Transit Gateway は NAT ゲートウェイを直接アタッチできない
- ハブを乱立させてもネットワーク一元化できず、構成が冗長・複雑化
D. AWS PrivateLink を使用
- PrivateLink はサービス公開用途（Interfaceエンドポイント/NLB向け通信）であり、ルーティング用途ではない
- インターネットアクセスのためのトラフィック転送には使用不可
■ SAP試験で押さえておくべきポイント
- Transit Gateway は推移的ルーティングと集中管理に対応した唯一のスケーラブルな手段
- VPC ピアリングは非推移的で大規模環境には不向き
- PrivateLink はサービス接続用途であり、汎用的なトラフィックルーティングには使えない
- NAT ゲートウェイを集中配置するには、Transit Gateway + egress VPC の構成がベストプラクティス
次の問題もあれば引き続きどうぞ。どんどん対応いたします。
以下は、問題7の内容を指定のフォーマットで整理したものです。
■ 問題文（編集せずに出力）
ソリューションアーキテクトは、ディザスタリカバリ要件が厳しい政府機関で働いています。すべての Amazon Elastic Block Store (Amazon EBS) のスナップショットは、少なくとも 2 つの追加の AWS リージョンに保存する必要があります。政府機関は、運用上のオーバーヘッドを可能な限り最小限に抑えることも求められます。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. Amazon Data Lifecycle Manager (Amazon DLM) でポリシーを 1 日 1 回実行して EBS スナップショットを追加のリージョンにコピーするように設定します。
- B. Amazon EventBridge を使用して、EBS スナップショットを追加リージョンにコピーする AWS Lambda 関数をスケジュールします。
- C. AWS Backup を設定して、EBS スナップショットを作成します。Amazon S3 クロスリージョンレプリケーション (CRR) を設定して、EBS スナップショットを追加のリージョンにコピーします。
- D. Amazon EC2 Image Builder を毎日 1 回実行するようにスケジュールして、AMI を作成し、AMI を追加リージョンにコピーします。
■ 問題文の要件の概要
- 厳格なディザスタリカバリ対策として
EBS スナップショットを 2 つ以上の追加リージョンに保存する必要がある - 運用オーバーヘッドを最小限に抑える必要がある
- 自動化されたスナップショットコピーが求められる
✅ 正解の選択肢と解説
- 正解：A
A. Amazon Data Lifecycle Manager（DLM）を使用したクロスリージョンコピー
- DLM は EBS スナップショットのライフサイクルを自動管理できるフルマネージドサービス
- スナップショット取得＋クロスリージョンコピーを 1 日 1 回などのスケジュールで自動実行できる
- 複数リージョンにコピーする設定もサポート
- スクリプト不要で、政府機関が求める最小運用コストに合致
❌ 不正解の選択肢の理由
B. EventBridge + Lambda
- 自動化は可能だが、スナップショット一覧取得・コピー処理のコード管理が必要
- 失敗時のリトライや通知の実装も追加作業
- 運用オーバーヘッドが高く、政府機関の要件に適合しない
C. AWS Backup + S3 CRR
- EBSスナップショットはS3オブジェクトではない
- CRR は S3 バケットに限定されており、EBS スナップショットの対象外
- この構成ではスナップショットをリージョン間でコピーできない
D. EC2 Image Builder を使って AMI をリージョンコピー
- AMI のコピーは可能だが、EBS スナップショット全体を対象としたバックアップではない
- 要件である 「EBS スナップショットを複数リージョンに保存」 に一致しない
■ SAP試験で押さえておくべきポイント
- Amazon DLM（Data Lifecycle Manager）は、EBS スナップショットのクロスリージョンコピーも含めたバックアップ自動化に最適
- 手動スクリプトや Lambda は柔軟だが、**試験では「フルマネージド」「運用簡素化」**がキーワード
- EBS スナップショット ≠ S3 オブジェクトであるため、CRR でのコピーは不可
- AMI = OSイメージ全体なのでスナップショットと混同しないこと
次の問題があれば、引き続きお送りください。すぐに対応します！
