type
status
date
slug
summary
tags
category
icon
password
书籍
111-IAMデータベース認証
理論
1. IAMデータベース認証 (IAM Database Authentication)
IAMデータベース認証は、AWSにおけるセキュリティ機能の一つで、データベースへのアクセスにおいて、従来のユーザー名とパスワードの認証方法の代わりに、IAMユーザーやロールを用いて認証を行う方法です。この方法により、データベース認証情報を直接コードや設定に埋め込むことなく、安全にアクセスを制御できます。
利点:
- セキュリティ向上: IAMデータベース認証は、認証情報が永続的に保存されることなく、IAMポリシーを使ってアクセス制御を行うため、パスワードの漏洩リスクを減らすことができます。
- パスワード管理の簡素化: AWSは自動的にIAMのロールに基づいてデータベース認証を管理し、認証情報を定期的に更新することができます。
使用条件:
- IAMデータベース認証は、Amazon Aurora (MySQLおよびPostgreSQL)で利用できます。データベースのIAM設定を有効にし、アクセス権限をIAMポリシーで管理します。
2. Secrets ManagerとParameter Store
Secrets ManagerやSystems Manager Parameter Storeは、アプリケーションの認証情報やAPIキー、データベースのパスワードなどの機密情報を安全に保存し、管理するためのAWSサービスです。これらのサービスを利用することで、認証情報の漏洩リスクを低減し、パスワードのローテーションを自動化することができます。
Secrets Manager vs Parameter Store:
- Secrets Manager: より高度な機能を提供し、認証情報のローテーションを自動化できます。特に機密情報を扱う場合に推奨されます。
- Parameter Store: よりシンプルでコストが低い選択肢です。認証情報を保存できますが、Secrets Managerほどの機能はありません。
3. VPCエンドポイント (VPC Endpoints)
VPCエンドポイントは、AWSのサービスへのプライベート接続を提供し、インターネット経由でデータを転送しないようにするための機能です。これにより、セキュアな通信が可能になり、データがインターネットに流れることなくAWSサービスにアクセスできます。
VPCエンドポイントの種類:
- ゲートウェイVPCエンドポイント: S3やDynamoDBのような特定のAWSサービスとVPC内でプライベートに接続できます。
- インターフェイスVPCエンドポイント: 他のAWSサービスへの接続に使われ、ネットワークインターフェースとして提供されます。
4. KMS (AWS Key Management Service)とS3の暗号化
AWS KMSは、データの暗号化を簡単に管理するためのサービスで、S3などのAWSサービスと連携して、データを保存・転送中に暗号化することができます。S3の暗号化設定では、SSE-KMSを利用して、データが自動的に暗号化され、KMSで管理されます。
SSE-KMS (Server-Side Encryption with KMS Keys):
SSE-KMSは、S3に保存するデータを暗号化し、AWS KMSで管理されるカスタムの暗号化キーを使用することで、データの安全性を高めます。
5. データ転送の暗号化
データ転送時にHTTPSを強制することは、インターネット経由で送信されるデータを暗号化するために必要なセキュリティ対策です。これにより、データの盗聴や改竄を防ぎます。AWSでは、S3へのデータアップロードやLambda関数とS3の連携を行う際、HTTPSを使用することが推奨されます。
6. 認証情報管理とセキュリティ
セキュリティのベストプラクティスとして、認証情報の管理方法は非常に重要です。IAMデータベース認証やSecrets Manager、Parameter Storeなどを使用することで、認証情報を安全に取り扱い、漏洩を防ぐことができます。また、パスワードローテーションを定期的に実施することも、セキュリティを高めるために重要です。
本質的知識のまとめ:
- IAMデータベース認証を使用すると、Lambda関数やその他のAWSリソースが直接IAMロールを通じてデータベースにアクセスでき、認証情報をコード内に含める必要がなくなります。
- Secrets ManagerやParameter Storeを使用して認証情報を安全に管理し、自動ローテーションを設定することで、認証情報漏洩のリスクを最小限に抑えることができます。
- VPCエンドポイントとHTTPSを使用することで、インターネット経由のデータ転送を防ぎ、データを安全に扱うことができます。
- AWS KMSを利用したS3の暗号化により、保存中のデータの安全性を確保できます。
これらの知識を統合することで、AWS環境におけるセキュリティ要件を満たすことができ、企業の情報資産を守るための強固な基盤を構築することができます。
一問道場
質問 #111
トピック 1
ソリューションアーキテクトが、ある企業のAWS Lambda関数のセキュリティ設定を監査しています。このLambda関数は、Amazon Auroraデータベースから最新の変更内容を取得します。Lambda関数とデータベースは同じVPC内で実行されています。Lambda環境変数がデータベースの認証情報をLambda関数に提供しています。Lambda関数はデータを集約し、そのデータをAmazon S3バケットに格納します。このバケットは、AWS KMS管理の暗号化キー(SSE-KMS)を使用してサーバー側で暗号化されています。データはインターネットを経由して移動しない必要があります。データベース認証情報が漏洩した場合、企業はその影響を最小限に抑えるソリューションを必要としています。
これらの要件を満たすためにソリューションアーキテクトが推奨するべき解決策はどれですか？
A. Aurora DBクラスターでIAMデータベース認証を有効にします。Lambda関数のIAMロールを変更して、IAMデータベース認証を使用してデータベースにアクセスできるようにします。VPC内でAmazon S3用のゲートウェイVPCエンドポイントを展開します。
B. Aurora DBクラスターでIAMデータベース認証を有効にします。Lambda関数のIAMロールを変更して、IAMデータベース認証を使用してデータベースにアクセスできるようにします。データ転送中にAmazon S3への接続でHTTPSを強制します。
C. データベース認証情報をAWS Systems Manager Parameter Storeに保存します。Parameter Storeで認証情報のパスワードローテーションを設定します。Lambda関数のIAMロールを変更して、Lambda関数がParameter Storeにアクセスできるようにします。Lambda関数を変更して、認証情報をParameter Storeから取得するようにします。VPC内でAmazon S3用のゲートウェイVPCエンドポイントを展開します。
D. データベース認証情報をAWS Secrets Managerに保存します。Secrets Managerで認証情報のパスワードローテーションを設定します。Lambda関数のIAMロールを変更して、Lambda関数がSecrets Managerにアクセスできるようにします。Lambda関数を変更して、認証情報をSecrets Managerから取得するようにします。データ転送中にAmazon S3への接続でHTTPSを強制します。
解説
「データはインターネットを経由して移動しない必要があります」という要件に基づいて、正解は A です。
理由：
- VPC内でAmazon S3用のゲートウェイVPCエンドポイントを展開することで、データがインターネットを経由することなく、プライベートネットワーク内で安全にS3に転送されます。ゲートウェイVPCエンドポイントを使用することにより、S3への通信がVPC内で完結し、インターネットに出ることはありません。
各選択肢の分析：
- A. Aurora DBクラスターでIAMデータベース認証を有効にします。Lambda関数のIAMロールを変更して、IAMデータベース認証を使用してデータベースにアクセスできるようにします。VPC内でAmazon S3用のゲートウェイVPCエンドポイントを展開します。
- 正解: IAMデータベース認証を使用して、認証情報をLambda関数内に埋め込むことなく安全に管理し、またVPCエンドポイントを使用してデータがインターネットを経由しないようにします。
- B. Aurora DBクラスターでIAMデータベース認証を有効にします。Lambda関数のIAMロールを変更して、IAMデータベース認証を使用してデータベースにアクセスできるようにします。データ転送中にAmazon S3への接続でHTTPSを強制します。
- 誤り: HTTPSを強制することはデータ転送のセキュリティを確保するために重要ですが、インターネットを経由する可能性があります。この選択肢では、インターネットを経由しないという要件に完全に一致しません。
- C. データベース認証情報をAWS Systems Manager Parameter Storeに保存します。Parameter Storeで認証情報のパスワードローテーションを設定します。Lambda関数のIAMロールを変更して、Lambda関数がParameter Storeにアクセスできるようにします。Lambda関数を変更して、認証情報をParameter Storeから取得するようにします。VPC内でAmazon S3用のゲートウェイVPCエンドポイントを展開します。
- 誤り: Parameter Storeを使って認証情報を管理するのは良い方法ですが、データの転送に関するインターネット経由の要件には関係ありません。この選択肢の構成は認証情報管理の部分で有効ですが、要件に完全に一致するかというと、VPCエンドポイントの利用に加えた認証情報の取り扱い方法が不完全です。
- D. データベース認証情報をAWS Secrets Managerに保存します。Secrets Managerで認証情報のパスワードローテーションを設定します。Lambda関数のIAMロールを変更して、Lambda関数がSecrets Managerにアクセスできるようにします。Lambda関数を変更して、認証情報をSecrets Managerから取得するようにします。データ転送中にAmazon S3への接続でHTTPSを強制します。
- 誤り: Secrets Managerで認証情報を管理すること自体は良いですが、HTTPSを強制することでデータがインターネットを経由する可能性があります。この選択肢も要件には完全に一致しません。
したがって、A が正解です。
112-IAMポリシー EC2インスタンスタイプ
理論
1. IAMポリシーの基本概念
IAMポリシーは、AWSリソースへのアクセスを制御するためのルールセットです。ポリシーは以下を基に構成されます：
- Effect: アクションを許可するか拒否する（
AllowまたはDeny）。
- Action: 許可または拒否する操作（例:
ec2:RunInstances）。
- Resource: 操作対象のAWSリソース（例: 特定のEC2インスタンスやIAMロール）。
- Condition: 特定の条件が満たされた場合にのみポリシーを適用。
2. EC2インスタンスタイプを制御するIAMポリシーの設計
特定のインスタンスタイプのみを許可するIAMポリシーを作成することで、意図しない高コストのインスタンスの起動を防げます。以下は、許可されたインスタンスタイプ以外の起動を拒否する例です：
ポリシー例
ポイント
- EffectがDeny
デフォルトで全ての操作が許可されているAWS環境において、明示的に拒否ルールを設定します。
- ConditionのStringNotEqualsIfExists
条件式で指定されたインスタンスタイプ（ここでは
t3.microとt3.small）以外のインスタンス起動を拒否します。- 柔軟性
必要に応じてリストに新しいインスタンスタイプを追加することで、許可範囲を調整可能です。
3. 使用シナリオとメリット
シナリオ
- 開発者のテスト環境: 開発者が自由にインスタンスを起動する環境で、高コストなインスタンスの誤起動を防ぐ。
- コスト最適化: 大規模な環境でコスト管理が課題となっている場合に役立つ。
メリット
- コスト管理: 高額なインスタンスタイプの誤起動を未然に防止。
- セキュリティ: 必要以上のリソース消費を制限し、予期せぬトラフィックやアクセスを抑制。
- 運用効率の向上: 適切なリソース制限により、AWS環境の管理が容易に。
4. ポリシー適用のベストプラクティス
- 最小特権の原則
必要最小限のアクセス権を与えることで、不必要な操作を防ぎます。
- グループ単位での適用
IAMユーザーではなく、IAMグループにポリシーを適用することで管理効率を向上。
- テスト環境での検証
実際の適用前にテスト環境でポリシーが期待通りに機能することを確認。
- ポリシードキュメントのバージョン管理
ポリシーを更新した際にバージョン管理を行い、変更履歴を記録します。
5. 追加の補助ツール
AWS Config
- 目的: 環境全体のリソース設定がポリシーに準拠しているかを監視。
- 使用例: インスタンスタイプの制御が設定されていることを継続的に検証。
AWS Cost Explorer
- 目的: コスト分析を行い、非効率なリソース使用を特定。
- 使用例: ポリシー導入後のコスト削減効果を可視化。
6. 結論
IAMポリシーを使用したインスタンスタイプの制御は、AWS環境におけるコスト最適化と運用効率化の重要な手段です。適切なポリシー設計と運用を組み合わせることで、安全で効果的なAWSリソース管理を実現できます。
一問道場
質問 #112
トピック 1
ある大規模なモバイルゲーム企業は、オンプレミスのインフラストラクチャをすべてAWSクラウドに移行することに成功しました。
ソリューションアーキテクトは、設計に従って構築されていること、またAWSのWell-Architected Frameworkに沿って稼働していることを確認するために環境をレビューしています。
コストエクスプローラーで前月のコストを確認している際、いくつかの大規模インスタンスタイプの作成とその後の終了が、コストの大部分を占めていることに気付きました。ソリューションアーキテクトは、同社の開発者がテストの一環として新しいAmazon EC2インスタンスを起動しており、適切なインスタンスタイプを使用していないことを発見しました。
ソリューションアーキテクトは、開発者が起動できるインスタンスタイプを制限するための制御メカニズムを実装する必要があります。
次のうち、要件を満たす解決策はどれですか？
A. AWS Configで許容されるインスタンスタイプを指定した
desired-instance-typeのマネージドルールを作成します。このルールを、新しいEC2インスタンスが起動されるたびに実行されるイベントに関連付けます。B. EC2コンソールで、許容されるインスタンスタイプを指定した起動テンプレートを作成します。このテンプレートを開発者のIAMアカウントに割り当てます。
C. 新しいIAMポリシーを作成します。許容されるインスタンスタイプを指定します。このポリシーを、開発者のIAMアカウントを含むIAMグループにアタッチします。
D. EC2 Image Builderを使用して、開発者向けのイメージパイプラインを作成し、ゴールデンイメージの作成を支援します。
解説
この問題では、開発者が起動できるEC2インスタンスタイプを制限するための適切な制御メカニズムを選択する必要があります。それぞれの選択肢について解説します。
A. AWS Configのマネージドルールを使用する
- 説明: AWS Configで
desired-instance-typeルールを作成し、許可されたインスタンスタイプを定義します。このルールをイベントに関連付け、新しいEC2インスタンスが起動されるたびに実行します。
- メリット: AWS Configは環境の監視と準拠状態の確認に役立ちますが、インスタンス起動を直接制限する機能ではありません。
- デメリット: この方法は、インスタンス起動後に非準拠状態を検出する仕組みであり、事前に制限をかけることはできません。
- 評価: 不正解 - インスタンスタイプの制御メカニズムとしては不適切。
B. 起動テンプレートを作成して割り当てる
- 説明: 開発者が起動テンプレートを使用してインスタンスを起動するように設定します。このテンプレートに許可されるインスタンスタイプを事前に定義します。
- メリット: 起動テンプレートでインスタンス構成を統一できます。
- デメリット: 起動テンプレートを強制的に使用させる仕組みはありません。開発者がテンプレートを使わない場合、制御は無効になります。
- 評価: 不正解 - インスタンスタイプ制限を強制する方法としては不十分。
C. IAMポリシーを使用して制限を設定する
- 説明: IAMポリシーで許可されるインスタンスタイプを明確に指定します。このポリシーを開発者が所属するIAMグループに適用します。
- メリット: IAMポリシーは事前にインスタンス起動を制御できるため、許可されたインスタンスタイプ以外の起動ができません。
- デメリット: ポリシーの設計が正確である必要がありますが、一度設定すれば手間がかかりません。
- 評価: 正解 - IAMポリシーは開発者が起動できるインスタンスタイプを制限するための最も効果的な方法です。
D. EC2 Image Builderを使用してゴールデンイメージを作成する
- 説明: EC2 Image Builderで標準化されたゴールデンイメージを作成し、開発者に使用を促します。
- メリット: イメージの標準化に役立ちます。
- デメリット: イメージ自体はインスタンスタイプを制限しません。また、Image Builderは主にAMIの構成管理ツールであり、インスタンスの制御には向いていません。
- 評価: 不正解 - インスタンスタイプの制御メカニズムとしては適切ではありません。
正解: C. IAMポリシーを使用する
理由
- IAMポリシーを使用すれば、特定のインスタンスタイプのみを許可するルールを設定可能です。これにより、開発者が指定されたタイプ以外のインスタンスを起動することを防げます。
- 例として、以下のIAMポリシーを作成できます：
このポリシーでは、許可されたインスタンスタイプ（例:
t3.microとt3.small）以外のインスタンス起動が拒否されます。113-AWS Configルール タグ
理論
AWSにおけるリソースタグ管理のベストプラクティス
AWS環境では、リソースに適切なタグを付与することが重要です。タグを活用することで、コスト管理、リソースの整理、アクセス制御を効率化できます。以下に、タグ管理を強化するための方法を簡単に解説します。
1. AWS Configを利用したタグ監視
- 概要: AWS Configはリソースの設定変更を追跡し、ルールを作成してタグの有無を監視できます。
- 利点: タグが不足しているリソースを特定し、コンプライアンスを維持可能。
- 使用例: 「特定のタグが存在しないリソースを検出する」ルールを作成。
2. Service Control Policies (SCP) を使用したタグ付けの強制
- 概要: SCPを使うと、AWS Organizations内のアカウントで特定の操作を制限できます。
- 利点: リソース作成時に必須タグがない場合、操作を拒否して未然に問題を防止可能。
- 使用例:
ec2:RunInstancesに対し、指定タグが欠けている場合の拒否ルールを設定。
3. AWS Configアグリゲーターによる一元管理
- 概要: 複数アカウントの設定データを集約し、全体を可視化できます。
- 利点: 組織全体のタグコンプライアンス状況を一元管理可能。
- 使用例: 各アカウントの「タグ不足リソース」を一覧化。
4. IAMポリシーとSCPの違い
- IAMポリシー: 個別のアカウント、ユーザー、ロールに適用。制御範囲が限定的。
- SCP: AWS Organizations全体で強制され、統一的な管理が可能。広範囲に適用したい場合に有効。
5. タグ管理のメリット
- コスト配分: プロジェクト別にコストを正確に追跡可能。
- リソース管理: タグで分類することで、検索性や整理が向上。
- アクセス制御: タグに基づいて操作を許可または拒否するポリシーを設定可能。
まとめ
AWSでは、適切なタグ付けとその監視・制御を組み合わせることで、効率的かつ透明性の高いリソース管理が可能になります。AWS Config、SCP、タグの運用ルールを活用して、リソース管理を最適化しましょう。
一問道場
質問 #113
トピック 1
ある企業は、AWSクラウド上で複数のプロジェクトを開発・ホスティングしています。これらのプロジェクトは、AWS Organizations内の同じ組織に属する複数のAWSアカウントで開発されています。企業は、クラウドインフラのコストを所有するプロジェクトに割り当てる必要があります。しかし、全てのAWSアカウントを管理しているチームが、いくつかのAmazon EC2インスタンスにコスト割り当てに使用される「Project」タグが欠けていることを発見しました。
ソリューションアーキテクトが、この問題を解決し、将来的に発生しないようにするためにはどのようなアクションを取るべきですか？（3つ選択してください。）
- A. 各アカウントで、タグが欠けているリソースを検出するためのAWS Configルールを作成します。
- B. 「Project」タグが欠けている場合、
ec2:RunInstancesを拒否するService Control Policy（SCP）を組織に作成します。
- C. 組織内でAmazon Inspectorを使用して、タグが欠けているリソースを検出します。
- D. 各アカウントに、「Project」タグが欠けている場合、
ec2:RunInstancesを拒否するIAMポリシーを作成します。
- E. 組織全体でAWS Configアグリゲーターを作成し、「Project」タグが欠けているEC2インスタンスのリストを収集します。
- F. AWS Security Hubを使用して、「Project」タグが欠けているEC2インスタンスのリストを集約します。
解説
この問題では、AWSリソースの適切なタグ付けを確保し、将来的なタグ付けの欠落を防止するための方法を問われています。以下に解説を示します。
正解: A, B, E
A. AWS Configルールを作成
AWS Configは、リソースの設定変更を追跡し、タグが欠けているリソースを検出するルールを作成できます。このルールを各アカウントで設定することで、現在タグが不足しているリソースを特定できます。
理由: タグの有無を監視するための基本的なツールとして役立ちます。
B. SCPを使用してタグの欠如を防止
Service Control Policies (SCP)は、AWS Organizations内でアカウント全体に適用されるポリシーを設定できます。この問題では、「Project」タグがない状態で
ec2:RunInstancesを実行する操作を拒否するSCPを作成することで、タグが不足しているリソースの作成を未然に防げます。理由: SCPはAWS Organizations内のすべてのアカウントで強制的に適用されるため、確実な予防策になります。
E. AWS Configアグリゲーターを使用
AWS Configアグリゲーターを使用することで、複数のアカウント間でコンプライアンスデータを集約し、タグが欠けているリソースを一元的に管理できます。
理由: 組織全体で一貫した監視を可能にし、コンプライアンス違反を迅速に特定できます。
誤答: C, D, F
C. Amazon Inspectorの使用
Amazon Inspectorは主にセキュリティと脆弱性管理ツールであり、タグの欠如を検出する機能はありません。この問題の要件を満たす適切なツールではありません。
D. IAMポリシーの使用
IAMポリシーは個別のアカウントやユーザーに適用されますが、組織全体での一貫した制御には適していません。この場合、SCPを使用する方が効果的です。
F. AWS Security Hubの使用
AWS Security Hubはセキュリティ関連の問題を統合的に管理するツールであり、タグの欠如に関する特定の機能は提供していません。
まとめ
- 現在の問題を解決する: AWS Configルール (A) と AWS Configアグリゲーター (E) でリソースを監視します。
- 将来の問題を防止する: SCP (B) を使用してタグが欠けているリソースの作成を防ぎます。
これにより、コスト割り当てが適切に行われ、リソース管理が改善されます。
114-Kinesis Data Firehose+ES
理論
項目 | Kinesis Data Streams | Kinesis Data Firehose |
用途 | リアルタイム処理 | データのバッファリングと転送 |
スケーリング | 手動（シャード管理） | 自動 |
永続化時間 | 最大7日間 | 永続化なし |
処理の手間 | カスタムアプリが必要 | フルマネージドで簡単 |
ターゲット | 任意のアプリケーション | S3、Redshift、Elasticsearchなど |
遅延 | 数十ミリ秒（リアルタイム向け） | 数秒〜数分（バッファ後転送） |
1. 半構造化データと動的スキーマ
半構造化データとは、通常のリレーショナルデータベースのように厳密なスキーマがないものの、一定の構造（例：JSONやXML）を持っているデータのことです。これに対し、動的スキーマは、データの形式が変更されても柔軟に対応できる特徴を持ちます。JSONデータはその典型であり、異なるフィールドやデータ型を持つことができるため、柔軟性が求められる場合に使用されます。
2. Amazon Kinesis
Amazon Kinesisは、リアルタイムでのデータストリーム処理を可能にするAWSサービスで、特に大量のデータを高頻度で処理するシナリオに最適です。Kinesisには以下のような主なコンポーネントがあります：
- Kinesis Data Streams (KDS): リアルタイムデータストリーミングを行い、イベントデータをバッファリングします。
- Kinesis Data Firehose: Kinesis Data Streamsと似ていますが、こちらは完全にマネージドサービスで、データを簡単に指定の場所に送信するために使用されます。データ処理のために自動的にスケールし、管理の手間を軽減します。
Kinesisは、バッファリングやストリーム処理が得意であり、リアルタイムでのデータ解析や可視化に利用されます。特にイベントの取り込みやデータ転送に関しては非常にスケーラブルで、自動でスケールする特徴があります。
3. AWS Lambda
AWS Lambdaは、サーバーレスコンピューティングサービスで、コードの実行にサーバーを管理する必要がありません。データが到着すると、Lambdaはイベント駆動型で自動的にトリガーされ、指定した処理（データ変換やフィルタリングなど）を実行します。これにより、リアルタイムデータ処理が簡単に行えます。
Lambdaを使用することで、開発者はインフラの管理に関与することなく、コードに集中することができます。また、JSON形式のデータを容易に処理でき、動的スキーマにも対応しています。
4. Amazon Elasticsearch Service (Amazon ES) と Kibana
Amazon Elasticsearch Serviceは、ログデータや検索データをインデックス化し、迅速に検索や分析を行うためのサービスです。Elasticsearchは主に非構造化データや半構造化データを高速で検索し、処理するために使用されます。KibanaはElasticsearchと連携し、データの可視化を行います。特に、ダッシュボードやグラフを使ってリアルタイムにデータを視覚的に分析するのに適しています。
5. Amazon QuickSight
Amazon QuickSightはAWSのBI（ビジネスインテリジェンス）サービスで、データの可視化と分析を行うためのツールです。QuickSightは、リアルタイムのダッシュボードを簡単に作成でき、さまざまなデータソース（RDS、S3、Redshiftなど）からデータを引き出して可視化を行います。
6. トラフィックとスケーラビリティ
スケーラビリティは、アプリケーションが増加するデータ量に対応できる能力を指します。特に、リアルタイムデータや高スループットなデータ処理が必要な場合、Amazon Kinesis Data FirehoseやAmazon Elasticsearchのようなサービスが重要です。これらは、データの量に応じて自動的にスケールし、適切なデータの流れと処理を提供します。
この問題では、半構造化データと動的スキーマの処理に関して、AWSのマネージドサービスをうまく活用するための知識が試されています。特に、Amazon KinesisやAWS Lambda、Amazon Elasticsearch Serviceは、リアルタイムのデータ処理や可視化に強力なツールです。また、データの柔軟性を保ちながら、簡単にスケーラブルなソリューションを構築できる点が重要です。
実践
一問道場
Question #114
Topic 1
ある企業では、イベントの永続化のためにPostgreSQLデータベースを使用したオンプレミスのモニタリングソリューションを採用しています。このデータベースは、高負荷のデータ取り込みのためにスケーリングができず、頻繁にストレージ不足になります。
企業はハイブリッドソリューションを作成したいと考えており、自社ネットワークとAWS間のVPN接続をすでに設定しています。ソリューションには以下の特性を含める必要があります:
- 運用の複雑さを最小限に抑えるためにAWSのマネージドサービスを使用すること
- データのスループットに合わせて自動でスケールし、継続的な管理を必要としないバッファ
- イベントをほぼリアルタイムで観測できるダッシュボードを作成するための可視化ツール
- 半構造化JSONデータと動的スキーマのサポート
これらの要件を満たすモニタリングソリューションを構築するために、どのコンポーネントの組み合わせが適切ですか？（2つ選択）
A. Amazon Kinesis Data Firehoseを使用してイベントをバッファリングする。AWS Lambda関数を作成してイベントを処理および変換する。
B. Amazon Kinesisデータストリームを作成してイベントをバッファリングする。AWS Lambda関数を作成してイベントを処理および変換する。
C. Amazon Aurora PostgreSQL DBクラスターを設定してイベントを受信する。Amazon QuickSightを使用してデータベースからデータを読み取り、ほぼリアルタイムの可視化とダッシュボードを作成する。
D. Amazon Elasticsearch Service（Amazon ES）を設定してイベントを受信する。Amazon ESにデプロイされたKibanaエンドポイントを使用して、ほぼリアルタイムの可視化とダッシュボードを作成する。
E. Amazon Neptune DBインスタンスを設定してイベントを受信する。Amazon QuickSightを使用してデータベースからデータを読み取り、ほぼリアルタイムの可視化とダッシュボードを作成する。
115-VPCエンドポイント
理論
1. VPCエンドポイント
VPCエンドポイントは、VPC内のリソースからインターネットを経由せずに、AWSサービスにアクセスするための専用のネットワーク接続です。これにより、インターネット経由の通信に比べてセキュリティが向上し、データ転送コストも削減されます。
- インターフェイスVPCエンドポイント: Amazon Kinesis、Amazon S3、AWS Secrets Managerなどのサービスへのアクセスに使用されます。これを設定することで、サービス間の通信がインターネット経由ではなく、プライベートネットワーク内で完結します。これにより、NATゲートウェイを介したインターネットトラフィックを削減できます。
2. NATゲートウェイ
NAT（Network Address Translation）ゲートウェイは、プライベートサブネットにあるインスタンスがインターネットにアクセスするためのリソースです。NATゲートウェイを使用すると、プライベートサブネット内のインスタンスは外部と通信できますが、その代償としてインターネット接続に関連するデータ転送コスト（NatGateway-Bytes）が発生します。
- コストが高くなる原因: NATゲートウェイは、インターネット接続のために使用する帯域幅に応じてコストが発生します。特に大量のデータ転送が行われる場合、コストが急増する可能性があります。
3. Cost Explorerとコスト管理
AWSのCost Explorerは、AWSリソースのコストを視覚化し、分析するためのツールです。特定のカテゴリやリソースごとにコストを追跡できるため、無駄なコストを見つけて最適化するのに役立ちます。例えば、NatGateway-Bytesという項目が高い場合、インターネット経由のトラフィックを減らす方法を考える必要があります。
4. セキュリティグループとトラフィック制御
セキュリティグループは、インスタンスにアクセスするためのルールを設定する仮想ファイアウォールです。VPC内で発生する不要なトラフィックをブロックすることができるため、コスト削減やセキュリティ向上に貢献します。VPC Flow LogsやAmazon Detectiveを活用して、不要なトラフィックを検出し、適切にセキュリティグループで制御することができます。
まとめ
VPCインターフェイスエンドポイントを利用することで、Kinesis Data StreamsなどのAWSサービスにアクセスする際のインターネット経由のトラフィックを削減でき、NATゲートウェイを介したデータ転送に関連するコストを削減できます。これにより、コスト最適化とセキュリティの向上を同時に達成できます。
一問道場
問題 #115
トピック 1
あるチームは、企業全体の行動データを収集し、ルーティングしています。企業は、パブリックサブネット、プライベートサブネット、およびインターネットゲートウェイを備えたMulti-AZ VPC環境を運用しています。各パブリックサブネットにはNATゲートウェイも含まれています。企業のアプリケーションのほとんどは、Amazon Kinesis Data Streamsから読み取り、書き込みを行います。ほとんどのワークロードはプライベートサブネットで実行されています。
ソリューションアーキテクトはインフラをレビューしており、コスト削減とアプリケーションの機能維持が求められています。ソリューションアーキテクトはCost Explorerを使用して、EC2-Otherカテゴリのコストが常に高いことに気付きました。さらに調査した結果、NatGateway-Bytesの料金がEC2-Otherカテゴリのコストを増加させていることが分かりました。
ソリューションアーキテクトはこの要件を満たすために何をすべきですか？
A. VPCフローログを有効にし、Amazon Athenaを使用して、削除可能なトラフィックをログで分析します。セキュリティグループが高コストの原因となっているトラフィックをブロックしていることを確認します。
B. Kinesis Data StreamsのインターフェースVPCエンドポイントをVPCに追加し、アプリケーションがインターフェースVPCエンドポイントを使用するために必要なIAM権限を持っていることを確認します。
C. VPCフローログとAmazon Detectiveを有効にし、Detectiveの調査結果を確認してKinesis Data Streamsに関連しないトラフィックを特定します。そのトラフィックをブロックするためにセキュリティグループを構成します。
D. Kinesis Data StreamsのインターフェースVPCエンドポイントをVPCに追加し、VPCエンドポイントポリシーがアプリケーションからのトラフィックを許可することを確認します。
解説
この問題に対する最適な解決策は B です。
理由:
- B. Kinesis Data Streams用にVPCインターフェイスエンドポイントを追加する VPCインターフェイスエンドポイントを使用することで、Kinesis Data Streamsへのアクセスがインターネット経由でなく、VPC内で完結します。このため、NATゲートウェイを通じて発生するデータ転送量が削減され、NatGateway-Bytes のコストが下がります。これが最も効率的なコスト削減方法です。
他の選択肢（A, C, D）は、トラフィックの調査やセキュリティグループの設定に関連していますが、直接的にNATゲートウェイのコスト削減にはつながりません。
116-Direct Connect
理論
主な違い
特徴 | プライベートVIF | トランジットVIF |
接続対象 | 単一のVPC | Transit Gateway |
複数VPC接続 | 不可 | 可能 |
複数リージョン対応 | 不可 | 可能 |
複雑なネットワークに適応 | 適していない | 適している |
用途 | 単一のVPCとオンプレミス接続 | 複数VPCやオンプレミスを統合 |
まとめ
Direct Connect gateway は、AWS Direct Connect を使用して、複数の VPC や AWS リージョンとオンプレミスのネットワークを接続するためのサービスです。
オンプレミス ↔ Direct Connect ↔ プライベートVIF ↔ VGW ↔ VPC
オンプレミス ↔ Direct Connect ↔ プライベートVIF ↔ Direct Connect Gateway ↔ TGW ↔ VPC群（同一または異なるリージョン）
オンプレミス ↔ Direct Connect ↔ トランジットVIF ↔ Direct Connect Gateway ↔ Transit Gateway ↔ VPC群 (同一リージョン)
オンプレミス ↔ Direct Connect ↔ トランジットVIF ↔ Direct Connect Gateway ↔ Transit Gateway(リージョンA) ↔ VPC群 (リージョンA)
↔ Transit Gateway(リージョンB) ↔ VPC群 (リージョンB)
一問道場
問題 #116
トピック 1
ある小売企業がヨーロッパにオンプレミスのデータセンターを持っています。この企業は、eu-west-1およびus-east-1リージョンのVPCに対してネットワークトラフィックをルーティングできるようにしたいと考えています。また、この企業は、これらのリージョン間で直接VPC間のトラフィックをルーティングする必要があります。ネットワークに単一障害点が存在してはいけません。
この企業は、すでにオンプレミスのデータセンターから2つの1 GbpsのAWS Direct Connect接続を作成しています。各接続は、ヨーロッパ内の異なるDirect Connectロケーションに接続しており、高可用性を確保しています。これらの2つのロケーションはそれぞれDX-AとDX-Bと呼ばれています。各リージョンには、リージョン内のすべてのVPC間トラフィックをルーティングするために設定された単一のAWS Transit Gatewayがあります。
この要件を満たすソリューションはどれですか？
A. DX-A接続からDirect ConnectゲートウェイへのプライベートVIFを作成し、DX-B接続から同じDirect ConnectゲートウェイへのプライベートVIFを作成して高可用性を確保します。eu-west-1およびus-east-1の両方のTransit GatewayをこのDirect Connectゲートウェイに関連付けます。Transit Gateway同士をピアリングして、リージョン間のルーティングをサポートします。
B. DX-A接続からDirect ConnectゲートウェイへのトランジットVIFを作成し、このDirect Connectゲートウェイにeu-west-1 Transit Gatewayを関連付けます。次に、DX-B接続から別のDirect ConnectゲートウェイへのトランジットVIFを作成し、このDirect Connectゲートウェイにus-east-1 Transit Gatewayを関連付けます。Direct Connectゲートウェイ同士をピアリングして、高可用性およびリージョン間のルーティングをサポートします。
C. DX-A接続からDirect ConnectゲートウェイへのトランジットVIFを作成し、DX-B接続から同じDirect ConnectゲートウェイへのトランジットVIFを作成して高可用性を確保します。eu-west-1およびus-east-1の両方のTransit GatewayをこのDirect Connectゲートウェイに関連付けます。Direct Connectゲートウェイを構成して、Transit Gateway間のトラフィックをルーティングします。
D. DX-A接続からDirect ConnectゲートウェイへのトランジットVIFを作成し、DX-B接続から同じDirect ConnectゲートウェイへのトランジットVIFを作成して高可用性を確保します。eu-west-1およびus-east-1の両方のTransit GatewayをこのDirect Connectゲートウェイに関連付けます。Transit Gateway同士をピアリングして、リージョン間のルーティングをサポートします。
正解
正解は A です。
解説：
- 問題文の要件には、「リージョン間で直接VPC間のトラフィックをルーティングする」「単一障害点が存在しないこと」などが含まれています。
- A のオプションでは、DX-AとDX-B接続から同じDirect ConnectゲートウェイにプライベートVIFを作成し、高可用性を確保しています。また、Transit Gateway同士をピアリングすることで、両リージョン間でのVPC間トラフィックのルーティングが可能です。
- B と C では、Direct Connectゲートウェイ同士をピアリングしない方法が提案されていますが、要件に「Direct Connectゲートウェイ同士をピアリングしてリージョン間ルーティングをサポートする」とあるため、これらは要件を満たしていません。
- D は、オプションAと同様にTransit Gateway同士をピアリングしますが、問題文の要件におけるルーティングの詳細が異なり、最も適切な方法としては A が最適です。
117-新しいユーザーのすべてのアクセスが自動的に削除
理論
AWSにおけるIAMユーザー管理とセキュリティ設計
IAMユーザーの役割と管理
- IAM (Identity and Access Management) は、AWSリソースへのアクセスを制御するための重要なサービスです。
- IAMユーザーは、AWSアカウントのリソースにアクセスするために作成される個別のエンティティであり、特定の認証情報（パスワード、アクセスキーなど）を持ちます。
- 適切な権限管理を行わないと、誤操作やセキュリティインシデントにつながる可能性があります。
IAMユーザー作成時のセキュリティリスク
- デフォルトアクセス権の乱用 新規ユーザーに不要な権限を付与すると、リソースが過剰に利用される可能性があります。
- セキュリティインシデント ユーザー作成後、権限がすぐに有効になると、不正アクセスのリスクが高まります。
IAMユーザーの作成とアクセス制御の自動化
AWSでは、IAMユーザー管理において以下の自動化が可能です：
- EventBridgeでのイベント検知
CloudTrailからのAPIコールイベント（例：
CreateUser）を監視。
- Step Functionsでのワークフロー管理 アクセス権限削除や承認プロセスを一括管理。
- SNSによる通知 セキュリティチームへの即時通知を実現。
イベント駆動型アーキテクチャの活用
AWSでは、イベント駆動型アーキテクチャを利用することで、リアルタイムの監視と対応が可能です。
EventBridgeの役割
EventBridgeは、AWSサービスやサードパーティアプリケーションのイベントを検知し、他のサービスをトリガーするサービスです。以下の特徴があります：
- 柔軟なイベントフィルタリング 例えば、IAMユーザー作成時のみ特定のルールをトリガー可能。
- 多様なターゲット Lambda、Step Functions、SNS、ECSなどをターゲットとして設定できます。
AWS Step Functionsによるプロセス自動化
Step Functionsは、複数のAWSサービスを統合し、シンプルなワークフローから複雑なプロセスまで管理するサービスです。
IAMユーザーのアクセス削除フロー例
- EventBridgeで
CreateUserイベントを検知。
- Step Functionsが以下のステップを実行：
- ユーザーの権限を削除（IAM APIの
DetachUserPolicyなどを使用）。 - 処理結果をSNSで通知。
通知と承認プロセス
Amazon SNSの役割
- 通知送信 セキュリティチームへのリアルタイム通知。
- 複数の送信先 Eメール、SMS、モバイルプッシュ通知などに対応。
ベストプラクティス
- 最小権限の原則 (Principle of Least Privilege) ユーザーやロールに必要最低限の権限を付与。
- リアルタイム監視の導入 CloudTrailとEventBridgeを活用してセキュリティイベントを検知。
- 自動化と手動プロセスのバランス 自動化で効率化しつつ、最終承認は手動で行うことでセキュリティを確保。
この知識を活用することで、IAMユーザー管理をより安全かつ効率的に行い、AWS環境のセキュリティを強化できます。
一問道場
ある会社がAWSクラウド上でアプリケーションを運用しています。
この会社のセキュリティチームは、新しいIAMユーザーを作成する際に必ず承認を行う必要があります。
新しいIAMユーザーが作成されると、そのユーザーのすべてのアクセスが自動的に削除される必要があります。
その後、セキュリティチームがユーザーを承認するための通知を受け取る必要があります。
この会社はAWSアカウント内でマルチリージョンAWS CloudTrailトレイルを使用しています。
この要件を満たすためのステップの組み合わせはどれですか？（3つ選択してください。）
A. Amazon EventBridge（Amazon CloudWatch Events）のルールを作成します。
詳細タイプ（detail-type）を
AWS API Call via CloudTrailに設定し、eventNameをCreateUserに設定してパターンを定義します。B. CloudTrailを設定して、
CreateUserイベントの通知をAmazon Simple Notification Service（Amazon SNS）トピックに送信します。C. AWS Fargate技術を使用してAmazon Elastic Container Service（Amazon ECS）で実行されるコンテナを呼び出し、アクセスを削除します。
D. AWS Step Functionsステートマシンを呼び出してアクセスを削除します。
E. Amazon Simple Notification Service（Amazon SNS）を使用してセキュリティチームに通知します。
解説
要件のポイント
- 新しいIAMユーザーが作成された際に自動でアクセスを削除する必要がある。
- セキュリティチームが通知を受け取り、ユーザーを承認するプロセスが必要である。
- AWS CloudTrailを活用する。
選択肢の評価
A. Amazon EventBridge（Amazon CloudWatch Events）のルールを作成
- 解説： EventBridgeのルールを設定することで、特定のイベント（この場合は
CreateUserイベント）が発生した際にトリガーを設定できます。これにより、IAMユーザーの作成イベントを検知できます。
- 正解： 要件を満たすために必要です。
B. CloudTrailを設定して通知をSNSトピックに送信
- 解説： CloudTrail自体には通知機能がありません。ただし、EventBridgeと連携することで、指定されたイベントが発生した際にSNSトピックに通知を送ることができます。しかし、この選択肢はCloudTrailから直接通知を送ることを指しているため不正確です。
- 不正解： CloudTrailは通知を直接送信しません。
C. AWS Fargate技術を使用してAmazon ECSで実行されるコンテナを呼び出す
- 解説： IAMユーザーのアクセスを削除するアクションは、LambdaやStep Functionsで実現するのが一般的であり、ECSを利用するのは効率が良くありません。
- 不正解： 不要に複雑です。
D. AWS Step Functionsを呼び出してアクセスを削除
- 解説： Step Functionsを使うことで、一連のプロセス（例：アクセス削除→通知）を実行できます。この要件を満たす効率的な方法の一つです。
- 正解： 要件を満たすために適しています。
E. Amazon SNSを使用してセキュリティチームに通知
- 解説： SNSは通知を送信するために最適なサービスです。セキュリティチームへの通知手段として妥当です。
- 正解： 要件を満たすために必要です。
F. Amazon Pinpointを使用してセキュリティチームに通知
- 解説： Pinpointは主にマーケティング向けの通知サービスであり、セキュリティチームへの通知には適していません。
- 不正解： 要件に適合しません。
正解の組み合わせ
A. EventBridgeルールを作成
D. Step Functionsを呼び出す
E. SNSを使用して通知
実現の流れ
- EventBridgeのルールを作成
CreateUserイベントを検知。
- Step Functionsでアクセス削除を実行
- 作成されたIAMユーザーの権限を削除。
- SNSでセキュリティチームに通知
- セキュリティチームが承認作業を実施可能。
これにより、要件をすべて満たす仕組みが完成します。
118-AWS マルチアカウント戦略
理論
AWS マルチアカウント戦略とセキュリティ管理の基本知識
AWS 環境でのマルチアカウント構造の設計と管理は、大規模な企業においてセキュリティ、スケーラビリティ、および運用効率を向上させるために重要な要素です。この問題に関連する本質的な知識を以下にまとめます。
1. マルチアカウント構造の利点
AWSでマルチアカウント戦略を採用することで、以下のような利点があります。
- セキュリティの強化: 各アカウントごとにリソースやポリシーを分離することで、セキュリティリスクを軽減できます。
- 責任の分離: 開発、ステージング、プロダクション環境を分離することで、運用上のミスや意図しない変更の影響を最小限に抑えます。
- コスト管理: アカウントごとにコストを追跡し、予算管理を容易にします。
- スケーラビリティ: 各部門やプロジェクトごとに独立した環境を持つことで、管理が容易になります。
2. AWS Control Tower
AWS Control Tower は、マルチアカウント環境のセットアップと管理を簡素化するサービスです。
- ランディングゾーン: Control Tower が提供するベストプラクティスに基づいたマルチアカウント環境の標準設定。
- AWS Organizations: 組織のアカウントを一元管理し、ポリシーを適用可能。
- ガードレール: アカウントごとにセキュリティポリシーを自動適用。
ユースケース:
Control Tower を使用して、開発、ステージング、プロダクション、共有ネットワークアカウントを一元管理できます。
3. AWS IAM Identity Center (AWS SSO)
IAM Identity Center は、AWS のシングルサインオン (SSO) ソリューションであり、ユーザー管理を効率化します。
- MFA: 多要素認証 (MFA) をサポートし、セキュリティを向上。
- ロール管理: ユーザーグループに基づいてアクセス権限を割り当て。
- 統合: Active Directory や外部IDプロバイダーとの連携が可能。
ユースケース:
各アカウントにログインするユーザーに、必要最小限の権限を付与することで、セキュリティを強化します。
4. ネットワーク設計: AWS Transit Gateway
AWS Transit Gateway は、複数のVPCやオンプレミス環境を統合的に接続するサービスです。
- 接続管理: 複数のVPCを一元管理して、ルートテーブルを設定可能。
- セキュリティ: トラフィックをプライベートネットワーク内に限定。
- スケーラビリティ: 大規模なネットワーク環境での接続を効率化。
ユースケース:
プロダクションと共有ネットワークアカウントの間で接続を確立し、他のアカウントとの分離を維持します。
5. セキュリティとアクセス管理のベストプラクティス
- 必要最小限のアクセス: ユーザーやアカウントごとにアクセス権限を厳密に制限。
- MFA の必須化: 全てのユーザーに対してMFAを強制することで、不正アクセスを防止。
- ログ管理: AWS CloudTrail を使用して全アカウントのアクティビティを記録。
- ポリシーの自動適用: AWS Config やControl Towerのガードレールを活用。
まとめ
AWS 環境でマルチアカウント構造を導入する際は、AWS Control Tower を使用してランディングゾーンを設定し、IAM Identity Center でユーザーアクセスを集中管理するのが推奨されます。また、Transit Gateway を活用してプライベートネットワークを構築することで、セキュリティと運用効率を向上させることができます。これらのサービスとベストプラクティスを組み合わせることで、安全かつスケーラブルなAWS環境を実現できます。
この図は、AWS Control Tower を使ってプロビジョニングされた「ランディングゾーン（Landing Zone）」の構成を説明しています。AWS Control Towerは、AWSアカウントの管理とガバナンスを簡素化し、セキュリティやコンプライアンス要件を満たすための環境を提供します。
図の主なポイント
- 管理アカウント（Management Account）
- AWS Control Towerを設定・運用する中心となるアカウント。
- 以下のサービスを通じて、環境を構成・管理します：
- AWS Organizations: マルチアカウント環境を作成・管理。
- AWS CloudFormation StackSets: 共通の設定やリソースを各アカウントにデプロイ。
- AWS Service Catalog (Account Factory): 新しいアカウントを簡単に作成するためのツール。
- AWS IAM Identity Center (AWS Single Sign-On): アカウント間のシングルサインオン（SSO）を設定。
- 組織単位（Organizational Units, OUs）
- アカウントを管理するためのグループ。以下の例が示されています：
- Security OU: セキュリティ関連のアカウントを管理。
- Sandbox OU: 開発や実験用アカウントを管理。
- 専用アカウント
- Log Archive Account（ログアーカイブアカウント）:
- 中央集約されたAWS CloudTrailやAWS Configのログを保存。
- セキュリティやコンプライアンスのために重要。
- Audit Account（監査アカウント）:
- セキュリティ通知やクロスアカウントロールを提供。
- AWS Configの設定を集約。
- Provisioned Accounts（プロビジョニングされたアカウント）:
- 開発、ステージング、プロダクションなど、用途に応じて作成されるアカウント。
- それぞれがアカウントのベースライン（共通設定）とネットワークのベースラインを持つ。
図が示すメリット
- 統合された管理: AWS Control Towerを活用することで、複数アカウントを一元的に管理できる。
- セキュリティとコンプライアンス: ログの一元化やクロスアカウントのセキュリティロールにより、セキュリティリスクを最小化。
- 効率的なアカウント作成: AWS Service Catalogを使い、新しいアカウントを迅速かつ標準化して作成可能。
- シングルサインオン: AWS IAM Identity Centerを利用して、ユーザーの認証を簡素化。
全体的に、この図はAWS Control Towerを活用して、複雑なマルチアカウント環境を効率的かつセキュアに管理する方法を示しています。
一問道場
質問 #118
トピック 1
ある企業がAWSへの移行を計画しています。この企業は、すべてのアカウントやアプリケーションへのアクセスを集中管理できるマルチアカウント構造を使用したいと考えています。また、トラフィックはプライベートネットワーク上で維持したいと考えています。
ログイン時に多要素認証（MFA）が必須であり、ユーザーグループごとに特定のロールが割り当てられる必要があります。
企業は、開発、ステージング、プロダクション、および共有ネットワーク用に個別のアカウントを作成する必要があります。プロダクションアカウントと共有ネットワークアカウントはすべてのアカウントに接続できる必要があり、開発アカウントとステージングアカウントはお互いにのみアクセスできる必要があります。
この要件を満たすために、ソリューションアーキテクトはどの手順の組み合わせを取るべきですか？（3つ選択）
選択肢：
A. AWS Control Tower を使用してランディングゾーン環境を展開します。アカウントを登録し、AWS Organizations に既存のアカウントを招待します。
B. すべてのアカウントで AWS Security Hub を有効化し、クロスアカウントアクセスを管理します。CloudTrail を通じて検出結果を収集し、MFAログインを強制します。
C. 各アカウントにトランジットゲートウェイとトランジットゲートウェイ VPC アタッチメントを作成し、適切なルートテーブルを設定します。
D. AWS IAM Identity Center (AWS Single Sign-On) を設定して有効化します。既存のアカウントに必要な MFA を含む適切なパーミッションセットを作成します。
E. すべてのアカウントで AWS Control Tower を有効化して、アカウント間のルーティングを管理します。CloudTrail を通じて検出結果を収集し、MFAログインを強制します。
F. IAMユーザーとグループを作成し、すべてのユーザーにMFAを設定します。Amazon Cognitoユーザープールとアイデンティティプールをセットアップして、アカウント間およびアカウントへのアクセスを管理します。
質問 #118
トピック 1
ある企業がAWSへの移行を計画しています。この企業は、すべてのアカウントとアプリケーションへのアクセスを一元管理できるマルチアカウント構造を使用したいと考えています。また、トラフィックはプライベートネットワーク内に限定することを希望しています。ログイン時には多要素認証（MFA）が必須であり、特定の役割がユーザーグループに割り当てられる必要があります。
以下の要件を満たすために、開発、ステージング、プロダクション、および共有ネットワーク用の個別のアカウントを作成する必要があります。
- プロダクションアカウントと共有ネットワークアカウントはすべてのアカウントに接続できる必要があります。
- 開発アカウントとステージングアカウントはお互いにのみアクセスできる必要があります。
ソリューションアーキテクトがこれらの要件を満たすために取るべき手順の組み合わせはどれですか？（3つ選択）
A. AWS Control Tower を使用してランディングゾーン環境を展開します。アカウントを登録し、既存のアカウントを AWS Organizations に招待します。
B. AWS Security Hub をすべてのアカウントで有効にして、アカウント間アクセスを管理します。AWS CloudTrail を使用してMFAログインを強制するための結果を収集します。
C. 各アカウントにトランジットゲートウェイとトランジットゲートウェイ VPC アタッチメントを作成します。適切なルートテーブルを設定します。
D. AWS IAM Identity Center（AWS シングルサインオン）を設定して有効化します。既存のアカウントに必要なMFAを含む適切な権限セットを作成します。
E. AWS Control Tower をすべてのアカウントで有効にして、アカウント間のルーティングを管理します。AWS CloudTrail を使用してMFAログインを強制するための結果を収集します。
F. IAM ユーザーとグループを作成します。すべてのユーザーにMFAを設定します。アカウント間およびアカウント内のアクセスを管理するために Amazon Cognito ユーザープールとアイデンティティプールを設定します。
解説
選択肢の検討
A. AWS Control Tower を使用してランディングゾーン環境を展開します
- 解説: AWS Control Tower は、複数のアカウントを統合管理するための推奨ソリューションです。ランディングゾーンを使用することで、セキュリティやコンプライアンスのベストプラクティスに基づいたマルチアカウント環境を作成できます。正解: 要件を満たします。
B. AWS Security Hub を有効化し、CloudTrail を通じて検出結果を収集します
- 解説: Security Hub はセキュリティデータの集約や可視化に役立ちますが、マルチアカウント構造のセットアップやMFAの管理には直接関与しません。不正解: 要件を直接満たしません。
C. 各アカウントにトランジットゲートウェイとVPCアタッチメントを作成します
- 解説: トランジットゲートウェイを使用すると、複数のアカウント間でのネットワーク接続を効率的に管理できます。開発・ステージング間やプロダクション・共有ネットワーク間の接続要件を満たすための適切な手法です。正解: 要件を満たします。
D. AWS IAM Identity Center (AWS Single Sign-On) を設定して有効化します
- 解説: IAM Identity Center (以前のAWS SSO) を使用すると、ユーザー認証、グループ管理、およびロール割り当てが可能です。MFAを含むセキュリティポリシーを設定し、集中管理ができます。正解: 要件を満たします。
E. すべてのアカウントで AWS Control Tower を有効化します
- 解説: Control Tower をすべてのアカウントに個別に有効化するのは非効率であり、AWS Organizations を通じた統合管理の手法と矛盾します。不正解: 要件を満たしません。
F. IAM ユーザーとグループを作成し、Cognito を使用します
- 解説: IAM ユーザーと Amazon Cognito はシングルサインオンやアカウント管理の代替手段として使用可能ですが、大規模なマルチアカウント環境の管理には向いていません。Control Tower やIAM Identity Centerの方が適切です。不正解: 要件を満たしません。
正しい選択肢
- A. AWS Control Tower を使用してランディングゾーン環境を展開します
- C. 各アカウントにトランジットゲートウェイとVPCアタッチメントを作成します
- D. AWS IAM Identity Center (AWS Single Sign-On) を設定して有効化します
解決の流れ
- マルチアカウント環境のセットアップ: AWS Control Tower を使用してランディングゾーンを構築し、マルチアカウント構造を設計。
- プライベートネットワーク構築: トランジットゲートウェイとVPCアタッチメントを使用して、必要なアカウント間で接続を設定。
- ユーザー管理と認証: AWS IAM Identity Center を利用してMFAを有効化し、グループごとの権限を設定。
この組み合わせにより、セキュリティを確保しつつ、効率的なマルチアカウント運用が可能になります。
119-インスタンス自動再開
理論
1. AWS EC2のコスト管理
Amazon EC2（Elastic Compute Cloud）は、オンデマンドで仮想サーバーを提供するサービスです。EC2インスタンスを24時間稼働させておくと、使用していない時間帯でもコストが発生します。特に開発環境やテスト環境では、常時稼働が必要ない場合が多いため、インスタンスを停止することでコストを削減することが重要です。
2. Amazon RDSのコスト管理
Amazon RDSを使ったコスト管理では、インスタンスの停止とストレージの最適化がカギとなります。不要な時間にインスタンスを停止することで、計算リソースのコストを削減できますが、ストレージ料金は引き続き発生するため、その管理も重要です。また、長期的なコスト削減には、スケーリングやリザーブドインスタンスの活用を検討するのが良いでしょう。
3. Amazon EventBridgeを利用した自動化
Amazon EventBridgeは、AWSリソース間でのイベント駆動型のワークフローを作成できるサービスです。EventBridgeを使うことで、特定の時間にインスタンスを開始または停止する自動化が可能です。これにより、手動での操作を減らし、最小限の運用作業でコスト削減を実現できます。
EventBridgeルールを作成して、例えば「平日の営業時間外に開発およびテスト環境のインスタンスを停止」するように設定することができます。これにより、リソースが必要ない時間帯に自動的に停止され、コスト削減が図れます。
4. タグを利用したリソース管理
AWSでは、リソースにタグを付けて分類・管理することが可能です。この問題では、**「development」「testing」「production」**の環境タグを使用して、各環境に対して異なる操作を実行するため、タグを基にしたルールを設定することが求められています。タグを使ったリソースのフィルタリングにより、特定の環境にのみ自動化を適用できるため、効率的なリソース管理が可能です。
5. EC2インスタンスのライフサイクル管理
インスタンスを「停止」することで、コストを削減できますが、「終了（terminate）」する場合、データは失われる可能性があります。通常、開発環境やテスト環境では、作業が完了した後にインスタンスを停止し、後で再利用できるようにした方が効率的です。
一方で、**終了（terminate）**する場合は、インスタンス自体を削除し、完全に不要なリソースを取り除くことができますが、データは失われるため、慎重に選択すべきです。
6. バックアップと復元
インスタンスを「終了」する代わりに、バックアップを取っておくことも一つの方法です。特にRDSでは自動バックアップやスナップショット機能を使って、データ損失を防ぐことができます。インスタンスを停止し、後で復元する場合は、バックアップからの復元手順を考慮する必要があります。
まとめ
EventBridgeを使用した自動化、タグを活用したリソース管理、EC2インスタンスの停止と終了、そしてバックアップからの復元手順を理解することで、最適なコスト削減策を講じることができます。特に開発やテスト環境においては、インスタンスの停止を適切に設定することで、無駄なコストを削減できます。
一問道場
質問 #119
トピック 1
ある企業は、eu-west-1リージョンでアプリケーションを実行しており、開発、テスト、そして本番環境ごとにそれぞれ別のAWSアカウントを使用しています。
すべての環境は、状態を持つAmazon EC2インスタンスとAmazon RDS for MySQLデータベースを使用して、1日24時間、週7日稼働しています。
データベースのサイズは500 GBから800 GBの間です。
- 開発チームとテストチームは、平日の営業時間に作業しますが、本番環境は1日24時間、週7日稼働しています。
- 会社はコスト削減を望んでいます。
- すべてのリソースには、キーが「development」「testing」「production」のいずれかの環境タグが付けられています。
最小限の運用作業でコストを削減するために、ソリューションアーキテクトは何をすべきですか？
選択肢
A.
毎日1回実行されるAmazon EventBridgeルールを作成します。このルールは、タグ、曜日、および時間に基づいてインスタンスを開始または停止するAWS Lambda関数を呼び出すように設定します。
B.
平日の夜に実行されるAmazon EventBridgeルールを作成します。このルールは、タグに基づいてインスタンスを停止するAWS Lambda関数を呼び出すように設定します。
さらに、平日の朝に実行される2つ目のEventBridgeルールを作成し、タグに基づいてインスタンスを開始する別のLambda関数を呼び出すように設定します。
C.
平日の夜に実行されるAmazon EventBridgeルールを作成します。このルールは、タグに基づいてインスタンスを終了（terminate）するAWS Lambda関数を呼び出すように設定します。
さらに、平日の朝に実行される2つ目のEventBridgeルールを作成し、タグに基づいて最後のバックアップからインスタンスを復元する別のLambda関数を呼び出すように設定します。
D.
毎時実行されるAmazon EventBridgeルールを作成します。このルールは、タグ、曜日、および時間に基づいてインスタンスを終了または最後のバックアップから復元するAWS Lambda関数を呼び出すように設定します。
解説
このシナリオでは、コスト削減のために、開発およびテスト環境のAmazon EC2インスタンスを必要に応じて停止または終了させ、24時間稼働する本番環境には影響を与えないようにする必要があります。
選択肢の解説:
- A. は毎日1回実行されるルールで、インスタンスを開始または停止するものですが、開発とテスト環境は平日の営業時間にのみ稼働する必要があり、1日の終了時に停止する処理を考慮していません。この選択肢では不十分です。
- B. は、平日の夜にインスタンスを停止し、平日の朝にインスタンスを開始するルールです。これにより、開発およびテスト環境は営業時間外に停止し、コスト削減が可能になります。最適な解答です。
- C. はインスタンスを「終了」させる方法ですが、終了後は復元する必要があり、インスタンスを終了することでデータが失われるリスクがあります。バックアップから復元するのは、複雑であり、最小限の運用作業を考慮した場合には適切ではありません。
- D. は毎時実行されるルールで、インスタンスを終了または復元するものですが、毎時のチェックが不必要であり、効率が悪く、コストがかかります。
Bが最も適切なソリューションです。
120-Amazon API Gateway
理論
Amazon API Gatewayにおけるスロットリングと制限の本質的な知識
Amazon API Gatewayは、サーバーレスのAPIを構築、管理、監視するための強力なサービスです。API Gatewayを使用する際に重要なのは、リクエストの処理能力やリソースの制限について理解することです。これらの制限に達した場合、リクエストはエラー（通常は 429 Too Many Requests）となり、Lambda関数やバックエンドサービスが呼び出されません。API Gatewayのスロットリングと制限について深掘りしてみましょう。
1. API Gatewayのスロットリング制限
API Gatewayは、APIの呼び出しを管理するためにスロットリング制限を設定しています。これにより、過負荷を防ぎ、リソースを保護することができます。主に2つのレベルで制限が設定されています：
- アカウント単位のスロットリング制限: これは、全リージョンのAPI Gatewayに共通の制限です。デフォルトでは、1秒あたり10,000リクエストが許可されています。この制限は、API Gatewayアカウント全体に適用されるため、複数のリージョンでサービスを展開している場合でも、合計でこの制限を超えてリクエストを送ることはできません。
- リージョンごとのAPI制限: 各リージョンにおいて、API Gatewayには独自の制限が設けられています。例えば、リージョンのAPIにはデフォルトで1秒あたり600リクエストまでという制限があり、これを超えるとリクエストは拒否されます。
- エッジ最適化API: エッジ最適化APIは、ユーザーのリクエストを最寄りのCloudFrontエッジロケーションで処理するためのAPIですが、この場合、1秒あたり120リクエストとさらに厳しい制限があります。
2. トークンバケットアルゴリズムによるバースト容量
API Gatewayは、トークンバケットアルゴリズムを使用して、通常時のリクエスト制限を超えて一定量のバーストを許可します。これは、短期間に多くのリクエストが発生する場合でも、システムが過負荷にならないようにするための仕組みです。
- 最大バースト容量: バースト容量は最大5,000リクエストまで対応可能です。これは、API Gatewayの通常のリクエスト制限（たとえば10,000リクエスト/秒）に追加される形で、急なリクエスト増加に対応します。
- バースト容量の管理: バースト容量はAPI Gatewayサービスチームによって管理され、顧客がその容量を増加させるためのリクエストを出すことはできません。リクエストがバースト容量を超えると、429 Too Many Requests エラーが返されます。
3. API Gatewayの制限と料金
API Gatewayには、リクエスト数やトラフィック量に基づいた料金体系があります。制限を意識せずにトラフィックを増加させると、料金が予想以上に高額になる場合があります。制限を越えないように設計を行うことが、コストを抑えるために重要です。
4. 制限に達した場合の対策
API Gatewayの制限に達した場合、リクエストが失敗し、429エラーが返されます。これに対する一般的な対策には以下があります：
- スロットリングの最適化: アプリケーションやAPIのトラフィックを適切に調整し、急激なトラフィックの増加を抑えるための調整が必要です。
- リクエストの再試行: APIリクエストが失敗した場合、一定時間後に再試行するようにアプリケーションを設計することで、リソースが回復した後にリクエストを再度送信することができます。
- スケーリングの検討: 高トラフィックが予想される場合は、API Gatewayの制限を上げる方法を検討したり、バックエンドのLambda関数やインフラをスケーリングすることが考えられます。
5. 制限とパフォーマンスのバランス
API Gatewayを利用する際には、パフォーマンスとコストをバランスよく管理することが求められます。スロットリング制限を超えないようにし、かつ、予測可能なトラフィックの増加に対応するためには、事前にトラフィックの予測とシステムの設計をしっかり行うことが不可欠です。
結論
Amazon API Gatewayは、柔軟でスケーラブルなAPI管理のソリューションを提供しますが、リクエスト制限を超えるとエラーが発生し、サービスに影響を与える可能性があります。これを回避するためには、API Gatewayの制限を理解し、アーキテクチャの最適化、スケーリングの計画、トラフィック管理を適切に行うことが必要です。
リソース/オペレーション | デフォルトのクォータ | 引き上げ可能 |
アカウント単位のスロットリングクォータ | 10,000リクエスト/秒（RPS）（バースト容量最大5,000リクエスト） | いいえ |
リージョンのAPI | 1秒あたり600リクエスト | いいえ |
エッジ最適化API | 1秒あたり120リクエスト | いいえ |
バースト容量 | 最大5,000リクエスト（トークンバケットアルゴリズムに基づく） | 顧客が制御できない |
注意点：
- バーストクォータ（最大5,000リクエスト）は、リージョンごとのアカウント単位の制限（10,000RPS）に基づいており、API Gatewayサービスチームによって決定されます。
- 引き上げ可能な項目は、アカウント単位のスロットリングクォータのみですが、これに関しては顧客が直接変更をリクエストすることはできません。
この表を基に、API Gatewayの制限やバースト容量について把握できます。
一問道場
質問 #120
トピック 1
ある企業がAWS上でソフトウェア・アズ・ア・サービス（SaaS）ソリューションを構築しています。この企業は、複数のAWSリージョンで、同じ本番アカウント内でAWS Lambda統合を伴うAmazon API Gateway REST APIを展開しています。
この企業は、顧客が1秒あたり一定数のAPI呼び出しを行うための容量に対して支払うことができる階層型価格設定を提供しています。プレミアムプランは最大3,000回の呼び出しを提供し、顧客は一意のAPIキーで識別されます。
ピーク使用時間中に複数のリージョンでいくつかのプレミアムプラン顧客が、複数のAPIメソッドから「429 Too Many Requests」のエラーレスポンスを受け取っていることを報告しています。ログによると、Lambda関数は一度も呼び出されていません。
これらの顧客に対するエラーメッセージの原因として考えられるものは何ですか？
A. Lambda関数が同時実行数の制限に達した
B. Lambda関数がリージョンごとの同時実行数制限に達した
C. 企業がAPI Gatewayアカウントの1秒あたりの呼び出し制限に達した
D. 企業がAPI Gatewayのデフォルトのメソッドごとの1秒あたりの呼び出し制限に達した
解説
C. 企業がAPI Gatewayアカウントの1秒あたりの呼び出し制限に達した です。
詳細な解説：
API Gatewayには、アカウント全体での制限があり、1秒あたりのAPI呼び出し回数には制限があります。企業が複数のリージョンでAPI Gatewayを使用しており、プレミアムプランの顧客が多く、特にピーク時に大量のリクエストがある場合、アカウント全体でこの制限を超えると、429 Too Many Requests エラーが発生します。このエラーは、リクエストが許容範囲を超えた場合に返されるもので、Lambda関数が実行される前にAPI Gatewayでブロックされるため、Lambdaが呼び出されないことが確認されている点も合致しています。
他の選択肢について：
- A. Lambda関数が同時実行数の制限に達した: この場合、Lambda関数の呼び出しが多すぎる場合に発生しますが、ログによるとLambdaは呼び出されていないため、この問題は該当しません。
- B. Lambda関数がリージョンごとの同時実行数制限に達した: 同様に、Lambdaの呼び出しが実行されていないため、この選択肢も不正解です。
- D. API Gatewayのデフォルトのメソッドごとの1秒あたりの呼び出し制限に達した: この制限はメソッドごとに設定されていますが、アカウント全体の制限が超過した場合に問題が発生しているため、選択肢Cが正解です。
したがって、正解は C です。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/16dd7ae8-88e2-8078-a702-c8087d571ce7
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
