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

type

status

date

slug

summary

501-AWS SAP AWS 「理論・実践・一問道場」ライフサイクルフック

理論

Auto Scaling と起動遅延の最適化

AWS Auto Scaling は、アプリケーションのトラフィックや負荷に基づいてインスタンスを動的にスケールできます。ただし、新しいインスタンスが起動される際の遅延は、ユーザー体験に影響を与えることがあります。以下に、遅延を最小限に抑えるための主要なアプローチをまとめます。

1. ウォームプール (Warm Pool) の活用

ウォームプールを設定することで、事前に準備された「ウォーム状態」のインスタンスを保持できます。

需要が増加した際に、これらのインスタンスを即時に使用可能な状態に切り替えられるため、起動時間を大幅に削減できます。

2. ライフサイクルフック (Lifecycle Hook)

インスタンスの起動プロセス中に、ユーザーデータスクリプトやカスタムパッケージのインストールを完了させる時間を確保します。

アプリケーションの初期化が完了するまで、インスタンスをアクティブな状態にしないよう制御できます。

3. スケーリングポリシーの選択

動的スケーリング: リアルタイムの負荷に応じてインスタンスを追加。即時性が高い。

予測スケーリング: 過去のパフォーマンスデータを元に、需要を事前に予測してスケールアウト。需要が予測可能な場合に有効。

4. ユーザーデータスクリプトの最適化

インスタンス起動中に必要な初期設定やパッケージインストールを自動化します。

再利用可能な AMI (Amazon Machine Image) を使用してインスタンス作成時間を短縮することも有効です。

ポイント

ウォームプールを使うことでインスタンス起動遅延を最小化。

ライフサイクルフックを組み合わせて、初期化の完了を保証。

スケーリングポリシーはシナリオに応じて動的または予測を選択。

適切な組み合わせにより、アプリケーションのパフォーマンスとユーザー体験を向上させることができます。

実践

略

一問道場

問題 #501

ある会社は、単一の Amazon EC2 インスタンスで Web アプリケーションを運営しています。ピーク時に CPU 使用率が常に 95% を超えており、エンドユーザーはアプリケーションのパフォーマンスが遅くなることを経験しています。ユーザーデータスクリプトは、EC2 インスタンスに必要なカスタムパッケージをインストールしますが、インスタンスの起動には数分かかります。

会社は、複数のインスタンスタイプ（CPU の異なるインスタンス）を使用する Auto Scaling グループを作成しており、最大容量制限も設定されています。この Auto Scaling グループは、さまざまな設定オプションのために起動テンプレートを使用します。会社は、Auto Scaling 中に新しいインスタンスが起動される際のアプリケーションの遅延を減らす必要があります。

どの解決策がこの要件を満たしますか？

A. 予測スケーリングポリシーを使用し、インスタンスメンテナンスポリシーを使用してユーザーデータスクリプトを実行します。デフォルトのインスタンスウォームアップ時間を 0 秒に設定します。

B. 動的スケーリングポリシーを使用し、ライフサイクルフックを使用してユーザーデータスクリプトを実行します。デフォルトのインスタンスウォームアップ時間を 0 秒に設定します。

C. 予測スケーリングポリシーを使用し、Auto Scaling グループでウォームプールを有効にします。インスタンスメンテナンスポリシーを使用してユーザーデータスクリプトを実行します。

D. 動的スケーリングポリシーを使用し、Auto Scaling グループでウォームプールを有効にします。ライフサイクルフックを使用してユーザーデータスクリプトを実行します。

解説

この問題のシナリオでは、Web アプリケーションが単一の EC2 インスタンスで実行されており、ピーク時に CPU 使用率が 95% を超えるため、パフォーマンスの低下が発生しています。会社は Auto Scaling グループを使用して負荷を分散させ、ユーザーの体験を改善しようとしていますが、以下の課題に直面しています。

課題のポイント

インスタンス起動の遅延

新しいインスタンスが起動するまでに数分かかる。

ユーザーデータスクリプトによる初期化も時間を要するため、エンドユーザーが遅延を感じる。

CPU 使用率の高負荷

現在の負荷に対応できるインスタンスを素早く用意する必要がある。

解決策の考え方

解決策は、新しいインスタンスが迅速に利用可能になるよう、インスタンスの準備時間を短縮する仕組みを導入することです。この要件に基づき、以下の技術的アプローチを考慮します。

1. ウォームプールの使用

ウォームプールでは、あらかじめ起動されたインスタンスを「ウォーム状態」で待機させておくことができます。

インスタンスがリクエストされると、ウォーム状態から即座にアクティブに切り替わるため、起動遅延が大幅に減少します。

2. ライフサイクルフックの活用

ライフサイクルフックを使うと、起動プロセス中にカスタムタスク（例: パッケージインストール）を実行する時間を確保できます。

ユーザーデータスクリプトの実行が完了してからインスタンスをサービスに投入できるため、未準備のインスタンスが稼働するリスクを防ぎます。

3. 動的スケーリングの採用

CPU 使用率などのリアルタイムメトリクスを基にインスタンスをスケールアウトする動的スケーリングは、急激な負荷変化への即応性に優れています。

将来の負荷を予測する「予測スケーリング」よりも、現在の課題には適しています。

選択肢の解説

A. 予測スケーリングとインスタンスメンテナンスポリシー

予測スケーリングは需要を予測して事前にスケールアウトしますが、このシナリオでは遅延が既に発生しているため、適切ではありません。

インスタンスメンテナンスポリシーは、ユーザーデータスクリプトの実行タイミングを制御しますが、遅延解消には十分でない。

B. 動的スケーリングとライフサイクルフック

動的スケーリングは負荷変化に応じますが、新しいインスタンスの準備に時間がかかるため、遅延を完全に防ぐには不十分です。

C. 予測スケーリングとウォームプール

ウォームプールによりインスタンス起動遅延は減少しますが、予測スケーリングは現在の負荷増加への即時対応には不適です。

D. 動的スケーリングとウォームプール、ライフサイクルフック

正解。ウォームプールで即時対応を可能にし、ライフサイクルフックでカスタムタスクを実行、動的スケーリングで負荷に応じたスケールアウトを行います。この組み合わせが最も効率的です。

まとめ

正解は D です。この解決策は、インスタンス起動遅延を最小限に抑え、動的スケーリングによる負荷変化への即応性を提供する最適な構成です。

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

理論

オンプレミスデータベースから Amazon RDS への移行方法

AWS を使用してオンプレミスデータベースを Amazon RDS に移行する際は、以下の主要ステップを理解することが重要です。

1. 移行のステップ

(1) スキーマと互換性の分析

AWS Schema Conversion Tool (AWS SCT) を使用し、データベーススキーマやストアドプロシージャを分析します。

異なるデータベースエンジン間の互換性を確認し、必要に応じて変換します。

(2) データの移行

AWS Database Migration Service (AWS DMS) を使用し、データをオンプレミスから Amazon RDS に移行します。

DMS はリアルタイムでのデータレプリケーションや運用停止時間の最小化を可能にします。

2. 選択するツールの概要

AWS SCT:

データベーススキーマやカスタムコード（例: ストアドプロシージャ）の変換と互換性分析に特化。

AWS DMS:

データベースの移行を自動化し、異なるデータベースエンジン間でもスムーズな移行を提供。

3. ベストプラクティス

事前にデータベースのスキーマやカスタムオブジェクト（ストアドプロシージャ、トリガー）を精査。

小規模なデータセットで移行テストを行い、本番移行前に問題点を洗い出す。

移行中は DMS の「継続的レプリケーション機能」を使用し、運用中のデータを最新に保つ。

まとめ

AWS SCT でスキーマの変換とカスタムコードの互換性をチェック。

AWS DMS でデータ移行を効率化。これにより、安全かつスムーズにオンプレミスデータベースを Amazon RDS に移行できます。

実践

略

一問道場

質問 #502

ある企業がオンプレミスのデータベース群を Amazon RDS に移行する必要があります。この企業は現在、Microsoft SQL Server、MySQL、および Oracle データベースの混在環境を使用しています。一部のデータベースにはカスタムスキーマやストアドプロシージャが含まれています。

企業は移行のためにどの手順を組み合わせるべきでしょうか？（2 つ選択）

A. Migration Evaluator Quick Insights を使用して、ソースデータベースを分析し、移行が必要なストアドプロシージャを特定します。

B. AWS Application Migration Service を使用して、ソースデータベースを分析し、移行が必要なストアドプロシージャを特定します。

C. AWS Schema Conversion Tool (AWS SCT) を使用して、ソースデータベースに必要な変更を分析します。

D. AWS Database Migration Service (AWS DMS) を使用して、ソースデータベースを Amazon RDS に移行します。

E. AWS DataSync を使用して、ソースデータベースのデータを Amazon RDS に移行します。

解説

問題の背景

この問題では、オンプレミスのデータベースを Amazon RDS に移行するための最適な方法を選択する必要があります。特に、複数のデータベースエンジン（Microsoft SQL Server、MySQL、Oracle）を扱い、一部にはカスタムスキーマやストアドプロシージャが含まれているという条件を考慮します。

移行プロセスでは、以下を考慮する必要があります：

スキーマとストアドプロシージャの互換性確認と変換

異なるデータベースエンジン間でのスキーマやストアドプロシージャの互換性を確認し、必要に応じて変換します。

データの移行

データ自体を効率的かつ安全に Amazon RDS に移行します。

各選択肢の評価

A. Migration Evaluator Quick Insights を使用して、ソースデータベースを分析し、移行が必要なストアドプロシージャを特定します。

不正解: Migration Evaluator は、オンプレミスのインフラストラクチャ全体のコスト分析や移行プラン作成に役立つツールです。ストアドプロシージャの特定には使用しません。

B. AWS Application Migration Service を使用して、ソースデータベースを分析し、移行が必要なストアドプロシージャを特定します。

不正解: Application Migration Service は、サーバーレベルの移行（リフト＆シフト）に使用されます。データベーススキーマやストアドプロシージャの分析には適していません。

C. AWS Schema Conversion Tool (AWS SCT) を使用して、ソースデータベースに必要な変更を分析します。

正解: AWS SCT は、データベーススキーマの変換やストアドプロシージャの互換性チェックを行うためのツールです。異なるデータベースエンジン間の変換が必要な場合に適しています。

D. AWS Database Migration Service (AWS DMS) を使用して、ソースデータベースを Amazon RDS に移行します。

正解: AWS DMS は、データの移行を実行するための主要なツールです。既存のデータを中断を最小限に抑えて RDS に移行できます。また、リアルタイムのデータレプリケーションも可能です。

E. AWS DataSync を使用して、ソースデータベースのデータを Amazon RDS に移行します。

不正解: AWS DataSync は主にファイルシステム間のデータ転送に使用され、データベース移行には適していません。

正解

C. AWS Schema Conversion Tool (AWS SCT)

D. AWS Database Migration Service (AWS DMS)

解説

この組み合わせにより、以下のプロセスを効率的に実行できます：

AWS SCT:

データベーススキーマやストアドプロシージャの分析・変換を実行します。これにより、異なるデータベースエンジン間の互換性の問題を解決します。

AWS DMS:

実際のデータ移行を行います。DMS は、運用停止を最小限に抑えながら、既存のデータを安全に移行するための最適なツールです。

この方法は、オンプレミス環境から Amazon RDS への移行を効果的かつ効率的に実現するベストプラクティスです。

503-AWS SAP AWS 「理論・実践・一問道場」AWS Snowball Edge Storage Optimized

理論

大量データ移行とリアルタイムファイル共有のベストプラクティス

AWS におけるオンプレミスシステムの移行時、大量データの移行とリアルタイムのファイル共有が必要な場合、以下のソリューションが効果的です。

1. 大量データの迅速な移行

AWS Snowball Edge

用途: 数十 TB 以上のデータを迅速かつ安全に移行。ネットワーク転送の制約を回避。

特徴:

1 デバイスで最大 80TB のデータ容量をサポート。複数デバイスを併用可能。
データを暗号化して安全に AWS に配送。

適用例: 200TB 以上のアーカイブデータの移行。

2. リアルタイムのファイル共有

Amazon Elastic File System (Amazon EFS)

用途: 複数の EC2 インスタンス間で共有ストレージを提供。オンプレミスとも連携可能。

特徴:

高スループットと低レイテンシでリアルタイムのデータ共有を実現。
マルチアベイラビリティゾーン対応で高可用性を確保。
NFS プロトコルを使用してオンプレミスサーバーと連携可能。

適用例: ブログプラットフォームのコンテンツ共有や頻繁な更新に対応。

3. ベストプラクティス

データ移行時:

AWS Snowball Edge を活用し、大規模なアーカイブデータを迅速に Amazon S3 に移行。ネットワーク経由の転送を避ける。

リアルタイム共有時:

Amazon EFS を使用して、EC2 インスタンスとオンプレミス間で統一されたファイル共有を構築。頻繁なデータ更新にも対応。

まとめ

AWS Snowball Edge と Amazon EFS を組み合わせることで、大規模データ移行とリアルタイム共有の課題を効率的に解決できます。これらのツールは、運用停止時間を最小限に抑えながら、信頼性の高い移行を実現します。

実践

略

一問道場

質問 #503

ある会社がブログプラットフォームを AWS に移行しようとしています。この会社のオンプレミスサーバーは、AWS Site-to-Site VPN 接続を通じて AWS に接続されています。ブログのコンテンツは、複数の著者によって 1 日に数回更新され、ネットワーク接続ストレージ（NAS）サーバー上のファイル共有から提供されています。

会社は、コンテンツの更新を遅らせることなく、ブログプラットフォームを移行する必要があります。また、ブログプラットフォームを実行するために、Amazon EC2 インスタンスを複数のアベイラビリティゾーンに展開し、Application Load Balancer の背後で動作させています。さらに、200 TB のアーカイブデータをオンプレミスサーバーから Amazon S3 にできるだけ早く移行する必要があります。

以下の手順の組み合わせで、この要件を満たすことができますか？（2 つ選択）

A. Amazon EventBridge で週次の cron ジョブを作成します。この cron ジョブを使用して AWS Lambda 関数を呼び出し、NAS サーバーから EC2 インスタンスを更新します。

B. Amazon Elastic Block Store（Amazon EBS）の Multi-Attach ボリュームを構成し、EC2 インスタンスがコンテンツを共有できるようにします。EBS ボリュームを NAS サーバーと同期させるコードを作成し、毎週同期します。

C. Amazon Elastic File System（Amazon EFS）ファイルシステムをオンプレミスサーバーにマウントして NAS サーバーとして機能させます。ブログデータを EFS ファイルシステムにコピーします。その後、EFS ファイルシステムを EC2 インスタンスにマウントしてコンテンツを提供します。

D. AWS Snowball Edge Storage Optimized デバイスを注文します。静的データの成果物をデバイスにコピーし、AWS に配送します。

E. AWS Snowcone SSD デバイスを注文します。静的データの成果物をデバイスにコピーし、AWS に配送します。

解説

問題の背景

この問題では、ブログプラットフォームを AWS に移行する際に、以下の要件を満たす必要があります：

コンテンツの更新を遅延なく継続

ブログコンテンツは頻繁に更新されるため、移行後もリアルタイムでコンテンツを提供する必要があります。

アーカイブデータ（200TB）の迅速な移行

大量のデータを短期間で Amazon S3 に移行する効率的な方法が必要です。

これらの要件を考慮し、最適な解決策を選択する必要があります。

各選択肢の評価

A. EventBridge と Lambda を使用して EC2 インスタンスを NAS サーバーから更新する

不正解: EventBridge や Lambda は定期的なタスク実行には適していますが、この方法では NAS サーバーからの直接更新がボトルネックになる可能性が高く、リアルタイム性に欠けます。また、コンテンツの共有や可用性の確保に直接的に寄与しません。

B. EBS Multi-Attach ボリュームを使用して EC2 インスタンス間でコンテンツを共有する

不正解: EBS Multi-Attach は単一のアベイラビリティゾーンでのみ使用可能であり、複数のアベイラビリティゾーンにまたがるシステムには適していません。また、データの同期を独自に実装する必要があるため、運用が複雑になります。

C. EFS を使用してファイルシステムを共有し、コンテンツを提供する

正解: Amazon EFS は、複数の EC2 インスタンスにマウント可能なスケーラブルなファイルストレージです。オンプレミスサーバーにも NFS を通じてマウント可能で、NAS サーバーとしての機能を提供します。これにより、コンテンツの共有が容易になり、更新の遅延を防ぐことができます。

D. AWS Snowball Edge Storage Optimized デバイスを使用してアーカイブデータを移行する

正解: Snowball Edge Storage Optimized は、大量のデータ（最大 80TB/デバイス）を移行するのに適しています。200TB のデータを移行する場合、複数の Snowball デバイスを利用することで、ネットワーク経由の転送に比べて迅速にデータを移行できます。

E. AWS Snowcone SSD デバイスを使用してアーカイブデータを移行する

不正解: Snowcone デバイスは最大 8TB までしかデータを保存できないため、200TB のデータ移行には不適です。また、複数のデバイスを利用する場合でも時間とコストが大きく増加します。

正解

C. Amazon EFS を使用してファイルシステムを共有する

