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

type

status

date

slug

summary

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

理論

データベース接続負荷軽減と資格情報管理の基本知識

AWSクラウドでアプリケーションを運用する際、データベースのパフォーマンスを維持しつつ、安全な資格情報管理を行うことは非常に重要です。この問題に関連する基本的な知識を以下にまとめます。

1. データベース接続の課題

アプリケーションがデータベースに多数の接続を開くと、データベースが過負荷になり、応答速度が低下します。

特に書き込み操作が多い場合、負荷はさらに増大します。

2. Amazon RDS Proxy

機能: RDS Proxyはデータベースとアプリケーションの間に配置されるプロキシレイヤーで、データベース接続を効率的に管理します。

利点:

接続プールを作成し、再利用可能な接続を提供。
短時間で大量の接続を処理できる。
データベースの負荷を軽減し、スケーラビリティを向上させる。
高可用性を実現し、障害時のフェイルオーバーも迅速に行う。

3. 資格情報管理とセキュリティ

アプリケーションがデータベースにアクセスするための資格情報は、安全に管理する必要があります。

AWS Secrets Manager:

資格情報を暗号化して保存。
自動ローテーション機能により、定期的に資格情報を更新可能。
アクセス制御（IAM）を利用して、安全に管理。

AWS Systems Manager Parameter Store:

資格情報を保存可能だが、Secrets Managerのような自動ローテーション機能は提供されていない。

4. Aurora Replica の用途

Aurora Replicaは、データベースの読み取り専用のレプリカを作成する機能。

主に読み取り性能を向上させる目的で使用される。

書き込み操作の負荷軽減には役立たない。

5. 本質的なポイント

書き込み負荷が問題の場合、接続の効率化が最優先。

資格情報の安全性と定期的なローテーションは、セキュリティ上の必須事項。

簡単なまとめ

データベース負荷の軽減には Amazon RDS Proxy を、資格情報の管理には AWS Secrets Manager を利用するのがベストプラクティスです。これらを組み合わせることで、効率的かつ安全なデータベース運用を実現できます。

実践

略

一問道場

質問 #201

トピック 1

ソリューションアーキテクトは、AWSクラウドでホストされているアプリケーションを改善する必要があります。このアプリケーションは、接続過多の問題を抱えているAmazon Aurora MySQL DBインスタンスを使用しています。アプリケーションの操作の大部分は、データベースへのレコード挿入です。現在、アプリケーションはテキストベースの構成ファイルに資格情報を保存しています。

ソリューションアーキテクトは、現在の接続負荷を処理できるようにするソリューションを実装する必要があります。このソリューションでは、資格情報を安全に保ち、定期的に資格情報を自動でローテーションできる機能を提供しなければなりません。

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

A. DBインスタンスの前にAmazon RDS Proxyレイヤーをデプロイする。接続資格情報をAWS Secrets Managerのシークレットとして保存する。

B. DBインスタンスの前にAmazon RDS Proxyレイヤーをデプロイする。接続資格情報をAWS Systems Manager Parameter Storeに保存する。

C. Aurora Replicaを作成する。接続資格情報をAWS Secrets Managerのシークレットとして保存する。

D. Aurora Replicaを作成する。接続資格情報をAWS Systems Manager Parameter Storeに保存する。

解説

この問題では、データベース接続の負荷を軽減しつつ、安全で定期的な資格情報のローテーションを実現するソリューションを選ぶ必要があります。それぞれの選択肢について解説します：

A. DBインスタンスの前にAmazon RDS Proxyレイヤーをデプロイする。接続資格情報をAWS Secrets Managerのシークレットとして保存する。

✅ 正解

RDS Proxy: Amazon RDS Proxyは、データベース接続のプールを提供し、アプリケーションの接続負荷を軽減します。これにより、アプリケーションが直接データベースに過剰な接続を行うことを防ぎます。

AWS Secrets Manager: 資格情報をSecrets Managerに保存することで、安全な保存と定期的なローテーションが可能になります。

このソリューションの利点:

データベースへの接続負荷を軽減。
資格情報を安全に管理。
定期的な資格情報のローテーションが可能。

B. DBインスタンスの前にAmazon RDS Proxyレイヤーをデプロイする。接続資格情報をAWS Systems Manager Parameter Storeに保存する。

❌ 不正解

RDS Proxyは接続負荷の軽減には有効ですが、AWS Systems Manager Parameter Storeでは資格情報の自動ローテーションがサポートされていません。そのため、「資格情報を定期的にローテーションする」という要件を満たしません。

C. Aurora Replicaを作成する。接続資格情報をAWS Secrets Managerのシークレットとして保存する。

❌ 不正解

Aurora Replicaを作成することで読み取り性能を向上させることはできますが、この問題では書き込み操作が主であるため、接続負荷の軽減にはつながりません。

資格情報をAWS Secrets Managerに保存する点は良いですが、Replicaだけでは問題を解決できません。

D. Aurora Replicaを作成する。接続資格情報をAWS Systems Manager Parameter Storeに保存する。

❌ 不正解

同様に、Replicaでは書き込み負荷を軽減できません。

さらに、AWS Systems Manager Parameter Storeでは資格情報の自動ローテーションがサポートされていません。

解説まとめ:

RDS Proxyは接続プールを管理し、データベースへの過剰な接続を防ぎます。

AWS Secrets Managerは資格情報を安全に保存し、定期的なローテーションを提供します。この要件を満たすのは選択肢 A です。

正解: A

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

理論

ディザスタリカバリ（DR）の基本知識

ディザスタリカバリ（Disaster Recovery, DR）は、システム障害や災害発生時に迅速にサービスを復旧させるための計画や仕組みを指します。以下にDR設計の基本要素を説明します。

1. RPO（Recovery Point Objective: 復旧時点目標）

定義: データがどの程度新しい状態まで復旧できるかを示す指標。データ損失の許容範囲を決定。

例: RPOが30秒の場合、最悪でも30秒前のデータ状態に復旧できる必要があります。

実現方法:

クロスリージョンリードレプリカ: データベースをリアルタイムで別リージョンに複製。
継続的なデータレプリケーションツール: AWS Elastic Disaster Recovery など。

2. RTO（Recovery Time Objective: 復旧時間目標）

定義: サービスがダウンしてから復旧するまでの許容時間。

例: RTOが10分の場合、障害発生後10分以内にサービスを再開する必要があります。

実現方法:

自動フェイルオーバー: Route 53 フェイルオーバールーティングポリシーを利用。
事前プロビジョニング: 必要最低限のインフラをDRリージョンに用意しておき、障害時にスケールアップ。

3. コスト効率

DR環境を維持するにはコストがかかります。通常運用時のコストを最小限に抑える方法が重要です。

ミニマム構成: DRリージョンではインスタンスを最小限に運用し、障害時にスケールアップ。

Infrastructure as Code（IaC）: 必要なリソースをスクリプトで迅速にデプロイ。

4. AWSでのDR実現方法

AWSでは以下のツールとサービスがDR構築に有効です：

Amazon RDS Cross-Region Read Replica:

RDSデータベースのデータをリアルタイムで別リージョンに複製。
高速なフェイルオーバーが可能。

AWS Elastic Disaster Recovery:

EC2インスタンスやオンプレミス環境の継続的なレプリケーション。
必要に応じて迅速に復旧可能。

Amazon Route 53:

フェイルオーバールーティングを利用して自動でDRリージョンに切り替え。

AWS Backup:

定期的なデータバックアップ。低コストだがRPO/RTOが高くなる可能性。

5. DR戦略の種類

バックアップ＆リストア:

コスト: 低
RPO/RTO: 高い（数時間～数日）

パイロットライト:

コスト: 中
RPO/RTO: 数分～数時間

ウォームスタンバイ:

コスト: 高
RPO/RTO: 数秒～数分

アクティブ/アクティブ:

コスト: 非常に高
RPO/RTO: 秒単位

まとめ

問題で提示された「RPO 30秒、RTO 10分」に対応するには、クロスリージョンリードレプリカとAWS Elastic Disaster Recoveryを組み合わせ、Route 53で自動フェイルオーバーを設定するのが最適です。

実践

略

一問道場

質問 #202

トピック 1

ある企業が、eコマースウェブサイトのディザスタリカバリ（DR）ソリューションを構築する必要があります。

ウェブアプリケーションは、複数のアベイラビリティゾーンにまたがるAuto Scalingグループで運用されているt3.large Amazon EC2インスタンスのフリート上にホストされています。また、Amazon RDS for MySQL DBインスタンスを使用しています。

災害が発生した場合、ウェブアプリケーションはセカンダリ環境にフェイルオーバーする必要があり、目標復旧時点（RPO）は30秒、目標復旧時間（RTO）は10分です。

