23-AWS SAP「理論・実践・10問道場」

type

status

date

slug

summary

231-AWS SAP AWS 「理論・実践・一問道場」

理論

SMBファイルとは？

SMB（Server Message Block）は、ネットワーク上でファイルやプリンタ、その他のリソースを共有するためのプロトコルです。特にWindows環境で広く使用されており、次のような用途があります。

主な特徴

ファイル共有

ネットワーク経由でファイルの読み書きが可能。

ユーザーごとのアクセス制御が可能。

プリンタ共有

ネットワーク上のプリンタを複数のユーザーで共有。

透過性

ユーザーには、ネットワーク上のファイルやリソースがローカルに存在するかのように見える。

SMBの使用例

オンプレミス環境

ローカルネットワークでファイルサーバを構築し、複数のクライアントが同じファイルを操作。

クラウドストレージ

AWS Storage GatewayやAmazon FSx for Windows File Serverなど、クラウドと統合したSMB共有が可能。

SMBのメリット

簡単なセットアップでファイル共有を実現。

ネイティブなWindowsサポート。

他のOS（Linux、macOS）でも利用可能。

AWSとの関連

AWSのStorage GatewayやAmazon FSx for Windows File Serverは、SMBプロトコルを活用してオンプレミス環境とクラウド間のファイル共有を簡単に実現します。

AWS Storage Gatewayの詳細

AWS Storage Gatewayは、オンプレミス環境とAWSクラウド間でデータを統合するためのハイブリッドクラウドストレージサービスです。特に「ファイルゲートウェイ」と「ボリュームゲートウェイ」は、それぞれ異なるデータタイプとユースケースに対応しています。

1. ファイルゲートウェイ (File Gateway)

概要

オンプレミスのアプリケーションが、Amazon S3に直接アクセスできるようにするためのゲートウェイです。データはファイル形式で管理されます。

特徴

プロトコル対応:

SMB（Server Message Block）: 主にWindowsベースの環境に対応。
NFS（Network File System）: 主にLinuxベースの環境に対応。

データ保存:

ファイルはAmazon S3にオブジェクト形式で保存されます。
オンプレミスのアプリケーションは、ファイルをS3上のデータとして認識します。

ローカルキャッシュ:

アクセス頻度の高いデータはオンプレミスにキャッシュされ、低遅延でのデータアクセスが可能です。

ユースケース:

バックアップおよびアーカイブ（Amazon S3 Glacierへの統合が可能）。
オンプレミスとクラウドを統合したファイル共有。

適用例

毎晩のデータエクスポートをAmazon S3に保存し、長期的なバックアップを実現したい場合。

2. ボリュームゲートウェイ (Volume Gateway)

概要

オンプレミスのアプリケーションにブロックストレージを提供し、バックアップやディザスタリカバリのためにデータをクラウドに保存するゲートウェイです。

モード

キャッシュモード:

使用頻度の高いデータをオンプレミスにキャッシュし、その他のデータはAmazon S3に保存。
高効率なストレージ使用を求めるケースに適しています。

ストアモード:

データの完全なコピーをオンプレミスに保存し、クラウドにバックアップします。
アクセス要件が厳しい場合や即時性が求められるデータに適しています。

特徴

プロトコル対応: iSCSI（オンプレミスアプリケーションがストレージをローカルディスクとして認識）。

スナップショット:

Amazon EBSスナップショットとしてクラウドに保存可能。
スナップショットはバックアップや復元、DR対策に活用できます。

ユースケース:

データベースのバックアップ。
ディザスタリカバリの実現。

適用例

オンプレミスのデータをクラウドにバックアップしつつ、ローカルストレージとしても利用したい場合。

比較表

特徴	ファイルゲートウェイ (File Gateway)	ボリュームゲートウェイ (Volume Gateway)
データ形式	ファイル	ブロック
対応プロトコル	SMB/NFS	iSCSI
保存先	Amazon S3（オブジェクト形式）	Amazon S3/EBSスナップショット
ローカルキャッシュ	あり	あり
主なユースケース	ファイル共有、バックアップ	ディスクバックアップ、ディザスタリカバリ

選択のポイント

ファイル共有やアーカイブが目的の場合は「ファイルゲートウェイ」を選択。

ブロックストレージのバックアップやDRが目的の場合は「ボリュームゲートウェイ」を選択。

これらをユースケースに合わせて選ぶことで、コスト効率とパフォーマンスの両立が可能です。

実践

略

一問道場

質問 #231

トピック 1

ある企業は、オンプレミスの Microsoft SQL Server データベースを使用しており、毎晩200 GBのエクスポートをローカルドライブに書き出しています。この企業は、バックアップをより堅牢なAmazon S3のクラウドストレージに移行したいと考えています。

企業は、オンプレミスのデータセンターとAWS間に10 GbpsのAWS Direct Connect接続を設定しています。

どのソリューションが、これらの要件を最もコスト効率よく満たしますか？

選択肢:

A. 新しいS3バケットを作成します。AWS Storage GatewayのファイルゲートウェイをVPC内にデプロイし、Direct Connect接続に接続します。新しいSMBファイル共有を作成し、毎晩のデータベースエクスポートをそのSMBファイル共有に書き込みます。

B. Amazon FSx for Windows File ServerのシングルAZファイルシステムをVPC内に作成し、Direct Connect接続に接続します。新しいSMBファイル共有を作成し、毎晩のデータベースエクスポートをそのSMBファイル共有に書き込みます。毎晩のバックアップを有効にします。

C. Amazon FSx for Windows File ServerのマルチAZファイルシステムをVPC内に作成し、Direct Connect接続に接続します。新しいSMBファイル共有を作成し、毎晩のデータベースエクスポートをそのSMBファイル共有に書き込みます。毎晩のバックアップを有効にします。

D. 新しいS3バケットを作成します。AWS Storage GatewayのボリュームゲートウェイをVPC内にデプロイし、Direct Connect接続に接続します。新しいSMBファイル共有を作成し、そのボリュームゲートウェイ上のSMBファイル共有に毎晩のデータベースエクスポートを書き込みます。このデータをS3バケットに自動コピーするように設定します。

解説

問題の解説

要件

オンプレミスのSQL Serverの200GBのデータエクスポートを、Amazon S3に移行したい。

コスト効率が最優先。

AWS Direct Connect（10 Gbps接続）を利用可能。

選択肢の評価

A (File Gateway - SMBでS3に直接保存)

ファイルゲートウェイを使用し、データを直接Amazon S3に保存する方法。

コスト効率が高い（Amazon S3への直接保存）ため最適解。

B/C (Amazon FSx for Windows File Server)

FSxを使用してファイルを保存後、バックアップする方法。

高コスト（FSxの運用コストがS3より高いため）。

D (Volume Gateway - S3バックアップ)

ボリュームゲートウェイを使用し、ブロックストレージ形式でS3に保存する方法。

複雑でコストが高い（ファイル形式をブロックストレージで扱う必要がない）。

正解: A

理由: ファイルゲートウェイはS3に直接保存でき、コスト効率が最も高い。

232-AWS SAP AWS 「理論・実践・一問道場」AWS Direct Connect

理論

実践

略

一問道場

ある企業は、オンプレミスのデータセンターとAWS間に接続を確立する必要があります。この企業は、異なるAWSリージョンにあるすべてのVPCを接続し、VPC間でトランジティブルーティング機能を提供する必要があります。また、ネットワークのアウトバウンドトラフィックコストを削減し、帯域幅スループットを増加させ、エンドユーザーに一貫したネットワーク体験を提供する必要があります。

どのソリューションがこれらの要件を満たすでしょうか？

A. オンプレミスのデータセンターと新しい中央VPC間にAWS Site-to-Site VPN接続を作成し、中央VPCからすべての他のVPCへのVPCピアリング接続を作成する。

B. オンプレミスのデータセンターとAWS間にAWS Direct Connect接続を作成し、トランジットVIFをプロビジョニングしてDirect Connectゲートウェイに接続し、Direct Connectゲートウェイを通じてすべての他のVPCに接続するために各リージョンでトランジットゲートウェイを使用する。

C. オンプレミスのデータセンターと新しい中央VPC間にAWS Site-to-Site VPN接続を作成し、動的ルーティングを使用したトランジットゲートウェイを作成し、そのトランジットゲートウェイをすべての他のVPCに接続する。

D. オンプレミスのデータセンターとAWS間にAWS Direct Connect接続を作成し、各リージョンのすべてのVPC間にAWS Site-to-Site VPN接続を確立し、中央VPCからすべての他のVPCへのVPCピアリング接続を作成する。

解説

問題の解説

要件:

オンプレミスのデータセンターとAWSを接続。

異なるリージョンのVPC間でトランジティブルーティングを提供。

ネットワークアウトバウンドトラフィックコストの削減、帯域幅の増加、一貫したネットワーク体験の提供。

選択肢の評価:

A (Site-to-Site VPN + VPCピアリング)

複数のVPC接続をVPNで行うが、トランジティブルーティングやコスト削減が難しく、帯域幅も限定的。

B (Direct Connect + トランジットゲートウェイ)

最適解。Direct Connectを使用し、低コストで高速な接続を実現。トランジットゲートウェイを使用して異なるリージョンのVPCを接続。

C (Site-to-Site VPN + トランジットゲートウェイ)

VPNを使用するため、帯域幅やコスト削減が制限される。

D (Direct Connect + Site-to-Site VPN + VPCピアリング)

Direct Connectを使うが、複雑で効率的な接続が難しく、コスト削減が最大化できない。

正解: B

理由: Direct Connectを使用してアウトバウンドトラフィックコストを削減し、トランジットゲートウェイを使って異なるリージョンのVPC間の効率的な接続を実現。

233-AWS SAP AWS 「理論・実践・一問道場」クロスアカウントロール

理論

1. IAMユーザーとIAMロール

IAMユーザー は、AWS内でアクセスできるリソースやアクションを定義する認証情報（アクセスキーやパスワードなど）を持つエンティティです。各ユーザーに特定の権限を割り当てることで、リソースへのアクセスを管理します。

IAMロール は、特定のアクションを実行できる権限を持つ一時的なアクセス権限のセットです。ロールは、他のアカウントやサービスに対してアクセスを許可する際に利用します。

2. クロスアカウントアクセス

クロスアカウントアクセスとは、1つのAWSアカウントから別のAWSアカウントのリソースにアクセスする 仕組みです。この仕組みを使うことで、異なるアカウント間でリソースのアクセスを適切に管理できます。クロスアカウントアクセスを実現するために使われるのが クロスアカウントロール です。

クロスアカウントアクセスを実現するための手順：

信頼ポリシー（Trust Policy）：クロスアカウントロールには、信頼ポリシー を設定する必要があります。信頼ポリシーは、どのアカウントやユーザーがそのロールを「仮定（assume）」できるかを定義するものです。このポリシーにより、どのユーザーがロールを引き受けてアクセスできるかを決定します。

例えば、管理アカウント の IAM ユーザーが 開発アカウント や 本番アカウント にあるリソースにアクセスできるようにするため、管理アカウント内で 信頼ポリシー を使って 各メンバーアカウントのロール を仮定できるように設定します。

仮定（AssumeRole）：IAMユーザーが他のアカウントのロールを仮定すると、そのロールの権限を一時的に得ることができます。この仮定されたロールを使用して、メンバーアカウントのリソースにアクセスできます。

3. 最小権限の原則

AWSでは、ユーザーやロールに対して最小権限の原則を適用することが推奨されます。これは、各ユーザーやロールには、そのタスクを実行するために必要な最小限の権限しか与えないという原則です。これにより、セキュリティリスクを最小化できます。

4. VPC ピアリングとトランジットゲートウェイ

VPCピアリング：異なるVPC間で直接通信を可能にする方法ですが、異なるアカウント間で複数のVPCが存在する場合、トラフィックが直線的に流れるわけではなく、個別に接続を設定する必要があります。

トランジットゲートウェイ：複数のVPCを一元的に接続するための AWS のサービスで、異なるアカウントの VPC間で トランジットルーティング を使用し、より効率的な接続を実現します。特に、多数の VPC が存在する場合、トランジットゲートウェイを利用することで、ネットワークの管理が容易になります。

5. AWS Organizations と Consolidated Billing

AWS Organizations は、複数のAWSアカウントを管理するためのサービスです。これを使うことで、複数のアカウントを1つの組織としてまとめ、コストの集約やアクセス管理を効率化できます。

Consolidated Billing は、複数のAWSアカウントの請求を一元化する仕組みで、複数アカウントのコストを管理しやすくします。

実践

略

一問道場

