type
status
date
slug
summary
tags
category
icon
password
481-AWS SAP AWS 「理論・実践・一問道場」Auroraレプリカ
理論
1. Auto ScalingとElastic Load Balancer (ELB)
- Auto Scalingは、負荷に応じてEC2インスタンスを自動的にスケールアウト（増加）またはスケールイン（減少）させることで、高負荷時でもアプリケーションが安定して動作するようにします。
- *Elastic Load Balancer (ELB)**は、トラフィックを複数のEC2インスタンスに分散するため、単一のインスタンスに負荷が集中することを防ぎます。
2. データベースのスケーラビリティ
- Amazon Auroraは、MySQL互換のフルマネージドなリレーショナルデータベースで、Auroraレプリカを利用することで、読み取り専用の操作を複数のレプリカに分散できます。これにより、読み取り負荷を軽減し、データベースのパフォーマンスが向上します。
- Multi-AZデプロイメントは、高可用性と自動フェイルオーバーを提供するため、障害が発生してもサービスの中断を最小限に抑えることができます。
3. AWS Lambdaとサーバーレスアーキテクチャ
- AWS Lambdaは、サーバーレスコンピューティングサービスで、インフラの管理なしでコードを実行できます。自動スケーリングを提供しますが、EC2ベースのアプリケーションをLambdaに移行するには大きな開発労力がかかります。
4. CDN (Content Delivery Network)
- Amazon CloudFrontは、グローバルに分散したエッジロケーションを使ってコンテンツを高速に配信するCDNです。主に静的コンテンツやキャッシュに利用され、アプリケーションのパフォーマンス向上に貢献しますが、動的コンテンツの負荷分散には直接的な効果は少ないです。
これらの概念は、アプリケーションのパフォーマンスや可用性を向上させ、信頼性の問題を最小限に抑えるために重要な技術です。
実践
略
一問道場
質問 #481
ある企業のWebアプリケーションには信頼性の問題があります。このアプリケーションはグローバルに顧客にサービスを提供しています。アプリケーションは単一のAmazon EC2インスタンスで実行され、Amazon RDS for MySQLデータベースに対して読み取り集中型の操作を行っています。高負荷時にアプリケーションは応答しなくなり、EC2インスタンスの手動再起動が必要です。ソリューションアーキテクトはアプリケーションの信頼性を向上させなければなりません。
最小の開発労力でこの要件を満たすソリューションはどれですか？
A. Amazon CloudFrontディストリビューションを作成します。EC2インスタンスをディストリビューションのオリジンとして指定し、RDS for MySQLデータベースのためにMulti-AZデプロイメントを構成します。読み取り集中型の操作にスタンバイDBインスタンスを使用します。
B. アプリケーションをAuto Scalingグループ内のEC2インスタンスで実行します。EC2インスタンスをElastic Load Balancer (ELB) ロードバランサーの背後に配置します。データベースサービスをAmazon Auroraに置き換え、読み取り集中型の操作にはAuroraレプリカを使用します。
C. AWS Global Acceleratorをデプロイします。RDS for MySQLデータベースのためにMulti-AZデプロイメントを構成します。読み取り集中型の操作にスタンバイDBインスタンスを使用します。
D. アプリケーションをAWS Lambda関数に移行します。RDS for MySQLデータベースのために読み取りレプリカを作成し、読み取り集中型の操作には読み取りレプリカを使用します。
解説
この問題では、信頼性の向上が求められています。特に、アプリケーションが高負荷時に応答しなくなり、手動でEC2インスタンスを再起動しなければならないという問題があります。最小の開発労力でこの問題を解決するソリューションを選択する必要があります。
それぞれの選択肢について説明します：
A. Amazon CloudFrontディストリビューションを作成し、Multi-AZデプロイメントを構成
- CloudFrontは、静的コンテンツの配信やキャッシュ用に利用されることが多いですが、動的なアプリケーションのパフォーマンス向上には直接的な効果がありません。また、RDSのスタンバイDBインスタンスを使用することで読み取り専用の負荷分散を試みることはできますが、これも信頼性向上には十分な解決策ではない可能性があります。
- 評価: これではWebアプリケーションのパフォーマンスや信頼性を大きく改善するのに十分ではありません。
B. Auto Scalingグループ、ELB、Auroraレプリカを利用
- Auto Scalingにより、EC2インスタンスが負荷に応じてスケールアップやスケールダウンするため、高負荷時でも自動的に新しいインスタンスが起動し、パフォーマンスが安定します。
- ELB（Elastic Load Balancer）を使用して、複数のEC2インスタンスにトラフィックを分散することで、1つのインスタンスに過剰な負荷がかかるのを防ぎます。
- Auroraレプリカを使用することで、読み取り集中型の操作を複数のレプリカに分散し、データベースの読み取りパフォーマンスが向上します。
- 評価: これは高負荷時のスケーラビリティを確保し、アプリケーションの信頼性とパフォーマンスを向上させる最も効果的で開発労力の少ない方法です。
C. AWS Global AcceleratorとMulti-AZ RDSデプロイメント
- AWS Global Acceleratorは、アプリケーションのパフォーマンス向上に役立つツールですが、主にネットワークの最適化に使用され、アプリケーションのスケーラビリティや信頼性に直接関係するわけではありません。
- RDSのMulti-AZデプロイメントは高可用性を提供しますが、アプリケーションのスケーラビリティや負荷分散には不十分です。
- 評価: Global Acceleratorは適切ですが、信頼性を向上させるための最小限の開発労力としては不足しています。
D. AWS Lambdaと読み取りレプリカを利用
- AWS Lambdaはサーバーレスのアーキテクチャであり、アプリケーションの自動スケーリングには役立ちますが、EC2インスタンスで動作している既存のアプリケーションをLambdaに移行するには、かなりの開発労力がかかります。
- 読み取りレプリカの利用は、データベースのパフォーマンスを改善するのに役立ちますが、アプリケーションのスケーラビリティや信頼性を大幅に向上させるには、Lambdaへの移行が必要となるため、これは最小の開発労力ではありません。
- 評価: 開発労力が大きく、最小限の開発労力での改善策としては不適切です。
結論
最も効率的で、最小の開発労力で信頼性を向上させる方法は B（Auto Scaling、ELB、Auroraレプリカを利用）です。これにより、アプリケーションはスケーラブルになり、負荷が高い時でも自動的に処理が分散されるため、信頼性とパフォーマンスが大幅に向上します。
482-AWS SAP AWS 「理論・実践・一問道場」PGP秘密鍵
理論
1. AWS Transfer Family
AWS Transfer Familyは、SFTP（SSH File Transfer Protocol）、FTPS（FTP Secure）、およびFTPを使用して、安全にデータをAWSに転送できるサービスです。これにより、外部のシステムとデータを安全に交換することができます。
2. PGP暗号化と復号化
- *PGP（Pretty Good Privacy）**は、電子メールの暗号化やファイルのセキュリティ確保に広く使用される暗号化技術です。
- PGPは、公開鍵と秘密鍵をペアで使用します。公開鍵で暗号化したデータは、対応する秘密鍵で復号化できます。
- PGP暗号化されたデータを復号化するためには、秘密鍵が必要です。
3. AWS Secrets Manager
AWS Secrets Managerは、アプリケーションで使用する秘密情報（APIキー、パスワード、秘密鍵など）を安全に管理・保管するためのサービスです。これを使用して、秘密鍵やその他の重要な情報を安全に保存し、必要なときにアクセスできます。
4. Transfer Family ワークフロー
AWS Transfer Familyでは、管理されたワークフローを使ってファイル処理を自動化できます。これにより、ファイル受信後に自動で処理（例えば、解読、転送、保存など）を行うことができます。ワークフロー内でのステップ設定を行うことで、データの暗号化/復号化を自動化することが可能です。
5. IAMロールとポリシー
- *IAM（Identity and Access Management）**は、AWSリソースへのアクセス権限を管理するためのサービスです。
- IAMサービスロールを使って、AWS Transfer FamilyなどのサービスがAWSリソース（例えば、Secrets ManagerやS3バケット）にアクセスできるようにします。信頼関係を設定することで、サービスが特定のロールを引き受け、アクセスできるようにします。
6. ノミナルステップ vs 例外処理
- ノミナルステップは、ワークフローの中で標準的な、予期される処理を行うステップです。
- 例外処理は、エラーや予期しない状況が発生した場合に行う処理です。解読処理には例外処理を使うべきではなく、正常なフローに組み込むべきです。
これらの知識を元に、AWS Transfer Familyを利用した自動化されたファイル受信とPGP復号化の設定を適切に行うことができます。
実践
略
一問道場
質問 #482
ある会社が、第三者のデータ供給者からの更新を受け取るために、AWS Transfer Family SFTP対応サーバーとAmazon S3バケットを使用する必要があります。データはPretty Good Privacy (PGP) 暗号化で暗号化されています。この会社は、データを受け取った後に自動的にデータを復号化するソリューションが必要です。
ソリューションアーキテクトは、Transfer Family管理されたワークフローを使用する予定です。この会社は、AWS Secrets ManagerおよびS3バケットへのアクセスを許可するIAMポリシーを使用してIAMサービスロールを作成しました。ロールの信頼関係により、transfer.amazonaws.comサービスがそのロールを引き受けることができます。
ソリューションアーキテクトは、自動復号化のためのソリューションを完成させるために次に何をすべきでしょうか？
A. PGP公開鍵をSecrets Managerに保存し、Transfer Family管理されたワークフローでファイルを復号化するためのノミナルステップを追加します。ノミナルステップでPGP暗号化パラメーターを設定します。ワークフローをTransfer Familyサーバーに関連付けます。
B. PGP秘密鍵をSecrets Managerに保存し、Transfer Family管理されたワークフローでファイルを復号化するための例外処理ステップを追加します。例外ハンドラでPGP暗号化パラメーターを設定します。ワークフローをSFTPユーザーに関連付けます。
C. PGP秘密鍵をSecrets Managerに保存し、Transfer Family管理されたワークフローでファイルを復号化するためのノミナルステップを追加します。ノミナルステップでPGP復号化パラメーターを設定します。ワークフローをTransfer Familyサーバーに関連付けます。
D. PGP公開鍵をSecrets Managerに保存し、Transfer Family管理されたワークフローでファイルを復号化するための例外処理ステップを追加します。例外ハンドラでPGP復号化パラメーターを設定します。ワークフローをSFTPユーザーに関連付けます。
解説
この問題は、AWS Transfer Familyを使用して、外部のデータ供給者からPGP（Pretty Good Privacy）で暗号化されたデータを受け取るシナリオに関するものです。受け取ったデータは暗号化されており、そのままでは利用できません。そのため、解決策としてデータを自動的に復号化（解読）する方法を選択する必要があります。
問題の要点：
- SFTPサーバー：AWS Transfer Familyを使用して、SFTPでデータを受け取ります。これにより、第三者からのファイル転送が可能になります。
- PGP暗号化：受け取るデータはPGPで暗号化されています。PGPはデータの暗号化と復号化に公開鍵と秘密鍵を使用します。
- 自動解読：データを受け取った後に自動的に復号化（解読）を行う必要があります。
進行中の作業：
- 会社は、IAMサービスロールを作成し、AWS Secrets Manager（PGP鍵を保存する場所）とS3バケットへのアクセス権を与えています。このロールの信頼関係により、AWS Transfer Familyはこのロールを引き受けて操作を実行できます。
- ここでの目的は、「受け取った暗号化されたデータを自動的に復号化する方法」を設定することです。
各選択肢の分析：
A. PGP公開鍵をSecrets Managerに保存し、ノミナルステップで解読を行う
- PGP公開鍵は暗号化に使用される鍵であり、復号化には秘密鍵が必要です。したがって、公開鍵を保存しても解読には使用できません。この選択肢は間違いです。
B. PGP秘密鍵をSecrets Managerに保存し、例外処理で解読を行う
- こちらは秘密鍵をSecrets Managerに保存する方法で、これは正しい手法です。しかし、**「例外処理」**を使用して解読を行うのは、標準的な処理としては適切ではありません。例外処理は通常、エラーが発生した場合に使用されるもので、正常なデータ解読のフローにはふさわしくないため、この選択肢も不正解です。
C. PGP秘密鍵をSecrets Managerに保存し、ノミナルステップで解読を行う
- これは正しい選択肢です。PGP秘密鍵をSecrets Managerに保存し、ノミナルステップでデータを復号化します。ノミナルステップは、標準的な、通常のフローであり、復号化のために適切な場所で実行されるべき処理です。
D. PGP公開鍵をSecrets Managerに保存し、例外処理で解読を行う
- 再度、公開鍵を使用して復号化することはできません。また、解読処理に例外処理を使用するのも不適切です。この選択肢も不正解です。
正解：
C. PGP秘密鍵をSecrets Managerに保存し、ノミナルステップで解読を行う
- PGP秘密鍵をSecrets Managerに保存し、標準的な解読ステップ（ノミナルステップ）を設定することで、データの復号化を自動化できます。この方法が最適です。
483-AWS SAP AWS 「理論・実践・一問道場」MemoryDB
理論
1. AWSにおけるデータベースとインメモリストレージ
- Amazon RDS (Relational Database Service):
- フルマネージドなリレーショナルデータベースサービス。耐久性が高く、バックアップやスケーリングが簡単ですが、書き込みレイテンシが高くなることがある。
- 用途: トランザクション処理や分析のためのデータ保持。
- Amazon MemoryDB for Redis:
- フルマネージドインメモリデータベースで、高いパフォーマンスと低レイテンシを提供。
- 永続化機能があり、高可用性とデータの永続化を確保。リアルタイムデータ処理に最適。
- 用途: 高速なデータアクセスが必要なアプリケーション（例: ゲームのリーダーボード、セッション管理）。
- Amazon ElastiCache for Redis:
- インメモリキャッシュサービス。データの読み取りと書き込み速度が非常に速い。
- 用途: キャッシュ用途や一時的なデータストレージとして使用され、データの永続化や高可用性には追加の設定が必要。
2. 高可用性と耐障害性の構成
- Multi-AZ配置:
- 複数のアベイラビリティゾーンにまたがる配置により、障害発生時の自動フェイルオーバーを実現。
- 耐障害性と高可用性を向上させ、システムダウンタイムを最小限に抑える。
- バックアップとデータ永続化:
- データの永続性を確保するために、データベースは定期的にバックアップを取る必要があります。
- S3やEBSなどを使用して、データのバックアップやログ保存が可能。
3. インメモリデータストレージの特徴
- 低レイテンシ:
- インメモリストレージは、ディスクベースのストレージよりも高速で、数ミリ秒単位でデータにアクセスできます。これがゲームやリアルタイムアプリケーションで重要です。
- データの一貫性:
- RedisやMemoryDBは、データがメモリ内で管理されるため、非常に高いパフォーマンスを発揮します。永続化設定をすることで、データをディスクにも保存でき、データの損失を防げます。
- スケーラビリティ:
- インメモリストレージは、スケールアウト（複数ノードの追加）やスケールアップ（より大きなインスタンスの使用）によって、アプリケーションの成長に対応できます。
4. 運用負荷の軽減
- フルマネージドサービス:
- AWSのフルマネージドサービス（MemoryDB for Redis、RDSなど）は、運用の手間を大きく削減します。バックアップ、スケーリング、障害復旧などをAWSが自動で処理してくれるため、運用負荷が低減します。
- EC2での自己管理:
- EC2インスタンスで自分でRedisを構築する場合、運用負荷が増加します。インスタンスの管理、スケーリング、バックアップの手動設定が必要です。
結論
この問題では、リアルタイム性とデータ永続化の要件を満たし、運用負荷を最小化するためには、MemoryDB for Redisのようなフルマネージドで高可用性のインメモリストレージが適していることがわかります。
実践
略
一問道場
問題 #483
ある企業が、大規模マルチプレイヤーゲームのインフラをAWSに移行しています。このゲームのアプリケーションには、プレイヤーがリアルタイムでランキングを見ることができるリーダーボードがあります。リーダーボードは、マイクロ秒単位の読み取りと、数ミリ秒単位の書き込み遅延を必要とします。データセットのサイズは数テラバイトで、プライマリノードが障害を起こした場合でも、1分以内に書き込みを受け付けることができなければなりません。企業は、データが今後の分析処理用にデータパイプラインを通じて永続化されるソリューションを必要としています。
どのソリューションが最も運用負荷を抑えつつ、これらの要件を満たしますか？
- A. Amazon ElastiCache for Redisクラスタを作成し、Multi-AZモードで構成します。アプリケーションをプライマリノードとやりとりするように設定します。
- B. Amazon RDSデータベースを作成し、読み取りレプリカを設定します。アプリケーションに書き込み先として書き込みエンドポイントを指し示し、読み取り先として読み取りエンドポイントを指し示すように設定します。
- C. Amazon MemoryDB for Redisクラスタを作成し、Multi-AZモードで構成します。アプリケーションをプライマリノードとやりとりするように設定します。
- D. 複数のRedisノードをAmazon EC2インスタンスに配置し、複数のアベイラビリティゾーンに分散させます。バックアップをAmazon S3に設定します。
解説
この問題では、大規模マルチプレイヤーゲームのインフラをAWSに移行し、リアルタイムで更新されるリーダーボードのデータを高いパフォーマンスで処理する必要があります。また、プライマリノードが障害を起こした場合でも迅速に復旧し、データを将来の分析処理のために永続化する必要があります。これらの要件を満たすために、最も運用負荷が少ない解決策を選ぶことが求められています。
各選択肢を順番に解析します。
A. Amazon ElastiCache for Redis クラスタを作成し、Multi-AZモードで構成します。アプリケーションをプライマリノードとやりとりするように設定します。
- ElastiCache for Redis はインメモリデータストアで、非常に高速なデータ読み書きが可能です。しかし、復旧の速さとデータ永続性の観点で不十分です。
- Redisは主にキャッシュ用途で使われるため、データを永続的に保存するためには追加のストレージ設定や、データパイプラインを構成する必要があります。
- ただし、データ永続化や分析用のデータパイプラインに関する要件は、この選択肢では十分に満たされません。
- したがって、この選択肢は要件を完全に満たさないため、不適切です。
B. Amazon RDSデータベースを作成し、読み取りレプリカを設定します。アプリケーションに書き込み先として書き込みエンドポイントを指し示し、読み取り先として読み取りエンドポイントを指し示すように設定します。
- Amazon RDS はリレーショナルデータベースサービスで、高い耐久性を提供し、データ永続性の要件に適しています。
- 読み取りレプリカを使用して、読み取りのパフォーマンスを向上させることができますが、書き込みのレイテンシーが数ミリ秒という要件に対して十分に対応できるかは不明です。特に、RDSはマルチプレイヤーゲームのような非常に高いスループットが要求されるアプリケーションには最適ではないかもしれません。
- また、RDSの復旧速度は遅く、障害発生時に1分以内で書き込みを受け付けるという要件を満たすためには追加の対策が必要になる可能性があります。
- よって、この選択肢はパフォーマンス要件を十分に満たすことができません。
C. Amazon MemoryDB for Redis クラスタを作成し、Multi-AZモードで構成します。アプリケーションをプライマリノードとやりとりするように設定します。
- MemoryDB for Redis はAWSのフルマネージドインメモリデータベースで、耐久性と高可用性を提供するために設計されています。データが永続化されるため、バックアップや障害復旧にも対応できます。
- また、Multi-AZモードを使用することで、高可用性と耐障害性が確保され、プライマリノードがダウンした場合でも、1分以内にデータの書き込みが再開できる可能性が高くなります。
- さらに、MemoryDB for Redisは非常に低い読み書きレイテンシ（数ミリ秒）を提供し、ゲームのようなリアルタイムアプリケーションに最適です。
- データを将来の分析処理のために永続化できることから、この選択肢は要件を最も満たすと言えます。
D. 複数のRedisノードをAmazon EC2インスタンスに配置し、複数のアベイラビリティゾーンに分散させます。バックアップをAmazon S3に設定します。
- EC2インスタンスに複数のRedisノードを配置して分散することは可能ですが、これには運用の管理負担が伴います。AWSのマネージドサービスを利用する場合と比べて、手動でのスケーリング、バックアップ、障害時の復旧など、管理が大変です。
- また、バックアップをS3に設定しても、高可用性や低レイテンシの要件を満たすためには、アーキテクチャの設計が複雑になり、運用負担が増える可能性があります。
- よって、この選択肢は運用負荷が高く、最小限の運用負荷を求める要件には適していません。
結論
最も運用負荷が少なく、すべての要件を満たすのは、C. Amazon MemoryDB for Redis クラスタを作成し、Multi-AZモードで構成するです。この選択肢は、低レイテンシ、高可用性、データ永続化に対応し、運用負荷も最小限に抑えることができます。
484-AWS SAP AWS 「理論・実践・一問道場」CUR
理論
1. AWSのコスト管理
AWSのコスト管理は、企業がリソース使用量や料金をトラッキングし、ビジネスユニットや部門ごとにコストを割り当てて管理するために重要です。AWSには、コストと使用状況を可視化し、管理するためのいくつかのツールが提供されています。
- AWS Cost Explorer:
- AWSリソースの使用量とコストを視覚化するツール。リソースごとのコスト分析やトレンドを把握できます。
- 特定のタグやアカウントに基づいてコストをフィルタリングする機能もあります。
- AWS Cost and Usage Report (CUR):
- 詳細なコストレポートを生成するためのツール。AWS CURでは、各サービスの使用状況や料金を1時間単位、日単位、月単位で取得できます。
- AWS CURを利用することで、アカウント単位やリソース単位での精密なコスト分析が可能です。
2. コスト割り当てタグ
- コスト割り当てタグ:
- AWSリソースにタグを付けることで、各ビジネスユニットやプロジェクトごとにコストを割り当てることができます。例えば、「BusinessUnit」や「Department」など、プロジェクトや部署に関連したタグを利用します。
- タグを使用すると、リソースごとにコストを追跡し、コスト分析や予算管理が容易になります。
3. データ集約と可視化
- Amazon S3:
- AWSでは、データやレポートの集約先としてAmazon S3がよく使用されます。AWS CURデータはS3バケットに保存され、そこからAthenaやQuickSightでクエリ・可視化ができます。
- S3は、データの保存や管理に非常にスケーラブルで、コスト効果の高いオプションです。
- Amazon Athena:
- S3に保存されたデータをSQLライクなクエリで簡単に検索できるサーバーレスなサービス。AWS CURデータを処理する際にも使用されます。
- Athenaは、データのフィルタリングや集計、分析が簡単に行え、コスト削減にも寄与します。
- Amazon QuickSight:
- ビジネスインテリジェンスツールで、Amazon S3に保存されたデータを視覚的に分析できます。リーダブルなダッシュボードを作成し、経営層やチームに対して可視化されたデータを提供します。
4. 役立つアーキテクチャとベストプラクティス
- 中央集約型のコスト管理:
- 複数のAWSアカウントを利用している場合、管理アカウントでAWS CURを集約し、コスト分析を行う方法が推奨されます。この方法では、すべてのリソースのデータを中央で管理でき、可視化やレポート生成が簡単になります。
- タグの一貫性:
- コスト分析を正確に行うためには、タグの一貫性を保つことが重要です。特に、BusinessUnitやProjectなどのタグを設定して、各リソースのコストを正確に把握できるようにします。
5. 可視化の重要性
- コストの可視化:
- コストを視覚的に分析することで、無駄なリソースの削減や、コスト効率の良い運用が可能になります。AWSのQuickSightやAthenaを使用することで、非常に詳細なレポートを作成でき、経営層へのレポーティングが簡単になります。
- CloudWatch vs. QuickSight:
- CloudWatchは主にモニタリングとアラートを提供するツールで、コスト分析には適していません。QuickSightはデータを視覚的に分析するためのBIツールで、コストレポートやビジネスインテリジェンスの可視化に最適です。
結論
AWSを使ったコスト管理では、タグ付けと中央集約型のデータ管理が基本です。これにより、複数のアカウントやリソースのコストを正確に把握し、効率的なコスト削減が実現できます。AthenaとQuickSightを使用した可視化によって、データに基づいた意思決定がしやすくなります。
実践
略
一問道場
問題 #484
ある企業がAWSクラウドで複数のアプリケーションを運用しています。これらのアプリケーションは企業の異なるビジネスユニットに特化しています。企業は、AWS Organizations内の複数のAWSアカウントでアプリケーションのコンポーネントを運用しています。企業のすべてのクラウドリソースには、「BusinessUnit」というタグが付けられており、そのタグにはビジネスユニット名が適切に設定されています。企業は、異なるビジネスユニットに対してクラウドコストを割り当て、各ビジネスユニットのクラウドコストを可視化する必要があります。
どのソリューションがこれらの要件を満たしますか？
- A. 組織の管理アカウントで、「BusinessUnit」という名前のコスト割り当てタグを作成します。また、管理アカウントでAmazon S3バケットとAWSコストおよび使用状況レポート（AWS CUR）を作成します。S3バケットをAWS CURの宛先として設定します。管理アカウントからAmazon Athenaを使用してAWS CURデータをクエリし、Amazon QuickSightで可視化します。
- B. 各メンバーアカウントで、「BusinessUnit」という名前のコスト割り当てタグを作成します。組織の管理アカウントでAmazon S3バケットとAWSコストおよび使用状況レポート（AWS CUR）を作成します。S3バケットをAWS CURの宛先として設定します。Amazon CloudWatchダッシュボードを作成して可視化します。
- C. 組織の管理アカウントで、「BusinessUnit」という名前のコスト割り当てタグを作成します。各メンバーアカウントでAmazon S3バケットとAWSコストおよび使用状況レポート（AWS CUR）を作成します。各S3バケットをそのAWS CURの宛先として設定します。管理アカウントでAmazon CloudWatchダッシュボードを作成して可視化します。
- D. 各メンバーアカウントで、「BusinessUnit」という名前のコスト割り当てタグを作成します。また、各メンバーアカウントでAmazon S3バケットとAWSコストおよび使用状況レポート（AWS CUR）を作成します。各S3バケットをそのAWS CURの宛先として設定します。管理アカウントからAmazon Athenaを使用してAWS CURデータをクエリし、Amazon QuickSightで可視化します。
解説
この問題では、複数のビジネスユニットに対してクラウドコストを割り当て、各ビジネスユニットのコストを可視化する必要があり、解決策としてAWSのコスト管理ツールを使用する方法を選ぶ必要があります。
各選択肢を順番に解析します。
選択肢 A: 組織の管理アカウントで、「BusinessUnit」という名前のコスト割り当てタグを作成し、S3バケットとAWS CURを設定し、AthenaでクエリしてQuickSightで可視化
- コスト割り当てタグの作成: コスト割り当てタグ（BusinessUnitタグ）を管理アカウントで作成することは、すべてのリソースにコストを正しく割り当てるために有効です。
- AWS CUR（Cost and Usage Report）: AWS CURは、使用状況とコストデータの詳細なレポートを生成できます。管理アカウントでS3バケットにCURを保存し、そこからデータを集計・可視化する流れは理にかなっています。
- Amazon AthenaとQuickSight: Athenaを使用してS3に保存されたAWS CURデータをクエリし、その結果をAmazon QuickSightで可視化することが可能です。QuickSightはBIツールとして、データを視覚的に分析できます。
- メリット: すべてのデータを中央で集約し、分析するため、運用管理が簡素化されます。
結論: この方法は最も合理的で、全体的に最も運用負荷が少なく、要件に最適な方法です。
選択肢 B: 各メンバーアカウントでタグを作成し、管理アカウントでAWS CURを設定し、CloudWatchダッシュボードで可視化
- コスト割り当てタグの作成: 各メンバーアカウントでBusinessUnitタグを作成することは適切ですが、タグ情報を集約して分析するための手段が不十分です。
- AWS CURとCloudWatchダッシュボード: AWS CURを設定してデータを収集するのは適切ですが、CloudWatchダッシュボードはコスト分析には最適ではないです。CloudWatchは主に監視ツールであり、コストの可視化には限界があります。
- 問題点: CloudWatchは主にメトリクスの監視を目的としたツールであり、コスト分析のために使用するには非効率的です。
結論: CloudWatchを使用してコストデータを可視化するのは適切でなく、この選択肢は要件を十分に満たさない可能性があります。
選択肢 C: 組織の管理アカウントでタグを作成し、各メンバーアカウントでS3バケットを設定し、CloudWatchダッシュボードで可視化
- コスト割り当てタグとAWS CURの設定: 管理アカウントでタグを作成し、各メンバーアカウントでS3バケットを設定してAWS CURを保存する方法は理にかなっています。しかし、これではデータが複数のバケットに分散されるため、集約が難しくなります。
- CloudWatchダッシュボードでの可視化: CloudWatchは再度、コスト可視化には不向きです。この選択肢も適切ではありません。
結論: データの集約に関して効率的でない上、CloudWatchを使うのは不適切です。
選択肢 D: 各メンバーアカウントでタグを作成し、S3バケットとAWS CURを設定し、AthenaとQuickSightで可視化
- コスト割り当てタグとAWS CURの設定: 各メンバーアカウントでタグを作成し、AWS CURを設定してS3に保存することは有効です。
- AthenaとQuickSightでの可視化: データがS3に集約されるので、Athenaでクエリし、QuickSightで可視化する流れは理にかなっています。しかし、この方法では、メンバーアカウントごとにS3バケットを管理する必要があり、管理が複雑になります。
結論: 各アカウントにS3バケットを設定し、データを分散して管理する必要があるため、運用の手間が増加します。
結論
最も適切な選択肢はAです。管理アカウントでコスト割り当てタグを作成し、AWS CURを集約し、AthenaとQuickSightを使用して可視化する方法が最も効率的で運用負荷が少ない方法です。
485-AWS SAP AWS 「理論・実践・一問道場」TooManyRequestsException
理論
1. DynamoDB のスループット制限
- ProvisionedThroughputExceededException は、DynamoDB の設定された書き込みキャパシティ（WCU）を超えたときに発生します。これを解決するために、DynamoDB の書き込みキャパシティユニット（WCU）を増加させることが効果的です。
- DynamoDB Auto Scaling を使用すると、トラフィックに応じて自動でキャパシティをスケーリングできます。
2. Lambda のメモリ設定
- AWS Lambda のパフォーマンスは、割り当てたメモリに依存します。メモリを増加させると、より多くの CPU リソースも利用可能になり、処理が高速化します。
- Lambda 関数のタイムアウト設定も確認し、適切な時間を設定することが重要です。
3. Kinesis とバッチ処理
- Amazon Kinesis は、リアルタイムでのデータストリーミングを処理するためのサービスです。Kinesis のデータストリームを利用することで、リアルタイムデータを効率的に処理し、バッチ処理にてデータをまとめて処理することができます。
- Kinesis はスケーラブルであり、データの流れを効率的に管理し、Lambda や他のサービスに負荷をかけすぎずにデータ処理が可能です。
4. API Gateway と Lambda の統合
- Amazon API Gateway を使用してデータを受信し、その後 Lambda で処理する方法は一般的ですが、大量のリクエストが来ると Lambda に過負荷がかかる場合があります。このような場合、Kinesis や SQS などのメッセージングサービスを使用してデータフローを効率的に管理することが推奨されます。
まとめ：
- DynamoDB の書き込みキャパシティを増やす と Lambda にメモリを増やす ことで、エラーや遅延を減らすことができます。
- Kinesis を使用してデータをストリーム処理し、Lambda での負荷を分散させることが効率的です。
これらの知識を適用することで、データ処理のパフォーマンスを最適化し、エラーを減少させることができます。
実践
略
一問道場
問題 #485
あるユーティリティ企業が、スマートメーターから5分ごとに使用データを収集し、時間帯別メーター測定を行いたいと考えています。メーターがデータをAWSに送信すると、そのデータはAmazon API Gatewayに送られ、AWS Lambda関数によって処理され、Amazon DynamoDBテーブルに保存されます。パイロットフェーズでは、Lambda関数の実行には3～5秒かかりました。スマートメーターの数が増えると、エンジニアはLambda関数の実行時間が1～2分かかるようになったことに気づきました。さらに、新しいタイプのメトリクスがデバイスから収集されることで、実行時間が増加しています。DynamoDBでPUT操作を行う際に、多くのProvisionedThroughputExceededExceptionエラーが発生し、Lambdaからは多くのTooManyRequestsExceptionエラーが発生しています。
これらの問題を解決するためには、どの変更を行うべきですか？（2つ選んでください。）
- A. DynamoDBテーブルの書き込み容量単位を増やす。
- B. Lambda関数に割り当てるメモリを増やす。
- C. スマートメーターから送信するペイロードサイズを増やす。
- D. データをAmazon KinesisデータストリームにAPI Gatewayからストリーミングし、バッチで処理する。
- E. Amazon SQS FIFOキューでデータを収集し、各メッセージを処理するLambda関数をトリガーする。
解説
この問題では、Lambda関数の処理時間が増加し、DynamoDBやLambdaからのエラーが発生している状況に対応するため、適切な変更を選ぶ必要があります。具体的には、ProvisionedThroughputExceededExceptionエラー（DynamoDBでのスループット超過）やTooManyRequestsExceptionエラー（Lambda関数がリクエストに過負荷）に対処する方法を考えます。
選択肢ごとに解説します。
A. DynamoDBテーブルの書き込み容量単位を増やす
- 解説: DynamoDBでは、データの読み書きにプロビジョンドスループットが使用されます。このエラー（ProvisionedThroughputExceededException）は、DynamoDBの書き込み容量（Write Capacity Units）が不足している場合に発生します。スマートメーターが増えてデータ量が増加するため、DynamoDBの**書き込み容量単位（WCU）**を増加させることで、スループットを確保し、エラーを回避できます。
- 結論: この選択肢は、DynamoDBでのエラー解決に有効です。
B. Lambda関数に割り当てるメモリを増やす
- 解説: Lambda関数の実行時間が長くなる原因の一つとして、メモリ不足が考えられます。メモリを増やすことで、関数の実行速度が改善される可能性があります。Lambdaの処理が速くなることで、実行時間を短縮できるため、TooManyRequestsExceptionエラーを軽減する効果も期待できます。
- 結論: Lambda関数のメモリ増加は、処理の効率を上げ、エラーを減らすために有効です。
C. スマートメーターから送信するペイロードサイズを増やす
- 解説: ペイロードサイズを増加させることは、必ずしも問題を解決する方法ではありません。むしろ、ペイロードが大きくなると、処理にかかる時間が増え、Lambdaのタイムアウトやエラーが発生するリスクが高くなります。この場合、ペイロードサイズの増加は問題を悪化させる可能性があるため、適切な解決策ではありません。
- 結論: この選択肢は問題解決にはつながりません。
D. データをAmazon KinesisデータストリームにAPI Gatewayからストリーミングし、バッチで処理する
- 解説: Kinesisは、高スループットでデータをストリーム処理するためのサービスです。API Gatewayから直接Kinesisにデータを流し、Lambda関数でバッチ処理を行うことで、リクエストのスパイクを分散させることができます。これにより、DynamoDBの負荷を分散し、Lambda関数へのリクエストを効率的に処理できるようになります。
- 結論: Kinesisを利用することで、データ処理をバッチ化し、システム全体のスループットを向上させることができるため、適切な解決策です。
E. Amazon SQS FIFOキューでデータを収集し、各メッセージを処理するLambda関数をトリガーする
- 解説: Amazon SQS（Simple Queue Service）は、メッセージのキューイングに使用されます。SQS FIFO（First-In-First-Out）キューを使用すると、メッセージの順序を保証しつつ、バックエンドで並列処理を行うことができます。この方法を使用することで、Lambda関数の負荷を分散し、TooManyRequestsExceptionエラーを軽減できます。さらに、各メッセージを個別に処理できるため、処理の効率化が図れます。
- 結論: SQS FIFOキューを使うことで、Lambda関数の負荷を軽減し、エラーの発生を防ぐことができます。
最適な解決策
- A. DynamoDBテーブルの書き込み容量単位を増やす
- D. データをAmazon KinesisデータストリームにAPI Gatewayからストリーミングし、バッチで処理する
これらの選択肢を組み合わせることで、DynamoDBのスループット不足やLambdaの負荷を解消し、全体的なパフォーマンスを向上させることができます。
486-AWS SAP AWS 「理論・実践・一問道場」WorkSpacesディレクトリ
理論
高可用性とディザスタリカバリのためのAWSの設定
AWS で高可用性を実現するために、複数のリージョンにまたがるサービスやリソースを活用する方法があります。特に Amazon WorkSpaces のようなサービスを複数のリージョンに展開し、障害時に自動的に切り替えるためには、以下のポイントが重要です。
- 接続別名（Connection Alias）:
- Amazon WorkSpaces に接続する際、接続別名（DNS名）が使用されます。これを使って、ユーザーがどのリージョンの WorkSpaces に接続するかを決定します。
- Route 53 ルーティングポリシー:
- Route 53 は、AWS の DNS サービスで、トラフィックのルーティング方法を決定します。高可用性のために、以下のルーティングポリシーを使用できます：
- フェイルオーバールーティング: 主リージョンに障害が発生した際に、バックアップリージョンに自動的にトラフィックを切り替えます。Route 53 の健康チェック機能を使って、ターゲットの状態を監視し、問題が発生した場合に切り替えます。
- 加重ルーティングや複数値回答ルーティングもありますが、フェイルオーバーの場合は、フェイルオーバールーティングが最適です。
- 高可用性アーキテクチャ:
- 複数のリージョンで 接続別名 を設定し、それぞれのリージョンに WorkSpaces ディレクトリ を配置することで、障害発生時にトラフィックを別リージョンに切り替えることが可能です。
まとめ:
- Amazon WorkSpaces の高可用性を確保するために、Route 53 のフェイルオーバールーティングポリシー を活用して、複数リージョンでの接続別名とディレクトリを管理します。これにより、リージョン間の障害発生時でも、ユーザーは引き続き仮想デスクトップを使用できるようになります。
実践
略
一問道場
ある企業は最近、Amazon WorkSpaces の概念実証を成功に完了しました。ソリューションアーキテクトは、ソリューションを2つのAWSリージョンにまたがって高可用性にする必要があります。Amazon WorkSpacesはフェイルオーバー用のリージョンにデプロイされ、Amazon Route 53にホストゾーンが設定されています。このソリューションの高可用性を構成するために、ソリューションアーキテクトは何をすべきでしょうか？
- A. プライマリリージョンとフェイルオーバーリージョンに接続エイリアスを作成します。接続エイリアスをそれぞれのリージョンのディレクトリに関連付けます。Route 53 にフェイルオーバールーティングポリシーを設定し、「Evaluate Target Health」を「Yes」にします。
- B. プライマリリージョンとフェイルオーバーリージョンに接続エイリアスを作成します。接続エイリアスをプライマリリージョンのディレクトリに関連付けます。Route 53 のマルチバリューアンサー・ルーティングポリシーを設定します。
- C. プライマリリージョンに接続エイリアスを作成します。接続エイリアスをプライマリリージョンのディレクトリに関連付けます。Route 53 にウェイテッド・ルーティングポリシーを設定します。
- D. プライマリリージョンに接続エイリアスを作成し、接続エイリアスをフェイルオーバーリージョンのディレクトリに関連付けます。Route 53 にフェイルオーバールーティングポリシーを設定し、「Evaluate Target Health」を「Yes」にします。
解説
この問題は、Amazon WorkSpaces を 複数の AWS リージョンで高可用性 を実現するために、適切な Route 53 の設定 を選択する問題です。目的は、主リージョンに障害が発生した際に、WorkSpaces をバックアップリージョンに切り替えることです。
解説:
- 接続別名（connection alias） は、WorkSpaces に接続するための DNS 名です。これにより、クライアントはどのリージョンの WorkSpaces に接続するかを決定します。
- Route 53 のルーティングポリシー で高可用性を実現します。複数のリージョン間で障害時に自動でトラフィックを切り替えるため、以下の設定が有効です。
正解: A.
- 接続別名を主リージョンとバックアップリージョンに作成し、ディレクトリに関連付け。その後、Route 53 のフェイルオーバールーティングポリシーを使用して、高可用性を実現します。この設定により、主リージョンに障害が発生した場合、Route 53 はバックアップリージョンに自動的にトラフィックを切り替えます。
他の選択肢について:
- B, C, D は、主にロードバランシングや異なるルーティング方法を使用しますが、フェイルオーバーに関しては最適ではないため、Aが最適です。
要点としては、Route 53 でフェイルオーバー設定を行い、複数リージョンにまたがる接続を構成することが重要です。
487-AWS SAP AWS 「理論・実践・一問道場」AWS Application Discovery Service Agentless Collector
理論
AWSへの移行を成功させるためには、オンプレミス環境の評価、アプリケーション依存関係の可視化、そして移行後の最適化をしっかり行うことが重要です。これに関して、以下のツールとアプローチが役立ちます：
- AWS Migration Evaluator (旧TSO Logic)
移行計画を立てるために、コスト削減やリソース最適化に役立つ評価を提供します。オンプレミスの環境を評価し、最適なAWSリソースに対する推奨事項を提供します。
- AWS Application Discovery Service
オンプレミスのアプリケーションとサーバーの依存関係を可視化するツールです。エージェントレスの「Agentless Collector」とエージェントを使用する方法（「Application Discovery Agent」）の2種類があります。
- AWS Migration Hub
移行プロジェクトの管理を支援するサービスで、アプリケーション依存関係の視覚化や進行状況の追跡が可能です。
- Amazon QuickSight
データを可視化するためのBIツールで、AWS環境への移行後のパフォーマンス分析やコスト分析を行います。
汎用的なアプローチ：
- 移行前評価：オフライン環境やオンプレミスのVMの性能を調査し、AWSのインスタンスにどれが最適かを評価する。
- 依存関係の可視化：アプリケーションの依存関係を把握することで、移行のリスクを最小化し、最適な移行手順を計画できる。
- ツールの選択：エージェントレスオプションを選択することで、運用負荷を減らし、より迅速にデータを収集・分析できる。
これらを駆使することで、AWSへの移行をスムーズかつコスト効率よく実施できます。
以下は、エージェントとエージェントレスの比較表です：
特徴 | エージェント | エージェントレス |
インストール | 各VMにインストールが必要 | インストール不要 |
運用負荷 | 高い（インストール・管理が必要） | 低い（インストール不要、簡便） |
データ収集の詳細度 | 高い（アプリ依存関係、リソース使用など詳細） | 低い（基本的なメトリックのみ収集可能） |
セキュリティ制約 | 制限される場合あり（管理者権限が必要） | 制限されにくい（インストール不要） |
使用例 | AWS Application Discovery Agent | AWS Application Discovery Service Agentless Collector |
利点 | 詳細な分析が可能、リソース使用状況も把握 | インストール不要、運用負荷が少ない |
欠点 | インストールと管理の手間、運用負荷が大きい | 詳細なデータ収集が難しい、ネットワーク制約あり |
実践
略
一問道場
ある企業が、オンプレミス環境からAWSへの多数のVMの移行を計画しています。企業は、移行前にオンプレミス環境の初期評価、VM上で実行されるアプリケーション間の依存関係の可視化、およびオンプレミス環境の評価レポートを必要としています。この情報を得るために、企業はMigration Evaluator評価リクエストを開始しました。企業は、オンプレミス環境にコレクターソフトウェアをインストールする制約がなく、インストールする能力を持っています。
最も運用負荷が少なく、必要な情報を提供するソリューションはどれですか？
A. オンプレミスの各VMにAWS Application Discovery Agentをインストールします。データ収集期間が終了した後、AWS Migration Hubを使用してアプリケーションの依存関係を表示し、Quick Insights評価レポートをMigration Hubからダウンロードします。
B. オンプレミスの各VMにMigration Evaluator Collectorをインストールします。データ収集期間が終了した後、Migration Evaluatorを使用してアプリケーションの依存関係を表示し、発見されたサーバーリストをエクスポートしてAmazon QuickSightにアップロードします。QuickSightレポートが生成されたら、Quick Insights評価レポートをダウンロードします。
C. オンプレミス環境にAWS Application Discovery Service Agentless Collectorをセットアップします。データ収集期間が終了した後、AWS Migration Hubを使用してアプリケーションの依存関係を表示し、Application Discovery Serviceから発見されたサーバーリストをエクスポートします。そのリストをMigration Evaluatorにアップロードし、Migration Evaluatorレポートが生成されたらQuick Insights評価レポートをダウンロードします。
D. オンプレミス環境にMigration Evaluator Collectorをセットアップし、各VMにAWS Application Discovery Agentをインストールします。データ収集期間が終了した後、AWS Migration Hubを使用してアプリケーションの依存関係を表示し、Quick Insights評価レポートをMigration Evaluatorからダウンロードします。
解説
正解は C です。
理由:
- C は、最も運用負荷が少なく、必要な情報を提供する方法です。
- このオプションでは、AWS Application Discovery Service Agentless Collectorを使用してオンプレミス環境のデータを収集し、依存関係を可視化します。Agentless Collectorは、ソフトウェアのインストールを必要とせず、ネットワークトラフィックやVMの動作を監視して情報を収集します。
- 収集したデータをAWS Migration Hubで表示し、その後、Migration Evaluatorにデータをアップロードして、Quick Insights評価レポートをダウンロードできます。
他のオプションの問題点:
- A はAWS Application Discovery AgentをVMごとにインストールする必要があり、VM数が多いと手間がかかります。
- B では、Migration Evaluator Collectorをインストールする必要があり、その後、QuickSightを使用してレポートを生成する必要があり、追加の操作が増えます。
- D では、Migration Evaluator CollectorとAWS Application Discovery Agentの両方をインストールする必要があり、手間が増えます。
したがって、C が最も効率的で運用負荷が少ない選択肢です。
488-AWS SAP AWS 「理論・実践・一問道場」Amazon Inspector レガシー API
理論
AWS のセキュリティ強化に関連する主要なサービスについて、以下のような汎用的な知識を持っておくと役立ちます：
- AWS WAF (Web Application Firewall)
- API Gateway や ALB（Application Load Balancer）を通じて、DoS（サービス拒否）攻撃や悪意のあるリクエストを防ぐために使用します。
- SQL インジェクションやクロスサイトスクリプティング（XSS）などの攻撃から保護する機能もあります。
- Amazon Inspector
- Amazon EC2 インスタンスやコンテナの脆弱性を検出するための自動化されたサービスです。
- セキュリティベストプラクティスに基づいた評価を提供し、システムのリスクを把握できます。
- レガシー API や EC2 インスタンスで動作するアプリケーションのセキュリティ診断に使用されます。
- Amazon GuardDuty
- AWS 環境内での脅威検出サービスで、マルウェア感染、異常なアクティビティ、不正アクセスを監視します。
- 自動的に攻撃や不正アクセスの兆候を検出し、アラートを発信します。防御機能は持ちませんが、他のサービス（例：AWS WAF や IAM ロール）と連携して対応します。
これらのサービスは、AWS 上でアプリケーションや API のセキュリティを向上させるために非常に重要です。WAF でアクセス制御を強化し、Inspector で脆弱性を発見し、GuardDuty でリアルタイムに不正アクセスを監視することが基本的なセキュリティ戦略です。
実践
略
一問道場
質問 #488
ある企業は、Amazon API Gateway API と AWS Lambda 関数を使用して、主要な API を AWS 上でホストしています。この企業の内部アプリケーションは、API を使用してコア機能やビジネスロジックを実行しています。また、顧客も API を使用して自分のアカウントのデータにアクセスしています。いくつかの顧客は、単一のスタンドアロン Amazon EC2 インスタンスで実行されているレガシー API にもアクセスしています。
企業は、これらの API のセキュリティを強化して、サービス拒否（DoS）攻撃を防ぎ、脆弱性をチェックし、一般的な悪用から守りたいと考えています。
ソリューションアーキテクトは、この要件を満たすために何をすべきですか？
A. AWS WAF を使用して両方の API を保護します。Amazon Inspector を使用してレガシー API を分析します。Amazon GuardDuty を使用して、API への不正アクセスの試みを監視します。
B. AWS WAF を使用して API Gateway API を保護します。Amazon Inspector を使用して両方の API を分析します。Amazon GuardDuty を使用して、不正アクセスの試みをブロックします。
C. AWS WAF を使用して API Gateway API を保護します。Amazon Inspector を使用してレガシー API を分析します。Amazon GuardDuty を使用して、API への不正アクセスの試みを監視します。
D. AWS WAF を使用して API Gateway API を保護します。Amazon Inspector を使用してレガシー API を保護します。Amazon GuardDuty を使用して、不正アクセスの試みをブロックします。
解説
この質問は、AWS 上の API をセキュリティ強化するために使用すべきサービスに関するものです。特に、DoS（サービス拒否）攻撃の防止、脆弱性チェック、および一般的な悪用からの保護を目的としています。選択肢に対する解説を以下に示します。
選択肢 A:
AWS WAF を使用して両方の API を保護し、Amazon Inspector を使用してレガシー API を分析し、Amazon GuardDuty を使用して不正アクセスの試みを監視する。
- AWS WAF は API Gateway に対して有効ですが、レガシー API（EC2 インスタンス上の API）に対しては直接適用できません。したがって、両方の API を保護するためには不十分です。
- Amazon Inspector は、EC2 インスタンス上の API の脆弱性を分析するために使用できますが、GuardDuty は不正アクセスを監視するのみで、攻撃を防ぐことはできません。
- 結論: この選択肢は要件に完全に一致していません。
選択肢 B:
AWS WAF を使用して API Gateway API を保護し、Amazon Inspector を使用して両方の API を分析し、Amazon GuardDuty を使用して不正アクセスをブロックする。
- Amazon GuardDuty は、セキュリティの脅威や不正アクセスを監視するサービスであり、攻撃をブロックする機能はありません。
- 結論: GuardDuty が不正アクセスを「ブロックする」ことはできないため、この選択肢は不適切です。
選択肢 C:
AWS WAF を使用して API Gateway API を保護し、Amazon Inspector を使用してレガシー API を分析し、Amazon GuardDuty を使用して不正アクセスの試みを監視する。
- AWS WAF は、API Gateway API に対して有効で、DoS 攻撃やその他の悪用から守るために使用できます。
- Amazon Inspector はレガシー API の脆弱性を分析できます。
- Amazon GuardDuty は、不正アクセスの試みを監視するための適切なサービスです。
- 結論: この選択肢は、監視と分析の要件に適合しており、最も適切です。
選択肢 D:
AWS WAF を使用して API Gateway API を保護し、Amazon Inspector を使用してレガシー API を保護し、Amazon GuardDuty を使用して不正アクセスをブロックする。
- Amazon GuardDuty は攻撃を監視し、警告を提供しますが、攻撃を自動的にブロックする機能はありません。
- 結論: GuardDuty が攻撃をブロックすることはできないため、この選択肢も不適切です。
正解は C です:
- AWS WAF で API Gateway の API を保護し、Amazon Inspector でレガシー API の脆弱性を分析し、Amazon GuardDuty で不正アクセスの試みを監視します。この構成が最も要件に適合し、効果的にセキュリティを強化できます。
489-AWS SAP AWS 「理論・実践・一問道場」プロビジョニングされた同時実行数
理論
AWS Lambda のパフォーマンス改善とスケーラビリティに関連する知識
- AWS Lambda とデータベース接続
- Lambda 関数は短期間で実行されるため、データベース接続の確立と切断のオーバーヘッドがパフォーマンスに影響を与えることがあります。特に、頻繁にデータベース接続を開いたり閉じたりする場合、遅延が発生しやすいです。
- RDS Proxy
- RDS Proxy は、データベース接続をプールするサービスで、Lambda 関数と RDS インスタンス間の接続を効率的に管理します。これにより、接続の再利用が促進され、接続の数が制限されることで、スケーラビリティとレイテンシーが向上します。
- RDS Proxy を使用することで、データベースの接続数が急増した場合でも安定したパフォーマンスを維持できます。
- Secrets Manager
- Secrets Manager は、データベースの認証情報（ユーザー名、パスワードなど）を安全に管理するサービスです。これを Lambda 関数や RDS Proxy と連携させることで、認証情報をセキュアに扱うことができます。
- Lambda の同時実行数
- プロビジョニングされた同時実行数は、指定した数だけ Lambda 関数を予め準備することで、トラフィックの急増に迅速に対応できます。Lambda がリクエストを処理するためのリソースをあらかじめ確保する方法です。
- 予約済み同時実行数は、特定のリソース数を確保するために使いますが、トラフィックが急激に増加した場合に最も効果的な方法は、プロビジョニングされた同時実行数の利用です。
- スケーラブルなアーキテクチャ
- サーバーレスアーキテクチャでは、RDS Proxy や AWS Lambda のスケーリング機能（プロビジョニングされた同時実行数、インスタンスのオートスケーリング）を活用して、トラフィックの急増に対応します。接続プールを管理し、動的にスケーリングすることで、システム全体のレイテンシーを最小化できます。
まとめ
- RDS Proxy と Secrets Manager を活用することで、Lambda 関数のデータベース接続の効率化が可能となり、トラフィックの急増に対応するための最適な方法になります。
以下は、プロビジョニングされた同時実行数と予約済み同時実行数の違いを簡潔に表形式でまとめたものです。
項目 | プロビジョニングされた同時実行数 | 予約済み同時実行数 |
目的 | 特定の数の Lambda インスタンスを常に稼働させ、即時にリクエストを処理できるようにする | 必要に応じて特定のインスタンス数を確保し、リソースを管理する |
スケーリング | トラフィック急増時にすぐに対応可能 | リソース確保のため、一定の同時実行数を予め予約する |
使用ケース | 高いスループットや低レイテンシーを求める場合に適している | 使用量が予測できるが、リソースの競合を避けたい場合に適している |
リソース管理 | 常に確保した同時実行数に対して課金される | 必要な時にだけリソースを確保し、コストを抑えることができる |
料金 | 固定料金が発生 (指定した同時実行数分) | 必要に応じて予約する料金が発生 (同時実行数に対する割引がある場合あり) |
まとめ:
- プロビジョニングされた同時実行数は、指定した数のインスタンスを常に稼働させ、即時に対応するためのもの。
- 予約済み同時実行数は、必要なインスタンス数を確保して、トラフィックに対応するためのリソースを管理する方法です。
実践
略
一問道場
質問 #489
ある企業は、AWS 上でサーバーレスの電子商取引アプリケーションを運営しています。アプリケーションは、Amazon API Gateway を使用して AWS Lambda Java 関数を呼び出します。Lambda 関数は、データを格納するために Amazon RDS for MySQL データベースに接続します。
最近のセールイベント中、急激なウェブトラフィックの増加により、API のパフォーマンス低下とデータベース接続の失敗が発生しました。企業は、Lambda 関数のレイテンシーを最小限に抑え、トラフィックの急増に対応するソリューションを実装する必要があります。
最小限の変更でこれらの要件を満たすソリューションはどれですか？
A. Lambda 関数のコードを更新して、Lambda 関数が関数ハンドラーの外でデータベース接続を開くようにします。Lambda 関数のプロビジョニングされた同時実行数を増加させます。
B. データベース用に RDS Proxy エンドポイントを作成します。データベースのシークレットを AWS Secrets Manager に格納します。必要な IAM 権限を設定します。Lambda 関数を更新して、RDS Proxy エンドポイントに接続します。Lambda 関数のプロビジョニングされた同時実行数を増加させます。
C. カスタムパラメーターグループを作成します。max_connections パラメーターの値を増加させます。カスタムパラメーターグループを RDS DB インスタンスに関連付け、再起動をスケジュールします。Lambda 関数の予約済み同時実行数を増加させます。
D. データベース用に RDS Proxy エンドポイントを作成します。データベースのシークレットを AWS Secrets Manager に格納します。必要な IAM 権限を設定します。Lambda 関数を更新して、RDS Proxy エンドポイントに接続します。Lambda 関数の予約済み同時実行数を増加させます。
解説
この問題は、Lambda 関数のレイテンシーの最小化と、急増するトラフィックに対応するためのソリューションを選択するものです。特に、データベース接続の問題を解決することが重要です。
各選択肢の解説
選択肢 A:
- Lambda 関数のコードを更新して、関数ハンドラーの外でデータベース接続を開く → これにより、接続の再利用はできますが、接続のスケーリング問題は解決できません。
- プロビジョニングされた同時実行数を増加させる → 同時実行数を増やすことで、より多くのリクエストに対応できますが、接続数の管理やスケーラビリティ問題は解決しません。
結論: このアプローチは接続の効率的な管理に関して不十分です。
選択肢 B:
- RDS Proxy エンドポイントを作成し、Secrets Manager でデータベースのシークレットを管理する → RDS Proxy はデータベース接続プールを提供し、Lambda 関数の接続数を効率的に管理できます。これにより、急増するトラフィックへの対応が可能になります。
- 必要な IAM 権限を設定し、Lambda 関数を RDS Proxy に接続 → これにより、セキュアに接続情報を管理できます。
- プロビジョニングされた同時実行数を増加させる → 高い同時実行数を確保することで、急増するリクエストに対してスケーラブルな対応が可能です。
結論: この方法は、接続の効率化とスケーラビリティの両方を解決し、最適な選択肢です。
選択肢 C:
- max_connections パラメーターを増加させる → これにより、RDS インスタンスが許可する接続数は増えますが、Lambda 関数が作成する接続数を管理する方法は提供されません。
- Lambda 関数の予約済み同時実行数を増加させる → 予約同時実行数を増加させることは Lambda のスケーラビリティを向上させますが、接続数の管理には役立ちません。
結論: 接続数の増加は一時的な対策であり、根本的な接続管理の問題は解決しません。
選択肢 D:
- RDS Proxy エンドポイントを作成し、Secrets Manager でデータベースのシークレットを管理する → これにより、データベース接続の管理が効率化されます。
- 予約済み同時実行数を増加させる → 予約済み同時実行数の増加はトラフィックに対応しますが、プロビジョニングされた同時実行数の方が急増するリクエストに柔軟に対応できます。
- 予約済み同時実行数を増加させることで、予測可能なトラフィックの増加に備えることができますが、急激な増加に対応するにはプロビジョニングされた同時実行数の方が効果的です。
結論: 予約済み同時実行数の増加では、トラフィックの急増に十分に対応できない可能性があります。
正解は B です:
- RDS Proxy による接続プール管理と、プロビジョニングされた同時実行数の増加を組み合わせることで、急増するトラフィックと接続管理の問題に効果的に対処できます。
490-AWS SAP AWS 「理論・実践・一問道場」プライベートDNSオプション
理論
インターフェイスエンドポイント (Interface Endpoint)
- 概要: AWSサービス（S3やDynamoDBなど）へのプライベート接続を提供するVPC内のエンドポイント。
- 特徴:
- サービスにアクセスする際にプライベートIPアドレスを使用。
- VPC内のリソースからAWSサービスへ、インターネットを経由せず、プライベートに通信できる。
プライベートDNSオプション
- 概要: VPC内のインターフェイスエンドポイントに関連付けられたDNS解決を、プライベートIPアドレスに変更するオプション。
- 重要性:
- 通常、AWSサービスのDNS名はパブリックIPアドレスに解決されるが、プライベートDNSオプションを有効にすることで、VPC内からアクセスする際にプライベートIPアドレスに解決される。
- 内部アプリケーションがAWSサービスに接続する場合に、プライベート接続が保証される。
設定方法
- インターフェイスエンドポイント作成時に、プライベートDNSオプションを有効にする。
- これにより、サービス名がプライベートIPアドレスに解決され、内部アプリケーションがインターフェイスエンドポイントを通じてAWSサービスに接続できる。
利点
- セキュリティ: データがインターネットを経由せず、VPC内で完結するため、セキュリティが向上。
- パフォーマンス: パブリックインターネット経由の通信に比べて、遅延が少なく安定した接続が可能。
注意点
- プライベートDNSオプションが無効になっていると、サービス名がパブリックIPアドレスに解決され、VPC内のリソースからインターフェイスエンドポイントに接続できなくなる。
これらの設定を理解しておくことで、AWSのプライベート接続に関する問題を効果的に解決できます。
実践
略
一問道場
企業は、すべての内部アプリケーション接続にプライベートIPアドレスを使用することを要求しています。このポリシーを実現するために、ソリューションアーキテクトは、AWSのパブリックサービスに接続するためのインターフェイスエンドポイントを作成しました。テストの結果、サービス名がパブリックIPアドレスに解決され、内部サービスがインターフェイスエンドポイントに接続できないことが分かりました。
この問題を解決するためにソリューションアーキテクトが取るべき手順はどれですか？
A. サブネットのルートテーブルにインターフェイスエンドポイントへのルートを追加する。
B. VPC属性でプライベートDNSオプションを有効にする。
C. インターフェイスエンドポイントのセキュリティグループを設定して、AWSサービスへの接続を許可する。
D. Amazon Route 53のプライベートホステッドゾーンを設定し、内部アプリケーション用に条件付きフォワーダーを設定する。
解説
この問題は、内部アプリケーションがAWSのパブリックサービスに接続する際、プライベートIPアドレスを使用する必要があるというシナリオです。ソリューションアーキテクトがインターフェイスエンドポイントを作成しましたが、テストの結果、サービス名がパブリックIPアドレスに解決され、内部サービスがインターフェイスエンドポイントに接続できないという問題が発生しています。
解説
インターフェイスエンドポイントとプライベートDNS
AWSでは、インターフェイスエンドポイントを利用してAWSのパブリックサービスとプライベート接続を確立することができます。インターフェイスエンドポイントを使うと、接続するサービスはプライベートIPアドレスを使用して通信します。しかし、インターフェイスエンドポイントが正常に機能するためには、VPC内でのDNS解決に関する設定が必要です。特に、プライベートDNSオプションを有効にすることが重要です。
プライベートDNSオプションを有効にすると、VPC内のリソースがインターフェイスエンドポイントを通じてサービスにアクセスする際に、DNS名がプライベートIPアドレスに解決されるようになります。これにより、サービス名がパブリックIPアドレスに解決される問題が解消され、内部アプリケーションがインターフェイスエンドポイントに接続できるようになります。
選択肢の分析
A. サブネットのルートテーブルにインターフェイスエンドポイントへのルートを追加する
インターフェイスエンドポイントへのルートは通常、VPCのルートテーブルに自動的に追加されます。手動で追加する必要は基本的にはありません。この選択肢は問題の解決には関係しません。
B. VPC属性でプライベートDNSオプションを有効にする
この選択肢が正解です。プライベートDNSオプションを有効にすることで、インターフェイスエンドポイントを通じてアクセスするサービスのDNS名が、プライベートIPアドレスに解決されるようになります。これにより、内部サービスがプライベートIPアドレスでAWSのパブリックサービスにアクセスできるようになります。
C. インターフェイスエンドポイントのセキュリティグループを設定して、AWSサービスへの接続を許可する
インターフェイスエンドポイント自体のセキュリティグループ設定が必要な場合がありますが、DNS解決の問題とは直接関係ありません。セキュリティグループは通信の許可/拒否を管理しますが、この問題の解決には関与しません。
D. Amazon Route 53のプライベートホステッドゾーンを設定し、内部アプリケーション用に条件付きフォワーダーを設定する
Route 53のプライベートホステッドゾーンや条件付きフォワーダーはDNS解決に関連しますが、インターフェイスエンドポイントと関連する問題を解決する方法としては適切ではありません。プライベートDNSオプションを有効にすることで、直接的に解決できます。
結論
問題の解決策は、B. VPC属性でプライベートDNSオプションを有効にするです。これにより、インターフェイスエンドポイントを使用してAWSサービスにアクセスする際に、DNS名が正しくプライベートIPアドレスに解決されます。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/17cd7ae8-88e2-80f5-a62f-d45b2163cb8a
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
