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

type

status

date

slug

summary

390-AWS SAP AWS 「理論・実践・一問道場」RDS リードレプリカ

理論

災害復旧（Disaster Recovery）におけるRPOとRTO

RPO（Recovery Point Objective）

データ損失を許容できる最大時間。

RPOが短い（数分以下）の場合、ほぼリアルタイムのデータ同期が必要。リードレプリカやデータレプリケーションを使用するのが一般的。

RTO（Recovery Time Objective）

システム復旧までの許容時間。

短いRTO（数分〜10分未満）を達成するには、フェイルオーバーの自動化や迅速な昇格プロセスが重要。

AWSにおける災害復旧ソリューションの選択肢

クロスリージョンリードレプリカ

概要: Amazon RDSで、別のリージョンにデータをリアルタイムでレプリケーションする機能。

特徴:

データがリアルタイムで同期されるため、RPOが短い。
フェイルオーバー時にリードレプリカをプライマリに昇格することで、RTOも短い。
Auroraよりもコストが低い。

適用ケース: 高速復旧が必要でコストを抑えたい場合。

Amazon Aurora Global Database

概要: Auroraのデータベースを複数のリージョンに配置して、低レイテンシでデータを同期。

特徴:

RPOは1秒未満、RTOは1分未満。
高性能だが、コストが高い。

適用ケース: 高速性と耐障害性が最優先の場合。

AWS DMS（Database Migration Service）

概要: データベース間のデータ移行や継続的なレプリケーションを提供。

特徴:

手動での設定が必要で運用コストが高い。
リアルタイム性が求められる場合には適さない。

適用ケース: 災害復旧よりデータ移行が主目的の場合。

スナップショットバックアップ

概要: データベースのスナップショットを取得して別のリージョンにコピー。

特徴:

復元には時間がかかり、RTOが長い。
コストは安いが、リアルタイム性が必要な場面には不向き。

適用ケース: 長期間保存や低コストが求められる場合。

選択基準

RPO/RTOが短い場合: クロスリージョンリードレプリカやAurora Global Databaseが適切。

コストを抑えたい場合: クロスリージョンリードレプリカがベストバランス。

長期間保存が目的の場合: スナップショットバックアップが有効。

AWSを使った災害復旧設計では、要件に応じて適切なソリューションを選ぶことが重要です。

実践

略

一問道場

質問 #390

ある企業が、RPO（復旧目標時点）が5分未満、RTO（復旧目標時間）が10分未満の要件を持つアプリケーションの設計段階にあります。ソリューションアーキテクチャチームは、データベースに約10 TBのデータが格納されると予測しています。この設計の一環として、セカンダリリージョンにフェイルオーバーする能力を持つデータベースソリューションを求めています。

どのソリューションが最低コストでこれらのビジネス要件を満たしますか？

選択肢

A. Amazon Aurora DB クラスターをデプロイし、クラスターのスナップショットを5分ごとに取得します。スナップショットが完了するたびに、それをセカンダリリージョンにコピーして、障害時のバックアップとして使用します。

B. Amazon RDS インスタンスをデプロイし、セカンダリリージョンにクロスリージョンのリードレプリカを作成します。障害発生時には、リードレプリカをプライマリに昇格させます。

C. Amazon Aurora DB クラスターをプライマリリージョンに、さらにセカンダリリージョンにもデプロイします。AWS DMS を使用して、セカンダリリージョンを同期状態に保ちます。

D. 同じリージョン内に Amazon RDS インスタンスとリードレプリカをデプロイします。障害発生時には、リードレプリカをプライマリに昇格させます。

解説

この問題では、以下の要件を満たすデータベースソリューションを選択する必要があります：

RPO（復旧目標時点）5分未満

データ損失を最小限に抑えるため、データが5分以上遅延することなく同期される必要があります。

RTO（復旧目標時間）10分未満

障害発生後、10分以内にサービスが復旧する必要があります。

コスト効率

最低コストでこれらの要件を満たすソリューションを選ぶ必要があります。

各選択肢の解説

A. Amazon Aurora DB クラスターをデプロイし、スナップショットを5分ごとに取得してセカンダリリージョンにコピー

スナップショットはRPOを確保する手段としては効果的ですが、RTO（10分以内に復旧）を満たすには適していません。スナップショットから復元するには時間がかかり、コストも高くなります。→ 不適切

B. Amazon RDS インスタンスをデプロイし、セカンダリリージョンにクロスリージョンのリードレプリカを作成

リードレプリカは自動的にデータを複製し、フェイルオーバー時にプライマリとして昇格させることが可能です。

クロスリージョンリードレプリカは、RPO（ほぼリアルタイム）とRTO（10分以内）の要件を満たします。また、Auroraよりもコストが低いです。→ 適切（最低コストで要件を満たす）

C. Amazon Aurora DB クラスターを2つのリージョンにデプロイし、AWS DMS で同期

Auroraは高性能ですが、AWS DMSを使った手動同期は設定が複雑で、コストが高くなります。また、RPOとRTOを確実に満たす保証がありません。→ 不適切

D. 同じリージョン内に Amazon RDS インスタンスとリードレプリカをデプロイ

同じリージョン内のリードレプリカは、クロスリージョンでの災害対策が必要な場合には適していません。セカンダリリージョンへのフェイルオーバーはできないため、要件を満たしません。→ 不適切

正解

B. Amazon RDS インスタンスをデプロイし、セカンダリリージョンにクロスリージョンのリードレプリカを作成

この選択肢は、RPOとRTOの両方の要件を満たしつつ、コスト効率が最も高いソリューションです。

392-AWS SAP AWS 「理論・実践・一問道場」データベースのメモリエラー

理論

1. API Gatewayとキャッシュ

API Gatewayは、REST APIを管理するためのサービスで、クライアントからのリクエストをLambda関数やバックエンドサービスにルーティングします。API Gatewayには、エッジ最適化エンドポイントやリージョナルエンドポイントがあり、これらは主にレイテンシーやスケーラビリティの最適化に使用されます。

キャッシュの有効化は、同じデータを繰り返し取得する場合に効果的です。API Gatewayのキャッシュ機能を使用すると、データベースの呼び出し頻度を減らし、レイテンシーを改善できます。

2. データベースのスケーラビリティとパフォーマンス

Amazon Aurora Serverlessは、需要に応じてスケーラブルにリソースを調整できるデータベースですが、頻繁なクエリが発生する環境では、スケールアップだけでは十分な効果が得られない場合があります。

読み取り専用レプリカや、クエリキャッシュを使用することで、データベースの読み取り負荷を分散し、パフォーマンスを向上させることができます。

3. ElastiCacheの利用

Amazon ElastiCacheは、メモリ内キャッシュサービスで、RedisやMemcachedをサポートしています。頻繁にアクセスされるデータをキャッシュすることで、データベースへの負荷を軽減し、レスポンス時間を短縮できます。

Redisは、高速でスケーラブルなインメモリデータストアであり、リアルタイムアプリケーションに最適です。Lambda関数でElastiCacheを使用することで、データベースの呼び出しを最小化し、キャッシュからデータを取得することが可能になります。

4. APIのトラフィック管理

スロットリング（API Gatewayのレート制限）は、リクエスト数を制限してシステムの過負荷を防ぐ手法ですが、リクエストの効率性を改善するためにはキャッシュを利用した方が効果的です。

トラフィックのピーク時にスロットリングを行うこともできますが、根本的な問題はデータベースのリクエスト数であり、スロットリングだけでは問題解決にはなりません。

結論

データベースのパフォーマンス向上には、キャッシュの利用が最も効果的です。ElastiCacheを用いて繰り返し実行されるクエリ結果をキャッシュし、データベースへのアクセスを削減することで、アプリケーションの効率を大幅に改善できます。また、API Gatewayやスロットリングはパフォーマンス改善には役立つが、キャッシュの使用が最も効率的です。

データベースのメモリエラーとは、データベースが要求された処理を実行するために十分なメモリを確保できず、処理が失敗する現象です。これにより、データベースが遅延したり、応答できなくなったりすることがあります。

実践

略

一問道場

質問 #392

あるレンタカー会社が、モバイルアプリにデータを提供するためにサーバーレスのREST APIを構築しました。このアプリは、以下で構成されています：

Amazon API Gateway API（リージョナルエンドポイント）

AWS Lambda関数

Amazon Aurora MySQL Serverless DBクラスター

最近、このAPIをパートナー企業のモバイルアプリに公開した結果、リクエスト数が大幅に増加し、断続的にデータベースのメモリエラーが発生するようになりました。

APIトラフィックの分析によると、クライアントが短期間に同じクエリに対して複数回のHTTP GETリクエストを送信していることがわかりました。トラフィックは営業時間中に集中し、特に休日やイベント時にピークを迎えます。

会社は追加の使用量をサポートする能力を向上させる必要がありますが、ソリューションに伴うコストの増加を最小限に抑えたいと考えています。

この要件を満たす戦略はどれですか？

選択肢

A. API Gatewayのリージョナルエンドポイントをエッジ最適化エンドポイントに変換し、プロダクションステージでキャッシュを有効化する。

B. Amazon ElastiCache for Redisを実装して、データベース呼び出しの結果をキャッシュに保存する。Lambda関数を修正してキャッシュを使用するようにする。

C. Aurora Serverless DBクラスターの構成を変更して、利用可能なメモリの最大値を増やす。

D. API Gatewayのプロダクションステージでスロットリングを有効にし、レートとバースト値を設定してリクエスト数を制限する。

解説

この問題では、サーバーレスREST APIのパフォーマンスとスケーラビリティを改善し、コストの増加を最小限に抑えつつ、増加したトラフィックを処理する方法を求めています。ここで重要なのは、データベースへの負荷を軽減し、リクエストの効率を向上させることです。以下は、選択肢の解説です。

A. API Gatewayのリージョナルエンドポイントをエッジ最適化エンドポイントに変換し、プロダクションステージでキャッシュを有効化する。

エッジ最適化エンドポイントは、ユーザーがどこからアクセスしても低遅延でAPIを提供するためにCloudFrontを利用するものです。しかし、キャッシュ機能を有効にすること自体はリクエストの負荷軽減に寄与しますが、このケースでは主にデータベースの負荷を軽減する必要があります。そのため、API Gatewayのエンドポイント変更とキャッシュ機能の設定は、データベースの負荷軽減にはあまり効果的ではありません。

不適切な選択肢です。

B. Amazon ElastiCache for Redisを実装して、データベース呼び出しの結果をキャッシュに保存する。Lambda関数を修正してキャッシュを使用するようにする。

Amazon ElastiCache for Redisは、高速なインメモリデータストアであり、データベースの結果をキャッシュして繰り返しのリクエストに対応することで、データベースの負荷を軽減します。この戦略は、同じクエリに対する繰り返しリクエストが多いため、非常に効果的です。Lambda関数がElastiCacheを利用して結果を取得できるようにすることで、データベースの呼び出し頻度を減らし、パフォーマンスを向上させることができます。

適切な選択肢です。

C. Aurora Serverless DBクラスターの構成を変更して、利用可能なメモリの最大値を増やす。

Aurora Serverlessはスケーラブルなデータベースサービスですが、メモリの増加だけではこの問題に対処するには不十分です。メモリ不足が原因ではなく、同じクエリへの頻繁なアクセスが問題であるため、メモリの増加では根本的な解決になりません。データベースの性能改善には、キャッシュの利用がより効果的です。

不適切な選択肢です。

D. API Gatewayのプロダクションステージでスロットリングを有効にし、レートとバースト値を設定してリクエスト数を制限する。

スロットリングはリクエストの量を制限する手段であり、トラフィックの過負荷を防ぐことはできますが、根本的な問題（同じクエリが繰り返し実行されること）には対処できません。スロットリングはトラフィックを制限する方法であって、キャッシュによる効率的なデータ処理とは異なります。

不適切な選択肢です。

結論

データベースへの呼び出しを効率化し、リソースの無駄を減らすためには、結果をキャッシュすることが最も効果的です。したがって、B. ElastiCache for Redisを利用するのが最も適切な選択肢です。

以下は、選択肢AとBの簡潔な比較です：

要素	A: API Gateway キャッシュ	B: Amazon ElastiCache for Redis
目的	APIレスポンスのキャッシュ	データベースクエリ結果のキャッシュ
効果	APIレスポンスを高速化	データベースの負荷を軽減
コスト	比較的低い	追加コストがかかる
データベースの負荷軽減	限定的	効果的に軽減
スケーラビリティ	限界あり	高いスケーラビリティ

結論：

AはAPIレスポンスの高速化に有効。

Bはデータベース負荷の軽減に有効。

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

理論

1. データベース移行の方法

データベースの移行にはいくつかの方法があります。主に以下のアプローチがあります。

フルロード (Full Load): すべてのデータを一度に転送します。大量のデータの移行には時間がかかりますが、移行が完了すればすぐに使用可能になります。

変更データキャプチャ (CDC: Change Data Capture): 初回のフルロード後に、データベースで行われた変更をリアルタイムで追跡・転送する技術です。これにより、移行後もオンプレミスとクラウド間でデータの同期が保たれ、最小限のダウンタイムで移行が可能になります。

2. AWSサービスの利用

AWS Database Migration Service (DMS): DMSは、オンプレミスからAWSへのデータベース移行をサポートするフルマネージドサービスです。フルロードとCDCを利用して、データ移行を高速化し、ダウンタイムを最小限に抑えることができます。

AWS Direct Connect: 物理的な専用ネットワーク接続をAWSとオンプレミスのネットワークに提供します。これにより、インターネット経由ではなく、安全で高帯域幅の接続が確立され、データ転送が高速かつセキュアになります。

AWS Key Management Service (KMS): データの暗号化を管理するサービスで、保存中のデータを暗号化するために利用します。DMSなどで使用される場合、AWS KMSのデフォルトキーまたはカスタムキーでデータを暗号化できます。

TLS (Transport Layer Security): インターネット経由の通信を暗号化するプロトコルで、データの転送中もセキュリティを確保します。

3. データの暗号化

保存中の暗号化 (At Rest): データが保存されている間に暗号化を適用する方法です。AWSでは、S3やRDSなどで管理された暗号化キー（AWS KMS）を利用してデータを暗号化できます。

転送中の暗号化 (In Transit): データが転送されている間に暗号化を適用する方法で、TLSを使用して通信を暗号化することが一般的です。

4. 最小限のダウンタイムのための戦略

データ移行中のダウンタイムを最小化するには、以下の方法が有効です。

変更データキャプチャ (CDC): フルロードの後に変更のみを転送することで、移行後のリアルタイム同期を実現し、ダウンタイムを最小化します。

DMSを使用した非同期転送: フルロードとCDCを組み合わせて使用することで、データ移行中のアプリケーションの停止を避け、サービスの中断を最小限に抑えることができます。

5. セキュリティ

データの機密性を保つために、保存中および転送中のデータの暗号化は必須です。AWSでは、S3やRDS、DMSでの暗号化を提供し、TLSを使用して転送中のデータも保護できます。

AWS Direct Connectを利用して、インターネット経由のデータ転送を避け、専用線を利用することでセキュリティが強化されます。

これらの技術とサービスを組み合わせることで、最小限のダウンタイムで安全にデータをAWSに移行でき、セキュリティ要件も満たすことが可能になります。

実践

略

一問道場

質問 #393

ある会社がオンプレミスのアプリケーションとMySQLデータベースをAWSに移行しています。このアプリケーションは高度に機密性の高いデータを処理しており、データベースには新しいデータが常に更新されています。データはインターネット経由で転送されてはなりません。また、データは転送中および保存中に暗号化されなければなりません。

データベースは5TBのサイズです。会社はすでにAmazon RDS for MySQL DBインスタンスにデータベーススキーマを作成しています。会社はAWSに1 GbpsのAWS Direct Connect接続を設定し、パブリックVIFとプライベートVIFを設定しています。

ソリューションアーキテクトは、最小限のダウンタイムでデータをAWSに移行するためのソリューションを設計する必要があります。

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

A. データベースバックアップを実行します。バックアップファイルをAWS Snowball Edge Storage Optimizedデバイスにコピーします。バックアップをAmazon S3にインポートします。保存中の暗号化にはAmazon S3管理暗号化キー（SSE-S3）を使用します。転送中の暗号化にはTLSを使用します。データをAmazon S3からDBインスタンスにインポートします。

B. AWS Database Migration Service（AWS DMS）を使用してデータをAWSに移行します。プライベートサブネットにDMSレプリケーションインスタンスを作成します。AWS DMS用にVPCエンドポイントを作成します。DMSタスクを構成して、オンプレミスのデータベースからDBインスタンスにフルロードおよび変更データキャプチャ（CDC）を使用してデータをコピーします。保存中の暗号化にはAWS Key Management Service（AWS KMS）のデフォルトキーを使用します。転送中の暗号化にはTLSを使用します。

C. データベースバックアップを実行します。AWS DataSyncを使用してバックアップファイルをAmazon S3に転送します。保存中の暗号化にはAmazon S3管理暗号化キー（SSE-S3）を使用します。転送中の暗号化にはTLSを使用します。データをAmazon S3からDBインスタンスにインポートします。

D. Amazon S3 File Gatewayを使用します。AWS PrivateLinkを使用してAmazon S3へのプライベート接続を設定します。データベースバックアップを実行します。バックアップファイルをAmazon S3にコピーします。保存中の暗号化にはAmazon S3管理暗号化キー（SSE-S3）を使用します。転送中の暗号化にはTLSを使用します。データをAmazon S3からDBインスタンスにインポートします。

解説

この質問では、オンプレミスのMySQLデータベースをAWSに移行するための最小限のダウンタイムでのソリューションを設計する必要があります。また、データはインターネット経由で転送されないことが求められ、転送中および保存中に暗号化される必要があります。

それぞれの選択肢について解説します。

A. Snowball Edgeを使用してバックアップを転送

AWS Snowball Edgeを使用して、データをオフラインで転送します。これにより、大量のデータを物理的にAWSに送信することができますが、インターネット経由での転送はありません。バックアップをAmazon S3にインポートし、そこからデータベースにロードします。

ただし、この方法では最小限のダウンタイムには対応しません。リアルタイムの変更や更新には対応できないため、最新のデータを反映するには不十分です。データの同期に時間がかかるため、ダウンタイムを最小化することができません。

B. AWS Database Migration Service（DMS）を使用

AWS Database Migration Service (DMS)は、データベース移行のための最適なサービスです。フルロードと変更データキャプチャ (CDC)を使用することで、最小限のダウンタイムでデータを移行できます。DMSはインターネット経由の転送を避けるために、プライベートVIFを使用したAWS Direct Connect経由で接続できます。

フルロードでは、最初に全データを移行し、その後CDCによってオンプレミスとAWS間の変更を同期します。このアプローチにより、ダウンタイムを最小化しつつ、最新のデータを正確に移行することができます。

AWS KMSを使用してデータを保存中に暗号化し、TLSで転送中も暗号化されるため、セキュリティ要件を満たしています。

C. DataSyncを使用してバックアップを転送

AWS DataSyncを使用してバックアップファイルをAmazon S3に転送する方法です。この方法も、インターネット経由での転送を回避できますが、データベースの変更の同期には対応していません。

フルバックアップを最初に転送し、そこからデータをRDSインスタンスにインポートすることになりますが、変更データをリアルタイムで同期することはできません。そのため、ダウンタイムを最小限にすることが難しく、移行後にデータが完全に同期するまでの時間が必要です。

D. S3 File Gatewayを使用

S3 File Gatewayは、オンプレミスのファイルシステムとAmazon S3との間でデータを転送するサービスです。しかし、これも変更データの同期には対応していないため、バックアップをS3に転送した後、データをRDSにインポートするだけです。この方法では、データの更新が反映されないため、最小限のダウンタイムを確保することができません。

最適な選択肢

B. AWS Database Migration Service (DMS) が最適な選択肢です。

フルロードとCDCを使用して、オンプレミスのデータベースからAWSへのデータ移行を行い、変更がリアルタイムで同期されます。

プライベートVIFを使用し、Direct Connect経由でデータが転送されるため、インターネット経由でのデータ転送を回避できます。

AWS KMSで暗号化され、TLSで転送中も暗号化されるため、セキュリティ要件にも適しています。

結論

B. AWS Database Migration Service (DMS) が最適なソリューションです。

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

理論

1. Amazon Elastic File System (EFS)

EFSは、AWSが提供する共有ファイルストレージサービスで、複数のEC2インスタンスから同時にアクセスできるPOSIX互換のストレージです。EFSは、スケーラブルで高可用性を備えており、複数のアベイラビリティゾーン（AZ）にデータを分散して保存することで耐障害性を提供します。

パフォーマンスモード：

General Purpose モード: 通常のワークロード向けに適しており、読み書き頻度が高いが、スループット要求が中程度のケースに最適です。
Max I/O モード: 高スループットや低レイテンシが要求される大規模なワークロード向けに最適化されています。このモードは、より多くのEC2インスタンスがアクセスする場合でも、高いパフォーマンスを維持します。

2. Elastic Block Store (EBS)

EBSは、EC2インスタンスにアタッチできるブロックレベルのストレージです。io2ボリュームは、高性能なブロックストレージで、特にI/O集約型のアプリケーションに向いています。しかし、EBSは一度に1つのインスタンスにしか接続できないため、複数のインスタンスからアクセスする共有ストレージには不向きです。

3. Network File System (NFS)

NFSは、ネットワークを通じてファイルシステムを共有するためのプロトコルで、POSIX互換性を提供します。LinuxやUNIX環境でよく使われ、特に分散ファイルシステムで重要な役割を果たします。AWSでは、EFSをNFSサーバーとして利用することで、複数のEC2インスタンスが共有アクセスすることができます。

4. 高可用性と耐障害性

高可用性と耐障害性を実現するために、AWSではデータが複数のアベイラビリティゾーンに分散して配置される仕組みを採用しています。これにより、1つのAZが障害を起こしても、システム全体はダウンせずに運用を続けることができます。

5. スループットとパフォーマンス

大規模なビッグデータ分析システムや高性能が求められるワークロードでは、高スループットと低遅延が重要です。EFSのMax I/O モードは、特にスループットとパフォーマンスが重要な場合に最適化されており、大規模なクラスター環境に適しています。

この知識を理解することで、AWSのストレージサービスを適切に選択し、要件に最適なソリューションを提供することができます。

実践

略

一問道場

質問 #394

ある会社がAWSでビッグデータ分析用の新しいクラスターを展開しています。このクラスターは、複数のアベイラビリティゾーンに分散された多くのLinux Amazon EC2インスタンスで実行されます。

クラスター内のすべてのノードは、共通の基盤となるファイルストレージに対して読み書きアクセスを持つ必要があります。ファイルストレージは、以下の要件を満たす必要があります：

高い可用性

高い耐障害性

Portable Operating System Interface（POSIX）との互換性

高いスループットの対応

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

A. AWS Storage GatewayファイルゲートウェイNFSファイル共有をAmazon S3バケットに接続して、クラスター内の各EC2インスタンスにNFSファイル共有をマウントする。

B. 新しいAmazon Elastic File System（Amazon EFS）ファイルシステムをGeneral Purposeパフォーマンスモードでプロビジョニングし、クラスター内の各EC2インスタンスにEFSファイルシステムをマウントする。

C. 新しいAmazon Elastic Block Store（Amazon EBS）ボリュームをio2ボリュームタイプでプロビジョニングし、EBSボリュームをクラスター内のすべてのEC2インスタンスにアタッチする。

D. 新しいAmazon Elastic File System（Amazon EFS）ファイルシステムをMax I/Oパフォーマンスモードでプロビジョニングし、クラスター内の各EC2インスタンスにEFSファイルシステムをマウントする。

解説

この問題に関する解説を行います。要件を順に確認し、どのストレージソリューションが最適かを見ていきます。

要件：

高可用性と耐障害性

ストレージソリューションは、複数のアベイラビリティゾーン（AZ）にまたがってデータを保持し、サービスの中断や障害から保護されている必要があります。

POSIX互換

POSIX（Portable Operating System Interface）は、特にLinuxやUNIXベースのシステムでファイルシステムの動作に関連する標準規格であり、NFS（Network File System）などのプロトコルを使ってファイルアクセスを行う場合に求められます。

高いスループット

ビッグデータ分析クラスターでは、ファイルストレージのアクセス速度が重要です。特に大量のデータを高速に読み書きする必要があります。

各選択肢の評価：

A. AWS Storage Gateway file gateway NFS file share

Storage Gatewayは、オンプレミス環境とAWSクラウドを接続するためのハイブリッドストレージサービスです。ファイルゲートウェイは、オンプレミスからS3へデータをアクセスする際にNFSを提供します。しかし、このアプローチは、ストレージがS3に基づいており、S3自体はPOSIX互換ではなく、高いスループットや低遅延アクセスには向いていません。したがって、この選択肢は要件を満たしません。

B. Amazon Elastic File System (EFS) - General Purpose performance mode

EFSは、複数のEC2インスタンスから同時にアクセス可能な共有ファイルシステムで、POSIX互換を持つ完全に管理されたファイルシステムです。General Purposeパフォーマンスモードは、読み書きが頻繁に行われる小規模～中規模なワークロード向けに最適化されています。EFSは複数のAZにデータを分散させ、高可用性と耐障害性を提供します。ビッグデータの分析用に十分なスループットも提供できるため、この選択肢は要件を満たします。

C. Amazon Elastic Block Store (EBS) - io2 volume type

EBSは、EC2インスタンスに直接接続されるブロックストレージです。io2ボリュームは高性能を提供しますが、EBSボリュームは複数のEC2インスタンスで同時にアクセスすることはできません。したがって、複数のインスタンスで共有アクセスを必要とするクラスターには適していません。このため、この選択肢は不適切です。

D. Amazon Elastic File System (EFS) - Max I/O performance mode

Max I/Oパフォーマンスモードは、EFSのもう一つのパフォーマンスモードで、非常に高いスループットを要求する大規模なワークロード向けに最適化されています。これにより、より多くのインスタンスがファイルシステムにアクセスする場合でも、非常に高いパフォーマンスを提供できます。ビッグデータ分析クラスターにはこのモードが適しており、高可用性や耐障害性、POSIX互換を持ちながら、非常に高いスループットもサポートするため、この選択肢は要件を満たします。

結論：

BとDが適切な選択肢ですが、DのMax I/Oパフォーマンスモードは、より高いスループットとパフォーマンスが必要なシナリオに最適で、要件に完全に合致します。したがって、最適な解答は D です。

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

理論

1. AWSの災害復旧（DR）戦略

災害復旧（DR）戦略は、システムが予期せぬ障害に直面した際にサービスを迅速に回復させるための計画です。DR戦略では以下の要素が重要です：

RTO（Recovery Time Objective）: サービスが復旧するまでの最大許容時間。

RPO（Recovery Point Objective）: データ損失を許容する最大の時間幅。

災害復旧戦略を構築する際、以下の点に注意する必要があります：

自動フェイルオーバーを活用することで、手動での介入を最小限にし、復旧時間を短縮。

データの複製を活用して、障害発生時に最小限のデータ損失で済むようにする。

2. Aurora MySQLグローバルデータベース

Aurora MySQLグローバルデータベースは、複数リージョンにわたってデータをリアルタイムで同期し、障害発生時に迅速にプライマリリージョンを切り替えることができます。これにより、以下の利点が得られます：

低遅延のリージョン間データ複製: リージョン間でのデータの同期が迅速で、レプリカの整合性を保ちながら複数のリージョンにわたる高可用性を実現します。

フェイルオーバーの迅速化: 災害発生時に、システムは自動的にバックアップリージョンに切り替わり、復旧時間（RTO）を最小限に抑えることができます。

3. Aurora Serverless v1とグローバルデータベース

Aurora Serverless v1は、スケーラブルでコスト効率の良いデータベースサービスですが、複数リージョン間でのデータ同期や自動フェイルオーバーには制限があります。災害復旧においては、Aurora MySQLグローバルデータベースが推奨されます。

4. AWS SAM（Serverless Application Model）

AWS SAMは、サーバーレスアプリケーションを簡単にデプロイできるツールです。主にLambda関数やAPI Gatewayのデプロイに使用されますが、災害復旧の際には、手動でのランブック（手順書）を使用するよりも、自動化されたフェイルオーバーやリカバリ機能を活用する方が理想的です。

5. 自動化と手動介入

災害復旧戦略においては、できるだけ自動化を活用することが重要です。自動フェイルオーバー機能やバックアップシステムを活用することで、復旧時間を短縮し、人的エラーを防ぐことができます。

重要なポイント

RTOとRPOを理解し、それに応じたシステム設計を行う。

Aurora MySQLグローバルデータベースを使用して、複数リージョンでのデータ同期と自動フェイルオーバーを実現。

AWS SAMはデプロイメントの自動化に便利ですが、災害復旧時には自動化された復旧機能を優先することが理想的。

このような戦略を用いることで、災害発生時でも最小限のダウンタイムとデータ損失でサービスを復旧させることができます。

実践

略

一問道場

質問 #395

ある会社は、AWSでソフトウェア・アズ・ア・サービス（SaaS）ソリューションをホストしています。このソリューションには、HTTPSエンドポイントを提供するAmazon API Gateway APIがあります。このAPIは、計算処理のためにAWS Lambda関数を使用しています。Lambda関数は、Amazon Aurora Serverless v1データベースにデータを格納します。会社は、AWS Serverless Application Model（AWS SAM）を使用してソリューションをデプロイしました。ソリューションは複数のアベイラビリティゾーンにまたがっており、災害復旧（DR）計画はありません。

ソリューションアーキテクトは、別のAWSリージョンでソリューションを復旧できるDR戦略を設計しなければなりません。このソリューションには、5分のRTO（復旧時間目標）と1分のRPO（復旧時点目標）があります。

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

選択肢

A. Aurora Serverless v1データベースのリードレプリカをターゲットリージョンに作成する。AWS SAMを使用してターゲットリージョンにソリューションをデプロイするためのランブックを作成する。災害時にはリードレプリカをプライマリに昇格させる。

B. Aurora Serverless v1データベースを、ソースリージョンとターゲットリージョンにまたがる標準のAurora MySQLグローバルデータベースに変更する。AWS SAMを使用してターゲットリージョンにソリューションをデプロイするためのランブックを作成する。

C. ターゲットリージョンに複数のライターインスタンスを持つAurora Serverless v1 DBクラスターを作成する。ターゲットリージョンでソリューションを起動する。2つのリージョンのソリューションをアクティブ-パッシブ構成で機能させるように設定する。

D. Aurora Serverless v1データベースを、ソースリージョンとターゲットリージョンにまたがる標準のAurora MySQLグローバルデータベースに変更する。ターゲットリージョンでソリューションを起動する。2つのリージョンのソリューションをアクティブ-パッシブ構成で機能させるように設定する。

解説

このシナリオでは、災害復旧（DR）戦略を設計するために、5分のRTO（復旧時間目標）と1分のRPO（復旧時点目標）を満たす必要があります。要件に基づいて、ソリューションアーキテクトは以下の選択肢から最適な戦略を選択する必要があります。

各選択肢の評価

選択肢A:

Aurora Serverless v1データベースのリードレプリカをターゲットリージョンに作成し、災害時にリードレプリカをプライマリに昇格させる方法です。
問題点: Aurora Serverless v1は、標準のAurora MySQLグローバルデータベースのように、複数リージョンにわたる高可用性をサポートしていません。リードレプリカは、常にプライマリでないため、復旧の際に昇格する時間がかかり、RTOを満たせない可能性があります。また、1分のRPOも達成しにくいでしょう。

選択肢B:

Aurora Serverless v1を、標準のAurora MySQLグローバルデータベースに変更する方法です。グローバルデータベースは、複数リージョンで同期的にデータを複製し、災害復旧時に迅速にプライマリリージョンを切り替えることができます。
AWS SAM（Serverless Application Model）は、サーバーレスアーキテクチャを構成しデプロイするためのツールです
良い点: Aurora MySQLグローバルデータベースは、高可用性と低い復旧時間を提供します。これにより、RTOとRPOを満たすことができるため、災害復旧戦略として適切です。

選択肢C:

ターゲットリージョンに複数のライターインスタンスを持つAurora Serverless v1 DBクラスターを作成し、アクティブ-パッシブ構成で機能させる方法です。
問題点: Aurora Serverless v1は、複数のライターインスタンスをサポートしていません。また、アクティブ-パッシブ構成は、このシナリオにおいて災害復旧要件に適合しません。Aurora Serverless v1は、スケーリングの方法に制限があるため、RTOやRPOを満たすことが難しいです。

選択肢D:

Aurora Serverless v1を、標準のAurora MySQLグローバルデータベースに変更し、アクティブ-パッシブ構成を作成する方法です。
良い点: Aurora MySQLグローバルデータベースは、複数リージョンでデータを同期的に複製し、迅速にプライマリリージョンを切り替えることができ、RTOとRPOの要件を満たします。これにより、災害復旧戦略において最適な選択肢です。

結論

選択肢 D が最も適切です。Aurora MySQLグローバルデータベースを使用することで、複数のリージョンにわたる高可用性を実現し、災害復旧時に5分のRTOと1分のRPOを達成することができます。

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

理論

1. DynamoDB Accelerator (DAX)

DAXは、Amazon DynamoDBに対するインメモリキャッシュの機能を提供するサービスです。DAXを使用すると、読み取りリクエストのレイテンシを大幅に削減し、データベースに対する負荷を軽減できます。特に、読み取りが多く発生するアプリケーションにおいて、パフォーマンスの向上とコスト削減に役立ちます。

メリット: DynamoDBの高速化、低レイテンシの読み取り、データベースの負荷軽減

ユースケース: リアルタイムデータ処理、頻繁にアクセスされるデータのキャッシュ

2. Amazon ElastiCache

ElastiCacheは、Amazonのマネージドキャッシュサービスで、RedisやMemcachedをサポートしています。これを使用することで、データベースやアプリケーションのパフォーマンスを向上させるために、データをメモリ内で高速にキャッシュできます。特に、頻繁にアクセスされるデータをキャッシュすることで、データベースアクセスを削減し、アプリケーションのレスポンス時間を短縮できます。

Redis vs Memcached: Redisは高機能なデータストア（データ永続化や高度なデータ構造をサポート）、Memcachedはシンプルなキャッシュ用ストア（簡単なキー・バリュー型データを処理）です。

3. Auto Scaling

Auto Scalingは、Amazon EC2インスタンスの数を自動で調整できるサービスで、トラフィックやリソースの負荷に応じてスケーリングを行います。これにより、アプリケーションは負荷に応じてリソースを最適化し、コスト効率よく運用できます。

種類:

スケーリングポリシー: 例えば、CPU使用率が高くなったときにインスタンスを追加する
スケーリング対象: Auto Scalingは、EC2インスタンスや他のリソース（例えば、ALBのターゲットグループ）に対しても適用できます

4. Application Load Balancer (ALB)

ALBは、複数のEC2インスタンス間でトラフィックを負荷分散するためのサービスです。特に、アプリケーション層での負荷分散（HTTP/HTTPS）に使用され、複雑なルーティングやターゲットグループに基づくトラフィック分散が可能です。

特徴: コンテナ化されたアプリケーションやマイクロサービスに適しており、複数のターゲットグループにトラフィックを分散できます。

5. Amazon CloudFront

CloudFrontは、コンテンツ配信ネットワーク（CDN）サービスで、静的コンテンツや動的コンテンツを高速に配信します。Edge locations（世界中のサーバー）を利用することで、ユーザーに近いサーバーからコンテンツを配信し、レイテンシを最小化します。

ユースケース: 静的コンテンツ（画像、ビデオ）、動的コンテンツ（WebアプリケーションのAPI）などの高速配信

6. Amazon Route 53

Route 53は、DNS（ドメインネームシステム）サービスで、トラフィックを適切なリソースにルーティングします。Route 53は、リソースの可用性やヘルスチェックに基づいてルーティングポリシーを設定できます。

ルーティングポリシー:

シンプルルーティング: 単純にIPアドレスにルーティング
ヘルスチェックルーティング: サービスが正常に動作していない場合に他のリソースにルーティング
マルチバリュー: 複数のIPアドレスを返し、負荷分散を実現

7. キャッシュ戦略

アプリケーションのパフォーマンスを向上させるために、キャッシュ戦略は重要です。一般的なキャッシュ戦略には、次のようなものがあります。

読み取りキャッシュ: 頻繁にアクセスされるデータをキャッシュして、データベースへの負荷を軽減

コンテンツ配信キャッシュ: 静的コンテンツや一時的に変動するコンテンツをCDN（CloudFront）を使ってキャッシュし、配信速度を向上

まとめ

コンテンツ更新時にアプリケーションが高負荷に耐えられるように、キャッシュ、スケーリング、負荷分散をうまく組み合わせる必要があります。DAXやElastiCacheなどのキャッシュ技術、Auto Scalingによるスケーリング、ALBやCloudFrontによるトラフィック分散の組み合わせが重要です。これにより、アプリケーションは高可用性を保ちながら、スムーズにコンテンツ更新時の負荷を処理できます。

実践

略

一問道場

質問 #396

ある会社は旅行代理店のチェーンを所有しており、AWSクラウド上でアプリケーションを運用しています。会社の従業員は、旅行先に関する情報を検索するためにアプリケーションを使用しています。旅行先のコンテンツは年に4回更新されます。

2つの固定されたAmazon EC2インスタンスがアプリケーションにサービスを提供しています。会社は、travel.example.comというAmazon Route 53のパブリックホステッドゾーンを使用しており、そこにはEC2インスタンスのElastic IPアドレスを返すマルチバリューレコードがあります。アプリケーションは、Amazon DynamoDBを主なデータストアとして使用しています。会社は、キャッシュソリューションとして自己ホストされたRedisインスタンスを使用しています。

コンテンツ更新時には、EC2インスタンスとキャッシュソリューションにかかる負荷が急増し、この負荷の増加が原因でダウンタイムが発生することがあります。ソリューションアーキテクトは、アプリケーションを更新して、アプリケーションが高可用性を持ち、コンテンツ更新によって発生する負荷に対応できるようにする必要があります。

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

A. DynamoDB Accelerator (DAX) をインメモリキャッシュとして設定します。アプリケーションをDAXに対応させます。EC2インスタンス用にAuto Scalingグループを作成します。Application Load Balancer (ALB)を作成し、ALBのターゲットとしてAuto Scalingグループを設定します。Route 53のレコードを更新して、ALBのDNSエイリアスをターゲットとするシンプルルーティングポリシーを使用します。コンテンツ更新前にEC2インスタンスのスケーリングをスケジュールします。

B. Amazon ElastiCache for Redisを設定します。アプリケーションをElastiCacheに対応させます。EC2インスタンス用にAuto Scalingグループを作成します。Amazon CloudFrontディストリビューションを作成し、Auto Scalingグループをディストリビューションのオリジンとして設定します。Route 53のレコードを更新して、CloudFrontディストリビューションのDNSエイリアスをターゲットとするシンプルルーティングポリシーを使用します。コンテンツ更新前にEC2インスタンスを手動でスケーリングします。

C. Amazon ElastiCache for Memcachedを設定します。アプリケーションをElastiCacheに対応させます。EC2インスタンス用にAuto Scalingグループを作成します。Application Load Balancer(ALB)を作成し、ALBのターゲットとしてAuto Scalingグループを設定します。Route 53のレコードを更新して、ALBのDNSエイリアスをターゲットとするシンプルルーティングポリシーを使用します。コンテンツ更新前にアプリケーションのスケーリングをスケジュールします。

D. DynamoDB Accelerator (DAX) をインメモリキャッシュとして設定します。アプリケーションをDAXに対応させます。EC2インスタンス用にAuto Scalingグループを作成します。Amazon CloudFrontディストリビューションを作成し、Auto Scalingグループをディストリビューションのオリジンとして設定します。Route 53のレコードを更新して、CloudFrontディストリビューションのDNSエイリアスをターゲットとするシンプルルーティングポリシーを使用します。コンテンツ更新前にEC2インスタンスを手動でスケーリングします。

解説

この問題では、旅行代理店のアプリケーションに対して、コンテンツ更新による急激な負荷の増加に対応できるようにアーキテクチャを更新する方法を求めています。要件としては、アプリケーションが高可用性を持ち、コンテンツ更新による負荷に耐えられるようにする必要があります。また、負荷の増加に対応するために、キャッシュやスケーリングの手法を活用することが求められています。

各選択肢の解説:

A. DynamoDB Accelerator (DAX) と Auto Scaling グループを使う方法

DAX（DynamoDB Accelerator）は、DynamoDB用のインメモリキャッシュサービスで、DynamoDBへの読み取り負荷を大幅に軽減できます。これにより、コンテンツ更新時の急増する読み取り要求に対応できます。

Auto Scalingを利用することで、EC2インスタンスの数を自動的に調整し、トラフィックの増加に対応できます。

*Application Load Balancer (ALB)**を使って、トラフィックを適切に分散させ、可用性を高めます。

Route 53の設定でALBをターゲットとし、シンプルなルーティングポリシーを用いることで、トラフィックをALBに正しくルーティングします。

この構成は、コンテンツ更新の際に急激に負荷が増えた場合でも、DAXによってDynamoDBの負荷が軽減され、EC2インスタンスも自動的にスケールアップし、可用性を確保できるため、最適な選択肢です。

B. ElastiCache for Redis と CloudFront を使う方法

ElastiCache for Redisはキャッシュ用のマネージドサービスで、Redisは高速なインメモリキャッシュを提供します。これを使うことで、データベースへのアクセスを減らし、パフォーマンスを向上させることができます。

Auto Scalingを使ってEC2インスタンスのスケーリングを行い、負荷に対応します。

CloudFrontは、コンテンツ配信のためのCDN（コンテンツ配信ネットワーク）ですが、Auto Scalingグループをオリジンとして設定するのは一般的ではなく、直接的なパフォーマンス向上には繋がりません。

また、EC2インスタンスを手動でスケーリングするという点が、効果的な自動化と比較して欠点になります。

この選択肢は、CloudFrontがEC2インスタンスのトラフィック分散に使われるため、ELB（ALB）を使う方がより適切です。CloudFrontの使用目的に合わないため、最適とは言えません。

C. ElastiCache for Memcached と ALB を使う方法

ElastiCache for Memcachedもインメモリキャッシュサービスで、Redisに似た役割を果たしますが、Redisと比較して機能が少し異なり、特定のユースケースに適しています。

ALBを利用することで、EC2インスタンスへのトラフィックを効率的に分散できます。

しかし、スケーリング前に手動で対応する必要があり、スケーリングの自動化が欠如しています。コンテンツ更新時に手動でスケーリングするのは、運用の効率性が低く、負荷に対する適切な対応が遅れる可能性があります。

この選択肢は、手動スケーリングが前提となっており、効率的な自動スケーリングを活用できないため、最適ではありません。

D. DAX と CloudFront を使う方法

DAXを使用してDynamoDBのキャッシュを高速化するのは適切ですが、CloudFrontをオリジンとして使うのは一般的ではありません。CloudFrontはCDNで、コンテンツ配信に特化しているため、EC2インスタンスのオリジンとして設定するのは無理があります。

EC2インスタンスの手動スケーリングは、コンテンツ更新時にスケーリングが遅れる可能性があり、負荷に迅速に対応できないため、最適ではありません。

この選択肢も、CloudFrontの使用方法に誤りがあり、最適ではありません。

結論:

最適な選択肢は A です。DynamoDBのインメモリキャッシュとしてDAXを使用し、EC2インスタンスの自動スケーリングを活用することで、コンテンツ更新時の急激な負荷に対応し、アプリケーションの可用性とパフォーマンスを向上させることができます。

397-AWS SAP AWS 「理論・実践・一問道場」プッシュ通知 SNS

理論

プッシュ通知とは、モバイルデバイスやウェブブラウザなどに、アプリケーションやサービスから送られる通知のことです。ユーザーがアプリケーションを開いていなくても、通知がリアルタイムで届くのが特徴です。プッシュ通知は、ユーザーに重要な情報をタイムリーに伝える手段として非常に効果的です。

プッシュ通知の主な特徴

リアルタイム配信: ユーザーがアプリを開いていなくても、通知は即座に届きます。これにより、重要な情報をタイムリーに届けることができます。

非侵襲的: プッシュ通知は、ユーザーがアプリを開いていない時にも届くため、アプリの外で情報を伝えることができます。ユーザーが通知をタップすると、そのアプリが開かれることが多いです。

インタラクション: 通常、プッシュ通知にはユーザーがアクションを取れるボタンが含まれており、これによってユーザーが特定のアクションを取ることができます（例: 「今すぐ確認」や「購入する」などのボタン）。

プッシュ通知の使用例

ニュースアプリ: 新しい記事が公開された際にユーザーに通知を送信する。

Eコマースアプリ: セール情報やカートに入れている商品が割引になった場合に通知を送る。

SNSアプリ: フォロワーのアクティビティやメッセージが届いた場合に通知を送る。

ゲームアプリ: ゲーム内イベントや報酬の受け取りを知らせる。

プッシュ通知の仕組み

サーバー側でプッシュ通知の内容（メッセージなど）が作成されます。

通知サービス（例えば、Apple Push Notification Service (APNS) や Firebase Cloud Messaging (FCM)）を使って、その通知をターゲットデバイスに送信します。

通知を受け取ったデバイスは、それを通知センター（Androidでは「通知バー」、iOSでは「ロック画面」）に表示します。

プッシュ通知は、ユーザーエンゲージメントを高め、アプリケーションの利用頻度を増やすための有効な手段です。

1. スケーラブルなストレージ

Amazon S3（Simple Storage Service）は、可用性が高く、スケーラブルなストレージサービスであり、大量のデータを保存するのに最適です。特に、アップロードされる画像などのメディアファイルのストレージに頻繁に使用されます。

S3には、データの保持、バージョニング、そしてアクセス制御の機能もあり、これらはデータの管理に役立ちます。

2. イベント駆動型アーキテクチャ

S3イベント通知を利用することで、ファイルがアップロードされた際にトリガーされる処理を指定できます。これにより、S3にファイルが追加されるたびに、その後の処理（例えば、画像処理）を自動的に開始できます。

通常、イベント通知は、Amazon SQS（Simple Queue Service）やSNS（Simple Notification Service）を使って、別のサービス（Lambda関数など）をトリガーするために使用されます。

3. スケーラブルな処理

AWS Lambdaはサーバーレスコンピューティングサービスであり、イベント駆動型で画像処理のようなタスクをスケーラブルに処理できます。Lambda関数はリソースを動的にスケールできるため、トラフィックのピーク時でも自動的に処理能力を拡張できます。

処理の内容としては、例えば、画像のリサイズやフォーマット変換、圧縮などが考えられます。

4. メッセージキューによる非同期処理

Amazon SQSやAmazon MQを使用して、メッセージングシステムを構築し、画像処理のタスクを非同期に処理できます。SQSは、スケーラブルで高耐障害性のメッセージキューサービスであり、大量のリクエストを処理するために適しています。

メッセージがキューに追加されると、Lambda関数がメッセージを受け取り、処理を行います。

5. 通知機能

処理が完了した際に、ユーザーに通知するために、Amazon SNS（プッシュ通知）やAmazon SES（メール通知）を使用することができます。これにより、ユーザーにリアルタイムで通知を送信できます。

SNSは複数の配信方法（モバイルプッシュ通知、Eメール、SMSなど）を提供し、SESはEメールを利用した通知に特化しています。

6. スケジュールと自動化

処理がピーク時に集中することを見越して、オートスケーリングやスケジュールベースのスケーリングを利用することで、トラフィックの増加に対応できます。例えば、画像アップロードのピーク時間に合わせて、EC2インスタンスのスケーリングを自動で調整できます。

まとめ

Amazon S3で画像を保存し、S3イベント通知を活用して画像アップロードをトリガーに、AWS Lambdaで非同期に処理を行い、その結果をSNSやSESでユーザーに通知することで、高スケーラブルで効率的な画像処理のシステムを構築できます。

実践

略

一問道場

質問 #397

ある企業は、カスタムモバイルアプリを使用してモバイルデバイスからアップロードされる画像データを保存および処理する必要があります。使用は平日の午前8時から午後5時の間にピークがあり、1分あたり数千のアップロードがあります。アプリはその他の時間帯にはほとんど使用されません。画像処理が完了した際にユーザーに通知されます。

画像処理が負荷に対応できるようにスケールするために、ソリューションアーキテクトはどのアクションを組み合わせて実行すべきですか？（3つ選んでください）

A. モバイルソフトウェアからファイルを直接Amazon S3にアップロードする。S3イベント通知を使用してAmazon MQキューにメッセージを作成する。

B. モバイルソフトウェアからファイルを直接Amazon S3にアップロードする。S3イベント通知を使用してAmazon Simple Queue Service (Amazon SQS)標準キューにメッセージを作成する。

C. キューにメッセージがある場合にAWS Lambda関数を呼び出して画像処理を実行する。

D. キューにメッセージがある場合にS3バッチ操作ジョブを呼び出して画像処理を実行する。

E. 処理が完了した際にAmazon Simple Notification Service (Amazon SNS)を使用してモバイルアプリにプッシュ通知を送信する。

F. 処理が完了した際にAmazon Simple Email Service (Amazon SES)を使用してモバイルアプリにプッシュ通知を送信する。

解説

この問題では、スケーラブルな画像処理ソリューションを構築するための最適なアクションの組み合わせを選ぶ必要があります。以下は、各選択肢に関する解説です。

正しい選択肢

B: 「モバイルソフトウェアからファイルを直接Amazon S3にアップロードする。S3イベント通知を使用してAmazon Simple Queue Service (Amazon SQS)標準キューにメッセージを作成する。」

理由: 画像データをS3にアップロードするのは、AWSのストレージサービスとして非常に効率的です。アップロードされた画像をトリガーにして、S3イベント通知でメッセージをSQSキューに送信します。SQSは、シンプルでスケーラブルなメッセージキューサービスであり、画像処理のリクエストを処理するための優れた手段です。

C: 「キューにメッセージがある場合にAWS Lambda関数を呼び出して画像処理を実行する。」

理由: Lambdaはサーバーレスの計算サービスで、イベント駆動型で動作するため、SQSキューにメッセージが届いた時に画像処理をスケーラブルに行えます。Lambdaはリソースの管理を自動で行い、高いスケーラビリティを提供します。

E: 「処理が完了した際にAmazon Simple Notification Service (Amazon SNS)を使用してモバイルアプリにプッシュ通知を送信する。」

理由: SNSはプッシュ通知を簡単に送信できるサービスです。画像処理が完了した際にユーザーに通知するために使用するのに最適です。SNSは複数のサブスクライバーに対して通知を送信でき、モバイルアプリにも対応しています。

なぜ他の選択肢が適していないのか

A: 「S3イベント通知を使用してAmazon MQキューにメッセージを作成する。」

理由: Amazon MQはメッセージキューのサービスですが、SQSよりも複雑で管理が必要です。SQSの方がシンプルで高性能な場合が多いため、SQSを選択する方が一般的です。

D: 「S3バッチ操作ジョブを呼び出して画像処理を実行する。」

理由: S3バッチ操作は主に大量のオブジェクトに対する一括処理に適していますが、リアルタイムでの画像処理にはLambdaの方が適しています。

F: 「処理が完了した際にAmazon SESを使用してモバイルアプリにプッシュ通知を送信する。」

理由: SESは主に電子メール送信のためのサービスです。プッシュ通知にはSNSの方が適しています。

結論

B、C、Eの組み合わせが最もスケーラブルで効率的なアプローチです。S3に直接アップロードした画像をトリガーにして、SQSキューにメッセージを送信し、Lambdaで画像処理を実行、処理完了後にSNSでユーザーに通知します。この方法は高いスケーラビリティと効率を提供し、負荷の変動にも対応可能です。

398-AWS SAP AWS 「理論・実践・一問道場」AWS Client VPN

理論

1. AWS Client VPN

AWS Client VPNは、Amazon Virtual Private Cloud (VPC)内のリソースにインターネット越しにセキュアにアクセスするためのサービスです。企業の従業員がリモートでアクセスできるようにするため、VPC内でのデータアクセスを提供します。

特徴

クライアントVPNは、ユーザーがローカルマシンからVPC内のリソースに安全に接続できるようにします。
セキュリティは、クライアント認証、アクセス制御リスト (ACL)、セキュアなトンネルなどを用いて提供されます。
インターネット経由で接続するので、企業内のオンプレミスネットワークに依存することなく利用できます。

使用シーン

リモートワーカーや外部からの安全なアクセスが必要な場合に最適です。自宅や外部オフィスからAWSリソースに接続したいときに役立ちます。

2. VPC内リソースへのアクセス

VPC (Virtual Private Cloud)内のリソースに安全にアクセスする方法として、AWSにはいくつかの選択肢があります。これには、バスティオンホスト、VPN接続、Direct Connectなどが含まれます。

バスティオンホストは、VPC内のインスタンスに対してセキュアなSSHまたはRDPアクセスを提供しますが、複数の開発者やリモートワークに対するスケーラビリティに欠けます。

Direct Connectは企業ネットワークとAWSを専用回線で接続するサービスであり、開発者向けにはコストが高すぎるため、一般的には不適切です。

VPN接続は、インターネット経由でVPC内のリソースに接続するセキュアな手段を提供し、AWS Client VPNがこの目的で簡単に使用できます。

3. セキュリティ管理

セキュリティはクラウド環境で最も重要な要素の一つです。AWSのリソースへのアクセスには、適切なセキュリティ管理が必要です。

IAMポリシーやセキュリティグループを使用して、アクセス権を細かく設定できます。

アクセスログを利用して、誰がどのリソースにアクセスしたかを追跡することが重要です。

4. リモート開発者のアクセス管理

リモートで働く開発者がVPC内のリソースにアクセスするためには、セキュリティ、スケーラビリティ、管理のしやすさを考慮する必要があります。AWS Client VPNの導入は、セキュリティ要件を満たし、リモート開発者の簡単なアクセスを可能にします。

5. スケーラビリティと管理性

開発者の数が増えた場合、手動での管理や個別接続を避けるために、スケーラブルで自動化されたアクセス管理方法が必要です。AWS Client VPNは、アクセス管理の効率性とスケーラビリティを提供します。

結論

AWS Client VPNを利用することで、VPC内のリソースへの安全なアクセスを提供し、リモートワークや開発者のニーズに対応できます。また、他のオプション（バスティオンホストやDirect Connect）は特定のニーズに適している場合がありますが、開発者のための安全かつ簡単なリモートアクセスにはClient VPNが最適です。

実践

略

一問道場

質問 #398

ある会社がAWS上にアプリケーションを構築しています。このアプリケーションは、ログをAmazon OpenSearch Serviceクラスターに送信して分析しています。すべてのデータはVPC内に保存する必要があります。

会社の開発者のうち、一部は自宅で作業しており、他の開発者は3つの異なる会社のオフィス拠点で作業しています。開発者は、ローカルの開発マシンからOpenSearch Serviceにアクセスし、ログを直接分析・可視化する必要があります。

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

A. AWS Client VPNエンドポイントを設定して構成します。Client VPNエンドポイントをVPC内のサブネットに関連付けます。Client VPN自己サービスポータルを構成します。開発者に、Client VPN用のクライアントを使用して接続するよう指示します。

B. トランジットゲートウェイを作成し、それをVPCに接続します。AWS Site-to-Site VPNを作成します。トランジットゲートウェイにアタッチメントを作成します。開発者にOpenVPNクライアントを使用して接続するよう指示します。

C. トランジットゲートウェイを作成し、それをVPCに接続します。AWS Direct Connect接続を注文します。Direct Connect接続にパブリックVIFを設定します。パブリックVIFをトランジットゲートウェイに関連付けます。開発者にDirect Connect接続に接続するよう指示します。

D. VPCのパブリックサブネットにバスティオンホストを作成して構成します。バスティオンホストのセキュリティグループを設定し、会社のCIDR範囲からのSSHアクセスを許可します。開発者にSSHを使用して接続するよう指示します。

解説

この問題では、開発者が自宅や会社のオフィスからAmazon OpenSearch Serviceにアクセスしてログ分析を行えるようにするための方法を問われています。具体的には、すべてのデータがVPC内に保存されているという要件があるため、VPC内でアクセスできるソリューションを選択する必要があります。

選択肢の解説:

A. AWS Client VPNエンドポイント

このオプションは、開発者が自宅や会社の外部からVPC内のリソースに安全にアクセスするための手段を提供します。AWS Client VPNは、VPC内のリソースに対してセキュアな接続を提供し、開発者が自分の開発マシンからOpenSearch Serviceにアクセスできるようにします。
適切なソリューションです。VPC内でのアクセスを確保でき、必要なセキュリティも提供されます。

B. トランジットゲートウェイとSite-to-Site VPN

トランジットゲートウェイとSite-to-Site VPNは、複数のVPCやオンプレミス環境との接続に使用されますが、このシナリオでは開発者の個々のマシンからのアクセスに必要なものではありません。また、OpenVPNクライアントを使用して接続するという指示も、ここでは過剰であり、過度に複雑です。
不適切なソリューションです。開発者のニーズに対して過剰であり、設定も複雑です。

C. トランジットゲートウェイとAWS Direct Connect

AWS Direct Connectは企業のオンプレミス環境とAWS環境を専用線で接続するためのサービスですが、開発者が自宅やオフィスから簡単にアクセスするためには過剰です。特に、Direct Connectの設定には高コストがかかり、普段から開発者がアクセスするためには不適切です。
不適切なソリューションです。コストやセットアップの複雑さが問題です。

D. バスティオンホスト

バスティオンホストを使用してSSH経由で接続する方法は、安全ではありますが、開発者がVPC内のリソースにアクセスするために直接SSH接続を使うのは便利ではなく、スケーラビリティに欠ける可能性があります。また、バスティオンホストは通常、管理者が使用するものであり、開発者向けには適していません。
不適切なソリューションです。SSH接続に頼るのは開発者のアクセスの要件に合っていません。

結論: Aの「AWS Client VPNエンドポイント」は、開発者が自宅やオフィスからVPC内のリソースにアクセスするための最も適切なソリューションです。この方法により、安全でスケーラブルなアクセスが提供され、要件を満たします。

399-AWS SAP AWS 「理論・実践・一問道場」bridge モード

理論

1. ECSタスクのネットワークモード

AWS ECSでコンテナを実行する際、ネットワーク設定には主に以下の3つのモードがあります：

bridge モード:

ECSタスクがホストEC2インスタンスのネットワークスタックを使用します。
各タスクが同じIPアドレスを共有し、ポート番号を変更して通信を行います。
セキュリティグループはタスクに直接適用されず、ホストEC2インスタンスに適用されるため、個別のネットワークアクセス制御には不向きです。

host モード:

ECSタスクがホストEC2インスタンスのIPアドレスをそのまま使用し、タスクのIPアドレスがホストインスタンスと共有されます。
bridgeモードよりも効率的ですが、個別にセキュリティグループを適用することができません。

awsvpc モード:

各ECSタスクに独立したElastic Network Interface (ENI) が割り当てられ、タスクごとに固有のIPアドレスを持つことになります。
このモードを使用すると、タスクごとにセキュリティグループを設定でき、より詳細なネットワークアクセス制御が可能です。最小権限の原則に従う上で推奨されます。

2. IAMロールの使用

IAMロールを使用することで、AWSリソースに対するアクセス権限を管理できます。特にECSでは、タスクごとにIAMロールを付与することができます。これにより、タスクが必要なリソースにのみアクセスできるようにし、セキュリティを強化します。

タスク用のIAMロール:

ECSタスクには、AWSサービスやリソースにアクセスするためのIAMロールを付与することができます。
このロールを使用することで、タスクが必要なリソース（例：S3バケット、DynamoDB、SQSなど）へのアクセスを、最小権限で管理できます。

3. セキュリティグループの管理

AWSでは、セキュリティグループを使用してインスタンスやタスクのネットワークアクセスを管理します。ECSでawsvpcネットワークモードを使用すると、個々のタスクにセキュリティグループを適用でき、タスク間のアクセスを詳細に制御することができます。

最小権限の原則:

各タスクやサービスには、アクセスを必要とするリソースに対してのみ権限を与えることが推奨されます。これにより、セキュリティリスクを減らし、攻撃があった場合でも影響を最小化できます。

4. コンテナ化アーキテクチャのセキュリティベストプラクティス

コンテナ化されたマイクロサービスアーキテクチャにおけるセキュリティベストプラクティスには、以下が含まれます：

最小権限の原則の適用:

IAMロールやセキュリティグループを利用して、コンテナやタスクに最小限のアクセス権限を与えます。

タスクの分離:

タスクごとに独立したIPアドレスを持たせ、必要なリソースへのアクセスを管理します。

暗号化と通信の保護:

データの暗号化や、コンテナ間の通信の保護を行い、セキュアなアーキテクチャを構築します。

これらのベストプラクティスを組み合わせることで、コンテナ化されたアーキテクチャのセキュリティが強化されます。ECSを使ったアプリケーションの設計時には、これらのセキュリティ対策を考慮してアーキテクチャを構築することが非常に重要です。

実践

略

一問道場

質問 #399

トピック 1

ある企業が、ウェブサイトをオンプレミスのデータセンターからAWSに移行したいと考えています。同時に、ウェブサイトをコンテナ化されたマイクロサービスアーキテクチャに移行し、可用性とコスト効率を改善したいと考えています。この企業のセキュリティポリシーでは、特権とネットワークのアクセス許可は、最小権限の原則に従って設定する必要があります。

ソリューションアーキテクトは、セキュリティ要件を満たすコンテナ化されたアーキテクチャを作成し、アプリケーションをAmazon ECSクラスターにデプロイしました。

デプロイ後、要件を満たすためにはどの手順が必要ですか？（2つ選んでください。）

A. ブリッジネットワークモードを使用してタスクを作成する。

B. awsvpcネットワークモードを使用してタスクを作成する。

C. Amazon EC2インスタンスにセキュリティグループを適用し、EC2インスタンスが他のリソースにアクセスするためのIAMロールを使用する。

D. タスクにセキュリティグループを適用し、コンテナ起動時に他のリソースにアクセスするためのIAM認証情報をコンテナに渡す。

E. タスクにセキュリティグループを適用し、タスクが他のリソースにアクセスするためのIAMロールを使用する。

解説

この問題に関して、セキュリティとアクセス管理のベストプラクティスに基づいて、Amazon ECSを使用したコンテナ化されたアーキテクチャに対して、最小権限の原則とセキュリティ要件を満たすために必要な手順を選択することが求められています。

正解の選択肢

B. awsvpcネットワークモードを使用してタスクを作成する。

E. タスクにセキュリティグループを適用し、タスクが他のリソースにアクセスするためのIAMロールを使用する。

解説

B. awsvpcネットワークモードを使用してタスクを作成する。

awsvpcネットワークモードは、Amazon ECSタスクが独自のElastic Network Interface (ENI) を持ち、IPアドレスを割り当てられる方式です。これにより、タスクごとにセキュリティグループを直接適用でき、ネットワークアクセスがきめ細かく制御できます。これは、最小権限の原則に従い、タスクごとに個別のネットワークアクセス制御を行うために重要です。

また、AWSのベストプラクティスとして、awsvpcモードを使用することで、コンテナが独自のネットワーク設定を持ち、他のリソースとの通信がより安全に管理できます。

E. タスクにセキュリティグループを適用し、タスクが他のリソースにアクセスするためのIAMロールを使用する。

コンテナに必要なアクセス権限を付与するために、タスクにセキュリティグループを適用することは、セキュリティのベストプラクティスです。これにより、タスクのネットワークアクセスが制御され、他のリソースへのアクセス権限を最小限に抑えることができます。

さらに、IAMロールをタスクに付与することで、最小権限で他のAWSサービスにアクセスできるようになります。これにより、セキュリティが向上し、コンテナが必要なリソースのみアクセスできるようになります。

なぜ他の選択肢が不適切なのか

A. ブリッジネットワークモードを使用してタスクを作成する。

bridgeネットワークモードは、タスクがホストEC2インスタンスのネットワーク上で実行され、ホストとの通信が必要な場合に使用されます。ただし、このモードでは、個別のセキュリティグループをタスクに適用することができません。そのため、最小権限の原則を満たすためには不適切です。

C. Amazon EC2インスタンスにセキュリティグループを適用し、EC2インスタンスが他のリソースにアクセスするためのIAMロールを使用する。

EC2インスタンスにセキュリティグループを適用することは一般的な方法ですが、コンテナタスクのセキュリティ要件には合いません。タスク自体にセキュリティグループを適用することで、より細かい制御が可能です。

D. タスクにセキュリティグループを適用し、コンテナ起動時に他のリソースにアクセスするためのIAM認証情報をコンテナに渡す。

IAM認証情報をコンテナに渡す方法は、セキュリティ上のリスクを高める可能性があり、AWSではIAMロールを使用してアクセスを制御する方が推奨されています。

結論

最小権限の原則に従い、awsvpcネットワークモードを使用し、タスクにセキュリティグループとIAMロールを適用することが、最も安全で効率的な方法です。

400-AWS SAP AWS 「理論・実践・一問道場」Amazon Neptune

理論

1. VPC内でのリソース配置と通信

AWS Lambda と Amazon Neptune などのデータベースを連携させるには、Lambda 関数と Neptune DB クラスターが 同じ VPC 内 に配置されている必要があります。これにより、Lambda 関数がプライベート IP アドレスを使用して Neptune へアクセスできます。

2. VPC内でのLambdaのアクセス方法

Lambda 関数は VPC 内のサブネットにホストされることで、VPC 内の他のリソース（例えば Neptune DB）と通信できます。これには、Lambda 関数がサブネット内に配置され、必要な セキュリティグループ が設定されていることが前提となります。

3. セキュリティグループとネットワーク設定

Neptune DB クラスターや Lambda 関数にアクセスするためには、それぞれに適切な セキュリティグループ を設定する必要があります。セキュリティグループで インバウンド/アウトバウンドのルール を設定することで、特定の IP アドレスやポートに対するアクセスを許可します。

4. VPC エンドポイント

VPC エンドポイントを使用することで、VPC 内のリソースがインターネットを介さずに他の AWS サービス（例：DynamoDB）と通信することができます。これにより、プライベートな通信経路を確保することができます。

5. サブネットの選択

Lambda 関数を配置するサブネットは、プライベートサブネットである必要があります。これにより、Lambda 関数がインターネットにアクセスしない場合でも、VPC 内のリソース（Neptune DB）に安全にアクセスできます。

6. NAT ゲートウェイ

Lambda 関数が プライベートサブネットにホストされている場合、外部のリソース（インターネットなど）へのアクセスが必要な場合は、NAT ゲートウェイを使用します。これにより、プライベートサブネットからインターネット経由でアクセスできるようになります。

まとめ

Lambda 関数と Neptune DB は同じ VPC 内で配置し、適切なセキュリティグループとサブネット設定を行うことで、安全かつ効率的にデータベースにアクセスできます。

実践

略

一問道場

問題 #400

ある企業が、いくつかの AWS Lambda 関数と Amazon DynamoDB テーブルから構成されるサーバーレスアプリケーションを運用しています。企業は、新しい機能を作成し、その機能では Lambda 関数が Amazon Neptune DB クラスターにアクセスする必要があります。Neptune DB クラスターは VPC 内の 3 つのサブネットに配置されています。

どのソリューションが Lambda 関数が Neptune DB クラスターと DynamoDB テーブルにアクセスできるようにしますか？（2つ選択してください。）

A. Neptune VPC 内に 3 つのパブリックサブネットを作成し、インターネットゲートウェイを介してトラフィックをルーティングします。Lambda 関数を 3 つの新しいパブリックサブネットにホストします。

B. Neptune VPC 内に 3 つのプライベートサブネットを作成し、インターネットトラフィックを NAT ゲートウェイを介してルーティングします。Lambda 関数を 3 つの新しいプライベートサブネットにホストします。

C. Lambda 関数を VPC 外にホストします。Neptune のセキュリティグループを更新し、Lambda 関数の IP 範囲からのアクセスを許可します。

D. Lambda 関数を VPC 外にホストします。Neptune データベースの VPC エンドポイントを作成し、Lambda 関数が VPC エンドポイント経由で Neptune にアクセスできるようにします。

E. Neptune VPC 内に 3 つのプライベートサブネットを作成します。Lambda 関数を 3 つの新しい隔離されたサブネットにホストします。DynamoDB の VPC エンドポイントを作成し、DynamoDB トラフィックを VPC エンドポイントにルーティングします。

解説

この問題では、AWS Lambda 関数が Amazon Neptune DB クラスターと DynamoDB テーブルにアクセスできるようにするための最適なソリューションを選択する必要があります。以下は、選択肢ごとの解説です。

A. Neptune VPC 内に 3 つのパブリックサブネットを作成し、インターネットゲートウェイを介してトラフィックをルーティングします。Lambda 関数を 3 つの新しいパブリックサブネットにホストします。

不正解: パブリックサブネットを作成することでインターネットアクセスが可能になりますが、Lambda 関数をインターネットに直接公開することは推奨されません。セキュリティ上の理由で、Lambda 関数は通常プライベートサブネット内で実行され、必要なリソースには VPC エンドポイントや NAT ゲートウェイを通じてアクセスします。

B. Neptune VPC 内に 3 つのプライベートサブネットを作成し、インターネットトラフィックを NAT ゲートウェイを介してルーティングします。Lambda 関数を 3 つの新しいプライベートサブネットにホストします。

正解: このアプローチは、Lambda 関数を VPC 内のプライベートサブネットでホストし、必要なリソースにアクセスするために NAT ゲートウェイを使用します。これにより、Lambda 関数はインターネットにアクセスすることなく Neptune DB クラスターにアクセスできます。プライベートサブネット内で実行されるため、セキュリティが強化されます。

C. Lambda 関数を VPC 外にホストします。Neptune のセキュリティグループを更新し、Lambda 関数の IP 範囲からのアクセスを許可します。

不正解: Lambda 関数を VPC 外にホストすることはできません。Lambda 関数は、VPC 内のリソースにアクセスするために VPC に接続する必要があります。セキュリティグループでアクセスを制限することはできますが、Lambda 関数が VPC 外にある場合、Neptune クラスターには接続できません。

D. Lambda 関数を VPC 外にホストします。Neptune データベースの VPC エンドポイントを作成し、Lambda 関数が VPC エンドポイント経由で Neptune にアクセスできるようにします。

不正解: VPC エンドポイントは、VPC 内からのリソースへのアクセスを提供しますが、Lambda 関数を VPC 外にホストする場合、VPC エンドポイントを使用してもアクセスできません。Lambda 関数が VPC に接続されている必要があります。

E. Neptune VPC 内に 3 つのプライベートサブネットを作成します。Lambda 関数を 3 つの新しい隔離されたサブネットにホストします。DynamoDB の VPC エンドポイントを作成し、DynamoDB トラフィックを VPC エンドポイントにルーティングします。

正解: Lambda 関数を VPC 内のプライベートサブネットでホストし、DynamoDB の VPC エンドポイントを作成することで、Lambda 関数がセキュアに Neptune と DynamoDB にアクセスできます。このソリューションは、セキュリティと可用性を確保しつつ、リソースに効率的にアクセスする方法です。

結論

最適な解決策は B と E です。両者は、Lambda 関数をプライベートサブネットにホストし、セキュアなアクセスを提供するために VPC エンドポイントを使用する方法です。これにより、Lambda 関数が Neptune と DynamoDB にアクセスでき、セキュリティとスケーラビリティが確保されます。