D. AWS Snowball Edge Storage Optimized を使用してアーカイブデータを移行する

解説

EFS は、オンプレミス環境と EC2 インスタンス間でリアルタイムでコンテンツを共有できる柔軟なストレージソリューションです。これにより、ブログプラットフォームが頻繁なコンテンツ更新にも対応できます。

Snowball Edge Storage Optimized は、大規模なデータ移行に特化した物理デバイスで、200TB のデータを迅速に Amazon S3 に移行する最適な選択肢です。

この組み合わせにより、ブログプラットフォームの移行が効率的かつ遅延なく実現できます。

504-AWS SAP AWS 「理論・実践・一問道場」AWS Elastic Beanstalk

理論

レガシーアプリケーションの AWS 移行と運用負荷軽減

レガシーなオンプレミスアプリケーションを AWS に移行する際、最小限の運用負荷でスケーリングと高可用性を確保することが重要です。以下のポイントに注目すると、移行と運用を効率化できます。

1. AWS Elastic Beanstalk

用途: アプリケーションのデプロイと管理を簡素化する完全マネージドサービス。

特徴:

Java アプリケーション（例: Tomcat）を簡単にデプロイ。
自動スケーリングとロードバランシングをサポート。
インフラ管理が不要で、アプリケーションロジックに集中できる。

適用例:

アプリケーションの設定や管理を自動化し、運用負荷を軽減。特にトラフィックの増加に対応するためのオートスケーリングが可能。

2. Amazon RDS for PostgreSQL

用途: 完全マネージドなリレーショナルデータベースサービス（PostgreSQL）。

特徴:

自動バックアップ、パッチ管理、スケーリング機能を提供。
高可用性のためのマルチAZデプロイをサポート。
PostgreSQL の運用を簡素化し、手動での管理作業を最小化。

適用例:

データベースのスケーリングと管理を自動化し、リソースの最適化を図る。

3. Application Load Balancer (ALB) と CloudFront

用途: トラフィックの負荷分散とコンテンツ配信の高速化。

特徴:

ALB はアプリケーションレベルでのロードバランシングを提供。
CloudFront はコンテンツ配信を最適化し、低レイテンシでエンドユーザーにサービスを提供。

適用例:

高可用性を確保し、アプリケーションのスケーリングをサポートするために使用。

まとめ

レガシーアプリケーションの移行には、AWS の Elastic Beanstalk と RDS を使用することで、運用負荷を軽減し、スケーリングと可用性を簡単に実現できます。

これにより、インフラ管理の負担を減らし、トラフィック増加に対して柔軟に対応することが可能となります。

実践

略

一問道場

質問 #504

ある会社が、レガシーなオンプレミスアプリケーションを AWS に移行する計画を立てています。このアプリケーションは、Apache Tomcat 上で実行される Java Web アプリケーションで、PostgreSQL データベースを使用しています。会社はソースコードにはアクセスできませんが、アプリケーションの Java アーカイブ（JAR）ファイルをデプロイできます。アプリケーションは月末にトラフィックが増加します。

最小限の運用負荷でこれらの要件を満たすソリューションはどれですか？

選択肢

複数のアベイラビリティゾーンに Amazon EC2 インスタンスを起動します。

Amazon Elastic File System (Amazon EFS) マウントポイントを使用して、すべてのインスタンスに Tomcat と PostgreSQL をデプロイします。

AWS Step Functions を使用して、トラフィック増加に対応するために追加の EC2 インスタンスをデプロイします。

Amazon Elastic Kubernetes Service (Amazon EKS) をプロビジョニングし、

複数の AWS リージョンにまたがる Auto Scaling グループでスケールします。

コンテナイメージに Tomcat と PostgreSQL をデプロイし、

ネットワークロードバランサーを使用してトラフィックの増加に対応します。

Java アプリケーションを Python ベースのコンテナにリファクタリングします。

アプリケーションロジックに AWS Lambda 関数を使用し、アプリケーションデータを Amazon DynamoDB グローバルテーブルに格納します。

AWS Storage Gateway と Lambda の同時実行を使用して、トラフィック増加に対応します。

AWS Elastic Beanstalk を使用して Tomcat サーバーをデプロイし、

複数のアベイラビリティゾーンでオートスケーリングを実行します。

アプリケーションデータを Amazon RDS for PostgreSQL データベースに格納します。

Amazon CloudFront と Application Load Balancer をデプロイして、トラフィック増加に対応します。

解説

この問題では、オンプレミスのレガシーアプリケーションを AWS に移行するため、最小限の運用負荷でトラフィックの増加に対応し、アプリケーションをスケールさせる方法を選ぶ必要があります。

選択肢 A: EC2 インスタンスと EFS、Step Functions

問題点:

EC2 インスタンスを複数のアベイラビリティゾーンに配置してスケールする方法は、一般的に効果的ですが、EFS を使って Tomcat と PostgreSQL をすべてのインスタンスで共有する設計は、管理が複雑になりがちです。
Step Functions は、トラフィック増加に合わせて EC2 インスタンスを追加するために使われますが、このアプローチは、手動での運用やオーケストレーションの追加作業が増えるため、運用負荷が高くなります。

結論: この方法は運用負荷が高く、最適ではありません。

選択肢 B: Amazon EKS と Auto Scaling

問題点:

EKS を使って Kubernetes ベースでスケーリングを実現することは非常に強力ですが、レガシーな Java Web アプリケーション（Tomcat）がコンテナ化されていない場合、まずアプリケーションをコンテナ化する必要があります。また、運用において Kubernetes の管理が必要になるため、運用負荷が増大する可能性があります。
さらに、PostgreSQL のデータベースもコンテナ化し、ネットワークロードバランサーを使ってスケールさせるのは、データベースのスケーリングに関する問題が発生する可能性があります。

結論: 高度なコンテナ化が必要であり、運用負荷が増えるため、このアプローチは最小限の運用負荷を求める要件には適していません。

選択肢 C: Python コンテナ、Lambda と DynamoDB

問題点:

この選択肢では、アプリケーションを Python ベースのコンテナにリファクタリングし、Lambda 関数を使用してアプリケーションロジックを実行することを提案しています。これは大規模なアーキテクチャの変更を意味します。特に、アプリケーションのソースコードにアクセスできないという制約があるため、このアプローチは不適切です。
また、DynamoDB は NoSQL データベースであり、PostgreSQL のリレーショナルデータベースに置き換えることは大きな設計変更を伴います。これは移行に多大な労力とコストがかかるため、最小限の運用負荷を達成する方法としては不適切です。

結論: アプリケーションのリファクタリングを必要とし、運用負荷が非常に高くなるため不適切です。

選択肢 D: AWS Elastic Beanstalk と RDS

正解:

Elastic Beanstalk は、アプリケーションのデプロイ、管理、スケーリングを簡素化する完全マネージドサービスです。Tomcat サーバーとそのオートスケーリングを簡単に設定でき、運用負荷が最小限に抑えられます。
Amazon RDS for PostgreSQL は、PostgreSQL データベースを完全にマネージドで提供し、データベースのスケーリングやバックアップなどを自動化します。これにより、データベースの運用負荷を軽減できます。
Application Load Balancer と Amazon CloudFront は、トラフィックの増加に対応するための自動スケーリングおよびコンテンツ配信をサポートします。これにより、高可用性とパフォーマンスが確保されます。

結論: AWS のマネージドサービスを使用することで、運用負荷を最小限に抑えつつ、スケーリングと高可用性を実現できるため、この選択肢が最適です。

まとめ

最小限の運用負荷でアプリケーションの移行とスケーリングを実現するためには、Elastic Beanstalk と RDS を使用する方法が最適です。この方法は、インフラ管理を自動化し、アプリケーションとデータベースの運用負荷を軽減し、スケーラビリティと高可用性を確保することができます。

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

理論

IoT プラットフォームの AWS 移行

AWS への IoT プラットフォームの移行には、スケーラブルで運用負荷が少ないサービスの活用が重要です。以下の主要サービスを理解し、運用負荷を軽減する方法を確認しましょう。

1. AWS IoT Core

概要: AWS IoT Core は、デバイスとクラウドを安全に接続するためのサービスです。MQTT や HTTP をサポートし、デバイスからのメッセージを簡単に受信できます。

特徴:

メッセージのルーティング、データ処理、ストレージに容易に接続可能。
IoT デバイスからのデータを Lambda 関数に直接送信し、リアルタイムで処理できます。
IoT デバイスの管理、監視、セキュリティ管理が簡単。

適用例:

IoT デバイスからのデータを集約して分析する際に有用。

2. AWS Lambda

概要: AWS Lambda は、サーバーレスでコードを実行するサービスです。インフラ管理なしで、イベント駆動型で処理を自動化できます。

特徴:

サーバーレスなので、インフラストラクチャの管理が不要。
自動スケーリング機能を持ち、負荷に応じて処理能力が自動で調整される。
イベントトリガー（IoT Core のメッセージ、S3 へのファイルアップロードなど）で実行できます。

適用例:

デバイスから送信されたデータをリアルタイムで処理したり、定期的にレポートを生成したりする場合。

3. Amazon DocumentDB (MongoDB 互換)

概要: Amazon DocumentDB は、MongoDB と互換性のあるフルマネージドデータベースサービスです。データベースの運用負荷を軽減し、スケーラビリティと可用性を確保できます。

特徴:

MongoDB のクエリ言語をサポート。
自動バックアップ、パッチ適用、スケーリングが自動化され、運用管理が簡素化。
高可用性を提供するため、マルチAZデプロイメントをサポート。

適用例:

データストレージのスケーラビリティを確保したい場合、運用負荷を減らしたい場合。

4. Amazon S3 と CloudFront

概要: Amazon S3 はオブジェクトストレージサービスで、CloudFront はコンテンツ配信ネットワーク（CDN）です。

特徴:

S3 でデータを格納し、CloudFront を使ってグローバルに高速配信できます。
CloudFront は低レイテンシでコンテンツをエンドユーザーに提供します。
レポートや静的なコンテンツの配信に最適。

適用例:

Web アプリケーションのレポート配信やデータ提供をスケーラブルで効率的に行う場合。

5. AWS Step Functions

概要: AWS Step Functions は、サーバーレスのオーケストレーションサービスです。ワークフローを自動化し、複数のサービス間で処理の流れを定義できます。

特徴:

Lambda 関数やその他の AWS サービスを組み合わせて、複雑なワークフローを自動化。
容易にスケーリングでき、エラー処理や状態管理が可能。
レポート作成や定期的なデータ処理のオーケストレーションに適している。

適用例:

複雑な処理を複数のステップで自動化したい場合や、データフローを管理したい場合。

まとめ

IoT プラットフォームを AWS に移行する際、運用負荷を減らし、パフォーマンスを向上させるために以下のサービスを活用します：

AWS IoT Core でデバイスからデータを収集。

AWS Lambda と Step Functions でデータ処理とレポート作成を自動化。

Amazon DocumentDB で MongoDB の管理を簡素化。

Amazon S3 と CloudFront でデータを効率的に配信。

これにより、スケーラブルで運用負荷が少ないシステムを構築できます。

実践

略

一問道場

質問 #505

ある会社がオンプレミスの IoT プラットフォームを AWS に移行する予定です。プラットフォームは以下のコンポーネントで構成されています：

収集された処理済み IoT データを保存する MongoDB クラスター

IoT デバイスと接続し、5 分ごとにデータを収集するために MQTT を使用するアプリケーション

IoT データからレポートを生成するために定期的にジョブを実行するアプリケーション。ジョブの実行には 120～600 秒かかります。

ウェブアプリケーションで、エンドユーザーはウェブアプリケーションを使って一般公開されるレポートにアクセスします。

会社は、運用負荷を軽減し、パフォーマンスを維持するためにプラットフォームを AWS に移行する必要があります。最小限の運用負荷でこの要件を満たすための手順を選んでください（3つ選んでください）。

選択肢

AWS Step Functions のステートマシンを作成し、AWS Lambda タスクを使用してレポートを準備し、Amazon S3 にレポートを書き込みます。

Amazon CloudFront を設定して、S3 をオリジンとしてレポートを提供します。

AWS Lambda 関数を作成し、Lambda 関数を使って IoT デバイスに接続し、データを処理してデータストアに書き込みます。

Lambda レイヤーを設定して、メッセージを一時的に格納し、処理します。

Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを設定し、Amazon EC2 インスタンスでレポートを準備します。

EKS クラスターにイングレスコントローラーを作成し、レポートを提供します。

IoT デバイスを AWS IoT Core に接続して、メッセージを発行します。

メッセージを受信した際に実行される AWS IoT ルールを作成し、そのルールで AWS Lambda 関数を呼び出して、デバイスからのメッセージデータを解析、変換、データストアに格納します。

MongoDB クラスターを Amazon DocumentDB（MongoDB 互換）に移行します。

MongoDB クラスターを Amazon EC2 インスタンスに移行します。

解説

この問題では、IoT プラットフォームを AWS に移行する際に、運用負荷を最小化し、パフォーマンスを維持するための手順を選択する必要があります。それぞれの選択肢を見ていきます。

選択肢 A: AWS Step Functions と CloudFront

AWS Step Functions を使用して、レポート作成のワークフローをオーケストレーションできます。Lambda タスクを使用してレポートを準備し、結果を Amazon S3 に保存します。

Amazon CloudFront を使うことで、S3 のレポートを迅速に配信できます。この方法は、レポートの提供を効率化し、運用負荷を軽減します。

運用負荷の軽減: Step Functions でワークフローを自動化し、CloudFront でレポート配信を最適化するため、運用管理が簡素化されます。

選択肢 B: AWS Lambda と Lambda レイヤー

AWS Lambda を使用して IoT デバイスからのデータを収集し、処理してデータストアに格納するアプローチです。

Lambda レイヤー は、メッセージを一時的に保存してから処理するために使用されます。これにより、データの処理を効率的に行えます。

運用負荷の軽減: Lambda によってサーバーレスでスケーラブルな処理が可能になり、運用負荷が最小限に抑えられます。

選択肢 C: Amazon EKS と EC2

Amazon EKS を使用して Kubernetes クラスターを管理し、EC2 インスタンス上でレポートを生成するアプローチですが、これには Kubernetes の管理が必要になります。

運用負荷の増加: EKS は強力なサービスですが、管理が必要であり、特に Kubernetes に不慣れな場合は運用負荷が増大します。このアプローチは、運用負荷を最小限に抑える目的には適していません。

選択肢 D: AWS IoT Core と Lambda

AWS IoT Core に接続した IoT デバイスからメッセージを受信し、AWS IoT ルール を使って Lambda 関数をトリガーします。Lambda 関数内でデバイスメッセージを解析し、データストアに保存することができます。

運用負荷の軽減: IoT Core と Lambda の組み合わせにより、メッセージ処理が自動化され、運用負荷が低減します。

選択肢 E: MongoDB を Amazon DocumentDB に移行

Amazon DocumentDB (MongoDB 互換) は、MongoDB と互換性のあるマネージドデータベースサービスです。MongoDB のクラスターを DocumentDB に移行することで、運用負荷を大幅に軽減できます。

運用負荷の軽減: DocumentDB はフルマネージドであり、スケーリングやバックアップなどの管理を自動化するため、運用管理の負担が減ります。

選択肢 F: MongoDB を EC2 に移行

MongoDB クラスターを Amazon EC2 インスタンス に移行する方法です。これでは MongoDB の管理を手動で行う必要があり、パフォーマンスやスケーリングの管理も自分で行う必要があります。

運用負荷の増加: EC2 インスタンスを使った MongoDB の管理は、フルマネージドサービスである DocumentDB に比べて運用負荷が高くなります。

最適な解決策

最小限の運用負荷で IoT プラットフォームを AWS に移行するために、以下の組み合わせが最適です：

A: AWS Step Functions と CloudFront を使ってレポート作成と配信の自動化。

D: AWS IoT Core と Lambda を使用して、デバイスからのデータ収集と処理を自動化。

E: MongoDB クラスターを Amazon DocumentDB に移行して、データベースの運用負荷を軽減。

これらのサービスを組み合わせることで、IoT プラットフォームのスケーラビリティとパフォーマンスを保ちながら、運用負荷を最小限に抑えることができます。

506-AWS SAP AWS 「理論・実践・一問道場」API 使用プラン

理論

API Gateway とコスト管理のベストプラクティス

AWS API Gatewayは、Web APIの作成と管理を簡素化するための強力なサービスです。API Gatewayは、Lambda関数やその他のAWSサービスと連携し、さまざまなアプリケーションのバックエンドを効率的に管理することができます。しかし、APIのトラフィックが急増した場合のコスト管理が重要です。以下では、API Gatewayのコスト管理と最適化のための主要なベストプラクティスを解説します。

1. 使用プランとスロットリング制限

API Gatewayでは、使用プラン（Usage Plan）とスロットリング制限（Throttling Limit）を設定することで、APIのトラフィックを管理できます。この機能を活用することで、以下のことが可能になります。

レート制限: APIへのリクエスト数を時間単位で制限することで、過剰なトラフィックを防ぎます。例えば、秒間で受け付ける最大リクエスト数を設定することができます。

クォータ制限: 使用プランで、APIを通じてどれくらいのデータを消費できるかの上限を設定することができます。これにより、特定の期間内におけるAPIの消費を制限し、過剰なコストが発生するのを防ぎます。

このアプローチは、APIを提供する側がトラフィックを制御し、過剰なリクエストや予期しない利用の増加を防ぐために効果的です。

2. API キーとアクセス制限

API Gatewayでは、API キーを利用して特定の開発者やユーザーにAPIアクセスを許可することができます。APIキーを作成し、それに対する使用プランを定義することで、個別の開発者グループやサービスのリクエストを制御することが可能です。

アクセス制御: APIキーを使うことで、特定のユーザーやクライアントに対してアクセスを許可し、その使用状況を監視することができます。

課金とモニタリング: API Gatewayでは、APIキーごとの使用状況をトラッキングできます。これにより、どのユーザーがどれだけのリソースを消費しているのかを把握しやすくなります。

3. API Gateway と Lambda 関数のスケーリング

API Gatewayは、トラフィックが増加した場合にLambda関数を自動的に呼び出して処理を行います。Lambda関数は、スケーリングに関して非常に柔軟であり、トラフィック量に応じて自動的にスケールします。しかし、トラフィック急増時にリソースの消費が過剰になる可能性があるため、Lambda関数のスケーリングを適切に設定することが重要です。

プロビジョニングされた同時実行数: AWS Lambdaでプロビジョニングされた同時実行数を設定することで、リクエストの増加に対して事前にリソースを確保できます。これにより、急激なトラフィックの増加にも対応可能ですが、事前に容量を確保している分、必要以上にリソースを消費してしまう可能性もあります。

オンデマンドのスケーリング: オンデマンドスケーリングでは、Lambda関数が実際に呼び出されたときに必要なリソースが確保されます。この方法はコスト効率が高いですが、急なトラフィックの増加時に遅延が生じる可能性もあります。

4. モニタリングとアラートの設定

API Gatewayのトラフィックを効率的に管理するためには、モニタリングとアラート設定が欠かせません。AWS CloudWatchを使ってAPI GatewayやLambdaのメトリクスをモニタリングし、特定の閾値を超えた場合にアラートを発動するように設定することができます。

メトリクスの監視: API Gatewayのリクエスト数、エラー率、Lambda関数の実行時間など、重要なメトリクスを監視します。

アラートの設定: APIの利用が急激に増加した場合にアラートを送信する設定を行い、コスト増加の兆候に早期に対応することができます。

結論

API Gatewayを使用しているシステムでは、使用プランとスロットリング制限を設定することが最も効果的なコスト管理方法となります。これにより、トラフィックの急増を抑制し、コストの最適化を図ることができます。また、APIキーを利用してアクセス制限を行い、個別に使用状況をモニタリングすることも重要です。

実践

略

一問道場

問題 #506

ある会社は、Amazon API Gateway API を作成し、外部の開発チームと API を共有しています。この API は AWS Lambda 関数を使用しており、「Production」という名前のステージにデプロイされています。外部開発チームは API の唯一の消費者です。この API は特定の時間に急激に使用量が増加し、コストの増加について懸念があります。会社は、Lambda 関数を再作成することなく、コストと使用量を制限する必要があります。

どの解決策が最もコスト効果が高いですか？

A. API を Amazon Simple Queue Service (Amazon SQS) キューにリクエストを送信するように設定します。その後、Lambda 関数を更新してキューからメッセージを消費し、リクエストを処理します。新しいメッセージが到着すると、キューが Lambda 関数を呼び出すように設定します。

B. 各 Lambda 関数に対してプロビジョニングされた同時実行数を設定します。AWS Application Auto Scaling を使用して、Lambda 関数をターゲットとして登録します。スケーリングスケジュールを設定して、API の使用状況に合わせて容量を増減させます。

C. API Gateway API キーを作成し、AWS WAF Regional Web ACL を作成します。Web ACL を Production ステージに関連付けます。Web ACL にレートベースのルールを追加します。このルールで、レート制限と X-API-Key ヘッダーを使用したカスタムリクエスト集約を指定します。API キーを外部の開発チームと共有します。

D. API Gateway API キーと使用プランを作成します。使用プランでスロットリング制限とクォータを定義します。使用プランを Production ステージと API キーに関連付けます。API キーを外部の開発チームと共有します。

解説

この問題では、API Gateway と Lambda 関数を使用しているシステムで、外部の開発チームに対する API の使用制限とコストの最適化が求められています。具体的には、Lambda 関数の再設計なしで、API の使用を効率的に管理し、コストを抑える方法を見つける必要があります。

以下は各選択肢の詳細な解説です。

A. SQS キューを使用する方法

内容: API Gateway がリクエストを SQS キューに送信し、Lambda 関数はそのキューからメッセージを処理します。

問題点: この方法は、リクエストをキューに入れてから Lambda 関数で処理するため、キューから Lambda 関数を呼び出す設定が必要です。これにより、レイテンシーが増加し、Lambda 関数の呼び出し回数を最適化することが難しくなります。また、SQS は即時処理を行いたい API に対しては不適切であり、コスト効果も低くなります。

結論: この方法は最適ではなく、コスト効果を最大化するためには他の方法が望ましいです。

B. プロビジョニングされた同時実行数と自動スケーリング

内容: Lambda 関数にプロビジョニングされた同時実行数を設定し、API のトラフィックに合わせてスケーリングを管理します。

問題点: プロビジョニングされた同時実行数は、事前に指定した数の同時実行を確保するため、ピーク時に容量を増やすことはできますが、API の需要が予測できない場合、無駄にリソースを消費する可能性があります。コストを抑えるためには、使用率に応じて動的にスケールする方が適切です。

結論: この方法は、予測可能なトラフィックの場合には有効ですが、急激なトラフィックの変動には適していません。

C. WAF と API キーを使用した制限

内容: API キーを作成し、WAF (Web Application Firewall) を使用して、API へのリクエストのレート制限を設定します。この方法は、API キーを外部の開発チームと共有し、アクセスを制限することで、過剰なリクエストを防ぐことができます。

問題点: WAF でレート制限を設定することは、API の使用量を制限するために有効ですが、API のトラフィックを管理する手段としては柔軟性が低いです。これだけではコスト削減の要件を満たすのに十分ではない可能性があります。

結論: 直接的に API の使用を制限できますが、Lambda 関数の実行回数を最適化する方法としては不十分です。

D. 使用プランとスロットリング制限の設定

内容: API Gateway で API キーを作成し、使用プランを設定してスロットリング制限（リクエストの最大数）やクォータ（使用量の制限）を定義します。これにより、API の使用を制限し、コストを管理できます。

利点: 使用プランとスロットリング制限を設定することで、API のトラフィックを制御でき、外部開発チームによる過剰なリクエストを防げます。これにより、予期しないトラフィックの急増に対してもコストを抑制できます。

結論: 最もコスト効果が高い方法です。API 使用量を制限し、開発チームに明確な制限を設けることができるため、コストとパフォーマンスのバランスが取れています。

結論

最もコスト効果が高いのは D の「使用プランとスロットリング制限の設定」です。この方法は、API のトラフィックを効率的に管理し、過剰な使用を防ぎ、予期しないコストの増加を抑えることができます。また、Lambda 関数の再設計や大規模なインフラストラクチャの変更を避けることができ、運用負荷も最小限に抑えられます。

507-AWS SAP AWS 「理論・実践・一問道場」Mountpoint for Amazon S3

理論

EC2インスタンスのデータ同期

AWSを利用する際、複数のEC2インスタンスで同じデータを共有・同期するニーズは一般的です。その解決方法とそれぞれの特性を以下にまとめます。

1. S3を活用したデータ共有

特徴

Amazon S3は高耐久性のオブジェクトストレージであり、データの共有に適しています。

適した用途: 静的データや頻繁に更新されるファイルを共有する場合。

ポイント:

S3バケットに直接アクセス: EC2インスタンスが最新のデータを取得可能。
Mountpoint for Amazon S3: S3をローカルストレージのように利用できるため、アプリケーションの変更が最小限。
コスト: S3ストレージ料金とリクエスト料金が発生。

2. DynamoDBを使用したデータ管理

特徴

DynamoDBは低レイテンシでスケーラブルなデータベースサービス。

適した用途: 動的データや高頻度で読み書きが発生する場合。

ポイント:

データベース設計が必要（キー設計やテーブル構造）。
APIを通じてデータをリアルタイムで取得。
読み取り/書き込み容量の調整が可能でコスト効率が高い。

3. Amazon EFSを使用したファイル共有

特徴

Amazon Elastic File System (EFS)は複数のEC2インスタンスで共有可能なファイルシステム。

適した用途: 継続的に変更される共有ファイルが必要な場合。

ポイント:

インスタンス間でリアルタイムで同期。
コストが高く、アクセス頻度が増えるほど費用がかさむ。

4. Amazon EBS + Multi-Attach

特徴

Amazon Elastic Block Store (EBS)は、EC2インスタンス専用のストレージ。

適した用途: 高速なローカルストレージが必要な場合。

ポイント:

Multi-Attachを利用して複数のインスタンスで1つのボリュームを共有可能。
同時書き込みが必要な場合は注意が必要。
容量制限があり、スケーラビリティは低い。

選択時の重要ポイント

データの性質

静的データか動的データか。

更新頻度やリアルタイム性の要求。

コスト効率

頻繁なアクセスが必要な場合、EFSやDynamoDBよりS3が安価。

実装の簡便さ

アプリケーションの改修が少ない方法を選択。

スケーラビリティ

スケールアウト時に対応可能な設計が必要。

推奨シナリオ

S3 + Mountpoint for Amazon S3: 低コストで静的なファイル共有に最適。

DynamoDB: 動的データやリアルタイムアクセスが必要な場合に最適。

EFS: 複数インスタンスで頻繁に更新するデータ共有が必要な場合に適切。

EBS Multi-Attach: 高速なI/O性能が必要な場合に限定的に使用。

実践

略

一問道場

質問 #507

あるエンターテインメント企業が、自社のチケットサービスをLinuxベースのAmazon EC2インスタンスのAuto Scalingグループ上でホストしています。このチケットサービスは価格情報を記載したファイル（pricing file）を使用しています。この価格情報ファイルは、S3 StandardストレージのAmazon S3バケットに保存されています。価格情報ファイルは、外部のサードパーティがホストする中央価格設定ソリューションによって更新されます。

価格情報ファイルは1～15分ごとに更新され、数千のアイテムが含まれています。価格情報ファイルは、EC2インスタンスが起動する際に各インスタンスにダウンロードされます。ただし、EC2インスタンスが時折古い価格情報を使用し、それにより顧客に対して不正確な請求が発生する可能性があります。

この問題を最もコスト効率良く解決するソリューションはどれですか？

A. AWS Lambda関数を作成して、価格情報ファイルが更新されるたびに新しい価格をAmazon DynamoDBテーブルに更新します。チケットサービスを更新してDynamoDBを使用して価格情報を取得するようにします。

B. AWS Lambda関数を作成して、価格情報ファイルが更新されるたびにAmazon Elastic File System (Amazon EFS)ファイル共有を更新します。チケットサービスを更新してAmazon EFSを使用して価格情報ファイルにアクセスするようにします。

C. Mountpoint for Amazon S3をEC2インスタンスのAMIにロードします。Mountpoint for Amazon S3を構成して、価格情報ファイルを格納しているS3バケットをマウントします。チケットサービスを更新して、マウントポイントおよびパスを介してS3オブジェクトにアクセスするようにします。

D. Amazon Elastic Block Store (Amazon EBS)ボリュームを作成します。EBS Multi-Attachを使用して、このボリュームをすべてのEC2インスタンスにアタッチします。新しいEC2インスタンスが起動する際に、ボリューム上の価格情報ファイルを更新するようにインスタンスを構成します。チケットサービスを更新して、新しいローカルソースを参照するようにします。

解説

質問の背景

EC2インスタンスが時折古い価格情報を使用するため、顧客に不正確な請求が発生する問題があります。この課題を解決するには、価格情報ファイルをリアルタイムまたはほぼリアルタイムで同期し、すべてのインスタンスが最新情報を利用できるようにする必要があります。また、コスト効率の高い方法が求められています。

各オプションの解説

A. AWS Lambda + DynamoDB

概要: 価格情報ファイルの更新をトリガーにしてAWS Lambdaが新しい価格情報をDynamoDBに書き込み、EC2インスタンスがDynamoDBから価格情報を取得する。

利点:

DynamoDBは分散データベースであり、すべてのEC2インスタンスがリアルタイムで最新の価格情報にアクセス可能。
更新頻度が高くてもDynamoDBはスケーラブル。

欠点:

DynamoDBのテーブル設計とEC2側のコード変更が必要。

コスト効率: 高い（DynamoDBのRead/Writeスループットは課金されるが、頻度と規模を考えると割安）。

B. AWS Lambda + Amazon EFS

概要: 価格情報ファイルをAmazon EFSに保存し、EC2インスタンスはEFSを共有ストレージとして価格情報を取得する。

利点:

すべてのインスタンスが共有ストレージを使用するため、同期の問題が発生しない。
ファイル形式を変更せずそのまま使用可能。

欠点:

Amazon EFSはコストが高い。
レイテンシが発生する場合がある。

コスト効率: 低い（特にスケールアウト時にEFSのコストが増加）。

C. Mountpoint for Amazon S3

概要: EC2インスタンスにMountpoint for Amazon S3をインストールし、価格情報ファイルが格納されているS3バケットを直接マウントしてアクセスする。

利点:

EC2インスタンスが常にS3内の最新ファイルにアクセス可能。
ファイルダウンロードが不要になり、同期の問題が解消。
コスト効率が高い（S3のストレージ料金のみ）。

欠点:

Mountpoint for Amazon S3のセットアップと運用が必要。
高頻度でアクセスする場合、S3リクエストコストが増加する可能性。

コスト効率: 非常に高い（ストレージとアクセスコストのみ）。

D. Amazon EBS + Multi-Attach

概要: EBSボリュームをMulti-Attachで複数のEC2インスタンスに接続し、ファイルを共有する。

利点:

ローカルストレージとして使用可能なため、レイテンシが最小化。
同期が一元化される。

欠点:

EBSボリュームの容量には限界がある。
Multi-Attachのセットアップが複雑で、同時書き込みの問題が発生する可能性。

コスト効率: 中程度（EBSストレージとインスタンスへの接続コストが必要）。

最適解

C. Mountpoint for Amazon S3

Mountpoint for Amazon S3を使用する方法が最もコスト効率が高く、簡単にすべてのEC2インスタンスで最新の価格情報を利用できます。この方法はS3バケットを直接マウントするため、価格情報ファイルの同期が不要になります。設定が比較的容易で、更新頻度の高いシナリオにも適しています。

選択肢のまとめ

オプション	コスト効率	実装難易度	リアルタイム性	推奨度
A	高い	中程度	高い	⭐⭐⭐⭐
B	低い	中程度	高い	⭐⭐
C	非常に高い	低い	高い	⭐⭐⭐⭐⭐
D	中程度	高い	中程度	⭐⭐⭐

508-AWS SAP AWS 「理論・実践・一問道場」AWS Service Catalog

理論

AWSを使用した安全な環境立ち上げに関するポイント

AWS環境で複数のユーザーや部門が関与する場合、適切な権限管理と効率的なプロビジョニングが重要です。以下は、関連する汎用的な知識を簡潔にまとめたものです。

1. 最小権限の原則（Principle of Least Privilege）

各ユーザーや役割（IAMロール）には、必要最小限の権限のみを付与する。

直接的なAPIやリソース操作を避け、制御された手段（例: AWS Service Catalog）を提供することでリスクを低減。

2. AWS Service Catalogの活用

概要: 管理者が事前に承認済みのリソースセット（CloudFormationテンプレートなど）をカタログ化し、ユーザーに提供。

利点:

起動制約を適用し、リソース作成時に指定のロールを使用させる。
環境の標準化と管理の簡素化。
ユーザーはAWS Service CatalogコンソールまたはCLIから安全に環境を立ち上げ可能。

3. AWS CloudFormationの活用

概要: インフラをコードとして管理し、リソースの構築・更新・削除を自動化。

利点:

再現性のある環境構築が可能。
IAMポリシーを使用して、特定のテンプレートとその作成リソースに限定的なアクセスを許可可能。

4. IAMロールの引き受け（Role Assumption）

概要: 特定の操作を行う際、一時的に権限を付与するロールを引き受ける仕組み。

利点:

必要なときだけ権限を有効化できる。
ロールを細かく制御することでセキュリティを強化。

5. AWS Elastic Beanstalkの利用（必要に応じて）

概要: Webアプリケーションやサービスを簡単にデプロイできるプラットフォーム。

利点:

アプリケーションのデプロイと運用を簡素化。

注意点: 汎用性が低く、既存のCloudFormationテンプレートを利用する場合には適さない場合がある。

6. セキュリティと管理のベストプラクティス

タグ付け: 各リソースにタグを付与して、監視やコスト管理を容易にする。

CloudTrailの利用: リソースやAPI操作の追跡を有効化し、監査ログを取得。

予算制限の設定: AWS Budgetsを活用して、利用コストを管理。

まとめ

AWS Service Catalogは、制御された環境立ち上げに最適であり、最小権限の原則を確保しやすい。

IAMロールやCloudFormationテンプレートを正しく設計することで、ユーザーが安全に環境を操作できる。

実践

略

一問道場

質問 #508

ある企業がアプリケーションを使用しており、このアプリケーションはAuto Scalingグループ内のAmazon EC2インスタンスを利用しています。品質保証（QA）部門では、大量の短期間の環境を立ち上げてアプリケーションをテストする必要があります。現在、アプリケーション環境はAWS CloudFormationテンプレートを使用して部門マネージャーが立ち上げています。スタックを立ち上げるために、マネージャーはCloudFormation、EC2、Auto Scaling APIを使用する権限を持つロールを使用しています。

マネージャーはテスターが自分たちで環境を立ち上げられるようにしたいと考えていますが、各ユーザーに広範な権限を与えることは避けたいとしています。

この目標を達成するためには、どのセットアップが適していますか？

A. AWS CloudFormationテンプレートをAmazon S3にアップロードします。QA部門のユーザーに、マネージャーのロールを引き受ける権限を付与し、そのテンプレートとそれが作成するリソースへの権限のみを許可するポリシーを追加します。ユーザーにCloudFormationコンソールからテンプレートを起動する方法を教えます。

B. 環境テンプレートからAWS Service Catalog製品を作成します。この製品に既存のロールを使用した起動制約を追加します。QA部門のユーザーにAWS Service Catalog APIの使用権限のみを付与します。ユーザーにAWS Service Catalogコンソールからテンプレートを起動する方法を教えます。

C. AWS CloudFormationテンプレートをAmazon S3にアップロードします。QA部門のユーザーにCloudFormationおよびS3 APIの使用権限を付与しますが、その権限をテンプレートとそれが作成するリソースに制限する条件を設定します。ユーザーにCloudFormationコンソールからテンプレートを起動する方法を教えます。

D. 環境テンプレートからAWS Elastic Beanstalkアプリケーションを作成します。QA部門のユーザーにElastic Beanstalk権限のみを付与します。Elastic Beanstalk CLIを使用して既存のロールをサービスロールとして環境に渡し、Elastic Beanstalk環境を起動する方法をユーザーに教えます。

解説

このシナリオでは、以下のポイントが重要です：

QA部門のユーザーが自分たちで環境を立ち上げられること

広範な権限を各ユーザーに与えることを避けること

現行のAWS CloudFormationテンプレートを使用することを考慮

各選択肢を検討すると、適切な答えは B です。以下でその理由を解説します。

選択肢の分析

A. マネージャーのロールを引き受ける権限を付与する方法

メリット: CloudFormationテンプレートを再利用でき、現在のマネージャーのロールを活用できる。

デメリット: 各ユーザーがマネージャーのロールを引き受けることになるため、意図せず広範な権限を与えてしまう可能性がある。

結論: ユーザーに最小権限を提供するという目標に反する。

B. AWS Service Catalogを利用する方法

メリット:

Service Catalogはカタログ化された製品をユーザーに提供し、背後の複雑さを隠すことができる。
既存のロールを使用した起動制約を適用することで、ユーザーに広範な権限を与えず、制御された環境の立ち上げを可能にする。
使い方を制御しやすく、権限もService Catalogの操作に限定できる。

デメリット: Service Catalogのセットアップが必要。ただし、一度設定すれば運用が容易。

結論: 目標に最も適している。

C. CloudFormationとS3 APIを直接使用する方法

メリット: テンプレートを再利用できる。

デメリット: S3 APIやCloudFormation APIを直接操作する権限をユーザーに付与する必要があり、設定が複雑になる。

また、テンプレートと作成リソースへのアクセス制御を設定するのが難しくなる可能性がある。

結論: 権限を厳密に制御するのが難しいため、最適ではない。

D. AWS Elastic Beanstalkを利用する方法

メリット: Elastic Beanstalkはアプリケーションの管理を簡素化できる。

デメリット:

現在のAWS CloudFormationテンプレートをElastic Beanstalk用に変更する必要があり、大きな変更が必要。
Elastic Beanstalkの設定がCloudFormationテンプレートと比較して柔軟性が低い可能性がある。

結論: 現状の構成と大きく異なり、目標達成に最適ではない。

正解: B. AWS Service Catalogを利用する方法

理由:

AWS Service Catalogを使用すれば、マネージャーが既存のCloudFormationテンプレートをカタログ製品として設定し、ユーザーにそのテンプレートを簡単に立ち上げる手段を提供できます。また、起動制約を設定することで、ユーザーが広範な権限を持つことを防ぎつつ、必要なリソースの作成を適切に管理できます。

これにより、**セキュリティ要件（最小権限の原則）**を満たしつつ、ユーザーが自律的に環境を作成することが可能になります。

509-AWS SAP AWS 「理論・実践・一問道場」マルチリージョン

理論

AWSを使用したマルチリージョン対応と災害復旧計画のポイント

1. マルチリージョン設計の重要性

災害復旧: 1つのリージョンで障害が発生した場合でも、別のリージョンでサービスを継続可能にする。

ユーザー体験向上: レイテンシーベースのルーティングで、ユーザーに近いリージョンからリソースを提供することで応答時間を短縮。

スケーラビリティ: 将来的な成長に対応するため、複数のリージョンでリソースを分散。

2. AWSサービスを活用した実装手順

インフラの複製:

AWS CloudFormation: テンプレートを使用して既存のインフラを効率的に複製。

テンプレートのパラメーター化: リージョン固有の値を動的に設定可能。

トラフィック分散:

Amazon Route 53:

Latency-based Routing（レイテンシーベースルーティング）: ユーザーに最適なリージョンにトラフィックを誘導。
Weighted Routing（加重ルーティング）: 複数リージョンへのトラフィックを指定の割合で分散。

データ同期:

DynamoDBグローバルテーブル:

複数リージョン間でデータをリアルタイムに同期。
DynamoDB Streamsを有効化してテーブルをグローバル化。

3. ベストプラクティス

最小権限の原則: IAMロールやポリシーを適切に設定して、必要最小限の権限を付与。

自動化: CloudFormationやAWS CDKでインフラの構築・更新を自動化し、ミスを防止。

監視と監査: Amazon CloudWatchやAWS CloudTrailを使用して、リソースのパフォーマンスとセキュリティを監視。

4. まとめ

マルチリージョン設計を適切に実施することで、災害復旧能力、ユーザー体験の向上、成長への柔軟性が得られる。AWSのサービスを組み合わせることで、効率的かつ安全に目標を達成可能です。

実践

略

一問道場

質問 #509

ある企業が単一のAWSリージョンでECサイトを運営しています。このウェブサイトは、Application Load Balancer（ALB）の背後に配置された複数のAmazon EC2インスタンスで動作するウェブアプリケーションを含んでいます。また、Amazon DynamoDBテーブルも使用しています。ALBにはAmazon Route 53でカスタムドメイン名がリンクされており、AWS Certificate Manager（ACM）で作成したSSL/TLS証明書がALBにアタッチされています。現在、この設計にはコンテンツ配信ネットワーク（CDN）は使用されていません。

この企業は、次の目標を達成するためにアプリケーション全体のスタックを2つ目のリージョンに複製したいと考えています：

災害復旧計画の作成

将来的な成長への対応

ユーザーへのアクセス時間の改善

ソリューションアーキテクトは、これらの目標を達成し、管理上の負担を最小限に抑えるためのソリューションを実装する必要があります。

次のうち、目標を達成するためにソリューションアーキテクトが実行すべきステップの組み合わせはどれですか？（3つ選択してください）

選択肢

A. 現在のインフラ設計用にAWS CloudFormationテンプレートを作成します。重要なシステム値（リージョンなど）のためにパラメーターを使用します。そのCloudFormationテンプレートを使用して、2つ目のリージョンで新しいインフラを作成します。

B. AWS Management Consoleを使用して、最初のリージョンの既存インフラ設計を文書化し、2つ目のリージョンで新しいインフラを作成します。

C. アプリケーション用のRoute 53ホストゾーンレコードを更新して、加重ルーティング（Weighted Routing）を使用します。各リージョンのALBにトラフィックの50%を送信します。

D. アプリケーション用のRoute 53ホストゾーンレコードを更新して、レイテンシーベースのルーティング（Latency-based Routing）を使用します。各リージョンのALBにトラフィックを送信します。

E. 既存のDynamoDBテーブルの設定を更新し、DynamoDB Streamsを有効化します。2つ目のリージョンを追加してグローバルテーブルを作成します。

F. 新しいDynamoDBテーブルを作成し、そのテーブルに対してDynamoDB Streamsを有効化します。2つ目のリージョンを追加してグローバルテーブルを作成します。既存のDynamoDBテーブルから新しいテーブルにデータを1回限りの操作でコピーします。

解説

このシナリオでは、ECサイトを2つ目のAWSリージョンに複製して、以下の目標を達成する必要があります：

災害復旧（Disaster Recovery）計画の作成

将来的な成長への対応

ユーザーのアクセス時間の改善

これらの目標を達成するため、以下の要件を満たすソリューションが必要です：

インフラの複製：既存のアプリケーションスタックを別のリージョンに効率的に複製する必要があります。

データの同期：DynamoDBテーブルのデータを複数リージョンで同期して、全体的な整合性を保つ必要があります。

トラフィック分散：複数リージョンのリソースを活用して、ユーザーに最適なレスポンスを提供する必要があります。

以下に各選択肢の検討結果を示します。

選択肢の分析

A. CloudFormationテンプレートでインフラを複製

解説: CloudFormationテンプレートを使用することで、既存のインフラを効率的に別のリージョンに複製できます。テンプレートでパラメーターを使用することで、リージョン固有の値を簡単に切り替えられるため、管理の負担が軽減されます。

評価: 必要な手順であり、正解。

B. AWS Management Consoleで手動操作

解説: 手動でインフラを複製する方法ですが、ミスが発生しやすく、管理の負担が大きくなります。目標の「管理負担を最小限にする」に反します。

評価: 不正解。

C. Weighted Routingを使用してトラフィック分散

解説: Weighted Routing（加重ルーティング）を使用すると、トラフィックを特定の割合で複数リージョンに分散できます。しかし、この方法はレイテンシーに基づく分散ではないため、アクセス時間の改善には直接つながりません。災害復旧計画の一部としては役立つ可能性がありますが、最適ではありません。

評価: 不正解。

D. Latency-based Routingを使用してトラフィック分散

解説: Latency-based Routing（レイテンシーベースのルーティング）は、ユーザーに最も近いリージョンのリソースにトラフィックを送信します。これにより、アクセス時間を短縮し、ユーザー体験を改善できます。また、2つ目のリージョンを活用できるようになるため、成長計画にも適合します。

評価: 必要な手順であり、正解。

E. 既存DynamoDBテーブルをグローバルテーブル化

解説: DynamoDB Streamsを有効にして、既存テーブルをグローバルテーブルとして設定することで、データが複数リージョン間でリアルタイムに同期されます。これにより、データの整合性を保ちながら2つ目のリージョンをサポートできます。

評価: 必要な手順であり、正解。

F. 新しいDynamoDBテーブルを作成してデータをコピー

解説: 新しいDynamoDBテーブルを作成してデータをコピーする方法は、初期構築時には可能ですが、継続的な同期が必要なこのシナリオには適していません。また、既存テーブルをグローバルテーブル化すればコピー作業は不要になります。

評価: 不正解。

正解: A, D, E

理由

A: CloudFormationテンプレートを使用してインフラを複製することで、効率的かつ一貫性のある展開が可能になる。

D: Latency-based Routingを使用することで、ユーザーのアクセス時間を短縮し、最適なリージョンでリソースを利用可能にする。

E: 既存のDynamoDBテーブルをグローバルテーブル化することで、複数リージョン間でデータのリアルタイム同期を実現する。

これらの手順により、災害復旧、将来の成長対応、およびユーザー体験の向上を効率的に達成できます。

510-AWS SAP AWS 「理論・実践・一問道場」タグプレフィックス

理論

S3アクセス制御とログ管理のベストプラクティス

1. S3へのユーザーごとのアクセス制御

IAM条件キーの活用:

aws:PrincipalTag/userNameを利用して、ユーザーごとにプレフィックス（フォルダ）を分離。
例: ユーザー「Alice」にはbucket/Alice/以下のみアクセスを許可。

IAM Identity Center（旧AWS SSO）の統合:

IAM Identity Centerのカスタム権限セットで、自動的にユーザー名タグを適用し、動的なアクセス制御を実現。

2. アクセスログの収集と可視化

AWS CloudTrail:

S3データイベントを有効化することで、どのユーザーがどのオブジェクトにアクセスしたかを詳細に記録。
例: GetObject（読み取り）やPutObject（書き込み）の操作ログ。

Amazon Athenaでのログ解析:

CloudTrailログをS3に保存し、Athenaを使って簡単にクエリを実行。
ユーザー別のアクセス状況や月次レポートを自動生成可能。

3. ベストプラクティスまとめ

ユーザーごとにアクセスを分離: IAM条件キーでS3プレフィックスを制御。

ログ収集と監査: CloudTrailでデータイベントを記録し、Athenaでレポート化。

最小権限の原則: 必要最低限のアクセス権限のみを付与。

これらを組み合わせることで、安全で効率的なデータ管理とログ監査が可能です。

実践

略

一問道場

質問 #510

ある企業が、データサイエンティストが仕事関連の文書を保存できる単一のAmazon S3バケットを作成したいと考えています。この企業はAWS IAM Identity Center（旧AWS SSO）を使用してすべてのユーザーを認証しています。また、データサイエンティスト用のグループが作成されています。

この企業は以下を実現したいと考えています：

データサイエンティストが自分の作業にのみアクセスできるようにすること。

各ユーザーがどの文書にアクセスしたかを示す月次レポートを作成すること。

これらの要件を満たすためには、どの手順の組み合わせが適切ですか？（2つ選択してください）

選択肢

A. カスタムIAM Identity Center権限セットを作成し、データサイエンティストに自分のユーザー名タグ（aws:PrincipalTag/userName）に一致するS3バケットプレフィックスへのアクセス権限を付与します。ポリシーで条件を使用し、パスを「aws:PrincipalTag/userName/*」に制限します。

B. データサイエンティストグループ用のIAM Identity Centerロールを作成し、そのロールにAmazon S3の読み取りアクセスおよび書き込みアクセスを付与します。また、IAM Identity Centerロールへのアクセスを許可するS3バケットポリシーを追加します。

C. AWS CloudTrailを設定してS3データイベントをログに記録し、ログをS3バケットに配信します。Amazon Athenaを使用して、Amazon S3に保存されたCloudTrailログにクエリを実行し、レポートを生成します。

D. AWS CloudTrailを設定してS3管理イベントをCloudWatchに記録します。Amazon AthenaのCloudWatchコネクタを使用してログにクエリを実行し、レポートを生成します。

E. S3アクセスログをEMRファイルシステム（EMRFS）に有効化します。Amazon S3 Selectを使用してログにクエリを実行し、レポートを生成します。

解説

この問題では、以下の2つの要件を満たす必要があります：

データサイエンティストごとに独立したアクセス権

各データサイエンティストが自分のプレフィックス（パス）にのみアクセスできるようにする。

これにより、他のユーザーのデータを保護できる。

アクセスログの収集とレポート作成

どのユーザーがどの文書にアクセスしたかを記録し、月次レポートとして確認できるようにする。

以下に各選択肢の詳細な分析を示します。

選択肢の分析

A. カスタムIAM Identity Center権限セットでアクセス制御

解説: IAM Identity Centerのカスタム権限セットを使用し、データサイエンティストに「ユーザー名に基づくプレフィックス」のみアクセス可能なポリシーを設定する方法です。IAMの条件キーaws:PrincipalTag/userNameを使用して、アクセスをユーザー名タグで制限することができます。

例:

ユーザー「Alice」は「s3://bucket/Alice/」以下にのみアクセス可能。
ユーザー「Bob」は「s3://bucket/Bob/」以下にのみアクセス可能。

メリット: 各ユーザーが他のユーザーのデータにアクセスできなくなり、要件を満たします。

評価: 正解。

B. IAM Identity CenterロールとS3バケットポリシーでアクセス制御

解説: IAM Identity Centerロールをグループに付与し、Amazon S3の読み取り/書き込みアクセス権を付与する方法です。ただし、この方法では全てのデータサイエンティストがS3バケット全体にアクセス可能になります。他のユーザーのデータにアクセスできてしまうため、要件に反します。

評価: 不正解。

C. AWS CloudTrailとAthenaでログ収集・レポート生成

解説: AWS CloudTrailを使用してS3のデータイベント（データレベルの操作）を記録し、そのログをAthenaでクエリする方法です。CloudTrailは、誰がどのオブジェクトにアクセスしたか（GetObjectやPutObjectなど）を詳細に記録できます。Athenaを使用することで、簡単に月次レポートを生成可能です。

評価: 正解。

D. CloudTrail管理イベントをCloudWatchでクエリ

解説: S3管理イベント（バケット作成や削除など）をCloudTrailで記録し、CloudWatchを介してAthenaでクエリする方法です。しかし、この方法は「データイベント」ではなく「管理イベント」のみを記録するため、特定のオブジェクトへのアクセス（GetObjectやPutObject）は記録されません。月次レポート要件を満たせません。