type
status
date
slug
summary
tags
category
icon
password
271-AWS SAP AWS 「理論・実践・一問道場」GraphQL API
理論
GraphQL API と REST API の違いについて、あなたの理解を整理します。
1. GraphQL API
- 目的: アプリケーションとバックエンド間のデータやり取りを効率的に行うためのAPIです。
- 特徴:
- クエリベース: クライアントは必要なデータを正確に指定できる。例えば、特定のフィールド（例: ユーザー名やメールアドレス）のみを取得できる。
- 1つのエンドポイントで複数のリソースにアクセスできる。RESTのように複数のURLを使う必要がない。
- 効率的なデータ取得: クライアントが欲しいデータのみを取得できるため、不要なデータの転送が少なく、ネットワーク負荷が軽減される。
2. REST API
- 目的: エンドユーザーとアプリケーション間、またはアプリケーションの異なるサービス間でデータやり取りを行うAPIです。
- 特徴:
- リソース指向: 各リソース（例: ユーザー、商品）に対して個別のエンドポイント（URL）を設け、HTTPメソッド（GET, POST, PUT, DELETE）で操作を行う。
- 冗長なデータ転送: クライアントが取得するデータは、通常、固定の形式でレスポンスとして返され、クライアントが必要でないデータまで含まれる場合が多い。
- 複数のエンドポイント: 各リソースごとにURLが分かれているため、異なるリソースの取得に対して複数のリクエストを送る必要がある場合も。
まとめ:
- GraphQL APIは主にアプリケーションとバックエンド間で、クライアントが必要なデータを自由に指定し取得するために使われます。
- REST APIは、エンドユーザーとアプリケーション、またはアプリケーション間で、リソースに対する操作をHTTPメソッドを通じて行うためのものです。
このように、GraphQLはデータの取得や操作において、より柔軟で効率的なやり取りを提供するのに対して、RESTはリソースベースのアーキテクチャを用いています。
SQSロングポーリングとは、Amazon SQS (Simple Queue Service) のキューにメッセージが来るまで、ずっと待ってくれる機能です。
通常、SQSは「ポーリング」という方法でメッセージをチェックします。ショートポーリングは、メッセージがない場合にすぐに「何もないよ！」と返事が返ってきます。しかし、ロングポーリングでは、メッセージが来るまで、最大20秒間待ってくれます。そのため、無駄なチェックが減って効率が良く、リソースやコストの節約にもなります。
例を使った説明：
例えば、レストランで注文を受け付けるシステムを考えましょう。注文が来るたびに料理を作るとします。
- ショートポーリング：シェフは「注文あるかな？」と1秒ごとにチェックして、もし注文がなければ「まだない」と言って休憩します。
- ロングポーリング：シェフは「注文来るまで待つよ！」と決めて、注文が来るまでずっと待っています。注文が来たら、すぐに料理を始めます。
ロングポーリングを使うことで、シェフ（システム）は無駄に待機して無駄な労力を使わず、効率よく仕事を進められます。
DLQとは
注文失敗の保持には、より明確に Dead Letter Queue (DLQ) を使うべきで、SQSロングポーリングを使用して失敗した注文を保持するという方法は直感的ではなく、混乱を招く可能性があります。
AWS AppSyncは、フルマネージドなサービスで、GraphQL APIを作成、管理、運用するためのツールです。GraphQLは、アプリケーションとサーバー間でデータをやり取りするためのクエリ言語で、クライアントが必要なデータだけを取得できるように設計されています。
AWS AppSyncの主な特徴：
- リアルタイムデータ更新：
- AWS AppSyncは、リアルタイムのデータ更新機能を提供します。これにより、アプリケーションがサーバーからの変更を即座に受け取って更新することができます。例えば、チャットアプリやライブデータストリーミングなど、リアルタイムでの情報交換が必要なアプリケーションに最適です。
- データソースの統合：
- AWS AppSyncは、Amazon DynamoDB、Amazon Elasticsearch、AWS Lambda、Amazon RDS など、さまざまなバックエンドデータソースに接続することができます。これにより、異なるデータストアからデータを集約し、シームレスにクエリを実行することができます。
- オフライン機能：
- AWS AppSyncは、モバイルやウェブアプリケーションのオフライン機能をサポートしており、ネットワーク接続が失われても、データの変更や同期が可能です。ネットワークが復旧すると、ローカルで行われた変更を自動的にサーバーと同期します。
- セキュリティと認証：
- Amazon CognitoやIAMを使って、ユーザー認証とアクセス制御を簡単に設定できます。これにより、特定のユーザーにのみアクセスを許可したり、データのセキュリティを強化できます。
例：
例えば、ECサイトで商品を表示するアプリケーションがあるとしましょう。GraphQLを使うと、クライアントは「価格だけ」「レビューだけ」「在庫数だけ」など、必要な情報だけをリクエストできます。AppSyncを使うと、これらのデータを異なるデータソース（例えばDynamoDBに保存された商品情報）から効率的に取得し、またリアルタイムで価格更新や在庫変動を即座に反映することができます。
AWS AppSyncを使うことで、データの取得が効率的になり、アプリケーションのパフォーマンスとスケーラビリティが向上します。
実践
略
一問道場
問題 #271
トピック 1
ある企業が、小売注文用のWebアプリケーションを再設計したいと考えています。このアプリケーションは現在、ロードバランサーで負荷分散されたAmazon EC2インスタンスのフリートを使用して、以下の役割を果たしています：
- Webホスティング
- データベースAPIサービス
- ビジネスロジック
企業は、疎結合でスケーラブルなアーキテクチャを構築し、失敗した注文を保持する仕組みを提供しつつ、運用コストを最小限に抑える必要があります。
どのソリューションがこれらの要件を満たすでしょうか？
A.
- Amazon S3 をWebホスティングに使用
- Amazon API Gateway をデータベースAPIサービスに使用
- Amazon Simple Queue Service（Amazon SQS）を注文キューとして使用
- Amazon Elastic Container Service（Amazon ECS）をビジネスロジックに使用し、失敗した注文の保持にAmazon SQSのロングポーリングを活用
B.
- AWS Elastic Beanstalk をWebホスティングに使用
- Amazon API Gateway をデータベースAPIサービスに使用
- Amazon MQ を注文キューとして使用
- AWS Step Functions をビジネスロジックに使用し、失敗した注文の保持にAmazon S3 Glacier Deep Archive を活用
C.
- Amazon S3 をWebホスティングに使用
- AWS AppSync をデータベースAPIサービスに使用
- Amazon Simple Queue Service（Amazon SQS）を注文キューとして使用
- AWS Lambda をビジネスロジックに使用し、失敗した注文の保持にAmazon SQSのデッドレタキューを活用
D.
- Amazon Lightsail をWebホスティングに使用
- AWS AppSync をデータベースAPIサービスに使用
- Amazon Simple Email Service（Amazon SES）を注文キューとして使用
- Amazon Elastic Kubernetes Service（Amazon EKS）をビジネスロジックに使用し、失敗した注文の保持にAmazon OpenSearch Service を活用
解説
この問題では、ウェブアプリケーションのアーキテクチャをスケーラブルかつデカップルし、注文の失敗を保持しつつ運用コストを最小限に抑える方法を求めています。正解はCです。
Cの選択肢は以下の理由で適切です：
- Amazon S3をウェブホスティングに使用し、静的なウェブサイトを効率的に提供できます。
- AWS AppSyncはGraphQL APIを利用して、データベースAPIサービスを効率的に提供します。
- Amazon SQSを使って注文をキューイングし、非同期処理を可能にします。
- AWS Lambdaはサーバーレスでビジネスロジックを処理し、失敗した注文を保持するためのSQS dead-letter queueを活用できます。
他の選択肢は、要件に対して適切でない技術スタックや構成を含んでいるため、選択肢Cが最もコスト効率が良く、要求を満たす解決策です。
272-AWS SAP AWS 「理論・実践・一問道場」Amazon Aurora Global Database
理論
クロスリージョン災害復旧とデータベースの高可用性
1. RTO（復旧時間目標）とRPO（復旧点目標）
- RTOは、システムが障害から復旧するまでにかかる最大時間を示します。
- RPOは、障害発生時に失われる可能性のある最大データ量（時間）を示します。
例えば、RTOが5分未満、RPOが1分未満という要件では、災害が発生しても、5分以内にシステムを復旧させ、1分以内にデータを失わない設計が求められます。
2. Amazon Aurora Global Database
- Amazon Aurora Global Databaseは、複数のリージョン間でデータを同期させ、クロスリージョンでの高可用性と災害復旧を提供します。
- Aurora Global Databaseは、データを各リージョンでリアルタイムに複製するため、RPOが1分未満、RTOが5分未満の要件を満たすことができます。
- プライマリリージョンがダウンしても、セカンダリリージョンに瞬時にフェイルオーバーでき、可用性を確保します。
3. RDSとMulti-AZ展開
- RDS Multi-AZは、同一リージョン内で高可用性を提供しますが、クロスリージョンの障害に対応することはできません。
- したがって、RTOやRPOの要件において、単一リージョン内の障害に備えるためには適切ですが、クロスリージョンでの災害には不十分です。
4. データベースの災害復旧
- クロスリージョンのデータベースレプリケーションは、万一のリージョン障害に対して、他のリージョンでデータを確保し、復旧を早急に行うための重要な手段です。
- Aurora Global Databaseなどは、データベースの変更を数秒で複製し、リアルタイムでの同期が可能なので、データの損失を最小限に抑えることができます。
5. 選択肢の評価基準
- クロスリージョンのレプリケーションが求められる場合、Aurora Global Databaseが最適。
- 同一リージョン内での高可用性を確保する場合、RDS Multi-AZが適切。
- 手動管理のスタンバイデータベースは、運用の複雑さが増し、可用性や復旧速度が保証されません。
結論
災害復旧シナリオでは、クロスリージョンのデータベース同期が重要であり、Amazon Aurora Global Databaseは、RPOとRTOの要件を満たす理想的な選択肢です。
実践
略
一問道場
問題 #272
トピック 1
ある企業が、us-east-1リージョンでウェブアプリケーションをAWSでホストしています。アプリケーションサーバーは3つのアベイラビリティゾーンに分散され、Application Load Balancerの背後に配置されています。データベースは、Amazon EC2インスタンス上のMySQLデータベースとしてホストされています。ソリューションアーキテクトは、AWSサービスを使用して、RTO（復旧時間目標）が5分未満、RPO（復旧点目標）が1分未満のクロスリージョンデータ復旧ソリューションを設計する必要があります。ソリューションアーキテクトは、us-west-2にアプリケーションサーバーを展開し、Amazon Route 53のヘルスチェックとDNSフェイルオーバーをus-west-2に設定しました。
ソリューションアーキテクトが取るべき追加の手順はどれですか？
A. データベースをAmazon RDS for MySQLインスタンスに移行し、us-west-2にクロスリージョンのリードレプリカを作成する。
B. データベースをAmazon Aurora Global Databaseに移行し、プライマリをus-east-1、セカンダリをus-west-2に配置する。
C. データベースをAmazon RDS for MySQLインスタンスに移行し、Multi-AZ展開を設定する。
D. us-west-2にMySQLスタンバイデータベースをAmazon EC2インスタンスで作成する。
解説
この問題では、RTO（復旧時間目標）が5分未満、RPO（復旧点目標）が1分未満であるクロスリージョンデータ復旧ソリューションを設計する必要があります。また、アプリケーションサーバーはus-east-1とus-west-2で展開されており、DNSフェイルオーバーが設定されています。
解説
選択肢 A:
「データベースをAmazon RDS for MySQLインスタンスに移行し、us-west-2にクロスリージョンのリードレプリカを作成する」
- RPOを1分未満に保つためには、リードレプリカを使用して、データの同期がほぼリアルタイムで行われる必要がありますが、RDSのリードレプリカはデータが非同期で複製されるため、RTOとRPOの要件には完全には対応できません。
選択肢 B:
「データベースをAmazon Aurora Global Databaseに移行し、プライマリをus-east-1、セカンダリをus-west-2に配置する」
- Amazon Aurora Global Databaseは、クロスリージョンでのデータベースレプリケーションを提供し、1分未満のRPOと5分未満のRTOの要件を満たすために最適です。データはほぼリアルタイムで同期されるため、災害復旧にも対応できます。この選択肢が最適です。
選択肢 C:
「データベースをAmazon RDS for MySQLインスタンスに移行し、Multi-AZ展開を設定する」
- Multi-AZは、単一リージョン内での高可用性を提供しますが、クロスリージョンの障害に対応することはできません。これではRTOとRPOの要件を満たすことができません。
選択肢 D:
「us-west-2にMySQLスタンバイデータベースをAmazon EC2インスタンスで作成する」
- スタンバイデータベースは復旧のオプションですが、手動で同期を行う必要があり、自動化された同期がないため、RPOとRTOを達成するのは困難です。また、運用面でも複雑さが増します。
結論
選択肢 B（Amazon Aurora Global Database）が最も適切です。この選択肢は、クロスリージョンのデータ同期を提供し、RPO 1分未満、RTO 5分未満を確実に満たすため、災害復旧のニーズに最適です。
273-AWS SAP AWS 「理論・実践・一問道場」SCP
理論
この問題に関連する本質的な知識は、AWS Organizations と Service Control Policies (SCP)、および タグポリシー の利用です。
1. AWS Organizations の利用
AWS Organizationsは、複数のAWSアカウントを一元的に管理するためのサービスです。企業はAWS Organizationsを使って、複数のアカウントをグループ化し、リソースの管理やガバナンスを効率化できます。これにより、企業はセキュリティやコンプライアンスの基準を維持しやすくなります。
2. Service Control Policies (SCP) の活用
SCPは、AWS Organizations内でアクセス制御を行うためのポリシーです。SCPは、特定のAWSリージョンへのアクセスを制限することができます。例えば、あるメンバーアカウントに対して「us-east-1」リージョンのみアクセス可能とするように設定できます。これにより、規制要件に従ったアクセス制限が可能になります。
3. タグポリシー の設定
タグポリシーは、AWSリソースに対して一貫したタグ付けを強制するために使用します。企業のグループ標準に基づいて、リソースが必ず特定のタグを持つようにすることができます。タグポリシーを適用することで、企業のガバナンスと監視が簡単になります。
4. OU (Organizational Units) の使用
AWS Organizations内でOU（組織単位）を作成し、異なるグループのアカウントをまとめることで、それぞれのOUに特定のポリシーを適用できます。例えば、特定のOU内のアカウントにのみ特定のリージョンでリソースを展開できるように制限をかけることができます。
結論
AWS Organizations、SCP、タグポリシーを組み合わせて利用することで、アカウントに対するアクセス制限やリソース管理を効率的に行い、規制要件を満たすことができます。これにより、リソース管理が一元化され、セキュリティやコンプライアンスを簡単に維持できます。
実践
略
一問道場
質問 #273
トピック 1
ある企業は、複数のアカウントを管理するためにAWS Organizationsを使用しています。規制要件により、企業は特定のメンバーアカウントがリソースをデプロイできるAWSリージョンを制限したいと考えています。アカウント内のリソースはタグ付けされ、グループ標準に基づいて強制され、中央で最小限の設定で管理される必要があります。
これらの要件を満たすためにソリューションアーキテクトは何をすべきですか？
A. 特定のメンバーアカウントにAWS Configルールを作成してリージョンを制限し、タグポリシーを適用する。
B. AWS Billing and Cost Managementコンソールの管理アカウントから、特定のメンバーアカウントのリージョンを無効にし、ルートでタグポリシーを適用する。
C. 特定のメンバーアカウントをルートに関連付け、タグポリシーと条件を使用してリージョンを制限するSCPを適用する。
D. 特定のメンバーアカウントを新しいOUに関連付け、タグポリシーと条件を使用してリージョンを制限するSCPを適用する。
解説
この問題は、AWS Organizationsを使用して複数のアカウントを管理する企業が、規制要件に基づいて特定のリージョンに対してリソースのデプロイを制限し、タグ付けと管理を一元化する方法について問われています。
正しい解答はD:「特定のメンバーアカウントを新しいOUに関連付け、タグポリシーと条件を使用してリージョンを制限するSCPを適用する。」 です。
理由は以下の通りです：
- AWS Organizations と SCP (Service Control Policies):
SCPを使用して、AWS Organizations内で特定のアカウントや組織単位（OU）に対してアクセス制御を行うことができます。SCPに条件を設定することで、特定のリージョンでのみリソースをデプロイできるように制限できます。
- タグポリシーの使用:
タグポリシーは、リソースにタグを付ける際の標準を強制するために使用できます。これにより、企業のグループ標準に従ってタグ付けを管理できます。
- 新しいOUへの関連付け:
特定のアカウントを新しいOUに関連付けることで、そのOUに適用されるポリシー（SCPやタグポリシー）を一元的に管理し、必要な制限を適用できます。
他の選択肢についての評価：
- A（AWS Configルールを使用）:
AWS Configはリソースの設定や変更を追跡しますが、リージョンの制限には直接的に使用できません。AWS Organizationsでのアカウント制限にはSCPを使用する方が効果的です。
- B（Billing and Cost Managementコンソールでのリージョン無効化）:
請求関連の設定でリージョンを無効にすることはできますが、この方法ではタグポリシーの適用や、規制要件に基づくリージョン制限の管理が不十分です。
- C（ルートに関連付け、SCPとタグポリシーの使用）:
ルートに関連付けると、組織内のすべてのアカウントに影響を与える可能性があり、特定のメンバーアカウントに対して細かい制限を加えるのには適していません。
したがって、Dが最も適切な選択肢です。
274-AWS SAP AWS 「理論・実践・一問道場」署名付きURL
理論
署名付きURL（pre-signed URL）は、AWSリソースへのアクセスを提供するために、特定のユーザーまたはサービスが発行します。基本的には、署名付きURLを発行するのはそのリソースへのアクセス権限を持っているAWSアカウントまたはサービスです。
誰が署名付きURLを発行するか？
- 署名付きURLを発行するのはAWSアカウントのユーザーまたはサービス:
- 署名付きURLは、リソースにアクセスする権限を持つAWSユーザーまたはサービスが発行します。
- 例えば、S3バケットのオブジェクトにアクセスする権限を持つIAMロールやIAMユーザー、またはその権限を持つAWSサービス（例えば、AWS Lambdaなど）が署名付きURLを発行します。
- 署名付きURLを発行するプロセス:
- AWSアカウントがAWS SDKやAWS CLIを使用して、署名付きURLを生成するためのAPIリクエストをS3に送信します。
- S3は署名付きURLを発行するのではなく、リクエストに基づいて署名付きURLを生成するために必要な情報を提供します。つまり、署名付きURLの「署名部分」を作成するためには、アクセス権限を持つIAMユーザーまたはサービスが署名を行い、それに基づいて一時的なURLが生成されます。
- 発行者:
- 実際に署名付きURLを発行するのは、権限を持ったIAMユーザーやサービス（例：AWS Lambda）が行います。これにより、指定されたオブジェクトへのアクセスを制御し、制限された期間内でそのオブジェクトにアクセスすることが可能になります。
署名付きURL発行の流れ（具体的な例）
- IAMユーザーやサービスがリクエスト：
- 署名付きURLを発行したいIAMユーザーまたはサービス（例えば、AWS Lambda）が、
get_object操作をS3バケットの対象オブジェクトに対してリクエストします。
- 署名の生成：
- このリクエストは、IAMユーザーまたはサービスがAWS SDKやCLIを使って行い、そのリクエストに基づいて署名が生成されます。署名は、そのユーザーまたはサービスが対象のリソースへのアクセス権限を持っていることを確認するものです。
- 署名付きURLの発行：
- 最終的に、署名付きURLが作成され、そのURLを利用することで、指定されたオブジェクトにアクセスできるようになります。署名付きURLには、リクエストが有効な期間や操作の種類（GETやPUT）が含まれています。
結論
署名付きURLを発行するのは、リソース（例：S3オブジェクト）に対するアクセス権限を持つIAMユーザーやサービスです。そのユーザーやサービスが署名を行い、署名付きURLを生成します。S3自体は署名付きURLを発行しませんが、署名付きURLがアクセスを可能にするために必要な情報を提供します。
実践
略
一問道場
会社は、レポートを生成し、それらをAmazon S3バケットに保存するアプリケーションを持っています。ユーザーがレポートにアクセスすると、アプリケーションは署名付きURLを生成して、ユーザーがレポートをダウンロードできるようにします。会社のセキュリティチームは、ファイルが公開されており、誰でも認証なしでダウンロードできることを発見しました。会社は、新しいレポートの生成を停止し、問題が解決されるまでそのままにしています。
このセキュリティの問題をアプリケーションの通常のワークフローに影響を与えることなく、即座に修正するためのアクションのセットはどれですか？
A. 認証されていないユーザーに対してすべてを拒否するポリシーを適用するAWS Lambda関数を作成します。そのLambda関数を実行するスケジュールイベントを設定します。
B. AWS Trusted Advisorのバケット権限チェックを確認し、推奨されるアクションを実施します。
C. スクリプトを実行して、バケット内のすべてのオブジェクトにプライベートACLを設定します。
D. Amazon S3の「ブロックパブリックアクセス」機能を使用して、バケットの「IgnorePublicAcls」オプションをTRUEに設定します。
解説
この問題の解決策は、S3バケット内のオブジェクトが公開されないように設定を変更することです。各選択肢について解説します。
A. AWS Lambda関数を作成し、認証されていないユーザーに対してすべてを拒否するポリシーを適用する
- Lambda関数でポリシーを適用する方法は、問題の根本的な解決策としては適切ですが、この方法は複雑であり、すぐに実行可能ではありません。Lambda関数の実装やスケジュールイベントの設定に時間がかかるため、即時の修正には向いていません。
B. AWS Trusted Advisorのバケット権限チェックを確認し、推奨されるアクションを実施する
- Trusted Advisorを使ってバケット権限を確認するのは有効ですが、具体的な修正手段が明示されていないため、この方法だけでは即座に問題を解決することは難しいです。
C. スクリプトを実行して、バケット内のすべてのオブジェクトにプライベートACLを設定する
- プライベートACLを設定することで、S3バケット内のオブジェクトへのアクセスを制限できますが、これは一時的な対応であり、継続的に管理する方法としては適切ではないかもしれません。手動でスクリプトを実行しなければならず、管理が複雑になる可能性があります。
D. Amazon S3の「ブロックパブリックアクセス」機能を使用して、バケットの「IgnorePublicAcls」オプションをTRUEに設定する
- 最適な解決策です。 S3の「ブロックパブリックアクセス」機能を使用すると、バケットやオブジェクトに対する公開アクセスを一時的かつ即座にブロックできます。
IgnorePublicAclsオプションをTRUEに設定することで、バケット内の既存の公開設定も無効化され、セキュリティが強化されます。アプリケーションの正常な動作に影響を与えることなく、すぐに問題を修正できます。
結論：
Dは、即座にセキュリティ問題を解決し、アプリケーションの正常なワークフローを維持できる最も簡単で効果的な方法です。
275-AWS SAP AWS 「理論・実践・一問道場」(AWS SCT)
理論
この問題に関連する本質的な知識は、データベース移行とその設計に関する以下のポイントです。
- AWS Database Migration Service (AWS DMS):
- AWS DMSは、データベース間での移行を行うためのサービスです。特に、変更データキャプチャ (CDC)を使用することで、移行中の新しいデータをターゲットデータベースに継続的に反映させることが可能です。これにより、ダウンタイムなしでデータベースの移行を実現できます。
- AWS Schema Conversion Tool (AWS SCT):
- AWS SCTは、異なるデータベース間でスキーマを変換するツールです。例えば、OracleからPostgreSQLへのスキーマ変換が可能で、移行プロセスを簡素化します。データ型や関数、インデックスなどの変換が含まれます。
- VPCピアリング:
- 異なるAWSアカウント間でデータベースインスタンスを相互に接続するためには、VPCピアリングを利用して、異なるVPC間で通信ができるように設定します。セキュリティグループを適切に設定することも重要です。
- CNAMEレコードの更新:
- アプリケーションがAmazon RDSインスタンスにアクセスする際、CNAMEレコードを使用してDNS経由で接続します。データベース移行後には、ターゲットインスタンスを指すようにCNAMEレコードを更新することが必要です。
これらのポイントを理解し、移行に適したツールやサービスを組み合わせて活用することで、効率的かつスムーズなデータベース移行が実現できます。
実践
略
一問道場
ある企業が、Amazon RDS for Oracle データベースを別の AWS アカウント内の RDS for PostgreSQL DB インスタンスに移行する予定です。ソリューションアーキテクトは、ダウンタイムなしで移行を完了させ、移行に必要な時間を最小限に抑える移行戦略を設計する必要があります。移行戦略は、すべての既存データおよび移行中に作成された新しいデータをレプリケートする必要があります。移行プロセスの完了時に、ターゲットデータベースはソースデータベースと同一でなければなりません。
現在、すべてのアプリケーションは、RDS for Oracle DB インスタンスと通信するためのエンドポイントとして Amazon Route 53 の CNAME レコードを使用しています。RDS for Oracle DB インスタンスはプライベートサブネットにあります。
要件を満たすためにソリューションアーキテクトが取るべきステップの組み合わせはどれですか？（3つ選んでください。）
A. ターゲットアカウントに新しい RDS for PostgreSQL DB インスタンスを作成し、AWS Schema Conversion Tool（AWS SCT）を使用してソースデータベースからターゲットデータベースへのデータベーススキーマを移行する。
B. AWS Schema Conversion Tool（AWS SCT）を使用して、ターゲットアカウントに新しい RDS for PostgreSQL DB インスタンスを作成し、ソースデータベースからターゲットデータベースにスキーマと初期データを移行する。
C. 両方の AWS アカウント間で VPC ピアリングを構成し、ターゲットアカウントから両方の DB インスタンスへの接続を提供する。ターゲットアカウントの VPC からデータベースポートでトラフィックを許可するように、各 DB インスタンスに関連付けられたセキュリティグループを構成する。
D. 一時的にソース DB インスタンスを公開アクセス可能にして、ターゲットアカウントの VPC からの接続を提供する。ターゲットアカウントの VPC からデータベースポートでトラフィックを許可するように、各 DB インスタンスに関連付けられたセキュリティグループを構成する。
E. ターゲットアカウントで AWS Database Migration Service（AWS DMS）を使用して、ソースデータベースからターゲットデータベースへのフルロードと変更データキャプチャ（CDC）移行を実行する。移行が完了したら、CNAME レコードをターゲット DB インスタンスのエンドポイントに変更する。
F. ターゲットアカウントで AWS Database Migration Service（AWS DMS）を使用して、ソースデータベースからターゲットデータベースへの変更データキャプチャ（CDC）移行を実行する。移行が完了したら、CNAME レコードをターゲット DB インスタンスのエンドポイントに変更する。
解説
この問題において、正しい選択肢は以下の3つです。
- A: AWS Schema Conversion Tool (AWS SCT) を使用して、ソースのOracleデータベースのスキーマをターゲットのPostgreSQLデータベースに移行します。これにより、スキーマの変換が行われます。
- C: VPCピアリングを設定して、ターゲットアカウントのDBインスタンスがソースDBインスタンスにアクセスできるようにします。セキュリティグループを適切に設定し、通信を許可する必要があります。
- E: AWS Database Migration Service (AWS DMS) を使用して、フルロードとCDC（変更データキャプチャ）を実行し、データをターゲットのPostgreSQLデータベースに移行します。移行が完了した後、CNAMEレコードを更新してターゲットDBインスタンスを指すようにします。
これらの選択肢を組み合わせることで、ダウンタイムなしで移行を完了し、ソースデータベースからターゲットデータベースへのデータの移行を確実に行うことができます。
276-AWS SAP AWS 「理論・実践・一問道場」SQS可視性タイムアウト
理論
1. 可視性タイムアウト
可視性タイムアウトは、メッセージが処理中であるときに他のコンシューマーに再び配信されないようにするための設定です。処理中のメッセージが再処理されることを防ぎますが、処理がタイムアウトすると、他のメッセージがブロックされる原因にもなり得ます。
2. デッドレターキュー (DLQ)
デッドレターキューは、処理に失敗したメッセージを隔離するために使用されます。これにより、故障したメッセージがシステム全体の処理を妨げることなく、後で分析して修正できます。デッドレターキューは標準キューかFIFOキューを設定できますが、通常は標準キューが推奨されます。
3. バックエンド処理とキュー設定の整合性
バックエンド処理タイムアウトと可視性タイムアウトが適切に調整されていないと、処理がタイムアウトし、メッセージが再度キューに戻され、再度エラーを引き起こす可能性があります。バックエンドの処理が終了する前にメッセージが再度キューに戻ることを防ぐために、可視性タイムアウトを適切に設定することが重要です。
バックエンド処理が完了するまでの時間が可視性タイムアウトより短くなるように設定することが重要です。これにより、メッセージの再処理を防ぎ、正常に処理が終了するまで他のコンシューマーがそのメッセージにアクセスしないようにできます。
4. FIFOキュー vs 標準キュー
FIFOキューはメッセージの順序を保証しますが、順序が重要でない場合やスループットが重視される場合には標準キューが適しています。標準キューは順序を保証しないため、より高いスループットを提供し、特にデッドレターキューとして使用する場合に適切です。
要点:
- 可視性タイムアウトとバックエンド処理タイムアウトの整合性を保つことが重要。
- デッドレターキューを設定して、処理に失敗したメッセージを隔離し、後で分析・修正できるようにする。
- 標準キューをデッドレターキューとして使用するのが最適。
これらの知識は、SQSを利用するシステムの健全性を保つために不可欠です。
実践
略
一問道場
質問 #276
トピック 1
ある会社がイベント駆動型アーキテクチャを使用して注文システムを実装しました。最初のテスト中にシステムが注文処理を停止しました。
さらにログ解析を行った結果、Amazon Simple Queue Service（Amazon SQS）の標準キューにある1件の注文メッセージがバックエンドでエラーを引き起こし、その後のすべての注文メッセージをブロックしていることが判明しました。
キューの可視性タイムアウトは30秒に設定されており、バックエンド処理タイムアウトは10秒に設定されています。ソリューションアーキテクトは、故障した注文メッセージを分析し、システムが後続のメッセージを処理し続けることを確実にする必要があります。
ソリューションアーキテクトがこの要件を満たすために取るべきステップはどれですか？
A. バックエンド処理タイムアウトを30秒に増やして可視性タイムアウトと一致させる。
B. キューの可視性タイムアウトを短くして、故障したメッセージを自動的に削除する。
C. 新しいSQS FIFOキューをデッドレターキューとして設定して、故障したメッセージを隔離する。
D. 新しいSQS標準キューをデッドレターキューとして設定して、故障したメッセージを隔離する。
解説
この問題では、Amazon SQSを使って注文システムが構築されており、1つの故障した注文メッセージが原因でシステム全体が停止してしまう状況です。目標は、故障したメッセージを分析しつつ、後続のメッセージが正常に処理されるようにすることです。
それぞれの選択肢を見ていきましょう。
A. バックエンド処理タイムアウトを30秒に増やして可視性タイムアウトと一致させる。
- 誤り: バックエンド処理タイムアウトを可視性タイムアウトと一致させても、故障したメッセージが後続の処理に影響を与える原因を解決するわけではありません。可視性タイムアウトはメッセージが再処理されるまでの時間を制御するものであり、システム全体の停止を防ぐためには、エラー処理の方法を改善することが重要です。
B. キューの可視性タイムアウトを短くして、故障したメッセージを自動的に削除する。
- 誤り: 可視性タイムアウトを短くしても、故障したメッセージの処理は早く終わらない可能性があり、結果的にメッセージの再処理が頻繁に行われ、システムが無限ループに陥る恐れがあります。故障したメッセージを自動的に削除する方法としては適切ではありません。
C. 新しいSQS FIFOキューをデッドレターキューとして設定して、故障したメッセージを隔離する。
- 誤り: FIFOキューはメッセージの順序を厳密に保証しますが、このシナリオではメッセージの順序を厳守する必要はありません。デッドレターキューとしてFIFOキューを使用するのはオーバーエンジニアリングであり、標準キューの方が適切です。
D. 新しいSQS標準キューをデッドレターキューとして設定して、故障したメッセージを隔離する。
- 正解: 標準キューをデッドレターキューとして設定することが最適です。デッドレターキューは、処理に失敗したメッセージを隔離するために使用され、これにより故障したメッセージが後続のメッセージ処理をブロックすることを防げます。標準キューは順序に依存しないため、後続のメッセージが正常に処理されることを確保できます。
結論: 正しい回答は D です。
277-AWS SAP AWS 「理論・実践・一問道場」AWS Step Functions
理論
AWS Step Functionsとエラーハンドリング
AWS Step Functionsは、複数のAWSサービスを統合し、ワークフローを構築するためのサービスです。これを使って、順次実行される複数のタスク（例：AWS Lambda関数）を管理できます。しかし、実行中にエラーが発生することがあり、これに対処するために効果的なエラーハンドリングの設計が重要です。
エラーハンドリングの重要性
- 再試行（Retry）: Step Functionsでは、タスクが失敗した場合に再試行を行う設定が可能です。再試行回数や間隔を調整することで、ネットワークの問題や一時的なサービス障害に対応できます。
- キャッチ（Catch）: タスクが失敗した際に、どのように処理を続けるかを指定するためのフィールドです。
Catchを使用することで、エラーが発生した場合に特定のタスク（例：通知の送信）に遷移させることができます。これにより、エラーが発生した際に必要なアクション（通知やリトライ）を自動化できます。
- SNSによる通知: 失敗時に通知を送るために、AWS SNS（Simple Notification Service）を利用することが一般的です。SNSトピックを作成し、エラーが発生した場合にそのトピックにメッセージを送ることができます。これにより、管理者やチームメンバーが即座に失敗を認識でき、迅速に対応が可能になります。
ベストプラクティス
- エラーハンドリングを統一する: すべてのタスクで一貫したエラーハンドリングを設定することが重要です。失敗した場合に通知が送信されるように、
CatchやRetryフィールドを設定します。
- 通知を活用する: エラーが発生した場合、SNSを使って通知を送信し、管理者や関係者に即座に知らせるようにします。これにより、再訓練やワークフローが失敗したことに気づくのが遅れることを防げます。
- エラータイプを適切に設定する:
ErrorEqualsフィールドに指定するエラータイプ（例えば、States.ALL）を適切に設定して、すべてのエラーに対して対応できるようにします。States.Runtimeはランタイムエラーに特化しているため、すべてのエラーを対象にする場合はStates.ALLを使用する方が汎用的です。
結論
AWS Step Functionsを使用する際には、エラー発生時に適切に対応できるように設計することが重要です。失敗通知をSNSで送るように設定し、ワークフローの停止を未然に防ぐためのエラーハンドリング（
Catch）や再試行（Retry）を適切に活用することで、システムの健全性を保つことができます。実践
略
一問道場
質問 #277
トピック 1
ある会社が、AWS Step Functionsを使用して機械学習モデルの夜間再訓練を自動化しています。このワークフローは、複数のAWS Lambdaステップで構成されています。各ステップはさまざまな理由で失敗する可能性があり、いずれの失敗も全体のワークフローの失敗を引き起こします。
レビューの結果、再訓練が何晩も連続して失敗していたことが判明しましたが、会社はその失敗に気づいていませんでした。ソリューションアーキテクトは、再訓練プロセス内でのすべてのタイプの失敗に対して通知が送信されるようにワークフローを改善する必要があります。
この要件を満たすためにソリューションアーキテクトが取るべき手順の組み合わせはどれですか？（3つ選んでください。）
A. Amazon Simple Notification Service (Amazon SNS) トピックを作成し、チームのメールリストをターゲットにした「Email」タイプのサブスクリプションを作成する。
B. 「Email」という名前のタスクを作成し、入力引数をSNSトピックに転送する。
C. 「ErrorEquals":["States.ALL"]」および「Next":"Email"というステートメントを持つ、すべてのTask、Map、およびParallelステートにCatchフィールドを追加する。
D. Amazon Simple Email Service (Amazon SES) に新しいメールアドレスを追加し、そのメールアドレスを確認する。
E. 「Email」という名前のタスクを作成し、入力引数をSESメールアドレスに転送する。
F. 「ErrorEquals":["States.Runtime"]」および「Next":"Email"というステートメントを持つ、すべてのTask、Map、およびParallelステートにCatchフィールドを追加する。
解説
この問題では、AWS Step Functionsを使用して機械学習モデルの夜間再訓練を自動化しているワークフローに対して、失敗通知を送信する方法を考える必要があります。ソリューションアーキテクトは、再訓練プロセス内で発生する可能性のあるすべての失敗に対して通知を送信する必要があります。
各選択肢の解説：
A. Amazon SNSトピックを作成し、チームのメールリストをターゲットにした「Email」タイプのサブスクリプションを作成する。
- 正解: Amazon SNSを使って通知を送信する方法は、AWS Step Functionsで失敗した場合に通知を送るための標準的な手段です。SNSトピックを作成し、それに「Email」サブスクリプションを設定することで、ワークフロー内でエラーが発生した際に、メールで通知を受け取ることができます。
B. 「Email」という名前のタスクを作成し、入力引数をSNSトピックに転送する。
- 正解: 「Email」という名前のタスクを作成して、失敗時に入力引数（エラー内容やステータス）をSNSトピックに転送することで、エラーの詳細を通知できます。このタスクは、エラーが発生した際に実行され、SNSトピックにメッセージを送信します。
C. 「ErrorEquals":["States.ALL"]」および「Next":"Email"というステートメントを持つ、すべてのTask、Map、およびParallelステートにCatchフィールドを追加する。
- 正解: Catchフィールドは、AWS Step Functionsのステートが失敗した場合に、どのステートに遷移するかを指定するために使用されます。「ErrorEquals":["States.ALL"]」はすべてのエラーにマッチするため、エラーが発生した際に「Email」タスクに遷移するように設定することができます。この設定により、すべてのエラーに対して通知が送信されます。
D. Amazon SESに新しいメールアドレスを追加し、そのメールアドレスを確認する。
- 誤り: Amazon SES（Simple Email Service）はメールの送信に使われますが、SNSによる通知の送信には使用しません。SNSで通知を送信するには、SESではなくSNSの設定が必要です。SESは送信メールの設定に関するもので、通知のためには関係ありません。
E. 「Email」という名前のタスクを作成し、入力引数をSESメールアドレスに転送する。
- 誤り: SESを直接使用して通知を送るのは適切ではありません。AWS Step Functionsでは、SNSを使用して通知を送る方が一般的です。SESは通知を送信するための適切な選択肢ではありません。
F. 「ErrorEquals":["States.Runtime"]」および「Next":"Email"というステートメントを持つ、すべてのTask、Map、およびParallelステートにCatchフィールドを追加する。
- 誤り: 「States.Runtime」エラーはランタイムエラーに特化していますが、すべてのエラータイプをカバーするわけではありません。「States.ALL」の方が包括的にすべてのエラーを捕まえるため、通知を送るためには「States.ALL」が適しています。
結論：
正しい手順は、SNS通知を設定し、失敗時に「Email」タスクを呼び出し、すべてのエラーをキャッチして通知する設定を行うことです。
したがって、正解は A, B, C です。
278-AWS SAP AWS 「理論・実践・一問道場」アウトバウンドResolver
理論
1. VPCとDNS解決
- VPC内でEC2インスタンスがDNS名を解決するためには、VPCのDNS設定が重要です。VPCにDNSホスト名を有効にすると、VPC内のインスタンスがDNS解決を行えるようになります。
2. Amazon Route 53 Resolver
- Route 53 Resolverは、VPC内でのDNS解決を制御するためのサービスです。Route 53 Resolverには「アウトバウンドエンドポイント」と「インバウンドエンドポイント」があります。
- アウトバウンドエンドポイント: VPC内のインスタンスからオンプレミスのDNSサーバーへのDNSリクエストを転送するために使用します。これにより、VPC内からオンプレミスのDNSゾーンを解決できます。
- インバウンドエンドポイント: オンプレミスのDNSサーバーからVPC内のリソースに対するDNSリクエストを転送するために使用します。
3. Resolverルール
- Resolverルールを設定することで、特定のドメイン（例:
company.example）に対するDNSリクエストを、指定したDNSサーバー（例えばオンプレミスのDNSサーバー）に転送できます。これにより、VPC内のインスタンスはオンプレミスのDNSゾーンを解決できます。
4. Amazon Route 53とDNSゾーン
- Route 53のプライベートDNSゾーンを使用することで、AWS内のリソースに対するDNS解決を行いますが、オンプレミスのDNSゾーンを解決するためには、Route 53 Resolverを使った設定が必要です。
5. オンプレミスDNSとの統合
- オンプレミスのDNSゾーンをAWSのVPC内で解決するために、VPC内のリソース（EC2インスタンスなど）がオンプレミスのDNSサーバーを使用できるようにする設定が必要です。この設定を行うことで、VPC内からオンプレミスのサービスを名前解決を通じて参照することができます。
結論
VPC内からオンプレミスのDNSゾーンを解決するには、Route 53 Resolverを使用してアウトバウンドエンドポイントを設定し、DNSリクエストをオンプレミスのDNSサーバーに転送する必要があります。この設定により、VPC内のEC2インスタンスは
company.exampleドメインを解決でき、既存のオンプレミスサービスと統合できます。実践
略
一問道場
Question #278
ある企業が、VPC内のAmazon EC2インスタンスに新しいプライベートイントラネットサービスを展開する予定です。AWS Site-to-Site VPNがVPCと企業のオンプレミスネットワークを接続しています。この新しいサービスは、既存のオンプレミスサービスと通信する必要があります。オンプレミスのサービスは、company.exampleというDNSゾーンにあるホスト名を使ってアクセスされます。このDNSゾーンは完全にオンプレミスでホストされており、企業のプライベートネットワーク上でのみ利用可能です。
ソリューションアーキテクトは、既存のサービスと統合できるように、新しいサービスがcompany.exampleドメインのホスト名を解決できるようにする必要があります。
この要件を満たす解決策はどれですか？
A. Amazon Route 53でcompany.exampleの空のプライベートゾーンを作成し、オンプレミスのcompany.exampleゾーンに新しいプライベートゾーンの権限を持つ名前サーバーを指す追加のNSレコードを追加します。
B. VPCのDNSホスト名をオンにし、Amazon Route 53 Resolverで新しいアウトバウンドエンドポイントを設定し、company.exampleのリクエストをオンプレミスの名前サーバーに転送するResolverルールを作成します。
C. VPCのDNSホスト名をオンにし、Amazon Route 53 Resolverで新しいインバウンドリゾルバーエンドポイントを設定し、オンプレミスのDNSサーバーを設定して、company.exampleのリクエストを新しいリゾルバーに転送します。
D. AWS Systems Managerを使用して、必要なホスト名を含むhostsファイルをインストールする実行ドキュメントを設定し、インスタンスが実行状態に入るときにそのドキュメントを実行するAmazon EventBridgeルールを作成します。
解説
この問題では、VPC内の新しいサービスが、企業のオンプレミスネットワーク内の既存のサービスと統合するために、オンプレミスのDNSゾーン（
company.example）を解決できるようにする必要があります。以下に、各選択肢の解説を行います。A. Amazon Route 53でcompany.exampleの空のプライベートゾーンを作成し、オンプレミスのcompany.exampleゾーンに新しいプライベートゾーンの権限を持つ名前サーバーを指す追加のNSレコードを追加します。
- 不適切: この方法は、Amazon Route 53で新しいプライベートDNSゾーンを作成することに関係していますが、オンプレミスDNSゾーンでその新しいゾーンのNSレコードを追加するだけでは、VPC内からオンプレミスDNSゾーン（
company.example）に対する名前解決を行うことはできません。オンプレミスのDNSゾーンを直接解決するためには、Route 53 Resolverを使用する方法が推奨されます。
B. VPCのDNSホスト名をオンにし、Amazon Route 53 Resolverで新しいアウトバウンドエンドポイントを設定し、company.exampleのリクエストをオンプレミスの名前サーバーに転送するResolverルールを作成します。
- 適切: この解決策は、VPC内のEC2インスタンスが、
company.exampleドメインに関するDNSリクエストをオンプレミスのDNSサーバーに転送できるようにするものです。まず、VPCのDNSホスト名を有効にし、Amazon Route 53 Resolverを使用して、リクエストをオンプレミスのDNSサーバーに転送するためのアウトバウンドエンドポイントとResolverルールを設定します。これにより、VPC内の新しいサービスがオンプレミスのDNSゾーンを解決できるようになります。
C. VPCのDNSホスト名をオンにし、Amazon Route 53 Resolverで新しいインバウンドリゾルバーエンドポイントを設定し、オンプレミスのDNSサーバーを設定して、company.exampleのリクエストを新しいリゾルバーに転送します。
- 不適切: この方法は、オンプレミスのDNSサーバーがAmazon Route 53 Resolverにリクエストを転送する構成です。しかし、問題では、VPC内の新しいサービスがオンプレミスのDNSを解決する必要があるため、インバウンドエンドポイントを使うのではなく、アウトバウンドエンドポイントを使うべきです。この解決策はVPCからオンプレミスへのDNS解決には適していません。
D. AWS Systems Managerを使用して、必要なホスト名を含むhostsファイルをインストールする実行ドキュメントを設定し、インスタンスが実行状態に入るときにそのドキュメントを実行するAmazon EventBridgeルールを作成します。
- 不適切: この方法では、EC2インスタンスに手動で
hostsファイルを設定することになります。これはホスト名解決の管理が非常に手動で、スケーラビリティが低く、長期的には運用が難しくなります。また、DNS解決の方法としては適切ではなく、Amazon Route 53 Resolverのような自動化された方法を使うほうが良いです。
正しい解決策
Bの選択肢が最も適切です。具体的には、VPC内のDNSホスト名を有効にし、Amazon Route 53 Resolverを使用して、オンプレミスのDNSサーバーにDNSリクエストを転送するためのアウトバウンドエンドポイントとResolverルールを設定することです。これにより、VPC内の新しいサービスがオンプレミスのDNSゾーン（
company.example）を正しく解決できるようになります。279-AWS SAP AWS 「理論・実践・一問道場」
理論
トランジットゲートウェイ（TGW）のルートテーブルの実例を示します。この例では、複数のVPCがトランジットゲートウェイを使用して接続され、各VPC間でトラフィックを制御する方法を示します。
シナリオ
- VPC1 (10.0.0.0/16)
- VPC2 (10.1.0.0/16)
- VPC3 (10.2.0.0/16)
- トランジットゲートウェイ (TGW)
- 各VPCはトランジットゲートウェイに接続されていますが、VPC1とVPC2のみ通信でき、VPC3との通信は制限したいとします。
1. トランジットゲートウェイの設定
まず、トランジットゲートウェイに接続されている各VPCのルートテーブルを設定します。
2. トランジットゲートウェイルートテーブル例
VPC1用のトランジットゲートウェイルートテーブル
送信先CIDR | ターゲット |
10.0.0.0/16 | ローカル（VPC1内） |
10.1.0.0/16 | VPC2（VPC2への接続） |
10.2.0.0/16 | なし（通信を拒否） |
説明:
- VPC1内の通信（10.0.0.0/16）はローカルで処理されます。
- VPC1はVPC2（10.1.0.0/16）との通信を許可します。
- VPC1からVPC3（10.2.0.0/16）への通信は許可されません。
VPC2用のトランジットゲートウェイルートテーブル
送信先CIDR | ターゲット |
10.0.0.0/16 | VPC1（VPC1への接続） |
10.1.0.0/16 | ローカル（VPC2内） |
10.2.0.0/16 | なし（通信を拒否） |
説明:
- VPC2内の通信（10.1.0.0/16）はローカルで処理されます。
- VPC2はVPC1（10.0.0.0/16）との通信を許可します。
- VPC2からVPC3（10.2.0.0/16）への通信は許可されません。
VPC3用のトランジットゲートウェイルートテーブル
送信先CIDR | ターゲット |
10.0.0.0/16 | なし（通信を拒否） |
10.1.0.0/16 | なし（通信を拒否） |
10.2.0.0/16 | ローカル（VPC3内） |
説明:
- VPC3内の通信（10.2.0.0/16）はローカルで処理されます。
- VPC3からVPC1（10.0.0.0/16）やVPC2（10.1.0.0/16）への通信は拒否されます。
3. 結果
- VPC1とVPC2はトランジットゲートウェイを通じてお互いに通信できます。
- VPC1とVPC3、VPC2とVPC3の間では通信が制限されます（ルートテーブルで拒否されているため）。
4. 実際の設定方法
- トランジットゲートウェイ作成
AWSマネジメントコンソールまたはAWS CLIを使用して、トランジットゲートウェイを作成します。
- VPC接続の作成
各VPCをトランジットゲートウェイに接続します。これにより、VPC間の通信が可能になります。
- ルートテーブル設定
- 各VPCに対して、他のVPCとの通信を許可または拒否するためのルートを指定します。
トランジットゲートウェイの設定で、「ルートテーブル」を作成し、各VPCの接続に応じて適切なルートを設定します。
- セキュリティ設定
必要に応じて、セキュリティグループやネットワークACLを使用して、インスタンス間の通信を制御します。
まとめ
- トランジットゲートウェイの専用ルートテーブルを使用することで、VPC間のトラフィックを細かく制御できます。
- ルートテーブルで特定のVPCとの通信を許可し、他のVPCとの通信を拒否することが可能です。
実践
略
一問道場
会社は、複数のVPCにアプリケーションを展開するためにAWS CloudFormationを使用しており、すべてのVPCはトランジットゲートウェイに接続されています。インターネットにトラフィックを送信する必要がある各VPCは、トラフィックを共有サービスVPCを経由して送信しなければなりません。各VPC内のサブネットはデフォルトのVPCルートテーブルを使用し、トラフィックはトランジットゲートウェイにルーティングされます。トランジットゲートウェイは、すべてのVPC接続に対してデフォルトのルートテーブルを使用します。
セキュリティ監査により、あるVPC内のAmazon EC2インスタンスが、会社の他のすべてのVPC内のEC2インスタンスと通信できることが判明しました。ソリューションアーキテクトは、VPC間のトラフィックを制限する必要があります。各VPCは、あらかじめ定義された限られたセットの承認されたVPCとのみ通信できるようにする必要があります。
ソリューションアーキテクトは、これらの要件を満たすために何をすべきですか？
A. 各VPC内のサブネットのネットワークACLを更新し、承認されたVPCへのみアウトバウンドトラフィックを許可します。デフォルトの拒否ルールを除くすべての拒否ルールを削除します。
B. 各VPC内で使用されているすべてのセキュリティグループを更新し、承認されていないVPCで使用されているセキュリティグループへのアウトバウンドトラフィックを拒否します。
C. 各VPC接続に専用のトランジットゲートウェイルートテーブルを作成し、トラフィックを承認されたVPCにのみルーティングします。
D. 各VPCのメインルートテーブルを更新し、トランジットゲートウェイを介して承認されたVPCへのみトラフィックをルーティングします。
解説
この問題の解決には、VPC間のトラフィックを制御し、各VPCが許可されたVPCにのみ通信できるようにする方法を選択する必要があります。選択肢を一つずつ見ていきましょう。
A. ネットワークACLを更新する
- ネットワークACL (アクセスコントロールリスト) は、VPC内のサブネットに対するトラフィックの許可/拒否を制御しますが、これはVPC間の通信に対してはあまり効果的ではありません。ネットワークACLはサブネット単位で機能し、トラフィックの制限が過度に複雑になる可能性があり、ルーティングやトランジットゲートウェイの管理が必要な場合には、適切な解決策ではありません。
- この選択肢は適切ではありません。
B. セキュリティグループを使用してアウトバウンドトラフィックを制限する
- セキュリティグループは、VPC内のインスタンスへのトラフィックを制御するためのもので、インスタンス間の通信をフィルタリングするのに便利です。しかし、セキュリティグループのルールで他のVPCのセキュリティグループへの通信を制限することは、VPC間の通信全体を効果的に制御する方法としては不十分です。
- また、セキュリティグループでVPC間の全トラフィックを制限するのは非常に難しく、推奨されません。
C. 専用のトランジットゲートウェイルートテーブルを作成
- トランジットゲートウェイは複数のVPCを接続するための中継点として機能します。トランジットゲートウェイのルートテーブルをVPCごとに専用で設定することで、VPC間の通信を細かく制御できます。
- 具体的には、各VPC接続に専用のルートテーブルを作成し、トラフィックを承認されたVPCにのみルーティングすることで、VPC間の通信を確実に制限できます。
- このアプローチは、VPC間の通信を正確に管理するための最も効果的な方法です。
D. メインルートテーブルを更新する
- メインルートテーブルの更新で、VPC内のサブネットごとのルートを制御することができますが、トランジットゲートウェイのルートテーブルを個別に設定することと比較して、柔軟性に欠ける場合があります。トランジットゲートウェイを使用する場合、専用のルートテーブルを作成する方が、より細かく管理でき、トラフィックの制限が容易になります。
- この方法は有効ですが、Cの方が適切です。
結論
C. 「専用のトランジットゲートウェイルートテーブルを作成し、トラフィックを承認されたVPCにのみルーティングする」が最も適切な方法です。これにより、VPC間の通信を細かく制御でき、必要なVPCにのみトラフィックを流すことができます。
280-AWS SAP AWS 「理論・実践・一問道場」AppStream 2.0
理論
区分 | AppStream 2.0 | WorkSpaces |
サービス概要 | クラウド上のアプリケーションをクライアントデバイスに配信するフルマネージドサービス | クラウド上のデスクトップ環境へのアクセスを提供するフルマネージドサービス |
インスタンスの永続性 | 非永続的なストリーミングインスタンス | 永続的なデスクトップインスタンス |
インスタンスのOS | ・Windows Server 2012 R2・Windows Server 2016・WindowsServer 2019※ライセンスインクルードのみ | ・Amazon Linux 2 LTSWindows7(Windows Server 2008 R2 デスクトップエクスペリエンス)・Windows10(Windows Server 2016 デスクトップエクスペリエンス)・Windows7(BYOL)・Windows10（BYOL) |
プロトコル | NICE DCV高解像の画面を軽量に配信 | PCoIP画面の要素を自動識別し最適化して転送 |
用途 | ・特定のアプリケーションのみをユーザーに提供したい。・高解像度の3Dアプリケーションを利用したい。・ユーザープールを使って迅速にアプリケーションを配信開始したい。 | ・ユーザーが自由に使えるデスクトップ環境を提供したい。・ユーザごとに永続インスタンスを割り当てたい・Linuxの利用や、Windowsライセンスの持ち込みを行いたい |
1. AWSにおけるアプリケーション再ホスティング
アプリケーションをAWSに再ホストする場合、いくつかの選択肢があります。AWSは仮想デスクトップ、コンテナ、ストリーミングなど、さまざまなサービスを提供しており、それぞれのサービスには特定のユースケースに最適なシナリオがあります。例えば：
- Amazon Workspacesは仮想デスクトップを提供し、ユーザーにフルWindows環境を提供しますが、管理が複雑になる可能性があります。
- Amazon AppStream 2.0は、アプリケーションをブラウザベースでストリーミングできるサービスで、異なるOSを使っているユーザーにも対応できる柔軟性があります。
- ECS + Fargateでは、コンテナ化されたアプリケーションをスケーラブルに実行でき、インフラの管理負担を軽減できますが、アプリケーションをリファクタリングする必要があります。
2. 認証管理
AWSでは認証の管理にAmazon Cognitoを利用することが多いです。Cognitoは、ユーザーのサインイン、サインアップ、認証を簡単に管理できるサービスです。Cognitoを使うと、企業の既存のディレクトリサービス（例えばActive Directory）と連携し、既存の認証基盤をAWS環境で簡単に活用できます。
- AppStream 2.0 + Cognitoの組み合わせは、異なるOSを使用するユーザーに対して統一された認証を提供し、アプリケーションへのアクセスを簡素化します。
3. 異なるOSのユーザー対応
- AppStream 2.0は、ユーザーのデバイスに依存せず、ブラウザからアプリケーションを提供できるため、WindowsやLinux、Macなど、異なるOSを使っているユーザーに対しても対応可能です。
- Workspacesは、仮想デスクトップ上でWindowsベースのアプリケーションを提供するため、特にWindows環境に特化していますが、Linuxユーザーには不便かもしれません。
4. 最小限の開発労力での解決
最小限の開発労力を求める場合、既存のインフラを活用し、開発作業をなるべく減らすことが重要です。AppStream 2.0は、ブラウザベースでアプリケーションのストリーミングを行うため、特別な開発なしで、すぐに利用を開始できる利点があります。また、認証もCognitoで簡単に設定できるため、管理が簡便です。
まとめ
- AWS上での再ホスティングの方法は、用途に応じて選択することが重要。AppStream 2.0は、異なるOSのユーザーにもアクセス可能で、最小限の開発で再ホスティングが可能です。
- Amazon Cognitoを使用した認証管理は、AWS環境で簡単に統一したユーザー管理を提供できます。
実践
略
一問道場
質問 #280
トピック 1
ある会社には、ユーザーのWindowsマシンにパッケージ化されてデプロイされているWindowsベースのデスクトップアプリケーションがあります。最近、その会社は主にLinuxオペレーティングシステムを使用している社員を持つ別の会社を買収しました。買収した会社は、WindowsベースのデスクトップアプリケーションをAWSに移行して再ホストすることを決定しました。
すべての社員は、アプリケーションを使用する前に認証される必要があります。買収した会社は、オンプレミスのActive Directoryを使用していますが、AWS上でのアプリケーションへのアクセス管理を簡素化したいと考えています。
どのソリューションが最も少ない開発労力でアプリケーションをAWSに再ホストできますか？
A. 各社員にAmazon Workspaces仮想デスクトップを設定して提供します。認証にはAmazon CognitoのIDプールを使用します。社員には、提供されたWorkspaces仮想デスクトップからアプリケーションを実行するように指示します。
B. WindowsベースのAmazon EC2インスタンスでAuto Scalingグループを作成します。各EC2インスタンスをオンプレミスのActive Directoryドメインに参加させます。認証は、オンプレミスのActive Directoryを使用して実施します。社員には、Windowsリモートデスクトップを使用してアプリケーションを実行するように指示します。
C. Amazon AppStream 2.0のイメージビルダーを使用して、アプリケーションと必要な設定を含むイメージを作成します。動的なFleet Auto Scalingポリシーを使用して、AppStream 2.0 On-Demandフリートをプロビジョニングします。認証にはAppStream 2.0のユーザープールを使用します。社員には、ブラウザベースのAppStream 2.0ストリーミングセッションを開始してアプリケーションにアクセスするように指示します。
D. アプリケーションをリファクタリングしてコンテナ化し、Webベースのアプリケーションとして実行します。Amazon ECSのAWS Fargate上でアプリケーションを実行し、ステップスケーリングポリシーを設定します。認証にはAmazon Cognitoのユーザープールを使用します。社員には、ブラウザからアプリケーションを実行するように指示します。
解説
この問題では、WindowsベースのデスクトップアプリケーションをAWSに再ホストし、最小限の開発労力で認証機能を統合する方法を求めています。
各選択肢についての分析:
A. Amazon Workspaces仮想デスクトップを設定し、Amazon Cognitoで認証を実施する
- 利点: Amazon Workspacesは、仮想デスクトップインフラストラクチャ（VDI）サービスで、社員にWindowsデスクトップ環境を提供できます。これにより、社員は自分の仮想デスクトップからアプリケーションにアクセスでき、Cognitoを使って簡単に認証できます。
- 課題: 全社員に個別の仮想デスクトップを提供する必要があり、大規模な導入になる可能性があり、リソースの無駄が発生するかもしれません。Linuxユーザーが多いため、仮想デスクトップ上でWindows専用のアプリケーションを実行する点でオーバーヘッドが発生します。
B. WindowsベースのEC2インスタンスを利用し、Active Directoryと連携する
- 利点: 既存のActive Directoryを利用して認証を行い、Windowsリモートデスクトップを使って社員にアプリケーションを提供するアプローチです。既存のインフラを最大限に活用できます。
- 課題: リモートデスクトップ接続の管理が必要になり、ユーザーがリモートデスクトップ接続の環境を利用する必要があるため、管理が複雑になり、ユーザーの操作性も低下します。さらに、LinuxユーザーにとってはWindowsベースのリモートデスクトップが使いづらい場合があります。
C. Amazon AppStream 2.0を使用してアプリケーションをストリーミングする
- 利点: AppStream 2.0は、アプリケーションをブラウザ経由でストリーミングできるサービスで、異なるOS（WindowsやLinux）でアプリケーションにアクセスできるため、特に異なるOSを使用する社員に対応するのに最適です。Cognitoを使用した認証も簡単に統合でき、ユーザーの体験もスムーズです。
- 課題: AppStream 2.0のコストが高くなる可能性があり、大規模なユーザーに対してはコスト効率が悪くなることがあります。
D. アプリケーションをコンテナ化し、ECSで実行する
- 利点: アプリケーションをコンテナ化してAWS Fargateで実行すれば、スケーラビリティや管理が容易になります。Cognitoによる認証も簡単に統合可能です。
- 課題: アプリケーションのリファクタリングが必要です。元々のWindowsベースのアプリケーションをコンテナ化するには多大な開発努力が必要で、既存のデスクトップアプリケーションをそのまま使うという目的には適しません。
結論
最も適切な選択肢は C です。AppStream 2.0は、WindowsやLinuxのユーザーに関係なく、ブラウザからアプリケーションにアクセスできるため、少ない開発労力で社員にサービスを提供できます。認証もCognitoで簡単に統合でき、異なるOSを使用している社員にも対応できるため、最適な選択です。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/174d7ae8-88e2-806a-9292-d9dc1b4c3e1c
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
