type
status
date
slug
summary
tags
category
icon
password
书籍
031-SCP
理論
1. AWS Marketplaceの管理
- Private Marketplace: 企業が事前に承認したサードパーティ製品のみを利用できるように制限するための仕組み。これにより、企業はセキュリティとコスト管理の面でリスクを軽減できる。
- 管理者権限: Private Marketplaceの設定やソフトウェア購入に関する管理は、特定のユーザーや役割に制限する必要がある。これにより、誤った購入や非承認のソフトウェアの利用を防ぐ。
2. IAM（Identity and Access Management）と役割
- IAMロール: 特定の役割に対してアクセス権限を与えるための設定。例えば、
procurement-manager-roleというIAMロールを使って、調達管理者がMarketplaceの管理を行えるようにする。
- インラインポリシー: IAMロールに直接追加するポリシーで、特定の操作を許可または拒否する。組織内の他のユーザーや役割には、Marketplaceの管理アクセスを拒否するインラインポリシーを適用することが推奨される。
3. サービスコントロールポリシー（SCP）
- SCP: AWS Organizations内のアカウントに対して、アクセス権限を制御するためのポリシー。SCPは、特定の操作を組織全体または特定の組織単位（OU）に対して許可または拒否することができる。
- SCPの利用: Private Marketplaceに関する管理権限を制限するため、SCPを使用して、
procurement-manager-role以外のユーザーに対する管理権限を拒否することができる。これにより、アクセス権限を一元管理し、リスクを軽減する。
4. アクセス制御と最小権限の原則
- 最小権限の原則: 各ユーザーや役割に必要最低限のアクセス権を付与することで、セキュリティリスクを減らす。この原則に基づき、開発者や他の社員には、ソフトウェアの選定や購入を行う権限を与えず、あらかじめ承認されたリストからのみ利用を許可する。
- 権限の境界:
AWSPrivateMarketplaceAdminFullAccessなどの管理権限を、特定の役割やユーザーに制限するために、権限の境界を設定することが推奨される。
結論
企業がAWS Marketplaceでサードパーティソフトウェアを管理する際には、IAMロール、インラインポリシー、SCPを効果的に組み合わせて、アクセス権限を厳格に管理することが重要です。最小権限の原則に従い、必要なユーザーだけに管理権限を与えることで、セキュリティと運用の効率性を向上させることができます。
![[アップデート]AWS Marketplaceにプライベート機能が追加され、独自のソフトウェアリストのみを公開できます #reinvent | DevelopersIO](https://www.notion.so/image/https%3A%2F%2Fdev.classmethod.jp%2Ffavicon.ico?table=block&id=165d7ae8-88e2-813a-8f5e-e3ec4a00cdf4&t=165d7ae8-88e2-813a-8f5e-e3ec4a00cdf4)
![[アップデート]AWS Marketplaceにプライベート機能が追加され、独自のソフトウェアリストのみを公開できます #reinvent | DevelopersIO](https://www.notion.so/image/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_reinvent-2018-city_1200x630.jpeg?table=block&id=165d7ae8-88e2-813a-8f5e-e3ec4a00cdf4&t=165d7ae8-88e2-813a-8f5e-e3ec4a00cdf4)
一問道場
エンタープライズ企業がAWS Marketplaceでサードパーティソフトウェアを購入する要件
あるエンタープライズ企業では、開発者がAWS Marketplaceを通じてサードパーティソフトウェアを購入できるようにしたいと考えています。この企業は、AWS Organizationsのアカウント構造を利用しており、フル機能が有効化されています。また、各組織単位（OU）には、調達管理者が使用する共有サービスアカウントがあります。
要件：
- 調達チームの方針
- 開発者は、承認されたリストからのみソフトウェアを取得可能にする必要があります。
- Private Marketplaceを使用してこの要件を実現します。
- 管理の制限
- Private Marketplaceの管理は、調達管理者が引き受ける
procurement-manager-roleというロールに限定します。 - 他のIAMユーザー、グループ、ロール、およびアカウント管理者は、Private Marketplaceの管理アクセスを拒否されるべきです。
最も効率的な設計方法を選ぶ選択肢
A.
すべてのAWSアカウントに
procurement-manager-roleというIAMロールを作成する。このロールにPowerUserAccessのマネージドポリシーを追加する。
さらに、すべてのIAMユーザーとロールに対して、インラインポリシーを適用して
AWSPrivateMarketplaceAdminFullAccessのマネージドポリシーに関する権限を拒否する。B.
すべてのAWSアカウントに
procurement-manager-roleというIAMロールを作成する。このロールにAdministratorAccessのマネージドポリシーを追加する。
その上で、AWSPrivateMarketplaceAdminFullAccessマネージドポリシーを使用して権限境界を定義し、すべての開発者ロールに適用する。
C.
すべての共有サービスアカウントに
procurement-manager-roleというIAMロールを作成する。このロールにAWSPrivateMarketplaceAdminFullAccessのマネージドポリシーを追加する。
OrganizationsのルートレベルでSCP（サービスコントロールポリシー）を作成し、次のことを行う：
procurement-manager-role以外のすべてのユーザーに対して、Private Marketplaceの管理権限を拒否する。
- 組織内のすべてのユーザーに対して、
procurement-manager-roleの作成を拒否する。
D.
開発者が使用するすべてのAWSアカウントに
procurement-manager-roleというIAMロールを作成する。このロールにAWSPrivateMarketplaceAdminFullAccessのマネージドポリシーを追加する。
OrganizationsでSCPを作成し、次のことを行う：
procurement-manager-role以外のすべてのユーザーに対して、Private Marketplaceの管理権限を拒否する。
- このSCPを組織内のすべての共有サービスアカウントに適用する。
問題の解説
この問題では、企業が AWS Marketplace の機能を活用して開発者がサードパーティソフトウェアを購入できるようにしたいという要件があります。しかし、同時に次のような制約が課されています：
要件の整理
- 開発者が購入できるのは承認済みのソフトウェアのみ
- Private Marketplace を利用して、承認済みのソフトウェアのみをリストアップします。
- Private Marketplaceの管理者権限の制限
- 管理権限を
procurement-manager-roleに限定し、他のIAMユーザー、グループ、ロール、またはアカウント管理者にはアクセスを禁止します。
- 効率的な管理が求められる
- AWS Organizations構造を活用し、すべてのアカウントに効率的にポリシーを適用します。
選択肢の比較
選択肢 A
- IAMロールをすべてのアカウントに作成し、
PowerUserAccessポリシーを付与。
- IAMユーザーやロールにインラインポリシーを適用し、
AWSPrivateMarketplaceAdminFullAccessを禁止。
問題点:
- IAMユーザーやロールごとにインラインポリシーを適用する必要があり、スケーラビリティが低い。
- 非効率で管理が複雑。
選択肢 B
- すべてのアカウントにIAMロールを作成し、
AdministratorAccessポリシーを付与。
- 開発者ロールに対して、
AWSPrivateMarketplaceAdminFullAccessを制限するための境界ポリシーを設定。
問題点:
- 開発者に関係のない
AdministratorAccessを全アカウントで付与するのはセキュリティ上のリスク。
- 設定が複雑になりやすい。
選択肢 C (正解)
- 共有サービスアカウントに
procurement-manager-roleを作成。 AWSPrivateMarketplaceAdminFullAccessポリシーを付与。
- AWS Organizationsで、次のSCP（Service Control Policy）を定義：
procurement-manager-role以外にはPrivate Marketplace管理権限を付与しないポリシー。- 他のユーザーが
procurement-manager-roleを作成する権限を禁止するポリシー。
理由:
- SCPを利用することで、ポリシー適用を組織全体で一元管理可能。
procurement-manager-roleの管理権限を制限でき、他のIAMユーザーやロールに管理権限を与えないよう確実に制御できる。
選択肢 D
- 開発者が利用するすべてのアカウントに
procurement-manager-roleを作成。
AWSPrivateMarketplaceAdminFullAccessを付与。
- SCPを用いて管理権限をロールに限定し、共有サービスアカウントに適用。
問題点:
procurement-manager-roleをすべてのアカウントに作成する手間がかかる。
- 管理が煩雑で、共有サービスアカウントで一元管理するメリットを活用できていない。
結論
最も効率的かつセキュアな方法は 選択肢 C です。この方法では、次のような利点があります：
- 管理の効率化:
procurement-manager-roleを共有サービスアカウントに限定し、一元管理可能。
- セキュリティの強化: SCPによる組織全体の制御で、意図しない権限の付与を防止。
- スケーラビリティ: 全アカウントでポリシーを一括適用可能。
032-SCP
一問道場
ある企業が、AWS Organizations を実装して、開発者が Amazon EC2、Amazon S3、Amazon DynamoDB のみを使用するよう制約を設けようとしています。開発者アカウントは専用の組織単位（OU）に所属しています。ソリューションアーキテクトは、以下の SCP（サービスコントロールポリシー）を開発者アカウントに実装しました。
しかし、このポリシーを適用した後も、開発者アカウント内の IAM ユーザーは、このポリシーに記載されていない AWS サービスを利用できています。
ソリューションアーキテクトは、開発者がポリシーの範囲外のサービスを利用できないようにするために、どのように対処すべきでしょうか？
選択肢：
A. 制約する必要がある各 AWS サービスについて、明示的な拒否（Deny）ステートメントを作成する。
B. 開発者アカウントの OU から FullAWSAccess SCP を削除する。
C. FullAWSAccess SCP を変更して、すべてのサービスを明示的に拒否する。
D. SCP の末尾にワイルドカード（
*）を使用した明示的な拒否ステートメントを追加する。解説
以下に、選択肢A、B、C、Dにおける 実際例 とその問題点を挙げて、説明します。
A. 制約する必要がある各 AWS サービスについて、明示的な拒否（Deny）ステートメントを作成する。
実際例:
問題点:
- 手間がかかる: 上記の例では、
ec2,dynamodb,s3以外の各サービスを個別に拒否していますが、新しいAWSサービスが追加される度に、拒否ステートメントを追加しなければならないため、管理が煩雑です。
- 漏れのリスク: 新たに追加されたサービスに対して、拒否設定を忘れてしまう可能性があります。
BC は OU 全体 に影響を与える可能性があるため避けた方がよいです。
D. SCP の末尾にワイルドカード（
実際例:
問題点:
- 過剰な拒否設定:
を使用して全サービスを拒否する場合、ec2,dynamodb,s3以外のサービスを拒否することは確かですが、他の依存関係を持つリソースが許可されない可能性があり、問題が発生する可能性もあります。たとえば、s3を利用するLambda関数やEC2インスタンスなどが問題に直面するかもしれません。
総括と改善案
- A: 手動で個別に拒否を追加する方法は、サービスの追加に対応できるものの、管理が煩雑になり、漏れのリスクが高いです。
- BC は OU 全体 に影響を与える可能性があるため避けた方がよいです。
- D は他のアカウントに影響を与えることなく、特定のアカウントに対して明示的な制限を加える方法として最適です。
- D: ワイルドカードを使用して拒否する方法は簡潔で効果的ですが、他のサービスの依存関係に注意が必要です。
最もバランスの取れた方法は、D（ワイルドカードを使用してすべてを拒否する）です。
033-ALB
理論
Amazon Route 53 マルチバリュー回答ルーティングポリシー
マルチバリュー回答ルーティングポリシー (Multivalue Answer Routing Policy) は、Amazon Route 53 で使用できるルーティングポリシーの一つで、複数の異なる IP アドレスを単一の DNS クエリの応答として返すものです。これにより、クライアントが複数のエンドポイントにアクセスできるようになり、可用性や冗長性を向上させることができます。
具体的な特徴と使い方は以下の通りです：
特徴：
- 複数の IP アドレスを返す：
- マルチバリュー回答ポリシーを使うと、複数の IP アドレスを一度に返すことができます。たとえば、5つの EC2 インスタンスを持つ場合、これらのインスタンスの IP アドレスをすべて Route 53 のレコードに設定し、クライアントにそれらの IP を一度に返すことができます。
- ロードバランシング：
- 返された IP アドレスの中から、クライアントがランダムに選択して接続することが多いため、一定のロードバランシング効果があります。
- ヘルスチェックの統合：
- 各エンドポイント（IP アドレス）に対してヘルスチェックを設定できます。これにより、ヘルスチェックに失敗した IP アドレスは、クエリの応答から除外されるため、正常に稼働しているインスタンスのみに接続されるようになります。
使用例：
- モバイルアプリやウェブアプリで、高可用性を確保したい場合に、複数のサーバー（EC2インスタンス）のIPを設定して、トラフィックを分散させる。
- 可用性向上のため、複数のリージョンやデータセンターにまたがるサーバーを設定する。
注意点：
- マルチバリュー回答ルーティングポリシーは、負荷分散の目的で使われますが、より高度な負荷分散が必要な場合には、Application Load Balancer（ALB）やAmazon CloudFrontなどを使用する方が効果的です。
- 複数の IP アドレスを返すため、クライアント側がどの IP を選ぶかに依存するため、完全な制御はできません。
このポリシーは、非常に簡単に冗長性と負荷分散を実現できるため、特にシンプルなシステムや低コストで冗長性を確保したい場合に便利です。
最小の運用オーバーヘッド
最小の運用オーバーヘッドとは、システムやサービスの運用や管理に必要な手間やコストが最も少ない状態を指します。具体的には、次のような要素が含まれます：
1. 自動化の活用
- システムのスケーリングやトラフィックの負荷分散などが自動で行われること。例えば、Application Load Balancer (ALB) では、トラフィックを自動的に健康なインスタンスに分散するため、手動でトラフィックの調整やインスタンスの追加・削除を行う必要がありません。
2. 管理作業の簡素化
- サービスやインフラの設定や管理に関わる作業が最小限で済むこと。たとえば、ALBを使うことで、複雑なトラフィック管理を簡単に設定でき、運用者が介入する必要が少なくなります。
3. 最小限の手動操作
- システムの変更や調整を手動で行わなくても、システムが自動的に最適な状態を維持できること。例えば、Auto Scaling や Route 53 の設定を使って、サーバーの台数やトラフィックの分散を自動化できます。
4. スケーラビリティ
- システムが自動的に負荷の変動に応じてスケールできること。例えば、EC2インスタンスの数が急増した場合でも、ALBやAuto Scalingにより、システムが必要なリソースを自動的に調整します。
5. 監視とアラート
- システムの監視や異常時の通知が効率的であり、問題が発生した場合にすぐに対応できること。これにより、問題が発生した場合に手動で監視を行う負担が軽減されます。
まとめると：
最小の運用オーバーヘッドは、システムを管理するために必要な時間や労力が最も少ない状態を指します。自動化、簡素化、スケーラビリティにより、手動作業が減り、効率的にサービスを提供できる状態が最小の運用オーバーヘッドです。
一問道場
質問 #33
トピック 1
ある企業が、モバイルアプリ用のモノリシックなRESTベースのAPIをVPCのパブリックサブネットにある5つのAmazon EC2インスタンスでホストしています。モバイルクライアントは、Amazon Route 53でホストされたドメイン名を使用してAPIに接続します。企業は、すべてのEC2インスタンスのIPアドレスを含むRoute 53のマルチバリュー回答ルーティングポリシーを作成しました。最近、アプリが大量で急激なトラフィックの増加に圧倒され、トラフィックに追いつけなくなっています。
ソリューションアーキテクトは、アプリが新しい負荷と変動する負荷に対応できるようにするためのソリューションを実装する必要があります。
最小の運用オーバーヘッドでこの要件を満たすソリューションはどれですか？
選択肢：
A.
APIを個別のAWS Lambda関数に分割します。
Amazon API Gateway REST APIを設定し、バックエンドとしてLambda統合を使用します。
Route 53レコードを更新してAPI Gateway APIを指すようにします。
B.
APIロジックをコンテナ化します。
Amazon Elastic Kubernetes Service（Amazon EKS）クラスターを作成し、Amazon EC2を使用してクラスター内でコンテナを実行します。
Kubernetesのイングレスを作成します。
Route 53レコードを更新してKubernetesイングレスを指すようにします。
C.
Auto Scalingグループを作成し、すべてのEC2インスタンスをそのAuto Scalingグループに配置します。
Auto Scalingグループを設定して、CPU使用率に基づいてスケーリングアクションを実行します。
Auto Scalingグループの変更に反応してRoute 53レコードを更新するAWS Lambda関数を作成します。
D.
Application Load Balancer（ALB）をAPIの前に作成します。
EC2インスタンスをVPCのプライベートサブネットに移動し、ALBのターゲットとしてEC2インスタンスを追加します。
Route 53レコードを更新してALBを指すようにします。
解説
D. Application Load Balancer (ALB) の使用 の理由：
- 運用オーバーヘッドを最小化するために、ALBは非常に有効です。ALBは自動でトラフィックを複数のインスタンスに分散するので、スケーリングや負荷分散を容易に行えます。これにより、手動でインスタンス数を調整する必要がなく、システムの運用負担が軽減されます。
- ALBを使うことで、トラフィックが自動的に分散され、EC2インスタンスがプライベートサブネットに移動しても、外部からのアクセスはALBを通じて管理されます。これにより、セキュリティが向上するとともに、トラフィックの負荷をうまく管理できます。
- Auto Scaling とALBの組み合わせは非常に効果的ですが、Auto Scaling自体はEC2インスタンスのスケーリングを管理するものであり、ALBがそのインスタンスに対してトラフィックを分散する役割を果たします。ALBとAuto Scalingは併用できますが、ALB単体で運用の負担を軽減する方法としては最も簡単です。
他の選択肢の問題点：
- A. LambdaとAPI Gateway: Lambda と API Gateway を使用すると、サーバーレスアーキテクチャに移行する必要があり、これには既存のモノリシックなAPIを再設計し、管理方法が変わるため、運用オーバーヘッドが増える可能性があります。
- B. EKSの使用: EKS はコンテナオーケストレーションサービスであり、コンテナ化されたアーキテクチャに移行する必要があります。これも大規模な変更を伴い、運用オーバーヘッドが増加します。
- C. Auto Scalingグループ: Auto Scaling は確かに効果的ですが、ALBと組み合わせることでより効果を発揮します。Auto Scaling単独では、インスタンス数が増減しても、ALBを使わないと、トラフィックの分散が効率的ではなくなります。
結論：
D. Application Load Balancer (ALB) の使用が最も運用オーバーヘッドを軽減し、効果的にトラフィックを管理する解決策です。ALBはインスタンスの負荷分散を行い、トラフィックのスケーラビリティと可用性を確保します。また、EC2インスタンスをプライベートサブネットに移動することで、セキュリティも強化されます。
034-CUR
理論
1. AWS Organizationsの管理機能
AWS Organizationsは、複数のAWSアカウントを一元的に管理するためのサービスです。これを使用すると、アカウントの階層構造を作成したり、ポリシーを適用したり、請求情報を集約したりできます。
このサービスにより、組織全体でコストと使用状況の管理が簡素化されます。複数のアカウントがある企業では、各アカウントの使用状況やコストの内訳を集約し、まとめて管理するために非常に有用です。
2. AWS Cost and Usage Report (CUR)
- AWS Cost and Usage Report (CUR)は、AWSアカウントの使用状況とコストの詳細なレポートを提供します。
- CURは、AWSのすべてのサービスについて、使用量（リソースごとの使用量、ストレージ量、ネットワーク転送量など）とコストを詳細にレポートします。
- これにより、各サービスがどれだけコストを消費しているか、特定のAWSリソースの使用状況がどうなっているかを正確に把握できます。
CURの特徴：
- CSV形式やParquet形式でデータを出力可能
- 月単位でレポートを生成し、コストや使用量を詳細に分析
- 複数のアカウント、サービス、リソースに分けてフィルタリングが可能
CURの利用方法：
- S3に保存することで、後で分析したり、Amazon RedshiftやAmazon QuickSightで視覚化したりできます。
3. Amazon QuickSight
Amazon QuickSightは、AWSのビジネスインテリジェンス（BI）サービスです。
QuickSightを使用すると、さまざまなデータソース（AWS S3、Redshift、RDSなど）からデータをインポートし、ダッシュボードや視覚化を作成して、チームや経営陣にインサイトを提供できます。
CURのデータをQuickSightで視覚化することで、コストと使用状況の傾向をリアルタイムでモニタリングすることができます。
4. AWSリソースアクセスマネージャー (RAM)
AWSリソースアクセスマネージャー (RAM) は、複数のAWSアカウント間でリソースを共有するためのサービスです。
例えば、AWS Organizationsを使用して管理されている複数のアカウント間で、特定のリソース（例えば、VPC、Route 53のホストゾーンなど）を共有することができます。
このサービスは主にリソースの共有に関連しており、コストや使用状況のレポートを直接生成するためには使用されません。
5. Systems ManagerとOpsCenter
AWS Systems Managerは、AWSのインフラ管理のためのツールで、リソースの運用を管理するための各種機能を提供します。
OpsCenterは、システムのインシデント（問題）を管理するための機能で、AWSリソースに関する問題解決やトラブルシューティングを支援します。
しかし、CURを視覚化する目的には、QuickSightのほうが適しています。OpsCenterはコスト管理には直接関連しません。
一問道場
質問：
会社は、AWS Organizationsで各エンジニアリングチーム用に組織単位（OU）を作成しており、各OUは複数のAWSアカウントを所有しています。組織には数百のAWSアカウントがあります。
ソリューションアーキテクトは、各OUがそのAWSアカウントのコスト使用状況を内訳で確認できるようなソリューションを設計する必要があります。
どのソリューションがこの要件を満たしますか？
選択肢：
A.
AWSリソースアクセスマネージャー（RAM）を使用して各OUに対してAWSコストおよび使用状況レポート（CUR）を作成し、各チームがAmazon QuickSightダッシュボードを通じてCURを可視化できるようにする。
B.
AWS Organizationsの管理アカウントからAWSコストおよび使用状況レポート（CUR）を作成し、各チームがAmazon QuickSightダッシュボードを通じてCURを可視化できるようにする。
C.
各AWS OrganizationsのメンバーアカウントでAWSコストおよび使用状況レポート（CUR）を作成し、各チームがAmazon QuickSightダッシュボードを通じてCURを可視化できるようにする。
D.
AWS Systems Managerを使用してAWSコストおよび使用状況レポート（CUR）を作成し、各チームがSystems Manager OpsCenterダッシュボードを通じてCURを可視化できるようにする。
解説
正解：B.
解説：
AWS Organizationsの管理アカウントからAWSコストおよび使用状況レポート（CUR）を作成し、各チームがAmazon QuickSightダッシュボードを通じて可視化する方法が、この要件を満たします。
理由:
- 集中管理されたコスト可視化
- AWS Organizationsの管理アカウントでは、組織全体のコストと使用状況データを集約できます。これにより、各OU（組織単位）やAWSアカウントの詳細なコストデータを取得しやすくなります。
- AWSコストおよび使用状況レポート（CUR）
- CURはAWSが提供する最も詳細なコストデータを収集するためのツールです。これを使用すると、各アカウントやOUごとに内訳を確認することが可能です。
- Amazon QuickSight
- QuickSightはデータを視覚化するためのBIツールで、CURデータを取り込んでOUやアカウントごとのダッシュボードを作成することができます。チームが簡単にコストデータを確認できます。
他の選択肢について
- A.
- AWSリソースアクセスマネージャー（RAM）はリソースの共有に使用するツールであり、コストの管理やレポート作成には適していません。そのため、要件を満たしません。
- C.
- 各メンバーアカウントでCURを作成すると、管理が分散し、効率が悪くなります。全体のコスト可視化が難しくなるため、適切なソリューションではありません。
- D.
- AWS Systems Managerはコストデータを直接扱うためのツールではありません。また、OpsCenterは運用イベントの管理が主な用途であり、CURを可視化するための機能はありません。
補足:
CURデータをQuickSightに統合する際は、Amazon S3バケットに保存されたCURデータをAthenaでクエリし、QuickSightにデータソースとして接続するのが一般的な方法です。この設定により、リアルタイムのコスト分析が可能となります。
035-AWS DataSync
理論
1. AWSのクラウドストレージオプション
AWSには、さまざまなストレージサービスがあり、それぞれ異なる使用ケースに最適化されています。主要なサービスには以下のようなものがあります。
- Amazon FSx: Windowsファイルシステム（Windows File Server）をクラウド上で提供するフルマネージドサービス。オンプレミスのWindowsファイルサーバーとの互換性があり、ファイル共有の移行や同期に最適です。
- Amazon Elastic File System (EFS): NFS（Network File System）プロトコルを使用するフルマネージドなファイルストレージ。Linuxベースのアプリケーションやコンテナ環境で使用されることが多いです。Windowsベースのファイルサーバーには不向きですが、Linuxやコンテナワークロードには適しています。
2. AWS DataSync
AWS DataSyncは、オンプレミスとAWS間でデータを迅速かつ効率的に移行するためのサービスです。大規模なデータ移行や定期的な同期に非常に有効です。主な特徴は以下の通りです。
- 自動化されたデータ転送: スケジュール機能を使って定期的にデータを移行または同期することができます。
- 効率的な帯域幅使用: 大量のデータを高速に転送し、帯域幅を効率的に使用します。
- データ整合性の保証: 転送中のデータの整合性を自動的にチェックします。
DataSyncは、ファイルシステム間の同期や移行に特化しており、WindowsファイルサーバーとFSxの組み合わせで特に効果を発揮します。
3. AWS Storage Gateway
AWS Storage Gatewayは、オンプレミスのストレージシステムとAWSクラウドストレージ（Amazon S3やFSxなど）を接続するためのサービスです。主に以下の3種類があります。
- File Gateway: オンプレミスのファイルシステムとAmazon S3を接続するゲートウェイ。ファイルベースのデータをS3にバックアップする際に使用されます。
- Volume Gateway: ブロックベースのストレージをAWSにバックアップするためのゲートウェイ。
- Tape Gateway: バーチャルテープライブラリ（VTL）として、バックアップデータをS3に保存します。
File Gatewayは、オンプレミスのファイルサーバーをAWSと連携させるために利用できますが、頻繁なデータ更新が求められる場合にはDataSyncの方が効果的です。
4. データ移行戦略
データ移行戦略では、以下のポイントを考慮する必要があります。
- データの移行頻度: 毎日のデータ生成がある場合、定期的な同期が可能なサービス（例：AWS DataSync）が最適です。
- データ量: 大量のデータを高速に移行するためのサービス選定が重要です。AWS DataSyncは帯域幅を効率的に使用し、大量データの移行を短時間で行えます。
- 互換性: オンプレミスのファイルシステムとクラウドのストレージの互換性を確認することが重要です。WindowsファイルシステムにはAmazon FSxが、LinuxベースのシステムにはEFSが適しています。
まとめ
AWSのデータ移行には、移行元と移行先のシステムに最適なストレージサービスと移行ツールを選ぶことが重要です。Windowsファイルサーバーからクラウドにデータを移行する場合、AWS DataSyncを利用して、Amazon FSxにデータを移行するのが最適なアプローチです。EFSはLinux向け、Storage Gatewayは主にバックアップやアーカイブ向けであり、特定のニーズに応じたサービス選定が求められます。
AWS Storage Gatewayは「オンプレミスのデータをクラウドにバックアップする」用途に最適であり、完全なファイルサーバーの置き換えには向かない
- AWS Storage Gatewayのファイルゲートウェイは、オンプレミス環境とクラウド間でファイルのバックアップを行うために使われますが、主にデータをAWSクラウドにバックアップまたはキャッシュするためのソリューションです。ファイルゲートウェイは、データの永続的な格納場所としてAmazon S3を使用しますが、完全なファイルサーバーの代替として利用するには不十分です。
- Windowsファイルサーバーと直接統合するためには、Windowsベースのファイルシステムのフル機能を提供するサービス（例：Amazon FSx for Windows File ServerやAmazon EFS）が適しています。
一問道場
質問 #35
トピック 1
ある会社がオンプレミスのWindowsファイルサーバーにデータを保存しています。この会社は毎日5 GBの新しいデータを生成しています。
この会社は一部のWindowsベースのワークロードをAWSに移行しており、そのデータをクラウドのファイルシステムで利用できるようにする必要があります。
この会社はすでにオンプレミスネットワークとAWSの間にAWS Direct Connect接続を確立しています。
この会社はどのデータ移行戦略を使用すべきでしょうか？
選択肢：
A. AWS Storage Gatewayのファイルゲートウェイオプションを使用して、
既存のWindowsファイルサーバーを置き換え、既存のファイル共有を新しいファイルゲートウェイにポイントする。
B. AWS DataSyncを使用して、オンプレミスのWindowsファイルサーバーとAmazon FSxの間でデータの複製を毎日スケジュールする。
C. AWS Data Pipelineを使用して、オンプレミスのWindowsファイルサーバーと
Amazon Elastic File System（Amazon EFS）の間でデータの複製を毎日スケジュールする。
D. AWS DataSyncを使用して、オンプレミスのWindowsファイルサーバーと
Amazon Elastic File System（Amazon EFS）の間でデータの複製を毎日スケジュールする。
この問題では、オンプレミスのWindowsファイルサーバーからAWSへのデータ移行方法を問われています。
- A: AWS Storage Gatewayのファイルゲートウェイを使用する方法ですが、頻繁なデータ移行には不向きです。
- B: 最適な選択肢。AWS DataSyncを使用して、オンプレミスのWindowsファイルサーバーとAmazon FSx間でデータを効率的に同期できます。
- C: AWS Data Pipelineは、データの移動には適していますが、ファイルシステム間の同期にはDataSyncの方が効果的です。
- D: EFSはWindows環境との互換性が低いため、FSxの方が適しています。
結論: Bが最適です。
036-CloudFront フェイルオーバー
理論
静的アセットとは、ウェブサイトやアプリケーションで使用される変更されない、または頻繁に変更されないファイルを指します。これらのファイルは、通常、ユーザーに提供されるコンテンツであり、動的な処理を伴わない、単純な形式のデータです。以下は、静的アセットの例です：
- 画像ファイル（JPEG、PNG、GIFなど）
- CSSファイル（スタイルシート）
- JavaScriptファイル
- フォントファイル
- HTMLファイル
- 動画ファイル（MP4など）
これらのファイルは通常、ウェブサーバーやCDN（コンテンツ配信ネットワーク）を通じて配信され、ウェブページの見た目やインタラクティブ性を提供します。静的アセットは、リクエストごとに変更されることなく、通常そのまま配信されます。
- クロスリージョンレプリケーション（Cross-Region Replication）：Amazon S3でクロスリージョンレプリケーション（CRR）を構成することで、
us-east-1のS3バケットから別のリージョンのS3バケットへオブジェクトを自動的にレプリケートできます。これにより、主リージョン（us-east-1）で障害が発生した場合でも、他のリージョンからデータをアクセスできるようになり、高可用性と災害復旧が確保されます。
- CloudFrontのオリジングループ（Origin Group）：CloudFrontでは、複数のS3バケットをオリジンとして設定することができます。CloudFrontは、利用可能なオリジンを自動的に選択します。例えば、1つのリージョンのS3バケットが利用できなくなった場合、CloudFrontは自動的に他のリージョンのS3バケットに切り替えます。これにより、ユーザーが静的コンテンツにアクセスする際に、障害時にも自動でフェイルオーバーが行われ、高可用性が向上します。
実践
参照元：
![[アップデート] CloudFrontのみでオリジンフェイルオーバーが出来るようになりました！ | DevelopersIO](https://www.notion.so/image/https%3A%2F%2Fdev.classmethod.jp%2Ffavicon.ico?table=block&id=1a8d7ae8-88e2-8000-b91f-e864f13abc78&t=1a8d7ae8-88e2-8000-b91f-e864f13abc78)
![[アップデート] CloudFrontのみでオリジンフェイルオーバーが出来るようになりました！ | DevelopersIO](https://www.notion.so/image/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_amazon-cloudfront_1200x630.jpeg?table=block&id=1a8d7ae8-88e2-8000-b91f-e864f13abc78&t=1a8d7ae8-88e2-8000-b91f-e864f13abc78)
以下は、オリジンアクセスアイデンティティ（OAI）を使用して、Amazon S3 オリジンを東京とオレゴンリージョンに構成するためのハンズオン記事のサンプルです。これにより、クロスリージョンレプリケーションを使用して、可用性の高い構成を実現します。
オリジンアクセスアイデンティティ（OAI）を使ったクロスリージョンS3オリジン構成のハンズオン
目標
本ハンズオンでは、AWSのオリジンアクセスアイデンティティ（OAI）を使用して、東京リージョンとオレゴンリージョンにS3オリジンを作成し、クロスリージョンレプリケーション（CRR）でコンテンツを同期します。これにより、片方のリージョンで障害が発生した場合でも、もう片方のリージョンからコンテンツを公開し続けることができます。
前提条件
- AWSアカウントがあること
- AWS管理コンソールにアクセスできること
- 東京リージョンとオレゴンリージョンにS3バケットを作成する権限があること
ステップ 1: 東京リージョンにS3バケットを作成
- AWS管理コンソールにログインし、東京リージョン（
ap-northeast-1）に移動します。
- 「S3」を選択し、「バケットを作成」ボタンをクリックします。
- バケット名を入力します（例:
my-content-bucket-tokyo）。
- 必要に応じて設定を調整し、「作成」をクリックします。
ステップ 2: オレゴンリージョンにS3バケットを作成
- オレゴンリージョン（
us-west-2）に移動します。
- 同様に、「S3」を選択し、「バケットを作成」ボタンをクリックします。
- バケット名を入力します（例:
my-content-bucket-oregon）。
- 必要に応じて設定を調整し、「作成」をクリックします。
ステップ 3: クロスリージョンレプリケーション（CRR）の設定
- 東京リージョンのS3バケットに移動し、「管理」タブを選択します。
- 「レプリケーションルール」を設定します。
- 「レプリケーション元バケット」として東京リージョンのバケットを選択し、レプリケーション先バケットとしてオレゴンリージョンのバケットを選択します。
- 必要な設定（オブジェクトのコピーなど）を選択し、レプリケーションを有効にします。
ステップ 4: CloudFrontディストリビューションの作成
- 東京リージョンのS3バケットに対して、CloudFrontディストリビューションを作成します。
- オリジンタイプとして「S3」を選択し、オリジンアクセスアイデンティティ（OAI）を選択します。
- これにより、東京リージョンのS3バケットのコンテンツがCloudFrontを通じて公開されます。
- オリジングループを作成、オレゴンリージョンのS3バケットもCloudFrontのオリジンとして追加することができます。
ステップ 5: レプリケーションの確認
- 東京リージョンのS3バケットにファイルをアップロードします。
- オレゴンリージョンのS3バケットにも自動的にレプリケーションされていることを確認します。
- CloudFront経由でコンテンツが両リージョンから配信されているか、URLで確認します。
ステップ 6: フェイルオーバーのテスト
- 東京リージョンで問題が発生した場合、オレゴンリージョンのS3バケットからコンテンツが引き続き配信されることを確認します。
- CloudFrontのオリジンを切り替える設定が行われていれば、オレゴンリージョンのコンテンツが自動的に配信されます。
まとめ
このハンズオンで、オリジンアクセスアイデンティティ（OAI）を使ったS3オリジン構成を東京とオレゴンリージョンに作成し、クロスリージョンレプリケーションを使用してコンテンツの可用性を高めました。障害発生時には、もう片方のリージョンからコンテンツが継続的に公開される構成が実現できました。
一問道場
問題 36
トピック 1
ある企業のソリューションアーキテクトが、AWS 上で実行されているウェブアプリケーションを確認しています。このアプリケーションは、us-east-1 リージョンにある Amazon S3 バケット内の静的アセットを参照しています。企業は、複数の AWS リージョン間でのレジリエンシー（回復力）を必要としています。企業はすでに、別のリージョンに S3 バケットを作成しています。
最小限の運用オーバーヘッドでこの要件を満たすソリューションはどれですか？
A.
アプリケーションを構成して、各オブジェクトを両方の S3 バケットに書き込むようにします。
Amazon Route 53 のパブリックホストゾーンを設定し、S3 バケットごとに加重ルーティングポリシーを使用したレコードセットを作成します。
アプリケーションを構成して、Route 53 の DNS 名を使用してオブジェクトを参照します。
B.
AWS Lambda 関数を作成して、us-east-1 の S3 バケットから別のリージョンの S3 バケットにオブジェクトをコピーします。
us-east-1 の S3 バケットにオブジェクトが書き込まれるたびに Lambda 関数を呼び出します。
2 つの S3 バケットをオリジンとして含む Amazon CloudFront のオリジングループを設定します。
C.
us-east-1 の S3 バケットでレプリケーションを構成し、オブジェクトを別のリージョンの S3 バケットにレプリケートします。
2 つの S3 バケットをオリジンとして含む Amazon CloudFront のオリジングループを設定します。
D.
us-east-1 の S3 バケットでレプリケーションを構成し、オブジェクトを別のリージョンの S3 バケットにレプリケートします。
フェイルオーバーが必要な場合、アプリケーションコードを更新して、別のリージョンの S3 バケットからオブジェクトをロードするようにします。
解説
この問題では、AWS 上で複数リージョン間でのレジリエンシーを確保する方法を問うています。
各選択肢の解説：
- A: 静的アセットを手動で両方の S3 バケットに書き込み、DNS でルーティングする方法は運用負担が大きく、最適ではありません。
- B: Lambda でオブジェクトをコピーする方法は複雑でスケーラビリティに欠けます。
- C (正解): クロスリージョンレプリケーションを使い、CloudFront のオリジングループを設定することで、レジリエンシーを確保し、運用負担を最小限にできます。
- D: レプリケーション後にアプリケーションコードを変更する必要があり、手動の介入が増えて運用が複雑になります。
結論:
最適な解決策は C の方法です。
037-スケーラブル
理論
1. スケーラビリティ
- Auto Scaling: 自動的にインスタンスを増減させることで、トラフィックの増減に対応します。これにより、必要なリソースが常に最適に確保され、コストの無駄も防げます。
- Aurora MySQL: 従来のMySQLよりも高いスケーラビリティを提供し、データベースの負荷に対する対応力が高いです。特に読み取り専用のリードレプリカや、複数のアベイラビリティゾーンへのデプロイが可能です。
2. 高可用性
- マルチAZ配置: インスタンスを複数のアベイラビリティゾーンに配置することで、1つのゾーンに障害が発生してもシステム全体の稼働を維持できます。これにより、サービスの中断を防ぎ、ビジネスの継続性を確保します。
- RDS MySQLのMulti-AZ: Amazon RDSでは、データベースの高可用性を確保するためにマルチAZ配置をサポートしており、障害時のフェイルオーバーも自動で行います。
3. 信頼性と再現性
- CloudFormation: インフラをコードとして定義することで、環境の再現性を保つことができます。これにより、インフラの設定や変更を管理しやすくなり、エラーのリスクを減らします。
- Elastic Load Balancing (ALB/NLB): ALB（Application Load Balancer）はHTTP/HTTPSトラフィックに最適で、アプリケーションの負荷分散を効率的に行います。NLB（Network Load Balancer）は、より高いスループットが必要なトラフィックに向いています。
結論
AWSにおけるスケーラビリティと高可用性を確保するためには、Auto Scaling、マルチAZ配置、そしてRDS Aurora MySQLの利用が鍵です。また、CloudFormationを使用したインフラのコード化は、運用の効率性と信頼性を高めます。
実践
略
一問道場
質問 #37
トピック 1
ある企業がオンプレミス環境で三層構造のウェブアプリケーションをホストしています。
最近のトラフィック急増によりダウンタイムが発生し、重大な財務的影響を受けたため、会社の経営陣はこのアプリケーションをAWSに移行するよう指示しました。
アプリケーションは.NETで開発されており、MySQLデータベースに依存しています。
ソリューションアーキテクトは、1日20万ユーザーの需要を満たすため、スケーラブルで高可用性のソリューションを設計する必要があります。
ソリューションアーキテクトは、適切なソリューションを設計するためにどの手順を取るべきでしょうか？
選択肢
A.
- AWS Elastic Beanstalkを使用して新しいアプリケーションを作成し、ウェブサーバー環境とAmazon RDS MySQLのマルチAZ DBインスタンスを設定する。
- 環境には、複数のアベイラビリティゾーンにまたがるAmazon EC2 Auto Scalingグループの前にNetwork Load Balancer (NLB)を起動する。
- Amazon Route 53のエイリアスレコードを使用して、会社のドメインからNLBにトラフィックをルーティングする。
B.
- AWS CloudFormationを使用してスタックを作成する。
- スタックは、3つのアベイラビリティゾーンにまたがるAmazon EC2 Auto Scalingグループの前にApplication Load Balancer (ALB)を起動する。
- Amazon Aurora MySQL DBクラスターのマルチAZデプロイメントと削除保持ポリシーを設定する。
- Amazon Route 53のエイリアスレコードを使用して、会社のドメインからALBにトラフィックをルーティングする。
C.
- AWS Elastic Beanstalkを使用して、2つの異なるリージョンにまたがる自動スケーリングのウェブサーバー環境を作成する。
- 各リージョンにApplication Load Balancer (ALB)を配置する。
- クロスリージョンのリードレプリカを持つAmazon Aurora MySQL DBクラスターのマルチAZデプロイメントを作成する。
- Amazon Route 53のジオプロキシミティルーティングポリシーを使用して、2つのリージョン間でトラフィックをルーティングする。
D.
- AWS CloudFormationを使用してスタックを作成する。
- スタックは、3つのアベイラビリティゾーンにまたがるSpotインスタンスのAmazon ECSクラスターの前にApplication Load Balancer (ALB)を起動する。
- スナップショット削除ポリシーを持つAmazon RDS MySQL DBインスタンスを起動する。
- Amazon Route 53のエイリアスレコードを使用して、会社のドメインからALBにトラフィックをルーティングする。
解説
正解：B
理由:
- スケーラブル:
Aurora MySQLは高いスケーラビリティを持ち、20万ユーザーのトラフィックに対応可能。
- 高可用性:
ALBと3つのアベイラビリティゾーンにまたがるAuto Scalingグループで高い可用性を実現。
- 信頼性:
CloudFormationでインフラ構成をコード化し、再現性のある環境を構築。
他の選択肢:
- A: NLBではHTTP/HTTPSの詳細なルーティングが不足。
- C: 複雑すぎる構成で、要件を超える。
- D: Spotインスタンスは中断リスクがあり、高可用性を保証できない。
Bは必要な要件を全て満たし、最適な選択肢です。
038-CloudFormation StackSets
理論
AWS CloudFormation StackSets と AWS Organizations の基本的な理解
1. AWS Organizations
AWS Organizations は、複数のAWSアカウントをまとめて管理するサービスです。これを使うと、アカウントのグループ化、ポリシーの適用、請求の管理などが一元化できます。例えば、セキュリティやコスト管理を全アカウントにわたって統一的に行うことができます。
2. CloudFormation と StackSets
- AWS CloudFormation: AWSのインフラをコードとして管理できるサービスで、テンプレートを使ってAWSリソース（サーバー、データベースなど）を自動で作成・管理できます。
- StackSets: CloudFormationの機能で、複数のアカウントやリージョンに対して同じ設定を自動で適用できる仕組みです。これにより、広範囲にわたってリソースを一度に管理できます。
3. サービス管理型権限とセルフサービス型権限
- サービス管理型権限: AWS Organizationsの管理アカウントが、メンバーアカウントに対してCloudFormationのスタックを一元的にデプロイできる権限です。この方法は、組織全体で統一された管理ができます。
- セルフサービス型権限: メンバーアカウントの管理者が自分でスタックを作成・管理できる権限です。これは、中央管理が必要ない場合に使用されます。
4. 自動デプロイとドリフト検出
- 自動デプロイ: スタックセットを使って、変更を自動で各アカウントに反映させる設定です。手動での操作が不要で、迅速な展開が可能です。
- ドリフト検出: スタックの設定が変更されていないか確認する機能です。リソースが意図しない変更を受けた場合に、これを検出して修正することができます。
5. デプロイオプション
- 組織にデプロイ: StackSetsを使って、AWS Organizations内のすべてのアカウントに同じリソースを一度にデプロイできます。これにより、組織全体で統一されたインフラ管理ができます。
まとめ
AWS CloudFormation StackSets と AWS Organizations を組み合わせることで、複数のAWSアカウントに対して同じリソース構成を一貫してデプロイでき、効率的な運用が可能になります。特に、サービス管理型権限を使うことで、中央管理が可能となり、自動デプロイやドリフト検出を活用することで信頼性の高い管理ができます。
一問道場
質問 #38
ある企業は、AWS Organizationsを使用して複数のAWSアカウントを管理しています。セキュリティの目的で、企業はすべてのOrganizationsメンバーアカウントでサードパーティのアラートシステムと統合できるAmazon Simple Notification Service（Amazon SNS）トピックの作成を要求しています。
ソリューションアーキテクトは、AWS CloudFormationテンプレートを使用してSNSトピックを作成し、CloudFormation StackSetsを使用してCloudFormationスタックのデプロイを自動化しました。Trusted accessはOrganizationsで有効になっています。
ソリューションアーキテクトは、すべてのAWSアカウントにCloudFormation StackSetsをデプロイするために何をすべきでしょうか？
選択肢:
A. Organizationsメンバーアカウントにスタックセットを作成します。
- サービス管理型の権限を使用します。
- デプロイオプションを「組織にデプロイ」に設定します。
- CloudFormation StackSetsのドリフト検出を有効にします。
B. Organizationsメンバーアカウントにスタックを作成します。
- セルフサービス型の権限を使用します。
- デプロイオプションを「組織にデプロイ」に設定します。
- CloudFormation StackSetsの自動デプロイを有効にします。
C. Organizationsの管理アカウントにスタックセットを作成します。
- サービス管理型の権限を使用します。
- デプロイオプションを「組織にデプロイ」に設定します。
- CloudFormation StackSetsの自動デプロイを有効にします。
D. Organizationsの管理アカウントにスタックを作成します。
- サービス管理型の権限を使用します。
- デプロイオプションを「組織にデプロイ」に設定します。
- CloudFormation StackSetsのドリフト検出を有効にします。
解説
この問題は、AWS CloudFormation StackSetsとAWS Organizationsを使って、複数のAWSアカウントにSNSトピックをデプロイする方法に関するものです。適切な手順は、管理アカウントでStackSetを作成し、サービス管理型権限を使用して、組織全体に自動デプロイすることです。
各選択肢の解説
- A: ドリフト検出を使用すると、デプロイ後に設定が変更されていないかチェックできますが、この問題には必須ではありません。
- B: セルフサービス型権限を使用する方法。これはメンバーアカウントに個別管理を任せる方法で、管理が分散するため不適切です。不正解。
- C: 管理アカウントでサービス管理型権限を使い、自動デプロイを有効にする方法。正解です。
- D: ドリフト検出を使う方法。これは必須ではなく、StackSetsを使うべきです。不正解。
正解
Cが最適です。
039-移行作業
理論
オンプレミスからAWSへの移行は、企業にとって大きな転換点です。正しい計画と適切なツールの使用が、スムーズでコスト効率の高い移行を実現するために不可欠です。以下に、移行に関連する本質的な知識と重要なAWSのツールについて詳述します。
1. AWS Application Discovery Service
AWSのApplication Discovery Serviceは、オンプレミス環境をAWSに移行する際に最も重要なツールの一つです。このサービスは、オンプレミスのワークロードに関する詳細な情報を収集し、移行のための計画をサポートします。
- システム構成の把握: オンプレミスのサーバーやアプリケーションの構成（OS、インストールされているソフトウェア、依存関係など）を把握します。
- パフォーマンスとネットワーク情報: サーバーやアプリケーションのパフォーマンス、稼働しているプロセス、ネットワーク接続の情報を収集し、移行後のシステム設計に役立てます。
- エージェントの使用: Application Discovery Agentを物理マシンや仮想マシンにインストールして、これらのデータを自動的に収集します。
2. AWS Migration Hub
AWS Migration Hubは、複数のAWSサービスを使った移行作業を管理し、追跡するための中心的なツールです。
- 移行の進捗管理: 複数の移行対象を追跡し、進捗状況を管理します。
- アプリケーションのグループ化: さまざまなサーバーやアプリケーションをグループ化し、それらの移行計画を効率化します。これにより、依存関係が明確になり、スムーズな移行が可能になります。
- インスタンスタイプの推奨: 移行後の最適なEC2インスタンスタイプの推奨を提供し、コスト効率の良いインフラ設計をサポートします。
3. AWS EC2インスタンスタイプの選定
移行後に最も重要なのは、最適なEC2インスタンスタイプを選定することです。アプリケーションに必要なリソースを正確に評価し、コストを最適化するために最適なインスタンスを選ぶことが求められます。
- インスタンスサイズ: CPU、メモリ、ストレージなど、アプリケーションに必要なリソースを基にインスタンスタイプを決定します。
- コスト効率: 使用するインスタンスのコストを考慮し、最適なバランスを取ることが重要です。移行計画の初期段階で推奨インスタンスを得ることができれば、コスト削減に役立ちます。
4. AWS移行ツールの利用
AWSには移行を支援するツールがいくつかあります。これらをうまく組み合わせることで、移行の複雑さを管理し、ダウンタイムを最小限に抑えながら移行を進めることができます。
- AWS Server Migration Service (SMS): オンプレミスの仮想マシンをAWSへ移行するための自動化ツールです。ダウンタイムを最小限に抑え、スムーズな移行を支援します。
- AWS Database Migration Service (DMS): オンプレミスのデータベースをAWSに移行するためのツールです。データベース間の互換性を確保し、リアルタイムでデータの移行を実施できます。
5. 移行計画と評価
移行計画の作成は、移行の成功に直結します。まず、現在のインフラとアプリケーションの評価を行い、AWSでの最適な設計を検討します。
- 移行対象の選定: すべてのアプリケーションが一度に移行されるわけではありません。優先順位をつけ、段階的に移行を進めます。
- 移行後の運用準備: 移行後の運用に備え、監視、バックアップ、セキュリティ、スケーリングの計画も考慮する必要があります。
まとめ
AWSへの移行は、単なるインフラの移行ではなく、ビジネスプロセスやアプリケーションの最適化を含んだ重要なプロジェクトです。Application Discovery Serviceでデータを収集し、Migration Hubで計画を管理、最適なEC2インスタンスタイプを選ぶことで、移行後のコスト効率とパフォーマンスを最大化できます。これらのツールを駆使して、オンプレミスからAWSへのスムーズで効率的な移行を実現しましょう。
実践
略
一問道場
問題 #39
トピック 1
ある企業がオンプレミスからAWSへのワークロード移行を検討しています。ワークロードはLinuxおよびWindowsで実行されています。企業には、物理マシンとVMを含む大規模なオンプレミスインフラがあり、そこでは多数のアプリケーションがホストされています。企業は、オンプレミスワークロードのシステム構成、システムパフォーマンス、実行中のプロセス、ネットワーク接続の詳細をキャプチャする必要があります。また、オンプレミスのアプリケーションをAWSへの移行のためにグループ化する必要もあります。企業は、AWSでワークロードを最もコスト効率よく実行するためのAmazon EC2インスタンスタイプの推奨も必要としています。
これらの要件を満たすために、ソリューションアーキテクトはどの手順を取るべきですか？（3つ選んでください。）
選択肢:
A. 物理マシンおよびVMにAWS Application Discovery Agentをインストールして、既存のアプリケーションを評価する。
B. 物理マシンおよびVMにAWS Systems Manager Agentをインストールして、既存のアプリケーションを評価する。
C. AWS Systems Manager Application Managerを使用して、移行するためにサーバーをアプリケーションにグループ化する。
D. AWS Migration Hubを使用して、移行するためにサーバーをアプリケーションにグループ化する。
E. AWS Migration Hubを使用して、推奨インスタンスタイプと関連するコストを生成する。
F. サーバーサイズに関するデータをAWS Trusted Advisorにインポートし、コスト最適化のための推奨をフォローする。
解説
この問題では、オンプレミスのワークロードをAWSに移行するためのステップを考える必要があります。具体的には、オンプレミスのアプリケーションの評価、移行計画、そしてEC2インスタンスタイプの推奨を行うために必要な手順について問われています。問題を解くために重要なポイントを順を追って解説します。
要件：
- システム情報の収集: オンプレミスのシステム構成、パフォーマンス、プロセス、ネットワーク接続に関するデータをキャプチャする必要があります。
- アプリケーションのグループ化: オンプレミスのアプリケーションをグループ化し、AWSに移行する準備を整えます。
- コスト効率のよいEC2インスタンスタイプの推奨: AWSにワークロードを移行するために、最適なインスタンスタイプとコストを推奨する必要があります。
解説：
選択肢：
- A: Application Discovery Agentをインストールして既存のアプリケーションを評価
- これは正しい選択肢です。AWS Application Discovery Serviceは、オンプレミス環境で実行されているアプリケーションの詳細なデータ（システム構成、パフォーマンス、ネットワーク接続など）を収集するために使用されます。エージェントを物理マシンやVMにインストールすることで、AWSに移行する前の情報収集が可能となります。
- B: Systems Manager Agentをインストールして既存のアプリケーションを評価
- これは適切ではありません。AWS Systems Manager Agent（SSM Agent）は、AWSリソースの管理や運用に使用されますが、Application Discovery Agentのようにオンプレミスのシステムのパフォーマンスや構成を直接収集することには使いません。
- C: Systems Manager Application Managerでアプリケーションをグループ化
- AWS Systems Manager Application Managerは、アプリケーションの運用管理に関するツールですが、移行に向けてのグループ化を行うためには、AWS Migration Hubを使うほうが適切です。したがって、この選択肢は不適切です。
- D: AWS Migration Hubでアプリケーションをグループ化
- これは正しい選択肢です。AWS Migration Hubを使用することで、オンプレミスのサーバーやアプリケーションを移行するためにグループ化することができます。Migration Hubは、移行の進捗状況を追跡し、移行対象をグループ化するために有効です。
- E: Migration Hubでインスタンスタイプとコストを推奨
- これは正しい選択肢です。AWS Migration Hubは、移行対象のワークロードに最適なEC2インスタンスタイプの推奨を提供します。また、コストの見積もりも行えるため、移行後の最適なインフラ設計をサポートします。
- F: Trusted Advisorにデータをインポートし、コスト最適化の推奨をフォロー
- これは適切ではありません。AWS Trusted Advisorは、既存のAWSリソースに対してコスト最適化のアドバイスを提供しますが、オンプレミスのデータをインポートして推奨を得ることはできません。移行前にはApplication Discovery AgentやMigration Hubを使う方が適切です。
正解：
- A, D, E が正しい選択肢です。
結論：
- オンプレミスの環境をAWSに移行する際は、まずは AWS Application Discovery Agent を使用してシステム情報を収集し、その後 AWS Migration Hub を利用してアプリケーションをグループ化、移行対象を追跡します。また、 Migration Hub は、移行後の最適なインスタンスタイプとコストの見積もりも提供するため、コスト効率を考えたインスタンス選定に役立ちます。
040-S3 VPCエンドポイント
理論
この問題に関連する本質的な知識は、AWSアーキテクチャ、特にネットワーク設計やコスト最適化の観点から、NATゲートウェイ、VPCエンドポイント、そしてAmazon EC2とS3の効率的な利用方法についての理解が必要です。これらのコンポーネントは、AWS上でのセキュリティ、パフォーマンス、コスト管理を最適化するために重要な役割を果たします。
1. VPC設計の基本概念
AWSのVirtual Private Cloud (VPC)は、インターネットから隔離された仮想的なネットワーク環境を提供します。このVPC内には、複数のサブネット（Public SubnetやPrivate Subnet）を作成することができ、それぞれ異なるセキュリティ要件やアクセスルールに応じて設計できます。
- Public Subnet: インターネットにアクセス可能なリソース（例：Application Load BalancerやNAT Gateway）が配置されるサブネット。
- Private Subnet: インターネットへのアクセスを制限したリソース（例：EC2インスタンス）が配置されるサブネット。
2. NATゲートウェイとNATインスタンス
- NATゲートウェイは、プライベートサブネット内のEC2インスタンスがインターネットにアクセスできるようにするAWSの完全にマネージドなサービスです。高可用性を提供し、スケーリングの管理が不要です。しかし、NATゲートウェイにはコストがかかるため、トラフィック量が多くなるとコストが増加します。
- NATインスタンスは、EC2インスタンスを利用してNAT機能を提供する方法で、コストを抑えるために使用できますが、管理とスケーリングが手動で必要です。
3. VPCエンドポイント（S3ゲートウェイエンドポイント）
- VPCエンドポイントは、VPC内のリソース（例えばEC2インスタンス）がインターネットを経由せずにAWSのサービス（S3、DynamoDBなど）にアクセスできるようにするためのAWSサービスです。インターネット経由のトラフィックを削減できるため、セキュリティとコスト効率を向上させます。
- S3ゲートウェイエンドポイントは、特にS3へのアクセスに使用されます。これにより、EC2インスタンスがインターネットを経由せずにS3からデータを取得できるため、データ転送が高速化され、コストも削減されます。
4. S3のデータ転送とコスト最適化
- Amazon S3は高い耐久性と可用性を提供するオブジェクトストレージサービスで、大量のデータを格納するのに最適です。EC2インスタンスが頻繁にS3から大量のデータ（1TBなど）を取得する場合、インターネット経由でのデータ転送はコストがかかり、遅延の原因となることがあります。
- VPCエンドポイントを利用することで、S3のデータ転送がインターネットを経由しないため、コストを削減し、データ転送のパフォーマンスが向上します。
5. コスト最適化とセキュリティ
- NATゲートウェイのコスト: NATゲートウェイの料金は、データ転送量や使用時間に基づいて課金されます。頻繁にインターネットにアクセスするアプリケーションでは、コストがかさむ可能性があります。これに対して、NATインスタンスを使用することで、コストを抑えることができますが、管理負担が増える可能性があります。
- VPCエンドポイントの利用: S3などのAWSサービスにアクセスする際、インターネット経由でなくVPCエンドポイントを使用することで、データ転送コストを削減できます。インターネットトラフィックを減らすことで、セキュリティも向上し、アクセス経路がより制御可能になります。
- セキュリティ: VPCエンドポイントはインターネットを経由しないため、セキュリティが向上します。また、VPCエンドポイントにポリシーを設定して、特定のS3バケットや操作に対するアクセスを制限することができます。
6. 推奨アーキテクチャ
- S3ゲートウェイエンドポイントを使用したアーキテクチャ:
- EC2インスタンスがS3にアクセスする際にVPCエンドポイントを使用することで、インターネットを経由せず、安全でコスト効率的にデータを転送できます。
- NATゲートウェイは、インターネットアクセスが必要な場合に使用し、コスト削減のためにその利用を最適化します。
- EC2インスタンスをプライベートサブネットに配置し、VPCエンドポイントを使用: これにより、データ転送の効率化とコスト削減が図れ、セキュリティも強化されます。
実践
略
一問道場
問題 #40
ある企業は、AWS上のVPCで画像処理サービスをホスティングしています。このVPCは2つのアベイラビリティゾーンに跨っています。各アベイラビリティゾーンには1つのパブリックサブネットと1つのプライベートサブネットがあります。サービスは、プライベートサブネット内のAmazon EC2インスタンスで実行されています。パブリックサブネット内にあるアプリケーションロードバランサーがサービスの前に配置されています。サービスはインターネットと通信する必要があり、2つのNATゲートウェイを通じて通信しています。サービスは画像の保存にAmazon S3を使用しています。EC2インスタンスは毎日約1TBのデータをS3バケットから取得します。企業はこのサービスを非常にセキュアであると宣伝しています。ソリューションアーキテクトは、サービスのセキュリティポスチャーを損なうことなく、運用時間を増加させることなく、可能な限りクラウドの支出を削減する必要があります。
どのソリューションがこの要件を満たすでしょうか？
- A. NATゲートウェイをNATインスタンスに置き換えます。VPCのルートテーブルで、プライベートサブネットからNATインスタンスへのルートを作成します。
- B. EC2インスタンスをパブリックサブネットに移動します。NATゲートウェイを削除します。
- C. S3ゲートウェイVPCエンドポイントをVPCに設定し、エンドポイントポリシーをエンドポイントにアタッチして、S3バケットに必要なアクションを許可します。
- D. Amazon Elastic File System（Amazon EFS）ボリュームをEC2インスタンスにアタッチし、EFSボリュームに画像をホストします。
解説
正解は C. です。
理由:
- C. S3ゲートウェイVPCエンドポイントをVPCに設定し、エンドポイントポリシーをエンドポイントにアタッチして、S3バケットに必要なアクションを許可します。
この解決策は、EC2インスタンスがインターネットを経由せずに直接Amazon S3と通信できるようにするため、セキュリティが高く、運用コストが削減されます。S3ゲートウェイVPCエンドポイントを使用すると、インターネット経由でのトラフィックを避け、VPC内で直接S3と通信できるようになります。これにより、NATゲートウェイを必要とせず、コストの削減が可能となります。また、エンドポイントポリシーを使用して、S3バケットに対するアクセス制御を行い、セキュリティも保たれます。
他の選択肢について:
- A. NATゲートウェイをNATインスタンスに置き換えることでコスト削減は可能ですが、NATインスタンスの管理が必要になり、可用性や運用の複雑さが増します。S3の直接通信には不向きです。
- B. EC2インスタンスをパブリックサブネットに移動することでインターネットアクセスは可能になりますが、セキュリティが低下します。また、NATゲートウェイを削除することは、他のセキュリティやアクセス要件に影響を与える可能性があります。
- D. Amazon EFSを使用して画像をホストすることは可能ですが、EFSはファイルシステムであり、S3とは異なり、画像データの大規模なストレージにおいてコストが高くなる可能性があります。S3の方が適切な選択です。
- 作者:みなみ
- 链接:https://www.minami.ac.cn//%E8%B3%87%E6%A0%BC%E5%8B%89%E5%BC%B7/165d7ae8-88e2-8078-a7e7-dde3e04da67d
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