以下のうち、コスト効率が最も高いソリューションはどれですか？

A. インフラストラクチャをコード（IaC）として記述して、DRリージョンに新しいインフラストラクチャをプロビジョニングします。DBインスタンスのクロスリージョンリードレプリカを作成します。AWS Backupでバックアッププランを設定し、EC2インスタンスとDBインスタンスのクロスリージョンバックアップを作成します。EC2インスタンスとDBインスタンスを30秒ごとにDRリージョンにバックアップするためのcron式を作成します。最新のEC2バックアップからインスタンスを復元します。Amazon Route 53の地理的ルーティングポリシーを使用して、災害発生時にDRリージョンへ自動的にフェイルオーバーします。

B. インフラストラクチャをコード（IaC）として記述して、DRリージョンに新しいインフラストラクチャをプロビジョニングします。DBインスタンスのクロスリージョンリードレプリカを作成します。AWS Elastic Disaster Recoveryを設定して、EC2インスタンスをDRリージョンに継続的にレプリケートします。DRリージョンでEC2インスタンスを最小容量で運用します。Amazon Route 53のフェイルオーバールーティングポリシーを使用して、災害発生時にDRリージョンへ自動的にフェイルオーバーします。Auto Scalingグループの希望容量を増加させます。

C. AWS Backupでバックアッププランを設定し、EC2インスタンスとDBインスタンスのクロスリージョンバックアップを作成します。EC2インスタンスとDBインスタンスを30秒ごとにDRリージョンにバックアップするためのcron式を作成します。インフラストラクチャをコード（IaC）として記述して、DRリージョンに新しいインフラストラクチャをプロビジョニングします。バックアップデータを手動で新しいインスタンスに復元します。Amazon Route 53のシンプルルーティングポリシーを使用して、災害発生時にDRリージョンへ自動的にフェイルオーバーします。

D. インフラストラクチャをコード（IaC）として記述して、DRリージョンに新しいインフラストラクチャをプロビジョニングします。Amazon Auroraグローバルデータベースを作成します。AWS Elastic Disaster Recoveryを設定して、EC2インスタンスをDRリージョンに継続的にレプリケートします。DRリージョンでEC2インスタンスのAuto Scalingグループをフル容量で運用します。Amazon Route 53のフェイルオーバールーティングポリシーを使用して、災害発生時にDRリージョンへ自動的にフェイルオーバーします。

解説

この問題は、コスト効率の高いディザスタリカバリ（DR）ソリューションを選ぶ問題です。主なポイントは以下の通りです：

RPO（復旧時点目標）30秒とRTO（復旧時間目標）10分を達成するために、

データが常に最新である必要があります（継続的なデータレプリケーション）。

短時間でリソースを起動できる仕組みが必要です。

コスト効率を考慮する必要があります。DRリージョンでのインフラは最小限に抑えつつ、必要に応じてスケールアップできる仕組みが理想です。

正解: B

理由:

クロスリージョンリードレプリカを利用してDBのデータをDRリージョンにリアルタイムで同期。
AWS Elastic Disaster Recoveryを使ってEC2インスタンスを継続的にレプリケート。これにより、RPOを30秒以内に維持可能。
DRリージョンではインフラを最小構成で運用し、必要時にAuto Scalingグループでスケールアップすることでコストを抑える。
Route 53のフェイルオーバールーティングポリシーで自動フェイルオーバーを実現し、RTO 10分を達成。

他の選択肢は以下の理由で不適切です：

A: 30秒ごとのバックアップではRPOを満たせません。さらに、復旧時間も長くなりコストも高いです。

C: 手動復旧は時間がかかり、RTOを満たせません。

D: DRリージョンで常にフル容量でインフラを運用するのは非常にコストが高いです。

203-AWS SAP AWS 「理論・実践・一問道場」大容量データ移行

理論

大容量データ移行の本質的知識

AWS環境における大容量データ移行の効率的な方法について、以下のポイントを理解することが重要です。

1. データ移行の課題

帯域幅の制限: インターネット接続を使用すると、データ量が大きい場合、移行に非常に長い時間がかかります。

コスト: 専用線や高速データ転送サービスはコストが高くなる場合があります。

セキュリティ: 移行中のデータを安全に保つ必要があります。

2. AWS Snowball

概要: AWS Snowballは、物理デバイスを使用して大容量データをAWSに転送するサービスです。帯域幅の制約を回避し、データ移行を数日で完了できます。

使用例: オンプレミスのデータセンターからS3バケットにデータを移行。

メリット:

インターネット接続不要。
迅速かつコスト効果が高い。
データは暗号化され、安全に転送されます。

3. AWS Database Migration Service (AWS DMS)

概要: AWS DMSは、データベースの移行を自動化・効率化するサービスです。既存のデータベースからAmazon Aurora MySQLなどのターゲットデータベースにデータを移行できます。

使用例: SnowballでS3に移行したデータをAurora MySQLに取り込む。

メリット:

ダウンタイムを最小限に抑えられる。
移行後もデータの同期を維持可能。

4. データ移行計画のベストプラクティス

初期評価: 移行対象データの量や種類、帯域幅の制約を確認。

移行方法の選択:

数TB以下のデータの場合: AWS DMSやAWS DataSyncを使用。

数十TB以上のデータの場合: AWS Snowballを使用して物理的に転送。

セキュリティ確保: 移行中のデータ暗号化を必須とする。

テスト: 本番環境に移行する前に、小規模なテストを実施。

まとめ

大容量データ移行では、インターネット帯域幅の制約を回避できる物理デバイス（AWS Snowball）の使用が鍵となります。

Snowballで迅速にデータをAWSに転送し、AWS DMSでデータベースに移行する方法が、コスト効率と時間効率の両方で優れています。

移行計画を立てる際には、セキュリティと可用性も考慮することが重要です。

実践

略

一問道場

問題 #203

トピック 1

ある企業がオンプレミスのMySQLデータベースを、米国東部（us-east-1）リージョンのAmazon Aurora MySQLに一度限りで移行する計画を立てています。この企業の現在のインターネット接続は帯域幅が限られています。オンプレミスのMySQLデータベースは60TBのサイズがあり、現在のインターネット接続を使用するとデータをAWSに転送するのに1か月かかると見積もられています。この企業は、データベースをより迅速に移行できるソリューションを必要としています。

どのソリューションが最も短い時間でデータベースを移行できますか？

A. オンプレミスのデータセンターとAWS間で1 GbpsのAWS Direct Connect接続をリクエストします。AWS Database Migration Service（AWS DMS）を使用して、オンプレミスのMySQLデータベースをAurora MySQLに移行します。

B. 現在のインターネット接続を使用してAWS DataSyncでデータ転送を加速します。AWS Application Migration Serviceを使用して、オンプレミスのMySQLデータベースをAurora MySQLに移行します。

C. AWS Snowball Edgeデバイスを注文します。データをAmazon S3バケットにS3インターフェースを使用してロードします。AWS Database Migration Service（AWS DMS）を使用して、Amazon S3からAurora MySQLにデータを移行します。

D. AWS Snowballデバイスを注文します。S3 Adapter for Snowballを使用してデータをAmazon S3バケットにロードします。AWS Application Migration Serviceを使用して、Amazon S3からAurora MySQLにデータを移行します。

解説

この問題では、60TBという非常に大容量のデータベースを限られた帯域幅のインターネット接続で迅速に移行する必要があります。効率的なデータ転送と移行プロセスを考慮する必要があります。

選択肢ごとの評価

A. AWS Direct Connect + AWS DMS

評価: AWS Direct Connectを利用すると、専用線による高速データ転送が可能になります。ただし、1Gbpsの接続をリクエストして構築するには時間がかかり、初期設定も複雑です。

結論: 時間的な効率が悪いため、不適切です。

B. AWS DataSync + AWS Application Migration Service

評価: AWS DataSyncはデータ転送を効率化しますが、オンプレミスとAWS間の帯域幅の制約が残り、1か月以上かかる可能性があります。また、Application Migration Serviceは通常、アプリケーション全体の移行に使用され、データベース専用ではないため、適用が難しいです。

結論: 現実的に帯域幅の問題を解決できないため、不適切です。

C. AWS Snowball Edge + AWS DMS

評価: AWS Snowball Edgeデバイスを使用して物理的にデータを転送することで、インターネット帯域幅の制約を回避できます。Snowball Edgeを利用すれば、数日以内にデータを転送し、Amazon S3に取り込むことができます。その後、AWS DMSを使用してAurora MySQLにデータを移行するプロセスも効率的です。

結論: 最適解です。

D. AWS Snowball + AWS Application Migration Service

評価: Snowballを使用したデータ転送自体はCと同様に効率的です。しかし、Application Migration Serviceはデータベースの移行には最適ではありません。Aurora MySQLへの移行には特化していないため、追加の作業が必要になります。

結論: Cと比較して効率が劣るため、不適切です。

解答

正解: C. AWS Snowball Edge + AWS DMS

理由:

AWS Snowball Edgeを使用することで、インターネット接続の制約を回避し、大量データの転送を数日で完了できます。

AWS DMSを使用することで、効率的にAmazon S3からAurora MySQLにデータを移行できます。

最も時間効率がよく、コスト効果も高い方法です。

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

理論

1. バックアップの自動化

バックアップの自動化は、災害復旧戦略において非常に重要です。手動でバックアップを管理するのは運用コストやエラーのリスクが高いため、自動化ツールを使用することで、バックアップ作業を効率的に行い、ミスを減らすことができます。AWSには、バックアップの自動化をサポートするいくつかのツールがあります：

以下がAWS Backupと**Amazon Data Lifecycle Manager (DLM)**の重点的な違いです：

特徴	AWS Backup	Amazon Data Lifecycle Manager (DLM)
対象リソース	EC2、EBS、RDS、DynamoDB、EFSなど複数のAWSリソース	主にEBSボリュームのスナップショット
クロスリージョンバックアップ	サポート（異なるリージョンにバックアップコピー可能）	サポートしない（同一リージョン内のみ）
復元の柔軟性	複数のAWSサービスから復元可能	EBSスナップショットのみ復元可能
料金	バックアップデータ容量に基づいて課金	EBSスナップショット容量に基づいて課金

まとめ：

AWS Backupは、複数のAWSリソースに対応し、クロスリージョンバックアップも可能。

DLMは、EBSのスナップショット管理に特化しており、シンプルでEBSのバックアップのライフサイクルを効率化します。

バックアップボールトは、AWS Backupサービスでバックアップデータを安全に保管する場所です。主な機能は次の通りです：

データ保管: EC2インスタンスやRDSなどのバックアップをまとめて格納します。

セキュリティ: バックアップデータは暗号化され、アクセス権限を設定できます。

復元: 必要な時に簡単にバックアップデータを復元できます。

ポリシー管理: バックアップの保存期間や削除ポリシーを設定できます。

監査機能: 操作履歴を追跡し、コンプライアンスに役立ちます。

これにより、バックアップデータの管理が効率的で安全に行えます。

2. 災害復旧 (DR) 戦略

災害復旧（DR）は、システム障害や災害時にデータを保護し、迅速に復元できるようにするための戦略です。企業は、災害発生時に業務を迅速に再開するための方法を計画する必要があります。以下の要素を考慮することが重要です：

RPO (Recovery Point Objective): データ損失が許容される最大の期間。例えば、RPOが「1日のデータ損失を許容する」とすると、1日の間隔でバックアップを取得する必要があります。

RTO (Recovery Time Objective): システム復旧にかかる最大許容時間。例えば、RTOが「1営業日以内」と設定されている場合、その時間内にシステムを復旧させる必要があります。

3. AWS CloudFormation

AWS CloudFormationは、インフラストラクチャをコードとして管理するサービスで、インフラリソースの設定や展開を自動化します。災害復旧の文脈では、CloudFormationを使って、災害発生時に別リージョンで必要なインフラを迅速に再作成するためのテンプレートを作成できます。これにより、手動でのインスタンス起動や設定作業を省略でき、復旧時間を短縮できます。

4. リージョン間バックアップと復元

異なるリージョンにバックアップをコピーしておくことで、リージョン全体で問題が発生した場合でもデータの損失を防ぐことができます。AWS BackupやDLMは、バックアップを異なるリージョンに自動でコピーする機能を提供しています。これにより、復元作業が迅速に行えるようになります。

5. 災害復旧のコスト効率化

バックアップや復元のためのソリューションは、コスト効率の良さも重要な要素です。例えば、バックアップをアクティブに保つリージョンで復元する場合、バックアップデータを異なるリージョンにコピーするコストや、復元後の運用コスト（インスタンス料金など）を最小限に抑えることが求められます。AWS Backupのスケジュールや保存期間を最適化することで、コストを抑えつつ信頼性の高いDRを構築することができます。

まとめ

災害復旧（DR）の設計において、バックアップの自動化、インフラのコード管理、リージョン間のバックアップ戦略、コスト効率の最適化が非常に重要な要素です。AWSには、これらのニーズを満たすための多くのサービスがあり、適切に組み合わせることで、効率的かつ信頼性の高い災害復旧ソリューションを実現することができます。

実践

略

一問道場

質問 #204トピック 1

ある企業がAWSクラウドでアプリケーションを運用しています。アプリケーションは20台のAmazon EC2インスタンスで実行されています。EC2インスタンスは永続的で、複数のAmazon Elastic Block Store（Amazon EBS）ボリュームにデータを保存しています。この企業は、バックアップを別のAWSリージョンに保持しなければなりません。また、EC2インスタンスとその設定を1営業日以内に回復できる必要があり、データの損失は1日分を超えてはなりません。企業には限られたスタッフしかおらず、運用効率とコストの最適化を目指すバックアップソリューションが必要です。企業はすでに、別のリージョンで必要なネットワーク設定をデプロイできるAWS CloudFormationテンプレートを作成しています。

この要件を満たすソリューションはどれですか？

A. 2番目のCloudFormationテンプレートを作成し、セカンダリリージョンでEC2インスタンスを再作成できるようにします。AWS Systems Manager Automationの実行ブックを使用して毎日複数のEBSボリュームのスナップショットを作成し、スナップショットをセカンダリリージョンにコピーします。障害が発生した場合、CloudFormationテンプレートを起動し、スナップショットからEBSボリュームを復元し、セカンダリリージョンに使用を移行します。

B. Amazon Data Lifecycle Manager（Amazon DLM）を使用して、EBSボリュームの毎日の複数ボリュームスナップショットを作成します。障害が発生した場合、CloudFormationテンプレートを起動し、Amazon DLMを使用してEBSボリュームを復元し、セカンダリリージョンに使用を移行します。

C. AWS Backupを使用して、EC2インスタンスの毎日のバックアップ計画を作成します。バックアップタスクを構成して、バックアップをセカンダリリージョンのボールトにコピーします。障害が発生した場合、CloudFormationテンプレートを起動し、バックアップボールトからインスタンスボリュームと設定を復元し、セカンダリリージョンに使用を移行します。

D. 同じサイズと設定のEC2インスタンスをセカンダリリージョンにデプロイします。AWS DataSyncを毎日使用して、プライマリリージョンからセカンダリリージョンにデータをコピーします。障害が発生した場合、CloudFormationテンプレートを起動し、セカンダリリージョンに使用を移行します。

解説

この問題は、AWSクラウドでアプリケーションを実行している企業が、EC2インスタンスとそのEBSボリュームをバックアップし、別のAWSリージョンでの障害回復を実現するための最適なバックアップソリューションを選ぶものです。

要件は次の通りです：

EC2インスタンスとEBSボリュームのバックアップを1営業日以内に復元し、1日分のデータ損失を許容する。

限られたスタッフで運用効率とコストの最適化を目指す。

既にAWS CloudFormationテンプレートを使って、別リージョンに必要なネットワーク設定をデプロイする準備がある。

解答を選ぶ際のポイントを説明します。

各選択肢の分析

メリット：CloudFormationテンプレートを使ってバックアップを手動で復元するフロー。AWS Systems Manager Automationを使用してスナップショットの作成とコピーが可能。
デメリット：手動で復元し、手間がかかるため、効率が悪くなる可能性があります。特にバックアップ操作や復元に時間がかかる可能性があります。

メリット：Amazon DLMを使用してEBSボリュームのスナップショットを自動で作成し、バックアップを効率的に管理できる。CloudFormationを使って復元できる。
デメリット：復元のフローが複雑で、バックアップデータの管理が若干手間になる可能性がある。

メリット：AWS Backupは、EC2インスタンスのバックアップを自動でスケジュールでき、バックアップを別のリージョンにコピーする機能がある。復元が簡単で、AWS CloudFormationを使ってインフラを再デプロイし、バックアップを利用して迅速に回復できる。
デメリット：AWS Backupのコストが発生する可能性があるが、バックアップと復元が効率的であり、少ないスタッフで管理可能。

メリット：AWS DataSyncを使って、データのコピーを効率的に行えるが、手動復元が前提となる。
デメリット：バックアップを取り、データ転送を行うには手間がかかり、1営業日以内での復元が難しくなる可能性がある。

