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

type

status

date

slug

summary

211-AWS SAP AWS 「理論・実践・一問道場」AWS Migration Hub

理論

VMwareからAWSへの移行に関する知識

AWSへの移行は、多くの企業にとって重要なプロジェクトであり、特にVMware環境からの移行には慎重な計画が必要です。以下は、移行計画を立てる際に役立つ本質的な知識です。

1. インベントリ管理の重要性

移行計画を立てる前に、まず現在の環境を正確に把握する必要があります。インベントリ管理では、どのサーバーがどのリソースを使っているのか、どのサーバーが非アクティブであるか、どのサーバーが高い利用率を持っているかなどの情報を収集します。この情報を基に、どのサーバーを移行するか、または廃止するかを決定できます。

2. AWS Migration Hub

AWS Migration Hubは、AWSへの移行プロジェクトを一元管理するためのサービスです。このツールを使うと、複数の移行ツールから得られた情報をまとめて管理できます。また、移行の進捗状況を可視化し、スムーズな移行を支援します。

3. Migration Evaluator

Migration Evaluatorは、VMware環境を含むオンプレミス環境をAWSに移行する際に、コスト推定と最適なインスタンスの選定を支援するツールです。エージェントレスで、インベントリ収集を自動的に行い、移行対象のサーバーをリストアップすることができます。これにより、手動でサーバーの状態を確認する手間が省け、運用負荷を大幅に削減できます。

4. エージェントレス収集の利点

エージェントレス収集は、移行準備の初期段階で非常に有用です。サーバーにソフトウェアをインストールすることなく、環境全体をスキャンできるため、非常に簡単に情報を集めることができます。これにより、手間が省け、迅速な準備が可能になります。

5. 非アクティブなサーバーの除外

移行対象のサーバーを選定する際、非アクティブなサーバーを除外することは重要です。これにより、移行するリソースを最適化し、コストを削減できます。特に、オンプレミスの環境では、非アクティブなサーバーが多く存在することがあるため、これを見逃さないようにすることがポイントです。

6. 移行後の最適化

移行が完了した後も、AWS上でのリソースの最適化は続きます。AWSには自動的にスケールする機能や、利用状況に応じてインスタンスのサイズを変更する機能（例：Auto Scaling、EC2インスタンスタイプの変更）があり、これを活用することでコスト効果の高い運用ができます。

結論

AWSへの移行を効率的に行うためには、まずインベントリを正確に把握することが重要です。Migration EvaluatorやAWS Migration Hubを利用することで、移行作業を最適化し、運用負荷を最小限に抑えることができます。エージェントレスで情報を収集できることは、移行準備を迅速かつ簡単に行える大きな利点です。

実践

略

一問道場

問題 #211

トピック 1

ある企業がAWSへの移行を検討しています。この企業はVMware ESXi環境で数千台の仮想マシン（VM）を運用していますが、構成管理データベース（CMDB）がなく、VMwareの利用状況についての情報がほとんどありません。ソリューションアーキテクトは、企業が費用対効果の高い移行を計画できるように、正確なインベントリを提供する必要があります。どのソリューションが最も運用負荷を低くしてこの要件を満たしますか？

A. AWS Systems Manager Patch Managerを使用して、Migration Evaluatorを各VMに展開します。収集したデータをAmazon QuickSightでレビューします。高い利用率のサーバーを特定し、高い利用率のサーバーを移行リストから除外します。そのデータをAWS Migration Hubにインポートします。

B. VMwareポートフォリオを.csvファイルとしてエクスポートします。各サーバーのディスク利用率を確認します。高い利用率のサーバーを除外します。そのデータをAWS Application Migration Serviceにエクスポートします。残りのサーバーをAWS Server Migration Service（AWS SMS）で移行します。 C. Migration EvaluatorのエージェントレスコレクターをESXiハイパーバイザーに展開します。収集したデータをMigration Evaluatorでレビューします。非アクティブなサーバーを特定し、移行リストから非アクティブなサーバーを除外します。そのデータをAWS Migration Hubにインポートします。 D. AWS Application Migration Serviceエージェントを各VMに展開します。データが収集された後、Amazon Redshiftにインポートして分析し、Amazon QuickSightでデータを視覚化します。

解説

正解は C です。

C. Migration Evaluatorエージェントレスコレクター

この選択肢は、エージェントレスでVMware環境から正確なインベントリを収集でき、非アクティブなサーバーを特定し、それらを移行リストから除外できます。収集したデータはそのままMigration Hubにインポートでき、運用負荷が少なく、正確で効率的な移行準備が可能です。

212-AWS SAP AWS 「理論・実践・一問道場」同時接続数制限

理論

1. AWS Lambda とデータベース接続

AWS Lambdaはイベント駆動型のコンピューティングサービスであり、イベントがトリガーされると関数が実行されます。通常、Lambda関数は外部リソース（例えば、データベース）と連携する際、データベースに新しい接続を作成します。しかし、Lambdaが高頻度でトリガーされると、短期間で多数の接続を生成するため、データベースの接続数制限に達してしまうことがあります。これがデータベースのクラッシュを引き起こす原因です。

2. データベース接続の制限

ほとんどのデータベースは同時接続数に制限があり、特に従来のSQLデータベース（例えば、MySQLやSQL Server）は、一定数の同時接続を超えるとパフォーマンスが低下し、最悪の場合、クラッシュすることがあります。Lambdaが高頻度で実行され、各インスタンスが新しい接続を作成すると、この制限に達し、データベースが正常に動作しなくなります。

3. RDS Proxy の役割

RDS Proxy は、AWSが提供するサービスで、Lambda関数がRDSインスタンス（例えば、Amazon AuroraやRDS MySQL）に接続する際の管理を行います。接続の管理とは、Lambda関数の接続を効率的にプールし、接続数を最適化することを意味します。これにより、Lambda関数とデータベースの間で効率的に接続を共有し、リソースを無駄なく使うことができます。

ただし、RDS Proxyが役立つのは、Lambdaの並行実行数がデータベースが処理できる範囲内である場合です。Lambdaの並行実行数があまりにも高すぎると、RDS Proxyでも接続数の制限を解消できないため、データベースがクラッシュする可能性があります。

4. SQS（Simple Queue Service）による管理

Amazon SQS はメッセージキューサービスで、Lambda関数にトリガーするイベントをキューに格納し、順番に処理させることができます。これにより、Lambda関数の並行実行数を制御することができます。特に、データベースが同時接続数に制限がある場合、Lambda関数を順番に処理させることで、データベースに過剰な負担をかけることなく安定した運用が可能になります。

5. 接続数の制限を超えるときの対策

接続のプール管理（RDS Proxyなど）: Lambdaの並行実行数が少ない場合や、データベースが接続数をある程度処理できる場合には有効です。

キューによる制御（SQSなど）: Lambdaの並行実行数が多い場合や、データベース接続数に強い制限がある場合には、SQSなどで並行実行数を調整して処理するのが最適です。

まとめ

AWS Lambdaを使用する際のデータベース接続の管理は重要なポイントです。接続数の過多を防ぐために、RDS Proxyを使うか、SQSで並行実行数を制御するかは、システムの設計やデータベースの能力に依存します。Lambda関数が高頻度でトリガーされる場合、SQSを使って並行実行数を調整する方法が特に有効です。

実践

略

一問道場

質問 #212

トピック 1

ある企業は、AWS Lambda関数でマイクロサービスを実行しています。このマイクロサービスは、同時接続数が限られているオンプレミスのSQLデータベースにデータを書き込みます。Lambda関数の呼び出し回数が多すぎると、データベースがクラッシュしてアプリケーションがダウンします。この企業は、AWS Direct Connect接続を使用して、企業のVPCとオンプレミスのデータセンターを接続しています。企業はデータベースのクラッシュを防ぎたいと考えています。

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

A. データをAmazon Simple Queue Service (Amazon SQS)キューに書き込みます。Lambda関数がキューからデータを読み取り、既存のデータベースに書き込むように構成します。データベースがサポートする接続数より少ないLambda関数の予約済み同時実行数を設定します。

B. 新しいAmazon Aurora Serverless DBクラスターを作成します。AWS DataSyncを使用して、データを既存のデータベースからAurora Serverlessに移行します。Lambda関数を書き込む先をAuroraに再構成します。

C. Amazon RDS Proxy DBインスタンスを作成します。RDS Proxy DBインスタンスをAmazon RDS DBインスタンスにアタッチします。Lambda関数を書き込む先をRDS Proxy DBインスタンスに再構成します。

D. データをAmazon Simple Notification Service (Amazon SNS)トピックに書き込みます。Lambda関数が新しいメッセージをトピックから受信したときに既存のデータベースに書き込むように呼び出します。Lambda関数の予約済み同時実行数をデータベースがサポートする接続数と同じに設定します。

解説

問題の背景

AWS Lambda：イベント駆動型で自動的にスケーリングするため、トリガーが発生するたびにLambdaが実行されます。しかし、この並行実行数が増えると、データベースの接続数制限を超えてしまい、データベースがクラッシュする可能性があります。

SQLデータベースの制限：SQLデータベース（オンプレミスやAWS RDSなど）は、同時接続数に制限があり、これを超えると性能が低下したり、クラッシュすることがあります。

各選択肢の分析

A. SQSを使用してデータを書き込む

選択肢Aは、SQS（Simple Queue Service）を使用して、データの書き込みを順番に処理させる方法です。

ポイント: Lambda関数を直接データベースに書き込むのではなく、まずSQSキューにデータを保存し、Lambda関数が順番にそのデータを処理します。
Lambdaの並行実行数を制限することで、データベースへの接続数を管理できます。
適切な選択肢です。Lambda関数を順番に処理することでデータベースへの負担を軽減できます。

B. Aurora Serverlessの導入

選択肢Bは、データベースをAurora Serverlessに移行し、Lambda関数をその新しいデータベースに接続させる方法です。

ポイント: Aurora Serverlessはスケーラブルなデータベースですが、問題の本質である「Lambda関数による接続過多」に直接対応しているわけではありません。
適切ではない。データベース自体がスケーリングするものの、Lambda関数がトリガーされる頻度によっては接続数の問題が依然として発生する可能性があります。

C. RDS Proxyを使用

選択肢Cは、RDS Proxyを使ってLambda関数の接続を管理する方法です。

ポイント: RDS ProxyはLambda関数とデータベース間の接続をプールし、効率的に管理します。これにより、接続数を最適化できます。
適切な選択肢です。ただし、Lambda関数が過剰に並行実行される場合、この方法でも限界がある可能性があります。

D. SNSを使用してデータを処理

選択肢Dは、SNS（Simple Notification Service）を使ってトリガーされたLambda関数にメッセージを送信し、処理する方法です。

ポイント: SNSはメッセージングサービスで、通知を使用してLambdaをトリガーします。SNSを使っても、Lambda関数が大量に並行実行される問題には対応できません。
適切ではない。SNSはメッセージ通知の機能であり、Lambdaの並行実行数を制限する仕組みがないため、データベースの負荷は解決できません。

正解

選択肢Aは、SQSを使ってLambda関数の並行実行を制御する方法が最適です。この方法では、Lambda関数が順番に処理を行うため、データベースへの過剰な接続数を防ぐことができます。また、SQSはLambdaとの組み合わせでスムーズに使えるサービスで、データベースの負荷を軽減できます。

まとめ:

選択肢A（SQSを使う）は、Lambdaの並行実行数を制御して、データベースへの接続過多を防ぐ最適な方法です。

他の選択肢（B、C、D）は、接続数制限の問題に対しては十分な解決策を提供しません。

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

理論

1. Grafanaとは

Grafanaは、主に監視と可視化のために使用されるオープンソースのツールです。システムやアプリケーションから収集した時系列データを視覚化し、ダッシュボードとして表示します。たとえば、AWSのリソースのパフォーマンスメトリクスやアプリケーションの健康状態を監視するために利用されます。

主な機能:

時系列データの可視化
複数のデータソース（CloudWatch、Prometheus、MySQL、PostgreSQLなど）の統合
ダッシュボードのカスタマイズ機能

課題:

自分で管理する場合、スケーリングや高可用性の確保が難しい
メンテナンスが煩雑になりやすい

2. AWS Managed Grafana

AWS Managed Grafanaは、AWSが提供するフルマネージドサービスで、Grafanaのすべての機能をクラウド環境で提供します。このサービスを利用することで、AWSインフラに統合された高可用性のGrafana環境を、簡単に構築・管理できます。

メリット:

高可用性: AWSによって自動的にインフラの冗長性とスケーラビリティが管理されるため、ダウンタイムのリスクを減らせます。
運用負荷の軽減: インフラの管理やスケーリングをAWSが処理するため、手動で設定や監視を行う必要がありません。
AWSサービスとの統合: CloudWatch、X-Ray、Amazon Managed Prometheusなど、AWSの他のサービスとシームレスに統合できます。

適用シナリオ: 高可用性が求められる環境で、運用の手間を最小限に抑えたい場合に最適です。

3. 高可用性（HA）

高可用性は、システムが予期しない障害や停止に耐え、サービスを途切れさせずに継続的に稼働し続ける能力を指します。特に監視ダッシュボードでは、リアルタイムでのデータ表示が求められるため、10分以内のダウンタイムという要件に応えるためには、サービスの冗長性が必要です。

AWS Managed Grafanaを使用すると、複数のAZ（Availability Zones）にまたがる冗長なインフラが提供されるため、高可用性が確保されます。

4. 運用オーバーヘッドの最小化

運用オーバーヘッドとは、システムを運用・管理するためにかかる労力やコストのことです。マネージドサービスを利用することで、手動での管理作業が不要になり、運用負荷を軽減できます。AWS Managed Grafanaを使うことで、インフラの管理、パッチ適用、スケーリング、バックアップなどのタスクをAWSが自動的に行います。

自動化: AWSがインフラの冗長性やスケーリングを管理するため、運用管理者はより戦略的な業務に集中できます。

実践

略

一問道場

質問 #213

トピック 1

ある企業は、AWSワークロードの健康状態を監視するために単一のAmazon EC2インスタンスで動作するGrafanaデータ可視化ソリューションを使用しています。この企業はダッシュボードの作成に時間と労力をかけており、そのダッシュボードを保存したいと考えています。ダッシュボードは高可用性が必要で、ダウンタイムは10分を超えてはいけません。また、企業は運用メンテナンスを最小限に抑えたいと考えています。

どのソリューションが最小限の運用オーバーヘッドでこれらの要件を満たしますか？

A. Amazon CloudWatchダッシュボードに移行します。既存のGrafanaダッシュボードに合わせてダッシュボードを再作成します。可能な限り自動ダッシュボードを使用します。

B. Amazon Managed Grafanaワークスペースを作成します。新しいAmazon CloudWatchデータソースを設定します。既存のGrafanaインスタンスからダッシュボードをエクスポートし、新しいワークスペースにインポートします。

C. Grafanaが事前にインストールされたAMIを作成します。既存のダッシュボードをAmazon Elastic File System (Amazon EFS)に保存します。新しいAMIを使用するAuto Scalingグループを作成し、Auto Scalingグループの最小、希望、最大インスタンス数を1に設定します。少なくとも2つのアベイラビリティゾーンを使用するアプリケーションロードバランサーを作成します。

D. AWS Backupを使用して、Grafanaが実行されているEC2インスタンスを1時間ごとにバックアップします。必要に応じて、最新のスナップショットからEC2インスタンスを別のアベイラビリティゾーンに復元します。

解説

A: CloudWatchダッシュボードへの移行

メリット: AWS環境に最適化されており、AWSリソースの監視には非常に便利です。
デメリット: Grafanaの柔軟性を活かすことができず、既存のダッシュボードの再作成が必要です。

B: AWS Managed Grafanaへの移行

メリット: 最適な選択肢です。既存のGrafanaダッシュボードを簡単に移行でき、AWSの他のサービス（CloudWatchなど）と統合できます。
デメリット: なし。運用負荷が最小限に抑えられるため、非常に効果的です。

C: EC2インスタンスにGrafanaをインストールしてスケーリング

メリット: 自分で管理する柔軟性があります。
デメリット: スケーリングや高可用性の管理が手動で行う必要があり、運用負荷が高くなります。

D: EC2インスタンスのバックアップ

メリット: バックアップを定期的に取っておくことで、データの保護は可能です。
デメリット: 復元に時間がかかり、10分以内のダウンタイムという要件には対応できません。

結論

この問題に最適な解決策は、AWS Managed Grafana（オプションB）です。これにより、ダッシュボードを迅速に移行し、高可用性を確保しつつ、運用負荷を最小限に抑えることができます。AWSのインフラと統合されており、冗長性とスケーラビリティを自動的に管理してくれるため、安定した運用が可能です。

214-AWS SAP AWS 「理論・実践・一問道場」AWS Schema Conversion Tool (SCT)

理論

この問題に関連した本質的な知識は、データベース移行およびパスワード管理に関する内容です。AWSにおけるデータベース移行やパスワードローテーションのベストプラクティスを理解することで、効率的かつ安全なシステム運用が可能になります。以下ではそれぞれのポイントについて詳しく解説します。

1. データベースの移行

AWSでは、さまざまな方法でデータベースをクラウドに移行することができます。特に、Amazon RDSやAmazon EC2を使った移行が一般的です。

Amazon RDS for Oracle

Amazon RDSは、マネージド型のリレーショナルデータベースサービスであり、データベースのセットアップ、運用管理（バックアップ、パッチ適用、スケーリングなど）を簡素化します。特にAmazon RDS for Oracleは、Oracleデータベースをクラウド環境で簡単に実行できるように提供されており、オンプレミスのOracleデータベースからの移行もサポートしています。

データベース移行ツール

*AWS Schema Conversion Tool (SCT)**は、オンプレミスのデータベースをAWSに移行する際に使用されるツールで、異なるデータベース間でスキーマの変換を自動化します。たとえば、OracleからAmazon DynamoDBやAmazon Neptuneなど、異なるデータベースタイプへの移行を容易にします。

2. パスワード管理とローテーション

セキュリティ要件に従って、データベースのパスワードローテーションは重要な課題です。AWSでは、パスワードや認証情報を安全に管理し、定期的なローテーションを自動化するためのサービスが提供されています。

AWS Secrets Manager

AWS Secrets Managerは、機密情報（データベースの認証情報、APIキーなど）を安全に管理するサービスです。Secrets Managerは、自動パスワードローテーションの機能を提供しており、ユーザーが設定したスケジュールに基づいてパスワードを自動的に変更し、更新された認証情報をアプリケーションに提供します。この機能は、セキュリティの維持に重要な役割を果たし、オペレーショナルオーバーヘッドを削減します。

AWS Systems Manager Parameter Store

AWS Systems Manager Parameter Storeは、パスワードや設定情報をセキュアに保存するためのサービスですが、パスワードローテーションの自動化に関しては、AWS Lambda関数を組み合わせる必要があります。Lambdaを使用してパラメータの更新をトリガーすることは可能ですが、Secrets Managerほど簡単には自動化できません。

3. 自動化と運用負荷の削減

問題の要件で最も重要なのは、運用負荷の削減と、自動化です。以下はそれを実現する方法です。

AWS Secrets Managerを使用して、パスワードローテーションを自動化する方法は、運用負荷を最小化する最も効率的な方法です。パスワードの更新と管理が自動で行われ、セキュリティ要件も満たすことができます。

AWS Lambdaを使用して、パスワードローテーションの処理をトリガーすることも可能ですが、AWS Secrets Managerのほうがシンプルで直感的に設定できるため、運用負荷が低く、推奨されます。

4. パスワードローテーションとセキュリティ

定期的なパスワードローテーションは、セキュリティの強化に役立ちます。パスワードを定期的に変更することで、万が一パスワードが漏洩した場合でもリスクを最小限に抑えることができます。

まとめ

この問題では、最も運用負荷が少ない方法として、Amazon RDS for Oracleに移行し、AWS Secrets Managerで自動パスワードローテーションを設定するソリューション（選択肢B）が最適です。このアプローチは、移行の容易さ、安全性、運用の簡便さを兼ね備えており、セキュリティ要件を満たしつつ、手間のかからない運用を実現します。

実践

略

一問道場

問題 #214

トピック:

ある企業は、顧客の取引データベースをオンプレミスからAWSに移行する必要があります。このデータベースは、Linuxサーバー上で実行されているOracle DBインスタンスに格納されています。新しいセキュリティ要件により、企業はデータベースのパスワードを毎年ローテーションしなければなりません。

最も運用負荷が少ない方法でこの要件を満たすソリューションはどれですか？

選択肢:

A. AWSスキーマ変換ツール（AWS SCT）を使用してデータベースをAmazon DynamoDBに変換します。パスワードをAWS Systems Managerパラメーターストアに保存します。Amazon CloudWatchアラームを作成し、毎年のパスワードローテーションのためにAWS Lambda関数を呼び出します。

B. データベースをAmazon RDS for Oracleに移行します。パスワードをAWS Secrets Managerに保存します。自動ローテーションをオンにし、毎年のローテーションスケジュールを設定します。

C. データベースをAmazon EC2インスタンスに移行します。AWS Systems Managerパラメーターストアを使用して接続文字列を保持し、AWS Lambda関数を使用して毎年スケジュールでローテーションします。

D. データベースをAWSスキーマ変換ツール（AWS SCT）を使用してAmazon Neptuneに移行します。Amazon CloudWatchアラームを作成し、毎年のパスワードローテーションのためにAWS Lambda関数を呼び出します。

解説

この問題では、顧客の取引データベースをオンプレミスからAWSに移行し、毎年のパスワードローテーションというセキュリティ要件に対応する方法を求めています。選択肢の中で最も運用負荷が少ないものを選ぶ必要があります。

各選択肢の解説：

選択肢A:

*AWS Schema Conversion Tool (SCT)**を使用して、Amazon DynamoDBにデータを移行する方法です。

ただし、DynamoDBはNoSQLデータベースであり、Oracle DBのリレーショナルデータベースとは大きく異なります。このような移行にはかなりの手間がかかり、既存のデータベースの要件に適していません。

また、パスワードローテーションについては、AWS Systems Manager Parameter Storeで管理し、Lambdaを使ってローテーションする必要があり、少し手間が増えます。

運用負荷が高く、効率的ではないため、適切ではありません。

選択肢B (正解):

Amazon RDS for Oracleにデータベースを移行し、AWS Secrets Managerでパスワードを管理し、自動ローテーションを設定する方法です。

RDS for Oracleは、管理が簡単なマネージド型のリレーショナルデータベースサービスで、Oracle DBに最適化されており、移行後の管理も楽になります。

Secrets Managerを使用することで、パスワードの自動ローテーションが実現でき、運用負荷が非常に低くなります。これにより、セキュリティ要件も満たし、手間がかからず自動的にローテーションされます。

最も運用負荷が少ないため、この選択肢が最適です。

選択肢C:

EC2インスタンス上にデータベースを移行し、AWS Systems Manager Parameter Storeを使ってパスワードを管理する方法です。

EC2インスタンスでデータベースを管理する場合、手動でバックアップやパッチ適用などの運用管理が必要になり、負担が増えます。また、パスワードローテーションのためにLambdaを設定する必要もあり、さらに運用負荷が増えます。

運用が煩雑になり、RDSの方が簡便なので、最適ではありません。

選択肢D:

Amazon Neptuneはグラフデータベースサービスで、Oracle DBとは全く異なるデータベースタイプです。データベース移行において、OracleからNeptuneへの移行は非常に不適切です。

パスワードローテーションに関しても、CloudWatchアラームとLambdaを使ってローテーションを管理する必要がありますが、不必要な複雑さが加わり、運用負荷が高くなります。

選択肢としては不適切です。

結論:

選択肢Bが最も効率的で運用負荷が低いため、正解です。AWSのRDS for Oracleに移行し、Secrets Managerでパスワードローテーションを自動化することで、セキュリティ要件を満たしつつ、運用を簡素化できます。

215-AWS SAP AWS 「理論・実践・一問道場」共有サービスアカウントと中央管理アカウント

理論

以下が共有サービスアカウントと中央管理アカウントの簡潔な比較です。

特徴	共有サービスアカウント	中央管理アカウント
目的	リソースを複数のアカウントで共有	複数VPCやネットワークを中央で管理
主な用途	VPCやサブネットの共有	Transit GatewayなどでVPC接続を管理
管理者	サービスリソースの管理者	ネットワーク全体の管理者
利用ケース	複数アカウント間でリソースを共有したい場合	複数のVPCを一元的に接続したい場合
コスト効率	リソース共有でコスト効率が良い	管理が集中するためコストが高くなることもあり

使う場面：

共有サービスアカウント: 複数のアカウントで共通のリソース（VPC、サブネット）を使う場合。

中央管理アカウント: 複数のVPCやネットワーク接続を一元的に管理したい場合。

実践

略

一問道場

問題 #215

トピック 1

ソリューションアーキテクトは、複数のチームで構成される会社のためにAWSアカウント構造を設計しています。すべてのチームは同じAWSリージョンで作業します。会社は、オンプレミスネットワークに接続されたVPCを必要としています。会社は、オンプレミスネットワークとの間で合計50 Mbps未満のトラフィックを予測しています。

これらの要件を最もコスト効果高く満たすための手順の組み合わせはどれですか？（2つ選択してください。）

A. AWS CloudFormationテンプレートを作成して、VPCおよび必要なサブネットをプロビジョニングします。テンプレートを各AWSアカウントにデプロイします。

B. AWS CloudFormationテンプレートを作成して、VPCおよび必要なサブネットをプロビジョニングします。テンプレートを共有サービスアカウントにデプロイします。AWSリソースアクセスマネージャーを使用してサブネットを共有します。

C. AWS Transit GatewayとAWS Site-to-Site VPNを使用してオンプレミスネットワークに接続します。AWSリソースアクセスマネージャーを使用してトランジットゲートウェイを共有します。

D. AWS Site-to-Site VPNを使用してオンプレミスネットワークに接続します。

E. AWS Direct Connectを使用してオンプレミスネットワークに接続します。

解説

この問題の正解は、次の2つの選択肢です：

理由：

選択肢B:

VPCの作成とサブネットの展開をAWS CloudFormationで自動化し、共有サービスアカウントを使って管理する方法は効率的で、複数のチームやアカウントに対してスケーラブルに展開できます。

*AWS Resource Access Manager (RAM)**を使ってサブネットを他のアカウントに共有することで、リソースの管理を簡素化し、運用の負荷を減らすことができます。

選択肢D:

AWS Site-to-Site VPNは、50 Mbps未満のトラフィック量に対応するための低コストかつシンプルな接続手段です。VPN接続は、オンプレミスネットワークとの接続において非常にコスト効果が高い選択肢です。

他の選択肢について：

選択肢A: これはCloudFormationを使ってVPCを作成する方法ですが、サブネットの共有が行われていないため、他のアカウント間でのリソース共有が必要な場合には不十分です。

選択肢C: AWS Transit Gatewayは、より大規模な接続や複雑なネットワーク構成に向いており、50 Mbpsの低トラフィック量にはオーバースペックです。

選択肢E: AWS Direct Connectは非常に高帯域な接続方法で、低トラフィック環境にはコストが高すぎる選択肢です。

これらの理由から、選択肢BとDが最もコスト効果が高く、要求に適しています。

216-AWS SAP AWS 「理論・実践・一問道場」AWS Network Firewall

理論

大量AWSアウトバウンドトラフィック管理

1. 大量アウトバウンドトラフィックの基本構成

AWSでは、インターネットへのアウトバウンドトラフィックを管理するには以下が必要です：

インターネットゲートウェイ（IGW）: VPC内から直接インターネットへ接続。

NATゲートウェイ: プライベートサブネットのリソースがインターネットにアクセスする際に使用。

2. 中央集約型管理の利点

一元管理: AWS OrganizationsやTransit Gatewayを使用すると、複数のアカウントを一箇所で管理可能。

セキュリティ強化: 全トラフィックを特定のポイントで制御できるため、統一したポリシーを適用可能。

3. AWS Network Firewallの特徴

ルールベースのフィルタリング: トラフィックに対してIP、ポート、プロトコルを基にフィルタリング。

スケーラビリティ: 高いスループットに対応（25Gbps以上可能）。

統合: Transit GatewayやVPCに簡単に統合できる。

4. 適切な構成の選択基準

規模: アカウントやリージョンの数。中央集約型が適するケースが多い。

パフォーマンス: スループット要件（本問では25Gbps/AZ）。

運用効率: 管理が複雑にならない構成が理想。

5. 推奨アプローチ

AWS Network Firewallを使用し、Transit Gatewayでルーティングを管理する構成が以下の点で最適：

スケーラビリティ: 大規模組織にも対応可能。

運用負荷の低減: ルール管理を一箇所で実施できる。

セキュリティ統制: 全アカウントに統一ポリシーを適用可能。

実践

略

一問道場

質問 #216

トピック 1

大企業のソリューションアーキテクトは、AWS Organizations内のすべてのAWSアカウントからインターネットへのアウトバウンドトラフィックのネットワークセキュリティを設定する必要があります。

組織には100以上のAWSアカウントがあり、アカウント間の通信は中央集約型AWS Transit Gatewayを介しています。

各アカウントには、インターネットへのアウトバウンドトラフィック用にインターネットゲートウェイとNATゲートウェイが設定されています。

リソースは単一のAWSリージョン内にのみデプロイされます。

会社は、全AWSアカウントのインターネットへのアウトバウンドトラフィックに対して、中央集約型のルールベースのフィルタリングを追加する必要があります。

アウトバウンドトラフィックのピーク負荷は、各アベイラビリティゾーン（AZ）で25Gbpsを超えません。

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

選択肢

A. 新しいVPCをアウトバウンドトラフィック用に作成し、既存のTransit Gatewayを新しいVPCに接続します。

新しいNATゲートウェイを設定します。

オートスケーリンググループを作成し、全アベイラビリティゾーンでルールベースのフィルタリングを行うオープンソースのインターネットプロキシを実行するAmazon EC2インスタンスをデプロイします。

すべてのデフォルトルートをプロキシのオートスケーリンググループにポイントするよう変更します。

B. 新しいVPCをアウトバウンドトラフィック用に作成し、既存のTransit Gatewayを新しいVPCに接続します。

新しいNATゲートウェイを設定します。

AWS Network Firewallをルールベースのフィルタリング用に使用します。

各アベイラビリティゾーンでNetwork Firewallのエンドポイントを作成します。

すべてのデフォルトルートをNetwork Firewallエンドポイントにポイントするよう変更します。

C. 各AWSアカウントでルールベースのフィルタリング用にAWS Network Firewallを作成します。

すべてのデフォルトルートを各アカウント内のNetwork Firewallにポイントするよう変更します。

D. 各AWSアカウントでネットワーク最適化されたAmazon EC2インスタンスを実行するオートスケーリンググループを作成し、オープンソースのインターネットプロキシでルールベースのフィルタリングを実行します。

すべてのデフォルトルートをプロキシのオートスケーリンググループにポイントするよう変更します。

正解

この問題は、AWS Organizationsに属する複数のアカウント間で共有されるアウトバウンドトラフィックに対する中央集約型のルールベースのフィルタリングを、効率的かつスケーラブルに実現する方法を問うています。

解説

要件のポイント:

中央管理でアウトバウンドトラフィックをフィルタリングする。

*高いスループット（25Gbps/AZ）**に対応する。

単一のAWSリージョンでの設定。

各選択肢の要約:

A: オープンソースプロキシを使用する案。設定が複雑で、スケーラビリティやメンテナンスの課題がある。
B: AWS Network Firewallを中央で利用し、スケーラブルかつ管理が容易な構成。
C: 各アカウントに個別のFirewallを作成。管理が煩雑になるため非効率。
D: 各アカウントでプロキシを使用。スケーラビリティと運用負荷が課題。

正解: B

AWS Network Firewallを使用することで、中央でルールを管理しつつ、高スループットに対応可能。

Transit GatewayとVPCを接続し、Network Firewallを通してトラフィックをルーティングすることで効率的かつ拡張性のある解決策を提供します。

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

理論

Amazon Inspectorとは

Amazon Inspectorとは、Amazon EC2インスタンスやコンテナなどのワークロードを自動的に検出し、ソフトウェアの脆弱性や意図しないネットワークへの露出がないか継続的にスキャンする脆弱性管理サービスです。

Amazon Inspectorは管理コンソールから簡単に有効化でき、組織にとって重大な脅威となる脆弱性を自動的に検知・可視化して、一元的な管理を実現します。従来はEC2のみ対象でしたが、2021年に新たなバージョンのAmazon Inspector v2が発表され、現在ではAmazon ECR（Elastic Container Registry）やAWS Lambda関数も対象になっています。

Amazon Inspectorが検出するもの（実例）

Amazon Inspectorは、AWS環境のセキュリティ脆弱性やコンプライアンス違反を検出する自動スキャンツールです。以下はその検出内容の実際例です。

1. ソフトウェアの脆弱性

検出例: インストール済みのソフトウェア（例: Apache, Nginx, Python）の古いバージョン。

脅威: 未更新のソフトウェアに存在する既知の脆弱性（例: CVE-2023-XXXXX）により、攻撃者に侵入されるリスク。

2. ネットワークの設定ミス

検出例: セキュリティグループが全トラフィック（0.0.0.0/0）を許可している。

脅威: パブリックアクセスが可能になり、意図しない外部からの攻撃を招く可能性。

3. IAMポリシーの過剰な権限

検出例: IAMユーザーが「AdministratorAccess」の権限を持っている。

脅威: 不要な権限が付与されている場合、内部の悪意ある行為や外部からの侵害に対して脆弱。

4. セキュリティパッチの未適用

検出例: Amazon EC2インスタンスにインストールされているOS（例: Amazon Linux, Ubuntu）のパッチが古い。

脅威: 未パッチのシステムは、攻撃者に既知の脆弱性を突かれるリスクが高い。

5. アプリケーション構成の問題

検出例: Dockerイメージに不要な秘密情報（例: ハードコードされた認証情報）が含まれている。

脅威: 攻撃者が機密情報を利用し、システムへの侵入やデータの盗難を行う可能性。

簡潔なまとめ

Amazon Inspectorは、ソフトウェアの脆弱性、設定ミス、権限管理の問題などを検出することで、AWSリソースのセキュリティを強化します。具体的には、古いソフトウェア、セキュリティグループの設定ミス、未適用パッチなどを見つけ、修正案を提供します。

AWS MarketplaceのAWSマネージドルールとは

AWS MarketplaceのAWSマネージドルールは、AWS WAFで利用できるサードパーティ製のセキュリティルールセットです。これを使うと、SQLインジェクションやXSS攻撃、ボットアクセスなどの脅威を簡単にブロックできます。

特徴

自動更新: 新しい脅威に対応したルールが自動で更新。

簡単導入: 簡単に適用でき、すぐに利用可能。

カスタマイズ可能: 環境に応じてルールを調整できる。

主な利用例

攻撃防御: SQLインジェクションやXSSのブロック。

ボット対策: 不正なボットアクセスの制御。

メリット

手間が減る: 専門知識がなくても簡単。

強固なセキュリティ: 最新の攻撃にも対応。

AWS Marketplaceから選び、WAFに適用するだけで、簡単にセキュリティ対策を強化できます！

ポイント

1. 一般的な脆弱性攻撃のフィルタリング

AWS WAF（Web Application Firewall）は、リクエストをフィルタリングして攻撃（例：SQLインジェクションやクロスサイトスクリプティング）を防ぐ機能を提供します。Web ACLを構成することで、ALB（Application Load Balancer）に適用可能です。

2. 拒否されたリクエストの監査

拒否されたリクエストのログを収集し、外部監査アプリケーションに送信するには、ログ記録とデータ転送が必要です。このため、以下の技術が活用されます：

CloudWatch Logs: ログデータの収集と保存。

Kinesis Data Firehose: ログを外部アプリケーションへリアルタイムで転送。

3. 高可用性の構築

高可用性を実現するためには、以下の設計が重要です：

Multi-AZ構成: 複数のアベイラビリティゾーンにリソースを分散。

Auto Scaling: トラフィックに応じた動的なリソース増減。

Kinesis Data Firehoseは、リアルタイムでデータを収集して、指定した保存先に自動で転送するサービスです。

主な用途

データ転送: アプリケーションやログからデータをリアルタイムでAmazon S3やRedshift、Elasticsearchなどに送信。

ログ管理: WAFやALBのログを集めて監査アプリやS3に転送。

リアルタイム分析: データを転送しながら処理して、分析基盤に活用。

簡単に言うと、データをリアルタイムで転送し、後続の処理や保存先に自動的に送る役割を果たします。

実践

略

一問道場

質問 #217

トピック 1

ある会社が、単一のアベイラビリティゾーンでAmazon EC2インスタンスにトラフィックを分散させるため、ロードバランサーを使用しています。会社はセキュリティに懸念があり、ソリューションアーキテクトに以下の要件を満たすようソリューションを再設計してほしいと考えています。

要件

着信リクエストは、一般的な脆弱性攻撃をフィルタリングする必要がある。

拒否されたリクエストは、サードパーティの監査アプリケーションに送信する必要がある。

すべてのリソースは高可用性であるべき。

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

アプリケーションのAMIを使用してMulti-AZのAuto Scalingグループを構成。

アプリケーションロードバランサー(ALB)を作成し、Auto Scalingグループをターゲットとして設定。

Amazon InspectorでALBとEC2インスタンスへのトラフィックをモニタリング。

AWS WAFでWeb ACLを作成し、ALBに適用。

Lambda関数を使用して、Amazon Inspectorのレポートをサードパーティの監査アプリケーションに送信。

アプリケーションロードバランサー(ALB)を構成し、EC2インスタンスをターゲットに追加。

AWS WAFでWeb ACLを作成し、ALBに適用。

Amazon CloudWatch Logsでログ記録を有効化。

Lambda関数を使用して、CloudWatch Logsのデータをサードパーティの監査アプリケーションに送信。

アプリケーションロードバランサー(ALB)を構成し、ターゲットグループにEC2インスタンスを追加。

Amazon Kinesis Data Firehoseを構成し、サードパーティ監査アプリケーションを宛先として設定。

AWS WAFでWeb ACLを作成し、ALBに適用。

Kinesis Data Firehoseをログの宛先としてログ記録を有効化。

AWS MarketplaceのAWSマネージドルールを購読し、WAFで使用。

アプリケーションのAMIを使用してMulti-AZのAuto Scalingグループを構成。

アプリケーションロードバランサー(ALB)を作成し、Auto Scalingグループをターゲットとして設定。

Amazon Kinesis Data Firehoseを構成し、サードパーティ監査アプリケーションを宛先として設定。

AWS WAFでWeb ACLを作成し、ALBに適用。

Kinesis Data Firehoseをログの宛先としてログ記録を有効化。

AWS MarketplaceのAWSマネージドルールを購読し、WAFで使用。

解説

選択肢の比較

A: Multi-AZ Auto Scaling + Amazon Inspector

Inspectorは脆弱性検査ツールであり、着信リクエストのリアルタイムフィルタリングには不向き。

適切なログ転送の仕組みが不足。→ 不適切

B: ALB + WAF + CloudWatch Logs + Lambda

WAFで攻撃を防ぎ、CloudWatch Logsで拒否されたリクエストを収集。

Lambdaで監査アプリケーションにデータを送信。

高可用性の説明が不足。→ 部分的に適切

C: ALB + WAF + Kinesis Data Firehose + AWS Managed Rules

WAFでフィルタリングし、Kinesisでログをリアルタイム転送。

AWS MarketplaceのManaged Rulesにより、包括的なセキュリティが実現。

高可用性も確保可能。→ 最適な選択肢

D: Multi-AZ Auto Scaling + WAF + Kinesis Data Firehose

Cに似ていますが、Auto Scalingを利用して高可用性がより強調されています。

AWS MarketplaceのManaged Rulesにより、セキュリティも万全。→ 非常に適切

結論

Dが最適：高可用性とセキュリティ、ログ転送のすべてをバランスよく満たしています。

218-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント+プライベートGateway

理論

1. API Gatewayのエンドポイントタイプ

API Gatewayには異なるエンドポイントタイプがありますが、セキュリティ要件に応じて選択できます。

インターネットエクスポーズ型 (Regional & Edge-Optimized): パブリックインターネットからアクセス可能。

プライベートエンドポイント: API GatewayをVPC内に制限し、インターネットからのアクセスを防ぎます。VPCエンドポイントを使うことで、セキュアな通信が可能となります。

2. VPCエンドポイント

VPCエンドポイントは、AWSサービスとVPC内のリソース間でトラフィックをインターネットを通さずに転送するためのものです。

インターフェースVPCエンドポイントを使用することで、プライベートIPアドレスでAPI Gatewayに接続できます。これにより、インターネットからのアクセスを遮断し、セキュリティを確保できます。

3. リソースポリシー

API Gatewayにはリソースポリシーが設定可能で、特定のIPアドレスやVPCエンドポイントからのみアクセスを許可できます。これにより、アクセス元を厳密に制御できます。

4. セキュアなデータ通信

VPCエンドポイントを利用すると、インターネットを経由せずにAWSのリソースと安全に通信ができます。API Gatewayへのアクセスもプライベートに保たれ、企業の機密データがインターネットに流れることを防げます。

まとめ

プライベートAPI Gateway: VPCエンドポイントを使ってインターネットからのアクセスを防ぎ、セキュリティを強化。

リソースポリシー: アクセス元をVPCや特定のエンドポイントに制限することで、APIのセキュリティを向上させる。

API GatewayとVPCの組み合わせにより、セキュアでスケーラブルなプライベートAPIが実現可能です。

実践

略

一問道場

会社はAWSクラウドでアプリケーションを実行しています。このアプリケーションは、複数のアベイラビリティゾーンにまたがるAmazon EC2インスタンスのフリートの背後にあるアプリケーションロードバランサーで実行されるマイクロサービスで構成されています。会社は最近、Amazon API Gatewayで実装された新しいREST APIを追加しました。古いマイクロサービスのいくつかは、この新しいAPIを呼び出す必要があります。会社は、APIがインターネットからアクセスされないこと、また専有データがインターネットを通過しないことを望んでいます。

解決策アーキテクトは、これらの要件を満たすために何をすべきですか？

A. VPCとAPI Gatewayの間にAWS Site-to-Site VPN接続を作成します。API Gatewayを使用して各マイクロサービス用に一意のAPIキーを生成します。APIメソッドを構成して、キーを必要とします。

B. API Gateway用にインターフェースVPCエンドポイントを作成し、エンドポイントポリシーを設定して特定のAPIへのアクセスのみを許可します。API Gatewayにリソースポリシーを追加して、VPCエンドポイントからのアクセスのみを許可します。API Gatewayのエンドポイントタイプを「プライベート」に変更します。

C. API GatewayをIAM認証を使用するように変更します。EC2インスタンスに割り当てられたIAMロールのIAMポリシーを更新して、API Gatewayへのアクセスを許可します。API Gatewayを新しいVPCに移動し、トランジットゲートウェイを展開してVPCを接続します。

D. AWS Global Acceleratorでアクセラレーターを作成し、アクセラレーターをAPI Gatewayに接続します。すべてのVPCサブネットのルートテーブルを更新して、作成したGlobal AcceleratorエンドポイントIPアドレスへのルートを追加します。各サービスが認証に使用するAPIキーを追加します。

解説

この問題では、API Gatewayをインターネットから非公開にし、EC2インスタンスからのみアクセスできるようにする方法を問うています。要件は、専有データがインターネットを通過せず、APIがパブリックインターネットからアクセスされないことです。

正解：B

Bの解答が最適です。

インターフェースVPCエンドポイントを作成し、API Gatewayへのアクセスをプライベートにします。

エンドポイントポリシーで特定のAPIへのアクセスのみを許可。

リソースポリシーでAPI GatewayがVPCエンドポイントからのアクセスのみを許可します。

API Gatewayのエンドポイントタイプを「プライベート」に変更し、インターネット経由でのアクセスを防ぎます。

これにより、APIはVPC内からのみアクセス可能となり、専有データはインターネットを経由せず、セキュアな通信が確保されます。

他の選択肢の問題点

A: Site-to-Site VPNはインターネットトラフィックを避ける解決策にはなりません。

C: IAM認証を使用しても、APIがインターネットからアクセスできる設定には変わりません。

D: Global Acceleratorはパフォーマンス向上のためのサービスで、セキュリティ要件には適しません。

結論: VPC内でプライベートアクセスを実現するには、インターフェースVPCエンドポイントを使用するのが最適です。

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

理論

企業がAWS環境を使用してインフラを構築しており、複数のエンジニアが同一のAWSアカウントで作業しています。問題は、エンジニアがEC2インスタンスのセキュリティグループ設定を誤って変更することによってコンプライアンス違反が発生することです。このような問題を防ぐため、システムをセットアップして、変更の追跡とアラート機能を提供する必要があります。

以下の手順で解決できます：

AWS CloudTrail:

CloudTrailは、AWSアカウント内でのAPI呼び出しを追跡するサービスです。これにより、誰がどのリソースにどのような操作を行ったかを詳細に記録できます。エンジニアがセキュリティグループ設定を変更した場合、その変更内容がCloudTrailのログに記録されます。

AWS Config:

AWS Configは、AWSリソースの設定を監視し、設定の変更履歴を保存するサービスです。特に、セキュリティグループの設定変更を追跡し、過去の設定状態との比較を行うことができます。AWS Configを使って、セキュリティグループの設定がコンプライアンス違反かどうかを検出し、アラートを発生させることが可能です。

Amazon CloudWatch:

CloudWatch Alarmsを使用することで、AWS ConfigやCloudTrailで検出された異常な設定変更に対してアラートを送信できます。例えば、セキュリティグループの設定がコンプライアンス基準を満たしていない場合、CloudWatchでアラートを設定して、即座に通知を送信することができます。

システム構築手順:

AWS Configで、EC2インスタンスのセキュリティグループの設定がコンプライアンス基準に合致しているかを定期的に評価します。

CloudTrailで、誰がどのタイミングでセキュリティグループの設定を変更したかを記録します。

CloudWatch Alarmsで、設定変更に関する通知を設定し、問題が発生した場合にエンジニアや管理者にアラートを送信します。

これにより、セキュリティグループの不正な変更を素早く検出し、適切な対応を取ることができます。

実践

略

一問道場

企業は、すべてのインフラをAWS上に構築しています。企業は、Amazon EC2インスタンスを使用してeコマースウェブサイトをホストし、Amazon S3を使用して静的データを保存しています。

3人のエンジニアが1つのAWSアカウントでクラウド管理と開発を行っています。

時折、あるエンジニアが他のエンジニアのEC2セキュリティグループ設定を変更し、その結果、環境でコンプライアンスの問題が発生します。

ソリューションアーキテクトは、エンジニアが行った変更を追跡するシステムをセットアップする必要があります。

このシステムは、エンジニアがEC2インスタンスのセキュリティ設定にコンプライアンス違反の変更を加えた場合にアラートを送信する必要があります。

最速でこの要件を満たす方法はどれですか？

A. 企業用にAWS Organizationsを設定する。SCPを適用して、AWSアカウント内で行われたセキュリティグループの非準拠な変更を管理および追跡する。

B. AWS CloudTrailを有効にして、EC2セキュリティグループの変更をキャプチャする。Amazon CloudWatchルールを設定して、非準拠なセキュリティ設定が検出された場合にアラートを送信する。

C. AWSアカウントにSCPを有効にして、非準拠なセキュリティグループ変更が行われた場合にアラートを送信する。

D. EC2セキュリティグループでAWS Configを有効にして、非準拠な変更を追跡する。変更をAmazon SNSトピックを通じてアラートとして送信する。

解説

D. EC2セキュリティグループでAWS Configを有効にして、非準拠な変更を追跡する

エンジニアがEC2インスタンスのセキュリティ設定にコンプライアンス違反の変更を加えた場合にアラートを送信する必要から見ると

AWS Configは、AWSリソースの設定履歴を記録し、設定が事前に定義したルール（コンプライアンス基準）に従っているかどうかを評価します。EC2セキュリティグループの設定変更が非準拠であった場合、その変更を検出し、アラートを送信する機能を持っています。

Amazon SNSを利用して、非準拠な変更に対するアラートを発信することができます。

このアプローチでは、AWS Configの評価が非常に重要です。Configはリソースの状態を監視し、定期的にチェックを行うことでコンプライアンス違反を検出します。

なぜDが正解か

AWS Configは、リソース設定の監視、評価、アラートの発信という一連の機能を包括的に提供します。特に「非準拠な変更」を追跡するためのツールとしては非常に優れています。CloudTrailやCloudWatchルールは変更の履歴をキャプチャしてアラートを発信するために有用ですが、Configはリソースの設定が基準を満たしているかを直接評価するため、コンプライアンス監視の要件を満たすには最も適した方法です。

まとめ

Dが最適な解決策です。AWS Configを使用して非準拠な変更を追跡し、変更があった際にアラートを送信するという方法が、要件に最も速やかに対応できる方法となります。

220-AWS SAP AWS 「理論・実践・一問道場」スロットリング

理論

スロットリング（Throttling）とは

システムやサービスが一定の制限を超えてリクエストを受け付けないようにする処理のことです。これは、リソースの消費が過度にならないように制御するために行われます。

例えば、Amazon Kinesis Data Streamsでは、各シャードに対して一定のスループット制限（1秒あたり最大1MBのデータまたは最大1000件のPUTリクエスト）が設けられています。この制限を超えるリクエストが行われると、システムはスロットリングを発生させ、リクエストが拒否されます。具体的には、"ReadProvisionedThroughputExceeded" というエラーが発生し、データの読み取りや書き込みが遅くなったり、失敗することがあります。

スロットリングは、システムが過負荷に陥るのを防ぐために、リソース使用を制限する方法としてよく使用されます。

シャード（Shard）とは、

データストリームを分割して処理する単位です。例えば、Amazon Kinesis Data Streamsでは、データがシャードという単位で分割され、各シャードがデータの読み書きや処理を担当します。

シャードには以下の特徴があります：

各シャードにはスループット制限（1秒あたり最大1MBのデータや1000件のリクエスト）が設定されています。

シャードの数を増やすことで、より多くのデータを処理できるようになります。

データを効率よく処理するために、システムに適切な数のシャードを配置することが重要です。

強化されたファンアウト（Enhanced Fan-Out）機能は、Amazon Kinesisの特徴で、複数の消費者がKinesisストリームから同時にデータを効率よく取得できる仕組みです。

通常、Kinesisのデータストリームは、1つの消費者がシャードからデータを取り出すと、他の消費者はそのデータを共有できません。しかし、強化されたファンアウトを使用すると、各消費者が独立して、シャードからデータをリアルタイムで取得でき、他の消費者と競合しないため、スループットが向上します。

主な特徴：

高スループット：複数の消費者が同時にデータを取り出せる。

独立したデータ取得：消費者間でデータの競合がない。

低レイテンシ：リアルタイムでデータを取得できる。

簡単に言うと、強化されたファンアウトは、複数の消費者が同時にストリームからデータを効率的に取得できるようにする機能です。

Kinesisでは、データはシャードごとに分割され、消費者（コンシューマ）は各シャードからデータを読み取って処理します。シャード間のデータのマージ（統合）は、通常、消費者側で行われますが、シャード自体の合併（リシャーディング）はKinesisが自動的に管理します。

簡単に言うと、消費者はデータをシャードごとに処理し、必要に応じてデータを統合してバックエンドに渡す役割を担います。

Kinesis Data Streamsと強化されたファンアウト機能の本質的知識

1. Kinesis Data Streamsの基本

Kinesis Data Streamsは、大量のデータをリアルタイムで処理するためのAWSサービスです。データはシャードという単位で分割され、消費者（コンシューマ）はシャードごとにデータを読み取ります。

2. シャードとデータの流れ

各シャードには固有のデータが格納されており、消費者はシャードIDを指定してデータを取得します。

通常、複数の消費者が同じシャードからデータを読み取ることができません。このため、複数の消費者が同時にデータを取得する際、競合やスロットリング（制限）問題が発生することがあります。

具体的には、強化されたファンアウトを使うと、Kinesisストリーム内のデータが複数の消費者に対して独立してコピーされ、各消費者がデータを同時に読み取ることができるようになります。これにより、各消費者は他の消費者と競合せずにリアルタイムでデータを取得できます。

3. 強化されたファンアウト（Enhanced Fan-Out）

強化されたファンアウト機能は、複数の消費者が同時に同じシャードから独立してデータを取得できる仕組みです。これにより、消費者間でのデータ競合を防ぎ、スループットを向上させます。

強化されたファンアウトを利用すると、各消費者は専用のスループットを持ち、他の消費者がデータを取得しても影響を受けません。

4. 適用シナリオ

強化されたファンアウトは、データをリアルタイムで処理する必要がある場合や、複数のアプリケーションが同じデータを消費する場合に特に有効です。

例えば、交通データやIoTデバイスのデータを複数のアプリケーションで同時に処理したい場合に、強化されたファンアウトを活用できます。

5. 利点

効率的なデータ取得: 消費者は独立してデータを取得できるため、データの競合がなくなり、スループットが向上します。

低レイテンシ: 各消費者がリアルタイムでデータを取得でき、アプリケーションの応答性が向上します。

結論：

Kinesisの強化されたファンアウト機能は、複数の消費者がリアルタイムで同時にデータを効率的に取得できるようにする重要な機能であり、大規模なデータストリーミング処理において、スループットやレイテンシを大きく改善します。

実践

略

一問道場

質問 #220

トピック 1

ある企業では、IoTセンサーが大都市全体の交通パターンを監視しています。企業は、センサーからデータを読み取り、収集し、データの集計を行いたいと考えています。

ソリューションアーキテクトは、IoTデバイスがAmazon Kinesis Data Streamsにストリームを送信し、複数のアプリケーションがそのストリームから読み取るソリューションを設計しました。しかし、いくつかの消費者がスロットリングを経験しており、定期的に「ReadProvisionedThroughputExceeded」エラーが発生しています。

この問題を解決するためにソリューションアーキテクトはどのようなアクションを取るべきですか？（3つ選んでください）

A. ストリームのシャード数を増加させるために、ストリームをリシャードする。

B. Kinesis Producer Library (KPL) を使用し、ポーリング頻度を調整する。

C. 強化されたファンアウト機能を使用した消費者を利用する。

D. ストリームのシャード数を減少させるために、ストリームをリシャードする。

E. 消費者のロジックでエラーのリトライと指数バックオフメカニズムを使用する。

F. ストリームを動的パーティショニングで構成する。

解説

シナリオ

複数のアプリケーションがKinesis Data Streamsからデータを読み取っていますが、一部の消費者がReadProvisionedThroughputExceededエラー（スロットリングエラー）に遭遇しています。これは、読み取りスループットが制限されていることが原因です。