ANS-#41

ANS#40 – ANS#41 – ANS#42
R – F

お疲れ様でした!ANS#41のクイズ終了しました。

解答スコアは %%SCORE%% / %%TOTAL%% 問正解です。

%%RATING%%

   →→学習履歴へ戻る←←   

あなたの選択した答えは強調表示されています。
問題1
Software-as-a-Service (SaaS) プロバイダーは、AWS クラウドの VPC 内の Amazon EC2 インスタンスでソリューションをホストしています。プロバイダーのすべてのお客様も AWS クラウド内に環境を持っています。

最近の設計会議で、お客様はプロバイダーの AWS デプロイメントと IP アドレスが重複していることが判明しました。お客様は、内部 IP アドレスを共有せず、プロバイダーの SaaS サービスにインターネット経由で接続したくないと述べています。

これらの要件を満たすソリューションの一部である最適な手順の組み合わせを選択してください。 (2 つ選択)
A
Network Load Balancer の背後に SaaS サービスのエンドポイントをデプロイします。
B
エンドポイントサービスを構成し、エンドポイントサービスへの接続を作成する権限をお客様に付与します。
C
Application Load Balancer の背後に SaaS サービスのエンドポイントをデプロイします。
D
AWS Transit Gateway をデプロイし、SaaS VPC に接続します。Transit Gateway をお客様と共有します。 Transit Gateway でルーティングを構成します。
E
お客様の VPC への VPC ピアリング接続を構成します。NAT ゲートウェイ経由でトラフィックをルーティングします。
問題 1 の説明および補足 
AWS PrivateLink
Network Load Balancer VPC エンドポイントサービス を使用してサービスを非公開で公開し、IP が重複していても機能するため正解です。

・Network Load Balancer の背後に SaaS サービスのエンドポイントをデプロイします。
→Network Load Balancer (NLB) の背後に SaaS サービスのエンドポイントをデプロイすることで、IP が重複していても機能します。NLB は、同じ IP アドレス範囲を持つ複数の VPC 間でのトラフィックを効果的に負荷分散することができます。

・エンドポイントサービスを構成し、エンドポイントサービスへの接続を作成する権限をお客様に付与します。
→VPC エンドポイントサービスを構成し、エンドポイントサービスへの接続を作成する権限をお客様に付与することで、インターネットを経由せずに SaaS サービスに接続することが可能になります。これにより、お客様は内部 IP アドレスを共有せずにサービスを利用できます。

※AWS PrivateLink
AWS PrivateLink は、VPC 間、AWS サービス、およびオンプレミスネットワーク間のプライベート接続を提供し、トラフィックをパブリックインターネットにさらすことなく、異なるアカウントや VPC 間でサービスを接続することが容易になります。これにより、 リージョン内 の 1 つの VPC (サービスプロバイダ) にあるサービス / アプリケーションを、他の VPC (コンシューマ) にプライベートに公開し、コンシューマ VPC がサービスプロバイダ VPC に接続を開始できます。

AWS PrivateLink を使用するには、VPC 内のアプリケーション用に Network Load Balancer を作成し、そのロードバランサを指す VPC エンドポイントサービス設定を作成します。次に、サービスコンシューマがインターフェースエンドポイントを作成します。これにより、サブネット内にプライベート IP アドレスを持つ Elastic Network Interface (ENI) が作成され、サービスへのトラフィックのエントリーポイントとなります。コンシューマとサービスは同じ VPC にある必要はありません。VPC が異なる場合、コンシューマとサービスプロバイダの VPC は重複した IP アドレス範囲を持つことができます。他の VPC 内のサービスにアクセスするためのインターフェース VPC エンドポイントの作成に加えて、AWS PrivateLink を介してサポートされる AWS サービスにプライベートにアクセスするためのインターフェース VPC エンドポイントを作成することができます。

参考URL : AWS PrivateLink

■以下は間違いです。
・お客様の VPC への VPC ピアリング接続を構成します。NAT ゲートウェイ経由でトラフィックをルーティングします。
・AWS Transit Gateway をデプロイし、SaaS VPC に接続します。Transit Gateway をお客様と共有します。 Transit Gateway でルーティングを構成します。
VPC ピアリング Transit Gateway 接続は重複する IP をサポートしていないため間違いです。

VPC ピアリングを使用しても、IP が重複する問題は解決できません。VPC ピアリングでは、異なる VPC 間で IP アドレス範囲が重複している場合、ルーティングが正常に機能しません。
Transit Gateway を使用しても、IP が重複する問題は直接解決できません。Transit Gateway は複数の VPC 間でのネットワーク接続を簡素化できますが、IP アドレスが重複している場合、ルーティングが正常に機能しない可能性があります。