最適解

C. AWS Backupが最も適切な選択肢です。

理由：AWS Backupは、複数のAWSリソース（EC2、EBS、RDSなど）のバックアップを効率的にスケジュールし、別リージョンへのコピー機能もサポートしています。これにより、バックアップからの復元を迅速に実施でき、運用効率とコストを最適化できます。

補足：AWS Backupを使用すると、バックアップの管理が自動化されるため、少ないスタッフでの運用が可能になり、災害復旧の要件（RTO、RPO）も満たすことができます。

結論

最も効率的でコスト効果の高いソリューションはAWS Backupを使うことであり、別リージョンへのバックアップコピー機能を活用して、迅速な障害回復を実現できます。

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

理論

S3とCloudFrontを使ったデータの暗号化

AWSで静的コンテンツをホストする際に、データを転送中および保存中に暗号化することは非常に重要です。ここでは、Amazon S3とAmazon CloudFrontを使用してデータの暗号化を強制する方法について説明します。

1. S3のサーバー側暗号化（SSE）

S3では、データを「保存中」に暗号化するためのサーバー側暗号化（SSE）を使用できます。これにより、S3にアップロードされたすべてのデータが自動的に暗号化されます。SSEには主に以下の方法があります：

SSE-S3: S3が管理する暗号化キーを使用。

SSE-KMS: AWS Key Management Service (KMS)によって管理される暗号化キーを使用。

SSE-C: 顧客が管理する暗号化キーを使用。

これを有効にすることで、S3に保存されたデータがすべて暗号化され、データの安全性が保証されます。

2. CloudFrontでのHTTPS強制

CloudFrontは、S3からコンテンツをキャッシュして配信するCDN（コンテンツ配信ネットワーク）です。データがインターネット上を移動する際、転送中の暗号化を確保するために、HTTPからHTTPSへのリダイレクトを設定することが重要です。これにより、ユーザーとCloudFront間、さらにCloudFrontとS3間の通信が常に暗号化され、データが盗聴されるリスクを防ぎます。

3. S3バケットポリシーで暗号化を強制

S3では、バケットポリシーを使用して、暗号化されていないデータのアップロードを拒否することができます。このポリシーを設定することで、すべてのデータが暗号化されることを強制できます。例えば、暗号化されていないオブジェクトがS3に保存されるのを防ぐポリシーを設定できます。

4. 署名付きURLでHTTPSの強制

署名付きURLを使用する場合、RequireSSLオプションを設定して、S3バケットへのアクセスが常にHTTPSで行われるように強制することができます。これにより、特に一時的なアクセスを提供する場合でも、通信が暗号化されることを確保できます。

結論

AWSでのデータ暗号化を確保するためには、保存時の暗号化と転送時の暗号化の両方を適切に設定することが重要です。S3のサーバー側暗号化を有効にし、CloudFrontでHTTPSリダイレクトを設定することで、データのセキュリティを確保し、法的要件や企業のセキュリティポリシーに準拠することができます。

実践

略

一問道場

問題 #205

トピック 1

ある企業が静的コンテンツをホストする新しいウェブサイトを設計しています。このウェブサイトでは、ユーザーが大きなファイルをアップロードおよびダウンロードできるようにします。企業の要求によると、すべてのデータは転送中と保存中の両方で暗号化される必要があります。ソリューションアーキテクトは、Amazon S3とAmazon CloudFrontを使用してソリューションを構築しています。

どの手順の組み合わせが暗号化要件を満たしますか？（3つ選んでください。）

A. ウェブアプリケーションが使用するS3バケットに対して、S3サーバー側暗号化を有効にする。

B. S3 ACLの読み書き操作に対して、「aws:SecureTransport":"true"」というポリシー属性を追加する。

C. ウェブアプリケーションが使用するS3バケットで、暗号化されていない操作を拒否するバケットポリシーを作成する。

D. CloudFrontで、AWS KMSキーを使用したサーバー側暗号化(SSE-KMS)による保存時の暗号化を設定する。

E. CloudFrontでHTTPリクエストをHTTPSリクエストにリダイレクトする設定を行う。

F. ウェブアプリケーションが使用するS3バケットに対して、署名付きURL作成時に「RequireSSL」オプションを使用する。

解説

この問題では、ウェブサイトが静的コンテンツをホストし、ユーザーが大きなファイルをアップロードおよびダウンロードするため、すべてのデータが「転送中」および「保存中」で暗号化される必要があります。以下の選択肢の組み合わせで、暗号化要件を満たす方法を説明します。

正解の選択肢

A. ウェブアプリケーションが使用するS3バケットに対して、S3サーバー側暗号化を有効にする。

S3のサーバー側暗号化を有効にすることで、S3に保存されるすべてのデータが保存時に暗号化されます。これにより、データは「保存中」も暗号化されます。

C. ウェブアプリケーションが使用するS3バケットで、暗号化されていない操作を拒否するバケットポリシーを作成する。

バケットポリシーを使って、暗号化されていないデータの保存を防ぐことができます。これにより、暗号化されていないデータがS3にアップロードされることを防ぎ、暗号化が必須であることを保証します。

E. CloudFrontでHTTPリクエストをHTTPSリクエストにリダイレクトする設定を行う。

CloudFrontでHTTPリクエストをHTTPSにリダイレクトすることによって、データの「転送中」の暗号化が強制されます。これにより、ユーザーとCloudFront間でやり取りされるデータがすべてHTTPSで暗号化されます。

なぜ他の選択肢は正解ではないか？

B. S3 ACLの読み書き操作に対して、「aws:SecureTransport":"true"」というポリシー属性を追加する。

これはS3のアクセスコントロールリスト（ACL）に基づいたポリシーですが、実際にはバケットポリシーを使用する方がより適切です。バケットポリシーを使って暗号化の強制をする方が効果的です。

D. CloudFrontで、AWS KMSキーを使用したサーバー側暗号化(SSE-KMS)による保存時の暗号化を設定する。

CloudFront自体では保存時の暗号化を設定することはできません。SSE-KMSによる保存時の暗号化は、S3に保存されたデータに適用されるものであり、CloudFrontには関係ありません。

F. ウェブアプリケーションが使用するS3バケットに対して、署名付きURL作成時に「RequireSSL」オプションを使用する。

署名付きURLに「RequireSSL」オプションを設定することは、データ転送をHTTPSに強制するために使われますが、この設定だけでは全体的な暗号化要件（保存時と転送時の暗号化）を満たすことにはなりません。

まとめ

保存時の暗号化: S3のサーバー側暗号化を有効にする（選択肢A）。

転送時の暗号化: CloudFrontでHTTPSへのリダイレクトを設定する（選択肢E）。

暗号化の強制: S3バケットポリシーを使用して暗号化されていない操作を拒否する（選択肢C）。

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

理論

1. AWS Lambda と環境変数のセキュリティ

AWS Lambda 関数は、コード実行をトリガーするサーバーレスサービスですが、環境変数を使用して外部の設定や認証情報を保持することができます。しかし、環境変数は暗号化されていない場合があり、機密情報を保持するには不適切な方法です。特に、ログやデバッグ情報で環境変数が露出する可能性があります。

2. AWS KMS（Key Management Service）

AWS Key Management Service（KMS）は、データの暗号化とキーの管理を行うサービスです。KMS を使用すると、**顧客管理キー（CMK）**を作成し、機密情報を暗号化できます。特に、管理者権限を制限して、特定の IAM ユーザー（例: IT セキュリティチーム）のみにアクセスを許可できます。これにより、暗号化された資格情報の安全な保管とアクセス制御が可能になります。

KMS のローテーション機能を利用することで、定期的なキーのローテーションが自動化され、セキュリティ強化に役立ちます。

3. AWS Secrets Manager

AWS Secrets Manager は、機密情報の管理専用サービスであり、データベースの認証情報や API キーなどを安全に保存できます。Secrets Manager では以下のような機能を提供しています：

自動的な資格情報のローテーション

KMS で暗号化

アクセス制御とポリシーを使用して、特定の IAM ユーザーグループやロールにのみアクセスを許可

Secrets Manager は特に機密情報の取り扱いを簡素化し、監査ログや自動ローテーションなどの機能を備えているため、セキュリティと運用効率を向上させることができます。

4. AWS IAM（Identity and Access Management）

AWS IAM は、AWS リソースへのアクセス権限を管理するためのサービスです。IAM を使用して、特定のユーザーやグループに対してアクセスを制御することができます。例えば、IT セキュリティチームのみが特定の KMS キーや Secrets Manager の資格情報にアクセスできるようにすることができます。これにより、最小権限の原則を実現し、アクセス制御を強化することができます。

5. Lambda 関数の役割

Lambda 関数は、IAM ロールを使用して他の AWS サービスにアクセスします。ロールを適切に設定することで、Lambda 関数は Secrets Manager や Systems Manager Parameter Store から暗号化された資格情報を安全に取得することができます。最小権限の原則に従って、Lambda 関数が必要なリソースにのみアクセスできるように設定することが推奨されます。

6. AWS Systems Manager Parameter Store

AWS Systems Manager Parameter Store は、アプリケーション設定や機密情報（資格情報など）を安全に保存するためのサービスです。SecureString パラメータを使用して、AWS KMSで暗号化されたデータを保存できます。Lambda 関数などからこの情報にアクセスするには、適切な IAM ポリシーが必要です。Secrets Manager との違いは、Secrets Managerがより機能が豊富であり、特に資格情報の自動ローテーションや監査機能を提供する点です。

結論

この問題において最も適切な選択肢は、AWS Secrets Managerを使用して機密情報を管理する方法です。Secrets Manager は、自動ローテーションや細かなアクセス制御、監査機能を提供し、セキュリティを向上させつつ運用効率を高めます。また、IAM ロールを活用して、Lambda 関数が必要なデータにのみアクセスできるように設定します。

実践

略

一問道場

質問 #206

トピック 1

ある企業は、AWS Lambda 関数を使用したサーバーレスアーキテクチャを実装しています。これらの関数は、Amazon RDS 上の Microsoft SQL Server DB インスタンスにアクセスする必要があります。この企業には開発環境と本番環境があり、データベースシステムのクローンも存在します。開発者は開発データベースの資格情報にアクセスできますが、本番データベースの資格情報は、IT セキュリティチームの IAM ユーザーグループのメンバーだけがアクセスできるキーで暗号化される必要があります。このキーは定期的にローテーションする必要があります。

本番環境でこれらの要件を満たすために、ソリューションアーキテクトは何をすべきですか？

A. AWS Systems Manager Parameter Store にデータベースの資格情報を SecureString パラメータとして保存し、AWS Key Management Service (AWS KMS) の顧客管理キーで暗号化します。各 Lambda 関数に役割を割り当て、SecureString パラメータへのアクセスを提供します。SecureString パラメータと顧客管理キーへのアクセスを IT セキュリティチームのみがアクセスできるように制限します。

B. データベースの資格情報を AWS Key Management Service (AWS KMS) のデフォルト Lambda キーで暗号化し、資格情報を各 Lambda 関数の環境変数に保存します。Lambda コードで環境変数から資格情報を読み込みます。KMS キーへのアクセスを IT セキュリティチームのみがアクセスできるように制限します。

C. データベースの資格情報を各 Lambda 関数の環境変数に保存し、AWS Key Management Service (AWS KMS) の顧客管理キーで環境変数を暗号化します。顧客管理キーへのアクセスを IT セキュリティチームのみがアクセスできるように制限します。

D. AWS Secrets Manager にデータベースの資格情報を秘密として保存し、AWS Key Management Service (AWS KMS) の顧客管理キーで暗号化します。各 Lambda 関数に役割を割り当て、秘密へのアクセスを提供します。秘密と顧客管理キーへのアクセスを IT セキュリティチームのみがアクセスできるように制限します。

解説

この問題は、本番環境におけるデータベースの資格情報のセキュリティを確保し、アクセス制御とキー管理を適切に実施する方法を問うものです。具体的には、AWS Lambda 関数が Microsoft SQL Server DB インスタンスにアクセスするために、暗号化された資格情報を管理する方法を選ぶ必要があります。

選択肢の解説:

A. AWS Systems Manager Parameter Storeを使用

AWS Systems Manager Parameter Storeは、資格情報や構成情報を安全に保存するためのサービスです。ここで、SecureString パラメータを使い、AWS KMSによって暗号化されたデータを保存できます。

顧客管理キー (CMK) を使用して暗号化し、特定の IAM ユーザーグループ（ITセキュリティチーム）のみがアクセスできるように制限できます。

Lambda 関数は、必要なパラメータにアクセスするために、適切な IAM ロールを通じてアクセスします。適切なアクセス制御と定期的なキーのローテーションが可能なため、最適な解決策です。

B. AWS KMS のデフォルト Lambda キーを使用

この選択肢では、データベースの資格情報を AWS KMS のデフォルト Lambda キーで暗号化し、Lambda 関数の 環境変数に保存します。

Lambda 関数で環境変数から資格情報を読み取りますが、環境変数はセキュリティ上のリスクが高く、特に機密情報を保存するためには適切でない方法です。

また、KMS のデフォルトキーでは、キー管理の制限が難しいため、セキュリティチームのみにアクセス制限を設けることができません。

C. Lambda 環境変数での暗号化

Lambda 関数の環境変数に資格情報を保存し、KMS 顧客管理キーで暗号化する方法です。

環境変数に機密情報を保存することはセキュリティ上のリスクが高いとされ、推奨されません。例えば、Lambda がログに出力した際に、環境変数が漏洩する可能性があります。

したがって、この選択肢は不適切です。

D. AWS Secrets Manager を使用

AWS Secrets Managerは、機密情報を安全に管理するためのサービスです。資格情報は自動的に AWS KMS 顧客管理キーで暗号化され、アクセスが制限された状態で保存されます。

Lambda 関数は IAM ロールを使用して、Secrets Manager から資格情報を取得します。Secrets Manager では資格情報の自動的なローテーションも可能であり、セキュリティと管理が容易です。

秘密の管理には最適なサービスであり、特に本番環境での資格情報管理において推奨される方法です。

正解:

A.とD.のいずれも適切なソリューションですが、よりセキュリティと運用効率を重視するなら、Dの選択肢が最も理想的です。なぜなら、AWS Secrets Managerは資格情報の管理だけでなく、自動ローテーションやアクセス制御も簡単に設定できるため、運用の負荷を軽減し、セキュリティの強化が図れるからです。

207-AWS SAP AWS 「理論・実践・一問道場」SQL Server

理論

SQL Serverは、Microsoftが開発したリレーショナルデータベース管理システム（RDBMS）です。データを表形式で管理し、SQL（Structured Query Language）を使ってデータの操作、検索、更新、削除を行います。

主な特徴は以下の通りです：

データ管理: 大量のデータを効率的に管理し、企業や組織のデータベース運用をサポートします。

スケーラビリティ: 小規模なシステムから大規模なエンタープライズシステムまで、用途に応じてスケールできます。

セキュリティ: データの暗号化やアクセス制御など、高度なセキュリティ機能を備えています。

バックアップ・リカバリ: 自動的なバックアップやリカバリ機能を提供し、データの保護を強化します。

SQL Serverは、企業の業務システムやアプリケーションのデータベースバックエンドとして広く利用されています。

データベースの移行と管理

アプリケーションの移行に伴い、データベースの移行方法と管理も重要な要素となります。特に、コスト効率とスケーラビリティに優れたデータベースサービスを選択することが、全体のパフォーマンスと運用コストに大きな影響を与えます。

2.1 Amazon Aurora

Aurora PostgreSQLやAurora MySQLは、リレーショナルデータベースサービスであり、SQL Serverなどのデータベースに代わる高パフォーマンスで低コストな選択肢です。

Auroraは、標準のMySQLやPostgreSQLと互換性があり、従来のRDSよりも高いパフォーマンスを提供します。特に、読み書きのスループットが非常に高く、データのスケーリングに強みを持っています。

さらに、Babelfishを使用することで、SQL ServerのクエリをAurora PostgreSQLでそのまま実行できるため、SQL Serverからの移行をスムーズに行えます。このように、Auroraはスケーラビリティの確保とコスト削減において非常に強力です。

実践

略

一問道場

オンライン小売会社が、レガシーのオンプレミスの.NETアプリケーションをAWSに移行しています。アプリケーションは、ロードバランスされたフロントエンドのWebサーバー、ロードバランスされたアプリケーションサーバー、およびMicrosoft SQL Serverデータベースで実行されています。会社は、可能な限りAWSのマネージドサービスを使用したいと考えており、アプリケーションを再構築することは望んでいません。ソリューションアーキテクトは、スケーリングの問題を解決し、アプリケーションがスケールする際にライセンスコストを最小限に抑えるソリューションを実装する必要があります。

どのソリューションが最もコスト効果的にこれらの要件を満たすでしょうか？

A. Web層とアプリケーション層のために、アプリケーションロードバランサーの背後でAuto ScalingグループにAmazon EC2インスタンスをデプロイします。SQL Serverデータベースを再プラットフォームするために、Babelfishを有効にしたAmazon Aurora PostgreSQLを使用します。

B. AWS Database Migration Service (AWS DMS)を使用してすべてのサーバーのイメージを作成します。オンプレミスのインポートに基づいてAmazon EC2インスタンスをデプロイします。Web層とアプリケーション層のために、Network Load Balancerの背後でAuto Scalingグループにインスタンスをデプロイします。データベース層にはAmazon DynamoDBを使用します。

C. Webフロントエンド層とアプリケーション層をコンテナ化します。Amazon Elastic Kubernetes Service (Amazon EKS)クラスタを作成します。Web層とアプリケーション層のために、Network Load Balancerの背後でAuto Scalingグループを作成します。データベースにはAmazon RDS for SQL Serverを使用します。

D. アプリケーション機能をAWS Lambda関数に分割します。Webフロントエンド層とアプリケーション層のためにAmazon API Gatewayを使用します。データはAmazon S3に移行し、Amazon Athenaを使用してデータをクエリします。

解説

この問題では、既存の.NETアプリケーションをAWSに移行し、スケーラビリティの問題を解決し、ライセンスコストを最小限に抑えるための最適な解決策を選ぶことが求められています。各選択肢を詳しく見てみましょう。

A: EC2 + Aurora PostgreSQL with Babelfish

解説:

Amazon EC2を使用して、Webおよびアプリケーション層をスケーリングできます。Auto Scalingにより、トラフィックの増減に応じてインスタンス数を自動で調整できます。
Amazon Aurora PostgreSQLを使用すると、SQL Serverからの移行が可能です。特に、Babelfishを使うことで、SQL Server用に書かれたクエリがそのまま実行できるため、アプリケーションの変更を最小限に抑えつつ、コスト削減ができます。Auroraは高性能なリレーショナルデータベースであり、スケーラビリティや可用性が高いです。
コスト効率: SQL ServerからAurora PostgreSQLに移行することで、SQL Serverライセンスのコストを削減できます。Auroraの料金は、SQL Serverよりも低コストで済む場合があります。

なぜ最適か:

既存のSQL Serverベースのアプリケーションをほとんど変更せずにクラウドに移行でき、コスト効率もよいため、最も効果的な解決策です。

B: AWS DMS + DynamoDB

解説:

*AWS Database Migration Service (AWS DMS)**を使用して、データベースの移行を効率的に行うことができます。これにより、オンプレミスのSQL ServerデータベースをAWSに移行できます。
Amazon DynamoDBを使用して、NoSQLのデータベースに移行します。しかし、アプリケーションがSQLベースで設計されている場合、DynamoDBに移行するためにはアプリケーションの大規模な変更が必要です。SQLとNoSQLの違いにより、データの設計や処理方法が大きく変わる可能性があります。

なぜ最適でないか:

SQLベースのアプリケーションに対してDynamoDBを使用するのは、大きな設計変更を伴います。そのため、既存アプリケーションに対しては不向きです。

C: EKS + RDS for SQL Server

解説:

Amazon EKSを使って、アプリケーションをコンテナ化し、Kubernetesクラスタで管理します。コンテナ化により、スケーラビリティと可搬性が向上しますが、コンテナ化にはアプリケーションの大規模な変更が必要です。
Amazon RDS for SQL Serverを使用することで、SQL Serverデータベースをフルマネージドで運用できます。これにより、データベースの運用負荷を削減し、スケーラビリティが向上します。

なぜ最適でないか:

コンテナ化にはアプリケーションコードの大規模な変更が必要です。また、RDS for SQL Serverは他のデータベースオプション（Aurora PostgreSQLなど）よりもコストが高くなる可能性があり、コスト削減の目的には適していないかもしれません。

D: Lambda + API Gateway + Athena

解説:

AWS Lambdaはサーバーレスでスケーラブルなコンピューティングサービスですが、完全なアプリケーションの移行にはアーキテクチャの再設計が必要です。
Amazon API Gatewayを使用して、API経由でフロントエンドとバックエンドを接続します。
Amazon S3にデータを保存し、Amazon Athenaを使ってデータクエリを実行します。AthenaはS3に保存されたデータに対してSQLクエリを実行できるサービスですが、リアルタイムのトランザクション処理には不向きです。

なぜ最適でないか:

アプリケーションをLambdaに完全に移行するには、設計とアーキテクチャの大規模な変更が必要です。また、Athenaはデータのクエリには適していますが、トランザクション処理には適していません。このため、オンライン小売業務に必要なリアルタイム処理には不向きです。

結論

最もコスト効率の良い解決策は選択肢Aです。理由は以下の通りです：

既存のアーキテクチャを最小限の変更で移行できる。

Aurora PostgreSQLはSQL Serverよりもコスト効率が良く、スケーラビリティや可用性が高いため、スケーリング問題を解決できます。

Babelfishを使うことで、SQL Serverのクエリをそのまま使用でき、アプリケーションの変更が最小限で済みます。

208-AWS SAP AWS 「理論・実践・一問道場」非標準メソッド

理論

AWS Global AcceleratorとAmazon API Gatewayのエッジ最適化されたAPIエンドポイントには、それぞれ異なる特性があります。以下に、これらのサービスの主要な違いを表形式で比較します。

特徴	AWS Global Accelerator	Amazon API Gateway（エッジ最適化APIエンドポイント）
目的	ユーザーのリクエストを最適なAWSリージョンのエンドポイントにルーティングし、全体的なパフォーマンスを向上させる	ユーザーがAPIに到達する距離を最短にすることでAPIレスポンスの高速化
利用シナリオ	- アプリケーションのエンドポイント（ALB、EC2、ELBなど）へのトラフィック最適化 - 複数リージョンにまたがるアプリケーション	- RESTful APIを公開 - APIのパフォーマンスを最適化するためにエッジ最適化を使用
トラフィックのルーティング	AWSのグローバルネットワークを使用し、最適なリージョンにトラフィックをルーティング	エッジロケーションを使用し、APIへのアクセスを最適化
非標準RESTメソッドのサポート	サポートあり (LINK, UNLINK, LOCK, UNLOCKなどに対応)	標準的なRESTメソッド（GET, POST, PUTなど）には対応しているが、非標準メソッドはサポートが限定的
グローバルなネットワークの利用	あり (AWSグローバルネットワークでルーティング)	あり (API Gatewayのエッジロケーションを利用)
接続先の設定	複数のAWSリージョンにまたがるサービスに接続可能	単一のAPI Gatewayエンドポイントに接続
遅延低減	グローバルに最適なエンドポイントにトラフィックをルーティングして遅延を低減	エッジ最適化により、ユーザーの最寄りのエッジロケーションでAPIリクエストを処理
用途に適したターゲット	アプリケーション全体のパフォーマンスを向上させる	APIのパフォーマンス向上に特化
トラフィックの分散	複数リージョンに対してトラフィックを分散し、最適化	一つのリージョンに対してAPIリクエストを処理
コスト	地理的に分散されたエンドポイントにトラフィックをルーティングするためコストが発生	エッジ最適化の使用においてはAPI Gatewayのコストが発生

要点

AWS Global Accelerator は、アプリケーション全体のトラフィックを最適化し、複数リージョンでの高可用性や低遅延を実現するために使用されます。非標準RESTメソッドのサポートがあり、グローバルなアプリケーションパフォーマンスを向上させます。

Amazon API Gatewayのエッジ最適化APIエンドポイント は、主にAPIの遅延を低減するために使用され、世界中のユーザーに対してAPIのパフォーマンスを最適化します。ただし、非標準RESTメソッドへの対応には限界があります。

これらのサービスは、使用目的やアプリケーションの要件に応じて適切に選択することが重要です。

ユーザーのリクエストは基本的には同じです。しかし、そのリクエストがどのように処理されるかは、AWS Global AcceleratorとAmazon API Gatewayで異なります。

ユーザーのリクエストの流れ（比較）

AWS Global Acceleratorの場合:

ユーザーがリクエストを送信します。

リクエストは、最寄りのAWSのエッジロケーションに到達します。

AWS Global Acceleratorが、最適なリージョンにリクエストをルーティングします（例えば、ユーザーが日本からアクセスしていれば、東京リージョンのサーバーにルーティング）。

最適なサーバーから応答が返され、ユーザーに届けられます。

Amazon API Gatewayの場合:

ユーザーがリクエストを送信します。

リクエストはAPI Gatewayに到達します。

API Gatewayは、そのリクエストに応じて、バックエンド（例えば、Lambda関数やEC2インスタンス）に処理を委任します。

バックエンドからの応答をユーザーに返します。

重要な違い：

Global Acceleratorは、リクエストを最適なリージョンにルーティングして、全体のパフォーマンスを向上させます。ユーザーは最寄りのエッジロケーションを通じて、最速で応答を受けます。

API Gatewayは、APIリクエストを管理し、適切なバックエンドに処理を委託する役割を果たします。APIの管理や認証、スロットリングなどを行います。

要するに：

Global Acceleratorは、リクエストの「ルーティングの最適化」や「パフォーマンス向上」を担います。

API Gatewayは、リクエストを受けて、アプリケーションに必要なデータやサービスを提供する「API管理」や「処理」の部分を担当します。

つまり、ユーザーのリクエストの最終的な目標は同じですが、それを実現する方法が異なるのです。

実践

略

一問道場

問題 #208

トピック 1

あるソフトウェア・アズ・ア・サービス（SaaS）プロバイダーは、Application Load Balancer（ALB）を通じてAPIを公開しています。ALBは、us-east-1リージョンに展開されたAmazon Elastic Kubernetes Service（Amazon EKS）クラスターに接続しています。公開されたAPIには、LINK、UNLINK、LOCK、UNLOCKという非標準のRESTメソッドが含まれています。米国以外のユーザーからは、これらのAPIに対して応答時間が長く、一貫性がないという報告があります。ソリューションアーキテクトは、運用オーバーヘッドを最小限に抑えつつ、この問題を解決する必要があります。

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

A. Amazon CloudFrontディストリビューションを追加し、ALBをオリジンとして設定する。

B. Amazon API Gatewayのエッジ最適化されたAPIエンドポイントを追加し、ALBをターゲットとして設定する。

C. AWS Global Acceleratorにアクセラレーターを追加し、ALBをオリジンとして設定する。

D. APIを2つの追加AWSリージョン（eu-west-1とap-southeast-2）に展開し、Amazon Route 53にレイテンシーに基づくルーティングレコードを追加する。

解説

AWS Global Acceleratorを使用することで、APIのパフォーマンスを向上させることができます。以下のポイントに関して解説します：

AWS Global Acceleratorの概要： AWS Global Acceleratorは、AWSのグローバルネットワークを活用して、トラフィックを最適なリージョンのエンドポイントにルーティングするサービスです。このルーティングは、クライアントの場所、エンドポイントのヘルス、設定されたポリシーに基づいて最適化されます。これにより、世界中のユーザーに対して低レイテンシで高パフォーマンスなアクセスを提供することができます。

ALBをオリジンとして設定する： Global Acceleratorを利用する場合、ALB（Application Load Balancer）をオリジン（接続先）として設定することができます。これにより、Global Acceleratorがユーザーからのリクエストを最適なALBエンドポイントに転送し、APIへのアクセスのパフォーマンスを改善します。

非標準RESTメソッドへの対応： APIで使用される非標準RESTメソッド（LINK、UNLINK、LOCK、UNLOCK）についても、AWS Global Acceleratorはサポートしています。これらのメソッドがAPIに組み込まれている場合でも、Global Acceleratorを使用して、ユーザーが安定した応答を得られるようにすることができます。

このソリューションの利点：

パフォーマンスの向上：AWSのグローバルネットワークを活用することで、APIリクエストの遅延を削減できます。特に、米国以外のユーザーに対しても、より高速で安定したアクセスを提供できます。

運用オーバーヘッドの削減：Global Acceleratorは、トラフィックルーティングを自動的に最適化し、管理の手間を最小限に抑えることができます。

非標準RESTメソッドのサポート：APIで非標準メソッドを使用していても、Global Acceleratorは問題なく機能し、全てのHTTPメソッドをサポートします。

したがって、このソリューションは、APIのパフォーマンス向上と運用効率化を実現し、特に地理的に分散したユーザー向けに最適です。

209-AWS SAP AWS 「理論・実践・一問道場」MQTTブローカー

理論

MQTTとIoTシステムの本質的知識：ブローカーの役割と設計のポイント

1. MQTTとは？

MQTT（Message Queuing Telemetry Transport）は、軽量で帯域幅を効率的に利用できるプロトコルです。特に、リソースが限られたIoTデバイス（センサーなど）や低帯域のネットワーク環境に適しています。

特徴:

パブリッシュ/サブスクライブモデル: クライアント間の直接通信ではなく、メッセージをブローカーを通じて送受信します。
軽量性: プロトコルが非常に軽量で、デバイスの計算リソースや通信帯域を効率的に使える。
リアルタイム通信: データのやり取りが非常に高速。

2. MQTTブローカーの役割

MQTTブローカーは、IoTシステムにおける通信の中心的なハブとして機能します。

基本的な役割:

メッセージの受信: センサーやデバイス（パブリッシャー）が送信するデータを受け取る。

メッセージの配信: 必要なデバイス（サブスクライバー）にデータを転送する。

トピックの管理: データを分類・ルーティングするための「トピック」を管理する。

接続管理: 多数のデバイスの接続を効率的に管理。

サーバ的側面:

クライアントが直接接続する「中心的なポイント」として、データ通信の安定性を提供する。

中継的側面:

パブリッシャーとサブスクライバー間でメッセージを転送する「ルータ」の役割を果たす。

3. MQTTブローカーをEC2で運用する課題

AWS EC2を使用してMQTTブローカーを運用する場合、以下の課題が発生する可能性があります：

スケーラビリティの問題: 単一のEC2インスタンスでは、多数のセンサーからの接続やデータの負荷に対応しきれなくなる。

フォールトトレランスの欠如: インスタンスが障害を起こした場合、システム全体が停止するリスクがある。

運用負荷: EC2インスタンスの監視やスケールアップの手動管理が必要。

4. AWSサービスを活用した信頼性の向上

課題を解決するために、AWSにはいくつかのマネージドサービスが用意されています。

A. AWS IoT Core

AWS IoT Coreは、IoTデバイス向けに設計されたフルマネージドのメッセージブローカーサービスです。

メリット:

自動スケーリングにより大量のデバイス接続を処理可能。
メッセージのセキュリティを標準で提供（TLS/SSL暗号化、認証管理）。
AWSサービス（DynamoDB、Lambdaなど）との簡単な統合。

B. Elastic Load Balancing (ELB) + Auto Scaling

EC2インスタンス上のMQTTブローカーを運用する場合、ELBとAuto Scalingを組み合わせることで高可用性を確保可能。

メリット:

ブローカーの負荷を分散。
負荷に応じてインスタンスを動的に増減。
障害が発生した場合の迅速な復旧。

C. AWS Global Accelerator

ネットワークレベルでの高速化と高可用性を提供。

MQTTブローカーを複数のリージョンに配置する場合、最適なエンドポイントにトラフィックをルーティング。

5. 高信頼性のIoTアーキテクチャ設計のポイント

以下を考慮してアーキテクチャを設計することで、信頼性が向上します：

スケーラブルなブローカーの選定:

マネージドサービス（AWS IoT Core）を利用するか、ELB＋Auto Scalingで動的拡張可能なブローカーを構築。

冗長性の確保:

単一障害点（Single Point of Failure）を避けるため、複数のインスタンスやリージョンを使用。

データの耐久性:

データ損失を防ぐため、DynamoDBやS3などの耐久性の高いデータストレージを利用。

セキュリティ管理:

TLS/SSLによる通信暗号化。

各デバイスに認証情報を割り当て、不正アクセスを防止。

コスト効率の最適化:

必要なトラフィック量に応じてリソースを動的に調整する。

6. 結論

IoTアーキテクチャにおいて、MQTTブローカーは通信の中核を担う重要なコンポーネントです。単一のEC2インスタンスに依存する構成は信頼性の低下を招く可能性があるため、AWSのマネージドサービスやスケーラビリティを考慮した設計を採用することが推奨されます。AWS IoT CoreやAuto Scalingを活用することで、高信頼性・高可用性を実現し、IoTデバイスからのデータ収集と処理を効率化することが可能です。

AWS IoT GreengrassとMQTTブローカーの違い

特徴	AWS IoT Core	AWS IoT Greengrass
設置場所	クラウド	エッジデバイス
用途	グローバルスケールのメッセージブローカー	ローカルでの処理と通信
オフライン対応	なし	あり
デバイス間通信	クラウド経由	ローカルネットワーク内で完結
計算処理	クラウド側で実行	デバイス側でAWS Lambdaを実行可能

AWS IoT Greengrassを使うべきケース

ローカルでリアルタイム処理が必要な場合:

センサーからのデータを即座に処理する必要がある。

ネットワークが不安定な場合:

インターネット接続なしでもシステムが継続して動作できる。

通信コストの削減が求められる場合:

大量のデータをクラウドに送るのではなく、必要な部分だけ送信する。

