type
status
date
slug
summary
tags
category
icon
password
331-AWS SAP AWS 「理論・実践・一問道場」カットオーバー
理論
カットオーバー(cut over)とは、IT用語で、新しく開発されたシステムやウェブサイトが稼働を開始することを意味する和製英語です。また、旧システムから新システムへの切り替えの際にも使われます。
1. AWS DataSync
AWS DataSyncは、オンプレミス環境とAWSの間で大規模なデータを高速かつ効率的に転送するサービスです。特に、ファイルシステム間でのデータ転送において非常に有効です。DataSyncは、ネットワーク帯域幅の最適化、転送の高速化、エラー処理の強化などを提供し、AWSのストレージサービス(S3やEFSなど)との統合が可能です。例えば、オンプレミスのNFSやSMBファイルシステムからAmazon EFSへのデータ転送にも利用できます。
- 使用ケース:
- 大量のデータを迅速にAWSに移行したい場合
- オンプレミスのファイルシステムとAWS間でデータを頻繁に同期させる必要がある場合
2. Amazon EFS (Elastic File System)
Amazon EFSは、AWSのフルマネージド型のNFSファイルシステムで、スケーラブルで高可用性のストレージを提供します。EFSは、EC2インスタンスやコンテナなどの複数のAWSリソースからアクセス可能で、複数のアプリケーションが同時にファイルを共有する必要がある場合に最適です。
- 特徴:
- 高可用性と耐久性
- ストレージ容量は自動的にスケールする
- NFS v4.1またはv4.0を使用して、EC2インスタンスやオンプレミスサーバーと簡単に接続できる
3. AWS Direct Connect
AWS Direct Connectは、オンプレミスのデータセンターとAWS間で専用線接続を提供するサービスです。これにより、高速かつ安定したデータ転送が可能になります。特に、大量のデータ転送をAWSに移行する際に、インターネット経由ではなく専用線を使用することで、より一貫性のあるパフォーマンスを提供します。
- 特徴:
- 高帯域幅と低遅延
- インターネット経由のトラフィックを減らす
- 安定したネットワーク接続を提供
4. AWS Storage Gateway
AWS Storage Gatewayは、オンプレミスの環境とAWSクラウドストレージサービス(S3、EFSなど)を橋渡しするハイブリッドクラウドサービスです。特にバックアップやアーカイブ用途で使用されることが多いですが、ファイルシステムとの接続も可能です。Storage Gatewayは、オンプレミスのデータをAWSのクラウドストレージにシームレスにバックアップするためのアプローチを提供します。
- 種類:
- File Gateway: オンプレミスのNFS/Samba環境とS3の間でデータを同期
- Volume Gateway: 仮想ディスクをAWSに同期
- Tape Gateway: テープバックアップをクラウドに転送
5. AWS Lambda
AWS Lambdaは、サーバーレスコンピューティングサービスで、イベント駆動型でコードを実行できます。Lambdaはデータ転送後の処理(例えば、S3にアップロードされたデータのコピーや加工)に使用されますが、データの転送そのものを効率的に処理することは得意ではありません。Lambdaは他のサービスと組み合わせて使用するのが一般的です。
- 使用ケース:
- S3イベント通知をトリガーにして、追加の処理を実行
- 自動的にデータを転送した後に必要な処理を行う
6. VPCエンドポイント (PrivateLink)
AWS PrivateLinkは、VPC内のリソースとAWSサービス(EFSなど)との間でプライベートな接続を提供します。これにより、インターネットを経由せずにAWSサービスと通信することができ、セキュリティとパフォーマンスが向上します。
- 使用ケース:
- AWSのサービス(EFS、S3など)へのアクセスをプライベートに保つ
- セキュリティやネットワークの制約がある環境で通信を行う場合
結論
これらの技術やサービスを理解して、適切に組み合わせることで、オンプレミスのデータを効率的にAWSに移行し、適切なストレージサービスに保存することができます。特に、AWS DataSyncやEFS、Direct Connectは、大規模なデータ転送やストレージに適したソリューションです。
実践
略
一問道場
問題#331
ある企業がアプリケーションをAWSクラウドに移行しています。このアプリケーションはオンプレミスのデータセンターで実行されており、毎晩何千枚もの画像をマウントされたNFSファイルシステムに書き込んでいます。会社がアプリケーションを移行した後、アプリケーションはAmazon EC2インスタンスでホストされ、マウントされたAmazon Elastic File System(Amazon EFS)ファイルシステムに画像を保存します。会社はAWS Direct Connect接続を確立しています。移行カットオーバー前に、ソリューションアーキテクトは、新たに作成されたオンプレミスの画像をEFSファイルシステムに複製するプロセスを構築する必要があります。
最も運用効率が高い方法で画像を複製するには、どの方法を選ぶべきですか?
A.オンプレミスのファイルシステムからAmazon S3にaws s3 syncコマンドを定期的に実行するプロセスを設定し、Amazon S3からのイベント通知を処理するAWS Lambda関数を設定して、画像をAmazon S3からEFSファイルシステムにコピーする。
B.AWS Storage GatewayファイルゲートウェイをNFSマウントポイントでデプロイし、オンプレミスサーバーでファイルゲートウェイファイルシステムをマウントする。定期的に画像をマウントポイントにコピーするプロセスを設定する。
C.AWS DataSyncエージェントをオンプレミスサーバーにデプロイし、NFSファイルシステムにアクセスして、Direct Connect接続を使用してS3バケットにデータを送信する。AWS Lambda関数を設定して、Amazon S3からのイベント通知を処理し、画像をEFSファイルシステムにコピーする。
D.AWS DataSyncエージェントをオンプレミスサーバーにデプロイし、NFSファイルシステムにアクセスして、Direct Connect接続を使用してAmazon EFSのためにAWS PrivateLinkインターフェースVPCエンドポイントにデータを送信する。DataSyncのスケジュールされたタスクを設定して、画像をEFSファイルシステムに毎日24時間ごとに送信する。
解説
この問題において最も運用効率が高い方法は、選択肢 D です。以下でその理由を解説します。
解説
選択肢 D:
AWS DataSyncエージェントをオンプレミスサーバーにデプロイし、NFSファイルシステムにアクセスして、Direct Connect接続を使用してAmazon EFSのためにAWS PrivateLinkインターフェースVPCエンドポイントにデータを送信する。DataSyncのスケジュールされたタスクを設定して、画像をEFSファイルシステムに毎日24時間ごとに送信する。
この方法は最も運用効率が高いです。その理由は以下の通りです:
- AWS DataSyncは、オンプレミスとAWSの間でデータを効率的に転送するサービスです。特に大量のデータやファイルを高速かつ安定して転送する際に非常に効果的です。DataSyncは転送のパフォーマンスを最適化し、帯域幅の使用効率も高いため、運用面で効率的です。
- AWS PrivateLinkを使用して、EFSとオンプレミス環境を安全かつプライベートに接続できます。PrivateLinkはVPCエンドポイントを介して、インターネットを経由せずに通信するため、セキュアな通信を提供します。
- 定期的なスケジュールタスクを設定することで、毎日自動的に画像がEFSに送信されるようになります。この自動化により、運用管理の手間を大幅に削減でき、安定したデータ転送が実現します。
他の選択肢の解説
- 選択肢 A:
aws s3 sync
コマンドを使用してS3にデータを同期し、その後LambdaでEFSにコピーする方法ですが、S3を経由するため、追加のストレージコストやLambdaの処理コストが発生します。また、S3からEFSへのコピーという手順が不要なため、効率的ではありません。- 選択肢 B:
AWS Storage Gatewayを使用してオンプレミスのファイルをAWSに複製する方法です。しかし、Storage Gatewayは主にバックアップやディザスタリカバリに使われることが多く、直接的に高パフォーマンスなデータ転送を行うには適していません。
- 選択肢 C:
DataSyncとLambdaを組み合わせる方法ですが、Lambdaでの処理が必要となり、Lambda関数の実行に伴うコストと複雑性が増します。これに対して、DataSyncのみで効率的にデータ転送を行うDが優れています。
結論
選択肢 Dは、最も効率的でコストパフォーマンスも高く、運用の手間が少なく、移行後の運用にも適した方法です。
332-AWS SAP AWS 「理論・実践・一問道場」CloudFront管理プレフィックスリスト
理論
CloudFrontとALBの連携に関する汎用的知識
WebアプリケーションをAWSで構築する際、CloudFrontとALB(Application Load Balancer)を組み合わせることで、高速でセキュアな配信を実現できます。ただし、CloudFrontを経由せず直接ALBにアクセスされることを防ぐ設定が必要になる場合があります。以下に、この問題に関連する重要な知識を簡潔にまとめます。
CloudFrontとALBの役割
- CloudFront
- グローバルコンテンツ配信ネットワーク(CDN)。
- キャッシュを利用して高速化し、トラフィックを最適化。
- セキュリティ機能(AWS WAFやオリジンアクセス制御)を提供。
- ALB
- アプリケーション層の負荷分散を提供。
- 複数のターゲット(EC2、ECSなど)にトラフィックを分散。
CloudFront経由のみアクセスを許可する方法
CloudFrontを通さず直接ALBにアクセスされるリスクを防ぐには、以下の方法を使用します。
1. CloudFront管理プレフィックスリストを利用
- AWSはCloudFront用の管理プレフィックスリストを提供しています。
- 設定方法:
- ALBのセキュリティグループのインバウンドルールに、
com.amazonaws.global.cloudfront.origin-facing
を指定。 - これにより、CloudFrontのオリジン-facingエッジIPのみがALBにアクセス可能となる。
2. AWS WAFを活用
- ALBにAWS WAFを設定し、特定のリファラーやIPからのアクセスを制限。
- WAFのルールを利用して、CloudFront以外からのトラフィックをブロック。
3. Lambda@Edgeを利用
- CloudFrontのリクエスト時にLambda@Edgeを使用して、リファラーを検証。
- ALBに直接アクセスされるリクエストをCloudFrontレベルでブロック可能。
運用上の注意点
- CloudFrontのIP変更:
ip-ranges.json
を手動で利用する方法は非推奨。管理プレフィックスリストを使用する方が効率的。
- コスト最適化:
- CloudFrontを経由することでキャッシュが効率化され、ALBの負荷を軽減。
まとめ
CloudFrontとALBを安全かつ効率的に運用するには、管理プレフィックスリストを利用してALBへのアクセスを制限することが最も推奨されます。この設定により、CloudFront経由のみのアクセスを簡単に実現できます。
実践
略
一問道場
質問 #332
ある企業が、WebアプリケーションをオンプレミスのデータセンターからAWSクラウドに移行しました。このWebアプリケーションのインフラストラクチャは、Amazon CloudFrontディストリビューションを使用してApplication Load Balancer(ALB)にルーティングし、Amazon Elastic Container Service(Amazon ECS)でリクエストを処理する構成です。最近のセキュリティ監査で、このWebアプリケーションがCloudFrontエンドポイントとALBエンドポイントの両方からアクセス可能であることが判明しました。しかし、企業はWebアプリケーションがCloudFrontエンドポイントからのみアクセス可能であることを求めています。
最小限の手間でこの要件を満たすソリューションはどれですか?
A: 新しいセキュリティグループを作成し、それをCloudFrontディストリビューションにアタッチする。ALBセキュリティグループのインバウンドルールを更新して、CloudFrontのセキュリティグループからのみアクセスを許可する。
B: ALBセキュリティグループのインバウンドルールを更新して、CloudFront管理プレフィックスリスト
com.amazonaws.global.cloudfront.origin-facing
のみからのアクセスを許可する。C: Elastic Load Balancing用のVPCインターフェイスエンドポイント
com.amazonaws.region.elasticloadbalancing
を作成する。ALBのスキームを「インターネット向け」から「内部」に変更する。D: AWSが提供する
ip-ranges.json
ドキュメントからCloudFrontのIPを抽出する。ALBセキュリティグループのインバウンドルールを更新して、CloudFront IPのみからのアクセスを許可する。解説
解説
この問題の目的は、Webアプリケーションが CloudFrontエンドポイント のみを介してアクセスできるようにし、直接のALBエンドポイントからのアクセスを制限することです。以下、各選択肢について解説します。
A: CloudFront用のセキュリティグループを作成してALBに適用
- CloudFrontに直接セキュリティグループを適用することはできません。CloudFrontはAWSのエッジサービスであり、EC2やALBのようにセキュリティグループをサポートしていないため、このアプローチは技術的に不可能です。
- 不適切な回答です。
B: CloudFront管理プレフィックスリストを使用する
- AWSはCloudFrontの管理プレフィックスリスト(
com.amazonaws.global.cloudfront.origin-facing
)を提供しています。このリストには、CloudFrontのオリジン-facingエッジIPが含まれています。
- ALBセキュリティグループのインバウンドルールを更新して、このプレフィックスリストのみにアクセスを許可することで、CloudFront経由のみのアクセスを実現できます。
- 最も効率的な方法であり、正解です。
C: ALBを内部ALBに変更する
- ALBを「インターネット向け」から「内部」に変更することで、ALBがプライベートアクセス専用になります。ただし、この方法ではCloudFrontのIP範囲を明示的に許可する設定が別途必要になります。
- この方法は、設定が複雑になるため、手間が増えます。
- 効率的ではないため不適切です。
D: ip-ranges.json
からCloudFrontのIPを抽出して設定
- AWSが提供する
ip-ranges.json
ファイルにはCloudFrontのIPアドレス範囲が記載されています。この情報を手動でALBセキュリティグループに設定することで、CloudFront経由のトラフィックのみを許可できます。
- ただし、この方法ではCloudFrontのIP範囲が変更された場合に都度更新が必要になり、運用負荷が増加します。
- Bと比べると手間が多いため不適切です。
正解: B
CloudFront管理プレフィックスリストを使用することで、簡単かつ効率的にCloudFront経由のトラフィックのみを許可できます。この方法は、運用負荷も最小限に抑えられるため、推奨される解決策です。
333-AWS SAP AWS 「理論・実践・一問道場」バックアップとリストア
理論
AWSにおける災害復旧(Disaster Recovery, DR)戦略の概要
AWSでは、ビジネス要件に応じた災害復旧(DR)戦略を構築するためのさまざまなサービスとアプローチが提供されています。以下では、コスト、復旧時間目標(RTO)、および復旧時点目標(RPO)に基づく主要なDR戦略を解説します。
1. バックアップとリストア (Backup and Restore)
- 概要: 必要なデータを定期的にバックアップし、障害発生時に復元する。
- 特徴:
- コスト: 非常に低い(バックアップストレージのみ)
- RTO: 数時間~1日
- RPO: バックアップ間隔次第(例: 8時間ごと)
- 使用するAWSサービス:
- Amazon S3(バックアップストレージ)
- AWS Backup(自動化されたバックアップ管理)
2. パイロットライト (Pilot Light)
- 概要: 必要最低限のリソースを稼働状態にしておき、障害時に迅速にスケールアップする。
- 特徴:
- コスト: 低~中(最小限のリソースのみ稼働)
- RTO: 数時間
- RPO: 最小限(レプリカを活用)
- 使用するAWSサービス:
- Amazon RDS(クロスリージョンリードレプリカ)
- AWS Auto Scaling(リソーススケールアップ)
3. ウォームスタンバイ (Warm Standby)
- 概要: セカンダリリージョンで縮小された形で本番環境を稼働させ、障害時に完全稼働に切り替える。
- 特徴:
- コスト: 中(縮小された環境の維持が必要)
- RTO: 数分~数時間
- RPO: レプリケーション頻度に依存(ほぼゼロも可能)
- 使用するAWSサービス:
- Amazon EC2(縮小構成での常時稼働)
- Elastic Load Balancer(DNS切り替え)
4. マルチサイト (Multi-Site Active-Active)
- 概要: 複数のリージョンで本番環境を常時稼働させる。
- 特徴:
- コスト: 高(複数のフル環境を維持)
- RTO: ほぼゼロ
- RPO: ほぼゼロ(同期レプリケーション)
- 使用するAWSサービス:
- Amazon Route 53(トラフィック分散)
- AWS Global Accelerator(低レイテンシ接続)
効果的な災害復旧の構築に必要な要素
- データの保護
- Amazon S3を利用したデータバックアップとクロスリージョンレプリケーション。
- Amazon RDSのスナップショットとリードレプリカ。
- リソースのプロビジョニング
- AWS CloudFormationを利用してリソースを自動デプロイ。
- Auto ScalingやAWS Lambdaを活用して障害時に迅速にリソースをスケールアップ。
- DNS管理
- Amazon Route 53を使用したフェイルオーバーとトラフィックルーティング。
具体例: パイロットライト戦略の構築
- 構成:
- プライマリリージョンでフル稼働のアプリケーション。
- セカンダリリージョンで最小限のリソース(例: リードレプリカ、スケールダウンしたインスタンス)。
- 障害発生時の手順:
- リードレプリカをプライマリに昇格。
- Auto Scalingポリシーでインスタンスを増加。
- DNS(Route 53)をセカンダリリージョンに切り替え。
まとめ
AWSの災害復旧戦略は、コストと復旧速度のバランスを考慮して選択することが重要です。
上記のような戦略を理解し、適切なAWSサービスを組み合わせることで、効率的かつ信頼性の高いDR環境を構築できます。
実践
略
一問道場
Question #333
ある企業が、コミュニティフォーラムサイトをホストしています。このサイトは、**Application Load Balancer(ALB)**と、Amazon ECS クラスターでホストされている Docker アプリケーションを使用しています。
サイトデータは Amazon RDS for MySQL に保存されており、コンテナイメージは Amazon ECR に保存されています。同社は、災害復旧(DR)に関する SLA を顧客に提供する必要があり、以下の要件を満たす必要があります:
- RTO(復旧時間目標):24時間以内
- RPO(復旧時点目標):8時間以内
次のうち、要件を満たす最もコスト効率の高い方法はどれですか?
A.
AWS CloudFormation を使用して、2つのリージョンに同一の ALB、EC2、ECS、および RDS リソースをデプロイします。
8時間ごとに RDS スナップショットをスケジュールします。RDS のマルチリージョンレプリケーションを使用して、セカンダリリージョンにデータベースを更新します。障害が発生した場合、最新のスナップショットから復元し、Amazon Route 53 の DNS フェイルオーバーポリシーを使用して顧客をセカンダリリージョンの ALB に自動的にリダイレクトします。
B.
Docker イメージを 2つのリージョンの ECR に保存します。8時間ごとに RDS スナップショットをスケジュールし、スナップショットをセカンダリリージョンにコピーします。障害が発生した場合、AWS CloudFormation を使用してセカンダリリージョンに ALB、EC2、ECS、および RDS リソースをデプロイし、最新のスナップショットから復元し、DNS レコードをセカンダリリージョンの ALB に更新します。
C.
AWS CloudFormation を使用して、セカンダリリージョンに同一の ALB、EC2、ECS、および RDS リソースをデプロイします。RDS MySQL のバックアップを毎時 Amazon S3 に保存し、クロスリージョンレプリケーションを使用してデータをセカンダリリージョンのバケットにレプリケートします。障害が発生した場合、最新の Docker イメージをセカンダリリージョンの Amazon ECR にインポートし、EC2 インスタンスにデプロイし、最新の MySQL バックアップを復元して、DNS レコードをセカンダリリージョンの ALB に更新します。
D.
セカンダリリージョンに パイロットライト環境 をデプロイします。この環境には、ALB と最小リソースの EC2 デプロイメント(スケーリングポリシー付き AWS Auto Scaling グループでノード数とインスタンスサイズを増やす設定)を含みます。RDS データのクロスリージョンリードレプリカを作成します。障害が発生した場合、レプリカをプライマリに昇格し、DNS レコードをセカンダリリージョンの ALB に更新します。
解説
正解が B とのことなので、その理由を分析します。
B. 解説
- 内容:
- Dockerイメージ: 2つのリージョンのECRに保存。
- RDSスナップショット: 8時間ごとに取得し、セカンダリリージョンにコピー。
- 障害発生時:
- CloudFormationでリソース(ALB、ECS、RDSなど)をセカンダリリージョンにデプロイ。
- RDSスナップショットを復元。
- DNSを更新してALBにルーティング。
このアプローチの強み
- コスト効率:
- セカンダリリージョンでは平常時にリソースを稼働させないため、運用コストを抑えられる。
- パイロットライトのように最小限のリソースを維持する必要がなく、完全に停止状態。
- RPO(8時間以内):
- 8時間ごとのRDSスナップショットとそのクロスリージョンコピーにより、データ損失を8時間以内に抑える。
- RTO(24時間以内):
- CloudFormationを使用することで、障害時に必要なリソースを迅速にプロビジョニング可能。
- 作業が自動化されており、運用負荷も低い。
D.(パイロットライト)との比較
比較項目 | B(正解) | D(パイロットライト) |
コスト | セカンダリでリソース未稼働 → コスト効率が非常に高い | 最小リソースを常時稼働 → Bよりコストが高い |
RTO(復旧時間) | リソース構築に時間がかかる可能性(CloudFormation依存) | 既にパイロット環境が稼働 → 短時間で切り替え可能 |
RPO(データ損失) | スナップショットコピーに依存(最大8時間の損失可能性) | クロスリージョンリードレプリカ → データ損失が少ない |
- D のパイロットライトは復旧速度が速いものの、コスト面で B より劣る点があるため、運用コストを重視する場合には不利となります。
なぜBが正解か
- 問題文において「最も費用対効果の高い方法(MOST cost-effective)」と指定されている。
- B はセカンダリリージョンでリソースを停止状態に保つため、コスト削減が可能。
- RTO(24時間)とRPO(8時間)の要件を満たしている。
補足
選択肢 D も有効なDR戦略ですが、RTO/RPOの要件が緩やかな場合、より低コストな B のアプローチが適しています。
334-AWS SAP AWS 「理論・実践・一問道場」AWS Control Tower
理論
AWSマルチアカウント環境と運用効率化に関する知識
1. AWS Control Tower
AWS Control Towerは、複数のAWSアカウントを管理するためのベストプラクティスを自動化するサービスです。以下が特徴です:
- 自動セットアップ:複数アカウントを簡単に作成し、管理のための基本構造(OUやSCPなど)を提供。
- ガードレール(Guardrails):セキュリティやコンプライアンスを強化するためのポリシーを自動的に適用。
- 一貫性と柔軟性:異なる規制要件に対応可能なOU(組織単位)を設定可能。
ユースケース:
- 初期設定が簡単で、管理の一貫性が求められる環境に最適。
2. AWS Organizations
AWS Organizationsは、マルチアカウント環境を管理するための基本サービスです。
- OU(組織単位):アカウントをグループ化し、ポリシーを適用可能。
- SCP(サービスコントロールポリシー):アカウントのアクセス権限を制御するためのポリシー。
注意点:
Control TowerなしでOrganizationsを使う場合、設定の自動化がなく運用負担が増える可能性があります。
3. AWS IAM Identity Center(AWS Single Sign-On)
- AWS IAM Identity Centerは、ユーザーとAWSアカウント間のアクセス管理を簡略化します。
- Active Directory(AD FS)との統合が可能で、オンプレミス環境とシームレスに接続できます。
- SSOを用いることで、複数アカウントに対する一貫したアクセス管理が実現します。
4. AWS Config
AWS Configは、リソースの設定変更を追跡し、規制要件に準拠しているかを確認するサービスです。
- コンフォーマンスパック:標準化された設定ルールのセットを適用可能。
- マルチアカウント環境全体での設定管理に役立つ。
5. ガードレールとセキュリティ管理
- AWS Control Towerのガードレールを活用することで、セキュリティ違反を未然に防ぐ。
- SCPを活用して、アカウントごとのアクセス制御を一元管理。
ベストプラクティス
- AWS Control Towerを活用する
- 初期構築を効率化し、セキュリティとコンプライアンスを自動的に適用する。
- AWS IAM Identity Centerを使用
- ユーザーアクセス管理を簡略化し、AD FSとの統合を実現。
- AWS Configで設定を監視
- マルチアカウント環境全体の設定状況をリアルタイムで追跡。
関連知識の適用例
企業がコンプライアンス要件を満たす必要がある場合、AWS Control Towerを使ってガードレールを設定し、AWS ConfigとIAM Identity Centerでセキュリティとアクセス管理を効率化することが最適なソリューションとなります。
実践
略
一問道場
質問 #334
ある企業がインフラストラクチャをAWSクラウドに移行しています。
この企業は、プロジェクトごとに異なるさまざまな規制基準に準拠する必要があります。企業はマルチアカウント環境を必要としています。
ソリューションアーキテクトは、基本となるインフラストラクチャを準備する必要があります。このソリューションは、管理とセキュリティの一貫した基盤を提供しつつ、各AWSアカウント内で異なるコンプライアンス要件に対応できる柔軟性を持たせる必要があります。また、このソリューションは、既存のオンプレミスのActive Directory Federation Services(AD FS)サーバーと統合する必要があります。
どのソリューションが最小限の運用オーバーヘッドでこれらの要件を満たしますか?
オプション:
A:
- AWS Organizationsで組織を作成する。
- すべてのアカウントに対して最小権限アクセス用の単一のサービスコントロールポリシー(SCP)を作成する。
- すべてのアカウントを1つの組織単位(OU)に配置する。
- オンプレミスのAD FSサーバーとのフェデレーション用にIAMアイデンティティプロバイダーを構成する。
- 中央ログ記録アカウントを構成し、ログ生成サービスがログイベントを中央アカウントに送信する定義済みプロセスを設定する。
- 中央アカウントでAWS Configを有効化し、すべてのアカウントに対してコンフォーマンスパックを設定する。
B:
- AWS Organizationsで組織を作成する。
- AWS Control Towerを組織で有効化する。
- SCP(ガードレール)として含まれているコントロールを確認する。
- 追加が必要な領域についてAWS Configを確認する。
- 必要に応じてOUを追加する。
- AWS IAM Identity Center(AWS Single Sign-On)をオンプレミスのAD FSサーバーに接続する。
C:
- AWS Organizationsで組織を作成する。
- 最小権限アクセス用のSCPを作成する。
- OU構造を作成し、AWSアカウントをグループ化する。
- AWS IAM Identity Center(AWS Single Sign-On)をオンプレミスのAD FSサーバーに接続する。
- 中央ログ記録アカウントを構成し、ログ生成サービスがログイベントを中央アカウントに送信する定義済みプロセスを設定する。
- 中央アカウントでAWS Configを有効化し、アグリゲーターとコンフォーマンスパックを使用する。
D:
- AWS Organizationsで組織を作成する。
- AWS Control Towerを組織で有効化する。
- SCP(ガードレール)として含まれているコントロールを確認する。
- 追加が必要な領域についてAWS Configを確認する。
- オンプレミスのAD FSサーバーとのフェデレーション用にIAMアイデンティティプロバイダーを構成する。
解説
この問題のポイントは、規制要件に対応したマルチアカウント環境を構築するための最適な方法を選ぶことです。要件には、以下が含まれます:
- 管理とセキュリティの一貫性を提供すること。
- 各AWSアカウントで異なるコンプライアンス要件をサポートする柔軟性を持つこと。
- オンプレミスのAD FSサーバーとの統合。
- 運用オーバーヘッドを最小限に抑えること。
各オプションの分析
A.
- AWS OrganizationsとIAMアイデンティティプロバイダーを活用し、シンプルな構成を提案していますが、AWS Control Towerのような追加ツールがないため、管理の一貫性と柔軟性が不足しています。
- 特にOU(組織単位)を1つだけ使用しているため、複数のコンプライアンス要件に対応する柔軟性がありません。
B.(正解)
- AWS Control Towerを活用することで、複数アカウント管理のためのベストプラクティスを自動的に適用できます。
- 各アカウントのガードレール(SCP)やAWS Configで管理の一貫性を保ちつつ、柔軟なOU構造で異なる規制要件に対応可能です。
- AWS IAM Identity Center(AWS Single Sign-On)は、オンプレミスのAD FSと容易に統合できます。
- Control Towerによるセットアップは自動化されており、運用オーバーヘッドが最小限になります。
C.
- AWS Control Towerを使用せず、手動でOUやSCPを構成する方法を提案しています。
- 手動構成のため、AWS Control Towerのような一貫した管理や運用の自動化がなく、運用オーバーヘッドが増えます。
D.
- AWS Control Towerを使用している点は良いですが、IAMアイデンティティプロバイダー(IdP)を選んでおり、AWS IAM Identity Center(AWS Single Sign-On)ではないため、オンプレミスAD FSとの統合が複雑になる可能性があります。
選択肢Bが正解の理由
- AWS Control Towerを使用することで、管理とセキュリティのベストプラクティスを自動的に適用できます。
- SCPやAWS Configを含む管理ツールが初期設定から提供されるため、追加の運用負担が最小限です。
- AWS IAM Identity Center(AWS Single Sign-On)はAD FSとの統合が容易で、アクセス管理を効率化できます。
まとめ
AWS Control Towerを中心にしたソリューション(B)は、規制要件に対応する柔軟性を確保しながら、運用オーバーヘッドを最小化します。そのため、Bが最も適切な選択肢です。
335-AWS SAP AWS 「理論・実践・一問道場」Aurora Global Databases
理論
- Aurora Global Databases:
- 複数のリージョンにまたがってデータベースを複製でき、クロスリージョンで高可用性を提供します。これにより、地理的に分散したユーザーに対して低レイテンシーでデータベースを利用できます。
- Amazon S3 Cross-Region Replication:
- 静的コンテンツ(画像、動画、CSSなど)を複数のリージョンに自動的に複製する機能です。これにより、グローバルに分散したユーザーに対してコンテンツを効率よく配信できます。
- Amazon Route 53 (Latency-based Routing):
- ユーザーの地理的位置に基づいて最適なリージョンにトラフィックをルーティングし、レスポンス時間を短縮します。
- Amazon CloudFront:
- コンテンツ配信ネットワーク(CDN)で、静的コンテンツや動的コンテンツをグローバルに高速で配信します。Edge locationsを利用して、最寄の場所からコンテンツを提供できます。
- Auto Scaling:
- アプリケーションが需要に応じて自動的にスケーリングする仕組みです。トラフィックの急増に対応でき、リソースの無駄を減らすことができます。
これらのサービスを組み合わせて、グローバルなパフォーマンスの最適化と高可用性を実現することができます。
実践
略
一問道場
質問 #335
オンラインマガジンは今月、最新号を公開します。この号は初めて世界中に配信されるものです。マガジンの動的なウェブサイトは現在、ウェブ層の前にアプリケーションロードバランサー(ALB)を配置し、ウェブとアプリケーションサーバー用のAmazon EC2インスタンスのフリート、そしてAmazon Aurora MySQLを使用しています。ウェブサイトの一部には静的コンテンツが含まれ、ほぼすべてのトラフィックは読み取り専用です。
マガジンは新しい号の公開時にインターネットトラフィックの大幅な増加を予想しており、公開後1週間は最適なパフォーマンスを維持することが最優先事項です。
グローバルなオーディエンス向けにシステムの応答時間を削減するために、ソリューションアーキテクトが取るべき手順はどれか?(2つ選んでください。)
A. 論理的なクロスリージョンレプリケーションを使用して、Aurora MySQLデータベースを別のリージョンに複製する。ウェブサーバーをAmazon S3に置き換え、S3バケットをクロスリージョンレプリケーションモードで展開する。
B. ウェブおよびアプリケーション層がそれぞれAuto Scalingグループに含まれていることを確認する。AWS Direct Connect接続を導入する。ウェブおよびアプリケーション層を世界中のリージョンに展開する。
C. データベースをAmazon AuroraからAmazon RDS for MySQLに移行する。ウェブ、アプリケーション、データベースの3つのアプリケーション層がすべてプライベートサブネットに配置されていることを確認する。
D. Auroraグローバルデータベースを使用して物理的なクロスリージョンレプリケーションを行う。静的コンテンツやリソースに対してAmazon S3とクロスリージョンレプリケーションを使用する。ウェブおよびアプリケーション層を世界中のリージョンに展開する。
E. Amazon Route 53のレイテンシーベースルーティングとAmazon CloudFrontディストリビューションを導入する。ウェブおよびアプリケーション層がそれぞれAuto Scalingグループに含まれていることを確認する。
解説
この問題では、グローバルなオーディエンス向けにシステムの応答時間を削減するための最適な手順を選択することが求められています。特に、パフォーマンスの最適化と高可用性のために、複数のリージョンでの展開と静的コンテンツの効率的な配信が重要な要素となります。
選択肢の解説:
- A: 論理的クロスリージョンレプリケーションを使ってAurora MySQLデータベースを別のリージョンに複製し、静的コンテンツをS3バケットに配置してクロスリージョンレプリケーションを使う方法です。この方法は静的コンテンツの配信に有効ですが、ウェブサーバーをS3に置き換えるのは不適切です。S3は静的コンテンツの配信には適していますが、動的コンテンツ(例えば、アプリケーションサーバーで処理されるコンテンツ)には向いていません。
- B: Auto Scalingグループを使用し、ウェブおよびアプリケーション層を世界中のリージョンに展開し、AWS Direct Connectを導入する提案です。Auto Scalingは需要に応じてリソースをスケーリングできるため、高トラフィック時に重要ですが、Direct Connectはネットワークのパフォーマンス向上に役立つものの、今回のシナリオにはあまり必要ないかもしれません。これに加えて、リージョン展開を行うことで、グローバルなパフォーマンス向上を図れます。
- C: データベースをAmazon AuroraからRDS for MySQLに移行し、すべてのアプリケーション層をプライベートサブネットに配置する方法です。Auroraは高パフォーマンスと可用性を提供するため、AuroraからRDSに移行するのは逆効果です。また、ウェブ層やアプリケーション層がプライベートサブネットに配置されていると、外部アクセスが制限されるため、パフォーマンスの向上にはつながりません。
- D: Auroraグローバルデータベースを使用してクロスリージョンレプリケーションを行い、S3を使って静的コンテンツをクロスリージョンレプリケーションで配信する方法です。この方法は、Auroraのグローバルデータベースを使用することで、複数のリージョンにデータをリアルタイムで複製でき、静的コンテンツに対してS3とクロスリージョンレプリケーションを活用することで、グローバルなパフォーマンス向上が期待できます。
- E: Amazon Route 53を使用してレイテンシーベースルーティングを設定し、CloudFrontディストリビューションを導入する方法です。これにより、ユーザーが最寄りのリージョンからコンテンツを取得できるようになり、グローバルに分散したオーディエンスへのパフォーマンス向上を図れます。また、Auto Scalingを使うことで、需要に応じたスケーリングも可能です。
最適な選択肢:
- D と E が最も効果的です。DはAuroraのグローバルデータベースを使って、データベースの複製と高可用性を確保し、S3で静的コンテンツを効果的に配信できます。EはRoute 53とCloudFrontを活用することで、ユーザーに最適なリージョンからコンテンツを配信し、さらにパフォーマンスを向上させることができます。
まとめ:
- D: 高可用性を持つAuroraグローバルデータベースと静的コンテンツの効率的な配信。
- E: レイテンシーベースルーティングとCloudFrontによるグローバルパフォーマンス向上。
336-AWS SAP AWS 「理論・実践・一問道場」AWSサービスカタログ
理論
- EC2インスタンスのセービングプラン:
- 長期間使用するインスタンスに割引を適用できるプラン。特に24時間365日稼働が必要なアプリケーション(例:オンラインゲーム)に有効。
- 予約インスタンスも同様に、長期契約での割引を受けることができる。
- オンデマンドインスタンス:
- 需要に応じてインスタンスを起動・停止する方式。短期間の利用や予測が難しい負荷に適しているが、コストは高め。
- スポットインスタンス:
- AWSの未使用キャパシティを利用する安価なインスタンス。中断可能なワークロード(例:アナリティクス処理)に適しており、コストを大幅に削減できる。
- AWSサービスカタログ:
- 企業内で使用するリソースやサービスを一元管理し、コスト削減を目指すツール。特に割引プランを組み合わせる際に利用される。
これらの選択肢を適切に組み合わせることで、コスト最適化を実現できます。
実践
略
一問道場
質問 #336
オンラインゲームの会社は、AWS上でのワークロードのコストを最適化する必要があります。会社は、オンラインゲームアプリケーションとアナリティクスアプリケーションをホストするために専用のアカウントを使用しています。
オンラインゲームアプリケーションはAmazon EC2インスタンスでホストされており、常に可用性が必要です。EC2インスタンスは年間通じて稼働します。アナリティクスアプリケーションはAmazon S3に格納されたデータを使用しており、アナリティクスアプリケーションは中断して再開することができます。
どのソリューションが最もコスト効率的にこれらの要件を満たすでしょうか?
A. オンラインゲームアプリケーションインスタンスにEC2インスタンスのセービングプランを購入し、アナリティクスアプリケーションにはオンデマンドインスタンスを使用する。
B. オンラインゲームアプリケーションインスタンスにEC2インスタンスのセービングプランを購入し、アナリティクスアプリケーションにはスポットインスタンスを使用する。
C. オンデマンドインスタンスとスポットインスタンスの両方をオンラインゲームアプリケーションとアナリティクスアプリケーションに使用し、AWSサービスカタログで割引価格でサービスを提供する。
D. オンデマンドインスタンスをオンラインゲームアプリケーションに使用し、アナリティクスアプリケーションにはスポットインスタンスを使用し、AWSサービスカタログで割引価格でサービスを提供する。
解説
この問題では、コスト最適化の観点からオンラインゲームアプリケーションとアナリティクスアプリケーションのEC2インスタンスに関して、最もコスト効率的なソリューションを選ぶ必要があります。
A. オンラインゲームアプリケーションインスタンスにEC2インスタンスのセービングプランを購入し、アナリティクスアプリケーションにはオンデマンドインスタンスを使用する。
- オンラインゲームアプリケーション: 常に可用性が必要であるため、オンデマンドインスタンスか**予約インスタンス(またはセービングプラン)**が適しています。セービングプランを使用することで、長期利用の割引が得られ、コスト削減が可能です。
- アナリティクスアプリケーション: 中断可能であり、再開可能なため、コストを抑えるためにオンデマンドインスタンスを使用するのは適していません。
B. オンラインゲームアプリケーションインスタンスにEC2インスタンスのセービングプランを購入し、アナリティクスアプリケーションにはスポットインスタンスを使用する。
- オンラインゲームアプリケーション: セービングプランを使用して、長期間の稼働に対する割引を受けるのが最適です。
- アナリティクスアプリケーション: スポットインスタンスは、中断可能なワークロードに対して非常にコスト効率が良いオプションです。アナリティクスアプリケーションは中断されても問題ないため、スポットインスタンスの使用は非常に適しています。
C. オンデマンドインスタンスとスポットインスタンスの両方をオンラインゲームアプリケーションとアナリティクスアプリケーションに使用し、AWSサービスカタログで割引価格でサービスを提供する。
- オンラインゲームアプリケーション: 常に稼働しているため、オンデマンドインスタンスではなく、長期間の割引を提供するセービングプランを選択すべきです。
- アナリティクスアプリケーション: スポットインスタンスが適しているので、この組み合わせはコスト効率的ではありません。
D. オンデマンドインスタンスをオンラインゲームアプリケーションに使用し、アナリティクスアプリケーションにはスポットインスタンスを使用し、AWSサービスカタログで割引価格でサービスを提供する。
- オンラインゲームアプリケーション: 長期間利用するため、オンデマンドインスタンスではなく、コスト効率を最適化するためにセービングプランが最適です。
- アナリティクスアプリケーション: スポットインスタンスの使用は最適です。
したがって、最適解はBです。オンラインゲームアプリケーションにはセービングプランを使い、アナリティクスアプリケーションにはスポットインスタンスを使用することで、コストを最も効率的に最適化できます。
337-AWS SAP AWS 「理論・実践・一問道場」バックアップボールト
理論
バックアップボールトは、AWS Backupがバックアップデータを保管するためのストレージコンテナです。データを安全に保存するために、アクセス制限や暗号化が設定できます。ボールト内のバックアップは、バックアップポリシーに従って管理され、復元や削除の際にもセキュリティが確保されます。
1. AWS Backupの基本
AWS Backupは、AWSサービス全体でのデータのバックアップと復元を簡素化するためのサービスです。これを使って、EC2インスタンス、RDSデータベース、EFSファイルシステムなどのリソースのバックアップを効率的に実行できます。バックアップは暗号化され、保存される場所はユーザーが指定できます。
2. バックアップの保護とセキュリティ
バックアップのデータを安全に保つためには、以下のポイントに留意する必要があります:
- バックアップの不正アクセス防止
AWS Backupには、バックアップボールトへのアクセス制御が組み込まれており、IAMポリシーやサービスコントロールポリシー(SCP)を使ってアクセス制限を設けることができます。バックアップボールトにアクセスする権限は最小限にし、特権ユーザーの資格情報が侵害されてもバックアップが安全であるようにします。
- バックアップの不正変更防止
AWS Backup Vault Lockを使用することで、バックアップが保持される期間中にその内容が変更されないように設定できます。これにより、ランサムウェア攻撃などでバックアップが暗号化されるリスクを最小化できます。Vault Lockには「コンプライアンスモード」や「操作モード」があり、特にコンプライアンスモードは業界標準のデータ保持ポリシーに準拠しています。
- クロスアカウントバックアップ
クロスアカウントバックアップにより、バックアップデータを別のAWSアカウントに格納することで、攻撃者が本番アカウントにアクセスできてもバックアップは安全な場所に保管されます。バックアップボールトを異なるアカウントに分けて保管することが推奨されます。
3. SCP(サービスコントロールポリシー)
SCPはAWS Organizationsの一部で、アカウントの管理者が許可するアクションを制限することができます。SCPを使用して、バックアップボールトの変更や削除、アクセスを制限することにより、バックアップデータを保護します。これにより、特権ユーザーの資格情報が侵害された場合でも、バックアップのセキュリティを保つことができます。
4. データ保持ポリシーとライフサイクル管理
バックアップデータを長期間保存するためには、ライフサイクル管理を適切に設定することが重要です。AWS Backupではバックアップの頻度、保持期間、ライフサイクルポリシーを設定でき、データを指定した期間保存した後に自動的に削除することが可能です。また、バックアップをコールドストレージ(Amazon S3 Glacierなど)に移動することでコストを削減できます。
5. S3オブジェクトロック
Amazon S3にはオブジェクトロックという機能があり、これを有効にすると、オブジェクトが削除されることなく一定期間保持されるようにできます。S3オブジェクトロックは、ランサムウェア攻撃を防ぐために有用です。バックアップデータをS3に格納し、オブジェクトロックを使ってその安全性を高めることができます。
6. AWS Backupのアラートと監査
AWS Backupは監査機能を提供しており、バックアップの成功/失敗、バックアップリストアの活動、バックアップボールトへのアクセスなどを記録できます。これにより、異常な活動が発生した場合にすぐに検出できるようになります。また、CloudWatchを使ってアラートを設定することも可能です。
結論
バックアップを適切に管理し、ランサムウェアなどの攻撃からデータを保護するためには、AWS Backupの高度な機能(Vault Lock、クロスアカウントバックアップ、SCPなど)を駆使することが重要です。これにより、データの保護と復元力を強化し、企業のデータセキュリティ基準を満たすことができます。
実践
略
一問道場
解説
この問題は、バックアップのセキュリティと復元力を確保するためのベストプラクティスを問うものです。企業はランサムウェア攻撃に対抗するため、バックアップを保護し、特権ユーザーの資格情報侵害に耐性を持たせる必要があります。以下は、最も効果的な手順についての解説です。
正解となる手順
- A. AWS Backupボールトを指定された非本番アカウントでクロスアカウントバックアップを実施する。
- 理由: バックアップは非本番アカウントで管理し、本番アカウントから分離することで、万が一本番アカウントが攻撃されても、バックアップは安全な場所に保管されます。これにより、特権ユーザーの資格情報侵害からバックアップを保護できます。
- B. AWS Backupボールトの変更を制限するSCP(サービスコントロールポリシー)を追加する。
- 理由: サービスコントロールポリシー(SCP)を使用して、AWS Backupボールトの変更を制限することができます。これにより、不正なアクセスや変更からボールトを保護し、ランサムウェア攻撃によるデータ損失を防ぎます。
- C. AWS Backup Vault Lockをコンプライアンスモードで実装する。
- 理由: AWS Backup Vault Lockのコンプライアンスモードを使用すると、バックアップが一定の期間変更不可となり、データがランサムウェア攻撃によって暗号化されても、保護されたバックアップが変更されることはありません。このモードはデータ保持ポリシーの強化に役立ちます。
なぜ他の選択肢が適切でないか
- D. AWS Backupに割り当てられたIAMサービスロールに対して最小権限アクセスを実装する。
- 最小権限アクセスは重要ですが、この選択肢はバックアップの保護という観点で直接的な解決策にはなりません。バックアップの保護に関する要件としては、ロール設定だけでは不十分です。
- E. バックアップの頻度、ライフサイクル、および保持期間を設定し、常に1つのバックアップがコールドティアに存在するようにする。
- バックアップの頻度や保持期間を設定することは重要ですが、ランサムウェア攻撃に対する耐性を確保するためには、バックアップの保護方法がもっと具体的でなければなりません。コールドティアへの保持のみでは不十分です。
- F. AWS Backupを設定して、すべてのバックアップを指定された非本番アカウントのAmazon S3バケットに書き込む。S3バケットにはS3オブジェクトロックを有効にする。
- S3オブジェクトロックを有効にすることは有用ですが、AWS Backupのクロスアカウントバックアップに比べて管理が複雑になる可能性があります。非本番アカウントにバックアップを保持する方法としては、AWS Backupボールトの方がよりセキュアで管理が容易です。
結論
ランサムウェア攻撃に対抗するためには、バックアップが改ざんされないように保護する手段を講じる必要があります。正解となる選択肢は、AWS Backupボールトのセキュリティを強化し、非本番アカウントでバックアップを管理する方法です。
338-AWS SAP AWS 「理論・実践・一問道場」Kinesis Data Stream
理論
1. AWS CloudWatch Logs
CloudWatch Logsは、AWSの各サービスからのログデータを収集し、リアルタイムで監視や分析を行うためのサービスです。複数アカウントからのログを集約する際には、ロググループとサブスクリプションフィルターを使用して、ログを特定の宛先に転送することができます。
2. Amazon Kinesis
Kinesisは、リアルタイムで大量のデータを処理・転送するために使用されるサービスです。ログデータの集約において、Kinesisは非常に有効です。特に、ログの大量インジェストと、他のシステムへのストリーミングに適しています。
- Kinesis Data Streamを使用すると、ログデータを並列に処理・転送できます。
- Kinesis Firehoseは、データをS3やRedshift、ElasticSearchなどに簡単に転送できるオプションもあります。
3. AWS Lambda
Lambdaはサーバーレスでコードを実行するサービスで、イベント駆動型でスケーラブルにデータ処理を行います。ログデータの正規化やフィルタリング、他のサービスへの転送(例えばセキュリティツールへの送信)には非常に有用です。
- Lambdaを使うことで、ログデータをリアルタイムで処理し、最終的に適切な形式で外部システムに送ることができます。
4. セキュリティとアクセス制御
ログを他のシステムに転送する際、IAMロールと適切な権限設定が必要です。各アカウントからログを集める場合、信頼されたロールを使用して、ログデータの送信を許可する必要があります。
- IAMロールを設定することで、セキュリティを確保しながら、必要なデータだけを転送することができます。
5. スケーラビリティとパフォーマンス
AWSの各サービスはスケーラブルであり、大量のデータを扱う際にも高パフォーマンスを発揮します。ログデータは特にスパイクが予想される場合が多いので、Kinesisのように動的にスケールするサービスを使用すると、負荷分散や性能の低下を避けることができます。
これらのサービスと技術を活用することで、複数アカウントからのログを効率的に集約し、処理することが可能となります。
実践
略
一問道場
問題内容
ある企業が、複数のAWSアカウントからAmazon CloudWatchログを1つの中央ログアカウントに集約する必要があります。収集されたログは作成されたAWSリージョン内にとどまる必要があります。中央ログアカウントは、ログを処理して標準的な出力形式に変換し、その後、セキュリティツールに出力ログをストリーミングしてさらに処理します。
ソリューションアーキテクトは、大量のログデータを取り込むためのソリューションを設計する必要があります。通常の営業時間外はログが少なく、通常の営業時間中に多くのログが発生します。ログソリューションは予想される負荷に合わせてスケールする必要があります。ソリューションアーキテクトは、AWS Control Tower設計を使用して複数アカウントのログ処理を行うことを決定しました。
要件を満たすためにソリューションアーキテクトが取るべき手順の組み合わせはどれですか?
(3つ選んでください)
選択肢
- A. 中央ログアカウントに、Amazon Kinesisデータストリームの宛先を作成する。
- B. 中央ログアカウントに、Amazon Simple Queue Service(Amazon SQS)キューの宛先を作成する。
- C. Amazon CloudWatch LogsがKinesisデータストリームにデータを追加する権限を付与するIAMロールを作成する。
- 信頼ポリシーを指定し、そのIAMロールに信頼ポリシーを設定する。
- 各メンバーアカウントで、各ロググループに対してKinesisデータストリームにデータを送信するサブスクリプションフィルタを作成する。
- D. Amazon CloudWatch LogsがAmazon Simple Queue Service(Amazon SQS)キューにデータを追加する権限を付与するIAMロールを作成する。
- 信頼ポリシーを指定し、そのIAMロールに信頼ポリシーを設定する。
- 各メンバーアカウントで、すべてのロググループに対してSQSキューにデータを送信する単一のサブスクリプションフィルタを作成する。
- E. 中央ログアカウントにAWS Lambda関数を作成し、Lambda関数を使ってログを標準形式に正規化し、セキュリティツールに書き込むようにプログラムする。
- F. メンバーアカウントにAWS Lambda関数を作成し、Lambda関数を使ってログを標準形式に正規化し、セキュリティツールに書き込むようにプログラムする。
解説
この問題は、AWS環境で複数のアカウントからのCloudWatchログを中央集約して処理し、スケーラブルで効率的な方法でセキュリティツールに流すソリューションを求めています。以下に各選択肢の解説を行います。
選択肢A:
中央ログアカウントに、Amazon Kinesisデータストリームの宛先を作成する。
Kinesisデータストリームは、リアルタイムでログデータを処理するために使用されるサービスです。大量のログデータを効率的に取り込み、後続の処理に適した形式に変換できるため、ログのストリーミングや集約に役立ちます。ここでKinesisを使用するのは適切です。
選択肢B:
中央ログアカウントに、Amazon Simple Queue Service(Amazon SQS)キューの宛先を作成する。
SQSはメッセージキューサービスで、非同期的にメッセージを送受信するために使用されますが、大量のログデータを効率的に処理するには、Kinesisの方が適しています。SQSはログの集約には最適ではないため、この選択肢は最適とは言えません。
選択肢C:
Amazon CloudWatch LogsがKinesisデータストリームにデータを追加する権限を付与するIAMロールを作成する。
CloudWatch LogsからKinesisデータストリームにデータを送るには、適切な権限を持つIAMロールを作成する必要があります。これにより、各メンバーアカウントからログをKinesisデータストリームに送信できるようになります。必要な権限を確保するのは、システムのセキュリティとスムーズなデータ転送に重要です。
選択肢D:
Amazon CloudWatch LogsがAmazon SQSキューにデータを追加する権限を付与するIAMロールを作成する。
SQSはメッセージの取り扱いに特化しており、ログのストリーミングにはKinesisが適しているため、SQSにデータを送る方法はあまり効率的ではありません。この選択肢は、ログデータの集約にKinesisを使用するのが最適な状況では適切ではないです。
選択肢E:
中央ログアカウントにAWS Lambda関数を作成し、Lambda関数を使ってログを標準形式に正規化し、セキュリティツールに書き込むようにプログラムする。
Lambda関数を使用して、ログデータを標準形式に変換するのは非常に有効です。Lambdaはイベント駆動型でスケーラブルなため、大量のデータを効率的に処理でき、後続のセキュリティツールにデータを提供するのに適しています。
選択肢F:
メンバーアカウントにAWS Lambda関数を作成し、Lambda関数を使ってログを標準形式に正規化し、セキュリティツールに書き込むようにプログラムする。
Lambda関数をメンバーアカウントに作成してログを処理する方法も考えられますが、中央集約型のログ処理を行うためには中央アカウントでLambdaを使う方が効率的です。メンバーアカウントで個別に処理を行うと、管理が複雑になり、全体の効率が低下する可能性があります。
結論
要件に最も適した方法は、A, C, Eの組み合わせです。
- Aは、ログデータを集約するためにKinesisを使用することを提案しています。
- Cは、CloudWatchからKinesisにログデータを送るための適切な権限を設定する方法を示しています。
- Eは、中央アカウントでLambdaを使用してログを標準化し、セキュリティツールに送信する手順です。
この組み合わせで、スケーラブルで効率的なログ収集・処理を実現でき、要件に沿った最適なソリューションとなります。
339-AWS SAP AWS 「理論・実践・一問道場」SMS
理論
1. AWS Server Migration Service (AWS SMS):
- AWS SMSは、オンプレミスのVMware仮想マシン(VM)をAWSクラウドに移行するためのサービスです。移行中、サーバーをアクティブに維持でき、ダウンタイムを最小限に抑えながら仮想マシンをAWSに移行できます。
- 特徴:
- 継続的なレプリケーションにより、最新のデータをAWSに同期できます。
- インクリメンタルな移行が可能で、移行元のVMの停止時間を短縮します。
- AWSインフラに最適化されており、大規模な移行にも対応します。
2. VM Import/Export:
- VM Import/Exportは、仮想マシン(VM)のイメージをAWSにインポートするためのツールです。VMware、Hyper-V、Xenなどの仮想化プラットフォームからVMイメージをEC2インスタンスに変換します。
- 制限:
- サーバーをAWSに移行する際に、インポートのための追加作業とダウンタイムが発生することがあり、時間がかかる可能性があります。
- リアルタイムのデータ同期やインクリメンタルな移行には向いていません。
3. AWS Database Migration Service (AWS DMS):
- AWS DMSは、データベースの移行を支援するサービスで、オンプレミスのデータベースをAmazon RDSなどのAWSのデータベースサービスに移行できます。データの複製と同期を行い、最小限のダウンタイムで移行可能です。
- 利用例:
- データベースが稼働し続ける必要がある場合、DMSを使ってリアルタイムでデータをAWSに転送します。
- 既存のオンプレミスのデータベースをAmazon RDSやAmazon Auroraに移行する際に有効です。
4. AWS Snowball Edge:
- AWS Snowball Edgeは、大規模なデータ転送を支援するハードウェアデバイスで、インターネット接続が遅いまたはない場所でも利用できます。
- 用途:
- 大量のデータをAWSに物理的に移行する際に使用され、ネットワーク転送が非効率な場合に有効です。
- サーバーや仮想マシンの移行には直接的な関与は少なく、主にデータのバックアップやオフライン移行に使用されます。
このように、仮想マシンやデータベースの移行方法は、必要なスピード、ダウンタイム、データの同期方法に応じて選択することが重要です。
実践
略
一問道場
会社は、オンプレミスのデータセンターからAWSへのレガシーアプリケーションの移行を行っています。アプリケーションは、単一のアプリケーションサーバーとMicrosoft SQL Serverデータベースサーバーで構成されています。それぞれのサーバーは、複数の接続されたボリュームに500 TBのデータを消費するVMware仮想マシン(VM)上に展開されています。
会社は、最寄りのAWSリージョンへの10 GbpsのAWS Direct Connect接続を確立していますが、この接続は現在他のサービスには使用されていません。
最小限のダウンタイムでアプリケーションを移行するために、ソリューションアーキテクトはどの組み合わせの手順を実行すべきですか?(2つ選んでください)
A. AWS Server Migration Service (AWS SMS)のレプリケーションジョブを使用して、データベースサーバーVMをAWSに移行する。
B. VM Import/Exportを使用して、アプリケーションサーバーVMをインポートする。
C. VMイメージをAWS Snowball Edge Storage Optimizedデバイスにエクスポートする。
D. AWS Server Migration Service (AWS SMS)のレプリケーションジョブを使用して、アプリケーションサーバーVMをAWSに移行する。
E. AWS Database Migration Service (AWS DMS)のレプリケーションインスタンスを使用して、データベースをAmazon RDS DBインスタンスに移行する。
解説
この問題における正解は以下の2つです:
A. AWS Server Migration Service (AWS SMS)のレプリケーションジョブを使用して、データベースサーバーVMをAWSに移行する。
D. AWS Server Migration Service (AWS SMS)のレプリケーションジョブを使用して、アプリケーションサーバーVMをAWSに移行する。
解説:
- AとD は、AWS Server Migration Service (AWS SMS) を使用して、VMwareベースのアプリケーションサーバーとデータベースサーバーをAWSに移行する方法です。AWS SMSは、VMware仮想マシンをAWSに移行する際に最も効率的で信頼性の高い方法です。特に、ダウンタイムを最小限に抑えながら、既存のVMware VMをAWSインフラに移行できます。
- B は、VM Import/Exportを使用して仮想マシンをインポートする方法ですが、この方法はAWS SMSに比べてダウンタイムが長くなる可能性があり、複雑な移行シナリオには不向きです。
- C は、AWS Snowball Edgeを使用してVMイメージをエクスポートする方法ですが、通常は大規模なデータ転送に利用され、VMware VMの移行には適していません。
- E は、AWS Database Migration Service (AWS DMS) を使用してデータベースをAmazon RDSに移行する方法ですが、SQL Serverの移行には直接的な関与が少なく、このシナリオではSMSの方が適しています。
340-AWS SAP AWS 「理論・実践・一問道場」AWS Transit Gateway
理論
AWS Transit Gateway とネットワーク接続管理
AWS Transit Gatewayの概要
AWS Transit Gatewayは、複数のVPC(Virtual Private Cloud)やオンプレミスネットワークを接続するためのサービスです。VPC間やオンプレミスネットワークとの接続を効率的に管理するための中心的なポイントとして機能します。
主な利点
- スケーラビリティ: 多くのVPCやVPN接続をシンプルに管理でき、スケーラブルなネットワークアーキテクチャを実現します。
- 一元的な管理: 複数のVPCを1つのTransit Gatewayに接続することで、ネットワーク全体を簡単に管理でき、管理負担を軽減します。
- ルート制御: ルートテーブルを使用して、VPC間のトラフィックフローや通信を柔軟に制御できます。
AWS Transit Gatewayの設定手順
- アタッチメントの作成: VPCやVPNをTransit Gatewayにアタッチします。これにより、接続されるネットワーク間で通信が可能になります。
- ルートテーブルの設定: Transit Gatewayには複数のルートテーブルを作成できます。これにより、どのネットワークがどのVPCやVPNにアクセスするかを細かく制御できます。
- AWS Resource Access Manager (RAM): 複数のAWSアカウント間でリソースを共有するために、AWS RAMを使用します。これにより、他のAWSアカウントとTransit Gatewayを共有して利用できます。
VPC Peeringとの違い
- VPC Peering: VPC間を接続するための方法ですが、複数のVPCを接続する場合に、ピアリングの設定が煩雑になることがあります。特に多くのVPCを管理する場合には、接続先が増えるごとに設定が複雑になるため、管理が難しくなります。
- Transit Gateway: 複数のVPCを一度に接続できるため、大規模なネットワーク構成をより簡単に管理できます。
ベストプラクティス
- 複数のAWSアカウントやVPCを扱う場合は、Transit Gatewayを利用することで、トラフィックのルーティングやセキュリティポリシーの管理が一元化され、運用の効率化が図れます。
- ルートテーブルを適切に設定し、アクセス制御を明確にすることで、ネットワーク間のトラフィックをセキュアかつ効率的に制御できます。
まとめ
AWS Transit Gatewayは、複数のVPCやオンプレミスネットワークを接続し、ネットワーク管理を簡素化するための強力なツールです。特に複数アカウントや大規模なネットワークインフラを運用する場合、Transit Gatewayを利用することで、スケーラビリティや一元管理、柔軟なルート制御が可能になります。
実践
略
一問道場
問題 #340
トピック 1
ある企業は、オンプレミスにサーバーフリートを運用しており、AWS Organizations内でAmazon EC2インスタンスのフリートも運用しています。企業のAWSアカウントには数百のVPCがあります。企業は、AWSアカウントをオンプレミスのネットワークに接続したいと考えています。すでに1つのAWSアカウントでAWS Site-to-Site VPN接続が確立されています。企業は、どのVPCが他のVPCと通信できるかを制御したいと考えています。
最小限の運用作業でこの制御を実現するために、どの組み合わせの手順を実行すべきですか?(3つ選択)
A. AWSアカウントにトランジットゲートウェイを作成し、AWSリソースアクセスマネージャー(AWS RAM)を使用してトランジットゲートウェイをアカウント間で共有します。
B. すべてのVPCおよびVPNにアタッチメントを設定します。
C. トランジットゲートウェイのルートテーブルを設定し、VPCとVPNをルートテーブルに関連付けます。
D. VPC間でVPCピアリングを設定します。
E. VPCとVPNの間でアタッチメントを設定します。
F. VPCおよびVPNのルートテーブルを設定します。
解説
この問題では、AWS上で複数のVPC間で通信を制御し、最小限の運用作業でオンプレミスネットワークとの接続を管理する方法について問われています。
正解の選択肢
A. AWSアカウントにトランジットゲートウェイを作成し、AWSリソースアクセスマネージャー(AWS RAM)を使用してトランジットゲートウェイをアカウント間で共有します。
- トランジットゲートウェイは、複数のVPCやオンプレミスネットワークと接続するためのサービスです。AWS Resource Access Manager(RAM)を使用して、複数のAWSアカウントでトランジットゲートウェイを共有できるため、VPC間の通信を集中管理し、効率的に制御できます。
B. すべてのVPCおよびVPNにアタッチメントを設定します。
- トランジットゲートウェイにVPCとVPNをアタッチすることで、これらのネットワーク間で通信できるようになります。これにより、個々のVPC間での接続管理が簡素化されます。
C. トランジットゲートウェイのルートテーブルを設定し、VPCとVPNをルートテーブルに関連付けます。
- トランジットゲートウェイのルートテーブルを設定することで、どのVPCとVPNがどのように接続されるかを制御できます。これにより、通信の流れを詳細に管理できます。
なぜこれらが正解か?
- トランジットゲートウェイの使用により、複数のVPC間の通信を一元管理でき、**リソースアクセスマネージャー(AWS RAM)**で共有することで、複数アカウントにまたがる管理をシンプルにします。
- ルートテーブルでの設定により、VPC間やVPNとの通信経路を柔軟に制御できます。これにより、セキュリティやアクセス制御の観点で最小限の労力で通信を制御できます。
不正解の選択肢について
- D. VPC間でVPCピアリングを設定します。
- VPCピアリングは、異なるVPC間の通信を可能にしますが、複数アカウントにわたる場合や数百のVPC間で管理するには運用負荷が高く、トランジットゲートウェイほど効率的ではありません。
- E. VPCとVPNの間でアタッチメントを設定します。
- VPN接続の設定は必要ですが、単独でVPC間通信を制御するには不十分です。トランジットゲートウェイを使用することで、より効率的な管理が可能です。
- F. VPCおよびVPNのルートテーブルを設定します。
- ルートテーブルの設定は必須ですが、単独でこれだけでは複数アカウントやVPCの管理には不十分です。トランジットゲートウェイを使うことで、よりスケーラブルかつ管理しやすい構成になります。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/177d7ae8-88e2-804c-8628-e973b382299f
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts