ありがとうございます!いただいたHTMLを整理して、指定のフォーマットでまとめました。
問題文
AWS のパートナー企業は、org1 という名前の組織を使用して AWS Organizations でサービスを構築しています。このサービスを利用するためには、パートナー企業が、org2 という別の組織にあるカスタマーアカウントの AWS リソースにアクセスする必要があります。パートナー企業は、API またはコマンドラインツールを使用して、カスタマーアカウントへの最小限の特権のセキュリティアクセスを確立する必要があります。org1 が org2 のリソースにアクセスできるようにするための最も安全な方法を選択してください。
選択肢
A. お客様は、ログインして必要なタスクを実行するために、パートナー企業に AWS アカウントのアクセスキーを提供する必要があります。
B. お客様は IAM ユーザーを作成し、IAM ユーザーに必要な権限を割り当てる必要があります。次に、お客様は、ログインして必要なタスクを実行するために、パートナー企業に認証情報を提供する必要があります。
C. お客様は IAM ロールを作成し、必要な権限を IAM ロールに割り当てる必要があります。パートナー企業は、必要なタスクを実行するためにアクセスを要求する際に、IAM ロールの Amazon リソース名 (ARN) を使用する必要があります。
D. お客様は IAM ロールを作成し、必要な権限を IAM ロールに割り当てる必要があります。パートナー企業は、必要なタスクを実行するためのアクセスを要求する際に、IAM ロールの信頼ポリシーの外部 ID を含む IAM ロールの Amazon リソース名 (ARN) を使用する必要があります。
問題文の要件の概要
- 状況: org1(パートナー企業)が org2(顧客)のリソースへアクセスする必要がある。
- 要件: API または CLI を用いて最小権限で安全にクロスアカウントアクセスを確立すること。
- ポイント: 外部組織への委任アクセスのベストプラクティスを選ぶ問題。
正解の選択肢と解説
正解: D
- 顧客が IAM ロールを作成し、必要最小限の権限を付与する。
- パートナー企業は STS AssumeRole を使って一時的な認証情報を取得する。
- 信頼ポリシーに 外部 ID を含めることで Confused Deputy 攻撃を防止できる。
- 長期のアクセスキー共有を避け、一時的な資格情報を利用することでセキュリティを担保できる。
不正解の選択肢の理由
- A: アクセスキー共有は長期固定認証情報の漏えいリスクが高く、セキュリティ的に禁忌。
- B: IAM ユーザーを作成して外部に渡すのは結局長期認証情報の共有であり、運用が煩雑かつ危険。
- C: ロールを利用する点は正しいが、外部 ID を使わないと第三者がロール ARN を知るだけで AssumeRole 可能になり、混同代理人攻撃を防げない。
SAP試験で押さえておくべきポイント
- クロスアカウントアクセスのベストプラクティスは「IAM ロール + STS AssumeRole + 外部 ID」。
- 外部 IDは Confused Deputy 攻撃を防ぐ仕組みであり、試験頻出ワード。
- 長期的な認証情報(アクセスキー・IAMユーザーの認証情報)を外部に渡すのはNG。
- 最小権限の原則を常に徹底(必要なポリシーのみ付与)。
- CloudTrailでの監査が可能になる点もアピールされやすい。
次の問題も同じ形式で整理していきますか?
了解しました!いただいた問題を整理しました。
問題文
ある企業がレガシーアプリケーションを AWS クラウドに移行しました。このアプリケーションは、3 つのアベイラビリティーゾーンに配置される 3 つの Amazon EC2 インスタンスで実行されます。各アベイラビリティーゾーンに 1 台の EC2 インスタンスがあります。EC2 インスタンスは、VPC の 3 つのプライベートサブネットで実行され、3 つのパブリックサブネットに関連付けられた Application Load Balancer (ALB) のターゲットとして設定されています。
アプリケーションはオンプレミスのシステムと通信する必要があります。オンプレミスのシステムへのアクセスは、会社の IP アドレス範囲内の IP アドレスからのトラフィックのみが許可されています。同社のセキュリティチームは、社内の IP アドレス範囲から 1 つの IP アドレスだけをクラウドに持ち込んでいます。同社はこの IP アドレスを社内ファイアウォールの許可リストに追加しました。同社は、この IP アドレスに対して Elastic IP アドレスを作成しました。
ソリューションアーキテクトは、アプリケーションがオンプレミスのシステムと通信できるソリューションを作成する必要があります。また、ソリューションは障害を自動的に軽減できなければなりません。
これらの要件を満たすソリューションを選択してください。
選択肢
A. パブリックサブネットに 1 台ずつ、合計 3 台の NAT ゲートウェイをデプロイします。NAT ゲートウェイに Elastic IP アドレスを割り当てます。NAT ゲートウェイのヘルスチェックを有効にします。NAT ゲートウェイがヘルスチェックに失敗した場合は、NAT ゲートウェイを再作成し、新しい NAT ゲートウェイに Elastic IP アドレスを割り当てます。
B. ALB を Network Load Balancer (NLB) に置き換えます。NLB に Elastic IP アドレスを割り当てます。NLB のヘルスチェックを有効にします。ヘルスチェックに失敗した場合は、NLB を別のサブネットに再デプロイします。
C. パブリックサブネットに単一の NAT ゲートウェイをデプロイします。NAT ゲートウェイに Elastic IP アドレスを割り当てます。Amazon CloudWatch をカスタムメトリクスで使用して、NAT ゲートウェイを監視します。NAT ゲートウェイが異常な場合は、AWS Lambda 関数を呼び出して、別のサブネットに新しい NAT ゲートウェイを作成します。新しい NAT ゲートウェイに Elastic IP アドレスを割り当てます。
D. ALB に Elastic IP アドレスを割り当てます。Elastic IP アドレスを値として Amazon Route 53 シンプルレコードを作成します。Route 53 ヘルスチェックを作成します。ヘルスチェックが失敗した場合は、別のサブネットで ALB を再作成します。
問題文の要件の概要
- オンプレミスと通信する必要がある(ファイアウォール許可リストに登録した Elastic IP を使う)。
- 通信経路はプライベートサブネット → NAT → オンプレミス。
- 自動的に障害を軽減できる仕組み(ヘルスチェック+自動復旧)。
- 要件の本質:Elastic IP を一貫して利用しつつ、冗長化・障害復旧を実現する。
正解の選択肢と解説
正解: C
- 単一の NAT Gateway に Elastic IP を割り当てることでオンプレミス側のファイアウォール設定を維持できる。
- CloudWatch メトリクス+Lambda で異常を検知し、別の AZ に自動的に新しい NAT Gateway を作成して同じ Elastic IP を再割り当て可能。
- これにより障害時も通信を維持し、自動復旧が可能になる。
- AWS が推奨する「Elastic IP を固定して、障害時に再割り当てする」設計と一致する。
不正解の選択肢の理由
- A: NAT Gateway はヘルスチェックを提供していない。再作成や Elastic IP 再割り当ては自動化されないため誤り。
- B: NLB に Elastic IP を割り当てることは可能だが、このシナリオでは アウトバウンド通信のために NAT が必要。NLB では要件を満たさない。
- D: ALB に Elastic IP を割り当てることは不可能。ALB は自動スケーリングされるマネージドリソースであり、EIPを直接関連付けできない。
SAP試験で押さえておくべきポイント
- NAT Gateway + Elastic IP はオンプレミスとの通信でよく出題されるパターン。
- 障害時は EIP を新しい NAT Gateway に再アタッチして復旧するのがベストプラクティス。
- ALB に EIP は付けられない → 試験でもよく問われるトリック。
- NLB は EIPを持てるが、用途が異なる(ここではアウトバウンド通信が必要)。
- CloudWatch + Lambda の自動復旧設計は試験で頻出。
次の問題も整理しますか?
ありがとうございます!こちらの問題も指定の形式で整理しました。
問題文
ある会社がアートワークのオークションサービスを提供しており、北米とヨーロッパにユーザーがいます。同社は、アプリケーションを us-east-1 リージョンの Amazon EC2 インスタンスでホストしています。アーティストは、自分の作品の写真を大容量な高解像度の画像ファイルとして携帯電話から、us-east-1 リージョンで作成された一元化された Amazon S3 バケットにアップロードします。ヨーロッパのユーザーは、画像のアップロードのパフォーマンスが遅いと報告しています。ソリューションアーキテクトはどのようにして画像アップロードプロセスのパフォーマンスを向上させることができますか?
選択肢
A. S3 マルチパートアップロードを使用するようにアプリケーションを再デプロイします。
B. Amazon CloudFront ディストリビューションを作成し、アプリケーションをカスタムオリジンとしてポイントします。
C. S3 Transfer Acceleration を使用するようにバケットを設定します。
D. EC2 インスタンスの Auto Scaling グループを作成し、スケーリングポリシーを作成します。
問題文の要件の概要
- ユーザーは北米とヨーロッパに分散。
- S3 バケットは us-east-1 に一元化されている。
- ヨーロッパからの アップロード遅延が問題。
- 要件は アップロード(入力経路)の高速化。
- 本質は「地理的に遠いユーザーから S3 バケットへのアップロードを高速化する方法」。
正解の選択肢と解説
正解: C. S3 Transfer Acceleration を使用するようにバケットを設定します。
- S3 Transfer Acceleration は Amazon CloudFront のエッジロケーションを活用して、最寄りのエッジにデータをアップロードさせ、AWS 内部ネットワーク経由で S3 バケットに転送する仕組み。
- 地理的に遠いユーザー(例:ヨーロッパ → us-east-1)でも、高速・安定した転送が可能。
- 特に「大容量ファイル」「大陸間転送」が多いユースケースに有効。
- これにより、ヨーロッパユーザーのアップロード遅延を解消できる。
不正解の選択肢の理由
- A(マルチパートアップロード): 大容量ファイルのアップロードを効率化する技術だが、地理的なレイテンシー問題は解決できない。
- B(CloudFront + カスタムオリジン): CloudFront は基本的に ダウンロード/配信の高速化に使う。アップロードを高速化する用途ではない。
- D(Auto Scaling): EC2 の処理能力を増やしても、S3 へのアップロード性能には無関係。
SAP試験で押さえておくべきポイント
- S3 Transfer Acceleration = グローバルから S3 へのアップロード高速化。
- CloudFront は「ダウンロード最適化」、Transfer Acceleration は「アップロード最適化」という違いを押さえる。
- 「大容量ファイル」「大陸間通信」「世界中のユーザーが一つのバケットにアップロードする」→ Transfer Acceleration が正解。
- マルチパートアップロードは「大きいファイルを分割して効率化」であり、帯域幅や地理的な遅延の改善策ではない。
次の問題(問題4)も整理していきますか?
ありがとうございます!問題4も整理しました。
問題文
ある会社が AWS でサーバーレスアプリケーションを実行したいと考えています。同社は、Amazon ECS クラスターで実行されている Docker コンテナーでアプリケーションをプロビジョニングすることを計画しています。アプリケーションは MySQL データベースを必要とし、Amazon RDS を使用することを計画しています。同社には、最初の 3 ヶ月間は頻繁にアクセスする必要があり、その後はほとんどアクセスしないドキュメントがあります。ドキュメントは 7 年間保持する必要があります。これらの要件を満たすための最もコスト効率の良いソリューションを選択してください。
選択肢
A. オンデマンドインスタンスを使用して ECS クラスターを作成します。スポットインスタンスを使用して、Amazon RDS でデータベースとそのリードレプリカをプロビジョニングします。ドキュメントを暗号化された EBS ボリュームに保存し、cron ジョブを作成して 7 年後にドキュメントを削除します。
B. スポットインスタンスのドレインを有効にして、スポットインスタンスのフリートを使用して ECS クラスターを作成します。リザーブドインスタンスを使用して、Amazon RDS でデータベースとそのリードレプリカをプロビジョニングします。ライフサイクルポリシーを使用してセキュリティで保護された Amazon S3 バケットにドキュメントを保存し、3 ヶ月以上経過したドキュメントを Amazon S3 Glacier に移動してから、7 年以上経過したドキュメントを Amazon S3 Glacier から削除します。
C. オンデマンドインスタンスを使用して ECS クラスターを作成します。オンデマンドインスタンスを使用して、Amazon RDS でデータベースとそのリードレプリカをプロビジョニングします。ドキュメントを Amazon EFS に保存します。cron ジョブを作成して、3 ヶ月以上経過したドキュメントを Amazon S3 Glacier に移動します。AWS Lambda 関数を作成して、7 年以上経過した S3 Glacier のドキュメントを削除します。
D. スポットインスタンスのドレインを有効にしたスポットインスタンスのフリートを使用して、ECS クラスターを作成します。オンデマンドインスタンスを使用して、Amazon RDS でデータベースとそのリードレプリカをプロビジョニングします。ライフサイクルポリシーを使用して、セキュリティで保護された Amazon S3 バケットにドキュメントを保存し、3 ヶ月以上経過したドキュメントを Amazon S3 Glacier に移動し、7 年後に Amazon S3 Glacier のドキュメントを削除します。
問題文の要件の概要
- アプリケーション実行基盤: コンテナ → ECS クラスターで実行。
- DB要件: MySQL → Amazon RDS を利用。
- ドキュメント要件:
- 最初の3ヶ月間は頻繁にアクセス。
- その後はほぼアクセスなし。
- 7年間保持必須。
- 目的: 最小コストで要件を満たすこと。
正解の選択肢と解説
正解: B
- ECSクラスター: スポットインスタンスを活用し、スポットドレイン機能を有効化。→ 低コストかつ自動復旧性を確保。
- RDS: リザーブドインスタンスを利用することで、長期的にコストを最適化。
- ストレージ:
- 頻繁アクセス時(最初の3ヶ月間)は Amazon S3 標準ストレージ。
- 3ヶ月以降は S3 Glacier にライフサイクルで自動移行 → 超低コスト。
- 7年経過後に ライフサイクルルールで削除。
- 手動での管理不要。自動化とコスト効率の両立。
不正解の選択肢の理由
- A: RDS にスポットインスタンスという概念はなく誤り。さらに EBS 保存は高コストでアーカイブ用途に不適。
- C: EFS は頻繁アクセス向きで、ほとんどアクセスしない長期保存にはコストが高すぎる。cron や Lambda での削除も不要。
- D: ECS 部分は妥当だが、RDS をオンデマンド利用しており長期コスト最適化に劣る。
SAP試験で押さえておくべきポイント
- ECS スポットインスタンス + ドレイン機能 → 高可用性と低コストを両立する設計。
- RDS リザーブドインスタンス → 長期稼働DBのコスト削減策。
- S3 ライフサイクルポリシー → 頻繁アクセス → Glacier 移行 → 削除、を自動化するのがベストプラクティス。
- EBS・EFS はアーカイブ用途に不向き → 試験のひっかけポイント。
- 最小コスト+長期保持+自動化がキーワード。
次の問題(問題5)も同じ形式で整理していきますか?
ありがとうございます!問題5を整理しました。
問題文
ソリューションアーキテクトは、ウェブ、アプリケーション、および NoSQL データ層を持つ 3 層アプリケーション用のソリューションのリファレンスアーキテクチャを定義する必要があります。リファレンスアーキテクチャは、以下の要件を満たす必要があります。
- AWS リージョン内での高可用性
- 災害復旧のために別の AWS リージョンへの 1 分以内のフェイルオーバー
- ユーザーエクスペリエンスへの影響を最小限に抑えつつ、最も効率的なソリューションの提供
これらの要件を満たすステップの組み合わせはどれですか? (3 つ選択)
選択肢
A. 選択した 2 つのリージョン間で 100/0 に設定された Amazon Route 53 加重ルーティングポリシーを使用します。有効期限 (TTL) を 1 時間に設定します。
B. プライマリリージョンから災害復旧リージョンへのフェイルオーバーには、Amazon Route 53 フェイルオーバールーティングポリシーを使用します。有効期限 (TTL) を 30 秒に設定します。
C. Amazon DynamoDB 内でグローバルテーブルを使用して、選択した 2 つのリージョンのデータにアクセスできるようにします。
D. プライマリリージョンの Amazon DynamoDB テーブルから 60 分ごとにデータをバックアップし、Amazon S3 にデータを書き込みます。S3 クロスリージョンレプリケーションを使用して、プライマリリージョンから災害復旧リージョンにデータをコピーします。災害復旧シナリオで、スクリプトにデータを DynamoDB にインポートさせます。
E. リージョン内の複数のアベイラビリティーゾーンにまたがるウェブ層とアプリケーション層の Auto Scaling グループを使用して、ホットスタンバイモデルを実装します。サーバーの最小数にはゾーンのリザーブドインスタンスを使用し、追加のリソースにはオンデマンドインスタンスを使用します。
問題文の要件の概要
- リージョン内高可用性 → 複数 AZ に跨る冗長構成が必須。
- 災害復旧 (DR) フェイルオーバー ≤ 1分 → DNS フェイルオーバー(Route 53)かつ TTL を短くする必要あり。
- 効率的ソリューション → データ層はリージョン間で自動かつ低遅延にレプリケートできる仕組みが必要。
正解の選択肢と解説
正解: B, C, E
- B: Route 53 フェイルオーバールーティング (TTL 30秒)
- 最小のユーザー影響で迅速にフェイルオーバーできる。
- 1分以内の DR フェイルオーバー要件を満たす。
- C: DynamoDB グローバルテーブル
- 複数リージョンでデータを自動複製し、どのリージョンでも同じデータを利用可能。
- DR 時も整合性を維持できる。
- E: 複数AZ + Auto Scaling グループ (ホットスタンバイ)
- リージョン内高可用性を担保。
- 最小インスタンスをリザーブドで確保し、追加分はオンデマンド → コスト効率と可用性の両立。
不正解の選択肢の理由
- A: Weighted routing (100/0) は実質フェイルオーバーにならない。TTL が 1時間では 即時フェイルオーバー不可。
- D: S3 経由の手動リストアは時間がかかり、1分以内のフェイルオーバー要件を満たせない。
SAP試験で押さえておくべきポイント
- Route 53 フェイルオーバーポリシー + 短TTL → DR対策の基本。
- DynamoDB グローバルテーブル → マルチリージョンの RPO/RTO 要件に有効。
- ホットスタンバイ構成 → リージョン内HAの実現。
- バックアップ&リストア型のDR は即時性に欠けるため、短いRTOが要求される設問では不正解。
- TTLの値が解答の分かれ目になるので注意。
次の問題(問題6)も整理していきますか?
ありがとうございます!問題6を整理しました。
問題文
ある企業がブログプラットフォームを AWS に移行しています。この会社のオンプレミスサーバーは、AWS Site-to-Site VPN 接続を介して AWS に接続しています。ブログコンテンツは、複数の作成者によって 1 日に数回更新され、ネットワーク接続ストレージ (NAS) サーバー上のファイル共有から提供されます。
同社は、コンテンツの更新を遅らせることなく、ブログプラットフォームを移行する必要があります。同社は、Application Load Balancer の背後でブログプラットフォームを実行するために、複数のアベイラビリティーゾーンに Amazon EC2 インスタンスをデプロイしています。また、200 TB のアーカイブデータをオンプレミスサーバーから Amazon S3 にできるだけ早く移動する必要もあります。
これらの要件を満たす解決策の組み合わせを選択してください。(2 つ選択)
選択肢
A. Amazon EventBridge で毎週 cron ジョブを作成します。cron ジョブを使用して、AWS Lambda 関数を呼び出し、NAS サーバーから EC2 インスタンスを更新します。
B. コンテンツアクセス用に、EC2 インスタンスが共有する Amazon Elastic Block Store (Amazon EBS) マルチアタッチボリュームを構成します。EBS ボリュームを NAS サーバーと毎週同期させるコードを記述します。
C. Amazon Elastic File System (Amazon EFS) ファイルシステムをオンプレミスサーバーにマウントして、NAS サーバーとして機能させます。ブログデータを EFS ファイルシステムにコピーします。EFS ファイルシステムを EC2 インスタンスにマウントし、コンテンツを提供します。
D. AWS Snowball Edge Storage Optimized デバイスを注文します。静的データアーティファクトをデバイスにコピーします。デバイスを AWS に発送します。
E. AWS Snowcone SSD デバイスを注文します。静的データアーティファクトをデバイスにコピーします。デバイスを AWS に発送します。
問題文の要件の概要
- 頻繁に更新されるコンテンツをリアルタイムに提供する必要あり → NAS の代替としてクラウド側にファイル共有システムが必要。
- 200 TB の大量データを迅速に移行する必要 → ネットワーク経由では非現実的。専用の物理転送デバイスを利用するのがベスト。
正解の選択肢と解説
正解: C, D
- C. Amazon EFS
- EFS は複数の EC2 インスタンスから同時アクセス可能な共有ファイルシステム。
- オンプレミスからも VPN 経由でマウント可能。
- ブログコンテンツをオンプレとクラウドの両方で即座に共有できるため、コンテンツ更新を遅延なく反映可能。
- D. AWS Snowball Edge Storage Optimized
- 数百 TB 級のデータ移行に最適。
- 200 TB を効率的に S3 に移動でき、ネットワーク経由の長期転送を避けられる。
- データは暗号化され、安全に AWS に送付可能。
不正解の選択肢の理由
- A. EventBridge + Lambda
- 定期的な同期しかできず、リアルタイム更新を保証できない。
- スループットやレイテンシー面で要件を満たせない。
- B. EBS マルチアタッチ
- EBS はブロックストレージであり、ファイル共有には不向き。
- 同期をコードで実装するのは非効率で、可用性も担保できない。
- E. Snowcone SSD
- 容量が最大数 TB 程度しかないため、200 TB には不適切。
- 小規模データやエッジ用途には適するが、大量データ移行には不向き。
SAP試験で押さえておくべきポイント
- EFS = 共有ファイルシステム、オンプレとクラウドのシームレス統合が可能。
- Snowball Edge = 数百 TB 級のデータ移行の王道解。
- Snowcone は小規模、Snowball Edge は大規模移行と覚える。
- EBS マルチアタッチは「ブロックレベル共有」であり、NFS のような「ファイルレベル共有用途」には適さない。
- 試験では「リアルタイム更新が必要」か「アーカイブデータ移行」かを見極めるのがポイント。
次の 問題7 も整理していきますか?
了解しました。ご提示いただいた問題を指定フォーマットで整理しました。
■問題文
ある企業では、AWS 上でウェブアプリケーションを us-east-1 リージョンでホストしています。アプリケーションサーバーは、 Application Load Balancer の背後にある 3 つのアベイラビリティーゾーンに分散しています。データベースは、Amazon EC2 インスタンス上の MySQL データベースでホストされています。ソリューションアーキテクトは、RTO が 5 分未満、RPO が 1 分未満の AWS サービスを使用して、クロスリージョンのデータリカバリソリューションを設計する必要があります。ソリューションアーキテクトは、アプリケーションサーバーを us-west-2 にデプロイし、Amazon Route 53 ヘルスチェックと DNS フェイルオーバーを us-west-2 に設定しました。ソリューションアーキテクトはどの追加ステップを実行する必要がありますか?
■選択肢
A. us-west-2 のクロスリージョンリードレプリカを使用して、データベースを Amazon RDS for MySQL インスタンスに移行します。
B. プライマリを us-east-1 に、セカンダリを us-west-2 にデプロイした Amazon Aurora Global Database にデータベースを移行します。
C. マルチ AZ 配置を使用してデータベースを AmazonRDS for MySQL インスタンスに移行します。
D. us-west-2 の Amazon EC2 インスタンスに MySQL スタンバイデータベースを作成します。
■問題文の要件の概要
- 現状: us-east-1 に ALB + EC2(MySQL) で稼働中
- 災害対策: us-west-2 に DR を構築
- 要件:
- RTO < 5 分
- RPO < 1 分
- Route 53 でフェイルオーバー設定済み
- 求められる追加ステップは「RTO と RPO を満たすクロスリージョンのデータベース復旧」
■正解の選択肢と解説
B. プライマリを us-east-1 に、セカンダリを us-west-2 にデプロイした Amazon Aurora Global Database にデータベースを移行します。
- 理由:
Aurora Global Database は RPO が 1 秒未満、RTO が 1 分未満 を実現可能。
グローバル分散により、災害時はセカンダリリージョンを昇格し迅速にフェイルオーバーできる。
EC2 上の MySQL や通常の RDS よりもはるかに高い DR 性能を持ち、問題の要件を満たす。
■不正解の選択肢の理由
- A. クロスリージョンリードレプリカ (RDS MySQL)
- 手動昇格が必要で RTO が長くなる。自動化も複雑で要件不達。
- C. RDS MySQL マルチAZ
- マルチAZは同一リージョン内の耐障害性の仕組みであり、クロスリージョン災害復旧には使えない。
- D. EC2 スタンバイ MySQL
- 手動でレプリケーション設定・フェイルオーバーが必要。RTO/RPO を満たせない。
■SAP試験で押さえておくべきポイント
- Aurora Global Database:
- 複数リージョンにレプリケーション(遅延 < 1 秒)
- RPO ≒ 1 秒未満、RTO ≒ 1 分未満
- DR(ディザスタリカバリ)要件に最適
- RDS マルチAZ → リージョン内の高可用性
- RDS クロスリージョンリードレプリカ → DR に使えるが RTO 長い
- EC2 上の MySQL → 運用負荷が高く、災害対策としては非推奨
次の問題も同じ形式で整理しましょうか?