type
status
date
slug
summary
tags
category
icon
password
书籍
121-GWLB
理論
Gateway Load Balancer (GWLB) の簡単な説明：
GWLBは、ネットワーク層（OSIモデルの第3層）で動作するロードバランサーです。主に、セキュリティツールやネットワークインスペクションツール（ファイアウォール、IDS、ディープパケットインスペクションなど）を効率的に管理・スケーリングするために使用されます。
Gateway Load Balancer (GWLB) は、ネットワークトラフィックを安全ツール（例えば、ファイアウォール、侵入検知システム、ディープパケットインスペクションシステムなど）に転送する役割を果たします。
具体的な流れは次の通りです：
- トラフィックの受信：GWLBはVPCに入ってくるすべてのトラフィックを受け取ります。
- トラフィックの転送：受け取ったトラフィックを、設定されたセキュリティツールにリアルタイムで転送します。
- 結果の返送：セキュリティツールがトラフィックを処理した後、その結果をGWLBが受け取り、適切なターゲット（アプリケーションサーバーなど）に戻します。
GWLBは、これらの処理を透過的に行い、セキュリティチェックを実施しながらも、アプリケーションやユーザーにはその処理が見えないようにします。これにより、トラフィックがセキュリティツールを通過する際に、パフォーマンスに影響を与えずに安全性を確保できます。
一問道場
質問 #121
トピック 1
ある金融会社が、オンプレミスからAWSへのWebアプリケーションの移行を計画しています。この会社は、サードパーティのセキュリティツールを使用してアプリケーションへの着信トラフィックを監視しています。このセキュリティツールは、過去15年間使用されており、ベンダーからはクラウド向けのソリューションは提供されていません。この会社のセキュリティチームは、AWSテクノロジーとの統合方法について懸念しています。
会社は、アプリケーション移行をAWS上のAmazon EC2インスタンスにデプロイする予定です。EC2インスタンスは、専用VPC内でAuto Scalingグループとして実行されます。会社は、セキュリティツールを使用して、VPC内に出入りするすべてのパケットをインスペクトする必要があります。このインスペクションはリアルタイムで行われ、アプリケーションのパフォーマンスに影響を与えてはいけません。ソリューションアーキテクトは、AWS上で高可用性を持つアーキテクチャを設計する必要があります。
この要件を満たすために、ソリューションアーキテクトはどの手順の組み合わせを取るべきでしょうか？（2つ選んでください。）
A. セキュリティツールを新しいAuto Scalingグループ内のEC2インスタンスにデプロイし、既存のVPCに配置する
B. Webアプリケーションをネットワークロードバランサーの背後に配置する
C. セキュリティツールインスタンスの前にアプリケーションロードバランサーを配置する
D. 各アベイラビリティゾーンにゲートウェイロードバランサーをプロビジョニングし、トラフィックをセキュリティツールにリダイレクトする
E. VPC間の通信を円滑にするためにトランジットゲートウェイをプロビジョニングする
解説
この問題の解説です。
要求
- セキュリティツールをAWS環境に統合し、VPC内のすべてのトラフィックをリアルタイムで監視。
- アプリケーションのパフォーマンスに影響を与えないように設計する。
- 高可用性なアーキテクチャを実現する。
選択肢の分析
A. セキュリティツールを新しいAuto Scalingグループ内のEC2インスタンスにデプロイし、既存のVPCに配置する
- メリット: セキュリティツールをEC2インスタンスにデプロイすることで、オンプレミス環境での使用と同様の監視機能をAWSでも利用できます。Auto Scalingを使用することで、トラフィックに合わせてインスタンス数を動的にスケールでき、需要に応じた処理が可能になります。
- デメリット: EC2インスタンスを使用すると、トラフィックの監視がパフォーマンスに影響を与える可能性があり、AWS特有のインフラ設計に最適化されていない場合、効率的でない可能性があります。
B. Webアプリケーションをネットワークロードバランサーの背後に配置する
- メリット: ネットワークロードバランサー（NLB）は、低レイテンシーでTCP/UDPトラフィックを処理でき、高いスループットを維持することができます。これにより、アプリケーションに対するトラフィックが効率的に分散されます。
- デメリット: NLB自体は、セキュリティツールの監視機能には直接関係しないため、この選択肢はセキュリティツールとトラフィックのインスペクションには直接影響しません。
C. セキュリティツールインスタンスの前にアプリケーションロードバランサーを配置する
- メリット: アプリケーションロードバランサー（ALB）は、HTTP/HTTPSトラフィックに最適化され、リクエスト内容に基づいたルーティングが可能です。しかし、ALBは特にセキュリティツールのインスペクションの前に配置しても直接的な利点は少ない可能性があります。
- デメリット: ALBは主にアプリケーション層（HTTP/HTTPS）で動作するため、トラフィックのインスペクションに関しては、ネットワークトラフィック全体を対象とするNLBほど効果的ではありません。
D. 各アベイラビリティゾーンにゲートウェイロードバランサーをプロビジョニングし、トラフィックをセキュリティツールにリダイレクトする
- メリット: ゲートウェイロードバランサー（GWLB）は、トラフィックを複数のセキュリティツール（例えば、ネットワークインスペクションツール）に分散するための最適な方法です。トラフィックはシームレスにセキュリティツールに転送され、インスペクションが行われます。GWLBは高可用性を確保し、トラフィックのスループットを最大化します。
- デメリット: このアーキテクチャは少し高度で、ゲートウェイロードバランサーの設定や運用に関して慎重に管理する必要があります。しかし、高可用性とパフォーマンスの観点からは非常に効果的です。
E. VPC間の通信を円滑にするためにトランジットゲートウェイをプロビジョニングする
- メリット: トランジットゲートウェイは、複数のVPC間の通信を簡素化するために使用されますが、このシナリオではセキュリティツールのトラフィックインスペクションには直接関連しません。
- デメリット: トランジットゲートウェイは、セキュリティツールのインスペクション要件に関する直接的な解決策ではないため、最適ではありません。
正解: D と A
- D: ゲートウェイロードバランサーを使用することで、トラフィックを効率的にセキュリティツールにリダイレクトし、リアルタイムでインスペクションが可能になります。高可用性を確保し、アーキテクチャ全体のパフォーマンスを最適化できます。
- A: セキュリティツールを新しいAuto Scalingグループ内のEC2インスタンスにデプロイすることで、トラフィック監視が可能になります。Auto Scalingを使用してリソースを動的に調整でき、必要に応じてスケールアップできます。
この2つのステップにより、高可用性を維持しながら、リアルタイムのトラフィックインスペクションが可能となり、パフォーマンスにも影響を与えません。
122-IoT Core
理論
1. IoTデータの取り扱いと処理
IoT（Internet of Things、モノのインターネット）デバイスから得られるデータは、通常、センサーや他のデバイスからリアルタイムで送信されます。このデータは多くの場合、ベンダー固有の形式であり、標準化されたJSONやCSV形式ではないことが一般的です。このため、データの処理は次のようなステップで行われます。
- データ収集: IoTセンサーから送信されるデータは、通信手段（例えばHTTP、MQTTなど）を通じて受信されます。
- データ変換と前処理: IoTセンサーが送るデータは、各ベンダーごとの独自形式を持っていることが多いため、これを一貫した形式（通常はJSONやCSV）に変換する必要があります。
- データ解析: 変換されたデータを用いて分析を行います。この解析にはAWSのサービスを利用してスケーラブルかつ効率的にデータを処理できます。
2. AWS IoT Core
AWS IoT Coreは、IoTデバイスとの接続を簡素化するAWSのフルマネージドサービスです。IoTデバイスからのデータをクラウドに安全に送信し、リアルタイムで処理できます。
- 特徴:
- 高いスケーラビリティ：数百万のIoTデバイスと接続でき、センサーのデータをリアルタイムで受け取ります。
- メッセージング機能：MQTTプロトコルやHTTPSを使用して、センサーからデータを送信できます。
- ルールエンジン：データが受信されると、設定したルールに基づいて自動的に処理やアクションをトリガーできます。
3. AWS Lambda
AWS Lambdaは、サーバーレスコンピューティングサービスで、コードをアップロードするだけでインフラの管理を不要にします。イベント駆動型で動作し、例えばIoT Coreから送信されたデータに基づいて自動的に実行されます。
- 特徴:
- サーバーレス: インフラを管理する必要がなく、スケーラビリティが自動的に処理されます。
- イベント駆動型: IoTセンサーから送られてくるデータをトリガーとして処理を開始できます。
- 短期間で処理可能: 複雑な処理も、データ量に応じて効率的に処理できます。
4. Amazon S3とデータ保存
Amazon S3（Simple Storage Service）は、スケーラブルで高可用性を誇るオブジェクトストレージサービスです。IoTセンサーから送信されたデータや解析結果を保存する場所として利用できます。
- 特徴:
- 耐久性と可用性: S3は高い耐久性（99.999999999%）を誇り、データの安全な保存が可能です。
- スケーラビリティ: データ量が増えても自動的にスケールします。
- 低コスト: 長期的なデータ保存やバックアップに適しており、低コストで利用できます。
5. Amazon Athenaとデータ分析
Amazon Athenaは、Amazon S3に保存されたデータを直接SQLで分析できるインタラクティブクエリサービスです。Athenaを使うことで、大量のデータを迅速にクエリし、分析結果を即座に得ることができます。
- 特徴:
- サーバーレス: インフラ管理なしで、S3上のデータを直接クエリできます。
- SQLサポート: SQLを使用してデータにアクセスし、簡単に分析が可能です。
- パフォーマンス: データのスキャンを最適化し、大規模なデータセットに対しても効率的にクエリを実行できます。
6. AWS Glueとデータカタログ
AWS Glueは、データの抽出、変換、ロード（ETL）の処理をサポートするフルマネージドサービスです。また、データカタログ機能を持ち、データセットを効率的に管理できます。
- 特徴:
- ETL処理: IoTデータのフォーマット変換やクレンジングを行い、データを一貫した形式に整えます。
- データカタログ: データのメタデータを管理し、他のAWSサービス（例えばAthenaやRedshift）からデータを簡単に参照できるようにします。
- スケーラビリティ: 大規模なデータに対してスケーラブルな処理を提供します。
7. コスト最適化
AWSでは、適切なサービスを組み合わせることでコストを最適化できます。特に、サーバーレスのサービス（Lambda、Athenaなど）は、利用した分だけ料金が発生し、インフラ管理の手間を省けるため、非常にコスト効率が良いです。
- コスト最適化ポイント:
- 使用した分だけ支払う: LambdaやAthenaは、リソース使用量に応じて課金され、予測可能でコスト管理がしやすいです。
- スケーラビリティ: 自動的にスケーリングするため、必要に応じてリソースを追加したり削減したりできます。
結論
この問題に関連する本質的な知識は、IoTデータのリアルタイム処理、サーバーレスアーキテクチャ、データ保存と分析の最適化に関するものです。AWSのサービス（IoT Core、Lambda、S3、Glue、Athenaなど）を組み合わせることで、効率的かつコスト最適化されたデータ処理と分析を実現できるという点が重要です。
一問道場
質問 #122
トピック 1
ある企業は、異なるベンダーから購入したアプライアンスを所有しています。これらのアプライアンスにはすべてIoTセンサーが搭載されており、センサーはベンダーの独自形式で状態情報を送信し、レガシーアプリケーションがその情報を解析してJSON形式に変換します。この解析は簡単ですが、各ベンダーには固有の形式があります。毎日、アプリケーションはすべてのJSONレコードを解析し、そのレコードを分析用にリレーショナルデータベースに保存します。
この企業は、より高速でコスト効率の良い新しいデータ分析ソリューションを設計する必要があります。
どのソリューションがこれらの要件を満たしますか？
A. IoTセンサーをAWS IoT Coreに接続します。ルールを設定してAWS Lambda関数を呼び出し、情報を解析して.csvファイルをAmazon S3に保存します。AWS Glueを使用してファイルをカタログ化します。分析にはAmazon AthenaとAmazon QuickSightを使用します。
B. アプリケーションサーバーをAWS Fargateに移行し、IoTセンサーから情報を受け取り、リレーショナル形式に解析します。解析した情報をAmazon Redshiftに保存して分析します。
C. AWS Transfer for SFTPサーバーを作成します。IoTセンサーのコードを更新して、情報を.csvファイルとしてSFTP経由でサーバーに送信します。AWS Glueを使用してファイルをカタログ化します。分析にはAmazon Athenaを使用します。
D. AWS Snowball Edgeを使用して、IoTセンサーからデータを直接収集し、ローカルで分析を行います。定期的にデータをAmazon Redshiftに収集して、グローバルな分析を行います。
解説
A. IoTセンサーをAWS IoT Coreに接続し、AWS Lambda関数を使用して解析した情報をAmazon S3に保存し、Amazon AthenaとQuickSightで分析
- 理由: AWS IoT Coreは、IoTデバイス（センサー）との接続に最適です。Lambdaを使って各ベンダー固有のフォーマットを解析し、結果をCSVファイルとしてAmazon S3に保存します。AWS Glueを使用してS3内のファイルをカタログ化し、その後Amazon AthenaでSQLクエリを実行してデータを分析できます。さらに、QuickSightを使って可視化やダッシュボード作成を行い、データ分析を支援します。これにより、サーバーレスでスケーラブルなデータパイプラインを構築でき、高速でコスト効率的な分析が可能です。
- 適切な選択肢。
B. アプリケーションサーバーをAWS Fargateに移行し、IoTセンサーから情報を受け取り解析後、Amazon Redshiftに保存して分析
- 理由: AWS Fargateはコンテナベースのサービスで、サーバーレスでアプリケーションを実行できますが、この場合、毎日送信される大量のデータに対して、サーバーレスのアプローチ（LambdaやAthena）のほうが適しています。Fargateの使用はやや過剰なリソースを必要とし、コスト面でも効率的ではない可能性があります。Redshiftへのデータ保存もできますが、これは他のソリューションよりもコストが高くなりがちです。
- 不適切な選択肢。
C. AWS Transfer for SFTPサーバーを使用し、CSVファイルを受け取り、AWS Glueでカタログ化してAmazon Athenaで分析
- 理由: AWS Transfer for SFTPは、セキュアなファイル転送を提供しますが、これを使う場合、IoTセンサーがCSV形式でデータを送信しなければならないという制約があります。IoTセンサーが独自の形式でデータを送信するため、このオプションではその形式の変換処理が必要です。さらに、SFTP経由で送信されるデータは毎日バッチで送られる可能性があり、リアルタイム性が求められる場合には不向きです。
- 不適切な選択肢。
D. AWS Snowball Edgeを使用して、IoTセンサーからデータを収集し、ローカルで分析、定期的にRedshiftに転送して分析
- 理由: AWS Snowball Edgeは、データの大規模な物理的転送やローカル分析に役立ちますが、IoTセンサーからのデータの定期的なローカル収集に適しています。ローカルで分析するためには、センサーから収集したデータを一時的に保存し、定期的にRedshiftに転送してグローバル分析を行います。しかし、リアルタイム性や低遅延での分析を求める場面には向いていません。Snowball Edgeを使うシナリオは、コストやパフォーマンスの最適化が難しい場合です。
- 不適切な選択肢。
結論
最も適切な選択肢は A です。AWS IoT CoreとLambda、S3、Athenaを組み合わせることで、リアルタイムでスケーラブルかつコスト効率の高いデータ分析を実現できます。
123-Direct Connect
理論
一問道場
質問 #123
トピック 1
ある企業がいくつかのアプリケーションをAWSに移行しています。この企業は、ネットワークおよびセキュリティ戦略が確定した後、アプリケーションの移行とモダナイゼーションを迅速に行いたいと考えています。企業は中央のネットワークアカウントにAWS Direct Connect接続を設定しました。企業は今後、数百のAWSアカウントおよびVPCを使用する予定です。企業のネットワークは、AWSのリソースにシームレスにアクセスでき、すべてのVPCと通信できる必要があります。また、企業は自社のデータセンターを通じて、クラウドリソースをインターネットにルーティングしたいと考えています。
この要件を満たすために、どの組み合わせの手順を選ぶべきでしょうか？（3つ選んでください。）
A. 中央アカウントにDirect Connectゲートウェイを作成します。各アカウントで、Direct Connectゲートウェイと仮想プライベートゲートウェイのアカウントIDを使用して、関連付け提案を作成します。
B. 中央ネットワークアカウントにDirect Connectゲートウェイとトランジットゲートウェイを作成します。トランジットゲートウェイをDirect Connectゲートウェイに接続します（トランジットVIFを使用）。
C. インターネットゲートウェイをプロビジョニングします。インターネットゲートウェイをサブネットに接続し、ゲートウェイを通じてインターネットトラフィックを許可します。
D. トランジットゲートウェイを他のアカウントと共有し、VPCをトランジットゲートウェイに接続します。
E. 必要に応じてVPCピアリングをプロビジョニングします。
F. プライベートサブネットのみをプロビジョニングし、トランジットゲートウェイとカスタマーゲートウェイに必要なルートを開放して、AWSからデータセンターのNATサービスを通じてインターネットに流れるアウトバウンドトラフィックを許可します。
解説
選択肢 B, D, F についての解説を行います。
B. Direct Connectゲートウェイとトランジットゲートウェイを中央ネットワークアカウントに作成し、トランジットVIFで接続
- 解説:
- これは正しい選択肢です。Direct Connectゲートウェイを使ってオンプレミスのデータセンターとAWSを接続し、さらにトランジットゲートウェイを使って複数のVPCを接続するという方法です。トランジットVIFを使用して、Direct Connectとトランジットゲートウェイを接続し、AWS全体のネットワークを一元管理することができます。
- 理由: トランジットゲートウェイを使うことで、複数のVPC間での通信を効率的にルーティングできます。また、Direct Connectゲートウェイとの接続により、オンプレミスとAWSの間の通信が安定します。
D. トランジットゲートウェイを他のアカウントと共有し、VPCを接続
- 解説:
- これは正しい選択肢です。トランジットゲートウェイを他のAWSアカウントと共有することができます。これにより、複数のVPCを簡単に接続し、リソースへのアクセスを効率的に管理できます。複数アカウントのVPC間での接続管理が簡素化され、スケーラビリティが向上します。
- 理由: 大規模な環境で複数アカウントを利用する場合、トランジットゲートウェイの共有は非常に便利です。
F. プライベートサブネットのみをプロビジョニングし、トランジットゲートウェイとカスタマーゲートウェイにルートを設定
- 解説:
- この選択肢は、VPCがプライベートサブネットだけを使用し、インターネット接続をオンプレミス経由で行う設定です。トランジットゲートウェイとカスタマーゲートウェイを使用して、VPCからインターネットへのルートを確立します。オンプレミスのデータセンターを経由してインターネットにアクセスするため、NATゲートウェイを使用するのではなく、オンプレミスのデバイスを利用します。
- 理由: オンプレミス経由でインターネットアクセスを行うという要件に沿った方法です。ただし、この方法が最適かどうかは、オンプレミスデータセンターの設定や要件に依存します。
なぜ B, D, F が正しいか:
- B はオンプレミスとAWSを接続するためのトランジットゲートウェイとDirect Connectゲートウェイの利用法で、AWS上のネットワークの中心的な管理方法として適切です。
- D は、トランジットゲートウェイを他のアカウントと共有することで、複数アカウント間で効率的にVPC接続ができるため、スケーラビリティを重視する要件に適しています。
- F は、プライベートサブネットとトランジットゲートウェイを使用してオンプレミス経由でインターネット接続を行うため、要件に沿った形でのインターネット接続を実現します。
これらの選択肢が、このシナリオに最も適した構成を提供します。
124-AWS Organizations
理論
1. AWS Organizationsとは？
AWS Organizationsは、複数のAWSアカウントを統合的に管理するためのサービスです。企業や大規模な組織で多数のAWSアカウントを運用する場合に、アカウント管理を効率化し、一貫したセキュリティ制御や請求管理を行うために使用されます。AWS Organizationsを使用することで、以下の利点があります：
- 一元管理: 複数のAWSアカウントを単一の管理者アカウントから管理できます。
- 組織単位（OU）: アカウントをグループにまとめ、グループごとに異なるポリシーを適用することが可能です。
- サービスコントロールポリシー(SCP): 各アカウントまたはOUに対して、特定のアクションを許可または禁止するポリシーを適用できます。
2. サービスコントロールポリシー (SCP)
SCPはAWS Organizationsの強力なセキュリティ機能で、組織内のアカウントに対して、実行できる操作を制限します。SCPを使うと、リソースの作成や変更を管理するだけでなく、アカウントが実行できる操作を柔軟に制御できます。SCPはIAMポリシーとは異なり、IAMポリシーはリソースに対する権限を定義するのに対し、SCPはアカウント全体の許可/拒否を定義します。
例えば、リザーブドインスタンスの購入や変更を制限したい場合、SCPを使って
ec2:PurchaseReservedInstancesOfferingやec2:ModifyReservedInstancesのアクションを拒否するポリシーを適用することができます。SCPは組織単位（OU）単位で適用できるため、特定のビジネスユニットやグループに対して異なる制限を設けることが可能です。3. IAMポリシー
IAMポリシーは、AWSアカウント内で特定のリソースに対してアクセス制御を実施するために使用されます。IAMポリシーは、ユーザー、グループ、ロールに対して権限を定義します。リザーブドインスタンスの購入や変更を制限するためには、IAMポリシーを使って、特定のアクションを禁止することができます。
ただし、IAMポリシーは、組織全体で一貫した制御を行うためには不向きです。各アカウントごとに設定を行う必要があり、アカウント数が多い場合には管理が煩雑になります。
4. 中央集権的なリソース管理とセキュリティ制御のベストプラクティス
大規模なAWS環境では、中央集権的なリソース管理とセキュリティ制御を行うことが重要です。以下は、ベストプラクティスとして考慮すべき点です：
1. AWS Organizationsを使用してアカウントを管理する
- 複数アカウントをAWS Organizationsで管理し、中央で一貫したセキュリティポリシーを適用します。
- これにより、全アカウントに対して一貫した管理や監視が可能になります。
2. SCPを使用して組織全体のセキュリティポリシーを定義する
- SCPを使って、アカウントが実行できる操作を制限します。これにより、例えばリザーブドインスタンスの購入や変更など、特定の操作をビジネスユニット単位で制限することができます。
- SCPは組織全体に対してポリシーを適用するため、個々のアカウントで手動でポリシーを設定する必要がなく、管理負担が軽減されます。
3. IAMポリシーを適切に使い分ける
- IAMポリシーは、特定のユーザーやサービスに対して権限を細かく設定するために使用します。
- ただし、SCPのようにアカウント全体に適用されるポリシーとは異なり、IAMポリシーは個別のリソースに対してアクセス制御を行います。
4. AWS Configでの監査
- AWS Configを使用して、ポリシーの適用状況を監査し、コンプライアンスをチェックします。
- Configルールを作成することで、ポリシーが適切に適用されているかどうかを確認できます。
5. 組織のリソースとアカウント管理
大規模なAWS環境では、リソースの整合性とセキュリティを保つために、アカウントの構造とリソースの管理方法に関する戦略を練ることが重要です。例えば、複数のビジネスユニットやプロジェクトがある場合、それぞれのユニットに対して異なるセキュリティポリシーやアクセス制御を設定することが求められます。
まとめ
この問題に関連する本質的な知識は、複数のAWSアカウントを効率的かつセキュアに管理するための方法として、AWS Organizationsの利用、SCPの適用、IAMポリシーによる細かい制御、そしてAWS Configによる監査機能の活用です。これらを駆使することで、大規模なAWS環境におけるリソース管理やセキュリティ制御を効率的に行うことができます。
一問道場
質問 #124
トピック 1
ある企業には数百のAWSアカウントがあります。この企業は最近、新しいリザーブドインスタンスを購入したり、既存のリザーブドインスタンスを変更したりするための中央集権的な内部プロセスを実装しました。このプロセスでは、リザーブドインスタンスを購入または変更したい各ビジネスユニットが、専任のチームにリクエストを送信する必要があります。それ以前は、ビジネスユニットが自分のAWSアカウント内でリザーブドインスタンスを直接購入または変更していました。
ソリューションアーキテクトは、最も安全な方法で新しいプロセスを強制する必要があります。
これらの要件を満たすために、ソリューションアーキテクトはどの組み合わせの手順を取るべきですか？（2つ選択してください）
A. すべてのAWSアカウントがAWS Organizationsの一部であり、すべての機能が有効になっていることを確認する。
B. AWS Configを使用して、
ec2:PurchaseReservedInstancesOffering アクションと ec2:ModifyReservedInstances アクションのアクセスを拒否するIAMポリシーの添付状況を報告する。C. 各AWSアカウントで、
ec2:PurchaseReservedInstancesOffering アクションと ec2:ModifyReservedInstances アクションを拒否するIAMポリシーを作成する。D. SCP（サービスコントロールポリシー）を作成し、
ec2:PurchaseReservedInstancesOffering アクションと ec2:ModifyReservedInstances アクションを拒否する。このSCPをAWS Organizationsの各OU（組織単位）に適用する。E. すべてのAWSアカウントが、統合請求機能を使用するAWS Organizationsの一部であることを確認する。
解説
この問題は、AWSアカウントの管理においてリザーブドインスタンスの購入・変更プロセスを中央集権化し、そのプロセスをセキュアに強制するための最適な方法を問うものです。企業は、特定のビジネスユニットが直接リザーブドインスタンスを購入したり変更したりすることを防ぎ、専任のチームを通じてこれらの操作を行わせたいという要件です。
以下は各選択肢の詳細な解説です。
A. すべてのAWSアカウントがAWS Organizationsの一部であり、すべての機能が有効になっていることを確認する。
- 解説: AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスであり、アカウントを組織にまとめることで、集中管理やセキュリティポリシーの適用が可能になります。このオプションは、組織内のすべてのアカウントに対してポリシーを適用し、セキュリティを強化するために必要です。すべての機能を有効にすることで、組織全体にサービスコントロールポリシー（SCP）を適用できます。
- 必要性: このオプションは、アカウント間で統一された管理とセキュリティ制御を確立するために非常に重要です。
B. AWS Configを使用して、ec2:PurchaseReservedInstancesOffering アクションと ec2:ModifyReservedInstances アクションのアクセスを拒否するIAMポリシーの添付状況を報告する。
- 解説: AWS Configはリソースの設定を追跡・監視するサービスですが、アクセス制御を実施するツールではありません。IAMポリシーを適用すること自体はConfigで実施できませんが、ポリシーが適用されているかどうかを追跡することは可能です。しかし、ポリシーを「適用する」という点では他の方法が有効です。したがって、このオプションはこの要件に対して十分ではありません。
- 不適切: AWS Configは監査目的には有効ですが、ポリシーの適用に直接関わるものではありません。
C. 各AWSアカウントで、ec2:PurchaseReservedInstancesOffering アクションと ec2:ModifyReservedInstances アクションを拒否するIAMポリシーを作成する。
- 解説: この方法では、各AWSアカウントで個別にIAMポリシーを設定し、リザーブドインスタンスの購入や変更を制限します。しかし、このアプローチは手動で設定しなければならず、複数アカウントに対して一貫性を持たせるのが難しく、管理負担が増加します。また、IAMポリシーは各アカウント単位での設定が必要なため、規模が大きくなると管理が煩雑になります。
- 不適切: この方法は非効率であり、大規模な環境では適切ではありません。
D. SCP（サービスコントロールポリシー）を作成し、ec2:PurchaseReservedInstancesOffering アクションと ec2:ModifyReservedInstances アクションを拒否する。このSCPをAWS Organizationsの各OU（組織単位）に適用する。
- 解説: AWS OrganizationsのSCPは、組織内の複数アカウントに対してセキュリティポリシーを一元的に適用できる強力なツールです。SCPを使用すると、組織内のすべてのアカウントに対して特定のアクションを拒否することができます。この方法は、中央集権的な管理を可能にし、アカウント数が多い環境でも一貫性を持ってセキュリティポリシーを適用できるため、非常に効果的です。
- 適切: この方法は、リザーブドインスタンスの購入・変更に関するプロセスを確実に管理し、ビジネスユニットが直接操作できないようにするための最良の選択肢です。
E. すべてのAWSアカウントが、統合請求機能を使用するAWS Organizationsの一部であることを確認する。
- 解説: 統合請求機能は、複数のAWSアカウントの請求を一元管理するための機能であり、リザーブドインスタンスの管理や購入には直接的な影響を与えません。これにより、請求の管理は簡素化されますが、リザーブドインスタンスの購入・変更の制御を行うためには他の方法が必要です。
- 不適切: 請求の管理には役立ちますが、リザーブドインスタンスの購入や変更を制御するための方法ではありません。
正しい選択肢: A と D
- A: AWS Organizationsでアカウントを一元管理することで、セキュリティポリシーを一貫して適用できます。
- D: SCPを使用して、組織全体でリザーブドインスタンスの購入・変更を禁止することで、プロセスを安全かつ確実に強制できます。
この方法で、リザーブドインスタンスの購入・変更に関する中央集権的な管理が可能となり、セキュリティを確保しながら、全アカウントに対して統一的なルールを適用できます。
125-Amazon Aurora 自動フェイルオーバー
理論
1. RDS for MySQLのMulti-AZとフェイルオーバー
Amazon RDS for MySQLは、Multi-AZデプロイメントを提供しており、これにより高可用性を実現します。Multi-AZデプロイメントでは、RDSインスタンスのデータが2つの異なるアベイラビリティゾーン（AZ）に同期的にレプリケートされます。これにより、障害が発生した際に、バックアップのAZから自動的にフェイルオーバーが発生し、ダウンタイムを最小限に抑えることができます。
ただし、MySQLのような一般的なデータベースエンジンでは、フェイルオーバーに数十秒かかることがあるため、さらにフェイルオーバーの時間を短縮する方法が求められることがあります。
2. RDS Proxy
RDS Proxyは、Amazon RDSのデータベース接続プーリングを提供するサービスです。RDS Proxyを使用すると、データベースの接続を効率的に管理でき、フェイルオーバーの際に接続の再確立を高速化できます。特に、アプリケーションとデータベースの接続が切れた後の再接続時間を短縮する効果があります。
- 接続プーリング：アプリケーションはRDS Proxyに接続し、RDS Proxyがデータベース接続を管理します。これにより、接続の数を効率的に制御でき、データベースインスタンスへの負荷を減らします。
- フェイルオーバー時の高速接続：RDS Proxyは、フェイルオーバーが発生しても、アプリケーションが接続を迅速に再確立できるように支援します。これにより、アプリケーションのダウンタイムを大幅に短縮できます。
3. Amazon Aurora MySQL
Amazon Auroraは、MySQL互換のフルマネージドデータベースサービスで、MySQLの性能を大幅に上回る性能を提供します。Auroraは、以下の理由から非常に高い可用性を提供します。
- 自動フェイルオーバー：Auroraでは、データベースインスタンスが障害を検出すると、秒単位で自動的に他のインスタンスにフェイルオーバーを行います。これにより、RDS for MySQLのように数十秒間のダウンタイムが発生することなく、迅速な復旧が可能です。
- 分散ストレージ：Auroraは、6つのコピーを分散ストレージに格納し、1つのAZで障害が発生してもデータが失われることはありません。
- Aurora Replicas：Auroraは、Aurora Replicasを作成して、読み取り専用のレプリカを利用することができます。これにより、読み取り負荷を分散させたり、フェイルオーバー時の復旧を迅速化することができます。
4. Aurora Replicas
Aurora Replicasは、Auroraクラスタ内で使用できる読み取り専用のレプリカで、次のような利点があります。
- 読み取りスケーリング：Aurora Replicasを使うことで、読み取り要求のスケーリングが可能です。これにより、アプリケーションの読み取り性能を向上させ、データベースの負荷を分散できます。
- フェイルオーバーの迅速化：Auroraのレプリカは、主インスタンスに障害が発生した場合に自動的に昇格して、即座にプライマリインスタンスとして機能します。これにより、ダウンタイムを最小化できます。
5. フェイルオーバー時の影響を最小化するためのベストプラクティス
- アプリケーション接続の管理：アプリケーションがデータベースと接続している場合、接続管理が非常に重要です。RDS Proxyのような接続プールを使用すると、アプリケーションはデータベースの可用性に依存せず、迅速に接続を再確立できます。
- Auroraへの移行：RDS for MySQLからAmazon Aurora MySQLに移行することで、フェイルオーバー時間を数秒に短縮することが可能です。Auroraは、MySQLの互換性を保ちながら、高可用性とスケーラビリティを提供します。
- Aurora Replicasの活用：Aurora Replicasを活用することで、フェイルオーバー時に読み取り専用のインスタンスに切り替えることができ、サービスの中断を最小限に抑えることができます。
結論
AWSで高可用性を実現するためには、RDS ProxyやAurora MySQLを活用することで、フェイルオーバー時間を短縮し、ダウンタイムを最小化することができます。これにより、特に重要なアプリケーションに対して、より高い可用性とパフォーマンスを提供することができます。
一問道場
問題 #125
トピック 1
ある企業は、データを保存するためにAmazon RDS for MySQLデータベースを使用する重要なアプリケーションを実行しています。RDS DBインスタンスはMulti-AZモードで展開されています。
最近、RDSデータベースのフェイルオーバーテストが行われ、アプリケーションに40秒の停止が発生しました。
ソリューションアーキテクトは、停止時間を20秒未満に短縮するためのソリューションを設計する必要があります。
この要件を満たすためにソリューションアーキテクトが取るべき手順の組み合わせはどれですか？（3つ選んでください。）
A. データベースの前にAmazon ElastiCache for Memcachedを使用する
B. データベースの前にAmazon ElastiCache for Redisを使用する
C. データベースの前にRDS Proxyを使用する
D. データベースをAmazon Aurora MySQLに移行する
E. Amazon Auroraレプリカを作成する
F. RDS for MySQLのリードレプリカを作成する
解説
問題：
ある企業が重要なアプリケーションを実行しており、そのデータベースは Amazon RDS for MySQL を使用しています。このデータベースは Multi-AZ モードでデプロイされていますが、最近行ったRDSデータベースのフェイルオーバーテストで、アプリケーションのダウンタイムが 40秒 発生しました。ソリューションアーキテクトは、このダウンタイムを 20秒未満 に短縮する方法を設計する必要があります。
正しい選択肢：
C, D, E
解説：
C. Use RDS Proxy in front of the database
- RDS Proxy を使うことで、データベース接続の管理を効率的に行い、接続プールを維持することができます。これにより、データベースのフェイルオーバー時に、アプリケーションがデータベース接続をすぐに再確立できるようになります。
- RDS Proxyを利用すると、フェイルオーバー時の接続の中断を最小限に抑えることができ、ダウンタイムの短縮に大きく貢献します。
D. Migrate the database to Amazon Aurora MySQL
- Amazon Aurora MySQL は、RDS for MySQL よりも高い可用性と性能を提供します。Auroraは、フェイルオーバーの際に再起動時間が通常 数秒 で済むため、ダウンタイムを大幅に短縮できます。
- RDS for MySQL と比較して、Auroraはデータベースのフェイルオーバー時間が短く、より高い可用性を実現します。
E. Create an Amazon Aurora Replica
- Aurora Replica は、Auroraデータベースの読み取り専用レプリカを作成する方法で、フェイルオーバー時のダウンタイムを短縮するために役立ちます。Auroraは自動的に最適なインスタンスを選んでフェイルオーバーを行うため、フェイルオーバー時間が非常に短くなります。
- Auroraのレプリカを使用すると、ダウンタイムがさらに短縮され、フェイルオーバーが発生した際の影響を最小化できます。
結論：
- C (RDS Proxy) を使用して接続の維持を行い、D (Aurora MySQLへの移行) によりフェイルオーバー時間を短縮し、さらに E (Aurora Replica) を作成することで、読み取り専用インスタンスを利用した冗長性とダウンタイムの短縮が実現します。
これらの3つのステップを組み合わせることで、アプリケーションのダウンタイムを 20秒未満 に抑えることができます。
126-スイッチロール
理論
1. IAMロールの信頼関係
- IAMロールは、特定のアクセス権限を持つ仮想的な役割です。
- 他のAWSアカウントのユーザーやサービスがこのロールを引き受けることで、リソースにアクセスできます。
- 信頼ポリシーで、どのアカウントやロールがそのロールを引き受けられるかを設定します。
2. クロスアカウントアクセス
- 顧客アカウント（org2）で、協力会社アカウント（org1）がアクセスできるようにIAMロールを作成します。
- このロールの信頼ポリシーに、org1のロールを指定し、アクセスを許可します。
- org1は、自分のIAMロールを使って顧客アカウントのリソースにアクセスします。
3. 最小特権アクセスと外部ID
- 最小特権：アクセス権限は必要最低限に留めるべきです。
- 外部ID：セキュリティを強化するために、アクセス時に外部IDを使って確認します。
まとめ：
AWSで安全にリソースにアクセスするためには、IAMロールを使って信頼ポリシーを設定し、クロスアカウントアクセスを実現します。
一問道場
質問 #126
トピック 1
AWS パートナー企業が AWS Organizations を使用して org1 という組織を作成し、サービスを構築しています。このサービスでは、パートナー企業が別の組織である org2 の顧客アカウント内の AWS リソースにアクセスする必要があります。パートナー企業は、API またはコマンドラインツールを使用して顧客アカウントへの最小特権のセキュリティアクセスを確立する必要があります。
org1 が org2 のリソースにアクセスするために最も安全な方法はどれですか？
A. 顧客はパートナー企業に AWS アカウントのアクセスキーを提供し、ログインして必要な作業を実行させる。
B. 顧客は IAM ユーザーを作成し、必要な権限をその IAM ユーザーに割り当てます。その後、顧客はパートナー企業に認証情報を提供し、ログインして必要な作業を実行させる。
C. 顧客は IAM ロールを作成し、必要な権限をその IAM ロールに割り当てます。その後、パートナー企業は IAM ロールの Amazon リソース名 (ARN) を使用して、必要な作業を実行するためにアクセスをリクエストします。
D. 顧客は IAM ロールを作成し、必要な権限をその IAM ロールに割り当てます。その後、パートナー企業は IAM ロールの Amazon リソース名 (ARN) を使用し、IAM ロールの信頼ポリシーに外部 ID を含めて、必要な作業を実行するためにアクセスをリクエストします。
解説
この問題では、AWS Organizations を使用して異なる組織間で最小特権のセキュリティアクセスを確立する方法について尋ねられています。セキュリティの観点から、パートナー企業（org1）が顧客アカウント（org2）のリソースにアクセスする際に最も安全な方法は、適切な IAM ロールの設定を利用することです。選択肢を見ていきましょう。
A. 顧客はパートナー企業に AWS アカウントのアクセスキーを提供し、ログインして必要な作業を実行させる。
これは最も危険な方法です。AWS アカウントのアクセスキーを他者に提供することは、セキュリティ上のリスクを伴います。アクセスキーを共有することで、その情報が漏洩する可能性が高まり、最小特権の原則にも反します。したがって、これを選ぶことは推奨されません。
B. 顧客は IAM ユーザーを作成し、必要な権限をその IAM ユーザーに割り当てます。その後、顧客はパートナー企業に認証情報を提供し、ログインして必要な作業を実行させる。
IAM ユーザーを作成し、認証情報をパートナー企業に提供する方法も、アクセスキーを共有することと似たリスクがあります。特に認証情報が漏洩する可能性が高く、アクセスを許可する範囲も広がってしまうため、最小特権のアプローチとしては不適切です。
C. 顧客は IAM ロールを作成し、必要な権限をその IAM ロールに割り当てます。その後、パートナー企業は IAM ロールの Amazon リソース名 (ARN) を使用して、必要な作業を実行するためにアクセスをリクエストします。
IAM ロールを使用してアクセスを提供する方法は、AWS の推奨されるセキュアな方法です。IAM ロールを使用することで、パートナー企業は特定のリソースに対してアクセス権を付与され、必要な作業だけを実行できます。ただし、この方法では信頼ポリシーに外部 ID を追加しないため、さらなるセキュリティ対策が欠けている可能性があります。
D. 顧客は IAM ロールを作成し、必要な権限をその IAM ロールに割り当てます。その後、パートナー企業は IAM ロールの Amazon リソース名 (ARN) を使用し、IAM ロールの信頼ポリシーに外部 ID を含めて、必要な作業を実行するためにアクセスをリクエストします。
これが最も安全な方法です。外部 ID を使用することで、アクセス権を持つパートナー企業が実際にアクセスをリクエストする際に、認証を強化できます。この方法は、最小特権アクセスを確保しつつ、アクセスの正当性を高めるための追加的なセキュリティ対策を提供します。外部 ID は、リクエスト元が確かに正当な企業であることを確認するための強力な手段となります。
結論:
最も安全で推奨される方法は D です。IAM ロールを使用し、外部 ID を信頼ポリシーに追加することで、最小特権アクセスを実現しつつ、セキュリティを強化することができます。
127-EKSとECS
理論
EKSとECSの違いと選択基準
AWSでコンテナを管理する際、EKSとECSはよく比較されます。それぞれの特徴と選択基準を理解することが重要です。
EKS（Amazon Elastic Kubernetes Service）
- 特徴:
- Fargate対応: 無サーバーでPodを動かせるが、Fargateプロファイルの設定が必要。
- 柔軟性: マルチクラウドやオンプレミス環境と統合しやすい。
- 運用負担: Kubernetesの管理知識が求められ、運用負担がやや高い。
Kubernetesを利用できるマネージドサービス。クラスタの設定や管理が必要。
- 適用例:
- Kubernetesベースのアプリケーションを既に使用している場合。
- マルチクラウド環境を構築したい場合。
ECS（Amazon Elastic Container Service）
- 特徴:
- Fargate対応: 追加設定が少なく、無サーバーでタスクを動かせる。
- AWS依存: 他のクラウドとの統合は難しいが、AWS内での最適化が容易。
- 運用負担: 設定が簡単で、運用負担が少ない。
AWSに特化したコンテナ管理サービス。設定がシンプルで、Fargateと簡単に統合可能。
- 適用例:
- 簡単にコンテナをデプロイしたい場合。
- 完全にAWS環境に依存している場合。
選択基準
- 運用負担を最小化: ECS＋Fargateが最適。
- 柔軟性を重視: EKSが適しているが、設定が複雑。
- コスト最適化: アプリケーションの要件と利用頻度に応じて選択。
一問道場
質問 #127
トピック 1
配送会社が現在使用しているサードパーティ製のルート計画アプリケーションをAWSに移行する必要があります。サードパーティは、パブリックレジストリからサポートされたDockerイメージを提供します。このイメージは、ルートマップを生成するために必要なだけのコンテナで実行できます。
会社は配送エリアをセクションごとに分けて、供給ハブから顧客への最短距離を配送ドライバーが移動できるようにしています。ルートマップを生成するための時間を短縮するために、各セクションは独自のDockerコンテナセットを使用し、セクション内のエリアでのみ注文を処理するカスタム構成をしています。
会社は、実行中のコンテナの数に基づいてリソースをコスト効率よく割り当てる必要があります。
要件を満たすソリューションはどれですか？
- A:
Amazon EC2上にAmazon Elastic Kubernetes Service（Amazon EKS）クラスターを作成し、Amazon EKS CLIを使用して、
-tagsオプションでカスタムタグをポッドに割り当てて計画アプリケーションをポッドとして起動する。- B:
AWS Fargate上にAmazon Elastic Kubernetes Service（Amazon EKS）クラスターを作成し、Amazon EKS CLIを使用して計画アプリケーションを起動し、AWS CLIのtag-resource API呼び出しを使用してポッドにカスタムタグを割り当てる。
- C:
Amazon EC2上にAmazon Elastic Container Service（Amazon ECS）クラスターを作成し、AWS CLIで
run-tasksをtrueに設定して、-tagsオプションでカスタムタグをタスクに割り当てて計画アプリケーションを起動する。- D:
AWS Fargate上にAmazon Elastic Container Service（Amazon ECS）クラスターを作成し、AWS CLI
run-taskコマンドでenableECSManagedTagsをtrueに設定して計画アプリケーションを起動し、-tagsオプションでカスタムタグをタスクに割り当てる。質問 #127
トピック 1
ある配送会社は、サードパーティのルート計画アプリケーションをAWSに移行する必要があります。このアプリケーションは、パブリックレジストリから提供されるDockerイメージを使用します。このイメージは、必要な数のコンテナとして実行され、ルートマップを生成できます。
配送会社は、供給ハブから顧客への移動距離を最短にするために、配送エリアを複数のセクションに分割しています。ルートマップを生成する時間を短縮するため、各セクションは独自のDockerコンテナセットを使用し、そのエリア内の注文のみを処理するカスタム構成を設定しています。
この会社は、稼働中のコンテナ数に基づいてコストを効率的に配分できる機能が必要です。
運用負担を最小限に抑えながら、この要件を満たす解決策はどれですか？
選択肢:
A. Amazon EC2 上に Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを作成します。EKS CLI を使用してポッド内で計画アプリケーションを起動し、
-tags オプションを使用してポッドにカスタムタグを割り当てます。B. AWS Fargate 上に Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを作成します。EKS CLI を使用して計画アプリケーションを起動します。AWS CLI の
tag-resource API を使用してポッドにカスタムタグを割り当てます。C. Amazon EC2 上に Amazon Elastic Container Service (Amazon ECS) クラスターを作成します。AWS CLI の
run-tasks オプションを有効にして計画アプリケーションを起動し、-tags オプションを使用してタスクにカスタムタグを割り当てます。D. AWS Fargate 上に Amazon Elastic Container Service (Amazon ECS) クラスターを作成します。AWS CLI の
run-task コマンドを使用して計画アプリケーションを起動し、enableECSManagedTags を true に設定します。また、--tags オプションを使用してタスクにカスタムタグを割り当てます。解説
D
EKS（Amazon Elastic Kubernetes Service）はFargateに対応していますが、設定が複雑になるため、この問題では推奨されません。
- EKSとFargateの組み合わせ:
- FargateでEKSを使用するには、NamespaceやPodにタグを付けるFargateプロファイルの設定が必要です。
- この設定は、運用負担（Operational Overhead）を増やします。
- この問題での要件:
- 「運用負担を最小化」がポイントです。
- ECSはFargateとの統合がシンプルで、設定も容易なため、運用負担を最小に抑えられます。
そのため、ECS＋Fargateを選ぶのが正解です。
128-VPCピアリング
理論
VPCピアリングを行うために必要な主な要件は以下の通りです：
- 異なるVPC間でCIDR範囲が重複していないこと。
- 適切なIAM権限があること。
- ピアリングリクエストと承認が正しく行われていること。
一問道場
Question #128
Topic 1
ソフトウェア会社が、複数のAWSアカウントおよびリージョンにまたがるリソースを使用してAWS上でアプリケーションをホストしています。このアプリケーションは、IPv4 CIDRブロックが10.10.0.0/16である、us-eastリージョンのアプリケーションVPC上のAmazon EC2インスタンスのグループで動作しています。別のAWSアカウントでは、IPv4 CIDRブロックが10.10.10.0/24であるus-east-2リージョンの共有サービスVPCがあります。
クラウドエンジニアがAWS CloudFormationを使用してアプリケーションVPCと共有サービスVPCをピアリングしようとすると、エラーメッセージが表示され、ピアリングが失敗します。
どの要因がこのエラーの原因となる可能性がありますか？（2つ選択）
A. 2つのVPCのIPv4 CIDR範囲が重複している
B. VPCが同じリージョンに存在しない
C. 一方または両方のアカウントがインターネットゲートウェイへのアクセスを持っていない
D. VPCの1つがAWS Resource Access Managerを通じて共有されていない
E. ピア受け入れアカウントのIAMロールが正しい権限を持っていない
解説
この問題の解説は以下の通りです。
問題の背景
VPCピアリングは、異なるVPC間で直接通信を可能にする機能です。ピアリング設定が失敗する場合、その原因は通常、設定や条件のいずれかに問題があります。
各選択肢の検討
A. 2つのVPCのIPv4 CIDR範囲が重複している
- 解説: VPCピアリングでは、2つのVPCのCIDR範囲が重複している場合、通信がルーティングできず、ピアリングが失敗します。
- 正解: はい。CIDRの重複はピアリング失敗の主要な原因の1つです。
B. VPCが同じリージョンに存在しない
- 解説: VPCピアリングは異なるリージョン間でも可能（リージョン間ピアリング）です。同一リージョンである必要はありません。
- 正解: いいえ。リージョンが異なってもピアリングできます。
C. 一方または両方のアカウントがインターネットゲートウェイへのアクセスを持っていない
- 解説: VPCピアリングはインターネットゲートウェイを必要としません。ピアリングはプライベート接続で動作します。
- 正解: いいえ。インターネットゲートウェイは不要です。
D. VPCの1つがAWS Resource Access Managerを通じて共有されていない
- 解説: Resource Access Manager (RAM)は異なるアカウント間でリソースを共有するための機能ですが、VPCピアリングには必要ありません。
- 正解: いいえ。RAMはピアリングに影響しません。
E. ピア受け入れアカウントのIAMロールが正しい権限を持っていない
- 解説: VPCピアリングを作成するには、ピアリングリクエストを承認する権限が必要です。IAMロールまたはユーザーが正しい権限を持っていない場合、ピアリングは失敗します。
- 正解: はい。権限不足はピアリング失敗の原因になり得ます。
正解
- A: CIDR範囲の重複
- E: IAMロールまたはユーザー権限の不足
ポイントまとめ
- CIDRの重複はピアリング失敗の主要原因。
- IAMロール/ユーザーの権限が正しく設定されていることを確認する。
- 異なるリージョン間のピアリングもサポートされている。
129-Lambda 最小権限 原則
理論
AWS Lambda の権限管理と最小権限の原則
AWS Lambda はサーバーレスアーキテクチャを支える重要なサービスですが、セキュリティを確保するためには適切なアクセス管理が必要です。Lambda の権限管理において重要な概念は「最小権限の原則」と「IAM ロール」です。
1. 最小権限の原則
最小権限の原則は、システムやサービスが動作に必要な最低限のアクセス権のみを付与するというセキュリティの原則です。この原則を守ることで、万が一セキュリティが侵害されても被害を最小限に抑えることができます。Lambda関数の場合、関数が必要とするリソースに対してのみ権限を付与することが求められます。
2. Lambda の IAM ロール
Lambda 関数は、リソースにアクセスするために IAM ロールを使用します。この IAM ロールに付与されるポリシーが、関数が呼び出し時にどのリソースにアクセスできるかを決定します。
例えば、Lambda が S3 バケットにアクセスする必要がある場合、その関数に関連付けられた IAM ロールには、S3 バケットに対する適切なアクセス権（例：
s3:GetObject）を含むポリシーが必要です。3. CloudTrail と IAM Access Analyzer
CloudTrail は AWS のサービスにおける API コールをログとして記録するサービスで、Lambda 関数が実行される際の API コールを追跡できます。このログを解析することで、関数がどのリソースにアクセスしているかを特定できます。
IAM Access Analyzer は、この CloudTrail のログから自動的に最小権限を抽出し、適切な IAM ポリシーを提案するツールです。
4. Lambda 関数の権限を最小化する方法
- CloudTrail を有効化して、Lambda の実行ログを記録し、関数が実際にどのリソースにアクセスしているのかを監視します。
- IAM Access Analyzerを使用して、CloudTrail の記録から必要なアクセス権を特定し、それに基づいて最小限の IAM ポリシーを生成します。
- アクセスポリシーのレビューと調整を行い、必要なリソースのみへのアクセスを許可するようにします。
これらのステップを踏むことで、Lambda 関数が持つべき最小権限を確実に設定し、セキュリティを向上させることができます。
一問道場
問題 #129
トピック 1
企業のサーバーレスアプリケーションの外部監査により、IAMポリシーが過剰な権限を付与していることが判明しました。これらのポリシーは企業のAWS Lambda実行ロールにアタッチされています。企業のLambda関数の何百もが、Amazon S3バケットやAmazon DynamoDBテーブルへのフルアクセス権など、広範なアクセス権限を持っています。企業は、各関数がそのタスクを完了するために必要な最小限の権限のみを持つようにしたいと考えています。
ソリューションアーキテクトは、各Lambda関数に必要な権限を特定しなければなりません。
最小限の労力でこの要件を満たすには、ソリューションアーキテクトは何をすべきですか？
A. Amazon CodeGuruを設定してLambda関数をプロファイリングし、AWS API呼び出しを検索します。
各Lambda関数に必要なAPI呼び出しとリソースのインベントリを作成し、新しいIAMアクセスポリシーを各Lambda関数に作成します。
新しいポリシーが企業のビジネス要件を満たしていることを確認します。
B. AWS CloudTrailログをAWSアカウントで有効にします。
AWS Identity and Access Management Access Analyzerを使用して、CloudTrailログに記録されたアクティビティに基づいてIAMアクセスポリシーを生成します。
生成されたポリシーが企業のビジネス要件を満たしていることを確認します。
C. AWS CloudTrailログをAWSアカウントで有効にします。
CloudTrailログを解析するスクリプトを作成し、Lambda実行ロールによるAWS API呼び出しを検索して要約レポートを作成します。
レポートを確認し、各Lambda関数により制限された権限を提供するIAMアクセスポリシーを作成します。
D. AWS CloudTrailログをAWSアカウントで有効にし、CloudTrailログをAmazon S3にエクスポートします。
Amazon EMRを使用して、Amazon S3に格納されたCloudTrailログを処理し、各実行ロールによるAPI呼び出しと使用されたリソースのレポートを作成します。
各ロールの新しいIAMアクセスポリシーを作成し、生成されたロールをS3バケットにエクスポートします。
生成されたポリシーが企業のビジネス要件を満たしていることを確認します。
130-AWS Compute Optimizer
理論
1. EC2 インスタンスの効率的な運用
EC2 インスタンスはクラウドコンピューティング環境でアプリケーションをホストするための仮想サーバーです。効率的な運用を行うためには、適切なインスタンスタイプ（メモリ、CPU、ストレージのリソース）を選択し、リソース使用状況 に基づいてインスタンスを調整（リサイズ）することが重要です。リサイズには、インスタンスのサイズ変更や不要なインスタンスの停止を含みます。
- Amazon CloudWatch でのモニタリングを通じて、インスタンスのパフォーマンス（CPU 使用率、メモリ使用量など）を監視することができます。この情報を基に、過剰なリソースを削減し、コストを最適化します。
2. AWS Compute Optimizer
AWS Compute Optimizer は、インスタンスのサイズを最適化するための自動ツールです。EC2 インスタンスの使用状況を分析し、どのインスタンスサイズが最適かを推奨します。これにより、最小限のコストで適切なパフォーマンスを得ることができ、手動でリサイズする手間を省けます。
- 使用するリソースに基づいて、推奨されるインスタンスタイプの選定が行われ、無駄なリソースを削減できます。
3. Amazon EBS ボリューム
Amazon Elastic Block Store (EBS) は、EC2 インスタンスにストレージを提供するサービスです。EBS ボリュームも、インスタンスと同様にリソースの管理と最適化が必要です。必要以上に大きなボリュームや、未使用のボリュームが存在すると、コストが無駄にかかるため、これらも監視し、最適化することが求められます。
4. AWS CloudTrail と CloudWatch
- AWS CloudTrail: アカウント内のすべてのAPIアクティビティを追跡・記録します。これを使って、インスタンスの使用履歴やリソースの消費履歴を確認し、最適化に役立てることができます。
- Amazon CloudWatch: EC2 インスタンスや EBS ボリュームのメトリクス（CPU 使用率、メモリ使用量、ディスクI/Oなど）をリアルタイムで監視でき、アラームを設定して異常を検出することができます。これを活用して、リソースの最適化を行います。
5. コスト効率の最適化
AWS では、リソースの最適化を行うことで、必要ないリソースの削減や、適切なインスタンスタイプへの変更が可能です。インスタンスの最適化によってコストを削減することは、AWS の利用における大きな利点です。
6. AWS Trusted Advisor
AWS Trusted Advisor は、AWS のリソースに関するアドバイスを提供するサービスです。インスタンスの最適化をはじめ、セキュリティ、コスト削減、パフォーマンスの向上に関する提案が得られます。エンタープライズサポートプランに加入している場合、これを活用して推奨事項を確認することができます。
これらのサービスや機能を活用することで、EC2 インスタンスと EBS ボリュームのリソース使用効率を最適化し、コスト削減を達成することができます。最適化を自動化するためのツール（例えば AWS Compute Optimizer や CloudWatch）を使うことで、手間をかけずに効率的にリソースを管理することが可能です。
一問道場
質問 #130
トピック
ソリューションアーキテクトは、会社の Amazon EC2 インスタンス と Amazon Elastic Block Store (Amazon EBS) ボリューム を分析し、会社がリソースを効率的に使用しているかどうかを確認する必要があります。会社は、アクティブ/パッシブ構成でデータベースクラスターをホストするためにいくつかの大きな高メモリ EC2 インスタンスを運用しています。これらの EC2 インスタンスの使用率は、データベースを使用するアプリケーションによって異なり、会社はまだパターンを特定していません。
ソリューションアーキテクトは、環境を分析し、調査結果に基づいて行動を取る必要があります。
どのソリューションが 最もコスト効率的 にこれらの要件を満たしますか？
A. AWS Systems Manager OpsCenter を使用してダッシュボードを作成します。EC2 インスタンス とその EBS ボリューム に関連する Amazon CloudWatch メトリクス の視覚化を構成します。ダッシュボードを定期的に確認し、使用パターンを特定します。メトリクスのピークに基づいて EC2 インスタンス のサイズを調整します。
B. EC2 インスタンス とその EBS ボリューム の詳細な監視を有効にします。メトリクスに基づいたダッシュボードを作成して確認します。使用パターンを特定します。メトリクスのピークに基づいて EC2 インスタンス のサイズを調整します。
C. 各 EC2 インスタンス に Amazon CloudWatch エージェント をインストールします。AWS Compute Optimizer を有効にし、12 時間以上実行させます。Compute Optimizer からの推奨事項を確認し、指示に従って EC2 インスタンス のサイズを調整します。
D. AWS エンタープライズサポートプラン にサインアップします。AWS Trusted Advisor を有効にし、12 時間待機します。Trusted Advisor からの推奨事項を確認し、指示に従って EC2 インスタンス のサイズを調整します。
解説
この問題では、会社が EC2 インスタンス と EBS ボリューム の効率的な使用状況を分析し、コスト効率を最大化する方法を問われています。
- A: Systems Manager OpsCenter と CloudWatch を使ってダッシュボードを作成し、定期的にメトリクスを確認する方法です。しかし、これは手動で確認する必要があり、完全な自動化が欠けているため、効率的ではありません。
- B: CloudWatch 詳細監視 を有効にし、ダッシュボードでメトリクスを確認する方法です。手動ですが、EC2 と EBS のパフォーマンスに基づき、適切なサイズ変更が可能です。
- C: CloudWatch エージェント と Compute Optimizer を使用し、インスタンスのサイズ調整を自動で推奨する方法です。これは、使用状況を自動的に分析して推奨を出してくれるため、最もコスト効率的 で、最小限の労力で最適化が可能です。
- D: Trusted Advisor を使う方法ですが、エンタープライズサポートプランが必要で、最も高コストな選択肢です。推奨事項の取得に時間がかかり、最小限の労力で最適化をするには不向きです。
最もコスト効率的 で手間の少ない選択肢は C の Compute Optimizer の使用です。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/16ed7ae8-88e2-800c-9aee-e348e71f8f47
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