・Application Load Balancer の背後に SaaS サービスのエンドポイントをデプロイします。
Application Load Balancer (ALB) は、IP が重複する場合に問題が発生する可能性があるため間違いです。Network Load Balancer (NLB) を構成する必要があります。

Application Load Balancer (ALB) を使用すると、IP が重複する場合に問題が発生する可能性があります。これは、ALB は IP が重複する状況での負荷分散やルーティングが困難であるためです。代わりに、Network Load Balancer (NLB) を使用することで、同じ IP アドレス範囲を持つ複数の VPC 間でのトラフィックを効果的に負荷分散することができます。
問題2
ある企業は、数千台の Amazon EC2 インスタンスで構成されるワークロードを実行しています。ワークロードは、いくつかのパブリックサブネットとプライベートサブネットを含む VPC で実行されています。パブリックサブネットには、既存のインターネットゲートウェイへの 0.0.0.0/0 のルートがあります。プライベートサブネットには、既存の NAT ゲートウェイへの 0.0.0.0/0 のルートがあります。ソリューションアーキテクトは、EC2 インスタンスのフリート全体を移行して IPv6 を使用する必要があります。プライベートサブネットにある EC2 インスタンスは、パブリックインターネットからアクセスできないようにする必要があります。

これらの要件を満たす最適な方法を選択してください。
A
既存の VPC を更新し、カスタム IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。すべての VPC のルートテーブルを更新し、インターネットゲートウェイに ::/0 のルートを追加します。
B
既存の VPC を更新し、カスタム IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。新しい NAT ゲートウェイを作成し、IPv6 サポートを有効にします。すべてのプライベートサブネットの VPC ルートテーブルを更新し、IPv6 を有効にした NAT ゲートウェイに ::/0 のルートを追加します。
C
既存の VPC を更新し、Amazon が提供する IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。Egress-Only インターネットゲートウェイを作成します。すべてのプライベートサブネットの VPC ルートテーブルを更新し、Egress-Only インターネットゲートウェイに ::/0 のルートを追加します。
D
既存の VPC を更新し、Amazon が提供する IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。すべてのプライベートサブネットの VPC ルートテーブルを更新し、NAT ゲートウェイに ::/0 用のルートを追加します。
問題 2 の説明および補足 
Egress-Only インターネットゲートウェイを使用してアウトバウンド IPv6 トラフィックを有効にする
Egress-Only インターネットゲートウェイは、プライベートサブネット内のインスタンスが IPv6 を使用してインターネットに接続できるため正解です。

Egress-Only インターネットゲートウェイ を使用することで、プライベートサブネット内の Amazon EC2 インスタンスが IPv6 を使用してインターネットにアクセスできるようになります。同時に、インターネットからのアクセスは許可されず、プライベートサブネット内のインスタンスのセキュリティが維持されます。

この選択肢では、既存の VPC を更新し、Amazon が提供する IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。その後、Egress-Only インターネットゲートウェイを作成し、すべてのプライベートサブネットの VPC ルートテーブルを更新して、Egress-Only インターネットゲートウェイに ::/0 のルートを追加します。これにより、プライベートサブネット内のインスタンスはインターネットに IPv6 でアクセスできるようになりますが、インターネットからアクセスされることはありません。

※Egress-Only インターネットゲートウェイを使用してアウトバウンド IPv6 トラフィックを有効にする
Egress-Only インターネットゲートウェイは水平にスケールされ、冗長で、高度な可用性を持つ VPC コンポーネントで、IPv6 経由での VPC からインターネットへの送信を可能にし、インスタンスとの IPv6 接続が開始されるのを防ぎます。
Egress-Only インターネットゲートウェイは、IPv6 トラフィックでのみ使用されます。IPv4 経由での送信専用のインターネット通信を可能にするには、代わりに NAT ゲートウェイを使用します。


IPv6 アドレスはグローバルに一意であるため、デフォルトではパブリックアドレスになっています。インスタンスにインターネットにアクセスさせる場合で、インターネット上のリソースにインスタンスとの通信を開始させないようにする場合は、Egress-Only インターネットゲートウェイを使用できます。これを行うには、Egress-Only インターネットゲートウェイを VPC で作成し、次にすべての IPv6 トラフィック (::/0) または特定の IPv6 アドレスの範囲をポイントするルートテーブルに、Egress-Only インターネットゲートウェイへのルートを追加します。ルートテーブルに関連付けられるサブネットの IPv6 トラフィックは、Egress-Only インターネットゲートウェイにルーティングされます。

Egress-Only インターネットゲートウェイはステートフルです。サブネットのインスタンスからインターネットや他の AWS のサービスに転送し、インスタンスに応答を戻します。

Egress-Only インターネットゲートウェイには、次のプロパティがあります :

・Egress-Only インターネットゲートウェイとセキュリティグループを関連付けることはできません。セキュリティグループは、プライベートサブネットのインスタンスに対して使用し、それらのインスタンスに出入りするトラフィックを管理できます。
・ネットワーク ACL を使用して、Egress-Only インターネットゲートウェイがサブネットとの間でルーティングするトラフィックを制御できます。
参考URL : Egress-Only インターネットゲートウェイを使用してアウトバウンド IPv6 トラフィックを有効にする

■以下は間違いです。
・既存の VPC を更新し、Amazon が提供する IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。すべてのプライベートサブネットの VPC ルートテーブルを更新し、NAT ゲートウェイに ::/0 用のルートを追加します。
・既存の VPC を更新し、カスタム IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。新しい NAT ゲートウェイを作成し、IPv6 サポートを有効にします。すべてのプライベートサブネットの VPC ルートテーブルを更新し、IPv6 を有効にした NAT ゲートウェイに ::/0 のルートを追加します。
→NAT ゲートウェイは IPv6 トラフィックをサポートしていないため間違いです。

・既存の VPC を更新し、カスタム IPv6 CIDR ブロックを VPC およびすべてのサブネットに関連付けます。すべての VPC のルートテーブルを更新し、インターネットゲートウェイに ::/0 のルートを追加します。
→インターネットからインスタンスへのアクセスを許可するため間違いです。

この方法ではインターネットからプライベートサブネット内のインスタンスへのアクセスが許可されてしまい、セキュリティ上の要件を満たせません。
問題3
ある共有ワークスペース企業内のデータエンジニアリングチームは、スペース予約システムで生成されるすべてのウェブログに対して一元化されたログシステムを構築したいと考えています。同社には、ウェブサイトで共有スペース予約のリクエストを処理する Amazon EC2 インスタンスのフリートがあります。データエンジニアリングチームは、すべてのウェブログを、ほぼリアルタイムの検索エンジンを提供するサービスに取り込みたいと考えています。データエンジニアリングチームは、ログ記録システムの保守と運用を管理したくありません。

AWS 内でウェブログ記録システムを効率的にセットアップできるソリューションを選択してください。
A
Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Data Streams を CloudWatch にサブスクライブします。ウェブログの最終宛先として Amazon OpenSearch Service を選択します。
B
Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Data Firehose 配信ストリームを CloudWatch にサブスクライブします。ウェブログの最終宛先として Amazon OpenSearch Service を選択します。
C
Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Firehose 配信ストリームを CloudWatch にサブスクライブします。ウェブログの最終宛先として Amazon DynamoDB を設定します。
D
Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Data Streams を CloudWatch にサブスクライブします。Splunk をウェブログの最終宛先として設定します。
問題 3 の説明および補足 
Amazon Kinesis Data Firehose
Amazon Kinesis Data Firehose は、Amazon CloudWatch Logs と統合し、Amazon OpenSearch Service にデータをストリーミングするためのマネージドソリューションを提供するため正解です。

Amazon Kinesis Data Firehose は、 Amazon CloudWatch Logs と統合して、データを Amazon OpenSearch Service にストリーミングすることができます。このマネージドソリューションを使用することで、データエンジニアリングチームはログ記録システムの保守と運用を管理する必要がなくなります。

まず、Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングします。次に、Amazon Kinesis Data Firehose 配信ストリームを CloudWatch にサブスクライブして、ウェブログを Amazon OpenSearch Service に転送します。これにより、データエンジニアリングチームはほぼリアルタイムの検索エンジンを実現できます。

■以下は間違いです。
・Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Firehose 配信ストリームを CloudWatch にサブスクライブします。ウェブログの最終宛先として Amazon DynamoDB を設定します。
→Amazon Kinesis Data Firehose は宛先として Amazon DynamoDB をサポートしておらず、Amazon DynamoDB はログの理想的なストレージソリューションではないため間違いです。

Amazon Kinesis Data Firehose は Amazon DynamoDB を宛先としてサポートしていません。また、Amazon DynamoDB は主にキー・バリュー型のデータストレージに最適化されており、ログデータの検索や分析には適していません。そのため、この選択肢はウェブログ記録システムには適していません。

・Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Data Streams を CloudWatch にサブスクライブします。Splunk をウェブログの最終宛先として設定します。
→Amazon Kinesis Data Streams によってウェブログ記録システムの保守・運用が増えます。また、Splunk を別途購入する必要があるため間違いです。

Amazon Kinesis Data Streams を使用すると、データエンジニアリングチームはログ記録システムの保守・運用を行う必要があります。さらに、 Splunk は別途購入が必要であり、コスト面でも効率的でないため、この選択肢は間違いです。

・Amazon CloudWatch エージェントを設定して、ウェブログを CloudWatch Logs にストリーミングし、Amazon Kinesis Data Streams を CloudWatch にサブスクライブします。ウェブログの最終宛先として Amazon OpenSearch Service を選択します。
→Amazon Kinesis Data Streams は、データ収集や Amazon OpenSearch Service への取り込みなど、ウェブログ記録システムの保守・運用の手間が増えるため間違いです。

Amazon Kinesis Data Streams を使用すると、データエンジニアリングチームはデータ収集や Amazon OpenSearch Service への取り込みに関連するタスクを手動で行う必要があります。これにより、保守・運用の手間が増えるため、この選択肢はウェブログ記録システムに適していません。
問題4
ある企業が AWS クラウドに新しいアプリケーションをデプロイしています。同社は、Elastic Load Balancer の背後にある可用性の高いウェブサーバーを必要としています。ロードバランサーは、リクエスト内の URL に基づいて複数のターゲットグループにリクエストをルーティングします。すべてのトラフィックで HTTPS を使用する必要があります。TLS 処理は、ロードバランサーにオフロードする必要があります。ウェブサーバーは、会社がセキュリティ目的で正確なログを残すことができるように、ユーザーの IP アドレスを認識している必要があります。

これらの要件を満たすソリューションを選択してください。
A
HTTPS リスナーを使用して Application Load Balancer をデプロイします。パスベースのルーティングルールを使用して、トラフィックを正しいターゲットグループに転送します。ターゲットへのトラフィックに X-Forwarded-For リクエストヘッダーを含めます。
B
各ドメインの TLS リスナーを使用して Network Load Balancer をデプロイします。ホストベースのルーティングルールを使用して、各ドメインの正しいターゲットグループにトラフィックを転送します。ターゲットへのトラフィックに対して、クライアント IP アドレスの保存を設定します。
C
TLS リスナーを使用して Network Load Balancer をデプロイします。パスベースのルーティングルールを使用して、トラフィックを正しいターゲットグループに転送します。ターゲットへのトラフィックに対して、クライアント IP アドレスの保存を設定します。
D
各ドメインに HTTPS リスナーを使用して Application Load Balancer をデプロイします。ホストベースのルーティングルールを使用して、各ドメインの正しいターゲットグループにトラフィックを転送します。ターゲットへのトラフィックに X-Forwarded-For リクエストヘッダーを含めます。
問題 4 の説明および補足 
X-Forwarded-For
Application Load Balancer は SSL 終端とパスベースのルーティングをサポートし、リクエストの URL に基づいて異なるターゲットグループにリクエストをルーティングできるため正解です。また、X-Forwarded-For ヘッダーもサポートされているため、HTTP または HTTPS ロードバランサーを使用するときにクライアントの IP アドレスを識別できます。

Application Load Balancer は、SSL 終端を行い、TLS 処理をロードバランサーにオフロードできます。これにより、すべてのトラフィックで HTTPS を使用する要件が満たされます。また、パスベースのルーティング機能を利用して、リクエスト内の URL に基づいて複数のターゲットグループにリクエストをルーティングすることができます。

さらに、Application Load Balancer は X-Forwarded-For リクエストヘッダーをサポートしており、これによってウェブサーバーはユーザーの IP アドレスを認識することができます。この機能を利用することで、企業はセキュリティ目的で正確なログを残すことが可能になります。

※X-Forwarded-For
X-Forwarded-For リクエストヘッダーは、HTTP または HTTPS ロードバランサーを使用する場合に、クライアントの IP アドレスを識別するのに役立ちます。ロードバランサーはクライアント / サーバー間のトラフィックをインターセプトするので、サーバーアクセスログにはロードバランサーの IP アドレスのみが含まれます。クライアントの IP アドレスを確認するには、routing.http.xff_header_processing.mode 属性を使用します。この属性を使用すると、Application Load Balancer がターゲットにリクエストを送信する前に、HTTP リクエストの X-Forwarded-For ヘッダーを変更、保持、削除できます。この属性に指定できる値は、append、preserve、および remove です。この属性のデフォルト値は append です。
参考URL : X-Forwarded-For

■以下は間違いです。
・TLS リスナーを使用して Network Load Balancer をデプロイします。パスベースのルーティングルールを使用して、トラフィックを正しいターゲットグループに転送します。ターゲットへのトラフィックに対して、クライアント IP アドレスの保存を設定します。
・各ドメインの TLS リスナーを使用して Network Load Balancer をデプロイします。ホストベースのルーティングルールを使用して、各ドメインの正しいターゲットグループにトラフィックを転送します。ターゲットへのトラフィックに対して、クライアント IP アドレスの保存を設定します。
Network Load Balancer はパスベースまたはホストベースのルーティングをサポートしていないため間違いです。

Network Load Balancer はパスベースのルーティングやホストベースのルーティングをサポートしていません。そのため、リクエスト内の URL に基づいて複数のターゲットグループにリクエストをルーティングする要件を満たすことができません。これらの機能は、Application Load Balancer を使用することで実現できます。

・各ドメインに HTTPS リスナーを使用して Application Load Balancer をデプロイします。ホストベースのルーティングルールを使用して、各ドメインの正しいターゲットグループにトラフィックを転送します。ターゲットへのトラフィックに X-Forwarded-For リクエストヘッダーを含めます。
→各ドメインの Application Load Balancer は必要ないため間違いです。ALB は、複数の TLS 証明書をサポートしています。

実際には、単一の Application Load Balancer で複数の TLS 証明書をサポートし、ホストベースのルーティングを使用してトラフィックを適切なターゲットグループに転送することができます。そのため、各ドメインごとに個別の Application Load Balancer をデプロイする必要はありません。
問題5
宇宙開発会社は、多数の画像と夜空のデータをキャプチャする一連の望遠鏡を所有しています。画像とデータは、Application Load Balancer (ALB) に割り当てられたターゲットグループの AWS Fargate でホストされているアプリケーションで処理されます。このアプリケーションは、https://space.example.com のアドレスで利用可能です。

科学者は、Auto Scaling グループ内の複数の Amazon EC2 インスタンスでホストされる別のカスタムビルドアプリケーションを必要とします。このアプリケーションは、https://space.example.com/meteor のアドレスから利用可能になります。同社は、夜間の少数のリクエストから、将来の流星群に対する多数のリクエストに自動的にスケーリングできるソリューションを必要としています。

これらの要件を満たす最も運用効率の高いソリューションを選択してください。
A
Amazon CloudFront ディストリビューションの背後に ALB を配置します。リクエスト URI を解析し、EC2 インスタンスの IP アドレスを含む path-pattern ヘッダーを /meteor のリクエストに追加する Lambda@Edge 関数を作成します。HTTP ヘッダーを検索し、EC2 インスタンスの IP アドレスを使用してトラフィックを転送するリスナールールを ALB に追加します。
B
既存のターゲットグループを新しい EC2 インスタンスで更新します。アプリケーションの ALB を更新し、/meteor を新しく追加された EC2 インスタンスにリダイレクトするリスナールールを追加します。
C
Network Load Balancer (NLB) を作成します。NLB を 2 つのポートでリッスンするように構成します。1 つ目のポートのターゲットグループを構成して、すべての IP トラフィックを Auto Scaling グループに配信し、カスタム画像を処理します。2 つ目のポートにターゲットグループを設定し、すべての IP トラフィックを Fargate に配信します。 ALB でパスベースのルーティングを使用して、URL プレフィックス /meteor のトラフィックを最初のターゲットグループに転送します。その他のパスはすべて 2 つ目のターゲットグループにルーティングします。
D
新しいターゲットグループを作成します。EC2 インスタンスの Auto Scaling グループがそのターゲットグループを使用するように設定します。新しいターゲットグループに /meteor をリダイレクトするリスナールールを追加して、ALB を更新します。
問題 5 の説明および補足 
Application Load Balancer でのパスベースのルーティング
ALB は パスベースのルーティング をサポートし、/meteor を処理するために新しいターゲットグループとリスナーを作成することができるため正解です。

Application Load Balancer (ALB) は、パスベースのルーティングをサポートしており、異なるターゲットグループにトラフィックを分配することができます。これにより、宇宙開発会社は新しいターゲットグループを作成し、EC2 インスタンスの Auto Scaling グループがそのターゲットグループを使用するように設定できます。さらに、/meteor をリダイレクトするリスナールールを追加して ALB を更新することで、/meteor へのアクセスを新しいターゲットグループにルーティングできます。

