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

type

status

date

slug

summary

241-AWS SAP AWS 「理論・実践・一問道場」AWS IoT Core

理論

スマート車両データ処理に関連する知識

1. MQTTプロトコルとAWS IoT Core

MQTTは軽量な通信プロトコルで、IoTデバイスからのデータ送信に最適。

AWS IoT CoreはMQTTをサポートし、IoTデバイスからのデータを効率的に収集・ルーティングできるマネージドサービス。

2. Amazon Kinesis Data Firehose

リアルタイムデータストリーミング: データを処理して、S3やRedshiftに直接保存可能。

マネージド型: 運用負荷が低く、大量のデータにスケール対応。

3. Kinesis Data Analytics

リアルタイム分析: ストリーミングデータを即座に処理し、異常検出や集計を実行可能。

SQLベース: 使いやすく、複雑な分析ロジックも実装できる。

4. Amazon S3

スケーラブルなストレージ: 保存容量を気にせず、大量のデータを効率的に保存。

耐久性と可用性: 重要データのバックアップやアーカイブに最適。

5. リアルタイム異常検出の手法

Kinesis Data Analytics: 定義したルールに基づいて異常検出。

高度な分析が必要な場合: Amazon SageMakerやLookout for Metricsの利用も選択肢。

6. 運用負荷の最小化

マネージドサービス（IoT Core、Kinesis Firehose、Data Analytics）を活用し、システム構築と運用管理を簡素化。

この知識を活用することで、大量のIoTデバイスからのデータ収集・分析を効率的に実現できます。

実践

略

一問道場

Question #241

トピック 1

ある企業がスマート車両を製造しています。この企業では、カスタムアプリケーションを使用して車両データを収集しています。車両はMQTTプロトコルを使用してアプリケーションに接続しています。企業では、データを5分間隔で処理し、車両のテレマティクスデータをオンプレミスのストレージにコピーしています。カスタムアプリケーションがこのデータを分析して異常を検出しています。

送信データを生成する車両の数は増え続けています。新しい車両は高いデータ量を生成するため、オンプレミスのストレージソリューションではピークトラフィックに対応できず、データ損失が発生しています。企業はこのソリューションを近代化し、スケーリングの課題を解決するためにAWSに移行する必要があります。

この要件を満たし、運用上のオーバーヘッドを最小限に抑えるソリューションはどれですか？

A. AWS IoT Greengrass を使用して車両データを Amazon Managed Streaming for Apache Kafka (Amazon MSK) に送信します。Apache Kafka アプリケーションを作成してデータを Amazon S3 に保存し、Amazon SageMaker の事前学習済みモデルを使用して異常を検出します。

B. AWS IoT Core を使用して車両データを受信します。Amazon Kinesis Data Firehose 配信ストリームにデータをルーティングするルールを設定し、そのデータを Amazon S3 に保存します。Amazon Kinesis Data Analytics アプリケーションを作成し、配信ストリームから読み取って異常を検出します。

C. AWS IoT FleetWise を使用して車両データを収集します。そのデータを Amazon Kinesis データストリームに送信します。Amazon Kinesis Data Firehose 配信ストリームを使用してデータを Amazon S3 に保存します。AWS Glue の組み込み機械学習変換を使用して異常を検出します。

D. Amazon MQ for RabbitMQ を使用して車両データを収集します。そのデータを Amazon Kinesis Data Firehose 配信ストリームに送信して Amazon S3 に保存します。Amazon Lookout for Metrics を使用して異常を検出します。

解説

この問題では、以下の要件を満たしながら運用負荷を最小限に抑えるAWSソリューションを選択します：

スケーラビリティ：増え続ける車両と大量のデータに対応可能であること。

データ処理の効率化：データを定期的に処理し、異常検出を実行すること。

運用負荷の軽減：自動化やマネージドサービスを活用すること。

選択肢の比較

A. AWS IoT Greengrass + Amazon MSK + SageMaker

メリット:

Apache Kafka はリアルタイムデータ処理に強い。
SageMaker による高度な機械学習モデルを使用可能。

デメリット:

Greengrass の導入や Kafka の管理は複雑で運用負荷が高い。
データを分析後に保存するフローが冗長。

B. AWS IoT Core + Kinesis Data Firehose + Kinesis Data Analytics

メリット:

完全マネージドサービスで運用負荷が低い。
Firehose はデータを S3 に直接保存し、Kinesis Data Analytics がリアルタイム分析を実行。
シンプルでスケーラブルな設計。

デメリット:

SageMaker などの高度な機械学習モデルは使用できないが、要件には合致している。

C. AWS IoT FleetWise + Kinesis + AWS Glue

メリット:

IoT FleetWise は車両データ収集に最適化されている。
Glue の機械学習変換機能で異常検出可能。

デメリット:

AWS Glue の導入やジョブ設計に時間がかかる。
FleetWise のセットアップが複雑。

D. Amazon MQ + Kinesis Firehose + Lookout for Metrics

メリット:

Lookout for Metrics は異常検出専用で使いやすい。

デメリット:

Amazon MQ はスケールアップが難しく、MQTT に比べて効率が低い。
他の選択肢と比べて全体的に複雑で最適ではない。

正解：B

理由:

AWS IoT Core: MQTT に対応しており、車両データを効率的に収集できる。

Amazon Kinesis Data Firehose: データを自動的に Amazon S3 に保存できる。

Kinesis Data Analytics: S3 に保存する前にリアルタイム分析が可能で、異常検出にも対応できる。

マネージドサービスを使用することで運用負荷を最小限に抑え、要件をすべて満たしている。

242-AWS SAP AWS 「理論・実践・一問道場」資格情報の漏洩

理論

セキュリティにおけるAWS IAM資格情報の管理

IAMユーザー資格情報のセキュリティ

シークレットアクセスキーやアクセスキーIDは、セキュリティ上重要な情報であり、ソースコードにハードコーディングすることは危険です。これが漏洩すると、悪用されるリスクが高まります。

AWS CodeCommitとトリガー

CodeCommitは、AWSのGitリポジトリサービスで、コードの管理に使用されます。セキュリティポリシーに基づいて、コードのコミットやプッシュ時にLambda関数をトリガーして、コミット内容をスキャンし、脆弱性（例えば、資格情報の漏洩）を検出することが可能です。

Lambda関数の活用

Lambda関数は、サーバーレスでコードを実行できるAWSのサービスです。CodeCommitでコードが更新されるとLambda関数が自動的に実行され、コードの内容をリアルタイムでチェックして、問題があれば即座に対応します。

セキュリティの自動化

自動化されたセキュリティチェックとアラートシステムを実装することで、手動での対応を最小限に抑え、迅速に脅威を検出し、対策を講じることができます。これにより、セキュリティ運用の負担が軽減され、リスクが減少します。

実践

略

一問道場

質問 #242

トピック 1

監査中に、セキュリティチームは開発チームがIAMユーザーのシークレットアクセスキーをコード内に埋め込み、そのコードをAWS CodeCommitリポジトリにコミットしていることを発見しました。セキュリティチームは、このセキュリティ脆弱性を自動的に発見し修正したいと考えています。

どのソリューションが、資格情報を適切に自動で保護することを保証しますか？

A. AWS Systems Manager Run Commandを使用してスクリプトを毎晩実行し、開発インスタンス内で資格情報を検索します。発見した場合は、AWS Secrets Managerを使用して資格情報を回転させます。

B. 定期的にAWS Lambda関数を使用してCodeCommitからアプリケーションコードをダウンロードし、スキャンします。資格情報が見つかった場合は、新しい資格情報を生成し、AWS KMSに保存します。

C. Amazon Macieを設定してCodeCommitリポジトリ内の資格情報をスキャンします。資格情報が見つかった場合は、AWS Lambda関数をトリガーして資格情報を無効化し、ユーザーに通知します。

D. CodeCommitトリガーを設定してAWS Lambda関数を呼び出し、新しいコードの提出を資格情報スキャンします。資格情報が見つかった場合は、AWS IAMでそれを無効化し、ユーザーに通知します。

解説

この問題は、AWS CodeCommitリポジトリにコミットされたIAMユーザーのシークレットアクセスキーを自動的に検出し、修正するソリューションを求めています。以下に選択肢ごとの説明を示します。

A. AWS Systems Manager Run Command

インスタンス内の資格情報を検索し、Secrets Managerで資格情報を回転する方法です。

問題点: これはインスタンス内のコードを対象としており、CodeCommitリポジトリ内のコードを監視していません。

不適切。

B. 定期的にLambdaを実行してCodeCommitをスキャン

定期的にLambda関数を使用してCodeCommitリポジトリのコードをスキャンするアプローチです。

問題点: Lambdaのスキャンがリアルタイムではなく、資格情報がすぐに悪用されるリスクを防げません。また、KMSは資格情報を管理するための直接的なサービスではありません。

不適切。

C. Amazon Macieを使用してCodeCommitをスキャン

Macieはデータの検出や機密情報の特定には有用ですが、現在のところCodeCommitリポジトリ内のスキャンを直接サポートしていません。また、Lambdaをトリガーする仕組みが明確でない点も課題です。

不適切。

D. CodeCommitトリガーとLambdaを使用

CodeCommitトリガーを設定することで、新しいコードのコミットが発生した際にリアルタイムでAWS Lambdaを呼び出します。Lambdaは資格情報をスキャンし、IAMで資格情報を無効化してユーザーに通知します。

このアプローチは、リアルタイム性が高く、リポジトリのスキャンを自動化する最適な方法です。

適切。

正解: D

理由

CodeCommitトリガーとLambdaを使用することで、新しいコードの提出を自動的に監視し、即座に対応できます。

IAM資格情報を無効化し、ユーザーに通知することでセキュリティリスクを最小限に抑えます。

243-AWS SAP AWS 「理論・実践・一問道場」S3 Access Points

理論

以下に、S3エンドポイントとアクセスポイントの簡潔な違いを示します：

項目	S3エンドポイント	S3アクセスポイント
目的	VPCからS3へのプライベートアクセス	アプリケーションやVPC単位でS3アクセスを管理
アクセス制御	VPC内でアクセス制御	特定のVPCやアプリケーションにアクセス制御
複数VPC対応	1つのVPCのみ	複数のVPC対応
使用例	VPC内のリソースからS3にアクセス	複数アプリケーションがS3にアクセスする場合

ポイント:

エンドポイントはVPCからのアクセス用。

アクセスポイントは複数VPCやアプリケーションにアクセス制御を提供。

実践

略

一問道場

ある企業がAmazon S3にデータレイクを持っており、そのデータレイクに複数のAWSアカウントから数百のアプリケーションがアクセスする必要があります。企業の情報セキュリティポリシーによると、S3バケットはインターネット越しにアクセスできないようにし、各アプリケーションには最小限の権限を付与する必要があります。これらの要件を満たすため、ソリューションアーキテクトは、各アプリケーションのために特定のVPCに制限されたS3アクセスポイントを使用することを計画しています。

このソリューションを実装するためにソリューションアーキテクトが取るべき手順の組み合わせはどれですか？（2つ選んでください）

A. 各アプリケーションのためにS3アクセスポイントを作成し、そのアクセスポイントをアプリケーションのVPCからのみアクセス可能に設定します。バケットポリシーを更新して、アクセスポイントからのアクセスを要求します。

B. 各アプリケーションのVPCにAmazon S3のインターフェースエンドポイントを作成し、エンドポイントポリシーを設定してS3アクセスポイントへのアクセスを許可します。S3エンドポイントにVPCゲートウェイアタッチメントを作成します。

C. 各アプリケーションのVPCにAmazon S3のゲートウェイエンドポイントを作成し、エンドポイントポリシーを設定してS3アクセスポイントへのアクセスを許可します。アクセスポイントにアクセスするために使用するルートテーブルを指定します。

D. 各AWSアカウントの各アプリケーションのためにS3アクセスポイントを作成し、それらのアクセスポイントをS3バケットに接続します。各アクセスポイントをアプリケーションのVPCからのみアクセス可能に設定し、バケットポリシーを更新してアクセスポイントからのアクセスを要求します。

E. データレイクのVPCにAmazon S3のゲートウェイエンドポイントを作成し、エンドポイントポリシーを設定してS3バケットへのアクセスを許可します。バケットにアクセスするために使用するルートテーブルを指定します。

解説

S3アクセスポイントをVPCに制限することで、セキュアなアクセスを実現できます。バケットポリシーでアクセスポイントのみからアクセスを許可することもできます。

ゲートウェイエンドポイントを使用して、アプリケーションのVPCから安全にS3アクセスポイントにアクセスする方法です。プライベート経由です。

この組み合わせが、要求されたセキュリティポリシーと最小限の権限付与を満たす解決策です。

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

理論

AWS CloudWatch LogsからFirehose経由でログを収集 | Splunk

CloudWatch Logsを使用すれば、AWS環境からすべてのログを1カ所に収集可能。Lambda関数(ラムダ式)などを介して、ログソースをソースとログ形式ごとに複数のロググループにまとめられます。この記事では、ログファイルをCloudWatchからSplunkに取り込む方法についてご紹介します。

https://www.splunk.com/ja_jp/blog/tips-and-tricks/how-to-ingest-any-log-from-aws-cloudwatch-logs-via-firehose.html

1. VPCフローのログ (VPC Flow Logs)

VPCフローのログは、AWS VPC内のネットワークトラフィックの詳細な情報を記録します。これにより、どのインスタンスがどのIPアドレスと通信しているか、どのポートが使用されているか、トラフィックの許可/拒否のステータスなどを把握できます。

利点: ネットワークレベルの監視が可能で、セキュリティの監査やトラブルシューティングに役立ちます。

2. CloudWatch Logs

CloudWatch Logsは、AWSのサービスやアプリケーションからのログデータを収集して保存するサービスです。ログのモニタリング、アラームの設定、ログの解析が可能です。

リアルタイムログ監視や、ログの分析に使用できます。

3. Kinesis Data Firehose

Amazon Kinesis Data Firehoseは、リアルタイムでデータを取り込み、保存、分析、処理、転送を行うサービスです。

Splunkのような外部システムへデータをストリーム形式で送信でき、リアルタイムでの監視と分析が可能です。

利点: 低遅延でデータを送信でき、スケーラブルであるため、大量のログデータの取り扱いに適しています。

4. AWS Lambda

AWS Lambdaは、サーバーレスでコードを実行するサービスです。KinesisやCloudWatch Logsと連携して、ログデータをリアルタイムで処理・変換・転送する役割を果たします。

Lambdaを使用して、例えばログデータをフィルタリングしたり、特定の処理を追加することができます。

5. リアルタイムでのデータ転送

リアルタイムでログデータを処理し、外部システム（例: Splunk）に転送するには、Kinesis Data Firehoseを活用する方法が最適です。これにより、低遅延でデータのストリーミングが可能となり、即座に監視やアラートが行えます。

6. Splunkとの連携

Splunkは、データ分析と可視化に強力なツールを提供するプラットフォームです。AWSと連携して、ログデータをリアルタイムで受け取り、トラフィックの異常検出や詳細な分析を行うことができます。

AWSのサービス（CloudWatch Logs、Kinesisなど）を使ってSplunkにデータを送信することで、監視の効率化や異常の早期検出が可能になります。

まとめ

ネットワークトラフィックの監視とログのリアルタイム処理には、VPCフローのログを使い、CloudWatch Logsでログを収集・分析し、Kinesis Data Firehoseを利用してリアルタイムでSplunkなどの外部システムにデータを送信するアーキテクチャが適しています。Lambdaを使ってデータの前処理を行うことも有効です。

実践

略

一問道場

質問 #244 トピック 1

ある企業が、オンプレミスのデータセンターとAWSのハイブリッドソリューションを開発しました。この企業はAmazon VPCとAmazon EC2インスタンスを使用しており、EC2インスタンスはアプリケーションのログをAmazon CloudWatchに送信しています。EC2インスタンスは、オンプレミスでホストされている複数のリレーショナルデータベースからデータを読み取ります。この企業は、どのEC2インスタンスがデータベースに接続されているかを、ほぼリアルタイムで監視したいと考えています。企業はすでにオンプレミスでSplunkを使用して監視ソリューションを持っています。ソリューションアーキテクトは、どのようにネットワークリングトラフィックをSplunkに送信するかを決定する必要があります。

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

A. VPCフローのログを有効にし、CloudWatchに送信します。AWS Lambda関数を作成して、CloudWatchログを定期的にAmazon S3バケットにエクスポートします。この際、事前定義されたエクスポート機能を使用します。ACCESS_KEYとSECRET_KEY AWS認証情報を生成し、その認証情報を使用してSplunkがS3バケットからログを取得できるように設定します。

B. Amazon Kinesis Data Firehose配信ストリームを作成し、宛先としてSplunkを指定します。Kinesis Data Firehoseストリームプロセッサを使用して個別のログイベントを抽出するための事前処理AWS Lambda関数を設定します。VPCフローのログを有効にし、CloudWatchに送信します。CloudWatch Logsサブスクリプションを作成して、ログイベントをKinesis Data Firehose配信ストリームに送信します。

C. 企業に対して、データベースへのリクエストをすべてログに記録し、EC2インスタンスのIPアドレスも含めるように依頼します。CloudWatchログをAmazon S3バケットにエクスポートします。Amazon Athenaを使用して、データベース名でグループ化したログをクエリします。Athenaの結果を別のS3バケットにエクスポートします。AWS Lambda関数を呼び出して、S3バケットに新しいファイルがアップロードされるたびに、Splunkに送信します。

