type
status
date
slug
summary
tags
category
icon
password
书籍
091-SSE-S3
理論
1. Amazon S3の暗号化オプション
Amazon S3は、データを保護するために暗号化機能を提供しています。主に2つの方法があります：
- SSE-S3 (Server-Side Encryption with S3 Managed Keys)
AWSが管理する暗号化キー（S3管理キー）を使用して、データを暗号化します。設定が簡単で、追加のキー管理の手間がかかりません。
- SSE-KMS (Server-Side Encryption with AWS Key Management Service)
より高度なセキュリティが求められる場合、AWS KMSを利用してユーザーが管理するカスタムキーを使って暗号化します。KMSを使用することで、暗号化キーの管理やアクセス制御を細かく設定できますが、設定が複雑になります。
2. 暗号化の適用方法
- 新規オブジェクトの暗号化: S3に新しくアップロードされるオブジェクトに暗号化を適用するには、バケットの設定で暗号化オプションを選択します。これにより、アップロード時に自動的に暗号化が適用されます。
- 既存オブジェクトの暗号化: 既存のオブジェクトには、バケット設定で「SSE-S3」または「SSE-KMS」を有効にしても、新しい暗号化方式は適用されません。そのため、既存オブジェクトには手動で暗号化を適用する必要があります。これには、AWS CLIやS3バッチ操作を利用して、オブジェクトを同じ場所にコピーしながら暗号化する方法が一般的です。
3. S3バッチ操作
S3バッチ操作は、大量のオブジェクトを効率的に操作するための機能で、オブジェクトのコピーや暗号化、タグ付け、削除などの一括処理をサポートします。この操作により、大規模なS3バケットの管理が効率的になります。
4. AWS KMSの役割
AWS KMSは暗号化キーの管理サービスで、SSE-KMSを使ってS3バケットのデータを暗号化する際に使用します。KMSは、キーの作成、管理、権限設定を行い、キーアクセスを制御できますが、その分設定や運用の手間が増えます。
結論
- SSE-S3は簡単で運用効率が高いですが、カスタマイズ性が低い。
- SSE-KMSはセキュリティ要件が高い場合に適していますが、管理が複雑です。
運用の簡便さを重視する場合はSSE-S3が最適です。
一問道場
問題 #91
ある企業は、2つの異なるビジネスユニットから構成されています。各ビジネスユニットは、AWS Organizations内で単一の組織内の異なるAWSアカウントを持っています。ビジネスユニット間では、機密文書を頻繁に共有しています。このため、企業は各アカウント内にAmazon S3バケットを作成し、バケット間で低レベルのレプリケーションを設定しました。S3バケットには数百万のオブジェクトがあります。
最近のセキュリティ監査で、どちらのS3バケットにも静止データの暗号化が有効になっていないことが確認されました。企業のポリシーでは、すべての文書は静止データの暗号化が施されている必要があります。企業は、**Amazon S3管理の暗号化キー（SSE-S3）**を使用してサーバーサイド暗号化を実施したいと考えています。
最も運用効率の良い解決策はどれですか？
選択肢
A. 両方のS3バケットでSSE-S3を有効にします。S3バッチ操作を使用して、オブジェクトを同じ場所にコピーして暗号化します。
B. 各アカウントにAWS Key Management Service（AWS KMS）キーを作成します。各S3バケットで、対応するAWSアカウントのKMSキーを使用してサーバーサイド暗号化（SSE-KMS）を有効にします。AWS CLIでS3コピーコマンドを使用して、既存のオブジェクトを暗号化します。
C. 両方のS3バケットでSSE-S3を有効にします。AWS CLIでS3コピーコマンドを使用して、既存のオブジェクトを暗号化します。
D. 各アカウントにAWS Key Management Service（AWS KMS）キーを作成します。各S3バケットで、対応するAWSアカウントのKMSキーを使用してサーバーサイド暗号化（SSE-KMS）を有効にします。S3バッチ操作を使用して、オブジェクトを同じ場所にコピーします。
解説
この問題は、AWSのS3バケットで静止データの暗号化を適用する方法に関するものです。企業は、機密文書を保存するためにS3を使用しており、監査で「静止データの暗号化」が有効でないことが発覚しました。企業のポリシーでは、すべての文書に暗号化が必要です。AWSで提供される暗号化方式には「SSE-S3」と「SSE-KMS」があり、それぞれの方法で適用できるソリューションを考える必要があります。
各選択肢の解説
A. 両方のS3バケットでSSE-S3を有効にします。S3バッチ操作を使用して、オブジェクトを同じ場所にコピーして暗号化します。
- 解説: これは「SSE-S3」を使用してオブジェクトを暗号化する方法です。S3バッチ操作を使用して、既存のオブジェクトを同じ場所にコピーして暗号化します。この方法は運用効率が高く、オブジェクトを一括で暗号化できるため、最も効率的な方法の一つです。
- 利点: SSE-S3は、AWS管理のキーを使用するため、AWS KMSの設定や管理が不要です。S3バッチ操作により、複数のオブジェクトを一度に処理でき、手動の操作を最小限に抑えられます。
B. 各アカウントにAWS Key Management Service（AWS KMS）キーを作成します。各S3バケットで、対応するAWSアカウントのKMSキーを使用してサーバーサイド暗号化（SSE-KMS）を有効にします。AWS CLIでS3コピーコマンドを使用して、既存のオブジェクトを暗号化します。
- 解説: これは「SSE-KMS」を使用して暗号化を行う方法です。SSE-KMSでは、ユーザーが管理するキーを使用して暗号化を行うため、キー管理が可能です。AWS CLIでオブジェクトをコピーして暗号化しますが、この方法は手動での作業が増えるため、運用の効率は低くなります。
- 問題点: KMSを使用する場合、キー管理や権限の設定など、追加の手間がかかります。
C. 両方のS3バケットでSSE-S3を有効にします。AWS CLIでS3コピーコマンドを使用して、既存のオブジェクトを暗号化します。
- 解説: これは「SSE-S3」を有効にしてオブジェクトを暗号化する方法です。しかし、既存のオブジェクトの暗号化をAWS CLIを使って手動で行う必要があります。手動でコマンドを入力する手間がかかり、非効率です。
- 問題点: 既存オブジェクトの暗号化を手動で行うため、運用効率が低いです。
D. 各アカウントにAWS Key Management Service（AWS KMS）キーを作成します。各S3バケットで、対応するAWSアカウントのKMSキーを使用してサーバーサイド暗号化（SSE-KMS）を有効にします。S3バッチ操作を使用して、オブジェクトを同じ場所にコピーします。
- 解説: これは「SSE-KMS」を使用してオブジェクトを暗号化する方法です。S3バッチ操作を使ってオブジェクトを一括で暗号化できますが、SSE-KMSの場合、KMSキーの管理が必要になります。運用効率はSSE-S3よりも低くなりがちです。
- 問題点: KMSの設定が必要であり、SSE-S3を使用するよりも設定が複雑です。
最適な解決策は「A」
理由:
- SSE-S3は、AWS管理の暗号化キーを使用し、追加のキー管理を必要としません。
- S3バッチ操作を使用して既存のオブジェクトを一括で暗号化できるため、運用効率が非常に高いです。
- SSE-KMSを使用する場合、キー管理の設定や追加の操作が必要になるため、SSE-S3に比べて複雑です。
したがって、Aが最も運用効率が良く、要件に最適です。
092-AWS Glue
理論
1. Amazon S3ストレージクラス
Amazon S3は、異なるニーズに対応する複数のストレージクラスを提供しています。データが増加する中で、最適なストレージクラスを選択することがコスト効率に大きな影響を与えます。
- S3 Standard: 頻繁にアクセスされるデータに適しているが、コストは比較的高い。
- S3 Glacier Deep Archive: ほとんどアクセスされないデータのアーカイブに適しており、最も低コストなオプション。
- S3 Intelligent-Tiering: 頻繁にアクセスされるデータとそうでないデータを自動的に分類し、コストを最適化するが、アクセス頻度に基づいた料金が発生します。
2. S3 Lifecycleポリシー
S3 Lifecycleポリシーを使用すると、データの年齢に基づいてストレージクラスを変更するルールを自動化できます。例えば、データが1年以上経過した後に、S3 Glacier Deep Archiveに移行することで、長期保存するデータのコストを削減できます。
3. データクエリと分析
AWSには大規模なデータ分析を行うためのツールがあります。
- S3 Select: S3内のオブジェクトから直接データを選択してクエリを実行する機能。小規模なデータに適しているが、数テラバイトのデータには向いていません。
- Amazon Redshift Spectrum: Amazon Redshiftの外部データを分析するためのサービス。大規模データ分析に適していますが、コストが高くなる可能性があります。
- Amazon Athena: S3に格納されたデータを直接クエリできるサービスで、サーバーレスでスケーラブル。Athenaは、大規模なデータを効率的に分析するのに適しており、料金もクエリしたデータ量に基づくため、必要な分だけ支払うことができます。
- AWS Glue: 大規模なデータセットを管理し、メタデータカタログを作成してデータ処理を効率化するためのサービス。
メタデータカタログ
メタデータカタログは、データの構造や属性に関する情報（メタデータ）を管理するシステムです。
メタデータカタログの役割：
- データの説明: メタデータカタログには、データセットの構造（テーブル名、列名、データ型など）やデータの場所（例えば、S3バケット内のパス）などの情報が含まれます。この情報は、データの管理、発見、利用を容易にします。
- スキーマ情報: メタデータカタログは、データベースやデータセットのスキーマ（例えば、テーブル、列の構造など）を管理する場合もあります。スキーマはデータの構造を定義するものですが、メタデータカタログはそのスキーマ情報を格納する役割を持ちます。
例：AWS Glue Data Catalog
AWS Glueのメタデータカタログは、データベース、テーブル、列、データ型などのメタデータを保存するために使用されます。これにより、AthenaやRedshift Spectrum、Glue ETLなどのツールが、S3に格納されたデータにアクセスする際に必要な情報を取得することができます。
まとめ：
- メタデータカタログ: データの構造、形式、場所などに関する情報を格納し、管理するシステム。
- スキーマ: データベース内でデータの構造を定義する設計図。メタデータカタログはこのスキーマ情報を管理することがあります。
つまり、メタデータカタログはスキーマ情報を含んでいますが、メタデータカタログ自体はスキーマそのものではなく、スキーマを含むより広範なデータに関する情報を管理するものです。
一問道場
質問 #92
トピック 1
ある企業がAWSクラウドでアプリケーションを実行しています。このアプリケーションは、Amazon S3バケットに大量の非構造化データを収集して保存しています。S3バケットには数テラバイトのデータがあり、S3 Standardストレージクラスが使用されています。データは毎日数ギガバイト増加します。
企業はこのデータをクエリして分析する必要があります。1年以上古いデータにはアクセスしませんが、コンプライアンスの理由でデータは無期限に保持する必要があります。
どのソリューションが最もコスト効率よくこれらの要件を満たしますか？
A. S3 Selectを使用してデータをクエリします。S3ライフサイクルポリシーを作成して、1年以上古いデータをS3 Glacier Deep Archiveに移行します。
B. Amazon Redshift Spectrumを使用してデータをクエリします。S3ライフサイクルポリシーを作成して、1年以上古いデータをS3 Glacier Deep Archiveに移行します。
C. AWS Glue Data CatalogとAmazon Athenaを使用してデータをクエリします。S3ライフサイクルポリシーを作成して、1年以上古いデータをS3 Glacier Deep Archiveに移行します。
D. Amazon Redshift Spectrumを使用してデータをクエリします。S3ライフサイクルポリシーを作成して、1年以上古いデータをS3 Intelligent-Tieringに移行します。
解説
この問題の要点は、企業がデータを無期限に保持しつつ、コスト効率よくクエリと分析を行いたいという要件です。
A. S3 Selectは小さなデータのクエリに適しており、数テラバイトのデータに対しては不向きです。
B. Amazon Redshift Spectrumは大規模データ分析に適していますが、料金が高くつきます。
C. AWS GlueとAmazon Athenaは、S3に保存されたデータに対して効率的な分析を提供し、特にクエリが大規模なデータセットに対して最適です。また、S3 Glacier Deep Archiveにデータを移行することも最適な選択です。
D. S3 Intelligent-Tieringはデータアクセスの頻度に基づいてコスト最適化を行いますが、ここではアクセス頻度に関する要件がないため、最適ではありません。
したがって、最もコスト効率よく要件を満たすのはCです。
093-AWS Snowball
一問道場
質問 #93トピック 1
あるビデオ処理会社が、AWSを使用して機械学習（ML）モデルを作成したいと考えています。モデルの作成には、同社のオンプレミスのネットワーク接続ストレージシステムに保存された600TBの圧縮データを使用する予定です。同社はオンプレミスにはML実験に必要なコンピューティングリソースが不足しており、AWSを利用したいと考えています。
この会社は、データ転送を3週間以内に完了する必要があります。このデータ転送は一度限りの転送です。また、データは転送中に暗号化される必要があります。同社のインターネット接続のアップロード速度は100Mbpsで、複数の部署がその接続を共有しています。
最もコスト効率の良い解決策はどれですか？
A. AWS Management Consoleを使用して複数のAWS Snowball Edge Storage Optimizedデバイスを注文し、デバイスにS3バケットを宛先として設定します。デバイスにデータをコピーし、デバイスをAWSに返送します。
B. 会社のロケーションと最寄りのAWSリージョン間に10GbpsのAWS Direct Connect接続を設定し、VPN接続を介してデータを転送してAmazon S3に保存します。
C. オンプレミスのネットワーク接続ストレージと最寄りのAWSリージョン間にVPN接続を作成し、VPN接続を介してデータを転送します。
D. オンプレミスにAWS Storage Gatewayファイルゲートウェイをデプロイし、ファイルゲートウェイにS3バケットを宛先として設定してデータをファイルゲートウェイにコピーします。
解説
この問題では、600TBの圧縮データをAWSに転送するための最もコスト効率の良い方法を選ぶ必要があります。各オプションの解説は以下の通りです：
- A: Snowball Edgeは大容量のデータ転送に適しており、転送中にデータは暗号化されます。物理的にデバイスを使ってデータをAWSに送るため、ネットワーク速度に依存せず、大量のデータを効率的に転送できます。これはコスト効率が高い方法です。
- B: Direct Connectは高い帯域幅を提供しますが、100Mbpsのインターネット接続と比較すると過剰であり、コストが高くなります。また、VPN接続を使用するための追加費用も発生します。
- C: VPN接続を使ってデータを転送する方法ですが、インターネット接続の帯域幅が100Mbpsしかないため、600TBの転送には非常に時間がかかり、効率が悪くなります。
- D: Storage Gatewayはファイル転送に便利ですが、ネットワークの帯域幅に依存するため、大量のデータを迅速に転送するには非効率です。
最適な選択肢はAです。Snowball Edgeを使うことで、大量のデータを短期間で、暗号化を保持して転送できます。
094-Amazon Textract
理論
1. Amazon Textract
Amazon Textractは、スキャンした文書やフォームからテキスト、テーブル、フォームのデータを抽出するマネージドサービスです。主に以下の特徴があります：
- OCR（Optical Character Recognition）: TextractはOCRを使用して画像から文字を認識し、文書内のテキストや表形式のデータを抽出します。
- フォームデータの抽出: 手書きや印刷されたフォームからもデータを自動で抽出できます。これにより、手作業でのデータ入力作業を削減できます。
- 高精度: Textractは、Amazonが提供するAI技術を活用し、フォームや文書内の複雑なレイアウトからも精度高く情報を抽出できます。
2. AWS Step Functions
AWS Step Functionsは、分散アプリケーションやマイクロサービスを簡単にオーケストレーションできるサービスです。主な特徴は以下の通りです：
- ワークフローの自動化: ステートマシンを定義して、複数のAWSサービスやLambda関数を順番に実行できます。これにより、手動での介入なしにプロセス全体を自動化できます。
- 状態管理: ステートマシンを使用することで、個々のステップの結果に基づいて次の処理を決定できます。エラーハンドリングや再試行のロジックも簡単に組み込むことができます。
- スケーラビリティと柔軟性: 多くの異なるAWSサービスと統合でき、柔軟に拡張することが可能です。
3. AWS Lambda
AWS Lambdaは、サーバーレスコンピューティングサービスで、コードをアップロードするだけでその実行環境を管理します。主な特徴：
- イベント駆動型処理: AWS Lambdaは、指定したイベント（例：S3バケットへのファイルアップロード）に応じて自動的にトリガーされ、処理を開始します。これにより、システム全体を自動化できます。
- スケーラビリティ: 高トラフィック時でも自動でスケールアップし、リソース管理を意識することなく大規模な処理を行えます。
- コスト効率: 実行時間に応じた課金制のため、使った分だけのコストで運用できます。
4. AWS S3 (Simple Storage Service)
Amazon S3は、オブジェクトストレージサービスで、大量のデータを高可用性・耐久性で保存できます。特に、データ処理のパイプラインにおいて中心的な役割を果たします。
- データの保存と管理: フォームのスキャンデータや抽出された結果をS3バケットに保存することで、安全に管理できます。
- S3イベントトリガー: S3はファイルのアップロードや変更をトリガーとしてLambda関数を呼び出すことができます。これにより、ファイルのアップロード後に自動的に処理を開始できます。
5. データ処理の自動化
本問題の核心は、フォーム処理を自動化し、データを迅速かつ正確に抽出することです。これには以下のようなステップが含まれます：
- ファイルのアップロード: ユーザーがフォームをS3にアップロードします。
- 自動OCR（Optical Character Recognition）: Textractを利用して、フォームからテキストやデータを抽出します。
- データ抽出と処理: AWS Lambdaを使用して、抽出されたデータを解析し、必要な形式に整形します。
- ターゲットシステムへの送信: 抽出されたデータは、API経由でターゲットシステムに送信されます。
まとめ
フォーム処理の自動化には、AWSのマネージドサービスであるAmazon Textract、AWS Step Functions、AWS Lambda、およびAmazon S3を活用することが重要です。これにより、手動の介入を最小化し、データ抽出の精度を高め、プロセス全体の効率化を図ることができます。また、これらのサービスはすべてスケーラブルで柔軟性があり、長期的な運用コストの削減にも寄与します。
4o mini
一問道場
質問 #94
トピック 1
ある企業は、フォーム処理アプリケーションをAWSに移行しました。ユーザーがアプリケーションと対話するとき、スキャンされたフォームをウェブアプリケーションを通じてファイルとしてアップロードします。データベースはユーザーメタデータと、Amazon S3に保存されているファイルの参照を格納します。ウェブアプリケーションは、Amazon EC2インスタンスとAmazon RDS for PostgreSQLデータベースで実行されています。
フォームがアップロードされると、アプリケーションはチームに通知を送信します（Amazon SNSを使用）。チームメンバーはログインして各フォームを処理します。チームメンバーはフォームのデータバリデーションを行い、関連するデータを抽出してから、その情報をAPIを使用する別のシステムに入力します。
ソリューションアーキテクトは、フォームの手動処理を自動化する必要があります。このソリューションは、正確なフォーム抽出を提供し、市場への投入までの時間を最小限にし、長期的な運用オーバーヘッドを最小限に抑える必要があります。
どのソリューションがこの要件を満たしますか？
A. フォームの光学文字認識（OCR）を実行するカスタムライブラリを開発します。これらのライブラリをAmazon Elastic Kubernetes Service（Amazon EKS）クラスターにデプロイして、アプリケーション層として使用します。フォームがアップロードされると、この層を使用してフォームを処理し、結果をAmazon S3に保存します。この出力を解析し、データをAmazon DynamoDBテーブルに抽出して格納し、ターゲットシステムのAPIにデータを送信します。新しいアプリケーション層はEC2インスタンス上でホストします。
B. AWS Step FunctionsとAWS Lambdaを使用するアプリケーション層でシステムを拡張します。この層を構成して、EC2インスタンス上でホストされている人工知能（AI）および機械学習（ML）モデルを使用してフォームの光学文字認識（OCR）を実行します。フォームがアップロードされると、結果をAmazon S3に保存します。この出力を解析して、必要なデータをアプリケーション層で抽出し、ターゲットシステムのAPIにデータを送信します。
C. 新しいアプリケーション層をEC2インスタンス上でホストします。この層を使用して、Amazon SageMakerにホストされたAI/MLモデルが提供するエンドポイントを呼び出し、フォームのOCRを実行します。結果をAmazon ElastiCacheに保存します。この出力を解析し、必要なデータをアプリケーション層で抽出して、ターゲットシステムのAPIにデータを送信します。
D. AWS Step FunctionsとAWS Lambdaを使用するアプリケーション層でシステムを拡張します。この層を構成して、Amazon TextractとAmazon Comprehendを使用してフォームの光学文字認識（OCR）を実行します。フォームがアップロードされると、結果をAmazon S3に保存します。この出力を解析して、必要なデータをアプリケーション層で抽出し、ターゲットシステムのAPIにデータを送信します。
解説
この問題における最適解は D であり、その理由を以下のように説明します。
解説
- タスクの要件:
- ユーザーはフォームをアップロードし、それを処理してデータを抽出し、他のシステムに送信する必要があります。
- 現在は手動で処理しているが、自動化したいという要求があります。
- 正確なフォーム抽出、時間の短縮、運用の手間を最小化する必要があります。
- 選択肢の評価:
- A は独自のライブラリを使ってOCRを行い、EKSクラスター上で処理をするというものですが、運用負荷が高くなります。特に、大規模なスケーラビリティを持たないため、EC2インスタンスの管理やスケーリング、運用の複雑さが増す可能性があります。
- B はAI/MLモデルをEC2インスタンス上でホストし、OCR処理を行う案ですが、EC2インスタンスの運用と管理の負担が増えます。また、AWSのネイティブなサービス（例: Textract）を使用せず、独自にOCRモデルを訓練し運用する点でオーバーエンジニアリングになりがちです。さらに、Step Functions や Lambda を使用せず、手動でデータの解析・送信を行う点でも自動化が不完全です。
- C はSageMakerを使ってOCR処理を行う案ですが、これはもともと機械学習モデルを訓練するためのサービスであり、テキスト抽出には過剰なリソースです。SageMakerの利用はコストや運用の面で非効率であり、Textractを使用する方が適切です。
- D は Amazon Textract を使ってOCRを実行し、データ抽出を行う案です。Textractはフォームや文書からのデータ抽出に特化しており、最も効率的で正確です。また、 AWS Step Functions と Lambda を組み合わせることで、ワークフロー全体を自動化できます。これにより、プロセス全体を効率的に管理でき、運用負担を最小化することができます。
- なぜDが最適か:
- Amazon Textract はフォームからのテキスト抽出に最適化されており、非常に高精度で迅速に処理できます。
- AWS Step Functions と Lambda を使用することで、プロセスを完全に自動化でき、手動での介入が不要になります。
- S3にデータを保存し、必要なデータをLambdaなどで処理する流れは、効率的でスケーラブルなシステム構築を可能にします。
- このソリューションは、運用コストを削減し、長期的に見て非常にスケーラブルで管理が容易です。
結論
D の解決策は、要求されている「自動化」「正確なデータ抽出」「運用効率」を最も高いレベルで実現するものであり、AWSの最適なサービスを活用した効率的なソリューションです。
095-Lift-and-shift
理論
1. クラウド移行戦略
クラウドへの移行において、最小の変更で最大の効果を得るためには、現在使用している技術スタックにできるだけ近いクラウドサービスを選ぶことが重要です。
- Lift-and-shift: 既存のシステムを最小限の変更でクラウドに移行し、クラウドのスケーラビリティや可用性を利用します。
- Replatforming: 必要に応じて、既存システムを少し変更してクラウドサービスに最適化します。
2. Amazon EC2とAuto Scaling
AWSのEC2インスタンスは、従来の仮想マシン（VM）と非常に似た機能を提供します。EC2を使用することで、既存のオンプレミスVMからクラウド環境に移行する際に最小限の変更で移行が可能です。
- EC2 Auto Scaling: これは、負荷に応じてインスタンス数を自動的にスケーリングできるサービスです。これにより、スケーラビリティを確保しつつ、効率的なコスト管理を実現します。
3. Amazon MQとAmazon SQS
メッセージングシステムに関しては、AWSにはいくつかの選択肢があります。
- Amazon MQ: RabbitMQやActiveMQなどの既存のメッセージングシステムと互換性があり、これらのシステムを使用している場合は、Amazon MQへの移行がスムーズです。Amazon MQは、フルマネージドのメッセージングサービスであり、インフラの管理が不要になります。
- Amazon SQS: よりシンプルでスケーラブルなキューイングサービスで、より高度な機能（トピックベースのメッセージングやメッセージの順序保証など）が必要ない場合に有効です。
4. Amazon EKS（Elastic Kubernetes Service）
コンテナ化されたアプリケーションをクラウドに移行する際、Amazon EKSを使用すると、AWS上でマネージドKubernetes環境を簡単に構築できます。これにより、コンテナの管理が大幅に簡素化され、スケーラブルなバックエンドシステムの構築が可能になります。
- EKSの利点: AWSのマネージドサービスなので、Kubernetesのインフラ管理が不要で、デプロイメントやスケーリングの作業が自動化され、運用の負担が軽減されます。
5. AWSの移行における運用オーバーヘッドの最小化
AWSへの移行時に運用オーバーヘッドを最小化するためには、できるだけ自動化されたマネージドサービスを活用することが重要です。特に、以下のようなサービスを利用することで、運用の効率化が可能です。
- Amazon EKSやAmazon MQは、インフラの管理やスケーリングを自動化し、開発者や運用者がコードに集中できる環境を提供します。
- Amazon EC2 Auto Scalingは、負荷の変動に応じて自動的にスケールアップ・スケールダウンできるため、運用の手間を減らし、コストを最適化できます。
一問道場
問題 #95
トピック 1
ある会社が、自社のオンプレミスの注文処理プラットフォームをAWSクラウドにリファクタリングしています。このプラットフォームには、WebフロントエンドがVMのクラスターでホストされ、RabbitMQがフロントエンドとバックエンドを接続するために使用され、Kubernetesクラスターがコンテナ化されたバックエンドシステムを実行して注文を処理しています。この会社は、アプリケーションに大きな変更を加えたくありません。
最も運用オーバーヘッドが少ない方法はどれですか？
A. WebサーバーVMのAMIを作成し、AMIとアプリケーションロードバランサーを使用するAmazon EC2オートスケーリンググループを作成します。Amazon MQを設定して、オンプレミスのメッセージングキューを置き換えます。注文処理バックエンドをホストするためにAmazon Elastic Kubernetes Service（Amazon EKS）を設定します。
B. Webサーバー環境を模倣するカスタムAWS Lambdaランタイムを作成し、フロントエンドWebサーバーを置き換えるためにAmazon API Gateway APIを作成します。Amazon MQを設定して、オンプレミスのメッセージングキューを置き換えます。注文処理バックエンドをホストするためにAmazon Elastic Kubernetes Service（Amazon EKS）を設定します。
C. WebサーバーVMのAMIを作成し、AMIとアプリケーションロードバランサーを使用するAmazon EC2オートスケーリンググループを作成します。Amazon MQを設定して、オンプレミスのメッセージングキューを置き換えます。注文処理バックエンドをホストするために、異なるEC2インスタンスのクラスターにKubernetesをインストールします。
D. WebサーバーVMのAMIを作成し、AMIとアプリケーションロードバランサーを使用するAmazon EC2オートスケーリンググループを作成します。Amazon Simple Queue Service（Amazon SQS）を設定して、オンプレミスのメッセージングキューを置き換えます。注文処理バックエンドをホストするためにAmazon Elastic Kubernetes Service（Amazon EKS）を設定します。
解説
Aの解説:
Aの選択肢では、以下のアーキテクチャを採用しています：
- Amazon EC2 Auto Scalingグループ: これは、既存のVMをAMI（Amazon Machine Image）として作成し、クラウド環境で同様の自動スケーリングと負荷分散を提供します。これにより、オンプレミス環境でのVMの管理に慣れている場合、最も少ない変更でクラウドに移行できます。
- Amazon MQ: RabbitMQの代替としてAmazon MQを使用することで、メッセージングのインフラをクラウドネイティブに移行できます。Amazon MQは、RabbitMQに似た機能を持っており、移行がスムーズです。
- Amazon EKS: コンテナ化されたバックエンドシステムをKubernetesに対応するAmazon EKSに移行することで、運用がシンプルになります。AWSが提供するマネージドKubernetesサービスなので、Kubernetesの管理が簡素化され、運用負担が軽減されます。
この構成は、オンプレミス環境に近い状態でクラウド移行ができるため、最小限の変更で運用でき、運用オーバーヘッドを最小化できます。
Bの解説:
Bの選択肢では、AWS LambdaとAPI Gatewayを使ってアーキテクチャを変更しますが、これは以下の理由で運用オーバーヘッドが高くなります：
- Lambdaのカスタムランタイム作成: Webサーバーの代わりにLambdaを使用するには、カスタムランタイムを作成して、既存のアプリケーションに合わせる必要があります。これには開発コストと運用の負担が増えます。
- API Gateway: API Gatewayをフロントエンドとして利用するには、LambdaとAPI Gatewayの組み合わせに合わせたアーキテクチャ設計が必要です。この変更は、既存のWebアプリケーションと大きな違いがあり、運用オーバーヘッドが増加します。
Cの解説:
Cの選択肢では、EC2インスタンスにKubernetesを手動でインストールして管理しますが、これには以下の問題があります：
- Kubernetesの手動管理: Kubernetesを自分で管理する場合、AWSのEKSのようなマネージドサービスを利用するよりも、運用やスケーリング、障害対応などの手間が大きくなります。EKSを使う方が管理が簡単です。
Dの解説:
Dの選択肢では、メッセージングキューとしてAmazon SQSを使いますが、Amazon MQの方がRabbitMQと同様のメッセージング機能を持っているため、より自然な移行が可能です。SQSはシンプルなメッセージングサービスですが、RabbitMQのような高度な機能を必要とする場合には適していません。
結論:
Aは、既存のインフラとの互換性を保ちながら、クラウドネイティブなサービス（EKSやAmazon MQ）を活用して、最小限の運用オーバーヘッドで移行を実現できる最適な選択肢です。
096-kms:GenerateDataKey
理論
AWS KMS とデータ暗号化の本質
AWS Key Management Service (KMS) は、データの暗号化とキー管理を簡素化するフルマネージドサービスです。主に以下の2つの方法でデータ暗号化を行います：
- サーバー側暗号化 (SSE)：
- データがAWSサービス（例：S3）に保存される際に自動で暗号化されます。
- KMSを使って暗号化キーを管理します。
- クライアント側暗号化：
- クライアント側でデータを暗号化し、その後暗号化されたデータをAWSにアップロードします。
- KMSは暗号化キーを生成・管理し、クライアントに提供します。
主要なアクションと権限
kms:GenerateDataKey：クライアントが暗号化に使用するデータキーを生成するために必要。KMSから共通鍵CMKを取得する権限
kms:Encrypt：データをKMSで暗号化するために必要。KMSに、指定した鍵でEncrypt権限
kms:Decrypt：暗号化されたデータを復号するために必要。KMSに、指定した鍵でDecrypt権限
IAMポリシーの設定
KMSにアクセスするためには、適切なIAMポリシーで権限を設定する必要があります。例えば、
kms:Encryptやkms:GenerateDataKeyを許可することで、データ暗号化が可能になります。まとめ
- KMSはデータ暗号化とキー管理を担当し、暗号化処理をサポートします。
- クライアント側暗号化とサーバー側暗号化は異なるアプローチでデータ保護を実現します。
- 適切な権限設定が重要で、KMSを使用する際は適切なIAMポリシーでアクセスを管理する必要があります。
一問道場
質問 #96
トピック 1
ソリューションアーキテクトは、オブジェクトが新しい Amazon S3 バケットに保存される際に、クライアントサイドの暗号化メカニズムを実装する必要があります。
ソリューションアーキテクトは、この目的のために AWS Key Management Service (AWS KMS) に保存された CMK を作成しました。
ソリューションアーキテクトは、次の IAM ポリシーを作成し、それを IAM ロールに添付しました：
テスト中、ソリューションアーキテクトは S3 バケット内の既存のテストオブジェクトを正常に取得できましたが、新しいオブジェクトをアップロードしようとしたところ、「アクションは禁止されています」というエラーメッセージが表示されました。このエラーメッセージは、アップロードの試行が失敗したことを示しています。
この要件を満たすために、ソリューションアーキテクトは IAM ポリシーにどのアクションを追加する必要がありますか？
A. kms:GenerateDataKey
B. kms:GetKeyPolicy
C. kms:GetPublicKey
D. kms:Sign
解説
この問題は、クライアントサイド暗号化を使用して Amazon S3 バケットにオブジェクトを保存する際に、必要な IAM ポリシーが適切に設定されていない場合に発生するエラーについて説明しています。具体的には、S3 バケットにオブジェクトをアップロードする際に、暗号化に関連する追加の権限が不足していることが原因です。
ポリシーの解析：
- S3 バケットのアクセス権限 (
s3:GetObject,s3:PutObject, など): これらは、S3 バケット内のオブジェクトを取得したり、アップロードしたりするために必要な基本的な権限です。この部分は問題ありません。
- KMS アクセス権限 (
kms:Decrypt,kms:Encrypt): これらは、AWS KMS を使用してデータを暗号化または復号化するための権限です。しかし、クライアントサイド暗号化を使用する場合、暗号化のために KMS キーを利用する際に、データキーの生成が必要です。
クライアントサイド暗号化の処理：
クライアントサイド暗号化では、データがアップロードされる前に、まずクライアント側でデータを暗号化し、その暗号化に使用するデータキーが KMS から生成される必要があります。これを行うために、
kms:GenerateDataKey 権限が必要です。この権限は、クライアントが KMS からデータ暗号化に必要なデータキーを生成するために必要です。正解：
A. kms:GenerateDataKey
このアクションを追加することで、クライアントは暗号化に使用するデータキーを KMS から生成できるようになり、オブジェクトのアップロードが成功するようになります。
他の選択肢の説明：
- B. kms:GetKeyPolicy: これは KMS キーのポリシーを取得するための権限ですが、データキーを生成するためには必要ありません。
- C. kms:GetPublicKey: 公開鍵を取得するための権限であり、クライアントサイド暗号化に必要なデータキーを生成するためには関係ありません。
- D. kms:Sign: データに署名するための権限ですが、暗号化や復号化に関連する操作には関係しません。
結論：
クライアントサイド暗号化を利用するためには、
kms:GenerateDataKey アクションをポリシーに追加する必要があります。これにより、S3 バケットへのオブジェクトのアップロードが正常に行えるようになります。097-Count
理論
AWS WAFの基本構成とイメージ：IAMとの類似性で理解する
AWS WAF (Web Application Firewall) は、ウェブアプリケーションを不正なアクセスから保護するためのサービスです。その基本構成は、「Web ACLs」「Rules」「Associated AWS resources」の3つの要素で成り立っています。この構成を IAM（Identity and Access Management）の仕組みと比較して考えると、非常に理解しやすくなります。
1. Web ACLs = IAM グループ
「Web ACLs」は、アクセス制御のルールを管理するための「箱」です。
IAM の「グループ」のような役割を果たし、この中にルール（Rules）を定義して、リソースに適用します。
例:
- Web ACLs を作成し、その中に「SQLインジェクション防止」「IP制限」などのルールを追加。
- その後、Application Load Balancer (ALB) や Amazon CloudFront などに Web ACL を関連付けます。
Countを使ったSQLインジェクション防止の設定
- Countって何？
- Count は、攻撃をブロックせず、どのリクエストがルールに引っかかるかを「数えるだけ」の設定です。
- どうやって使うの？
- まず、「SQLインジェクション防止」のルールを作ります。
- 最初は Count に設定して、どんなリクエストがルールに引っかかるかを記録します。
- AWS WAF のログを確認して、「正しいリクエストまで引っかかっていないか」をチェックします。
- なぜCountを使うの？
- 誤検知（正しいリクエストをブロックするミス）を防ぐため。
- どのリクエストが問題かを安全にテストできます。
- 次に何をするの？
- ログを見て、必要があればルールを調整します。
- 誤検知がなくなったら、 Count を Block に変えて、本番で攻撃をブロックします。
簡単な流れ
- Count で試す → どのリクエストが引っかかるか確認。
- ログを確認 → 誤検知があればルールを修正。
- Block に切り替える → 攻撃を本番環境で防ぐ！
これで、まず安全にルールを試し、本番適用できます！
2. Rules = IAM ポリシー
「Rules」は、トラフィックを許可するか拒否するかを判断する具体的な条件を記述したものです。
IAM の「ポリシー」に似ており、許可 (Allow)、拒否 (Deny)、またはカウント (Count) のアクションを指定できます。
例:
- 特定のIPアドレスからのリクエストのみ許可するルール。
- SQLインジェクション攻撃の可能性があるリクエストをブロックするルール。
3. Associated AWS Resources = IAM ユーザー
「Associated AWS resources」は、Web ACL を適用する対象のリソースを指します。
IAM の「ユーザー」に該当する部分であり、これらのリソースに適用されたルールに基づいて、リクエストが許可または拒否されます。
例:
- ALB に Web ACL を関連付けて、リクエストの制御を行う。
- CloudFront を対象とする場合、グローバルに適用可能。
AWS WAFの構成イメージ
IAM の考え方を WAF に当てはめると、以下のような対応関係が成り立ちます：
WAF の要素 | IAM の要素 |
Web ACLs | グループ |
Rules | ポリシー |
Associated AWS Resources | ユーザー |
まとめ
AWS WAF は、Web ACL を中心に構成要素が整理されており、IAM の仕組みに似た考え方で理解できます。このように整理することで、ルールの設計やリソースの関連付けをスムーズに行えるようになります。WAF を効果的に利用して、ウェブアプリケーションのセキュリティを強化しましょう！
レートベースのルールは、短時間に大量のリクエストを送る攻撃（DDoSやブルートフォース攻撃など）を防ぐためのルールです。
何のため？
- 異常なトラフィックを制限: 1分間に一定以上のリクエストを送るIPアドレスを一時的にブロックします。
- ウェブアプリを保護: 正常な利用者に影響を与えず、攻撃だけを抑えることができます。
例
- 「1分間に1,000リクエストを超えたIPアドレスをブロックする」ルールを設定。
これにより、リソースを守りつつ、アプリケーションの可用性を確保します！
一問道場
質問 #97
トピック 1
ある企業がウェブアプリケーションを開発しました。この企業は、アプリケーションを Amazon EC2 インスタンスのグループにホスティングしており、その背後に Application Load Balancer を配置しています。この企業は、アプリケーションのセキュリティを向上させることを望んでおり、AWS WAF の Web ACL を使用する計画です。ただし、アプリケーションへの正当なトラフィックに悪影響を与えないようにする必要があります。
ソリューションアーキテクトはこの要件を満たすために Web ACL をどのように構成すべきでしょうか？
A. Web ACL ルールのアクションを Count に設定します。AWS WAF ログ記録を有効にします。誤検知（false positive）を分析し、誤検知を回避するようルールを変更します。時間をかけて、Web ACL ルールのアクションを Count から Block に変更します。
B. Web ACL ではレートベースのルールのみを使用し、スロットル制限を可能な限り高く設定します。制限を超えたすべてのリクエストを一時的にブロックします。範囲を狭めるためにネストされたルールを定義します。
C. Web ACL ルールのアクションを Block に設定します。AWS 管理ルールグループのみを Web ACL に使用します。AWS WAF のサンプルリクエストや AWS WAF ログを使用して、Amazon CloudWatch メトリクスでルールグループを評価します。
D. カスタムルールグループのみを Web ACL に使用し、アクションを Allow に設定します。AWS WAF ログ記録を有効にします。誤検知を分析し、誤検知を回避するようルールを変更します。時間をかけて、Web ACL ルールのアクションを Allow から Block に変更します。
解説
問題の解説
ポイント:
AWS WAF を導入する際、誤検知を防ぎながらセキュリティを向上させるのが重要です。そのため、初めは Count アクションを使ってルールを試し、問題がないと確認できたら Block に切り替えるのがベストプラクティスです。
正解: A
- Count を使う理由: 初めから Block を適用すると、正しいトラフィックも誤って遮断するリスクがあるため、まずは Count でトラフィックを分析します。
- WAFログで確認: AWS WAF ログを分析して、ルールが適切かどうかを確認します。
- 誤検知がない場合: Count から Block に変更し、セキュリティを本番環境で有効にします。
他の選択肢が間違いな理由
- B: レートベースルールのみでは、すべての攻撃を防げません。高い閾値の設定も適切ではない場合があります。
- C: 初めから Block を適用すると、誤検知による影響で正常なトラフィックがブロックされるリスクがあります。
- D: カスタムルールだけに依存すると、管理や設定の負担が大きく、最適化に時間がかかります。
結論: Count → ログ確認 → Block の順で設定することが、安全かつ効果的な手法です。
098-カスタマーマネージドプレフィックスリスト
理論
AWSにおけるセキュリティグループの管理は、複数のAWSアカウント間で共通のネットワークアクセス制御を一元的に行うために重要です。特に、IP CIDR範囲の管理を効率化する方法として、以下のポイントが本質的な知識となります。
1. カスタマーマネージドプレフィックスリスト
- プレフィックスリストは、特定のIP範囲をセキュリティグループやネットワークACLに一元的に適用できるリストです。これを使うことで、CIDR範囲を各アカウントで手動で設定する必要がなくなります。
- 利点: プレフィックスリストは複数のアカウントで共有できるため、一貫性が保たれ、管理が簡単になります。
2. AWS Resource Access Manager (RAM)
- AWS RAMを利用すると、組織内でリソース（プレフィックスリストなど）を他のアカウントと安全に共有できます。これにより、セキュリティチームは一度の設定で他のアカウントにも最新のIP範囲を適用できます。
3. 運用負荷の最小化
- 一元管理されたプレフィックスリストを使い、AWS RAMで簡単に共有することで、管理作業を効率化できます。これにより、セキュリティグループの設定や更新作業が自動化され、人的ミスのリスクも減少します。
これらのツールと手法を駆使することで、複数のAWSアカウントにまたがるネットワーク管理をシンプルかつ効率的に行えるようになります。
一問道場
質問 #98
トピック 1
ある企業は、AWS Organizations を使用して多数の AWS アカウントを管理しています。ソリューションアーキテクトは、組織内の AWS アカウントで共通のセキュリティグループルールをより効率的に管理する方法を改善する必要があります。
企業は、オンプレミスネットワークへのアクセスを許可するために、各 AWS アカウントに共通の IP CIDR 範囲の許可リストを持っています。各アカウント内の開発者は、自分のセキュリティグループに新しい IP CIDR 範囲を追加する責任があります。一方、セキュリティチームは独自の AWS アカウントを持っており、現在、許可リストに変更が加えられるたびに他の AWS アカウントの所有者に通知しています。
ソリューションアーキテクトは、共通の CIDR 範囲セットをすべてのアカウントに配布するソリューションを設計する必要があります。この要件を満たしながら、運用の負荷を最小限に抑える必要があります。
どのソリューションが、最小限の運用負荷でこれらの要件を満たしますか？
A. セキュリティチームの AWS アカウントに Amazon SNS トピックを設定します。各 AWS アカウントに AWS Lambda 関数をデプロイします。SNS トピックがメッセージを受信するたびに Lambda 関数が実行されるように設定します。Lambda 関数が IP アドレスを入力として受け取り、そのアカウントのセキュリティグループリストに追加するように構成します。セキュリティチームに、変更を SNS トピックに公開するよう指示します。
B. 組織内の各 AWS アカウントで新しいカスタマーマネージドプレフィックスリストを作成します。各アカウントのプレフィックスリストにすべての内部 CIDR 範囲を入力します。各 AWS アカウントの所有者に、新しいカスタマーマネージドプレフィックスリスト ID をセキュリティグループで許可するよう通知します。セキュリティチームに、各 AWS アカウント所有者に更新を共有するよう指示します。
C. セキュリティチームの AWS アカウントに新しいカスタマーマネージドプレフィックスリストを作成します。そのプレフィックスリストにすべての内部 CIDR 範囲を入力します。AWS Resource Access Manager を使用して、組織全体でプレフィックスリストを共有します。各 AWS アカウントの所有者に、新しいカスタマーマネージドプレフィックスリスト ID をセキュリティグループで許可するよう通知します。
D. 組織内の各アカウントに IAM ロールを作成します。そのロールにセキュリティグループを更新する権限を付与します。セキュリティチームの AWS アカウントに AWS Lambda 関数をデプロイします。Lambda 関数が内部 IP アドレスのリストを入力として受け取り、各組織アカウントでロールを引き受け、その IP アドレスリストをセキュリティグループに追加するように構成します。
099-Client VPN end point
理論
一問道場
問題 #99
トピック 1
ある企業が新しいポリシーを導入し、従業員はVPNを使用して自宅からリモートワークできるようになりました。企業は複数のAWSアカウント内のVPCに内部アプリケーションをホストしています。現在、アプリケーションは企業のオンプレミスオフィスネットワークからAWS Site-to-Site VPN接続を通じてアクセス可能です。企業の一つ主要なAWSアカウントのVPCには、他のAWSアカウントのVPCとピアリング接続が確立されています。
ソリューションアーキテクトは、従業員が自宅で作業する際に使用するスケーラブルなAWS Client VPNソリューションを設計する必要があります。
最もコスト効果の高い解決策はどれですか？
A. 各AWSアカウントにClient VPNエンドポイントを作成し、内部アプリケーションへのアクセスを許可するために必要なルーティングを設定する。
B. 主要なAWSアカウントにClient VPNエンドポイントを作成し、内部アプリケーションへのアクセスを許可するために必要なルーティングを設定する。
C. 主要なAWSアカウントにClient VPNエンドポイントを作成し、各AWSアカウントに接続されたトランジットゲートウェイをプロビジョニングし、内部アプリケーションへのアクセスを許可するために必要なルーティングを設定する。
D. 主要なAWSアカウントにClient VPNエンドポイントを作成し、AWS Site-to-Site VPNとの接続を確立する。
解説
この問題では、従業員が自宅からAWS上の内部アプリケーションにアクセスするためのスケーラブルでコスト効果の高いAWS Client VPNソリューションを設計する必要があります。
解説:
最適な解答は B です。
B の理由:
- 1つのClient VPNエンドポイントの利用: 主要なAWSアカウントにClient VPNエンドポイントを作成することで、他のアカウントに対しても適切なルーティングを設定し、内部アプリケーションへのアクセスを提供できます。この方法は、管理が集中しており、追加の複雑なインフラストラクチャ（例えば、トランジットゲートウェイなど）を必要としません。
- コスト効果: 他の選択肢に比べて、1つのClient VPNエンドポイントを使用することで、余分なインフラコストを避けられ、シンプルで管理が容易になります。
他の選択肢について:
- A: 各AWSアカウントにClient VPNエンドポイントを作成する方法では、複数のエンドポイントを管理しなければならず、運用負荷が増えます。また、コストが高くなる可能性があります。
- C: トランジットゲートウェイを利用する方法は、複雑でコストがかかります。特にトランジットゲートウェイのプロビジョニングや設定が必要であり、複数アカウントを接続するためには大規模な設定が必要となります。
- D: AWS Site-to-Site VPNとClient VPNを直接接続する方法は、設問の要求に合致していません。Site-to-Site VPNはオンプレミスネットワーク向けの接続であり、リモートワークに使用するClient VPNには不向きです。
まとめ
- Bの選択肢が最もシンプルでコスト効率が良く、スケーラビリティの面でも優れています。他の選択肢に比べて運用の複雑さやコストが低いため、最適な解決策です。
100-Amazon SQS
理論
サードパーティサービスの非同期呼び出しと疎結合の重要性
アプリケーションが外部サービスと連携する場合、サービスからの応答遅延やエラーが直接アプリケーションに影響を及ぼすことがあります。これを防ぐためには、外部サービスとのやり取りを非同期で行うことで、アプリケーションのパフォーマンスや信頼性を改善することができます。
非同期処理のメリット
- 応答時間の改善: 外部サービスの応答を待つことなく他の処理を並行して実行できるため、アプリケーション全体の応答性が向上します。
- スケーラビリティ: 非同期処理を活用することで、大量のリクエストが発生しても、リソースを効率的に分散し、スムーズに処理を行えます。
- エラーハンドリングと再試行: 非同期メッセージングサービスでは、失敗したリクエストを再試行したり、メッセージの順番を管理したりすることが容易にできます。
非同期メッセージングサービス
- Amazon SQS (Simple Queue Service):
SQSは、メッセージをキューに格納し、処理するシステムがメッセージを順番に取り出して実行する仕組みを提供します。メッセージが失敗した場合でも再試行が可能で、順序通りに処理を進められるため、信頼性の高い非同期処理が実現できます。
- Amazon SNS (Simple Notification Service):
SNSは、複数のサブスクライバーに対して通知を送信できるサービスですが、メッセージ順序や再試行機能は提供していません。メッセージ配信の確実性や処理順序が重要な場合、SQSの方が適しています。
非同期ワークフロー管理
- AWS Step Functions: AWS Step Functionsは、複雑なワークフローや状態管理を支援します。状態遷移の管理や並行処理が簡単に構築でき、エラーハンドリングも組み込むことができます。しかし、単純な非同期処理には過剰なソリューションとなることがあるため、SQSやSNSがよりシンプルで効率的です。
まとめ
外部サービスと連携する際に、非同期メッセージングを活用することで、アプリケーションの疎結合化、エラーハンドリング、スケーラビリティの向上が実現できます。Amazon SQS は、メッセージ順序の保証や再試行機能があり、信頼性を高めるために最適な選択肢となります。
一問道場
問題 #100
トピック 1
ある企業がAWSクラウドでアプリケーションを運用しています。最近のアプリケーションのメトリクスでは、応答時間が一貫しないこととエラー率が大幅に増加していることが示されています。サードパーティサービスへの呼び出しが遅延の原因となっています。現在、アプリケーションはAWS Lambda関数を直接呼び出してサードパーティサービスに同期的にアクセスしています。
ソリューションアーキテクトは、サードパーティサービスへの呼び出しを疎結合化し、すべての呼び出しが最終的に完了することを保証する必要があります。
この要件を満たすソリューションはどれですか？
A. Amazon Simple Queue Service (Amazon SQS) キューを使用してイベントを保存し、Lambda関数を呼び出します。
B. AWS Step Functions ステートマシンを使用してイベントをLambda関数に渡します。
C. Amazon EventBridge ルールを使用してイベントをLambda関数に渡します。
D. Amazon Simple Notification Service (Amazon SNS) トピックを使用してイベントを保存し、Lambda関数を呼び出します。
解説
この問題では、サードパーティサービスへの同期的な呼び出しが遅延を引き起こしているため、非同期に呼び出しを行い、アプリケーションの応答性を改善したいという要件です。要件は「疎結合化し、すべての呼び出しが最終的に完了すること」を求めています。
解説：
- A. Amazon SQS
- 正解。SQSは非同期のメッセージキューサービスで、Lambda関数がキューからメッセージを取り出して処理することができます。これにより、サードパーティサービスへの呼び出しが非同期になり、アプリケーションの応答性が向上します。処理は順番に行われ、メッセージが消費されるまで再試行されるため、最終的にすべての呼び出しが完了します。
- B. AWS Step Functions
- Step Functionsは状態管理を行い、複雑なワークフローを定義できますが、このケースでは単に非同期で処理を行うためには過剰なソリューションです。
- C. Amazon EventBridge
- EventBridgeはイベント駆動型のサービスですが、メッセージキューのような再試行や順序の管理が必要な場合には、SQSの方が適しています。
- D. Amazon SNS
- SNSは通知を送るためのサービスで、非同期にメッセージを送信できますが、再試行の機能がなく、メッセージ順序が保証されないため、SQSよりも効果的ではありません。
結論：
A. SQS は最もシンプルで効果的な非同期解決策であり、要求された疎結合と最終的な完了を保証します。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/16cd7ae8-88e2-8083-b6db-f4b2a3e0cd59
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