このソリューションは、宇宙開発会社が必要とする自動スケーリング機能を提供し、他の選択肢と比較して最も運用効率が高いといえます。

※Application Load Balancer でのパスベースのルーティングを実現するにはどうすればよいですか ?
Application Load Balancer では、URL に基づいてリクエストをターゲットグループに転送するルールを持つリスナーを作成できます。この機能は、Classic Load Balancer、Network Load Balancer、Gateway Load Balancer など、他の種類のロードバランサーでは使用できません。

Application Load Balancer でパスベースのルーティングを確立するには、次の操作を実行します。

1. ターゲットグループを作成します。
2. リスナールールを設定します。
参考URL : Application Load Balancer でのパスベースのルーティングを実現するにはどうすればよいですか ?

■以下は間違いです。
・Amazon CloudFront ディストリビューションの背後に ALB を配置します。リクエスト URI を解析し、EC2 インスタンスの IP アドレスを含む path-pattern ヘッダーを /meteor のリクエストに追加する Lambda@Edge 関数を作成します。HTTP ヘッダーを検索し、EC2 インスタンスの IP アドレスを使用してトラフィックを転送するリスナールールを ALB に追加します。
→アプリケーションの スケーリング に役立たないため間違いです。

Amazon CloudFront と Lambda@Edge 関数を使用しても、アプリケーションの自動スケーリングが実現できません。宇宙開発会社はアプリケーションが自動的にスケーリングされることを求めているため、この選択肢は適切ではありません。

・Network Load Balancer (NLB) を作成します。NLB を 2 つのポートでリッスンするように構成します。1 つ目のポートのターゲットグループを構成して、すべての IP トラフィックを Auto Scaling グループに配信し、カスタム画像を処理します。2 つ目のポートにターゲットグループを設定し、すべての IP トラフィックを Fargate に配信します。 ALB でパスベースのルーティングを使用して、URL プレフィックス /meteor のトラフィックを最初のターゲットグループに転送します。その他のパスはすべて 2 つ目のターゲットグループにルーティングします。
→トラフィックは主に HTTPSであり、NLB よりも ALB が理想的であるため間違いです。

Network Load Balancer (NLB) は主に TCP/UDP トラフィックに対して最適化されており、HTTPS やパスベースのルーティングには適していません。そのため、ALB を使用する方が効果的です。

・既存のターゲットグループを新しい EC2 インスタンスで更新します。アプリケーションの ALB を更新し、/meteor を新しく追加された EC2 インスタンスにリダイレクトするリスナールールを追加します。
→既存のターゲットグループが ルーティングを処理できない ため間違いです。

既存のターゲットグループを新しい EC2 インスタンスで更新しても、/meteor へのアクセスを適切にルーティングできません。パスベースのルーティングを使用するためには、新しいターゲットグループとリスナールールが必要です。
問題6
ある会社は、オンプレミスのデータセンターと Amazon VPC の間に 10Gbps の AWS Direct Connect 接続を持っています。VPC 内の Amazon EC2 インスタンスで実行されているアプリケーションは、オンプレミスのデータセンターに保存されている機密データに、利用可能な最高の帯域幅で一貫したパフォーマンスでアクセスする必要があります。コンプライアンスのために、データの暗号化が必要です。

これらの要件を最も効率的に運用する最適な方法を選択してください。
A
10 Gbps 接続の Direct Connect MACsec 暗号化を構成します。
B
Direct Connect 接続でパブリック仮想インターフェースを構成します。カスタマーゲートウェイと VPC 内の仮想プライベートゲートウェイとの間に AWS Site-to-Site VPN を設定します。
C
Direct Connect 接続でプライベート仮想インターフェースを構成します。カスタマーゲートウェイと VPC 内の仮想プライベートゲートウェイとの間に AWS Site-to-Site VPN を設定します。
D
VPC にインターネットゲートウェイを構成します。カスタマーゲートウェイと VPC 内の仮想プライベートゲートウェイとの間に AWS Site-to-Site VPN を設定します。
問題 6 の説明および補足 
MAC セキュリティ
MACsec を使用した Direct Connect は、運用効率の高い方法で、利用可能な最大帯域幅で安全に AWS とデータを交換するのに役立つため正解です。

MACsec は、有線イーサネットネットワークにおける暗号化のためのプロトコルであり、データの保護とコンプライアンスを提供します。MACsec を使用した Direct Connect は、最大帯域幅で安全かつ効率的にデータを交換することができます。このため、この選択肢は最も効率的な運用方法を提供し、要件を満たします。

※MAC セキュリティ
MAC Security (MACsec) は IEEE 標準の 1 つです。データの機密性、データの整合性、およびデータオリジンの信頼性を定義しています。MACsec をサポートする AWS Direct Connect 接続を使用して、企業のデータセンターから AWS Direct Connect ロケーションへのデータを暗号化できます。データセンターおよびリージョンと相互接続する AWS グローバルネットワークを流れるすべてのデータは、データセンターを離れる前に物理層で自動的に暗号化されます。

次の図では、専用接続とオンプレミスのリソースの両方が MacSec をサポートしている必要があります。データセンターとの間にある、専用接続を通過するレイヤ 2 トラフィックは暗号化されます。


これまで、ネットワークと AWS の間で転送中のデータをマルチギガビットの速度で保護するには、単一の VPN 接続を使用する場合のスループット制限を避けるために複数の IPsec VPN トンネルを集約する必要がありました。このようなソリューションは複雑であるため、運用リスクが高まり、10 Gbps を超える高速接続を確保することによる利点がなくなります。MACsec サポートのリリースにより、AWS Direct Connect は、10 Gbps および 100 Gbps の専用接続に対してネイティブでほぼラインレートのポイントツーポイント暗号化を提供するようになり、AWS とデータセンター、オフィス、またはコロケーション施設との間のデータ通信が引き続き保護されます。
参考URL : MAC セキュリティ

■以下は間違いです。
・VPC にインターネットゲートウェイを構成します。カスタマーゲートウェイと VPC 内の仮想プライベートゲートウェイとの間に AWS Site-to-Site VPN を設定します。
VPN は安全な接続性を提供するだけであり、安定したパフォーマンスを提供することはできないため間違いです。

インターネットゲートウェイを通じた VPN 接続を提案していますが、安全な接続性を提供するだけであり、帯域幅の制約や安定性の問題があるため、安定したパフォーマンスを提供することはできません。

・Direct Connect 接続でパブリック仮想インターフェースを構成します。カスタマーゲートウェイと VPC 内の仮想プライベートゲートウェイとの間に AWS Site-to-Site VPN を設定します。
・Direct Connect 接続でプライベート仮想インターフェースを構成します。カスタマーゲートウェイと VPC 内の仮想プライベートゲートウェイとの間に AWS Site-to-Site VPN を設定します。
VPN over AWS Direct Connect は、利用可能な最高の帯域幅でパフォーマンスを提供しないため間違いです。

VPN 接続は、暗号化や安全性のために追加のオーバーヘッドをもたらすため、最大帯域幅でのパフォーマンスが得られません。これは、オンプレミスのデータセンターと Amazon VPC の間で利用可能な最高の帯域幅で一貫したパフォーマンスを提供するという要件に適合しません。
問題7
ある企業には、Auto Scaling グループの Amazon EC2 インスタンスでホストされているステートフルなウェブアプリケーションがあります。インスタンスは、単一のターゲットグループを持つ Application Load Balancer (ALB) の背後で実行されます。この ALB は、Amazon CloudFront ディストリビューションのオリジンとして設定されています。ユーザーが、ウェブアプリケーションからランダムにログアウトすることが報告されています。

この問題を解決する最適な手順の組み合わせを選択してください。(2 つ選択)
A
ALB のターゲットグループでスティッキーセッションを有効にします。
B
CloudFront ディストリビューションのキャッシュ動作でヘッダー転送を設定します。
C
ALB のターゲットグループの最小未処理リクエストアルゴリズムに変更します。
D
ALB リスナールールでグループレベルのスティッキーネスを有効にします。
E
CloudFront ディストリビューションのキャッシュ動作で Cookie 転送を設定します。
問題 7 の説明および補足 
スティッキーセッション
ログアウトの理由は、セッションが維持されず、リクエストが異なるインスタンスに送信されるためです。スティッキーセッションは、Cookie 転送用に設定された Application Load Balancer と Amazon CloudFront に対して有効にする必要があります。

・CloudFront ディストリビューションのキャッシュ動作で Cookie 転送を設定します。
→Amazon CloudFront ディストリビューションのキャッシュ動作で Cookie 転送を設定することにより、セッション情報を維持できます。これによって、ユーザーがログアウトする問題が解決されます。

