type
status
date
slug
summary
tags
category
icon
password
461-AWS SAP AWS 「理論・実践・一問道場」Elastic Beanstalk ウェブサイトの移行
理論
AWS でウェブサイトを移行する際の重要ポイント
ウェブサイトをオンプレミス環境からAWSに移行する際は、以下の主要な要素に基づいて設計する必要があります。
1. ストレージ要件の選定
- Amazon EFS (Elastic File System)
- 特長: NFS互換のマネージドストレージ。複数のEC2インスタンスから同時アクセス可能。
- 適用例: CMSのように共有ストレージが必要なアプリケーション。
- Amazon EBS (Elastic Block Store)
- 特長: 高パフォーマンスなブロックストレージ。
- 制限: Multi-Attachはあるが、同時アクセスのためのNFS互換ではない。共有ストレージには不適。
2. スケーラブルなアーキテクチャの設計
- Auto Scaling Group:
- トラフィックに応じてEC2インスタンスを自動でスケール。
- 最大・最小インスタンス数を定義可能。
- Elastic Beanstalk:
- アプリケーションデプロイとインフラ管理を簡略化するPaaSソリューション。
- Auto Scalingとロードバランサーを自動で設定可能。
3. 高可用性とデータ保護
- Amazon Aurora (MySQL互換):
- 自動バックアップやマルチAZデプロイで高可用性を実現。
- データ損失リスクを最小限に抑える。
- Amazon RDS:
- マネージドなデータベースサービスで、運用負荷を軽減。
4. トラフィックの分散
- ロードバランサーの選択:
- Application Load Balancer (ALB): HTTP/HTTPSトラフィック向け。
- Network Load Balancer (NLB): 高スループット、低レイテンシトラフィック向け。
- 利点: トラフィックを複数のインスタンスに均等に分散し、可用性を向上。
5. 運用管理の効率化
- AWS マネージドサービスを活用:
- Elastic BeanstalkやRDS、EFSなど、運用負荷を軽減するマネージドサービスを組み合わせる。
- スケール時の設定自動化:
- 起動テンプレートやライフサイクルフックを活用して、自動的にストレージをマウント。
まとめ
AWSでは、目的に応じた適切なサービスを選択することで、スケーラブルかつ高可用性なウェブサイトを実現できます。CMSのような共有ストレージが必要なシステムでは、Amazon EFSが最適な選択肢です。また、運用を簡素化するには、Elastic Beanstalkを活用することが効果的です。
実践
略
一問道場
質問 #461
ある企業がオンプレミスのデータセンターからAWSへのウェブサイト移行を必要としています。ウェブサイトは、ロードバランサー、Linuxオペレーティングシステムで動作するコンテンツ管理システム（CMS）、およびMySQLデータベースで構成されています。
CMSはファイルシステム用にNFS互換の永続ストレージを必要としています。AWS上の新しいソリューションは、予測不可能なトラフィックの増加に応じて、Amazon EC2インスタンスを2台から30台までスケールできる必要があります。また、この新しいソリューションではウェブサイトの変更を一切必要とせず、データ損失を防ぐ必要があります。
どのソリューションがこれらの要件を満たしますか？
A. Amazon Elastic File System（Amazon EFS）ファイルシステムを作成します。CMSをAWS Elastic Beanstalkに、アプリケーションロードバランサーとAuto Scalingグループを使ってデプロイします。.ebextensionsを使用してEFSファイルシステムをEC2インスタンスにマウントします。Elastic Beanstalk環境とは別に、Amazon Aurora MySQLデータベースを作成します。
B. Amazon Elastic Block Store（Amazon EBS）のMulti-Attachボリュームを作成します。CMSをAWS Elastic Beanstalkに、ネットワークロードバランサーとAuto Scalingグループを使ってデプロイします。.ebextensionsを使用してEBSボリュームをEC2インスタンスにマウントします。Elastic Beanstalk環境内にAmazon RDS for MySQLデータベースを作成します。
C. Amazon Elastic File System（Amazon EFS）ファイルシステムを作成します。起動テンプレートとAuto Scalingグループを作成し、CMSをサポートするEC2インスタンスを起動します。ネットワークロードバランサーを作成してトラフィックを分散します。Amazon Aurora MySQLデータベースを作成します。EC2 Auto Scalingのスケールインライフサイクルフックを使用して、EFSファイルシステムをEC2インスタンスにマウントします。
D. Amazon Elastic Block Store（Amazon EBS）のMulti-Attachボリュームを作成します。起動テンプレートとAuto Scalingグループを作成し、CMSをサポートするEC2インスタンスを起動します。アプリケーションロードバランサーを作成してトラフィックを分散します。MySQLデータベースをサポートするためにAmazon ElastiCache for Redisクラスターを作成します。EC2のユーザーデータを使用して、EBSボリュームをEC2インスタンスにアタッチします。
解説
この問題では、AWS上でウェブサイトを移行するための要件を満たすソリューションを選ぶ必要があります。それぞれの選択肢を要件と照らし合わせながら確認します。
要件の整理
- NFS互換の永続ストレージ：CMSが必要としているため、Amazon EFSが適しています。EFSはNFS互換であり、複数のEC2インスタンスで同時に使用可能です。
- スケーラブルなEC2インスタンス：Auto Scalingグループを利用して、2台から30台までスケール可能である必要があります。
- データ損失の防止：ファイルシステムやデータベースが高可用性を提供することが必要です。
- ウェブサイトに変更が不要：既存のCMSの要件を満たしつつ、アプリケーションを改修する必要がないようにする必要があります。
各選択肢の分析
A. Amazon EFS と Elastic Beanstalk
- EFS：NFS互換で永続ストレージの要件を満たす。
- Elastic Beanstalk：ロードバランサーとAuto Scalingを簡単に設定可能。複雑なインフラ管理を避けられる。
- Aurora MySQL：高可用性とパフォーマンスを提供。
- 評価：すべての要件を満たすため、最適なソリューション。
B. Amazon EBS の Multi-Attach
- EBS Multi-Attach：EBSボリュームは複数のインスタンスで共有可能だが、ファイルシステムとして同時アクセスには制限があり、CMSには不向き。
- Elastic Beanstalk：スケーラブルな設定は可能。
- RDS MySQL：適切だが、EBSの選択が問題。
- 評価：EBS Multi-AttachはNFS互換ではなく、同時アクセスが難しいため不適切。
C. Amazon EFS と独自の設定
- EFS：永続ストレージの要件を満たす。
- 起動テンプレートとAuto Scaling：手動で設定することでスケーラビリティを確保可能。
- Aurora MySQL：高可用性を提供。
- 評価：要件は満たすが、Elastic Beanstalkを使用しないため運用が複雑になる。
D. Amazon EBS の Multi-Attach と ElastiCache
- EBS Multi-Attach：Bと同様にCMSには不向き。
- ElastiCache：MySQLの補助には役立つが、直接的なデータストレージとしては不適切。
- 評価：EBS Multi-Attachが原因で要件を満たさない。
最適解
A. Amazon EFS と Elastic Beanstalk
- 理由：EFSがNFS互換ストレージとして最適であり、Elastic Beanstalkがスケーラビリティと運用の容易さを提供します。Aurora MySQLを使用することで高可用性とデータ損失の防止も実現できます。
462-AWS SAP AWS 「理論・実践・一問道場」フロントエンド AMI
理論
AWS 災害復旧とパフォーマンス最適化のポイント
1. RDSリードレプリカ
- 概要: Amazon RDSのリードレプリカは、読み取り専用のデータベースインスタンスを作成可能。
- 利点:
- 読み取りクエリを分散し、パフォーマンスを最適化。
- マルチリージョンのレプリケーションで災害復旧にも対応。
- 注意点: 災害時には手動でリードレプリカを昇格する必要がある。
2. S3クロスリージョンレプリケーション（CRR）
- 概要: S3バケット間でデータを自動的に複製し、別リージョンに冗長性を確保。
- 利点:
- リアルタイムでデータを同期。
- バケット間で災害対策が可能。
3. AMI（Amazon Machine Image）
- 概要: EC2インスタンスのスナップショットを作成し、他リージョンにコピー可能。
- 利点:
- 新しいインスタンスを迅速に起動。
- 災害時のリカバリーに有効。
4. 災害復旧の基本戦略
- RPO（Recovery Point Objective）: 許容できるデータ損失の最大値を定義。
- 例: S3のCRRやRDSリードレプリカを使えば、RPOを最小化可能。
- RTO（Recovery Time Objective）: システムを復旧させる目標時間。
- 例: AMIを使用すれば、短時間でシステムを復旧可能。
5. パフォーマンス最適化のアプローチ
- ElastiCache: クエリをキャッシュし、データベース負荷を軽減。
- リードレプリカ: 読み取り専用クエリを分離して、本番環境の性能を確保。
まとめ
AWSでは、RDSリードレプリカ、S3のCRR、AMIなどを組み合わせることで、災害復旧とパフォーマンス最適化を同時に達成できる。特にマルチリージョン構成は、データ損失を最小化し、迅速な復旧を可能にする強力なソリューションです。
実践
略
一問道場
問題 #462
ある企業が、単一のAWSリージョンで稼働している重要なアプリケーションの災害復旧を実装する必要があります。このアプリケーションのユーザーは、Application Load Balancer (ALB) の背後にあるAmazon EC2インスタンスにホストされたWebフロントエンドを介してアプリケーションとやり取りします。アプリケーションはAmazon RDS for MySQLデータベースに書き込みを行い、処理されたドキュメントをAmazon S3バケットに保存します。
この企業の財務チームは、データベースに直接クエリを実行してレポートを生成しますが、繁忙期にはこれらのクエリがリソースを消費し、アプリケーションのパフォーマンスに悪影響を与えています。
ソリューションアーキテクトは、災害時の復元性を提供するソリューションを設計する必要があります。このソリューションは、データ損失を最小限に抑え、財務チームのクエリによるパフォーマンス問題を解決する必要があります。
どのソリューションがこれらの要件を満たしますか？
A.
データベースをAmazon DynamoDBに移行し、DynamoDBグローバルテーブルを使用します。財務チームには、別のリージョンにあるグローバルテーブルをクエリするよう指示します。AWS Lambda関数を作成して、元のS3バケットの内容を別のリージョンにある新しいS3バケットに定期的に同期します。別のリージョンにEC2インスタンスを起動し、ALBを作成します。アプリケーションを新しいS3バケットに向けるように設定します。
B.
別のリージョンにアプリケーションをホストする追加のEC2インスタンスを起動します。それらのインスタンスを既存のALBに追加します。別のリージョンでRDS DBインスタンスのリードレプリカを作成します。財務チームには、このリードレプリカに対してクエリを実行するよう指示します。元のS3バケットから別のリージョンにある新しいS3バケットへのS3クロスリージョンレプリケーション（CRR）を設定します。災害時には、リードレプリカをスタンドアロンDBインスタンスに昇格させます。アプリケーションを新しいS3バケットと昇格したリードレプリカに向けるように設定します。
C.
別のリージョンでRDS DBインスタンスのリードレプリカを作成します。財務チームには、このリードレプリカに対してクエリを実行するよう指示します。アプリケーションフロントエンドをホストするEC2インスタンスのAMIを作成し、そのAMIを別のリージョンにコピーします。元のS3バケットから別のリージョンにある新しいS3バケットへのS3クロスリージョンレプリケーション（CRR）を設定します。災害時には、リードレプリカをスタンドアロンDBインスタンスに昇格させます。AMIからEC2インスタンスを起動し、ALBを作成してエンドユーザーにアプリケーションを提供します。アプリケーションを新しいS3バケットに向けるように設定します。
D.
RDS DBインスタンスのスナップショットを毎時作成し、それを別のリージョンにコピーします。既存のRDSデータベースの前にAmazon ElastiCacheクラスターを追加します。アプリケーションフロントエンドをホストするEC2インスタンスのAMIを作成し、そのAMIを別のリージョンにコピーします。元のS3バケットから別のリージョンにある新しいS3バケットへのS3クロスリージョンレプリケーション（CRR）を設定します。災害時には、最新のRDSスナップショットからデータベースを復元します。AMIからEC2インスタンスを起動し、ALBを作成してエンドユーザーにアプリケーションを提供します。アプリケーションを新しいS3バケットに向けるように設定します。
解説
設問のポイント
- 災害復旧 (Disaster Recovery)
- 別のAWSリージョンでアプリケーションとデータを冗長化する必要があります。
- データ損失を最小限に抑える設計が求められます。
- パフォーマンス問題の解消
- 財務チームのクエリがアプリケーション性能に悪影響を及ぼさないようにする必要があります。
選択肢の評価
A. DynamoDBに移行し、グローバルテーブルを使用する
- メリット
- DynamoDBはスケーラブルであり、グローバルテーブルによりデータの冗長化が簡単に可能。
- デメリット
- データベースをDynamoDBに移行するため、アプリケーションコードの変更が必要。この問題では「アプリケーションコードの変更なし」が前提条件。
→ 条件に合わないため、不適切。
B. 別リージョンにリードレプリカを作成し、RDSを昇格させる
- メリット
- RDSのリードレプリカを使用することで、財務チームのクエリを分離し、パフォーマンスを改善できる。
- クロスリージョンレプリケーションによりデータ損失を最小化。
- デメリット
- ALBに別リージョンのEC2インスタンスを追加するのは現実的ではない（異なるリージョン間でロードバランシングはサポートされていない）。
→ ALBの設計に不備があるため、不適切。
C. 別リージョンにリードレプリカを作成し、AMIをコピーする
- メリット
- RDSのリードレプリカを使用することで、財務チームのクエリを本番環境から分離できる。
- S3のクロスリージョンレプリケーションにより、ストレージデータの同期を確保。
- 災害発生時にはリードレプリカを昇格し、AMIから新しいEC2インスタンスを立ち上げることで復旧が可能。
- デメリット
- 災害発生時に手動でリードレプリカを昇格させる必要がある。
→ 条件を満たすため、適切。
D. RDSスナップショットとElastiCacheを使用する
- メリット
- ElastiCacheにより、クエリのパフォーマンス問題を解消可能。
- スナップショットを別リージョンにコピーすることでデータ損失を最小限に抑えられる。
- デメリット
- スナップショットの復元には時間がかかるため、RPO（復旧ポイント目標）が緩和される可能性がある。
- リアルタイムのデータ同期が行われないため、データ損失リスクが若干高い。
→ データ損失リスクがあるため、不適切。
正解: C
Cは災害復旧とパフォーマンス問題解消の両方に対応しており、要件を最も適切に満たします。
補足知識
- RDSリードレプリカ
- 読み取り専用のクエリを別のインスタンスにオフロード可能。マルチリージョンでのデータ同期も可能。
- S3クロスリージョンレプリケーション（CRR）
- S3バケット間でデータを自動的に複製し、冗長性を確保する機能。
- AMI（Amazon Machine Image）
- EC2インスタンスの状態を保存し、他リージョンにコピーすることで迅速な復旧が可能。
463-AWS SAP AWS 「理論・実践・一問道場」PrivateLink NLB
理論
AWS PrivateLinkを利用した安全なサービス公開に関する汎用的知識
1. AWS PrivateLinkとは
- 定義: AWS PrivateLinkは、インターネットを経由せず、VPC内で安全にサービスを公開・利用できる仕組み。
- 主な利用ケース:
- 機密データを扱うサービスの安全な共有。
- 他のAWSアカウントやVPCへのサービス提供。
2. PrivateLinkの構成要素
- VPCエンドポイントサービス: サービスを提供するためのエンドポイント。
- Network Load Balancer (NLB): TCP/UDPトラフィックを処理するロードバランサー。
- エンドポイント: サービスを利用する側のVPC内で作成される接続ポイント。
3. PrivateLinkの利点
- セキュリティ: トラフィックがインターネットを経由しないため、安全性が高い。
- シンプルな接続: サービス提供者と利用者間で簡単に接続を確立できる。
- 低レイテンシ: データ転送がAWSの内部ネットワークで行われるため、高速。
4. 構築の基本手順
- Network Load Balancer (NLB)の設定: サービスをホストするインスタンスをターゲットとして登録。
- VPCエンドポイントサービスの作成: NLBをバックエンドに設定。
- サービス利用者の設定: エンドポイントを作成し、サービスに接続。
5. PrivateLink利用時の注意点
- プロトコルの制限: NLBはTCP/UDPに対応しており、HTTP/HTTPSは直接サポートしない（ALBは使用不可）。
- コスト: VPCエンドポイントやNLBの利用料金が発生する。
- 接続範囲: 同じリージョン内またはクロスアカウントで利用可能。
関連ユースケース
- オンプレミスとAWS間の接続: Direct Connectを活用し、プライベートな通信を実現。
- B2Bサービスの提供: 他社向けに安全なAWSサービスを公開。
これらを理解することで、AWS環境でのセキュリティとパフォーマンスを最適化できます。
実践
略
一問道場
Question #463
ある会社は、オンプレミスのデータセンターで多数のサービスを運用しています。データセンターは、AWS Direct Connect (DX) と IPSec VPN を使用して AWS に接続されています。このサービスのデータは機密性が高く、インターネットを経由する接続は許可されていません。
この会社は、新しい市場セグメントに進出し、AWS を使用している他の企業にサービスを提供し始めたいと考えています。
どのソリューションがこれらの要件を満たしますか？
A. TCP トラフィックを受け入れる VPC エンドポイントサービスを作成し、Network Load Balancer の背後にホストし、サービスを DX 経由で利用可能にする。
B. HTTP または HTTPS トラフィックを受け入れる VPC エンドポイントサービスを作成し、Application Load Balancer の背後にホストし、サービスを DX 経由で利用可能にする。
C. VPC にインターネットゲートウェイをアタッチし、関連するインバウンドおよびアウトバウンドトラフィックを許可するようにネットワークアクセス制御およびセキュリティグループルールを設定する。
D. VPC に NAT ゲートウェイをアタッチし、関連するインバウンドおよびアウトバウンドトラフィックを許可するようにネットワークアクセス制御およびセキュリティグループルールを設定する。
解説
この問題では、オンプレミスのデータセンターとAWS間の接続を安全に維持しながら、AWSを利用する他社にサービスを提供する方法が問われています。各選択肢について詳しく解説します。
A. TCP トラフィックを受け入れる VPC エンドポイントサービスを作成し、Network Load Balancer の背後にホストし、サービスを DX 経由で利用可能にする。
- 説明:
- VPCエンドポイントサービス（PrivateLink） を使用することで、他のAWSアカウントに安全にサービスを公開可能。
- Network Load Balancer (NLB) はTCPトラフィックを処理し、Direct Connectを通じて通信できる。
- インターネットを経由しないため、機密データの要件を満たす。
- 結論: この選択肢は要件を完全に満たします。
B. HTTP または HTTPS トラフィックを受け入れる VPC エンドポイントサービスを作成し、Application Load Balancer の背後にホストし、サービスを DX 経由で利用可能にする。
- 説明:
- Application Load Balancer (ALB) はHTTP/HTTPSトラフィックを処理します。
- しかし、ALBはVPCエンドポイントサービス（PrivateLink）には対応していません。
- このため、ALBを使用するこの選択肢は要件を満たしません。
- 結論: 不正解。
C. VPC にインターネットゲートウェイをアタッチし、関連するインバウンドおよびアウトバウンドトラフィックを許可するようにネットワークアクセス制御およびセキュリティグループルールを設定する。
- 説明:
- インターネットゲートウェイをアタッチすることで、インターネット経由でサービスを公開できます。
- しかし、インターネットを経由しないという要件を満たさないため、適切ではありません。
- 結論: 不正解。
D. VPC に NAT ゲートウェイをアタッチし、関連するインバウンドおよびアウトバウンドトラフィックを許可するようにネットワークアクセス制御およびセキュリティグループルールを設定する。
- 説明:
- NATゲートウェイは、プライベートサブネット内のインスタンスがインターネットに接続するために使用されます。
- しかし、サービスを他社に提供する仕組みとしては不適切であり、Direct Connectを利用しない。
- 結論: 不正解。
正解: A
理由:
- VPCエンドポイントサービス（PrivateLink） は、サービスを他社に安全に公開する最適な方法です。
- Direct Connect を介して通信し、インターネットを経由しないため、機密性の高いデータの要件を満たします。
- Network Load Balancer (NLB) はTCPトラフィックを処理するため、要件に適合します。
補足
- VPCエンドポイントサービス（PrivateLink）: 他のAWSアカウントやVPC間で、インターネットを経由せずにプライベートネットワーク上でサービスを共有可能。
464-AWS SAP AWS 「理論・実践・一問道場」AWS Organizations SCP
理論
AWS OrganizationsとSCP（サービスコントロールポリシー）を活用するための重要な知識を簡潔にまとめます。
AWS Organizations
- AWS Organizationsは、複数のAWSアカウントを一元管理するサービスで、リソースのアクセス制御やポリシー適用を組織単位で管理できます。
- 組織内のアカウントに共通のポリシーを適用したり、アカウントをグループ化（OU: Organizational Units）して管理したりできます。
SCP（サービスコントロールポリシー）
- SCPは、AWS Organizationsの各アカウントに対して適用する制限を定義するポリシーです。特定のサービスやアクションを制限し、アクセス権限を管理できます。
- SCPは「許可」ではなく「拒否」ポリシーで動作します。例えば、あるアクションを拒否する設定をすると、それを許可するIAMポリシーがあっても、そのアクションは実行できません。
管理者ロールの制限
- AWS OrganizationsでIAMアクションを制限したい場合、管理者ロールを使ってアクセス制御を行います。管理者ロールにのみ特定のアクション（例: IAMユーザーの作成やポリシーの管理）を許可することで、セキュリティリスクを低減できます。
- SCPを使って、IAMアクションをすべてのユーザーに対して拒否し、管理者ロールに例外を設けることで、最小限の権限で管理できます。
最小権限の原則
- 「最小権限の原則」では、ユーザーやロールにはその業務に必要な最低限の権限のみを付与することが求められます。これにより、不正アクセスや誤操作を防ぎます。
運用負荷を最小化するための方法
- SCPを利用することで、組織全体にポリシーを一元的に適用でき、各アカウントで個別に設定する必要がなくなります。これにより、管理の負担が大幅に軽減されます。
- 一方で、IAMパーミッションバウンダリやCloudTrail＋Lambdaを使う方法は、管理が複雑になりやすいため、一般的にはSCPを使った一括管理の方が望ましいです。
重要ポイント
- SCPでのポリシー適用は、アクセス制御の中心的な手段であり、アカウント間で一貫したセキュリティ管理を実現します。
- 管理者ロールにアクセスを限定することで、セキュリティを強化し、最小権限の原則を守りながら運用できます。
実践
略
一問道場
質問 #464
ある企業はAWS Organizationsを使用してAWSアカウントを管理しています。
ソリューションアーキテクトは、IAMアクションを実行できるのは管理者ロールのみとするソリューションを設計しなければなりません。
ただし、ソリューションアーキテクトは会社全体のすべてのAWSアカウントにアクセス権を持っているわけではありません。
最小の運用負荷でこれらの要件を満たすソリューションはどれですか？
A. すべてのAWSアカウントに適用されるSCP（サービスコントロールポリシー）を作成し、IAMアクションを管理者ロールにのみ許可します。このSCPをルートOU（組織単位）に適用します。
B. AWS CloudTrailを設定し、IAMアクションに関連する各イベントでAWS Lambda関数を呼び出します。この関数を設定し、アクションを実行したユーザーが管理者でない場合にアクションを拒否します。
C. すべてのAWSアカウントに適用されるSCPを作成し、IAMアクションをすべてのユーザーに拒否し、管理者ロールを持つユーザーのみ例外とします。このSCPをルートOUに適用します。
D. IAMアクションを許可するIAMパーミッションバウンダリを設定し、そのパーミッションバウンダリをすべてのAWSアカウント内の管理者ロールにアタッチします。
解説
C. すべてのAWSアカウントに適用されるSCPを作成し、IAMアクションをすべてのユーザーに拒否し、管理者ロールを持つユーザーのみ例外とします。このSCPをルートOUに適用します。
このアプローチは、要件に対して非常に適切であり、効率的です。詳細は以下の通りです：
SCP（サービスコントロールポリシー）を使用する利点
- 一貫性: SCPはAWS Organizations内のすべてのアカウントに一貫して適用されます。これにより、全てのアカウントに対して同じアクセス制限を設定でき、管理が簡素化されます。
- 中央集権的管理: SCPを利用することで、管理者はすべてのAWSアカウントに対する制御を中央で行えます。特定のIAMアクションに対してアクセスを制限し、管理者ロールにのみ例外を設けることで、不要なアクセスを防止します。
IAMアクションを制限する方法
- このポリシーでは、IAMアクションをすべてのユーザーに対して拒否し、管理者ロールのユーザーに対してのみアクセスを許可する形にします。これにより、非管理者のユーザーがIAMアクションを実行することはできなくなり、最小限の権限で運用が可能です。
- 具体的には、SCPで「iam: *」アクションを拒否するポリシーを作成し、その例外として管理者ロールに必要なアクション（例えば「iam: CreateRole」や「iam: AttachRolePolicy」など）を許可します。
適用方法
- ルートOU（組織単位）に適用することで、AWS Organizations内の全てのアカウントに対して一度に適用できます。これにより、個々のアカウントに対して個別に設定を行う必要がなく、運用負荷が大きく削減されます。
メリット
- 最小限の運用負荷: SCPはポリシーが一元管理され、すべてのアカウントに一括適用されるため、個々のアカウントやユーザーに対して別々の設定を行う必要がなく、非常に効率的です。
- セキュリティ強化: IAMアクションの制限を管理者ロールのみに絞ることで、誤った権限付与を防ぎ、セキュリティを強化します。
考慮すべき点
- SCPの「拒否」ポリシーを設定する際、管理者ロールに必要な権限を明示的に許可する必要があります。この設定が正しくないと、管理者ロール自体にもアクセス制限がかかる可能性があります。そのため、管理者ロールを正確に特定し、適切な許可を与えることが重要です。
結論
選択肢 C は、最小限の運用負荷で要件を満たす非常に効率的な方法です。AWS OrganizationsのSCPを使用することで、全アカウントに対して一貫したポリシーを適用でき、管理者ロールにのみIAMアクションを許可するという要件を簡潔に実現できます。
465-AWS SAP AWS 「理論・実践・一問道場」トランジットゲートウェイの自動承認
理論
AWS Organizations
- AWS Organizationsは、複数のAWSアカウントを中央で管理し、リソースのアクセスやポリシーを組織単位で制御できるサービスです。これにより、アカウントの管理を効率化し、セキュリティやコスト管理の最適化が図れます。
トランジットゲートウェイ
- トランジットゲートウェイは、複数のVPCやオンプレミスネットワーク間で接続を提供するサービスです。これにより、複数のVPCを一元的に接続し、通信を効率化できます。
- トランジットゲートウェイを使用することで、各アカウント間でのネットワーク接続を簡素化し、異なるAWSアカウントにまたがるリソース間の通信を管理できます。
AWS RAM (Resource Access Manager)
- AWSリソースアクセスマネージャー（AWS RAM）は、AWSアカウント間でリソースを共有するサービスです。これを使用することで、開発アカウントと共有サービスアカウント間で、トランジットゲートウェイなどのリソースを簡単に共有できます。
VPCエンドポイント
- VPCエンドポイントは、VPC内から他のVPCやAWSサービスにアクセスするためのインターフェースを提供します。トランジットゲートウェイの代わりに使うことはありますが、アカウント間接続の管理には一般的にトランジットゲートウェイがより適しています。
自動承認の設定
- トランジットゲートウェイで自動承認を有効にすることで、接続リクエストを手動で承認する必要がなくなります。これにより、開発環境が頻繁にリソースを再作成しても、再接続が簡単になります。
AWS Lambda と EventBridge
- AWS LambdaとAmazon EventBridgeを組み合わせて、イベント駆動型で自動的にアクションを実行することができます。しかし、トランジットゲートウェイの接続管理には、この方法は複雑で運用負荷が高くなるため、一般的にはRAMや自動承認機能を利用した方法が推奨されます。
最適な接続管理方法
- 開発環境でのリソースの頻繁な変更には、AWS RAMを使ったリソースの共有と、トランジットゲートウェイの自動承認機能を組み合わせることが最適です。これにより、接続を手動で再設定することなく、開発チームが容易に接続を再作成できるようになります。
実践
略
一問道場
質問 #465
ある企業は、AWS Organizationsを使用して複数のAWSアカウントを管理しています。企業は、共有サービスアカウント内のVPCでいくつかのアプリケーションをホストしています。企業は、トランジットゲートウェイを共有サービスアカウント内のVPCに接続しています。企業は新しい機能を開発しており、開発環境を作成しました。この開発環境は、共有サービスアカウント内のアプリケーションへのアクセスを必要とします。企業は、開発アカウント内でリソースを頻繁に削除および再作成する予定です。また、開発チームが必要に応じて、共有サービスアカウントへの接続を再作成する能力を持つようにしたいと考えています。
どのソリューションがこれらの要件を満たすでしょうか？
A. 開発アカウントにトランジットゲートウェイを作成します。開発アカウントから共有サービスアカウントにトランジットゲートウェイピアリングリクエストを作成します。共有サービスのトランジットゲートウェイを設定して、ピアリング接続を自動的に承認するようにします。
B. 共有サービスアカウントでトランジットゲートウェイの自動承認をオンにします。AWSリソースアクセスマネージャー（AWS RAM）を使用して、共有サービスアカウントのトランジットゲートウェイリソースを開発アカウントと共有します。開発アカウントでリソースを受け入れ、開発アカウント内にトランジットゲートウェイアタッチメントを作成します。
C. 共有サービスアカウントでトランジットゲートウェイの自動承認をオンにします。VPCエンドポイントを作成します。エンドポイントポリシーを使用して、開発アカウントに対してVPCエンドポイントの権限を付与します。エンドポイントサービスを設定して、接続リクエストを自動的に承認します。エンドポイントの詳細を開発チームに提供します。
D. Amazon EventBridgeルールを作成して、開発アカウントがアタッチメントリクエストを行った際にAWS Lambda関数を呼び出してトランジットゲートウェイアタッチメントを承認します。AWSネットワークマネージャーを使用して、共有サービスアカウントのトランジットゲートウェイを開発アカウントと共有します。開発アカウントでトランジットゲートウェイを承認します。
解説
この問題の解説を行います。要点は、開発環境のリソースが頻繁に削除・再作成され、開発チームが必要に応じて共有サービスアカウントのリソースへの接続を再作成できる方法を提供することです。ここでは、トランジットゲートウェイを使って、開発アカウントと共有サービスアカウント間の接続を管理する方法に関する問題です。
各選択肢の解説：
A. 開発アカウントにトランジットゲートウェイを作成。開発アカウントから共有サービスアカウントにトランジットゲートウェイピアリングリクエストを作成。共有サービスのトランジットゲートウェイを設定して、ピアリング接続を自動的に承認するようにする。
- 解説: 開発アカウントでトランジットゲートウェイを作成し、ピアリング接続を手動でリクエストして承認を受ける方法です。これでは、開発チームがリソースを再作成するたびに手動で接続を再設定する必要があり、要件で求められている頻繁な接続の再作成に対しては効率的ではありません。また、ピアリング接続の管理は手間がかかるため、このアプローチは最適ではありません。
B. 共有サービスアカウントでトランジットゲートウェイの自動承認をオンにする。AWSリソースアクセスマネージャー（AWS RAM）を使用して、共有サービスアカウントのトランジットゲートウェイリソースを開発アカウントと共有。開発アカウントでリソースを受け入れ、開発アカウント内にトランジットゲートウェイアタッチメントを作成。
- 解説: これは、トランジットゲートウェイをAWSリソースアクセスマネージャー（AWS RAM）で共有する方法です。開発アカウントに対してリソースを共有し、自動承認をオンにすることで、開発アカウントが自動的にトランジットゲートウェイを受け入れることができます。これにより、開発チームは手動で接続を再作成することなく、リソースを再作成するたびに自動的に接続を再作成できるという要件を満たすことができます。最も効率的で簡潔な方法です。
C. 共有サービスアカウントでトランジットゲートウェイの自動承認をオンにする。VPCエンドポイントを作成。エンドポイントポリシーを使用して、開発アカウントに対してVPCエンドポイントの権限を付与。エンドポイントサービスを設定して、接続リクエストを自動的に承認。エンドポイントの詳細を開発チームに提供。
- 解説: この選択肢は、トランジットゲートウェイではなくVPCエンドポイントを利用する方法ですが、VPCエンドポイントは通常、VPC内のリソースへのアクセスを管理するために使用され、トランジットゲートウェイを介したアカウント間接続には適していません。この方法は、接続の管理において無関係な部分が多く、問題の要件に最適ではありません。
D. Amazon EventBridgeルールを作成して、開発アカウントがアタッチメントリクエストを行った際にAWS Lambda関数を呼び出してトランジットゲートウェイアタッチメントを承認。AWSネットワークマネージャーを使用して、共有サービスアカウントのトランジットゲートウェイを開発アカウントと共有。開発アカウントでトランジットゲートウェイを承認。
- 解説: EventBridgeとLambdaを使用してアタッチメントリクエストを承認する方法ですが、これにはかなりの設定作業と自動化が必要です。Lambda関数を使って接続を承認するのは技術的には可能ですが、必要な作業が多く、運用負荷が増える可能性があります。また、要件に対する最適な解決策とは言えません。
最適な解答: B
選択肢 B が最も適切です。この方法では、AWS RAMを使用してトランジットゲートウェイリソースを共有し、自動承認をオンにすることで、開発アカウントが接続を自動的に再作成できるようになります。これにより、開発チームはリソースを削除して再作成しても、手動で接続を再設定することなく、必要な接続を自動的に作成できます。
466-AWS SAP AWS 「理論・実践・一問道場」TCO（総所有コスト）
理論
1. TCO（総所有コスト）レポートの重要性
- TCOレポートは、オンプレミスからクラウド（AWSなど）への移行に伴う総コスト（ハードウェア、ソフトウェア、運用、エネルギー、メンテナンス等）を評価するための重要なツールです。AWSでは、Migration Evaluator（旧称 TCO Calculator）を使用して移行前後のコストを比較できます。
2. Migration Evaluatorの使用
- Migration Evaluatorは、オンプレミスの環境のコストと、AWS環境に移行した場合のコストを見積もるツールです。エージェントレスでデータ収集を行う方法を提供し、SNMPを使用して既存の仮想マシン（VM）からメトリクスを収集します。これにより、物理的な変更を加えることなくコスト評価を行うことができます。
3. エージェントレスデータ収集
- エージェントレスのデータ収集方法は、既存のインフラに変更を加えずに、ネットワークを通じて必要な情報（メモリ、CPU使用率、ストレージ容量など）を収集する手段です。これにより、インストール不要で即座にデータを取得でき、移行計画の初期段階でコスト評価が可能になります。
4. AWS Migration Hubとの連携
- AWS Migration Hubは、移行プロジェクトの管理と追跡を行うツールです。Migration Evaluatorと連携し、収集されたデータを基に移行のTCOレポートを生成します。Migration Hubは、複数の移行ツールと連携し、移行計画全体を一元管理できます。
5. AWSサービスを利用した移行計画
- 企業がAWSに移行する際、Application Migration ServiceやMigration Hub Strategy Recommendationsなど、複数のAWSサービスが利用されます。これらのサービスを使用して、移行するワークロードの評価、最適化、TCO分析を行います。
結論：
この問題は、AWSへの移行におけるTCO評価の方法と、エージェントレスのデータ収集方法を中心に、最適な移行プランを立てるための知識に関するものです。AWSのツールを活用して、移行前後のコストを予測し、効率的なクラウド移行を支援します。
実践
略
一問道場
質問#466
ある企業が、オンプレミスのデータセンターからAWSに仮想Microsoftワークロードを移行しようとしています。この企業は、AWS上でいくつかのサンプルワークロードのテストに成功しています。また、企業はVPCにAWS Site-to-Site VPN接続を作成しています。ソリューションアーキテクトは、データセンターからすべてのワークロードを移行するための総所有コスト（TCO）レポートを作成する必要があります。
データセンター内の各VMでSimple Network Management Protocol（SNMP）が有効化されています。企業は、データセンター内にVMを追加したり、VMに追加のソフトウェアをインストールしたりすることはできません。発見データは自動的にAWS Migration Hubにインポートされる必要があります。
どのソリューションがこれらの要件を満たしますか？
A. AWS Application Migration ServiceのエージェントレスサービスとAWS Migration Hub Strategy Recommendationsを使用してTCOレポートを生成する。
B. WindowsのAmazon EC2インスタンスを起動し、Migration Evaluatorのエージェントレスコレクタをインストールして、Migration EvaluatorでTCOレポートを生成する。
C. WindowsのAmazon EC2インスタンスを起動し、Migration Evaluatorのエージェントレスコレクタをインストールして、Migration HubでTCOレポートを生成する。
D. VPC内でAWS Migration Readiness Assessmentツールを使用し、Migration Evaluatorを構成してTCOレポートを生成する。
解説
この問題の目的は、企業がAWSにワークロードを移行するために、AWS Migration Hubを使用して、オンプレミスのデータセンターからの移行に関する**総所有コスト（TCO）**レポートを自動的に生成する方法を選ぶことです。
まず、要点を整理します：
- 仮想マシン（VM）でSNMPが有効化されている：これにより、既存の仮想マシンのメトリクスや性能データを収集できますが、VMの追加やソフトウェアのインストールはできません。したがって、エージェントレスのソリューションが求められます。
- 自動的にデータをAWS Migration Hubにインポートする必要があります。
- すでにAWS Site-to-Site VPN接続が設定されているため、AWSとオンプレミス環境間でのネットワーク接続は問題ありません。
各選択肢の解説：
- A. AWS Application Migration ServiceのエージェントレスサービスとAWS Migration Hub Strategy Recommendationsを使用してTCOレポートを生成する。
- AWS Application Migration Serviceは通常、エージェントを使用して移行するサービスであり、このシナリオのようにエージェントレスで動作するわけではありません。また、このサービスは移行に重点を置いており、TCOレポートの生成には直接的な関連性がないため、適切な解答ではありません。
- B. WindowsのAmazon EC2インスタンスを起動し、Migration Evaluatorのエージェントレスコレクタをインストールして、Migration EvaluatorでTCOレポートを生成する。
- これはエージェントレスのアプローチで、Migration Evaluatorを使用してTCOレポートを生成する方法です。Migration Evaluatorは、オンプレミスのインフラを評価し、TCOのシミュレーションを行うツールです。エージェントレスのコレクタを使用することで、データセンターのVMにソフトウェアをインストールせずに情報を収集できます。よって、条件に適しています。
- C. WindowsのAmazon EC2インスタンスを起動し、Migration Evaluatorのエージェントレスコレクタをインストールして、Migration HubでTCOレポートを生成する。
- Migration Hubは、移行の追跡と管理を行うサービスですが、TCOレポートの生成には直接的に関連しません。TCOレポートを生成するには、Migration Evaluatorを使用する必要があります。そのため、この選択肢は不適切です。
- D. VPC内でAWS Migration Readiness Assessmentツールを使用し、Migration Evaluatorを構成してTCOレポートを生成する。
- Migration Readiness Assessmentツールは、移行準備状況を評価するためのツールであり、TCOレポートを生成するためのものではありません。このツールは主に移行の準備が整っているかを判断するために使用されるもので、TCOレポートを直接生成する役割はありません。
結論：
最も適切な選択肢はBです。
Bでは、Windows EC2インスタンス上でMigration Evaluatorのエージェントレスコレクタを使用して、TCOレポートを生成できます。エージェントレスでデータセンター内のVMから必要なデータを収集でき、Migration Hubに自動的にデータをインポートする要件も満たします。
467-AWS SAP AWS 「理論・実践・一問道場」レイテンシーベースのルーティング
理論
AWSでのレイテンシーベースおよびフェイルオーバーのルーティング
1. レイテンシーベースのルーティング
- Amazon Route 53 では、レイテンシーエイリアスレコードを使うことで、ユーザーに最も近いリージョンからコンテンツを提供することができます。これにより、ゲームやアプリケーションなど、レスポンス時間を重要視するサービスでのパフォーマンス向上が可能です。
2. ヘルスチェックとターゲットの評価
- Route 53ヘルスチェックを使って、各ALB（Application Load Balancer）の状態を監視できます。ヘルスチェックを設定することで、ターゲットがダウンした場合、トラフィックを別のリージョンに自動的に切り替えることができます。
- Evaluate Target Healthオプションを「はい」に設定すると、ALBのターゲットインスタンスが健康かどうかに基づいて、Route 53がトラフィックをルーティングします。
3. フェイルオーバールーティング
- フェイルオーバールーティングは、1つのリソース（例えばALB）が使用できなくなった場合に、予備のリソースに自動的に切り替えるために使用します。通常は、プライマリリソースがダウンしたときにサブリソースにトラフィックを送信します。
4. CloudFrontとALBの利用
- Amazon CloudFrontはCDN（コンテンツ配信ネットワーク）として、静的コンテンツや動的コンテンツを迅速に配信するために利用されます。ALBをバックエンドとして設定することもできますが、レイテンシー最適化にはRoute 53のレイテンシーエイリアスレコードを使用する方が効率的です。
まとめ:
AWSで最寄りのリージョンにトラフィックをルーティングするためには、Route 53のレイテンシーエイリアスレコードを使い、ヘルスチェックとターゲット評価を組み合わせて可用性とパフォーマンスを向上させます。
実践
略
一問道場
質問#467
ある企業がモバイルゲームを開発しており、ゲームアセットを2つのAWSリージョンで提供しています。ゲームアセットは、それぞれのリージョンにあるAmazon EC2インスタンスのセットから、Application Load Balancer（ALB）を通じて提供されます。企業は、ゲームアセットを最寄りのリージョンから取得できることを要求しています。また、最寄りのリージョンでゲームアセットが利用できない場合、別のリージョンから取得できるようにする必要があります。
ソリューションアーキテクトは、この要件を満たすために何をすべきでしょうか？
A. Amazon CloudFrontディストリビューションを作成し、各ALBのオリジングループを作成します。1つのオリジンをプライマリとして設定します。
B. 各ALBに対してAmazon Route 53のヘルスチェックを作成します。Route 53のフェイルオーバールーティングレコードを作成し、2つのALBを指し示します。Evaluate Target Healthの値を「はい」に設定します。
C. 2つのAmazon CloudFrontディストリビューションを作成し、それぞれのALBをオリジンとして設定します。Amazon Route 53のフェイルオーバールーティングレコードを作成し、2つのCloudFrontディストリビューションを指し示します。Evaluate Target Healthの値を「はい」に設定します。
D. 各ALBに対してAmazon Route 53のヘルスチェックを作成します。Route 53のレイテンシーエイリアスレコードを作成し、2つのALBを指し示します。Evaluate Target Healthの値を「はい」に設定します。
解説
この問題の目的は、ゲームアセットを最寄りのリージョンから取得でき、最寄りのリージョンでアセットが利用できない場合は別のリージョンから取得できるようにすることです。
最も適切なソリューションは D の「各ALBに対してAmazon Route 53のヘルスチェックを作成し、Route 53のレイテンシーエイリアスレコードを作成し、2つのALBを指し示します。Evaluate Target Healthの値を「はい」に設定します。」です。
解説:
- Amazon Route 53のレイテンシーエイリアスレコード:
- レイテンシーエイリアスレコードを使用すると、最寄りのリージョンからトラフィックをルーティングすることができます。Route 53はユーザーのリクエストに対して、最も低いレイテンシーを持つリソースに自動的にリクエストを送信します。このため、ゲームアセットは最寄りのリージョンから提供されます。
- ヘルスチェックとEvaluate Target Healthの設定:
- 各ALBに対してヘルスチェックを設定し、Evaluate Target Healthを「はい」に設定することで、ALBが正常でない場合に自動的に別のリージョンに切り替えられるようになります。これにより、片方のリージョンが利用できない場合にもう一方のリージョンからゲームアセットを提供できます。
他の選択肢について:
- A. Amazon CloudFrontディストリビューションを作成し、各ALBのオリジングループを作成:
- CloudFrontは通常、コンテンツ配信に使用され、ALBをバックエンドとして設定することもできますが、レイテンシーベースのルーティングを行うためにはRoute 53の機能がより適しています。この方法は要件に合いません。
- B. 各ALBに対してRoute 53のヘルスチェックとフェイルオーバールーティングレコード:
- フェイルオーバールーティングは主にプライマリリソースがダウンしたときにサブリソースへ切り替えるために使用されますが、最寄りのリージョンからトラフィックを優先的にルーティングするには、レイテンシーエイリアスレコードの方が適しています。
- C. 2つのCloudFrontディストリビューションを作成し、Route 53のフェイルオーバールーティングレコードを作成:
- 2つのCloudFrontディストリビューションを使用する方法は不必要に複雑であり、レイテンシーエイリアスレコードを使った方が簡便かつ効率的です。
結論として、D の選択肢が最も適切な解答です。
468-AWS SAP AWS 「理論・実践・一問道場」Apache Parquet パーケット
理論
Athenaのパフォーマンス最適化とデータ形式
Amazon Athenaは、Amazon S3に保存されたデータに対してSQLクエリを実行できるサービスです。パフォーマンスを向上させ、コストを削減するためのベストプラクティスを以下にまとめます。
1. 適切なデータ形式の選択
- Apache Parquetは、Athenaでのクエリパフォーマンスを大幅に向上させるために最適なデータ形式です。Parquetは列指向のフォーマットで、クエリ時に必要な列だけを読み込むため、スキャンするデータ量が減り、クエリが高速化します。また、Parquetは圧縮効率が高く、ストレージコストの削減にも寄与します。
- JSONやCSVは一般的にテキストベースのフォーマットですが、クエリのパフォーマンスはParquetほど高くありません。Athenaでのクエリを効率的にするためには、データ形式をParquetに変換することを推奨します。
2. パーティションの活用
- Athenaではパーティションを使用することで、クエリが対象とするデータの範囲を絞り、パフォーマンスを大幅に向上させることができます。例えば、ログデータを時間単位（年、月、日）でパーティション分けすることで、クエリ時に特定の期間のデータのみをスキャンでき、検索時間が短縮されます。
- パーティションの設計はデータの使用パターンに基づいて行う必要があり、過剰なパーティション化は逆にパフォーマンスを悪化させることもあります。
3. 圧縮
- 圧縮はストレージの効率化とクエリパフォーマンスの向上に重要です。Athenaは圧縮されたファイルを直接クエリできるため、適切な圧縮方式を使用することが推奨されます。
- Parquet形式自体は圧縮されているため、追加の圧縮は不要ですが、テキストファイル（CSVやJSON）を圧縮して保存する場合は、GzipやSnappyなどの効率的な圧縮形式を使用することが良いです。
4. Athenaの設定と最適化
- Athenaエンジンバージョン: Athenaは新しいエンジンバージョン（例：Athenaエンジンバージョン2）を提供しており、これにはクエリパフォーマンスの改善やコスト削減が含まれています。最新のエンジンバージョンを使用することで、より効率的にデータを処理できます。
- メモリや並列処理の最適化: Athenaの設定を最適化することで、より効率的にクエリを処理することが可能です。特に、大規模なデータセットを扱う場合は、適切なワークグループ設定を行い、リソースの最適化を図ることが重要です。
まとめ
Athenaでのクエリパフォーマンスを最適化するためには、Parquet形式を使用し、パーティションや圧縮を活用することが基本です。また、Athenaエンジンバージョンの更新や適切なワークグループ設定を行うことで、より効率的なデータ分析が可能になります。
実践
略
一問道場
質問 #468
ある企業は、複数のAWSアカウントにワークロードをデプロイしています。各アカウントにはVPCがあり、VPCフローログはテキストログ形式で中央のAmazon S3バケットに発行されています。各ログファイルはgzip圧縮されています。企業はログファイルを無期限に保持する必要があります。
セキュリティエンジニアは、Amazon Athenaを使用してVPCフローログを分析していますが、ログが増えるにつれてクエリのパフォーマンスが低下しています。ソリューションアーキテクトは、ログ分析のパフォーマンスを改善し、VPCフローログの使用するストレージスペースを削減する必要があります。
どのソリューションが最も大きなパフォーマンス改善をもたらしますか？
A. AWS Lambda関数を作成して、gzipファイルを解凍し、bzip2圧縮でファイルを圧縮します。Lambda関数をS3バケットのs3:ObjectCreated:Put S3イベント通知にサブスクライブします。
B. S3バケットでS3転送加速を有効にし、ファイルがアップロードされるとすぐにファイルをS3インテリジェントティアリングストレージクラスに移動するS3ライフサイクル設定を作成します。
C. VPCフローログの設定を更新して、ファイルをApache Parquet形式で保存します。ログファイルのために時間単位のパーティションを指定します。
D. 新しいAthenaワークグループを作成し、データ使用制限を設定しないようにします。Athenaエンジンバージョン2を使用します。
解説
この問題は、VPCフローログの分析パフォーマンスを改善し、ストレージスペースを削減するための最適なソリューションを選択する問題です。解説は以下の通りです。
各選択肢の解説:
A. AWS Lambda関数を作成して、gzipファイルを解凍し、bzip2圧縮でファイルを圧縮します。Lambda関数をS3バケットのs3:ObjectCreated:Put S3イベント通知にサブスクライブします。
- 問題点: GzipからBzip2に圧縮方法を変更することは、ストレージの使用効率を改善できるかもしれませんが、Athenaでのクエリパフォーマンスを劇的に向上させることはありません。また、Lambdaで圧縮を変更することはオーバーヘッドが高く、ファイルの取り扱いが複雑になる可能性があります。
- 結論: パフォーマンス改善には効果が少なく、ストレージ効率も大きな改善にはつながりません。
B. S3転送加速を有効にし、S3インテリジェントティアリングストレージクラスに移動するS3ライフサイクル設定を作成します。
- 問題点: S3転送加速はデータのアップロード速度を向上させるものであり、ストレージの効率やAthenaのクエリパフォーマンスには直接的な影響を与えません。また、インテリジェントティアリングはコストの最適化には役立つかもしれませんが、パフォーマンスの改善には繋がりません。
- 結論: パフォーマンス向上にはほとんど寄与しません。
C. VPCフローログの設定を更新して、ファイルをApache Parquet形式で保存します。ログファイルのために時間単位のパーティションを指定します。
- ベストプラクティス: Apache Parquet形式は列指向のフォーマットで、Athenaのクエリパフォーマンスを大幅に改善します。AthenaはParquet形式でデータを効率的に処理でき、圧縮率も高いためストレージコストも削減されます。また、時間単位のパーティションを指定することで、クエリが必要な部分のみをスキャンするため、パフォーマンスがさらに向上します。
- 結論: この方法は、パフォーマンスの大幅な改善とストレージの削減に最も効果的です。
D. 新しいAthenaワークグループを作成し、データ使用制限を設定しないようにします。Athenaエンジンバージョン2を使用します。
- 問題点: Athenaエンジンバージョン2はパフォーマンスが向上する可能性がありますが、根本的にデータ形式（例えばParquet形式）やストレージの効率を改善するものではありません。また、データ使用制限を設定しないことでコストの管理が難しくなる可能性があります。
- 結論: パフォーマンス向上の効果はありますが、データフォーマットの最適化に比べると改善幅は限定的です。
結論:
C. VPCフローログの設定を更新して、ファイルをApache Parquet形式で保存します。ログファイルのために時間単位のパーティションを指定します。
が最も効果的な解決策です。Parquet形式とパーティションを使用することで、Athenaのクエリパフォーマンスが大幅に改善され、ストレージの効率化も実現できます。
469-AWS SAP AWS 「理論・実践・一問道場」ルート広告 BGP
理論
Direct Connectゲートウェイ と VIF または Transit Gateway の使用
1. Direct Connect網ゲートウェイ + 2つのVIF
このアーキテクチャでは、Direct Connect を使って本社ネットワークと2つのVPCを接続します。各VPCに対して個別のVIFを使用します。
- 1つのDirect Connect網ゲートウェイ：複数のVPCを接続するために使用します。
- 2つのVIF（Virtual Interface）：
- 各VPCには個別の私有VIFが必要で、本社ネットワークと各VPC間の通信を担当します。
- 1つのVIFはVPC1に、もう1つはVPC2に接続します。
流れ：
- 本社ネットワーク → VIF1 → Direct Connect網ゲートウェイ → VPC1
- 本社ネットワーク → VIF2 → Direct Connect網ゲートウェイ → VPC2
この方法では、Direct Connect網ゲートウェイが本社ネットワークと2つのVPC間の通信を管理します。VPC間の直接通信はなく、VPCごとに独立してVIFを使用します。
2. Direct Connect網ゲートウェイ + Transit Gateway + 1つのVIF
複数のVPCがある場合や、VPC間の通信を集中管理したい場合に、Transit Gateway を使用する方法です。
- 1つのDirect Connect網ゲートウェイ：本社ネットワークをTransit Gateway に接続します。
- 1つのVIF：本社ネットワークとDirect Connect網ゲートウェイを接続します。
- Transit Gateway：本社ネットワークと複数のVPC間で流れるトラフィックを集中管理します。
流れ：
- 本社ネットワーク → VIF → Direct Connect網ゲートウェイ → Transit Gateway → VPC1 & VPC2
この方法では、Transit Gateway がVPC1とVPC2間の通信を管理し、両方のVPCと本社ネットワークの接続を中継します。VPC間の通信が直接可能になり、1つのVIFで複数のVPCを接続できます。
どちらの方法を選ぶべきか？
- Direct Connect網ゲートウェイ + 2つのVIF：
- 複数のVPC間での直接通信は必要なく、各VPCごとに個別に接続したい場合。
- 本社ネットワークとVPC間の個別接続が求められる場合。
- Direct Connect網ゲートウェイ + Transit Gateway + 1つのVIF：
- 複数のVPC間で通信を集中管理したい場合（例えば、VPC1とVPC2が直接通信できるようにしたい場合）。
- VPC間通信をTransit Gatewayを介して管理し、本社ネットワークからのトラフィックを一元管理したい場合。
まとめ：
- 2つのVPCを接続する場合、Direct Connect網ゲートウェイ + 2つのVIF は各VPCに個別に接続する方法です。
- 複数のVPC間での通信を集中管理するには、Direct Connect網ゲートウェイ + Transit Gateway + 1つのVIF の方が効率的です。
ルート広告（BGPの広告）とは？
- 広告する（advertise） というのは、BGP（Border Gateway Protocol） を使って、特定の IPアドレス範囲（プレフィックス） を他のネットワークに通知する行為を指します。
- これにより、ネットワーク間で経路情報が交換され、受け取ったネットワークは、そのプレフィックスに到達するための経路を自動的にルートテーブルに登録します。
ルートテーブルの自動登録とは？
- ルートテーブルの自動登録は、BGP広告 を受け取った後、受信側のルーターが自動的にその経路情報を自分のルートテーブルに追加することです。
- これにより、ネットワーク間の通信が可能になり、各ネットワークがどのIP範囲にどうアクセスするかを決定します。
具体的な流れ（例）：
- AWS VPCからプレフィックスを広告する：
- AWSが自分のVPCのプレフィックス（例：
10.0.0.0/16）を BGP を通じて オンプレミスネットワーク に「広告」します。 - オンプレミスのネットワーク（ルーター）は、このプレフィックスを受け取り、そのプレフィックスがどの経路を通じて到達するかを決定します。
- その後、オンプレミスのルーターは自動的に自分のルートテーブルに
10.0.0.0/16の経路を追加します。
- オンプレミスネットワークからプレフィックスを広告する：
- オンプレミスネットワークが自分のネットワークプレフィックス（例：
192.168.1.0/24）を BGP を通じて AWS に「広告」します。 - AWSのDirect Connectゲートウェイがこの情報を受け取り、AWS内のルーターが自動的にそのプレフィックスを自分のルートテーブルに登録します。
まとめ：
- 広告する という行為は、BGPを使用してネットワーク間でIPアドレス範囲（プレフィックス）を通知し、相手のネットワークがその情報を基に自分のルートテーブルを自動的に更新することを意味します。
- ルートテーブルの自動登録 は、BGP広告を受けた結果として、ルーターがその経路情報を自動的に自分のルートテーブルに追加するプロセスです。
したがって、「広告する」と「ルートテーブルの自動登録」は密接に関連しており、BGPを通じて自動的に経路情報が交換され、ルートテーブルが更新されるという流れを指します。
ルートテーブル例：
オンプレミスネットワーク（例：192.168.1.0/24）のルートテーブル：
宛先（Destination） | ゲートウェイ（Gateway） |
10.0.0.0/16 | AWS Direct Connect経由 |
AWS VPCのルートテーブル（例：10.0.0.0/16）：
宛先（Destination） | ゲートウェイ（Gateway） |
192.168.1.0/24 | Direct Connectゲートウェイ |
自動登録：
- オンプレミスネットワーク のルーターは、AWS VPC のプレフィックス（
10.0.0.0/16）を広告してもらった後、その情報を自動的に自分のルートテーブルに登録します。
- 同様に、AWS VPC のルーターも、オンプレミスネットワーク のプレフィックス（
192.168.1.0/24）を広告してもらった後、それを自動的にルートテーブルに登録します。
これにより、AWS VPCとオンプレミスネットワーク間での通信が可能になります。
実践
略
一問道場
質問 #469
ある企業は、オンプレミスのインフラとAWS間に専用接続を確立したいと考えています。企業は、1 GbpsのAWS Direct Connect接続を自社のVPCに設定しています。アーキテクチャには、複数のVPCとオンプレミスのインフラを接続するためのトランジットゲートウェイとDirect Connectゲートウェイが含まれています。
企業は、Direct Connect接続を使ってトランジットVIF経由でVPCリソースに接続する必要があります。
これらの要件を満たすために必要な手順の組み合わせはどれですか？（2つ選んでください）
A. 1 GbpsのDirect Connect接続を10 Gbpsに変更する。
B. トランジットVIF経由でオンプレミスネットワークのプレフィックスを広告する。
C. Direct ConnectゲートウェイからVPCのプレフィックスをオンプレミスネットワークにトランジットVIF経由で広告する。
D. Direct Connect接続のMACsec暗号化モードを「mustencrypt」に設定する。
E. Direct Connect接続にMACsec接続キー名/接続関連キー（CKN/CAK）ペアを関連付ける。
解説
この問題の解説を行います。問題の要点は、AWS Direct Connectを利用して、オンプレミスのインフラストラクチャとAWS間で接続を確立し、トランジットVIF経由でVPCリソースにアクセスする方法を理解することです。
概要
企業は、AWS Direct Connectを使って自社のオンプレミスインフラとAWS環境を接続し、VPCリソース（例えば、EC2インスタンスなど）にアクセスしたいと考えています。設定には、トランジットゲートウェイ（Transit Gateway）とDirect Connectゲートウェイ（Direct Connect Gateway）を活用して、複数のVPCとオンプレミスのインフラを接続する必要があります。
流量は、オンプレミスからAWSへ、またはその逆に、**トランジットVIF（Virtual Interface）**を通じて流れることになります。この要求を満たすためには、いくつかの設定を適切に行う必要があります。
主要なコンポーネント
- AWS Direct Connect：オンプレミスのデータセンターとAWS間の専用回線を提供します。
- トランジットゲートウェイ：複数のVPCやオンプレミスネットワークを接続するためのAWSサービスです。
- Direct Connectゲートウェイ：Direct Connect接続をVPCに接続するためのサービスで、AWS上のVPCに接続された複数のネットワーク間の通信を可能にします。
- トランジットVIF：VPCリソースへのアクセスに使用される仮想インターフェースです。
問題の要点と解説
企業が目指すべき設定は、オンプレミスのネットワークからAWS上のVPCリソースへアクセスすることです。そのために必要な手順は以下の通りです：
選択肢の解説：
- A: 1 GbpsのDirect Connect接続を10 Gbpsに更新する
- この選択肢は、単に帯域幅の増加を提案していますが、問題の要件には帯域幅の増加は必須ではありません。この設定を行わなくても、トランジットVIFを経由してリソースへの接続は可能です。
- B: トランジットVIF経由でオンプレミスネットワークのプレフィックスを広告する
- 必須のステップです。トランジットVIFを介して、オンプレミスネットワークのIPプレフィックス（ネットワーク範囲）をAWSに広告する必要があります。これにより、AWSからオンプレミスネットワークへのルーティングが可能になります。
- C: Direct ConnectゲートウェイからVPCプレフィックスをオンプレミスネットワークにトランジットVIF経由で広告する
- 必須のステップです。Direct Connectゲートウェイは、VPC内のリソース（例：EC2インスタンスなど）のIPプレフィックスをオンプレミスネットワークに広告する役割を果たします。これにより、オンプレミスからVPCリソースへのルーティングが可能になります。
- D: Direct Connect接続のMACsec暗号化モード属性を「mustencrypt」に更新する
- この設定は、セキュリティを強化するためにMACsec（Media Access Control Security）を利用するための設定ですが、問題文に記載されている要件には関係ありません。したがって、必須ではありません。
- E: MACsec接続キー名/接続関連キー（CKN/CAK）ペアをDirect Connect接続に関連付ける
- Dと同様、これはセキュリティ設定に関連しており、暗号化を強化するオプションですが、要件には含まれていません。
正しい解答：
- BとCの組み合わせが正しい解答です。
- B: トランジットVIF経由でオンプレミスネットワークのプレフィックスを広告する。
- C: Direct ConnectゲートウェイからVPCプレフィックスをオンプレミスネットワークにトランジットVIF経由で広告する。
なぜBとCなのか：
- Bでは、オンプレミスからAWSにルーティングされるための情報（ネットワークプレフィックス）を提供します。これにより、オンプレミスネットワークがAWSリソースにアクセスできるようになります。
- Cでは、AWSのVPCリソースにアクセスできるよう、VPCのネットワークプレフィックスをオンプレミスネットワークに広告します。これにより、オンプレミスネットワークがVPCのリソースにアクセスできるようになります。
まとめ：
- トランジットVIFを使って、オンプレミスとAWSのVPCリソース間で通信を確立するためには、BとCの手順が必須です。
- A、D、Eはこのシナリオには関連性が低く、必要な設定ではありません。
470-AWS SAP AWS 「理論・実践・一問道場」WorkSpacesディレクトリにIPアクセスコントロールグループ
理論
Amazon WorkSpacesにおけるセキュリティ制御のベストプラクティス
Amazon WorkSpacesを利用する際、企業のセキュリティポリシーを満たすための主な手法とその特徴を以下にまとめます。
1. IPアクセスコントロールグループ
- 概要 WorkSpacesへのアクセスを許可するIPアドレスの範囲を制御します。
- 利点
- 支店や拠点ごとの公開IPアドレスをリスト化し、WorkSpacesディレクトリに適用可能。
- 新しい支店を開設した場合でも、IPリストを更新するだけで対応可能。
- 運用効率 管理がシンプルで、セキュリティ要件に容易に適合。
2. AWS Firewall Manager
- 概要 複数のAWSアカウントでファイアウォールルールを一元管理します。
- 適用例 Webアプリケーションファイアウォール（AWS WAF）と組み合わせてWebトラフィックを制御。
- 注意点 Amazon WorkSpacesの直接的なIP制御には使用できない。
3. デバイス証明書と認証
- 概要 AWS Certificate Manager（ACM）を利用してデバイス証明書を発行し、信頼されたデバイスのみアクセスを許可します。
- 利点 高度なセキュリティを実現。
- 課題 導入コストと運用負担が大きく、小規模なネットワークには不向き。
4. カスタムWorkSpaceイメージ
- 概要 カスタムイメージを作成し、Windows Firewallやその他のセキュリティ設定を適用。
- 課題
- 各WorkSpaceに個別設定が必要。
- 拡張性に乏しく、管理負担が増大。
5. その他の考慮事項
- セキュリティ要件の変化 新しい拠点や従業員増加に柔軟に対応できる仕組みが必要。
- コストと効率 導入コストを抑え、運用のシンプルさを重視することが重要。
結論
運用効率とセキュリティのバランスを考慮すると、IPアクセスコントロールグループはAmazon WorkSpacesのアクセス制御に最適な方法です。この方法は、拡張性が高く、企業のセキュリティポリシーに適合します。
実践
略
一問道場
質問 #470
ある企業は、Amazon WorkSpacesを薄型クライアントデバイスと組み合わせて、老朽化したデスクトップを置き換えたいと考えています。従業員は、臨床試験データと連携するアプリケーションにアクセスするためにデスクトップを使用しています。企業のセキュリティポリシーでは、アプリケーションへのアクセスを会社の支店所在地に限定する必要があります。企業は、今後6ヶ月以内に追加の支店を開設する予定です。
最も運用効率の良い方法でこの要件を満たすソリューションはどれですか？
A. 支店の公開アドレスのリストを使用して、IPアクセスコントロールグループのルールを作成します。WorkSpacesディレクトリにIPアクセスコントロールグループを関連付けます。
B. AWS Firewall Managerを使用して、支店所在地の公開アドレスのリストを持つIPセットを使用してWeb ACLルールを作成します。Web ACLをWorkSpacesディレクトリに関連付けます。
C. AWS Certificate Manager（ACM）を使用して、支店所在地に展開されたマシンに信頼されたデバイス証明書を発行します。WorkSpacesディレクトリで制限されたアクセスを有効にします。
D. 支店の公開アドレスにアクセスを制限するように設定されたWindows Firewallを使用してカスタムWorkSpaceイメージを作成します。そのイメージを使用してWorkSpacesを展開します。
解説
正解は A. 支店の公開アドレスのリストを使用して、IPアクセスコントロールグループのルールを作成します。WorkSpacesディレクトリにIPアクセスコントロールグループを関連付けます。 です。
理由
- セキュリティポリシーの要件
企業のセキュリティポリシーは、アプリケーションへのアクセスを支店所在地に限定することを求めています。この要件を満たすために、IPアドレスベースの制御が適切です。
- 運用効率
- IPアクセスコントロールグループは、Amazon WorkSpacesディレクトリに直接関連付けて使用できる機能で、特定のIPアドレスまたはアドレス範囲からのアクセスのみを許可します。
- 新しい支店が開設された場合でも、IPアドレスをリストに追加するだけで対応可能であり、管理が容易です。
- 他の選択肢と比較
- B. AWS Firewall Manager Firewall Managerは主にWebアプリケーションファイアウォール（WAF）の管理に使用され、Amazon WorkSpacesのディレクトリに直接関連付けることはできません。
- C. AWS Certificate Manager デバイス証明書を利用する方法は複雑で、管理オーバーヘッドが高くなります。また、この要件に適合する最適な方法ではありません。
- D. Windows Firewallを使用したカスタムイメージ 各WorkSpaceに個別設定を適用する必要があり、運用効率が悪く、拡張性に欠けます。
補足
IPアクセスコントロールグループは、Amazon WorkSpacesのセキュリティ要件に対応する標準的な方法であり、簡単かつ効率的に管理できます。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/17bd7ae8-88e2-809e-9830-f71156f195e1
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