ある企業が、開発と本番のワークロードをAWS Organizations内の新しい組織に移行しています。企業は、開発用の別のメンバーアカウントと本番用の別のメンバーアカウントを作成しました。統合請求は管理アカウントにリンクされています。管理アカウント内で、ソリューションアーキテクトは、両方のメンバーアカウントでリソースを停止または終了できるIAMユーザーを作成する必要があります。

どのソリューションがこの要件を満たしますか？

A. 管理アカウントでIAMユーザーとクロスアカウントロールを作成します。クロスアカウントロールにメンバーアカウントへの最小権限アクセスを設定します。

B. 各メンバーアカウントでIAMユーザーを作成します。管理アカウントで最小権限アクセスを持つクロスアカウントロールを作成します。信頼ポリシーを使用してIAMユーザーにクロスアカウントロールへのアクセスを付与します。

C. 管理アカウントでIAMユーザーを作成します。メンバーアカウントで最小権限アクセスを持つIAMグループを作成します。管理アカウントのIAMユーザーを各メンバーアカウントのIAMグループに追加します。

D. 管理アカウントでIAMユーザーを作成します。メンバーアカウントで最小権限アクセスを持つクロスアカウントロールを作成します。信頼ポリシーを使用してIAMユーザーにこれらのロールへのアクセスを付与します。

解説

選択肢 D では、クロスアカウントロールをメンバーアカウントに作成し、そのロールに対して信頼ポリシーを設定して、管理アカウントの IAM ユーザーがそのロールを「仮定」できるようにします。

クロスアカウントロールはメンバーアカウントに作成します。

信頼ポリシーで、管理アカウントの IAM ユーザーをロールの信頼エンティティとして設定します。

これにより、管理アカウントの IAM ユーザーがメンバーアカウント内のリソースにアクセスして操作できます。

234-AWS SAP AWS 「理論・実践・一問道場」RPO

理論

1. 災害復旧（Disaster Recovery, DR）の基本概念

災害復旧は、システム障害や自然災害などの影響で業務が停止した場合に、重要なデータとアプリケーションを迅速に復旧させるプロセスです。DR計画では、復旧時間目標（RTO: Recovery Time Objective）と復旧ポイント目標（RPO: Recovery Point Objective）**を定義し、これらに基づいて最適なソリューションを選択します。

RTO: システム障害が発生してから復旧作業を完了するまでの時間。

RPO: 障害が発生する前の時点からどれだけのデータを復旧できるか。

2. AWSでの災害復旧ソリューション

AWSには、災害復旧を実現するためのさまざまなサービスが提供されています。特に重要なものは次の通りです：

AWS Elastic Disaster Recovery (DRS): オンプレミスのサーバーやVMをAWSにレプリケーションし、災害発生時に自動的にフェイルオーバーするサービスです。フェイルバックも簡単に行え、RTOとRPOの要件を満たしやすいです。

AWS Storage Gateway: オンプレミスとAWSクラウド間でデータのバックアップと復元を行うためのサービス。ファイルゲートウェイやボリュームゲートウェイを使用して、データをS3やEBSに保存し、災害時に復元できますが、フェイルオーバー機能は限られています。

AWS DataSync: 高速かつ効率的にデータをAWSストレージに転送するサービス。大量のデータを短時間で移行でき、EFSやFSx for Windows File Serverといったサービスと組み合わせて使用されます。

3. 冗長性と可用性

アクティブ-アクティブ構成: 2つのデータセンター（またはAWSリージョン）で両方が稼働しており、システム全体が冗長化されている状態。災害時には自動的にフェイルオーバーし、ダウンタイムを最小限に抑えます。

アクティブ-パッシブ構成: 主に一方が稼働し、バックアップ用に待機しているシステム構成。災害時に切り替えることで復旧します。

4. データの同期とフェイルオーバー

データレプリケーション: データの同期と複製は、DRの要となります。レプリケーションによって、災害時に即座にデータを復元できるようにすることが求められます。

フェイルオーバーとフェイルバック: システムがダウンした際にAWS環境にシームレスに移行し、復旧後にオンプレミスに戻す（フェイルバック）仕組みが重要です。Elastic Disaster RecoveryやCloudFormation、AWS CDKなどを用いて、これを自動化することが可能です。

結論：

災害復旧の要件（RTO、RPO）に対応するためには、AWS Elastic Disaster Recoveryが最も効率的でコスト効果の高い選択肢です。データの高速レプリケーションと自動フェイルオーバー、フェイルバック機能を提供し、最小限の手動作業で災害復旧を実現できます。

実践

略

一問道場

問題 #234

トピック 1

ある企業は、オンプレミスアプリケーションのためにAWSを災害復旧の目的で使用したいと考えています。この企業には、アプリケーションを実行する数百台のWindowsサーバーがあります。すべてのサーバーは共通の共有ディスクをマウントしています。

この企業の目標復旧時間（RTO）は15分、目標復旧ポイント（RPO）は5分です。ソリューションは、ネイティブなフェイルオーバーおよびフェイルバック機能をサポートする必要があります。

どのソリューションが最もコスト効果が高いか？

A. AWS Storage Gatewayのファイルゲートウェイを作成し、Windowsサーバーのバックアップを毎日スケジュールします。データをAmazon S3に保存します。災害時には、バックアップからオンプレミスサーバーを復元します。フェイルバック時には、オンプレミスのサーバーをAmazon EC2インスタンスで実行します。

B. AWS CloudFormationのテンプレートを作成し、インフラを構築します。AWS DataSyncを使用して、データをAmazon Elastic File System（Amazon EFS）に複製します。災害時には、AWS CodePipelineを使用してテンプレートをデプロイし、オンプレミスサーバーを復元します。データのフェイルバックはDataSyncを使用します。

C. AWS Cloud Development Kit（AWS CDK）パイプラインを作成して、AWS上にマルチサイトのアクティブ-アクティブ環境を構築します。s3 syncコマンドを使用して、データをAmazon S3に複製します。災害時には、DNSエンドポイントをAWSに切り替えます。データのフェイルバックは、s3 syncコマンドを使用して行います。

D. AWS Elastic Disaster Recoveryを使用してオンプレミスサーバーを複製します。AWS DataSyncを使用してデータをAmazon FSx for Windows File Serverファイルシステムに複製します。ファイルシステムをAWSサーバーにマウントします。災害時には、オンプレミスサーバーをAWSにフェイルオーバーします。フェイルバックはElastic Disaster Recoveryを使用して、新しいまたは既存のサーバーに行います。

解説

この問題では、災害復旧の要件（RTO: 15分、RPO: 5分）を満たすために、最もコスト効率の良いソリューションを選ぶ必要があります。