D. CloudWatchログをAmazon Kinesisデータストリームに送信し、Amazon Kinesis Data Analytics for SQLアプリケーションを使用します。1分のスライディングウィンドウを設定してイベントを収集します。SQLクエリを作成し、異常検出テンプレートを使用してネットワークリングトラフィックの異常をほぼリアルタイムで監視します。その結果をAmazon Kinesis Data Firehose配信ストリームに送信し、宛先としてSplunkを指定します。

解説

このシナリオでは、EC2インスタンスのネットワークリングトラフィックをリアルタイムで監視し、そのデータをSplunkに送信する方法を決定する必要があります。以下、各選択肢の解説です。

A.

VPCフローのログを有効にし、CloudWatchに送信。LambdaでS3にエクスポートし、SplunkでS3から取得する設定

この方法は、CloudWatchログを定期的にS3にエクスポートし、そのデータをSplunkに取り込ませる方法です。ただし、ログをリアルタイムで取得するには時間がかかるため、リアルタイム監視には適していません。

リアルタイム性が求められる場合にはあまり効果的ではありません。

B.

Kinesis Data Firehoseを使用してSplunkに送信、CloudWatch Logsからのデータをストリーム経由で処理

この方法は、CloudWatch LogsのデータをリアルタイムでKinesis Data Firehoseに送信し、Splunkに直接送るものです。

Kinesis Data Firehoseを利用することで、リアルタイムでログを処理し、Splunkに転送できるため、要件を満たしています。

最適な選択肢です。

C.

データベースリクエストをログに記録、Athenaでクエリし、結果をS3からSplunkに送信

これはデータベースのログをCloudWatchに送信し、Athenaで解析する方法です。リアルタイム性が欠けており、データの取得や処理に時間がかかります。

リアルタイム監視には不向きです。

D.

Kinesisデータストリームを使用し、SQLクエリでトラフィック異常を監視し、結果をSplunkに送信

Kinesis Data AnalyticsでSQLクエリを使用して異常を監視する方法ですが、ログを処理するのに多少の遅延が発生する可能性があり、完全にリアルタイムではありません。

リアルタイム監視には少し効果的ですが、異常検出を行うための設定が複雑です。

結論

Bが最も適切な方法です。Kinesis Data Firehoseを使用して、CloudWatchからのログデータをリアルタイムでSplunkに送信することができ、効率的かつ確実に監視要件を満たします。

245-AWS SAP AWS 「理論・実践・一問道場」AWS Cost and Usage Reports

理論

1. AWS Organizations

AWS Organizationsを使うことで、複数のAWSアカウントを一元管理できます。これにより、アカウント間でのコストの統合、セキュリティポリシーの管理、さらには請求関連の管理が容易になります。特に、組織内の各アカウントに対して一貫性を持ったポリシーを適用することができます。

2. SCP（Service Control Policies）

SCPは、AWS Organizations内で特定のアカウントや組織単位（OU）に対して、アクセス制御ポリシーを定義する機能です。SCPを使うことで、アメリカ合衆国以外のリージョンでリソースを作成することを禁止するなど、リージョン制限を適用できます。これにより、コンプライアンス要件に従って、リソースが不適切なリージョンで作成されるのを防げます。

3. AWS Cost and Usage Reports

AWS Cost and Usage Reports（CUR）は、AWSの各サービスの使用状況とコストを詳細に追跡できる機能です。このレポートは、支出の分析やコスト管理に非常に有用です。S3バケットにレポートを保存し、さらに自動化した処理を通じて分析ツールに送ることで、財務チームは月次でのコスト追跡を行えます。

4. AWS Cost Explorer

Cost Explorerは、AWSのリソース使用状況やコストを視覚的に分析できるツールです。これにより、過去のコスト傾向を把握し、将来の支出を予測することができます。また、特定のAWSアカウントやサービスに関連するコストをフィルタリングし、詳細な分析を行えます。

結論

複数のAWSアカウントに対して、効率的にコストを管理し、リージョン制限を設けてコンプライアンスを守るためには、AWS OrganizationsとSCPを活用して、アカウントの管理とポリシー適用を行うことが鍵となります。また、AWS Cost and Usage ReportsやCost Explorerを使うことで、財務チームが必要なコスト情報を追跡・分析することができます。

実践

略

一問道場

ある企業には5つの開発チームがあり、それぞれが5つのAWSアカウントを作成してアプリケーションを開発・ホストしています。支出を追跡するために、開発チームは毎月各アカウントにログインし、AWS Billing and Cost Managementコンソールから現在のコストを記録し、その情報を会社の財務チームに提供しています。しかし、会社は厳格なコンプライアンス要件があり、リソースはアメリカ合衆国のAWSリージョンでのみ作成されるべきです。しかし、いくつかのリソースは他のリージョンに作成されています。ソリューションアーキテクトは、財務チームがすべてのアカウントの支出を追跡し、統合できるようにするソリューションを実装する必要があります。また、会社がアメリカ合衆国以外のリージョンでリソースを作成できないようにする必要があります。

どの組み合わせの手順が最も運用効率の良い方法でこの要件を満たすでしょうか？（3つ選んでください）

A. 新しいアカウントを作成して管理アカウントとして使用します。財務チーム用にAmazon S3バケットを作成します。AWS Cost and Usage Reportsを使用して月次レポートを作成し、そのデータを財務チームのS3バケットに保存します。

B. 新しいアカウントを作成して管理アカウントとして使用します。AWS Organizationsで全機能を有効にした組織を展開し、既存のすべてのアカウントをその組織に招待します。各アカウントが招待を受け入れるようにします。

C. すべての開発チームを含む組織単位（OU）を作成します。アメリカ合衆国にあるリージョンでのみリソースを作成できるようにするSCP（サービス制御ポリシー）を作成します。このSCPをOUに適用します。

D. すべての開発チームを含む組織単位（OU）を作成します。アメリカ合衆国以外のリージョンでリソースの作成を拒否するSCPを作成します。このSCPをOUに適用します。

E. 管理アカウントにIAMロールを作成し、Billing and Cost Managementコンソールを表示するための権限を含むポリシーをアタッチします。財務チームのユーザーにそのロールを引き受けることを許可します。AWS Cost ExplorerとBilling and Cost Managementコンソールを使用してコストを分析します。

F. 各AWSアカウントにIAMロールを作成し、Billing and Cost Managementコンソールを表示するための権限を含むポリシーをアタッチします。財務チームのユーザーにそのロールを引き受けることを許可します。

解説

この問題では、以下の要件を満たすための最適な手順を選択する必要があります。

要件：

支出の追跡と統合

すべてのAWSアカウントでの支出を追跡し、財務チームに提供すること。

コンプライアンス要件

アメリカ合衆国のAWSリージョンでのみリソースが作成されることを確保すること。

手順解説

A. AWS Cost and Usage Reportsを使用して月次レポートを作成し、そのデータを財務チームのS3バケットに保存する

解説：AWS Cost and Usage Reports (CUR)は、AWSのリソース使用状況とコストに関する詳細なレポートを作成できるツールです。これを使用すると、複数のアカウントに対するコストデータを集約し、保存することができます。これにより、財務チームは必要なデータを一元管理しやすくなります。

B. AWS Organizationsで全機能を有効にした組織を展開し、既存のすべてのアカウントをその組織に招待する

解説：AWS Organizationsを利用することで、複数のAWSアカウントを一元的に管理できます。この方法により、各開発チームが個別に管理する必要がなくなり、効率的なコスト管理が可能となります。組織内でポリシーを一貫して適用できるため、コストの追跡やリソース制限が容易に行えます。

C. SCPを使って、アメリカ合衆国以外のリージョンでリソースの作成を拒否する

解説：SCP（サービス制御ポリシー）を使用することで、AWS Organizations内でのリージョン制限を強制できます。これにより、アメリカ合衆国以外のリージョンでリソースが作成されるのを防ぐことができます。コンプライアンス要件を満たすために、リソースが不適切なリージョンで作成されないように制御できます。

D. SCPを使って、アメリカ合衆国にあるリージョンのみでリソースを作成できるようにする

解説：選択肢Cと似ていますが、こちらは「アメリカ合衆国にあるリージョンのみでリソースを作成できるようにする」ポリシーです。このように、特定のリージョンでのみリソースを作成できるように制限を設けることで、企業のコンプライアンスポリシーに沿った運用が可能です。

E. 管理アカウントにIAMロールを作成し、財務チームにコスト管理コンソールへのアクセスを許可する

解説：IAMロールを作成して、財務チームがコスト管理コンソールにアクセスできるようにする方法です。これにより、財務チームはAWS Cost ExplorerやBilling and Cost Management Consoleを使用して、AWSのコストを分析できます。ユーザーに必要な権限を委譲することで、コスト管理が円滑に行えます。

F. 各AWSアカウントにIAMロールを作成し、財務チームにコスト管理コンソールへのアクセスを許可する

解説：この方法もEの選択肢と似ていますが、ここでは各AWSアカウントごとにIAMロールを作成します。これにより、財務チームは各アカウントのコスト情報を直接確認できるようになります。複数のアカウントを扱う場合でも、それぞれに適切な権限を付与することで、個別にコストを追跡できます。

正解：

B: AWS Organizationsを使用して、すべてのアカウントを統合します。

D: SCPでアメリカ合衆国以外のリージョンでリソース作成を拒否します。

E: 管理アカウントにIAMロールを作成して、財務チームがコスト管理コンソールにアクセスできるようにします。

これらの選択肢を組み合わせることで、複数アカウントのコスト追跡とコンプライアンス要件の遵守を効率的に行うことができます。

246-AWS SAP AWS 「理論・実践・一問道場」信頼関係

理論

アカウントAのユーザーは、アカウントBで作成されたロールを引き受けることによって、アカウントBのリソースにアクセスできます。これは、ロールスイッチ（AssumeRole）によって実現されます。

クロスアカウントアクセスの安全な方法（AからBにアクセスする場合）

信頼関係を築いたロールを使用:

アカウントAからアカウントBにアクセスするには、まずアカウントBにIAMロールを作成し、そのロールに対してアカウントAのみがアクセスできるように設定します（信頼関係の設定）。

最小権限の原則:

アカウントBのロールには、アカウントAに提供する必要最小限の権限（例: 読み取り専用アクセス）だけを与えます。

ロールスイッチ（AssumeRole）によるアクセス:

アカウントAのユーザーは、AssumeRoleを使ってアカウントBのロールを引き受け、そこからアクセスを行います。

監査と監視:

CloudTrailを使って、アカウントAがアカウントBにアクセスした履歴を追跡・監視し、不正アクセスを防ぎます。

AWS Configで設定変更を監視し、設定ミスや不正な変更を防ぎます。

リスクと注意点

設定ミス:

アカウントBでの信頼関係設定を誤ると、アカウントA以外のアカウントが不正にアクセスできるようになってしまう可能性があります。

過剰な権限付与:

アカウントBのロールに不必要に広い権限（例えば、書き込み権限や管理者権限）を付与すると、セキュリティリスクが高まります。最小権限で設定することが重要です。

実践

略

一問道場

会社は、複数の部門用に複数のAWSアカウントを中央で作成および管理する必要があります。セキュリティチームは、独自のAWSアカウントからすべてのアカウントに対して読み取り専用アクセスを持つ必要があります。会社はAWS Organizationsを使用しており、セキュリティチーム用のアカウントも作成しています。

この要件を満たすために、ソリューションアーキテクトはどのように対応すべきでしょうか？

A. OrganizationAccountAccessRole IAMロールを使用して、各メンバーアカウントに読み取り専用アクセスを持つ新しいIAMポリシーを作成します。そして、各メンバーアカウントのIAMポリシーとセキュリティアカウントとの間に信頼関係を確立します。セキュリティチームにそのIAMポリシーを使ってアクセスするよう依頼します。

B. OrganizationAccountAccessRole IAMロールを使用して、各メンバーアカウントに読み取り専用アクセスを持つ新しいIAMロールを作成します。そして、各メンバーアカウントのIAMロールとセキュリティアカウントとの間に信頼関係を確立します。セキュリティチームにそのIAMロールを使ってアクセスするよう依頼します。

C. セキュリティチームに、AWS Security Token Service (AWS STS)を使って、セキュリティアカウントから管理アカウントのOrganizationAccountAccessRole IAMロールに対してAssumeRole APIを呼び出すよう依頼します。生成された一時的な認証情報を使用してアクセスします。

D. セキュリティチームに、AWS Security Token Service (AWS STS)を使って、セキュリティアカウントからメンバーアカウントのOrganizationAccountAccessRole IAMロールに対してAssumeRole APIを呼び出すよう依頼します。生成された一時的な認証情報を使用してアクセスします。

解説

この問題では、アカウントAのユーザーがアカウントBのリソースにアクセスできるかという質問です。

正解は、アカウントAのユーザーがアカウントBで作成されたロールを引き受けてアクセスできるということです。

クロスアカウントアクセスを実現する方法として、アカウントBでロールを作成し、そのロールに対して信頼関係ポリシーを設定します。このポリシーにより、アカウントAのユーザーがそのロールを引き受けることができます。

具体的なステップは以下の通りです：

アカウントBでIAMロールを作成し、アカウントAを信頼するように設定。

アカウントAのユーザーが、そのロールをAssumeRoleで引き受ける。

引き受けたロールに基づき、アカウントBのリソースにアクセスできる。

これにより、アカウントAのユーザーは、アカウントBのリソースにアクセスすることができます。

注意点として、最小権限の原則に従い、必要最小限の権限のみを付与することが重要です。

247-AWS SAP AWS 「理論・実践・一問道場」ハブアンドスポーク

理論

ハブアンドスポークとは、中心拠点（ハブ）に貨物や人などを集約させ、そこから各拠点（スポーク）に分散させる輸送方式やネットワーク戦略です。自転車のハブとタイヤのスポークのように見えることからこの名前が付けられました。

実践

略

一問道場

質問 #247

トピック1

大企業は、数百のAWSアカウントに分散されたVPCでワークロードを実行しています。各VPCは、複数のアベイラビリティゾーンにまたがるパブリックサブネットとプライベートサブネットで構成されています。NATゲートウェイはパブリックサブネットに展開され、プライベートサブネットからインターネットへの外向き接続を可能にしています。

ソリューションアーキテクトは、ハブアンドスポーク設計に取り組んでいます。スポークVPCのすべてのプライベートサブネットは、エグレスVPCを通じてインターネットにトラフィックをルーティングする必要があります。ソリューションアーキテクトはすでに中央のAWSアカウントでエグレスVPCにNATゲートウェイを展開しています。

これらの要件を満たすために、ソリューションアーキテクトが取るべき追加のステップはどれですか？

A. エグレスVPCとスポークVPCの間にピアリング接続を作成し、インターネットへのアクセスを許可するために必要なルーティングを設定する。

B. トランジットゲートウェイを作成し、それを既存のAWSアカウントと共有する。既存のVPCをトランジットゲートウェイに接続し、インターネットへのアクセスを許可するために必要なルーティングを設定する。

C. 各アカウントにトランジットゲートウェイを作成し、NATゲートウェイをトランジットゲートウェイに接続し、インターネットへのアクセスを許可するために必要なルーティングを設定する。

D. エグレスVPCとスポークVPCの間にAWS PrivateLink接続を作成し、インターネットへのアクセスを許可するために必要なルーティングを設定

解説

この問題の解説です：

要件：

複数のスポークVPCからインターネットに接続するため、すべてのプライベートサブネットがエグレスVPCを経由してインターネットにアクセスする必要があります。

すでにエグレスVPCにNATゲートウェイが展開されています。

各選択肢の分析：

A. ピアリング接続を作成し、インターネットアクセスのためにルーティングを設定

問題点: ピアリング接続を使う場合、VPC間のトラフィックが直接ルーティングされることになるため、大規模なVPC設計では管理が複雑になります。また、ピアリング接続は1対1の接続に限られ、VPC間の管理が手動で行われるため、スケーラビリティが低くなります。大規模な環境ではあまり適切ではありません。

B. トランジットゲートウェイを作成し、AWSアカウントで共有し、VPCを接続

正解: トランジットゲートウェイ（TGW）は複数のVPCを接続し、集中管理されたルーティングを提供します。この方法はスケーラブルで、複数のVPC間でインターネット接続を効率的に管理できます。トランジットゲートウェイは、すべてのVPCが一元的にインターネットへのトラフィックをルーティングできるため、理想的な選択肢です。

C. 各アカウントにトランジットゲートウェイを作成し、NATゲートウェイを接続

問題点: 各アカウントに個別にトランジットゲートウェイを作成するのは管理が煩雑でコストがかかります。中央集権的なトランジットゲートウェイを使う方法が最適であるため、複数アカウントにトランジットゲートウェイを設定するのは効率的でなく、過剰な設定になります。

D. AWS PrivateLinkを使用して接続

問題点: AWS PrivateLinkは、サービス間のプライベートな接続を提供するため、主にサービスアクセス向けです。インターネットアクセスのためには適していません。また、PrivateLinkを使ってインターネット接続をルーティングするのは非効率的です。

結論：

最適な方法はBの「トランジットゲートウェイを作成し、VPCを接続する方法」です。トランジットゲートウェイを利用すれば、スケーラブルかつ効率的にインターネット接続を管理できます。

248-AWS SAP AWS 「理論・実践・一問道場」レートベースルール

理論

AWS WAF とレートベースルール

AWS WAF（Web Application Firewall）:

概要: AWS WAFは、Webアプリケーションを一般的な攻撃（SQLインジェクションやクロスサイトスクリプティングなど）から保護するためのサービスです。ALB（Application Load Balancer）やCloudFrontディストリビューションに接続して、トラフィックを監視し、不正アクセスをブロックできます。

レートベースのルール:

概要: WAFのレートベースルールは、一定時間内に過剰なリクエストを送信しているIPアドレスを自動的にブロックします。これにより、ブルートフォース攻撃（多くのログイン試行）などからアプリケーションを保護できます。

利点: 毎週異なるIPアドレスからの試行をブロックするのに非常に効果的で、IPアドレスが動的に変わる状況にも対応できます。

最小限の運用負荷で攻撃から保護

AWS WAF + レートベースルールは、定期的に変化する大量の不正アクセスに対処するため、最も運用負荷が低い解決策です。IPアドレスを手動で特定してブロックする必要がないため、運用の効率が高いです。

実践

略

一問道場

問題：

ある教育会社が、世界中の大学生によって使用されるウェブアプリケーションを運営しています。このアプリケーションは、Amazon Elastic Container Service（Amazon ECS）のクラスター内で、Auto ScalingグループとApplication Load Balancer（ALB）の背後で実行されています。システム管理者は、毎週ログイン試行の失敗が急増し、アプリケーションの認証サービスが過負荷になっていることに気付きました(攻撃されています)。失敗したログイン試行は毎週、約500個の異なるIPアドレスから発生しています。ソリューションアーキテクトは、認証サービスが過負荷にならないようにする必要があります。

次の中で、最も運用効率の高い方法はどれですか？

A. AWS Firewall Managerを使用して、セキュリティグループとセキュリティグループポリシーを作成し、特定のIPアドレスからのアクセスを拒否する。

B. AWS WAFウェブACLを作成し、レートベースのルールを設定して、アクションを「ブロック」に設定する。ウェブACLをALBに接続する。

C. AWS Firewall Managerを使用して、セキュリティグループとセキュリティグループポリシーを作成し、特定のCIDR範囲からのアクセスのみを許可する。

D. AWS WAFウェブACLを作成し、IPセットマッチルールを設定して、アクションを「ブロック」に設定する。ウェブACLをALBに接続する。

解説

アプリケーションへのログイン試行の失敗が急増し、そのアクセス元は毎週異なる約500個のIPアドレスから発生しています。この状況を防ぐために、特定のIPアドレスからのアクセスを制限する方法を選ぶ必要があります。

最も運用効率が高い解決策はBです：

B. AWS WAFウェブACLを作成し、レートベースのルールを設定して、アクションを「ブロック」に設定する。ウェブACLをALBに接続する。

理由：AWS WAFのレートベースのルールは、短期間に大量のリクエストを送信するIPアドレスを特定して自動的にブロックできます。これにより、異常な数のログイン試行が認証サービスに到達するのを防げます。特に、IPアドレスが毎週変わる状況でも効果的です。

その他の選択肢は、IPアドレスの特定や許可範囲を固定した方法（A、C、D）であり、動的に変化するIPアドレスに対応するには不適切です。

249-AWS SAP AWS 「理論・実践・一問道場」AWS Transfer for SFTP

理論

AWSによるSFTPサービスの運用とファイル転送の最適化

AWSは、SaaSソリューションのファイル転送サービスの運用を簡素化するための多くの方法を提供しています。顧客が使用するSFTPエンドポイントのIPアドレスを変更せずに、AWSでファイル転送サービスを運用する場合、以下のアーキテクチャの選択肢が考えられます。

1. AWS Transfer for SFTP

概要: AWS Transfer for SFTPは、SFTPプロトコルを介してAmazon S3にファイルをアップロードするサービスです。このサービスは、顧客が既存のSFTPクライアントを使用してS3にアクセスできるようにします。

メリット: サーバー管理やインフラの設定を不要にし、SFTPエンドポイントをAWSのネイティブサービスで簡単に作成できます。IPアドレスの制限や許可も簡単に管理できます。

2. Elastic IPアドレス (EIP)

概要: Elastic IPは、静的なIPアドレスを提供し、AWSのリソースに関連付けることができます。これをSFTPのエンドポイントに関連付けることで、顧客が必要とする固定IPを提供できます。

メリット: 企業が持つIPアドレスをAWS環境に統合し、顧客がファイアウォールで許可するIPアドレスを変更せずに済むため、システム移行時の影響を最小限に抑えることができます。

3. Amazon S3 VPCエンドポイント

概要: Amazon S3 VPCエンドポイントは、VPC内からS3に直接アクセスできるエンドポイントを提供します。これにより、インターネット経由ではなく、AWSのプライベートネットワークを通じてS3にアクセスできます。

メリット: セキュリティが向上し、ファイルの転送がより安全に行われます。加えて、インターネット接続の依存をなくすことができます。

4. Network Load Balancer (NLB)とApplication Load Balancer (ALB)

概要: これらは、複数のEC2インスタンスやサービスへのトラフィックの分散を担う負荷分散サービスです。これらを使用することで、高可用性とスケーラビリティを実現し、SFTPサービスを効率的に提供できます。

メリット: EC2インスタンスのスケーリングや負荷分散を自動化し、トラフィックが増加した場合にもシステムが安定して動作します。

5. AWS WAF（Web Application Firewall）

概要: AWS WAFは、アプリケーションレベルでのセキュリティ保護を提供します。SFTPエンドポイントに対する悪意のあるリクエストをブロックすることができます。

メリット: セキュリティを強化し、不要なトラフィックや攻撃からSFTPエンドポイントを保護します。

結論

AWSでSaaSのファイル転送サービスを運用する際は、AWS Transfer for SFTPとElastic IPアドレスを活用することが最も効率的であり、既存のファイアウォール設定を変更せずに移行する方法として最適です。これにより、運用の複雑さを減らしつつ、スケーラブルで高可用性のあるインフラを構築できます。

実践

略

一問道場

ある企業がオンプレミスのSaaSソリューションを運営しており、毎日複数のファイルを取り込みます。企業は顧客に対してファイル転送を容易にするために複数の公開SFTPエンドポイントを提供しています。顧客は、SFTPエンドポイントのIPアドレスを自分のファイアウォールの許可リストに追加します。SFTPエンドポイントのIPアドレスの変更は許可されていません。この企業は、SaaSソリューションをAWSに移行し、ファイル転送サービスの運用負荷を減らしたいと考えています。

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

A. 顧客が所有するIPアドレスのブロックを企業のAWSアカウントに登録します。アドレスプールからElastic IPアドレスを作成し、AWS Transfer for SFTPエンドポイントに割り当てます。AWS Transferを使用してファイルをAmazon S3に保存します。

B. 顧客が所有するIPアドレスのブロックを含むサブネットをVPCに追加します。アドレスプールからElastic IPアドレスを作成し、Application Load Balancer（ALB）に割り当てます。EC2インスタンスでFTPサービスをホストし、Auto ScalingグループでALBの背後に配置します。ファイルはAmazon Elastic Block Store（EBS）ボリュームに保存します。

C. 顧客が所有するIPアドレスのブロックをAmazon Route 53に登録します。Route 53でエイリアスレコードを作成し、それらをNetwork Load Balancer（NLB）にポイントします。EC2インスタンスでFTPサービスをホストし、Auto ScalingグループでNLBの背後に配置します。ファイルはAmazon S3に保存します。

D. 顧客が所有するIPアドレスのブロックを企業のAWSアカウントに登録します。アドレスプールからElastic IPアドレスを作成し、それらをAmazon S3 VPCエンドポイントに割り当てます。S3バケットでSFTPサポートを有効にします。

解説

A. AWS Transfer for SFTP + Elastic IP

解説:

AWS Transfer for SFTPを使うことで、Amazon S3と連携してSFTPサーバーを構成できます。このサービスを利用すれば、顧客が使用するSFTPクライアントからのアクセスがそのままS3に反映され、インフラの管理が大幅に簡素化されます。
Elastic IPアドレスを使って、既存のSFTPエンドポイントIPアドレスを変更せずにAWSに関連付けることができます。これにより、顧客側の設定変更を避けることができ、ファイアウォールの許可リストに新しいIPアドレスを追加する手間を省けます。
最適解: 既存のSFTPエンドポイントIPアドレスをそのまま使用しつつ、AWS Transfer for SFTPで管理を簡素化するため、この選択肢が最も適しています。

250-AWS SAP AWS 「理論・実践・一問道場」EC2配置グループ

理論

1. クラスター配置グループ (Cluster Placement Group)

目的: 高スループット・低遅延のネットワーク接続が必要な場合に使用します。

特徴: インスタンスが物理的に近いサーバー上に配置され、最小のネットワークレイテンシでの通信が可能になります。これにより、EC2インスタンス間のネットワーク性能が向上します。

使用シーン: 高性能計算（HPC）、データ分析、ゲームサーバー、金融トランザクションシステムなど、パフォーマンスを重視したアプリケーションに最適です。

2. パーティション配置グループ (Partition Placement Group)

目的: フォールトトレラント性を確保しつつ、インスタンスのネットワークパフォーマンスを向上させるために使用します。

特徴: 各インスタンスが異なるパーティション（物理的に隔離されたホスト）に配置されます。これにより、パーティション内で障害が発生した場合でも、他のパーティションに配置されたインスタンスは影響を受けません。

使用シーン: 複数のインスタンスをデータベースや分散システムのようなアプリケーションで使用する場合に適していますが、クラスター配置グループほどの低遅延は提供しません。

3. スプレッド配置グループ (Spread Placement Group)

目的: インスタンスが複数の物理ホストに分散して配置され、単一の障害ドメインによる影響を受けにくくするために使用します。

特徴: 各インスタンスは異なる物理ホストに配置され、障害発生時のリスクを分散します。ただし、ネットワークレイテンシは最適化されません。

使用シーン: フォールトトレラント性を重視するが、ネットワーク性能よりも可用性が優先される場合に適しています。

4. オートスケーリングとENI

Elastic Network Interface (ENI):

複数のネットワークインターフェースを使用することで、各インスタンスのネットワーク帯域幅を拡張することができます。ただし、ENI自体はネットワークレイテンシを直接最適化するわけではなく、通信の負荷を分散する役割を果たします。

実践

略

一問道場

問題 #250

トピック 1

ある企業が新しいアプリケーションを、単一のAWSリージョン内で5台のAmazon EC2インスタンスで実行する必要があります。このアプリケーションは、アプリケーションが実行されるすべてのEC2インスタンス間で、高スループット・低遅延のネットワーク接続を必要とします。アプリケーションにフォールトトレラント性の要求はありません。

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

A. 5台の新しいEC2インスタンスをクラスター配置グループに起動します。EC2インスタンスタイプが拡張ネットワーキングをサポートしていることを確認します。

B. 5台の新しいEC2インスタンスを同じアベイラビリティゾーンのオートスケーリンググループに起動します。各EC2インスタンスに追加のElastic Network Interface（ENI）をアタッチします。

C. 5台の新しいEC2インスタンスをパーティション配置グループに起動します。EC2インスタンスタイプが拡張ネットワーキングをサポートしていることを確認します。

D. 5台の新しいEC2インスタンスをスプレッド配置グループに起動します。各EC2インスタンスに追加のElastic Network Interface（ENI）をアタッチします。

解説

この問題では、高スループットかつ低遅延のネットワーク接続を実現するために、EC2インスタンスをどのように配置すべきかが問われています。

解説：

クラスター配置グループは、インスタンスが物理的に近いサーバーに配置され、最小のネットワークレイテンシを提供します。このため、スループットとレイテンシが重要なアプリケーションに最適です。

他の配置グループ（パーティション、スプレッド）は、ネットワークパフォーマンスよりも可用性やフォールトトレラント性を優先しており、低遅延の要件には適していません。

したがって、A: クラスター配置グループを選ぶことが正解です。