type
status
date
slug
summary
tags
category
icon
password
361-AWS SAP AWS 「理論・実践・一問道場」PrivateLink
理論
AWS PrivateLinkの基本
AWS PrivateLinkは、異なるVPC間で安全かつプライベートに通信を行うためのサービスです。インターネットを介さず、プライベートIPアドレスを使用してサービスを接続できるため、セキュアな通信が可能です。
- PrivateLinkエンドポイントサービス：サービスを提供する側（ホスト側）が設定するリソースで、他のVPCからアクセス可能にします。
- PrivateLinkエンドポイント：クライアント側がPrivateLinkエンドポイントサービスに接続するために作成するリソースです。
これにより、異なるリージョン間でプライベートにサービスを利用することができます。
VPCピアリングの基本
VPCピアリングは、異なるVPC間で通信を可能にする設定で、1対1の接続を作ります。これにより、両VPC間で直接的な通信が可能となります。ただし、VPCピアリングは、リージョンを越えた接続にも使用できます。
- VPCピアリングは、インターネットゲートウェイを経由せずに、プライベートIPでの通信を実現できます。
- 複数のVPCが接続される場合、トランジットゲートウェイやPrivateLinkと組み合わせることも可能です。
エンドポイントサービスとNLB
- Network Load Balancer (NLB)：プライベートVPC間でのトラフィックを効率的に分散するための負荷分散サービスで、特にTCPトラフィックに適しています。
- PrivateLinkエンドポイントサービスは、通常、NLBを使って構成されます。これにより、異なるリージョン間でプライベートな接続を実現できます。
他の選択肢
- AWS RAM (Resource Access Manager)：他のアカウントやリージョンとリソースを共有するためのサービスですが、EC2インスタンスを共有する用途には使えません。
最適なアーキテクチャ
- 既存のインフラ（例えば、
eu-west-2のNLB）を利用して、新しいリージョン（us-east-1）の顧客にアクセスを提供する場合、PrivateLinkエンドポイントサービスを利用して、既存のリソースを効率よく再利用するのが最適です。これにより、新しいEC2インスタンスを追加せずに、サービスを拡張できます。
まとめ
- PrivateLink：異なるVPC間でセキュアかつプライベートに通信を行うために使用される。
- VPCピアリング：異なるリージョン間での直接通信を可能にするが、PrivateLinkとの併用が推奨される。
- NLB + PrivateLinkエンドポイントサービス：異なるリージョンでのリソースを安全かつプライベートに接続するために活用される。
実践
略
一問道場
あるSaaS（ソフトウェア・アズ・ア・サービス）企業が、AWSを使用してサービスをホストしており、このサービスはAWS PrivateLinkを使用して提供されています。このサービスは、Network Load Balancer（NLB）の背後で動作する3つのAmazon EC2インスタンスで構成されています。インスタンスは、複数のアベイラビリティゾーンにあるプライベートサブネット内に配置されています。すべての顧客はeu-west-2リージョンにいます。
しかし、この企業は新しい顧客をus-east-1リージョンで獲得しました。企業は新しいVPCと新しいサブネットをus-east-1リージョンに作成し、2つのリージョン間でVPCピアリングを確立しました。企業は新しい顧客にSaaSサービスへのアクセスを提供したいと考えていますが、us-east-1リージョンに新しいEC2リソースを即座に展開したくありません。
この要件を満たすソリューションはどれですか？
A. us-east-1にPrivateLinkエンドポイントサービスを設定し、eu-west-2にある既存のNLBを使用します。特定のAWSアカウントにSaaSサービスへの接続を許可します。
B. us-east-1にNLBを作成し、eu-west-2にあるSaaSサービスをホストしているインスタンスのIPアドレスを使用したIPターゲットグループを作成します。us-east-1にあるNLBを使用するPrivateLinkエンドポイントサービスを設定します。特定のAWSアカウントにSaaSサービスへの接続を許可します。
C. eu-west-2にあるEC2インスタンスの前にApplication Load Balancer（ALB）を作成し、us-east-1にNLBを作成します。us-east-1にあるNLBをALBターゲットグループに関連付け、eu-west-2にあるALBを使用します。us-east-1にあるNLBを使用するPrivateLinkエンドポイントサービスを設定します。特定のAWSアカウントにSaaSサービスへの接続を許可します。
D. AWS Resource Access Manager（AWS RAM）を使用して、eu-west-2にあるEC2インスタンスを共有します。us-east-1でNLBとインスタンスタスクターゲットグループを作成し、共有されたEC2インスタンスをターゲットに含めます。us-east-1にあるNLBを使用するPrivateLinkエンドポイントサービスを設定します。特定のAWSアカウントにSaaSサービスへの接続を許可します。
解説
この問題では、AWS PrivateLinkを使用して、新しい顧客（アメリカ東部の
us-east-1リージョン）に、既存のサービス（現在、ヨーロッパ西部のeu-west-2リージョンでホストされているSaaSサービス）へのアクセスを提供する方法を問われています。また、新しいEC2インスタンスをus-east-1リージョンにデプロイしないという条件もあります。問題の要点
- サービス構成：サービスは、複数のAvailability Zone（AZ）にまたがるプライベートサブネットのEC2インスタンス（NLBの背後）にホストされています。
- 顧客の要求：新しい顧客（
us-east-1リージョン）に、既存のサービスへのアクセスを提供したい。
- 条件：
- 新しいEC2インスタンスを
us-east-1に追加したくない。 PrivateLinkを利用する必要がある。
解説
AWS PrivateLinkは、AWSサービス（またはカスタマーサービス）を他のVPCに対して安全かつプライベートに提供するためのサービスです。プライベートIPを介して、VPC間でリソースをアクセスすることができ、インターネットを介さずに接続を実現します。
問題で示されている要件を達成するために最も効果的な方法は、既存のNLB（Network Load Balancer）を使用し、
us-east-1リージョンの顧客にアクセスを提供する方法です。具体的には、次のステップで解決できます：各選択肢の分析
A. us-east-1でPrivateLinkエンドポイントサービスを構成して、既存のNLB（eu-west-2）を使用する
- 解説：
- 既存のNLB（
eu-west-2リージョンにある）をus-east-1の新しい顧客に提供するために、PrivateLinkエンドポイントサービスを作成します。これにより、us-east-1の顧客はeu-west-2にあるNLBにアクセスできます。 - 新しいEC2インスタンスは不要で、既存のリソースを最大限活用できます。
- 非常に効率的で、操作負担も少なく、要件を満たします。
B. us-east-1で新しいNLBを作成し、eu-west-2のEC2インスタンスIPをターゲットとして指定する
- 解説：
- 新しいNLBを
us-east-1リージョンで作成し、そのターゲットとしてeu-west-2のインスタンスIPを指定する方法です。 - これも実現可能ですが、NLBを作成し、ターゲットを指定するという手間が増え、最適な選択肢とは言えません。
- 追加の設定と管理が必要です。
C. eu-west-2にALB（Application Load Balancer）を作成し、us-east-1にNLBを作成し、ALBターゲットグループに関連付ける
- 解説：
- ALB（
eu-west-2に配置）とNLB（us-east-1に配置）を組み合わせる方法ですが、複雑で管理が大変です。2つの負荷分散機能を組み合わせる必要があり、設定も複雑になります。 - この方法は、リソースの管理や設定が面倒になる可能性があり、最適とは言えません。
D. AWS RAMを使ってeu-west-2のEC2インスタンスを共有し、us-east-1にNLBを作成してインスタンスをターゲットにする
- 解説：
- AWS RAM（リソースアクセスマネージャー）は、特定のAWSリソース（例えばVPCサブネットやAurora DBなど）を他のアカウントやリージョンと共有するためのサービスです。しかし、EC2インスタンスの共有には使えません。したがって、この方法は不適切です。
最適な解答はAです：
us-east-1リージョンでPrivateLinkエンドポイントサービスを作成し、既存のeu-west-2リージョンのNLBを利用することで、新しいEC2インスタンスをデプロイすることなく、最小限の管理負担で顧客にサービスを提供できます。
この解決策は、要件を効率的に満たし、運用の簡素化を図ることができるため、最適な選択肢です。
362-AWS SAP AWS 「理論・実践・一問道場」S3 Storage Lens
理論
S3バケットの監視と暗号化メトリクスの追跡に関する基本知識
1. S3 Storage Lens
- 概要:
S3 Storage Lensは、Amazon S3のネイティブなストレージ分析ツールで、ストレージ使用量やパフォーマンスに関するメトリクスを提供します。
- 特徴:
- S3バケットのストレージ使用量やオブジェクト数、暗号化状況などを可視化。
- デフォルトダッシュボードで、追加設定なしに基本的な情報を確認可能。
- クロスリージョンのデータ追跡にはカスタムダッシュボードを設定可能。
- 適用例:
- 企業が複数リージョンにわたるS3バケットの暗号化状況を追跡する際に有効。
2. 暗号化の重要性
- 背景:
- サーバーサイド暗号化 (SSE):
- SSE-S3（S3管理キー）
- SSE-KMS（KMSキー）
- SSE-C（顧客提供キー）
- クライアントサイド暗号化: データをアップロードする前にローカルで暗号化。
データ暗号化はセキュリティとコンプライアンスの観点で非常に重要です。Amazon S3では以下の方法でデータを暗号化できます：
- 追跡の必要性:
- 内部監査や外部規制に対応するため、バケット内の暗号化状況を定期的にモニタリングする必要があります。
3. ダッシュボードとモニタリングのベストプラクティス
- 簡易設定:
- S3 Storage Lensのデフォルトダッシュボードを活用することで、迅速に監視を開始できます。
- 必要に応じて、カスタムダッシュボードを作成し、特定のメトリクスを表示可能。
- 高度な可視化:
- 必要に応じて、Amazon QuickSightを活用してカスタマイズしたレポートを作成し、他の部門と共有。
4. AWSサービスの比較
サービス | 主な用途 | メリット | デメリット |
S3 Storage Lens | ストレージメトリクスの可視化 | 簡単な設定で利用可能。追加の管理が不要。 | カスタム要件に対応するには制限がある場合がある。 |
Amazon QuickSight | データの可視化、レポート作成 | カスタマイズ可能なダッシュボードを作成可能。 | 構成が必要で、学習コストが発生する。 |
AWS Lambda + Athena | カスタムデータ処理、分析 | 高度なデータ処理が可能。 | メンテナンスが必要で複雑性が増す。 |
5. この知識の適用例
- 社内コンプライアンス: 定期的に暗号化メトリクスをモニタリングし、ダッシュボードを通じて管理者に報告。
- データセキュリティ: 暗号化が適用されていないオブジェクトを迅速に検出し、修正。
- 監査対応: S3 Storage Lensを活用して、外部監査のための証拠を即時提供可能。
S3 Storage Lensを活用することで、手間を最小限に抑えつつ効果的なモニタリングを実現できます。
実践
略
一問道場
質問 #362
ある企業が、2つのAWSリージョンにまたがる増加中のAmazon S3バケットを監視する必要があります。また、S3内のオブジェクトが暗号化されている割合を追跡し、その情報をコンプライアンスチーム向けのダッシュボードに表示したいと考えています。
この要件を最小限の運用負担で満たすには、どのソリューションが適していますか？
選択肢：
A. 各リージョンに新しいS3 Storage Lensダッシュボードを作成し、バケットと暗号化メトリクスを追跡します。両方のリージョンのデータをAmazon QuickSightで1つのダッシュボードにまとめて、コンプライアンスチームに提供します。
B. 各リージョンにAWS Lambda関数をデプロイし、バケット数とオブジェクトの暗号化状況をリスト化します。このデータをAmazon S3に保存し、Amazon Athenaクエリで分析します。Amazon QuickSightのカスタムダッシュボードで結果を表示し、コンプライアンスチームに提供します。
C. S3 Storage Lensのデフォルトダッシュボードを使用して、バケットと暗号化メトリクスを追跡します。コンプライアンスチームにS3コンソール内でダッシュボードへ直接アクセスできるようにします。
D. Amazon EventBridgeルールを設定して、S3オブジェクト作成に関するAWS CloudTrailイベントを検出します。このルールを使ってAWS Lambda関数を呼び出し、暗号化メトリクスをAmazon DynamoDBに記録します。そのデータをAmazon QuickSightのダッシュボードで表示し、コンプライアンスチームに提供します。
解説
この問題では、最小限の運用負担でS3バケットの監視および暗号化メトリクスの可視化を実現する方法を選択します。各選択肢を詳しく解説します。
選択肢A:
説明:
各リージョンにS3 Storage Lensダッシュボードを作成し、データを集約してQuickSightに表示します。
評価:
- S3 Storage LensはネイティブなS3管理ツールで、バケットや暗号化のメトリクスを追跡可能。
- ただし、QuickSightでダッシュボードを統合するための設定が必要で、追加の運用負担が発生します。
適合度: 中程度
QuickSightの設定が必要なため「最小限の運用負担」とは言えません。
選択肢B:
説明:
Lambda関数で暗号化状況を取得し、AthenaクエリとQuickSightでデータを可視化します。
評価:
- Lambda関数をデプロイする必要があり、メンテナンス負担が増加します。
- データ収集、Athena設定、QuickSightのダッシュボード作成など、多くのステップが必要です。
適合度: 低い
運用負担が大きく、シンプルな解決策ではありません。
選択肢C:（正解）
説明:
S3 Storage Lensのデフォルトダッシュボードを使用し、コンプライアンスチームに直接提供します。
評価:
- Storage LensはAWSが提供するネイティブなダッシュボードで、暗号化メトリクスをすぐに確認可能。
- 追加設定や構築がほぼ不要で、コンプライアンスチームが直接アクセスできるため、運用負担が最小限です。
適合度: 高い
設定が簡単で、要件をすべて満たします。
選択肢D:
説明:
EventBridgeでS3イベントを検出し、Lambda関数でDynamoDBに記録。QuickSightで表示します。
評価:
- EventBridgeやDynamoDB、QuickSightを組み合わせる構成で、運用負担が非常に大きいです。
- システム全体の複雑性が増加し、「最小限の運用負担」には適しません。
適合度: 低い
必要以上に複雑で、この要件にはオーバースペックです。
正解: C
理由:
- S3 Storage Lensのデフォルトダッシュボードは、AWSが提供する既存の機能を活用するため、追加構築が不要です。
- バケットや暗号化メトリクスをすぐに確認可能で、運用負担が最小限です。
- コンプライアンスチームに直接アクセス権を与えるだけで要件を満たします。
結論: 運用負担の観点から最も効率的な解決策です。
363-AWS SAP AWS 「理論・実践・一問道場」ブルー/グリーンデプロイメント
理論
CI/CDにおけるブルー/グリーンデプロイメントの概要と利点
1. ブルー/グリーンデプロイメントとは？
ブルー/グリーンデプロイメントは、現在稼働中の環境（ブルー）と新しいバージョンの環境（グリーン）を並行して用意し、トラフィックを段階的に切り替える手法です。以下の特徴があります。
- リスク軽減: 新しいバージョンに問題があれば、旧バージョン（ブルー）に迅速に切り戻せます。
- ダウンタイムの最小化: ユーザーへの影響をほぼゼロにできます。
- 段階的移行: トラフィックを部分的に切り替えることで、新しい環境を安全にテストできます。
2. 利用するAWSサービス
- AWS CodeDeploy:
- ブルー/グリーンデプロイメントをサポート。
- ロールバック機能を備え、エラー発生時に旧バージョンに切り戻しが可能。
- AWS CodePipeline:
- CI/CDパイプライン全体を自動化。
- ソースコード（GitHubなど）からビルド、テスト、デプロイまでを統合的に管理。
- Application Load Balancer (ALB):
- トラフィックを新旧環境に柔軟に振り分け可能。
3. メリットと注意点
- メリット:
- アップデート中のユーザー影響を抑制。
- 問題発生時にすぐに旧バージョンに戻せる。
- 本番環境と同じ設定で新しいバージョンをテスト可能。
- 注意点:
- 新しい環境のリソース（EC2インスタンスやコンテナ）が追加で必要。
- コストが一時的に増加する可能性がある。
4. 適用例
- ウェブアプリケーションのアップデート:
- トラフィックの一部を新しいバージョンにルーティングし、安定性を確認。
- 迅速なセキュリティパッチ適用:
- 新しい環境でパッチを適用後、すぐに本番トラフィックを移行。
- 段階的リリース:
- 全ユーザーにリリースする前に、少数のユーザーで新機能を試験運用。
この手法は、高可用性を求めるサービスや継続的なデリバリーが求められる環境で特に有効です。
AWS OpsWorks とは？
AWS OpsWorks は、サーバー構成管理とアプリケーションデプロイの自動化を提供するサービスです。Chef や Puppet を利用して、サーバー設定をコードで管理し、一貫性のある環境を構築できます。
主な特徴
- 構成管理: Chef/Puppet でサーバーを自動設定。
- アプリケーションデプロイ: サーバーに自動的にアプリをデプロイ。
- 動的スケーリング: トラフィックに応じて EC2 インスタンスを自動スケール。
- クロスプラットフォーム: Linux/Windows サポート。
ユースケース
- 一貫性のある環境構築と設定管理。
- アクセス量に応じたインフラの自動スケーリング。
- 複数環境（開発/本番）への簡単なデプロイ。
メリット
- 柔軟な構成管理（Chef/Puppet 対応）。
- アプリケーションとインフラの一元管理。
他サービスとの違い
特徴 | AWS OpsWorks | AWS CodeDeploy |
用途 | 構成管理＋デプロイ | デプロイのみ |
構成管理ツール | Chef/Puppet 対応 | なし |
OpsWorks は構成管理が必要なケースに最適ですが、シンプルなデプロイには CodeDeploy のほうが適しています。
実践
略
一問道場
Question #363
ある企業のCISO（最高情報セキュリティ責任者）が、現在のCI/CD（継続的インテグレーション/継続的デプロイメント）プロセスを再設計するようソリューションアーキテクトに依頼しました。
目的:
- 脆弱性が発見された場合、アプリケーションのパッチデプロイメントを可能な限り迅速に行う。
- ダウンタイムを最小限に抑える。
- エラーが発生した場合には、迅速にロールバックできる。
現在の状況:
- ウェブアプリケーションは、Application Load Balancerの背後に配置されたAmazon EC2インスタンス群でホストされている。
- アプリケーションのソースコードはGitHubにホストされている。
- AWS CodeBuildプロジェクトを使用してアプリケーションをビルドしている。
- AWS CodePipelineを使用してGitHubのコミットからビルドをトリガーし、既存のCodeBuildプロジェクトを利用する予定。
要件をすべて満たすCI/CD構成はどれか？
選択肢:
A.
CodePipelineにデプロイステージを設定し、AWS CodeDeployを使用したインプレースデプロイメントを構成する。
新しくデプロイされたコードを監視し、問題があれば別のコード更新をプッシュする。
B.
CodePipelineにデプロイステージを設定し、AWS CodeDeployを使用したブルー/グリーンデプロイメントを構成する。
新しくデプロイされたコードを監視し、問題があればCodeDeployを使用して手動でロールバックをトリガーする。
C.
CodePipelineにデプロイステージを設定し、AWS CloudFormationを使用してテストと本番スタック用のパイプラインを作成する。
新しくデプロイされたコードを監視し、問題があれば別のコード更新をプッシュする。
D.
CodePipelineにデプロイステージを設定し、AWS OpsWorksとインプレースデプロイメントを使用する。
新しくデプロイされたコードを監視し、問題があれば別のコード更新をプッシュする。
解説
この問題では、CI/CDパイプラインの構成で、以下の要件を満たすことが求められています。
- 迅速なパッチデプロイメント: アプリケーションに脆弱性が発見された場合、できるだけ早くデプロイできること。
- ダウンタイムの最小化: アプリケーションをアップデートする際、ユーザーに影響を与えない。
- 迅速なロールバック: 問題が発生した場合、迅速に以前のバージョンに戻せること。
選択肢の分析
A. インプレースデプロイメントを使用したCodeDeploy
- メリット: 現在のインスタンスをその場で更新するため、リソース消費が少ない。
- デメリット: デプロイ中にサービスが停止するリスクがある（ダウンタイムが発生する可能性がある）。
- 結論: ダウンタイムを最小化する要件を満たさないため不適切。
B. ブルー/グリーンデプロイメントを使用したCodeDeploy
- メリット:
- 新しいコードを「ブルー」（現在稼働中の環境）から「グリーン」（新しい環境）に切り替える手法を使用する。
- ダウンタイムをほぼゼロに抑えることが可能。
- 問題が発生した場合、簡単にブルー環境に切り戻す（ロールバック）ことができる。
- 結論: ダウンタイムの最小化と迅速なロールバックの要件を満たすため、最適な解答。
C. AWS CloudFormationを使用したスタックデプロイ
- メリット: インフラ全体をコード化して管理できる。
- デメリット: アプリケーションのデプロイにおけるダウンタイムやロールバック手法が具体的に述べられていない。
- 結論: ダウンタイムやロールバックの要件が曖昧なため不適切。
D. AWS OpsWorksを使用したデプロイ
- メリット: アプリケーションの設定管理に適している。
- デメリット: OpsWorksは主にChefを使用した設定管理に特化しており、CI/CDパイプライン全体の効率的なデプロイには向いていない。
- 結論: CI/CDソリューションとして適切ではない。
正解
B. CodeDeployを使用したブルー/グリーンデプロイメント
理由
- ブルー/グリーンデプロイメントは、ダウンタイムを最小化しつつ、問題発生時に迅速なロールバックを可能にする。
- AWS CodeDeployは、GitHubやCodePipelineと連携でき、既存の環境を活かしながら要件を満たす理想的な手法である。
364-AWS SAP AWS 「理論・実践・一問道場」Tag Policies
理論
1. タグポリシー (Tag Policies)
AWS Organizationsにおけるタグポリシーは、リソースに対して特定のタグの適用を強制するために使用されます。タグポリシーを使用すると、リソースが必要なタグを持っているか、タグが正しく適用されているかを検証できます。例えば、タグキーやタグ値の整合性を保つことができ、管理の効率化を図れます。
- タグポリシーの適用範囲: タグポリシーは、AWS Organizationsの**アカウントや組織単位（OU）**に適用できます。ポリシーを組織の管理アカウントに適用することで、一貫したタグ管理を実現できます。
- タグの強制: リソースが特定のタグ（例：「BusinessUnit」）を持っていない場合、タグポリシーにより警告やエラーが発生します。これを基に手動で修正を行うか、他の仕組みで自動修正を加えます。
2. サービスコントロールポリシー (SCPs)
サービスコントロールポリシーは、AWS Organizations内のアカウントが実行できるサービスやアクションを制限するためのポリシーです。タグの付け忘れを防ぐために、SCPを使用してリソース作成時に必要なタグがなければアクションを拒否することもできます。
- 制限対象: SCPは組織内の全アカウントに対して適用できますが、タグの管理に関してはタグポリシーの方が専用の機能です。
- タグによる制限: SCPでタグの条件を設定し、リソース作成時に特定のタグ（例：「BusinessUnit」）が欠けている場合にその作成を拒否することができます。しかし、タグを強制するためにはSCPと組み合わせて、適切なタグポリシーを運用するのが効果的です。
3. タグの使用例と重要性
- コスト管理: タグはAWSリソースのコスト管理において非常に重要です。タグを使って各事業部門やプロジェクトごとにコストを分けて追跡することができます。
- リソース管理: タグを使うことで、リソースのグループ化やフィルタリングが可能になります。これにより、大規模なAWS環境においてもリソースの管理が容易になります。
まとめ
- タグポリシーを使って特定のタグの適用を強制することが、タグ管理の基本です。
- SCPは、タグ管理の補完的な役割を果たし、リソースの作成時に必要なタグを強制するための手段として使えますが、タグポリシーと併用することが推奨されます。
- タグ管理はコストやリソース管理を効率化し、AWS環境の運用において不可欠な要素です。
実践
略
一問道場
ある会社は、AWS Organizationsを使用して多くのAWSアカウントを管理しています。会社の異なる事業部門がAmazon EC2インスタンスでアプリケーションを実行しています。すべてのEC2インスタンスには「BusinessUnit」タグを付ける必要があり、これにより会社は各事業部門のコストを追跡できます。
最近の監査で、いくつかのインスタンスにこのタグが欠けていることが判明しました。会社は手動で不足しているタグをインスタンスに追加しました。
今後、このタグ付け要件を強制するためにソリューションアーキテクトは何をすべきでしょうか？
A. 組織でタグポリシーを有効にし、「BusinessUnit」タグのタグポリシーを作成します。タグキーの大文字小文字の整合性を無効にし、ec2:instanceリソースタイプにタグポリシーを実装し、組織のルートに適用します。
B. 組織でタグポリシーを有効にし、「BusinessUnit」タグのタグポリシーを作成します。タグキーの大文字小文字の整合性を有効にし、ec2:instanceリソースタイプにタグポリシーを実装し、組織の管理アカウントに適用します。
C. SCP（サービスコントロールポリシー）を作成し、それを組織のルートに適用します。次のステートメントをSCPに含めます：
D. SCP（サービスコントロールポリシー）を作成し、それを組織の管理アカウントに適用します。次のステートメントをSCPに含めます：
解説
この問題は、AWS環境において、EC2インスタンスに「BusinessUnit」タグを必ず設定することで、各事業部門のコストを追跡するために、将来的にタグの管理を自動化する方法を問うものです。
解説
タグポリシー（Tag Policies）とサービスコントロールポリシー（SCP） の使い方について理解する必要があります。
- タグポリシーは、特定のタグがリソースに正しく適用されることを強制するために使います。これにより、リソースに必要なタグが付けられていない場合に、エラーを発生させることができます。タグポリシーを設定すると、リソースを作成する際にタグが正しく付けられているかを自動的にチェックできます。
- *サービスコントロールポリシー（SCP）**は、AWS Organizations内のアカウントに適用されるポリシーで、特定のアクションやリソースの操作を制限することができます。これにより、例えば、タグが欠けているインスタンスの起動を禁止することができます。
各選択肢の解説
- A. タグポリシーを有効にして、タグキーの大文字小文字の整合性を無効にする
- タグポリシーは正しい選択ですが、タグキーの大文字小文字の整合性を無効にする理由は不明です。AWSでは、タグキーの大文字小文字の整合性を有効にしておくのが一般的です。このため、この選択肢は不適切です。
- B. タグポリシーを有効にして、大文字小文字の整合性を有効にする
- こちらは適切な選択肢です。タグポリシーを有効にし、
BusinessUnitタグの整合性をチェックすることで、タグが欠けているインスタンスを作成できなくなります。これにより、将来的に手動でタグを追加する必要がなくなります。
- C. SCPを作成して、タグがないインスタンスの作成を禁止
- SCPを使用してインスタンス作成時に「BusinessUnit」タグが付いていない場合、インスタンスを起動できないように制限する方法です。これは確実な方法ですが、SCPはインスタンス作成の「ブロック」を意味します。タグがないインスタンスの作成を防ぐために使える手段ではありますが、タグポリシーを利用した方が簡潔で管理が容易です。
- D. SCPを作成して、タグがないインスタンスの作成を禁止（管理アカウント）
- SCPを管理アカウントに適用してインスタンス作成を制限する方法です。しかし、タグの制御に関しては、ポリシーを管理アカウントに適用するよりも、組織全体に対して適用する方が理想的です。
結論
最も簡単で効率的な方法は B です。タグポリシーを使って「BusinessUnit」タグが設定されていないインスタンスの作成を防ぐことができ、これにより手動でタグを追加する手間を省くことができます。
365-AWS SAP AWS 「理論・実践・一問道場」エグレス専用インターネットゲートウェイ
理論
1. IPv6の導入
- IPv6は、IPv4のアドレス枯渇問題を解決するために設計された次世代のインターネットプロトコルです。IPv4アドレスは32ビットの長さですが、IPv6は128ビットで構成され、膨大な数のユニークIPアドレスを提供します。
- Amazon VPCにおけるIPv6の設定:
- VPCにIPv6アドレスを導入する際、Amazon提供のIPv6 CIDRブロックを使用するのが一般的です。これは、AWSが提供するIPv6アドレス空間をVPCに関連付ける方法です。
- カスタムIPv6 CIDRブロックも使用できますが、Amazon提供のブロックの方が簡便で自動的に設定される場合が多いです。
2. エグレス専用インターネットゲートウェイ（Egress-Only Internet Gateway）
- エグレス専用インターネットゲートウェイは、IPv6トラフィック専用で、インターネットへのアウトバウンド（送信）通信を許可するが、インターネットからのインバウンド（受信）通信はブロックする機能です。
- プライベートサブネットにあるEC2インスタンスがインターネットにアクセスできるようにする一方で、セキュリティ上の理由から外部からのアクセスを拒否するために有効です。
- NATゲートウェイはIPv4専用で、IPv6通信には対応していないため、IPv6対応のアウトバウンドトラフィックにはエグレス専用インターネットゲートウェイを使用する必要があります。
3. VPCルートテーブルの更新
- IPv6導入時には、VPC内のルートテーブルを適切に更新し、各サブネットに対して適切なルートを追加する必要があります。特にプライベートサブネットの場合、アウトバウンド通信（::/0）をエグレス専用インターネットゲートウェイにルーティングする設定が求められます。
- パブリックサブネットの場合は、インターネットゲートウェイへのルートを追加し、インターネットへのアクセスを許可します。
4. プライベートサブネットとパブリックサブネットの設計
- プライベートサブネット：インターネットから直接アクセスできないように設計されたサブネットで、通常はNATゲートウェイまたはエグレス専用インターネットゲートウェイを使用して外部との通信を行います。
- パブリックサブネット：インターネットから直接アクセス可能なサブネットで、インターネットゲートウェイを介して外部と通信します。
5. セキュリティとアクセス制御
- セキュリティグループやネットワークACL（アクセス制御リスト）を使用して、各サブネットにおけるインバウンドおよびアウトバウンドのトラフィックを制御できます。これにより、特定のIPアドレスやポートに対するアクセスを制限できます。
まとめ
- IPv6対応のインターネット接続: エグレス専用インターネットゲートウェイを使用することで、プライベートサブネットのEC2インスタンスがインターネットへ安全にアクセスできるようになります。
- VPC設計の最適化: プライベートおよびパブリックサブネットを適切に設計し、各サブネットに対して適切なルートとセキュリティ設定を行うことが、効率的かつ安全なネットワーク構成の鍵となります。
この知識を踏まえて、AWS上でのIPv6移行やネットワーク設計を行うことができます。
実践
略
一問道場
質問 #365
ある会社が、数千のAmazon EC2インスタンスで構成されたワークロードを実行しています。このワークロードは、複数のパブリックサブネットとプライベートサブネットを含むVPCで実行されています。パブリックサブネットにはインターネットゲートウェイへの0.0.0.0/0ルートがあり、プライベートサブネットにはNATゲートウェイへの0.0.0.0/0ルートがあります。
ソリューションアーキテクトは、EC2インスタンス全体をIPv6を使用するように移行する必要があります。プライベートサブネットにあるEC2インスタンスは、パブリックインターネットからアクセスできないようにする必要があります。
要件を満たすためにソリューションアーキテクトは何をすべきでしょうか？
A. 既存のVPCを更新し、VPCおよびすべてのサブネットにカスタムIPv6 CIDRブロックを関連付けます。すべてのVPCルートテーブルを更新し、::/0のルートをインターネットゲートウェイに追加します。
B. 既存のVPCを更新し、VPCおよびすべてのサブネットにAmazon提供のIPv6 CIDRブロックを関連付けます。すべてのプライベートサブネットのVPCルートテーブルを更新し、::/0のルートをNATゲートウェイに追加します。
C. 既存のVPCを更新し、VPCおよびすべてのサブネットにAmazon提供のIPv6 CIDRブロックを関連付けます。エグレス専用インターネットゲートウェイを作成します。すべてのプライベートサブネットのVPCルートテーブルを更新し、::/0のルートをエグレス専用インターネットゲートウェイに追加します。
D. 既存のVPCを更新し、VPCおよびすべてのサブネットにカスタムIPv6 CIDRブロックを関連付けます。新しいNATゲートウェイを作成し、IPv6サポートを有効にします。すべてのプライベートサブネットのVPCルートテーブルを更新し、::/0のルートをIPv6対応のNATゲートウェイに追加します。
解説
この問題は、既存のVPC内でIPv6を使用する方法に関するものです。特に、プライベートサブネットにあるEC2インスタンスがパブリックインターネットからアクセスできないようにしつつ、IPv6を有効にする方法を問うています。解説は以下の通りです。
要件：
- IPv6の導入: すべてのEC2インスタンスはIPv6を使用する必要があります。
- プライベートサブネットのインスタンスがインターネットからアクセスできない: プライベートサブネットにあるEC2インスタンスは、インターネットからアクセスできないようにする必要があります。
各選択肢の解説：
A. 既存のVPCを更新し、VPCおよびすべてのサブネットにカスタムIPv6 CIDRブロックを関連付け、すべてのVPCルートテーブルを更新し、::/0のルートをインターネットゲートウェイに追加する。
- 誤り: カスタムIPv6 CIDRブロックを使う場合、インターネットゲートウェイを介してすべてのIPv6トラフィックをインターネットにルーティングすることになります。しかし、プライベートサブネットのインスタンスはインターネットからアクセスできないようにする必要があるため、インターネットゲートウェイを使用するのは不適切です。
B. 既存のVPCを更新し、VPCおよびすべてのサブネットにAmazon提供のIPv6 CIDRブロックを関連付け、すべてのプライベートサブネットのVPCルートテーブルを更新し、::/0のルートをNATゲートウェイに追加する。
- 誤り: NATゲートウェイはIPv4トラフィックをインターネットにルーティングするためのものですが、IPv6トラフィックには対応していません。したがって、IPv6のトラフィックをNATゲートウェイにルーティングすることはできません。
C. 既存のVPCを更新し、VPCおよびすべてのサブネットにAmazon提供のIPv6 CIDRブロックを関連付け、エグレス専用インターネットゲートウェイを作成し、すべてのプライベートサブネットのVPCルートテーブルを更新し、::/0のルートをエグレス専用インターネットゲートウェイに追加する。
- 正解: エグレス専用インターネットゲートウェイは、IPv6トラフィックがインターネットへのアウトバウンド通信のみを行えるようにするもので、インターネットからのインバウンド通信を防ぎます。これにより、プライベートサブネット内のインスタンスはIPv6を使用してインターネットにアクセスできますが、インターネットからアクセスされることはありません。これが要件を満たします。
D. 既存のVPCを更新し、VPCおよびすべてのサブネットにカスタムIPv6 CIDRブロックを関連付け、新しいNATゲートウェイを作成し、IPv6サポートを有効にし、すべてのプライベートサブネットのVPCルートテーブルを更新し、::/0のルートをIPv6対応のNATゲートウェイに追加する。
- 誤り: 新しいNATゲートウェイを作成してIPv6をサポートすることはできますが、NATゲートウェイ自体がIPv6に対応していないため、IPv6のトラフィックをルーティングすることができません。NATゲートウェイはIPv4専用のサービスです。
結論：
最も適切な選択肢はCです。エグレス専用インターネットゲートウェイを使用して、プライベートサブネットのEC2インスタンスがIPv6を利用してインターネットへのアウトバウンド通信を行い、インターネットからのアクセスを防ぐことができます。
366-AWS SAP AWS 「理論・実践・一問道場」API GatewayのインターフェースVPCエンドポイント
理論
1. インターフェースVPCエンドポイント
- インターフェースVPCエンドポイントは、VPC内からAWSサービス（API Gatewayを含む）に対してプライベートな接続を提供します。これを利用することで、インターネットを経由せず、VPC内のインスタンスから直接API Gatewayへアクセスすることが可能になります。
- VPC内のリソースが、インターネットゲートウェイやNATゲートウェイを使わずに、AWSサービスにアクセスできるため、セキュリティを強化できます。
2. API GatewayのプライベートAPI
- API GatewayのプライベートAPIは、特定のVPCからしかアクセスできないAPIです。通常、API Gatewayはインターネット経由でアクセスされますが、プライベートAPIでは、VPC内からのアクセスに限定されます。
- プライベートAPIの設定には、VPCエンドポイントや、APIリソースポリシーの設定が重要です。
3. エンドポイントポリシー
- エンドポイントポリシーは、インターフェースVPCエンドポイントにアクセスする際に使用されるIAMポリシーです。このポリシーを使って、VPCエンドポイントからアクセス可能なAWSサービスや操作を制御します。
execute-api:Invokeなど、API Gatewayへのアクセスに必要なアクションを許可するポリシーを設定します。
4. プライベートDNS
- プライベートDNSを有効にすると、VPC内からDNS名を使用してAPI Gatewayにアクセスすることができます。これにより、インターネットを経由せず、VPC内のリソースから安全にAPIにアクセスできます。
- プライベートDNSを無効にすると、VPC内からDNS名でAPIにアクセスすることができなくなり、IPアドレスを使用して接続する必要が生じます。
5. APIリソースポリシー
- APIリソースポリシーは、API Gatewayで設定できるアクセス制御ポリシーで、どのVPCやIPアドレス、エンドポイントからAPIにアクセスできるかを制御します。VPCからのアクセスを許可するために、適切なリソースポリシーを設定することが必要です。
6. VPCリンクとALB/NLB
- VPCリンクは、API GatewayとVPC内のサービス（例えば、ALBやNLB）とのプライベート統合を可能にします。API Gatewayを介してVPC内のサービスにアクセスする際には、ALBやNLBを使う場合もありますが、通常、API GatewayへのアクセスはインターフェースVPCエンドポイントで行うことが推奨されます。
結論
この問題のように、VPC内からのAPI Gatewayへのプライベートアクセスを設定する際、インターフェースVPCエンドポイントの作成と、適切なAPIリソースポリシーの設定、プライベートDNSの有効化が重要です。この構成により、インターネットを経由せずにVPC内のインスタンスからAPI Gatewayへの安全なアクセスが実現できます。
実践
略
一問道場
問題 #366
ある会社がAmazon API Gatewayを使用して、機密データへのアクセスを提供するプライベートREST APIをデプロイしています。このAPIは、VPCにデプロイされたアプリケーションからのみアクセスできる必要があります。会社はAPIを正常にデプロイしましたが、VPCにデプロイされたAmazon EC2インスタンスからAPIにアクセスできません。
EC2インスタンスとAPI間の接続を提供するためには、どのソリューションを使用すべきでしょうか？
A. API GatewayのインターフェースVPCエンドポイントを作成します。エンドポイントポリシーを追加して、apigateway:*アクションを許可します。VPCエンドポイントに対してプライベートDNS名を無効にします。VPCからアクセスを許可するAPIリソースポリシーを設定します。VPCエンドポイントのDNS名を使用してAPIにアクセスします。
B. API GatewayのインターフェースVPCエンドポイントを作成します。エンドポイントポリシーを追加して、execute-api:Invokeアクションを許可します。VPCエンドポイントに対してプライベートDNS名を有効にします。VPCエンドポイントからアクセスを許可するAPIリソースポリシーを設定します。APIエンドポイントのDNS名を使用してAPIにアクセスします。
C. ネットワークロードバランサー（NLB）とVPCリンクを作成します。API GatewayとNLB間でプライベート統合を構成します。APIエンドポイントのDNS名を使用してAPIにアクセスします。
D. アプリケーションロードバランサー（ALB）とVPCリンクを作成します。API GatewayとALB間でプライベート統合を構成します。ALBエンドポイントのDNS名を使用してAPIにアクセスします。
解説
この問題における解説は、Amazon API GatewayとVPC間で安全に通信を行う方法についてです。要点は、EC2インスタンスからAPI GatewayのプライベートREST APIにアクセスする方法に関するものです。
解決方法: インターフェースVPCエンドポイントを使用
API GatewayのプライベートREST APIは、インターネット経由ではなく、特定のVPC内からアクセスすることが求められています。そのため、インターフェースVPCエンドポイントを使って、VPC内のリソースからAPI Gatewayにアクセスできるようにします。
各選択肢の解説：
A. インターフェースVPCエンドポイントの作成 (不正解)
- 理由: エンドポイントポリシーで
apigateway:*アクションを許可するのは、過剰に広い権限を与えることになり、セキュリティ上好ましくありません。API Gatewayへのアクセスを制限するために、より細かいポリシーを使用するべきです。
- また、プライベートDNSを無効にすると、VPC内からAPI Gatewayのアクセスが困難になり、推奨されない方法です。
B. インターフェースVPCエンドポイントの作成 (正解)
- 理由:
execute-api:Invokeアクションを許可するエンドポイントポリシーは、API Gatewayへの正しいアクセス制御を提供します。さらに、プライベートDNSを有効にすることで、VPC内のインスタンスからAPI GatewayのDNS名で直接アクセスできるようになります。これは、APIをプライベートに安全にアクセスできる最適な方法です。
- APIリソースポリシーで、VPCからのアクセスを許可する設定を行うことで、APIのセキュリティが確保されます。
C. ネットワークロードバランサー（NLB）とVPCリンク (不正解)
- 理由: NLBはAPI Gatewayとの統合には適していません。NLBは通常、インスタンスやコンテナベースのサービスに対して利用されますが、API Gatewayとの統合に使用することは非推奨です。API GatewayはVPCエンドポイントを使ったアクセスをサポートしており、NLBを使う必要はありません。
D. アプリケーションロードバランサー（ALB）とVPCリンク (不正解)
- 理由: ALBも、API GatewayのプライベートAPIにアクセスするための推奨方法ではありません。API Gatewayは、VPCエンドポイントと組み合わせて利用することが一般的です。ALBを使ってAPI Gatewayと統合するのは不適切です。
結論
正解はBです。インターフェースVPCエンドポイントを作成し、
execute-api:Invokeアクションを許可し、プライベートDNSを有効にすることで、VPC内のEC2インスタンスからAPI GatewayのプライベートREST APIに安全にアクセスできるようになります。367-AWS SAP AWS 「理論・実践・一問道場」クロスアカウントアクセス
理論
1. AWS Organizationsの基本
AWS Organizationsは、複数のAWSアカウントを中央で管理できるサービスです。これにより、アカウントの作成、管理、ポリシー適用、請求管理などを一元化することができます。主な機能には次のようなものがあります：
- アカウント管理：複数のAWSアカウントを一元管理。
- 組織単位 (OU)：アカウントを論理的にグループ化し、管理。
- サービスコントロールポリシー (SCP)：アカウントや組織単位に対するアクセス制限を設定。
- 中央管理の請求：組織内での一元的な請求書管理。
2. OrganizationAccountAccessRole (組織アカウントアクセスロール)
- AWS Organizationsを使用してメンバーアカウントにアクセスするためには、各メンバーアカウントに**
OrganizationAccountAccessRole*というIAMロールを作成する必要があります。このロールは、管理アカウントに対してメンバーアカウントのリソースにアクセスできる権限を与えるために使用されます。
- このロールは、デフォルトでAdministratorAccessの権限を持ち、管理アカウントはこのロールを引き受けてメンバーアカウントを管理します。
3. IAMロールとクロスアカウントアクセス
- クロスアカウントアクセスとは、あるAWSアカウント（管理アカウント）が、別のAWSアカウント（メンバーアカウント）のリソースにアクセスするための仕組みです。このアクセスは通常、IAMロールを使用して設定します。
- 管理アカウントは、IAMロールを引き受けてメンバーアカウント内で操作を実行することができます。
OrganizationAccountAccessRoleは、特にAWS Organizations内でこれを効率的に設定するための特別なロールです。
4. AdministratorAccessポリシー
AdministratorAccessは、AWSのすべてのサービスに対して完全なアクセス権を持つポリシーです。このポリシーは、ユーザーやロールに付与することで、リソースの作成や削除、設定変更など、管理者としての完全な権限を与えます。
OrganizationAccountAccessRoleは、管理者権限を持つロールとしてAWS Organizations内で使用されるため、通常、AdministratorAccessを含んでいます。
5. アクセスの制限とセキュリティ
- *サービスコントロールポリシー (SCP)**は、AWS Organizations内のアカウントに対するアクセス権限を制限するために使用されます。SCPはアカウントが実行できるアクションを制限しますが、IAMロールによる具体的なアクセス権の付与とは異なり、組織全体のポリシーとして機能します。
結論
AWS OrganizationsとIAMロールを利用することで、複数のAWSアカウントを効率的に管理でき、管理アカウントに必要なアクセス権限を付与できます。
OrganizationAccountAccessRoleは、メンバーアカウントにアクセスするためのロールとして特に重要であり、これを使用することでセキュアかつ効率的にアカウント間のアクセスを管理できます。実践
略
一問道場
ある大手給与会社が最近、小規模なスタッフ派遣会社と統合しました。統合された会社は、複数の事業部門があり、それぞれが独自のAWSアカウントを持っています。
ソリューションアーキテクトは、すべてのAWSアカウントに対して請求とアクセスポリシーを中央で管理できるようにする必要があります。ソリューションアーキテクトは、中央の管理アカウントからすべてのメンバーアカウントに招待状を送信してAWS Organizationsを設定しました。
次に、ソリューションアーキテクトがこの要件を満たすために行うべきことは何ですか？
A. 各メンバーアカウントにOrganizationAccountAccess IAMグループを作成し、各管理者に必要なIAMロールを含める。
B. 各メンバーアカウントにOrganizationAccountAccessPolicy IAMポリシーを作成し、クロスアカウントアクセスを使用してメンバーアカウントを管理アカウントに接続する。
C. 各メンバーアカウントにOrganizationAccountAccessRole IAMロールを作成し、管理アカウントにそのIAMロールを引き受ける権限を付与する。
D. 管理アカウントにOrganizationAccountAccessRole IAMロールを作成し、そのIAMロールにAdministratorAccess AWS管理ポリシーをアタッチし、各メンバーアカウントの管理者にそのIAMロールを割り当てる。
解説
この問題は、AWS Organizationsを使用して複数のAWSアカウントを管理し、中央で請求とアクセスのポリシーを管理する方法に関するものです。具体的には、管理アカウントからメンバーアカウントに対してアクセスを設定する方法を問われています。
各選択肢について解説します：
A. 各メンバーアカウントにOrganizationAccountAccess IAMグループを作成し、各管理者に必要なIAMロールを含める
- この選択肢は正しくありません。IAMグループはユーザーをまとめて管理するためのものですが、AWS Organizationsの設定には関係がありません。特に、メンバーアカウントと管理アカウントを接続するためにはIAMロールを使用する必要があります。
B. 各メンバーアカウントにOrganizationAccountAccessPolicy IAMポリシーを作成し、クロスアカウントアクセスを使用してメンバーアカウントを管理アカウントに接続する
- これは不正解です。AWS Organizationsの管理には、ポリシーではなくIAMロールを使用して、管理アカウントがメンバーアカウントのリソースにアクセスできるようにする必要があります。また、クロスアカウントアクセスは特定のケースで使用しますが、AWS Organizationsの機能としてはロールの作成が適切です。
C. 各メンバーアカウントにOrganizationAccountAccessRole IAMロールを作成し、管理アカウントにそのIAMロールを引き受ける権限を付与する
- この選択肢が正解です。AWS Organizationsでは、管理アカウントがメンバーアカウントに対してアクセスを制御するために、OrganizationAccountAccessRole というIAMロールを作成します。このロールを使用すると、管理アカウントはメンバーアカウントに対する管理権限を持ち、中央でアカウントを管理できます。
D. 管理アカウントにOrganizationAccountAccessRole IAMロールを作成し、そのIAMロールにAdministratorAccess AWS管理ポリシーをアタッチし、各メンバーアカウントの管理者にそのIAMロールを割り当てる
- この選択肢も不正解です。管理アカウントにIAMロールを作成するのではなく、メンバーアカウントにロールを作成し、管理アカウントがそのロールを引き受ける形にする必要があります。管理アカウントにはロールを割り当てるのではなく、他のアカウントのロールを引き受ける権限を与える形が正しいです。
結論
正解は C です。各メンバーアカウントに
OrganizationAccountAccessRole IAMロールを作成し、管理アカウントにそのロールを引き受ける権限を付与することで、中央でアカウントの管理と請求を行うことができます。368-AWS SAP AWS 「理論・実践・一問道場」Kafka
理論
フラッグシップ（flagship）とは、企業の製品やサービスの中で最も重要なものや代表的なものを指す言葉です。旗艦（きかん）とも呼ばれ、企業の顔となるモデルを意味します
Apache Kafkaとは、分散型のストリーミングプラットフォームで、リアルタイムでのデータの送受信や処理をサポートするツールです。Kafkaは大規模なデータのストリームを扱うために設計されており、高いスループット、耐障害性、スケーラビリティを提供します。
主な機能:
- メッセージングシステム: Kafkaは、プロデューサー（データを送信する側）とコンシューマー（データを受信する側）間のメッセージ交換を効率的に行います。データはトピックという論理的なチャネルを通じて送受信され、トピックは複数のパーティションに分割できます。
- ストリーム処理: Kafkaは単なるメッセージングだけでなく、データのストリーム処理もサポートします。リアルタイムでデータの変換やフィルタリングを行い、データフローを管理する機能を持っています。
- 高可用性と耐障害性: Kafkaはデータのレプリケーションをサポートし、複数のサーバーにデータを保存することで、高可用性を実現します。サーバーがダウンしてもデータは失われません。
- スケーラビリティ: Kafkaは大規模なデータストリームを効率的に処理できるため、数百万のメッセージを扱うシステムにも対応できます。パーティションを使ってデータを分散し、スケールアップまたはスケールアウトが可能です。
- 永続性: Kafkaは、データをディスクに永続化し、必要に応じて再処理することができます。これにより、メッセージが失われることなく、一定期間データを保存することができます。
具体的な使用ケース:
- リアルタイムのログ収集: Kafkaはアプリケーションやサーバーからリアルタイムでログを収集し、モニタリングや分析に役立てます。
- イベント駆動アーキテクチャ: 分散システムでのイベントや通知を非同期に処理する際に利用されます。
- ストリーム処理: リアルタイムでのデータ分析やトランザクション処理に用いられます。たとえば、オンラインストアの顧客行動データをリアルタイムで処理する場合などです。
Amazon Managed Streaming for Apache Kafka (Amazon MSK)
AWSでは、Apache Kafkaをマネージドサービスとして提供する「Amazon MSK」が利用できます。これにより、ユーザーはKafkaのインフラの管理から解放され、スケーラブルで高可用なストリーミングシステムを迅速に構築できます。Amazon MSKは、次のような利点があります：
- 簡素化された管理: Kafkaのセットアップや運用を簡素化し、スケーリングやパッチ適用をAWSが管理します。
- フルマネージド: インフラの管理が不要で、運用の手間を大幅に減らします。
- AWS統合: 他のAWSサービス（例：AWS LambdaやAmazon S3）との統合が容易で、データフローをさらに効率化できます。
関連:
- Kafkaの導入は、イベント駆動型アーキテクチャの実装や大量のデータストリームの処理に役立ちます。たとえば、注文処理システムやリアルタイム分析が必要な場合に有効です。
- Amazon MSKを使用することで、Kafkaの運用負担を軽減し、アプリケーションのスケーラビリティや耐障害性を高めることができます。
Kafkaを使うことにより、運用の簡素化と同時に、スケーラビリティや可用性が向上し、アーキテクチャ全体のパフォーマンスを大きく向上させることができます。
実践
略
一問道場
ある会社には、複数のAmazon EC2インスタンスにデプロイされたコンテナ化されたアプリケーションサービスがあります。Apache KafkaクラスターがEC2インスタンスにデプロイされ、PostgreSQLデータベースはAmazon RDS for PostgreSQLに移行されています。会社は、新しいバージョンのフラッグシップ製品のリリース時にプラットフォームの注文が大幅に増加することを予測しています。
現在のアーキテクチャにどのような変更を加えれば、運用のオーバーヘッドを削減し、製品のリリースをサポートできるでしょうか？
A. アプリケーションロードバランサーの背後にEC2オートスケーリンググループを作成します。データベースインスタンスに追加のリードレプリカを作成します。Amazon Kinesisデータストリームを作成し、アプリケーションサービスをデータストリームに接続します。静的コンテンツを直接Amazon S3から提供します。
B. アプリケーションロードバランサーの背後にEC2オートスケーリンググループを作成します。データベースインスタンスをMulti-AZモードでデプロイし、ストレージのオートスケーリングを有効にします。Amazon Kinesisデータストリームを作成し、アプリケーションサービスをデータストリームに接続します。静的コンテンツを直接Amazon S3から提供します。
C. EC2インスタンス上に作成したKubernetesクラスターにアプリケーションをデプロイし、アプリケーションロードバランサーの背後に配置します。データベースインスタンスをMulti-AZモードでデプロイし、ストレージのオートスケーリングを有効にします。Amazon Managed Streaming for Apache Kafkaクラスターを作成し、アプリケーションサービスをクラスターに接続します。静的コンテンツをAmazon S3に格納し、Amazon CloudFrontディストリビューションの背後で提供します。
D. Amazon Elastic Kubernetes Service (Amazon EKS)を使用してアプリケーションをデプロイし、AWS Fargateでオートスケーリングを有効にし、アプリケーションロードバランサーの背後に配置します。データベースインスタンスに追加のリードレプリカを作成します。Amazon Managed Streaming for Apache Kafkaクラスターを作成し、アプリケーションサービスをクラスターに接続します。静的コンテンツをAmazon S3に格納し、Amazon CloudFrontディストリビューションの背後で提供します。
解説
この問題では、アーキテクチャの変更を通じて、運用オーバーヘッドを削減し、プラットフォームの注文増加を支えるために必要なリソースやアーキテクチャを選定する必要があります。選択肢にある各解決策について詳しく解説します。
A. EC2 Auto Scalingグループ、Kinesisデータストリーム、S3の使用
- EC2 Auto Scaling：EC2インスタンスのスケーリングにより、負荷の変動に対応できるため、リソース不足を回避できます。
- Kinesisデータストリーム：データストリームを使用することで、リアルタイムでデータを収集・処理できるようになり、アプリケーションのスケーラビリティを向上させます。
- S3からの静的コンテンツ提供：静的コンテンツをS3に格納し提供することで、サーバーの負荷を軽減できますが、Kafkaの管理を維持し続ける必要があり、他の選択肢に比べて管理負担が大きくなります。
B. EC2 Auto Scalingグループ、Kinesisデータストリーム、S3の使用、DBのMulti-AZ設定
- Multi-AZ設定：RDSをMulti-AZで構成することで、可用性が高まり、災害復旧の準備が整います。データベースの耐障害性を向上させるためには重要です。
- ストレージオートスケーリング：RDSのストレージが自動的にスケールするため、ディスク容量の管理が簡単になります。
- 静的コンテンツの提供：S3から静的コンテンツを提供する点は、Aと同じですが、データベースの高可用性を確保するための追加要素が含まれています。
C. Kubernetesクラスター、Kafkaの管理、S3 + CloudFront
- Kubernetesクラスター：Kubernetesの使用は、アプリケーションをコンテナ化してより効率的にスケーリングできるため、サービスを管理しやすくします。
- Amazon Managed Streaming for Apache Kafka：Kafkaをマネージドサービスとして使用することで、インフラの管理が簡素化され、可用性が向上します。これにより運用のオーバーヘッドが減少します。
- CloudFrontによる静的コンテンツ配信：CloudFrontを利用することで、コンテンツ配信の速度が向上し、リクエストの負荷分散が可能になります。
D. Amazon EKS、Fargate、Kafka、CloudFront
- Amazon EKS：EKSにより、Kubernetesの管理がAWSに委託されるため、インフラの管理が大幅に簡略化されます。
- Fargate：Fargateを使用することで、インフラの管理から解放され、コンテナのスケーリングが自動的に行われるため、運用オーバーヘッドを大幅に減少させます。
- Kafkaの管理：Amazon Managed Streaming for Apache Kafkaにより、運用負担が軽減され、Kafkaの管理が簡単になります。
- CloudFrontで静的コンテンツ配信：CloudFrontによるコンテンツ配信は、配信速度の向上とキャッシュによる負荷の軽減を実現します。
最適な選択肢：D
- 運用オーバーヘッドの削減：EKS、Fargate、Kafkaの管理がマネージドサービスとして提供されるため、インフラの管理負担を最小限に抑えることができます。また、静的コンテンツをCloudFrontを使って効率的に配信することができます。
- スケーラビリティと可用性：EKSとFargateの組み合わせにより、アプリケーションのスケーラビリティが確保され、Kafkaを管理サービスとして利用することで、パフォーマンスや可用性の向上が期待できます。
このように、Dの選択肢は運用の簡素化、スケーラビリティの向上、可用性の確保に最も効果的な構成です。
369-AWS SAP AWS 「理論・実践・一問道場」Amazon FSx for Windows File Server
理論
1. AWS Storage Gateway
- 概要: AWS Storage Gatewayは、オンプレミスのストレージとAWSクラウドストレージ（Amazon S3、Amazon EBSなど）をシームレスに統合するハイブリッドクラウドサービスです。主に、バックアップ、アーカイブ、リフト・アンド・シフト（移行）などの用途に利用されます。
- Volume Gateway: オンプレミスのストレージシステムを仮想ディスクとして利用できるようにし、クラウドにバックアップを取ったり、リモートアクセスを提供するために使います。
2. Amazon FSx for Windows File Server
- 概要: Amazon FSx for Windows File Serverは、フルマネージドのWindowsネイティブのファイルシステムです。Windows Server環境で利用されるWindowsファイル共有（SMBプロトコル）をサポートしており、オンプレミスからクラウドへの移行を簡素化します。
- 用途: 特にWindowsアプリケーションやWindowsユーザーが必要とするファイルシステムに最適。リモートユーザーがアクセスする場合に、オンプレミスのサーバーに依存せずにAWS上でスケーラブルなファイルシステムを提供できます。
3. AWS Client VPN
- 概要: AWS Client VPNは、AWSのフルマネージド型のVPNサービスです。これにより、リモートユーザーがインターネット経由でAWSリソースに安全にアクセスできるようになります。
- メリット:
- AWSインフラにリモートアクセスするためのシームレスな方法。
- 大規模にスケールすることができ、リモートワーカーの増加にも対応。
- 管理が簡単で、運用オーバーヘッドを最小化。
4. Amazon Direct Connect
- 概要: AWS Direct Connectは、オンプレミスのデータセンターとAWS間に専用のネットワーク接続を提供します。これにより、インターネットを経由せずに安定した高速接続が可能となります。
- 用途: 高帯域幅のデータ転送、低レイテンシーが求められるアプリケーションやバックアップに適しています。しかし、リモートワークのスケーリングにおいては、通常、VPNサービス（AWS Client VPN）やクラウドストレージ（Amazon FSxなど）の方が効果的です。
5. Amazon FSx for Lustre
- 概要: Amazon FSx for Lustreは、高パフォーマンスな並列ファイルシステムで、主にデータ分析やハイパフォーマンスコンピューティング（HPC）用途に最適です。
- 用途: 通常のファイルシステムの要求を超えるパフォーマンスを求められる場合に利用されます。一般的な企業のファイル共有用途（Windowsのホームディレクトリなど）には向いていません。
6. リモートワーク時の帯域幅管理
- 問題: リモートワークの増加により、VPN接続への負荷が増大し、帯域幅が逼迫する問題が発生します。特に大容量のファイルを扱う場合や、接続数が増加する場合に問題となります。
- 解決策:
- クラウドストレージへの移行: Amazon FSx for Windows File Serverを利用することで、オンプレミスのVPNトラフィックを減少させ、クラウド上でスケーラブルにデータを管理できます。
- AWS Client VPNの活用: リモートユーザーをクラウドインフラに直接接続させ、帯域幅負荷を分散させることで、VPNの負荷を軽減します。
これらのサービスやアーキテクチャを適切に選定・設計することで、リモートワークの増加に伴う帯域幅の負荷を効率的に管理し、運用のオーバーヘッドを最小限に抑えることが可能です。
実践
略
一問道場
問題 #369
ある企業は、オンプレミスのデータセンターでVPNをホストしています。従業員は現在、VPNに接続してWindowsのホームディレクトリ内のファイルにアクセスしています。最近、リモート勤務の従業員が増加したため、データセンターへの接続の帯域幅使用量が業務時間中に100％に達するようになりました。企業は、リモートワークフォースの増加をサポートし、データセンターへの接続の帯域幅使用量を削減し、運用のオーバーヘッドを削減するために、AWS上で解決策を設計する必要があります。
これらの要件を最小の運用オーバーヘッドで満たすための手順の組み合わせはどれですか？（2つ選んでください。）
A. AWS Storage GatewayのVolume Gatewayを作成し、Volume Gatewayからボリュームをオンプレミスのファイルサーバーにマウントする。
B. ホームディレクトリをAmazon FSx for Windows File Serverに移行する。
C. ホームディレクトリをAmazon FSx for Lustreに移行する。
D. リモートユーザーをAWS Client VPNに移行する。
E. オンプレミスのデータセンターからAWSにAWS Direct Connect接続を作成する。
解説
この問題では、リモートワークの増加に対応し、オンプレミスのVPN接続への帯域幅負荷を軽減するためのAWSソリューションの設計について考えます。最小の運用オーバーヘッドでこの要件を満たすための選択肢は以下の通りです。
選択肢 B と D が最適です。
B. ホームディレクトリをAmazon FSx for Windows File Serverに移行する
- 理由: Amazon FSx for Windows File Serverは、Windows環境に最適化されたフルマネージドのファイルシステムです。これにより、オンプレミスのWindowsファイルサーバーからホームディレクトリをクラウドに移行できます。リモートユーザーはAWSにホストされたファイルにアクセスできるようになり、データセンターへの接続の帯域幅負荷を減らすことができます。また、AWSはフルマネージドサービスなので、運用のオーバーヘッドも最小限に抑えられます。
D. リモートユーザーをAWS Client VPNに移行する
- 理由: AWS Client VPNは、リモートユーザーに安全にAWSリソースにアクセスさせるためのフルマネージド型VPNサービスです。これを利用することで、ユーザーがAWSインフラに直接アクセスできるようになります。既存のオンプレミスVPNに依存せず、クラウド環境にスケーラブルに対応できるため、帯域幅の使用を分散させることができます。また、運用負担が少ないため、最小のオーバーヘッドでスケーリングが可能です。
他の選択肢の解説:
- A. AWS Storage Gateway Volume Gatewayを作成し、ボリュームをオンプレミスのファイルサーバーにマウントする:
- AWS Storage Gatewayはクラウドにストレージを提供するサービスですが、リモートワークの増加に伴う帯域幅負荷軽減に対して直接的な解決にはなりません。オンプレミスのファイルサーバーに依存するため、完全にAWSに移行する方法としては不十分です。
- C. ホームディレクトリをAmazon FSx for Lustreに移行する:
- Amazon FSx for Lustreは、ハイパフォーマンスなファイルシステムですが、一般的なWindows環境のファイルストレージには適していません。特にWindows環境向けのホームディレクトリには、FSx for Windows File Serverの方が適しています。
- E. オンプレミスのデータセンターからAWSにAWS Direct Connect接続を作成する:
- AWS Direct Connectは、オンプレミスデータセンターとAWS間に専用のネットワーク接続を提供しますが、この場合、帯域幅の負荷を減らすという目的にはあまり効果的ではありません。Direct Connect自体は高帯域幅の接続を提供しますが、リモートワークをスケールさせるためには、VPNやクラウドストレージの移行がより効果的です。
このように、B と D の選択肢がリモートワークの帯域幅の問題を解決し、運用のオーバーヘッドを最小限に抑える最適なソリューションです。
370-AWS SAP AWS 「理論・実践・一問道場」AWS Control Tower
理論
1. AWS OrganizationsとAWS Control Tower
- AWS Organizations: 複数のAWSアカウントを一元管理するためのサービスです。複数アカウントを組織的に管理することで、ポリシーの適用や請求の統一、リソースの整理が可能になります。
- AWS Control Tower: AWS Organizationsと連携し、ベストプラクティスに基づいたセキュリティポリシー（ガードレール）やコンプライアンス規則を自動的に適用するサービスです。新しいアカウントが作成されるたびに、暗号化などのセキュリティ要件を強制できます。
2. EBSボリュームの暗号化
- Amazon EBS（Elastic Block Store）は、EC2インスタンスにアタッチされるブロックストレージです。デフォルトでは、EBSボリュームは暗号化されていませんが、セキュリティ要件に応じて暗号化を強制する必要があります。
- EBSボリュームの暗号化: Amazon EBSボリュームは作成時に暗号化することができます。また、既存のボリュームに対してもスナップショットを使用して暗号化できます。
3. セキュリティとコンプライアンス
- AWSでのセキュリティ管理は、暗号化やIAM（Identity and Access Management）のポリシー適用、監査などを通じて行います。AWS Control Towerを利用することで、セキュリティポリシーをアカウント全体で一貫して管理でき、コンプライアンスに対応した運用が可能になります。
- スナップショットによる暗号化: 暗号化されていないEBSボリュームを暗号化する最も一般的な方法は、スナップショットを作成し、そのスナップショットから新たな暗号化されたボリュームを作成することです。
4. 自動化と運用負荷の軽減
- AWS ConfigやAmazon EventBridgeを利用して、特定のリソース（例えば、暗号化されていないEBSボリューム）が作成されるたびに自動的に通知を受けたり、修正を行ったりすることができます。
- AWS CloudTrailは、APIコールやリソースの変更を監視するサービスで、セキュリティインシデントの早期発見に役立ちます。
まとめ
AWS環境において、暗号化されたEBSボリュームを使用することは、セキュリティとコンプライアンスを維持するために不可欠です。AWS OrganizationsとAWS Control Towerを使用すれば、複数のAWSアカウントに対してセキュリティポリシーを一元管理し、暗号化を必須とする運用を自動化できます。さらに、スナップショットを利用して既存の未暗号化ボリュームを暗号化し、セキュリティ要件を満たすことができます。
実践
略
一問道場
問題 #370
ある企業には複数のAWSアカウントがあります。この企業は最近行ったセキュリティ監査で、Amazon EC2インスタンスにアタッチされている多くの暗号化されていないAmazon Elastic Block Store（Amazon EBS）ボリュームが存在することが判明しました。
ソリューションアーキテクトは、暗号化されていないボリュームを暗号化し、今後暗号化されていないボリュームを自動的に検出できるようにする必要があります。さらに、企業はコンプライアンスとセキュリティに重点を置いて複数のAWSアカウントを集中管理したいと考えています。
ソリューションアーキテクトは、これらの要件を満たすためにどの組み合わせの手順を踏むべきでしょうか？（2つ選んでください。）
A. AWS Organizationsで組織を作成し、AWS Control Towerを設定して、強く推奨されるコントロール（ガードレール）をオンにします。すべてのアカウントを組織に参加させ、AWSアカウントを組織単位（OU）に分類します。
B. AWS CLIを使用して、すべてのAWSアカウントで暗号化されていないボリュームをリストします。スクリプトを実行して、暗号化されていないボリュームをそのまま暗号化します。
C. 各暗号化されていないボリュームのスナップショットを作成し、スナップショットから新しい暗号化されたボリュームを作成します。既存のボリュームを切り離し、暗号化されたボリュームに置き換えます。
D. AWS Organizationsで組織を作成し、AWS Control Towerを設定して、必須のコントロール（ガードレール）をオンにします。すべてのアカウントを組織に参加させ、AWSアカウントを組織単位（OU）に分類します。
E. AWS CloudTrailをオンにし、Amazon EventBridgeルールを設定して、暗号化されていないボリュームを自動的に検出して暗号化します。
解説
正しい選択肢: A と C
A. AWS OrganizationsとAWS Control Towerを使用する
このステップは、複数のAWSアカウントを一元管理し、セキュリティやコンプライアンスのガードレール（制約）を強制するための重要な方法です。AWS Control Towerを利用することで、セキュリティポリシーを統一的に適用でき、暗号化されていないEBSボリュームに関する管理を一元化できます。
- AWS Organizationsでアカウントを整理し、AWS Control Towerを設定することで、各アカウントのセキュリティ要件（例えば、暗号化を必須とするポリシー）を一貫して適用できます。
- これにより、新しい暗号化規則をアカウント全体で強制することが可能になり、将来新しいEBSボリュームが暗号化されないことを防げます。
C. スナップショットを作成して暗号化されたボリュームを作成する
暗号化されていないボリュームを検出し、それを暗号化する方法として、このステップは実用的です。具体的なプロセスは以下の通りです：
- 暗号化されていないEBSボリュームのスナップショットを作成
- スナップショットから新しい暗号化されたボリュームを作成
- 既存のボリュームを切り離し、新しい暗号化されたボリュームに差し替える
これにより、既存の暗号化されていないEBSボリュームを暗号化することができるため、セキュリティの要件を満たすことができます。
結論
- A は、AWSアカウントの一元管理と、ポリシー適用の強制を実現します。
- C は、手動で暗号化されていないEBSボリュームを暗号化する方法として実行可能です。
この組み合わせにより、企業全体でセキュリティポリシーを一貫して強制し、現在および将来のEBSボリュームの暗号化を実現できるため、最小の運用負荷で要件を満たすことができます。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/178d7ae8-88e2-8059-bf24-d0925e40a4c5
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