選択肢Dが最も適しています。理由は、AWS Elastic Disaster Recoveryを使用することで、オンプレミスのサーバーをAWSにレプリケーションし、災害発生時に迅速にフェイルオーバーできます。さらに、フェイルバック機能も備えており、復旧後に新しいサーバーや既存のサーバーに戻すことができます。この方法は、RTOとRPOの要件を満たし、効率的な災害復旧を提供します。

他の選択肢は、フェイルオーバーやデータの同期が自動化されていないか、要件を満たすために複雑すぎるため、最適ではありません。

235-AWS SAP AWS 「理論・実践・一問道場」EFA

理論

1. Elastic Fabric Adapter (EFA)

EFAは、低遅延かつ高帯域幅のネットワーク通信を提供するために、EC2インスタンスで使用されるネットワークインターフェースです。特にHPCや分散処理ワークロードで重要です。

EFAを使用することで、インスタンス間通信が劇的に改善され、スケールを拡張してもパフォーマンスが向上します。

EC2インスタンスタイプでEFAを有効にすることがパフォーマンス向上の鍵です。

2. Amazon FSx for Lustre

Lustreは、HPCワークロードに最適化された並列ファイルシステムです。EFSは一般的なファイルストレージですが、大規模な並列アクセスや高い帯域幅が求められるHPCワークロードでは、FSx for Lustreが適しています。

FSx for Lustreは、パフォーマンスが非常に高く、複雑な計算や大量のデータを高速に処理するために最適化されています。これにより、EC2インスタンスのスケーリング時にもパフォーマンスを維持できます。

3. 高可用性とスケーラビリティの確保

HPCクラスタは、複数のアベイラビリティゾーンにまたがって配置することで、冗長性と可用性を確保し、クラスタ全体の耐障害性を向上させます。単一のアベイラビリティゾーンに依存することは、スケールアップや障害発生時にリスクを伴います。

EC2インスタンスのネットワークインターフェースやストレージのスケーラビリティを考慮した設計が必要です。

4. EBSのRAID構成

3. RAID構成の選択肢

RAID0: 高速化を重視する場合に使用（冗長性なし）。

RAID1: データの冗長性を確保しながらパフォーマンスを維持。

RAID5: 複数のボリュームを使ってストライピングとパリティを組み合わせ、冗長性を保ちつつ、効率的にディスクスペースを使用します。

注意点

RAID構成をEBSで使用する場合、パフォーマンス向上のために複数のEBSボリュームを使用します

実践

略

一問道場

ある会社が、AWS上で緊密に結合されたワークロードのために高性能コンピューティング（HPC）クラスタを構築しました。このワークロードは、Amazon EFSに保存された多数の共有ファイルを生成します。クラスタは、EC2インスタンスの数が100の時には良好に動作していました。しかし、クラスタサイズを1,000 EC2インスタンスに増やしたところ、全体的なパフォーマンスが期待以下となりました。

HPCクラスタから最大のパフォーマンスを引き出すために、ソリューションアーキテクトが行うべき設計の選択肢はどれですか？（3つ選んでください。）

A. HPCクラスタを単一のアベイラビリティゾーン内で起動することを確認する。

B. EC2インスタンスを起動し、4つのエラスティックネットワークインターフェース（ENI）を複数でアタッチする。

C. Elastic Fabric Adapter（EFA）が有効になっているEC2インスタンスタイプを選択する。

D. クラスタが複数のアベイラビリティゾーンにまたがって起動することを確認する。

E. Amazon EFSを複数のAmazon EBSボリュームのRAIDアレイに置き換える。

F. Amazon EFSをAmazon FSx for Lustreに置き換える。

解説

A. 単一のアベイラビリティゾーンにHPCクラスターを配置する

HPCワークロードでは、低レイテンシが重要です。クラスターが単一のアベイラビリティゾーンに配置されている場合、ネットワーク遅延が最小化され、パフォーマンスが向上する可能性があります。

C. EFA（Elastic Fabric Adapter）を有効にしたEC2インスタンスタイプを選択する

EFAは、高速で低レイテンシのネットワークを提供する専用ハードウェアです。これにより、大規模なHPCクラスターで必要な高帯域幅と低レイテンシが確保でき、パフォーマンスが大幅に向上します。

F. Amazon EFSをAmazon FSx for Lustreに置き換える

Amazon FSx for Lustreは、高パフォーマンスな並列ファイルシステムで、HPCワークロードに最適です。EFSよりも高いパフォーマンスを提供し、大規模なファイル処理が必要なシナリオにおいて優れた選択肢です。

なぜこれらが正解か

A: 単一のAZに配置することで、EC2インスタンス間の通信が高速になります。

C: EFAを使うことで、EC2インスタンス間のネットワーク通信が大幅に向上します。

F: FSx for LustreはHPCに適した高パフォーマンスのファイルシステムで、EFSよりも高いパフォーマンスを提供します。

これらの選択肢は、クラスタのパフォーマンス向上に直結し、HPCワークロードに必要な性能を引き出すことができます。

236-AWS SAP AWS 「理論・実践・一問道場」拒否ポリシー

理論

明示的な「拒否」ポリシーが設定されていない場合、デフォルトでは許可される。

もしSCPで**「拒否」**が設定されていれば、その拒否は組織全体に適用され、下位アカウントやリソースでもその操作は行えません。

もし 管理アカウント（ルートアカウント） で「全て拒否」のSCPを設定すると、その拒否は組織全体に適用されます。下位のメンバーアカウントやOUで許可のポリシーを設定しても、拒否ポリシーが優先されて、その操作は実行できません。

例：

ルートアカウント に「全て拒否」のSCPを設定 → すべての操作が拒否されます。

メンバーアカウント に「特定の操作を許可」のSCPを設定 → ルートアカウントの拒否が優先されるため、その操作は実行できません。

つまり、SCPで「拒否」を設定すると、それが優先され、下位での「許可」は無効になります。

AWS Organizationsにおけるタグ管理とポリシー適用の基本的な知識:

AWS Organizations:

複数のAWSアカウントを一元管理するサービス。

組織単位（OU）を使用してアカウントを階層的にグループ化し、各OUにポリシーを適用できる。

タグポリシー:

AWSリソースにタグを標準化して適用するためのルール。

タグの値や名前を指定して、リソース作成時にタグを必須にしたり、特定の値を要求することができる。

サービス制御ポリシー（SCP）:

AWS Organizations内でアカウントに適用するアクセス制御ポリシー。

リソース作成時に必要なタグが欠けている場合の制限を加えることができる。

リソース作成時のタグ要求:

リソース作成時にタグを必須にしたり、特定のタグ値を要求する場合、タグポリシーとSCPを組み合わせて設定する。

OUごとに異なるタグ値を要求する場合、各OUに対して異なるタグポリシーを適用する。

最適なアプローチ:

タグポリシーで各OUに対するタグの要件を定義し、SCPでタグなしでリソースを作成できないように制限することが最も効果的な方法です。

拒否ポリシーは常に許可ポリシーより優先されます。もしある操作を確実に禁止したい場合は、明示的に拒否するポリシーを使うことが重要です。

つまり、AWSでは「拒否」が「許可」よりも強い力を持っているということです。

実践

略

一問道場

質問 #236

トピック 1

ある会社がAWS Organizationsの構成を設計しています。この会社は、組織全体でタグを適用するプロセスを標準化したいと考えています。新しいリソースを作成する際に、特定の値を持つタグが必要になります。会社の各OU（組織単位）にはユニークなタグ値があります。

どのソリューションがこれらの要件を満たしますか？

A. SCP（サービス制御ポリシー）を使用して、必要なタグがないリソースの作成を拒否します。会社が各OUに割り当てたタグ値を含むタグポリシーを作成し、そのタグポリシーをOUに適用します。

B. SCPを使用して、必要なタグがないリソースの作成を拒否します。会社が各OUに割り当てたタグ値を含むタグポリシーを作成し、そのタグポリシーを組織の管理アカウントに適用します。

C. SCPを使用して、リソースに必要なタグがある場合のみ作成を許可します。会社が各OUに割り当てたタグ値を含むタグポリシーを作成し、そのタグポリシーをOUに適用します。

D. SCPを使用して、必要なタグがないリソースの作成を拒否します。タグのリストを定義し、そのSCPをOUに適用します。

解説

この問題では、AWS Organizationsを使って、組織内でリソース作成時に特定のタグを適用するプロセスを標準化する方法を尋ねています。目標は、ユーザーが新しいリソースを作成する際に、リソースに必ず特定のタグが付与されることを保証することです。さらに、各組織単位（OU）ごとに異なるタグの値を設定する必要があります。

選択肢の分析:

A: SCPを使用してタグがないリソースの作成を拒否し、タグポリシーでOUごとに異なるタグの値を定義します。このタグポリシーはOUに適用されるため、要求に合っています。

B: SCPでリソースの作成時にタグを要求するという点は正しいですが、タグポリシーが組織の管理アカウントに適用されるため、OUごとに異なるタグ値を管理することができません。管理アカウントに適用する方法は不適切です。

C: SCPでリソース作成時にタグが必要だと許可する方法は誤りです。タグがないリソースを作成することを拒否する必要があり、許可するのは逆効果です。また、タグポリシーがOUに適用されるのは正しいですが、SCPの設定が間違っています。

D: SCPでタグがないリソースを作成することを拒否し、タグポリシーでタグの一覧を定義するのは部分的に正しいですが、タグポリシーがOUごとに異なるタグ値を設定するという要件を満たしていません。タグの一覧を指定するだけでは十分ではありません。

正解: A

SCPを使用してタグが付いていないリソースの作成を拒否し、タグポリシーを使用して各OUに適切なタグ値を要求することが最も効果的であり、要件に最適です。

237-AWS SAP AWS 「理論・実践・一問道場」MQTTプロトコル

理論

1. AWS IoT Core

機能：

AWS IoT Core は、IoTデバイス（例：センサー）から送られてくるデータを処理するための完全マネージドサービスです。

MQTTプロトコルをネイティブでサポートしており、センサーからのデータを直接受信できます。

高可用性とスケーラビリティを提供し、デバイスの増加やネットワークの不安定さがあってもデータを失わないようにします。

このソリューションでの役割：

センサーからMQTTプロトコルを使用して送られるデータを受信。

受信したデータを Kinesis Data Firehose に転送。

2. Amazon Kinesis Data Firehose

機能：

Kinesis Data Firehose は、リアルタイムデータストリームを処理・転送するための完全マネージドサービスです。

データを Amazon S3、Amazon Redshift、Amazon Elasticsearch Service などのターゲットストレージに送ることができます。

データ形式の変換やバッチ処理をサポートしています。

例での役割：

AWS IoT Core からデータを受け取り、Amazon S3 などのターゲットに信頼性を持って送信。

高い耐障害性を提供し、データの紛失を防ぎます。

3. AWS Lambda

機能：

AWS Lambda は、イベント駆動型のサーバーレスコンピューティングサービスで、コードを実行してデータを処理することができます。

データの形式変換、クリーニング、分析など、カスタムロジックを柔軟に実装可能です。

必要なときだけ実行されるため、コスト効率が高い。

このソリューションでの役割：

Kinesis Data Firehose にデータを送信する前に、AWS IoT Core から受信したデータを処理。

データ形式の変換やメタデータの追加を行い、ターゲットに適した形に整えます。

4. Amazon S3

機能：

Amazon S3 は、オブジェクトストレージサービスで、データを安全かつ長期的に保存することができます。

高い耐久性と冗長性を備えており、データの安全性を確保します。

このソリューションでの役割：

センサーから送られてきたデータの最終的な保存先として機能。

保存されたデータは、後で分析やアーカイブに利用可能。

全体の流れ：

センサーがデータを送信：センサーは MQTTプロトコル を使ってデータを AWS IoT Core に送信。

AWS IoT Coreがデータを転送：受信したデータを Kinesis Data Firehose に渡す。

データ変換：Kinesis Data Firehoseが AWS Lambda をトリガーしてデータを変換・処理。

データ保存：変換後のデータを Amazon S3 に安全に保存。

まとめ：

AWS IoT Core：デバイスデータの受信。

Kinesis Data Firehose：データを信頼性をもって転送。

AWS Lambda：データの変換・加工。

Amazon S3：最終的なデータの保存と管理。

実践

略

一問道場

質問 #237

トピック 1

ある企業が、10,000以上のセンサーを所有しており、これらのセンサーはMessage Queuing Telemetry Transport (MQTT) プロトコルを使用してオンプレミスのApache Kafkaサーバーにデータを送信しています。Kafkaサーバーはデータを変換し、その結果をAmazon S3バケットにオブジェクトとして保存します。最近、Kafkaサーバーがクラッシュし、サーバーの復旧中にセンサーデータを失いました。ソリューションアーキテクトは、高可用性でスケーラブルな新しいAWS上の設計を作成し、同様の問題が再発しないようにする必要があります。

以下のどのソリューションがこれらの要件を満たしますか？

A. 2つのAmazon EC2インスタンスを起動して、Kafkaサーバーを2つのアベイラビリティゾーンにまたがるアクティブ/スタンバイ構成でホストします。Amazon Route 53でドメイン名を作成し、Route 53のフェイルオーバーポリシーを作成します。センサーがデータをそのドメイン名に送信するようにルーティングします。

B. オンプレミスのKafkaサーバーをAmazon Managed Streaming for Apache Kafka (Amazon MSK) に移行します。Amazon MSKブローカーを指すNetwork Load Balancer (NLB) を作成します。NLBのヘルスチェックを有効にします。センサーがデータをNLBに送信するようにルーティングします。

C. AWS IoT Coreをデプロイし、それをAmazon Kinesis Data Firehose配信ストリームに接続します。データ変換を処理するAWS Lambda関数を使用します。センサーがAWS IoT Coreにデータを送信するようにルーティングします。

D. AWS IoT Coreをデプロイし、KafkaサーバーをホストするためのAmazon EC2インスタンスを起動します。AWS IoT Coreを設定してデータをそのEC2インスタンスに送信します。センサーがAWS IoT Coreにデータを送信するようにルーティングします。

解説

正解は C. AWS IoT Coreをデプロイし、それをAmazon Kinesis Data Firehose配信ストリームに接続します。データ変換を処理するAWS Lambda関数を使用します。センサーがAWS IoT Coreにデータを送信するようにルーティングします。

解説

この選択肢が適切である理由は以下の通りです。

高可用性

AWS IoT Coreは完全マネージドサービスであり、高可用性とスケーラビリティを提供します。オンプレミスのKafkaサーバーのクラッシュによる問題を回避できます。

MQTTプロトコル対応

AWS IoT CoreはMQTTプロトコルをネイティブにサポートしており、センサーからのデータ送信を容易に処理できます。

スケーラビリティ

IoT CoreとKinesis Data Firehoseを使用することで、センサーデータの増加にスケーラブルに対応可能です。

データ変換の柔軟性

AWS Lambdaを使用してKinesis Data Firehoseの前処理または後処理としてデータを変換できます。これにより、現在のKafkaサーバーが行っているデータ変換機能を代替できます。

信頼性と耐障害性

Kinesis Data Firehoseは信頼性の高いデータ配信サービスであり、Amazon S3へのデータ保存が保証されます。

他の選択肢について

A: KafkaサーバーをEC2インスタンスでホストする場合、管理負荷が増加し、完全な耐障害性やスケーラビリティが保証されません。

B: Amazon MSKはKafkaのマネージドサービスで高可用性を提供しますが、センサーがMQTTプロトコルを使用しているため、直接接続が困難です。追加のプロトコル変換が必要になります。

D: IoT CoreとEC2上のKafkaを組み合わせる構成は、Kafkaの管理負荷が再び発生するため、根本的な問題解決にはなりません。

以上より、Cが最適なソリューションです。

238-AWS SAP AWS 「理論・実践・一問道場」AWS Backup

理論

1. AWS Backup

AWS Backup は、AWS上でバックアップを一元管理するサービスです。複数のサービス（Amazon EC2、Amazon RDS、Amazon EFSなど）に対して、バックアップ計画を自動的に設定できます。これにより、バックアップのスケジュール、保持、復元を簡単に管理できます。

バックアップ計画（Backup Plan）を作成し、特定の保持期間（日次、週次、月次）に基づいてバックアップを保存します。
バックアップのコピー機能を利用して、バックアップを別のリージョンに複製できます。これにより、災害復旧の要件を満たすことができます。

2. AWS SNS（Simple Notification Service）

Amazon SNSは、通知サービスで、バックアップジョブのステータスを監視し、失敗時に通知を受け取るために使用されます。SNSは、AWS Backupのバックアップ計画と連携して、バックアップ処理が正常に完了したかどうかを確認し、問題が発生した場合に通知を送信します。

3. AWS Lambda

AWS Lambdaは、イベント駆動型でカスタム処理を実行できるサーバーレスコンピューティングサービスです。バックアップの失敗時に特定のアクション（通知やログ保存）を実行するカスタムコードを実行するために使用できます。ただし、AWS BackupやSNSの機能で十分に対応できる場合、Lambdaを使用する必要はなく、運用の手間が増える可能性があります。

4. バックアップ保持とスケジュール

企業のバックアップ要件に合わせて、バックアップの保持期間（例えば、日次、週次、月次）を設定し、それに基づいた自動バックアップを実行することが重要です。AWS Backupを使用すると、バックアップルール（Retention Rules）を設定して、特定の期間データを保持できます。

5. 災害復旧と冗長性

重要なデータのバックアップは、リージョン間冗長性を持つことが推奨されます。バックアップを1つのリージョンに保存するだけでなく、災害が発生した場合に備えて別のリージョンにバックアップをコピーすることで、データの損失リスクを軽減します。

実践

略

一問道場

質問 #238

トピック 1

ある企業が最近、AWSクラウドで新しいアプリケーションワークロードのホスティングを開始しました。この企業は、Amazon EC2インスタンス、Amazon Elastic File System（Amazon EFS）ファイルシステム、およびAmazon RDS DBインスタンスを利用しています。

規制およびビジネス要件を満たすために、データバックアップについて以下の変更を行う必要があります：

バックアップは、カスタムの日次、週次、および月次要件に基づいて保持される必要があります。

バックアップは取得後すぐに少なくとももう1つのAWSリージョンに複製される必要があります。

バックアップソリューションは、AWS環境全体でバックアップステータスの一元的な情報を提供する必要があります。

バックアップリソースが失敗した場合は、即時通知を送信する必要があります。

以下の手順の組み合わせで、最小限の運用負荷でこれらの要件を満たすものはどれですか？（3つ選択してください）

A. カスタムの保持要件ごとにバックアップルールを含むAWS Backupプランを作成する。

B. AWS Backupプランを設定して、バックアップを別のリージョンにコピーするようにする。

C. AWS Lambda関数を作成して、バックアップを別のリージョンに複製し、失敗が発生した場合に通知を送信する。

D. バックアッププランにAmazon Simple Notification Service（Amazon SNS）トピックを追加し、BACKUP_JOB_COMPLETED以外のステータスを持つ完了ジョブについて通知を送信する。

E. カスタムの保持要件ごとにAmazon Data Lifecycle Manager（Amazon DLM）のスナップショットライフサイクルポリシーを作成する。

F. 各データベースでRDSスナップショットを設定する。

解説

この問題の解説を以下に行います。目標は、最小限の運用負荷で要求されたバックアップ要件を満たすことです。問題におけるバックアップ要件は次のとおりです：

バックアップ保持要件：バックアップは日次、週次、月次のカスタム保持要件に従って保持される必要があります。

バックアップのリージョン間複製：バックアップは、取得後すぐに少なくとも1つの他のAWSリージョンに複製される必要があります。

バックアップステータスの一元管理：バックアップの状態は、AWS環境全体で一元的に管理され、モニタリングされる必要があります。

バックアップ失敗時の通知：バックアップ失敗が発生した場合、即時に通知が送信される必要があります。

これらの要件に基づいて、各選択肢を見ていきます。

A. AWS Backupプランを作成し、バックアップルールを設定する

解説: AWS Backupを使ってバックアップのスケジュールと保持ルールを設定することができます。これにより、日次、週次、月次の保持要件を簡単に管理できます。この選択肢は要件を満たしており、バックアップのスケジュールを最小限の操作で自動化できます。

適合性: 必要（バックアップの保持とスケジュール管理）

B. AWS Backupプランを設定して、バックアップを別のリージョンにコピー

解説: AWS Backupには、バックアップを他のAWSリージョンにコピーするオプションがあります。これにより、バックアップデータの冗長性と災害復旧の要件を満たすことができます。バックアップのリージョン間複製が求められているため、このステップは重要です。

適合性: 必要（リージョン間バックアップの複製）

C. AWS Lambda関数を作成して、バックアップを別リージョンに複製し、通知を送信する

解説: AWS Lambdaはサーバーレスのコンピューティングサービスで、カスタムバックアップ処理を自動化するために使用できます。バックアップの失敗時に通知を送信するなどのカスタムアクションを実行することができますが、AWS Backupサービスに含まれる機能でカバーできるため、運用負荷が高くなる可能性があります。

適合性: 不必要（AWS Backupで済む機能をLambdaで実装するのは過剰）

D. Amazon SNSトピックをバックアッププランに追加して、バックアップ完了通知を送信する

解説: Amazon SNSは、バックアップの完了や失敗に関する通知を送るために使用されます。AWS BackupにはSNS通知を設定するオプションがあり、バックアップジョブのステータスに基づいて通知を送信できます。これはバックアップの監視とエラー通知に最適です。

適合性: 必要（バックアップ失敗時の通知）

E. Amazon Data Lifecycle Manager（DLM）スナップショットライフサイクルポリシーを作成する

解説: Amazon DLMは、EBSスナップショットを管理するためのサービスです。しかし、問題文で示されているバックアップ対象はEC2インスタンス、EFS、RDSといった異なるサービスにまたがっており、DLMは主にEBSボリュームのバックアップに適しています。したがって、DLMはこのケースでは適切ではありません。

適合性: 不必要（EBSバックアップ専用）

F. RDSスナップショットを設定する

解説: RDSスナップショットは、RDSデータベースのバックアップを管理するために使用できます。RDSインスタンスに関連するバックアップ要件には役立ちますが、問題ではEC2やEFSなど他のリソースも対象であり、全体的なバックアップ戦略にはRDSだけでは対応できません。

適合性: 不完全（RDSのみ対応）

最適な解答:

A: AWS Backupを使用してバックアップ計画を作成することで、スケジュールと保持要件を管理。

B: AWS Backupプランを設定して、バックアップを別リージョンにコピー。

D: Amazon SNSを使って、バックアップの状態に基づいた通知を送信。

これらの選択肢が最小限の運用負荷で要件を満たし、効率的なバックアップ管理を実現します。

239-AWS SAP AWS 「理論・実践・一問道場」Amazon Kinesis Data Streams

理論

実例

目的

遺伝子情報を収集するデバイスから送信される膨大なデータをリアルタイムで処理し、分析結果をデータウェアハウスに保存するシステムを構築する。

データの流れと処理のステップ

データ収集:

オンプレミスシステム（センサーデバイス）から、Amazon Kinesis Data Streamsに対してリアルタイムでデータを送信します。

このデータは、1秒間に8KBの遺伝子データが送信されるという前提です。

データ分析:

Kinesisクライアント（例えば、AWS SDKやKinesis Client Library（KCL））を使用して、Kinesis Data Streamsに送られたデータをリアルタイムで取得し、分析します。

分析の内容としては、データの変換、集約、フィルタリングなどが考えられます。

データ処理（分散処理）:

Amazon EMR（Elastic MapReduce）を使用して、Kinesis Data Streamsから取得したデータをさらに高度な処理を行います。EMRは、HadoopやApache Sparkを利用して、大量のデータを並列処理するためのプラットフォームです。

ここでは、データの集約、解析、機械学習モデルの適用など、複雑な処理を行います。

結果の保存:

Amazon Redshift（データウェアハウス）に、処理されたデータや分析結果を保存します。

Redshiftは、大量のデータを効率的に格納し、高速でクエリを実行できるため、分析後のデータを管理するために最適です。

まとめた流れ

オンプレミスデバイス → Kinesis Data Streams

センサーがリアルタイムでデータをKinesis Data Streamsに送信。

Kinesisクライアント → データ分析

Kinesisクライアントがデータをリアルタイムで処理・分析。

EMR → 高度なデータ処理

Amazon EMRを使用して、大規模なデータの分散処理や複雑な計算を実行。

Amazon Redshift → 結果保存

処理結果をAmazon Redshiftに格納し、後でクエリや分析を行う。

この流れで、リアルタイムで遺伝子情報データを効率的に収集・処理・保存でき、研究者がデータ分析結果を迅速に活用できるようになります。

実践

略

一問道場

問題 #239 トピック 1

ある企業が、研究者が多様な集団から大規模なデータサンプルを収集するのを支援するための遺伝子報告デバイスを開発しています。このデバイスは、毎秒8KBの遺伝子データをデータプラットフォームに送信し、そのデータを処理・分析して研究者に情報を提供する必要があります。データプラットフォームは以下の要件を満たす必要があります：

受信した遺伝子データのほぼリアルタイムでの分析を提供する

データは柔軟で、並列的で、耐久性があることを保証する

処理結果をデータウェアハウスに提供する

ソリューションアーキテクトがこれらの要件を満たすために使用すべき戦略はどれですか？

A. Amazon Kinesis Data Firehoseを使用して受信したセンサーデータを収集し、Kinesisクライアントでデータを分析し、その結果をAmazon RDSインスタンスに保存する

B. Amazon Kinesis Data Streamsを使用して受信したセンサーデータを収集し、Kinesisクライアントでデータを分析し、その結果をAmazon Redshiftクラスターに保存するためにAmazon EMRを使用する

C. Amazon S3を使用して受信したデバイスデータを収集し、Amazon SQSからKinesisでデータを分析し、その結果をAmazon Redshiftクラスターに保存する

D. Amazon API Gatewayを使用してリクエストをAmazon SQSキューに入れ、AWS Lambda関数でデータを分析し、その結果をAmazon Redshiftクラスターに保存するためにAmazon EMRを使用する

解説

この問題では、センサーデバイスからのリアルタイムデータを収集し、分析結果をデータウェアハウスに保存するシステムの設計について問われています。

解答Bの解説:

Amazon Kinesis Data Streamsを使ってリアルタイムでセンサーデータを収集。

Kinesisクライアントを使用してデータをリアルタイムで分析。これにより、ストリーミングデータを処理できます。

Amazon EMRは、さらに高度なデータ処理を行うために使用され、結果をAmazon Redshiftに保存します。

この構成は、要求されているリアルタイムのデータ分析と耐久性を確保し、分析結果をRedshiftに保存する要件を満たします。

240-AWS SAP AWS 「理論・実践・一問道場」3層アプリケーション

理論

3層アプリケーションとは、典型的に以下のように分離されたアーキテクチャを指します。具体的な技術スタック（例: Apache, Python, MySQL）は利用する環境によりますが、基本的な構成は以下の通りです。

1. プレゼンテーション層（Web層）

役割: ユーザーがアプリケーションと対話するインターフェースを提供します。

例:

ApacheやNginx: Webサーバー
フロントエンドフレームワーク: HTML, CSS, JavaScript, React, Angularなど

動作: ユーザーリクエストを受け取り、アプリケーション層に渡す。

2. アプリケーション層（ビジネスロジック層）

役割: アプリケーションのビジネスロジックや処理を担当します。

例:

Python: Django, Flaskなど
Java: Spring Framework
Node.js: Expressなど

動作: プレゼンテーション層からのリクエストを処理し、データ層とやり取りする。

3. データ層（データベース層）

役割: データの保存、取得、更新を担当します。

例:

MySQL, PostgreSQL: リレーショナルデータベース
MongoDB, DynamoDB: NoSQLデータベース

動作: アプリケーション層から受け取ったクエリを処理し、必要なデータを返す。

3層アプリケーションの特長

スケーラビリティ: 各層を個別に拡張可能。

モジュール性: 各層が独立しており、変更が容易。

高可用性: 層ごとに冗長化を行える。

具体例: Apache + Python + MySQL

この技術スタックで3層アーキテクチャを実装すると以下のようになります。

プレゼンテーション層: Apacheがリクエストを受け取る。

アプリケーション層: Python（DjangoやFlask）がロジックを処理。

データ層: MySQLがデータを管理。

ただし、現代のシステムではこれらの技術スタックに限らず、AWSサービス（例: API Gateway, Lambda, DynamoDB）や他のフレームワークも利用されます。

AWSでの高可用性と災害復旧の重要ポイント

高可用性の設計

Auto Scalingグループ + 複数AZ: アプリケーションやウェブサーバーを複数AZに展開して障害に備える。

予約インスタンス + オンデマンドインスタンス: コストと柔軟性を両立。

迅速な災害復旧（DR）

DynamoDBグローバルテーブル: リージョン間でデータを自動レプリケーションし、高速な切り替えを実現。

Route 53フェイルオーバー: TTLを短く設定（例: 30秒）して自動切り替えを迅速化。

効率的なデータレプリケーション

S3クロスリージョンレプリケーション: 静的データやバックアップの効率的なレプリケーション。

RDSリードレプリカ: 他リージョンでのDBデータ保持と迅速な昇格。

コスト効率とパフォーマンスのバランス

必要最低限のインスタンスは予約、急激な増加にはオンデマンドまたはスポットインスタンスで対応。

ベストプラクティス

DynamoDBグローバルテーブル + Route 53: 迅速なフェイルオーバーが必要なシナリオに最適。

S3やRDSのレプリケーション: コスト効率を重視したバックアップ設計に有効。

実践

略

一問道場

質問 #240

トピック 1

ソリューションアーキテクトは、Web、アプリケーション、NoSQLデータの3層アプリケーション向けの参照アーキテクチャを定義する必要があります。この参照アーキテクチャは、次の要件を満たさなければなりません：

AWSリージョン内での高可用性

災害復旧のために1分以内に別のAWSリージョンにフェイルオーバー可能

ユーザーエクスペリエンスへの影響を最小限に抑えつつ、最も効率的なソリューションを提供

以下のステップの組み合わせでこれらの要件を満たすものを選択してください（3つ選択）。

A. 2つの選択されたリージョン間でAmazon Route 53の加重ルーティングポリシーを使用し、比率を100/0に設定する。TTL（Time to Live）は1時間に設定する。

B. Amazon Route 53のフェイルオーバールーティングポリシーを使用して、プライマリリージョンから災害復旧リージョンへのフェイルオーバーを設定する。TTLは30秒に設定する。

C. Amazon DynamoDBのグローバルテーブルを使用して、2つの選択されたリージョンでデータにアクセスできるようにする。

D. プライマリリージョンのAmazon DynamoDBテーブルから60分ごとにデータをバックアップし、そのデータをAmazon S3に書き込む。S3のクロスリージョンレプリケーションを使用して、データをプライマリリージョンから災害復旧リージョンにコピーする。災害復旧シナリオでは、スクリプトを使用してDynamoDBにデータをインポートする。

E. ホットスタンバイモデルを実装し、複数のアベイラビリティゾーンにまたがるリージョンで、Web層とアプリケーション層にAuto Scalingグループを使用する。最小限のサーバー数にゾーン予約インスタンスを使用し、追加リソースにはオンデマンドインスタンスを使用する。

F. Web層とアプリケーション層にAuto Scalingグループを使用し、複数のアベイラビリティゾーンにまたがるリージョンで動作させる。必要なリソースにはスポットインスタンスを使用する。