AWS IoT Greengrassを利用したシステム設計のポイント

クラウドとエッジの役割分担を明確にする:

例えば、データの即時処理はGreengrassで、長期保存や高度な分析はクラウドで行う。

セキュリティを確保:

デバイス認証とデータ暗号化を必ず実装。

適切なトピック設計:

MQTTトピックの命名規則を統一し、デバイス間通信を効率化。

結論

AWS IoT Greengrassは、エッジデバイスにおけるリアルタイム処理やオフライン対応を可能にする強力なツールです。特に、通信遅延やインターネット接続の不安定さが課題となるシステムにおいて、クラウドサービスとのシームレスな統合を実現し、IoTシステムの信頼性と効率性を向上させます。

実践

略

一問道場

質問 #209

トピック 1

ある会社がAWSクラウドでIoTアプリケーションを運用しています。この会社は、米国内の住宅からデータを収集する数百万のセンサーを保有しています。センサーはMQTTプロトコルを使用して接続し、カスタムMQTTブローカーにデータを送信します。MQTTブローカーはデータを単一のAmazon EC2インスタンスに保存しています。センサーはiot.example.comというドメイン名を使用してブローカーに接続しています。会社はAmazon Route 53をDNSサービスとして使用しており、データはAmazon DynamoDBに保存されています。

何度か、データ量がMQTTブローカーを過負荷にし、センサーからのデータが失われることがありました。会社はこのソリューションの信頼性を向上させる必要があります。

この要件を満たすソリューションはどれですか？

A. アプリケーションロードバランサー (ALB) と Auto Scaling グループを MQTT ブローカー用に作成します。ALB のターゲットとして Auto Scaling グループを使用します。Route 53 の DNS レコードをエイリアスレコードに更新し、このエイリアスレコードを ALB にポイントします。MQTT ブローカーを使用してデータを保存します。

B. AWS IoT Core を設定してセンサーのデータを受信します。カスタムドメインを作成して AWS IoT Core に接続できるように構成します。Route 53 の DNS レコードを AWS IoT Core Data-ATS エンドポイントにポイントするよう更新します。AWS IoT ルールを構成してデータを保存します。

C. ネットワークロードバランサー (NLB) を作成します。MQTT ブローカーをターゲットに設定します。AWS Global Accelerator を設定し、NLB をアクセラレーターのエンドポイントとして設定します。Route 53 の DNS レコードをマルチバリューアンサーレコードに更新し、Global Accelerator の IP アドレスを値として設定します。MQTT ブローカーを使用してデータを保存します。

D. AWS IoT Greengrass を設定してセンサーのデータを受信します。Route 53 の DNS レコードを AWS IoT Greengrass エンドポイントにポイントするように更新します。AWS IoT ルールを構成し、データを保存するために AWS Lambda 関数を呼び出します。

解説

この問題は、IoTアプリケーションの信頼性を向上させる方法を問うています。現在のシステムは、センサーからデータを受信するMQTTブローカーが単一のAmazon EC2インスタンスで動作しており、負荷が増加するとデータが失われる問題があります。

問題解決のポイント

負荷分散とスケーラビリティの実現

→ 現状の単一インスタンスでは、負荷増加時に対応できないため、柔軟に拡張可能な仕組みが必要。

データの信頼性向上

→ データを失わないように、より安定したサービスを利用する。

選択肢の比較

A: ALB + Auto Scaling

負荷分散を実現するが、MQTTプロトコルはHTTPベースではないため適切ではない。

B: AWS IoT Core

MQTTのネイティブサポートがあり、高スケーラビリティと信頼性を提供。最適な解決策。

C: NLB + Global Accelerator

負荷分散とグローバル接続を提供するが、データ信頼性の課題は解決できない。

D: AWS IoT Greengrass

主にローカルデバイスでの処理を強化するためのツールで、クラウド規模のMQTT処理には適さない。

正解: B (AWS IoT Core)

AWS IoT CoreはMQTTをネイティブにサポートし、センサーからのデータを効率的かつスケーラブルに処理できます。また、Route 53のDNS設定をAWS IoT Coreに変更することで、既存のシステムに影響を与えずに移行可能です。

解説まとめ

AWS IoT Coreは、IoTデータを安定的に処理するためのクラウドサービスで、スケーラビリティや信頼性を必要とするシステムに最適です。この問題では、MQTTプロトコルをネイティブサポートするサービスを利用することで、データの喪失問題を根本的に解決できます。

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

理論

以下に AWS Secrets Manager と AWS Key Management Service (KMS) の比較表を示します。これらは両方ともセキュリティに関連したサービスですが、主に異なる目的で使用されます。

以下は、AWS Secrets Manager と AWS KMS の比較表です。

特徴	AWS Secrets Manager	AWS KMS
主な目的	機密情報（APIキー、データベースパスワードなど）の管理	暗号化キーの管理とデータの暗号化・復号化
保存対象	APIキー、パスワード、秘密鍵などの機密情報	対称鍵や非対称鍵、データ暗号化キー
暗号化	内部で機密情報を暗号化、ユーザーは復号化して使用	ユーザーが暗号化/復号化キーを使って暗号化操作
自動ローテーション	サポート（機密情報の自動更新機能）	サポートしない（キー自体の自動更新は不可）
統合	AWSサービスやサードパーティ製品との統合が容易	主にAWSサービスでのデータ暗号化に使用
アクセス制御	IAMポリシーを使用してアクセス制御	KMSポリシーとIAMを使ってアクセス制御
利用用途	アプリケーションでの機密情報の安全な管理	データの暗号化、署名、復号化処理
価格	使用量に応じて料金が発生	キー管理操作やAPIリクエストに対する料金が発生

まとめ

AWS Secrets Manager は、アプリケーションの機密情報（パスワードやAPIキーなど）の保存・管理を行うサービスです。機密情報の自動ローテーションが可能です。

AWS KMS は、データの暗号化と復号化を行うためのキー管理サービスです。暗号化キーの管理が主な役割です。

どちらもセキュリティに重要な役割を果たしますが、Secrets Managerはアプリケーションの機密情報を扱い、KMSはデータの暗号化に特化しています。

補足

AWS Secrets Manager はシークレット情報（APIキーやデータベースの認証情報など）を安全に管理し、必要に応じてローテーションを自動的に実行します。シークレットの内容をアプリケーションや他のサービスで利用する場合に非常に便利です。

AWS KMS は暗号化キーを生成、管理、使用するためのサービスであり、データの暗号化や復号化に使用されます。シークレット自体を保存するわけではありませんが、Secrets Managerで保存されるシークレットの暗号化にも利用されています。

選択のポイント

シークレット情報（パスワードやAPIキーなど）を安全に保存し、必要に応じてローテーションを行いたい場合は Secrets Manager を選択します。

データの暗号化や復号化に関する管理を行いたい場合や、暗号化キーの管理をしたい場合は KMS を使用します。

実践

略

一問道場

質問 #210

トピック 1

会社はLinuxベースのAmazon EC2インスタンスを使用しています。ユーザーはEC2 SSHキーペアを使用してSSHでインスタンスにアクセスする必要があります。各マシンにはユニークなEC2キーペアが必要です。

会社は、リクエストに応じてすべてのEC2キーペアを自動的にローテーションし、キーを安全に暗号化された場所に保存するキーのローテーションポリシーを実装したいと考えています。キーのローテーション中に1分未満のダウンタイムは許容されます。

この要件を満たすソリューションはどれですか？

A: すべてのキーをAWS Secrets Managerに保存します。Secrets Managerのローテーションスケジュールを定義してAWS Lambda関数を呼び出し、新しいキーペアを生成します。EC2インスタンス上の公開キーを置き換え、Secrets Managerのプライベートキーを更新します。

B: すべてのキーをAWS Systems Managerの機能であるParameter Storeに文字列として保存します。Systems Managerのメンテナンスウィンドウを定義してAWS Lambda関数を呼び出し、新しいキーペアを生成します。EC2インスタンス上の公開キーを置き換え、Parameter Storeのプライベートキーを更新します。

C: EC2キーペアをAWS Key Management Service（AWS KMS）にインポートします。これらのキーペアに対して自動キーのローテーションを設定します。Amazon EventBridgeのスケジュールされたルールを作成し、AWS Lambda関数を呼び出してAWS KMSでキーのローテーションを開始します。

D: すべてのEC2インスタンスをAWS Systems Managerの機能であるFleet Managerに追加します。Systems Managerのメンテナンスウィンドウを定義し、Systems ManagerのRun Commandドキュメントを発行して新しいキーペアを生成し、Fleet Manager内のすべてのインスタンスの公開キーをローテーションします。