・ALB のターゲットグループでスティッキーセッションを有効にします。
→Application Load Balancer (ALB) のターゲットグループでスティッキーセッションを有効にすることで、ユーザーのリクエストが同じインスタンスに送信され続けます。これにより、セッションが維持され、ログアウト問題が解消されます。

※Application Load Balancer のスティッキーセッション
デフォルトでは、Application Load Balancer は、選択したロードバランシングアルゴリズムに基づいて、登録されたターゲットに各リクエストを個別にルーティングします。ただし、スティッキーセッション機能 (セッションアフィニティとも呼ばれます) を使用して、ロードバランサーがユーザーのセッションを特定のターゲットにバインドするように設定できます。これにより、ユーザーのセッション中のすべてのリクエストが同じターゲットに送信されます。これは、クライアントに連続したエクスペリエンスを提供するために状態情報を維持するサーバーに役立ちます。スティッキーセッションを使用するには、クライアントが Cookie をサポートする必要があります。

Application Load Balancer は、期間ベースの Cookie とアプリケーションベースの Cookie の両方をサポートします。スティッキーセッションの管理において重要なのは、ロードバランサーがユーザーのリクエストを同じターゲットに一貫してルーティングする期間の決定です。ターゲットグループレベルでスティッキーセッションを有効にします。すべてのターゲットグループで、期間ベースの維持、アプリケーションベースの維持、および維持しないの組み合わせを使用できます。
参考URL : Application Load Balancer のスティッキーセッション

※Cookie に基づくコンテンツのキャッシュ
デフォルトでは、CloudFront はリクエストとレスポンスを処理するとき、またはオブジェクトをエッジロケーションにキャッシュするときに Cookie を考慮しません。CloudFront が Cookie ヘッダーに含まれる内容以外は同一の 2 つのリクエストを受信した場合、デフォルトでは、CloudFront はリクエストを同一として扱い、両方のリクエストに対して同じオブジェクトを返します。
参考URL : Cookie に基づくコンテンツのキャッシュ

■以下は間違いです。
・ALB リスナールールでグループレベルのスティッキーネスを有効にします。
→スティッキーネスは、セッション維持に役立ちますが、リスナールールではなく、Application Load Balancer のターゲットグループで設定する必要があります。この選択肢では、問題が解決されません。

※Application Load Balancer がアプリケーション Cookie のスティッキーネスのサポートを開始
Application Load Balancer (ALB) がアプリケーション Cookie のスティッキーネスのサポートを開始しました。この新機能は、クライアントがアプリケーション Cookie を使用して、セッション中に同じターゲットのロードバランサーに接続できることを保証するのに役立ちます。これにより、カスタム Cookie 名を設定する柔軟性や、ターゲットグループ内でのクライアントターゲットのスティッキーネスの基準など、より優れた制御により、一貫性のあるクライアントサーバー体験を実現できます。
参考URL : Application Load Balancer がアプリケーション Cookie のスティッキーネスのサポートを開始

・CloudFront ディストリビューションのキャッシュ動作でヘッダー転送を設定します。
→ヘッダー転送は、キャッシュ動作と関連する設定であり、セッション維持とは直接関係がありません。問題を解決するためには、Cookie 転送を設定する必要があります。

・ALB のターゲットグループの最小未処理リクエストアルゴリズムに変更します。
→最小未処理リクエストアルゴリズムは、リクエストのロードバランシングに関するものであり、セッションの維持には関係ありません。したがって、この選択肢ではログアウト問題は解決されません。

※Application Load Balancer のターゲットグループ
各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。各リスナーのルールを作成するときに、ターゲットグループと条件を指定します。ルールの条件が満たされると、トラフィックが該当するターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。
参考URL : Application Load Balancer のターゲットグループ

※最小未処理リクエストアルゴリズム
最小未処理リクエスト (LOR) アルゴリズムを使用してターゲットグループ内でリクエストをルーティングすることを選択できます。このアルゴリズムを使用すると、新しいリクエストが到着したときにロードバランサーが未処理のリクエスト数が 最も少ないターゲット にリクエストを送信します。長期にわたるリクエストを処理するターゲットや処理能力が低いターゲットは、リクエストが増えても負荷がかからず、ターゲット全体に負荷が均等に分散されます。これは、新しいターゲットが過負荷のターゲットから効果的に負荷を取り除くためにも役立ちます。
参考URL : 最小未処理リクエストアルゴリズム
学習を記録
問題は全部で 7 問。全て答えられるように頑張りましょう!
リスト
戻る
網掛け部分は完了した項目です。
12345
67ゴール
戻る
error: