type
status
date
slug
summary
tags
category
icon
password
431-AWS SAP AWS 「理論・実践・一問道場」CIDR重複 VPC接続 単方向
理論
複数VPC間での接続方法とその考慮事項
1. VPCピアリング
- 概要: VPCピアリングは、2つのVPCを直接接続し、リソースが相互に通信できるようにするAWSの機能です。
- 制限:
- CIDRブロックの重複: ピアリング接続するVPCのCIDRが重複している場合、正常にルーティングできません。これが原因で接続が失敗することがあります。
- ルーティング制御: ピアリング接続後、各VPCのルーティングテーブルを設定する必要があります。
2. AWS Transit Gateway
- 概要: Transit Gatewayは、複数のVPCを中央で接続するサービスです。これにより、大規模なVPCの接続管理が簡素化されます。
- 制限:
- CIDR重複: Transit Gatewayでは、接続するVPCのCIDRが重複している場合、問題が発生します。異なるCIDRブロックを持つVPC同士でのみ機能します。
3. VPCエンドポイントサービス
- 概要: VPCエンドポイントサービスは、NLBを利用して、サービスへのアクセスをVPC間で提供する方法です。クライアントVPCは、エンドポイントサービスに接続するためにVPCエンドポイントを作成します。
- 利点:
- セキュリティ: エンドポイント承認機能を使用すると、アクセスを特定のVPCに制限でき、セキュリティが向上します。
- CIDR重複に対応: VPCエンドポイントサービスは、CIDR重複の問題なく利用できます。
- 運用:
- アクセス管理: 承認されたVPCに対してのみ接続を許可することができます。
4. Site-to-Site VPN
- 概要: Site-to-Site VPNは、オンプレミスとAWS VPC間、またはVPC間でセキュアな接続を提供するための方法です。
- 制限:
- CIDR重複: VPN接続の場合もCIDRブロックの重複が問題となり、正常に動作しない可能性があります。
重要なポイント:
- CIDRブロックの重複: CIDRが重複している場合、VPCピアリングやVPN接続、Transit Gatewayの利用には制限があります。
- VPCエンドポイントサービス: CIDR重複を避けつつ、セキュアにVPC間でサービスを提供する場合には、VPCエンドポイントサービスが適切です。
実践
略
一問道場
問題 #431
ある会社は、単一の共有VPCにホストされた集中型のAmazon EC2アプリケーションを提供しています。この集中型アプリケーションは、他の事業部門のVPCにあるクライアントアプリケーションからアクセスできる必要があります。集中型アプリケーションのフロントエンドは、スケーラビリティのためにNetwork Load Balancer (NLB)で設定されています。最大10個の事業部門VPCが共有VPCに接続する必要があり、いくつかの事業部門VPCのCIDRブロックは共有VPCと重複しており、またお互いに重複しています。共有VPC内の集中型アプリケーションへのネットワーク接続は、認証された事業部門VPCからのみ許可されるべきです。
この要件に基づき、事業部門VPCのクライアントアプリケーションから共有VPC内の集中型アプリケーションへの接続を提供するためには、どのネットワーク構成を使用すべきですか？
A. AWS Transit Gatewayを作成し、共有VPCと認証された事業部門VPCをTransit Gatewayに接続します。単一のTransit Gatewayルートテーブルを作成し、それをすべての接続されたVPCに関連付けます。接続からのルート自動伝播を許可し、VPCのルーティングテーブルを構成してトラフィックをTransit Gatewayに送信します。
B. 集中型アプリケーションのNLBを使用してVPCエンドポイントサービスを作成し、エンドポイントの承認を必要とするオプションを有効にします。各事業部門VPCにサービス名を使用してVPCエンドポイントを作成し、エンドポイントサービスコンソールで認証されたエンドポイント要求を承認します。
C. 各事業部門VPCから共有VPCへのVPCピアリング接続を作成し、共有VPCコンソールでVPCピアリング接続を承認します。VPCのルーティングテーブルを構成して、トラフィックをVPCピアリング接続に送信します。
D. 共有VPCに仮想プライベートゲートウェイを構成し、各認証された事業部門VPCにカスタマーゲートウェイを作成します。事業部門VPCから共有VPCへのSite-to-Site VPN接続を確立し、VPCのルーティングテーブルを構成して、トラフィックをVPN接続に送信します。
解説
要件の整理:
- CIDR重複: 事業部門VPCのCIDRが共有VPCと重複しているため、通常のVPCピアリングやVPN接続は使えません。
- 認証されたVPCからの接続のみ許可: アクセスを認証されたVPCに制限する必要があります。
- NLBを利用したスケーラビリティ: 共有VPC内の集中型アプリケーションはNLB（Network Load Balancer）でフロントエンドが構成されています。
この要件を基に、選択肢を再評価します。
各選択肢の検討:
A. AWS Transit Gatewayを作成し、共有VPCと認証された事業部門VPCをTransit Gatewayに接続する方法
- 利点: Transit Gatewayは複数のVPCを接続するために使用でき、スケーラビリティや中央集約的な管理が可能ですが、CIDR重複の問題により、この方法は利用できません。CIDRブロックが重複していると、Transit Gateway経由でのルーティングが機能しません。
- 結論: CIDR重複があるため、この方法は適用できません。
B. 集中型アプリケーションのNLBを使用してVPCエンドポイントサービスを作成し、エンドポイントの承認を必要とするオプションを有効にする方法
- 利点: VPCエンドポイントサービスは、NLBを使って集中型アプリケーションへのアクセスを提供します。この方法では、エンドポイント承認機能を利用することで、アクセスを認証されたVPCのみに制限できます。また、VPCエンドポイントサービスはCIDR重複にも対応可能です。
- 欠点: 特にありません。CIDR重複を考慮しても問題なく動作します。
- 結論: 最適な選択肢です。この方法は要件に完全に合致しています。
C. 各事業部門VPCから共有VPCへのVPCピアリング接続を作成する方法
- 利点: VPCピアリングはシンプルにVPC間の接続を提供しますが、CIDR重複がある場合、ルーティングが機能しないため、VPCピアリングは利用できません。
- 結論: CIDR重複により、この方法は適用できません。
D. 共有VPCに仮想プライベートゲートウェイを構成し、各認証された事業部門VPCにカスタマーゲートウェイを作成し、VPN接続を確立する方法
- 利点: VPN接続を利用することで、セキュアな接続が提供できますが、CIDR重複の問題が依然として解決できません。また、複数のVPN接続の管理が煩雑になります。
- 結論: CIDR重複が問題となるため、この方法は適用できません。
結論:
最適解: B
NLBを使用したVPCエンドポイントサービスが最適な方法です。これにより、アクセスが認証されたVPCのみに制限され、CIDR重複の問題にも対応できます。
432-AWS SAP AWS 「理論・実践・一問道場」EKS
理論
1. KubernetesのAWS移行
KubernetesクラスターをオンプレミスからAWSに移行する場合、Amazon Elastic Kubernetes Service (EKS) を利用することが最も簡単で効率的です。EKSは、AWSが管理するKubernetesサービスで、インフラの管理を簡素化し、スケーラビリティや高可用性を提供します。既存のKubernetesマニフェストやアーキテクチャをそのまま活用できるため、移行作業の負担が軽減されます。
- EKSの利点:
- フルマネージドなKubernetes環境を提供
- スケーラビリティ、可用性、セキュリティを簡単に設定可能
- 他のAWSサービス（ECR、RDS、Aurora）との統合がスムーズ
2. コンテナイメージの管理
コンテナ化されたアプリケーションをAWSに移行する際には、Amazon Elastic Container Registry (ECR) を使用するのが一般的です。ECRはAWSのフルマネージド型コンテナイメージリポジトリで、セキュアでスケーラブルなコンテナイメージの管理を提供します。移行時には、オンプレミスのコンテナイメージをECRにアップロードし、その後EKSやECSにデプロイすることが多いです。
- ECRの利点:
- 高可用性とセキュリティが確保されたコンテナリポジトリ
- AWS内の他のサービス（EKS、ECS）との密接な統合
- コンテナイメージの自動スキャン機能によるセキュリティ強化
3. データベースの選択
移行後のデータベースに関しては、AWSではAmazon Aurora や Amazon RDS for PostgreSQL を使用することが一般的です。これらはフルマネージド型データベースサービスで、スケーラビリティ、バックアップ、リストア、パッチ適用などを自動化し、運用の負担を軽減します。
- Amazon Aurora PostgreSQLの利点:
- 高パフォーマンスとスケーラビリティを提供
- RDSと互換性があり、簡単に移行が可能
- 高可用性の設定（Multi-AZ配置）や自動バックアップ機能が提供
4. コンテナオーケストレーションサービスの選択
AWSにはコンテナオーケストレーションのためのサービスとして、Amazon Elastic Kubernetes Service (EKS) と Amazon Elastic Container Service (ECS) の2つの主な選択肢があります。
- EKS vs. ECS:
- EKS はKubernetesを使用している場合に最適で、Kubernetesの柔軟性を活かして高度な設定が可能です。
- ECS はAWS専用のオーケストレーションサービスで、Kubernetesよりも簡便で、AWSに特化した設計がされています。移行時には、コンテナの管理が簡単ですが、Kubernetesのフル機能には対応していません。
5. 運用管理の簡素化
AWSでは、フルマネージドサービス（EKS、RDS、Auroraなど）を利用することで、インフラの管理やメンテナンスの負担を大幅に軽減できます。AWSが提供する管理機能を最大限に活用することで、運用コストや時間を節約し、移行をスムーズに進めることが可能です。
これらの基本的な知識を元に、AWSへの移行は計画的に進めることができます。選択するサービスは、既存のインフラストラクチャや運用方法に最も適したものを選ぶことが重要です。
実践
略
一問道場
問題 #432
ある企業がウェブサイトをAWSに移行したいと考えています。このウェブサイトはマイクロサービスを使用しており、コンテナはオンプレミスの自己管理型Kubernetesクラスターにデプロイされています。Kubernetesデプロイメントを定義するすべてのマニフェストはソースコード管理に格納されています。
ウェブサイトのすべてのデータはPostgreSQLデータベースに格納されています。オンプレミス環境では、オープンソースのコンテナイメージリポジトリが動作しています。
ソリューションアーキテクトは、AWS上でウェブサイトのアーキテクチャを決定する必要があります。
どのソリューションが最小の移行作業でこれらの要件を満たすでしょうか？
A. AWS App Runnerサービスを作成し、App Runnerサービスをオープンソースのコンテナイメージリポジトリに接続します。オンプレミスからマニフェストをApp Runnerサービスにデプロイします。Amazon RDS for PostgreSQLデータベースを作成します。
B. Amazon Elastic Kubernetes Service (Amazon EKS)クラスターを作成し、管理されたノードグループを設定します。アプリケーションコンテナを新しいAmazon Elastic Container Registry (Amazon ECR)リポジトリにコピーします。オンプレミスからマニフェストをEKSクラスターにデプロイします。Amazon Aurora PostgreSQL DBクラスターを作成します。
C. Amazon Elastic Container Service (Amazon ECS)クラスターを作成し、Amazon EC2キャパシティプールを設定します。アプリケーションコンテナを新しいAmazon Elastic Container Registry (Amazon ECR)リポジトリにコピーします。各コンテナイメージを新しいタスク定義として登録します。元のKubernetesデプロイメントに合わせてECSサービスを設定します。Amazon Aurora PostgreSQL DBクラスターを作成します。
D. オンプレミスのKubernetesクラスターをAmazon EC2インスタンス上でホストするように再構築します。オープンソースのコンテナイメージリポジトリをEC2インスタンスに移行します。オンプレミスから新しいAWSクラスターにマニフェストをデプロイします。新しいクラスターにオープンソースのPostgreSQLデータベースをデプロイします。
解説
この問題では、AWSにウェブサイトを移行する際の最小の労力で要件を満たすアーキテクチャを選ぶ必要があります。以下の選択肢ごとの解説を行います。
A. AWS App Runnerサービスを作成し、App Runnerサービスをオープンソースのコンテナイメージリポジトリに接続
- 評価: App Runnerは簡単にコンテナアプリケーションをデプロイできるサービスですが、Kubernetesマニフェストのデプロイや運用に特化していません。Kubernetes環境での移行には不向きです。また、PostgreSQLのデータベースをRDSにすることはできますが、全体的にこの選択肢は機能面で最適ではありません。
- 結論: このオプションはAWSの他のサービスを活用できるものの、Kubernetesで管理されていたアプリケーションに最も適しているとは言えません。
B. Amazon EKSクラスターを作成し、管理されたノードグループを設定
- 評価: EKSはAWSが管理するKubernetes環境で、オンプレミスのKubernetesからの移行には非常に適しています。コンテナイメージをECRに移し、KubernetesマニフェストをEKSにデプロイすることで、オンプレミスで使っていた環境をそのままAWSに再現できます。さらに、Aurora PostgreSQLを使用することでスケーラビリティと高可用性を確保できます。
- 結論: Kubernetesの運用をそのままAWSで行いたい場合、EKSは最も適切な選択肢です。
C. Amazon ECSクラスターを作成し、EC2キャパシティプールを設定
- 評価: ECSもコンテナオーケストレーションサービスですが、Kubernetesに基づく運用から移行する場合、EKSよりも設定や管理の手間がかかる可能性があります。ECSはKubernetesほどの柔軟性は提供しませんが、簡単にコンテナの管理ができる点では便利です。しかし、Kubernetesのマニフェストをそのまま利用するには調整が必要になります。
- 結論: ECSは手軽なオプションですが、Kubernetesの経験がある環境からの移行には少し手間がかかります。
D. オンプレミスのKubernetesクラスターをEC2インスタンスでホストし、コンテナイメージリポジトリも移行
- 評価: EC2インスタンス上でKubernetesクラスターを再構築することは可能ですが、AWS上での運用管理はかなり手間がかかります。EC2でKubernetesを管理するのは、EKSに比べて負担が大きく、AWSの提供する他の機能を活用するのが難しくなります。また、PostgreSQLを自己管理で運用する必要があり、スケーラビリティや可用性がEKSやRDSほど容易には確保できません。
- 結論: オンプレミスの運用をそのままAWSに移行する方法ですが、AWSのマネージドサービスを使わないため、管理が煩雑になりやすく、最小の労力とは言えません。
最適な選択肢
- B: Amazon Elastic Kubernetes Service (Amazon EKS)クラスターを作成する
- 理由: オンプレミスでKubernetesを使用しているため、AWS上でもEKSを使用することで、現在の運用とほぼ同じ環境を再現できます。また、マニフェストの移行や管理が容易であり、スケーラビリティや可用性を確保するためにAmazon Aurora PostgreSQLを利用することが可能です。最も効率的で最小の労力で移行できる選択肢となります。
433-AWS SAP AWS 「理論・実践・一問道場」TTL機能
理論
1. サーバーレスアーキテクチャ
- AWS Lambdaは、サーバーレスなコンピューティングサービスで、コードの実行に必要なインフラの管理を不要にします。Lambdaはイベント駆動型で、指定されたイベントが発生すると自動的にコードが実行されるため、リソースをオンデマンドで使用でき、コストを削減できます。
- サーバーレスアーキテクチャは、スケーリングが自動で行われ、使った分だけ課金されるため、リソースを効率的に使用でき、運用コストを最適化できます。
2. データベースのTTL（Time-to-Live）機能
- DynamoDBのTTL属性は、指定された期限が過ぎると自動的にデータを削除する機能です。この機能は、データが一定の期間後に不要になる場合に非常に役立ち、データの管理を自動化します。コンテストのように一時的なデータを取り扱う場合、TTLを活用することで不要なデータを手動で削除する手間を省けます。
- TTLを使うことで、データが期限切れとなった際にコストが発生するのを防ぎ、データの保持が最小限に抑えられるため、ストレージコストを削減できます。
3. スケーラブルなデータストレージ
- Amazon DynamoDBは、高速でスケーラブルなNoSQLデータベースです。高い可用性を誇り、大規模なデータストレージに対応しており、トランザクションを扱う場面でも強力です。特に、スケールアップやスケールダウンが必要な場合、DynamoDBは効率的に対応できます。
- DynamoDBは、低レイテンシーで高いスループットを提供するため、大規模なWebアプリケーションや一時的なデータ保存に適しています。
4. AWS Fargate
- AWS Fargateは、コンテナ化されたアプリケーションの実行にサーバーレスなコンテナ管理サービスです。インフラの管理なしにコンテナを実行でき、アプリケーションのスケーラビリティや高可用性を簡単に達成できます。Fargateを使うことで、計算リソースを効率的に管理でき、運用負担が軽減されます。
- サーバーレスであるため、必要なコンテナリソースだけを消費し、無駄なコストが発生しません。
5. コスト効率の高いアーキテクチャ設計
- コスト削減のためには、使用するリソースを最適化する必要があります。例えば、不要なデータを早期に削除する、サーバーレスサービスを使用してリソースを動的にスケールする、データベースのTTL機能を使ってデータの寿命を管理する、などが効果的です。
- 定期的に使用状況を監視し、不要なリソースを削減することも、コスト管理の重要な手段です。
これらの知識は、コストを最適化しつつ効率的なシステムを構築するために役立ちます。特に、サーバーレスアーキテクチャやTTL機能、スケーラブルなデータベースの組み合わせは、効率的で柔軟なシステム設計において非常に有用です。
実践
略
一問道場
問題 #433
ある会社はAWSでオンラインコンテストを実施するためのモバイルアプリを使用しています。コンテスト終了時にランダムに当選者を選びます。コンテストは時間の長さが変動しますが、コンテストが終了した後はデータを保持する必要はありません。会社はカスタムコードを使用して、Amazon EC2インスタンスでコンテストデータを処理し、当選者を選びます。EC2インスタンスはアプリケーションロードバランサーの背後で実行され、コンテストのエントリーはAmazon RDS DBインスタンスに保存されます。会社は、コンテストの実行コストを削減するための新しいアーキテクチャを設計する必要があります。
どのソリューションが最もコスト効率よく要件を満たしますか？
A. コンテストエントリーの保存をAmazon DynamoDBに移行します。DynamoDB Accelerator（DAX）クラスタを作成します。コードをAmazon Elastic Container Service (Amazon ECS)コンテナとして書き換え、Fargate起動タイプを使用します。コンテスト終了時にDynamoDBテーブルを削除します。
B. コンテストエントリーの保存をAmazon Redshiftに移行します。コードをAWS Lambda関数として書き換えます。コンテスト終了時にRedshiftクラスタを削除します。
C. Amazon ElastiCache for RedisクラスタをRDS DBインスタンスの前に追加して、コンテストエントリーをキャッシュします。コードをAmazon Elastic Container Service (Amazon ECS)コンテナとして書き換え、Fargate起動タイプを使用します。ElastiCacheのTTL属性を設定して、各エントリーがコンテスト終了時に期限切れになるようにします。
D. コンテストエントリーの保存をAmazon DynamoDBに移行します。コードをAWS Lambda関数として書き換えます。DynamoDBのTTL属性を設定して、各エントリーがコンテスト終了時に期限切れになるようにします。
解説
この問題では、コンテストデータの管理方法とアーキテクチャの変更を通じて、コスト削減を目指しています。選択肢ごとに解説します。
A. DynamoDB + DAX + ECS (Fargate)
- DynamoDB はスケーラブルで高速なNoSQLデータベースで、読み書きが頻繁に行われる場面に適しています。コンテストデータをDynamoDBに保存することで、データベース管理の手間を削減し、コストを抑えることができます。
- DAX (DynamoDB Accelerator) は、DynamoDBに対するキャッシュを提供し、読み取り性能を向上させます。これにより、アクセス頻度の高いデータに対して速やかなレスポンスが可能になります。
- Amazon ECS と Fargate は、サーバーレスなコンテナオーケストレーションサービスです。Fargateを使うことで、インフラ管理なしでコンテナの実行が可能となり、コストと運用の負担を軽減できます。
- コンテスト終了後、DynamoDBテーブルの削除により不要なデータの保存コストが削減されます。
この構成は、スケーラビリティ、パフォーマンス、そして運用コストを最適化する方法として非常にコスト効率が良いです。
B. Redshift + AWS Lambda
- Amazon Redshift はデータウェアハウスサービスで、大量のデータの集計や分析に特化していますが、リアルタイムのデータ処理には不向きです。コンテストのような短期的で大量のトランザクションを処理するシナリオには適しません。
- AWS Lambda はイベント駆動型のサーバーレスコンピューティングサービスですが、Redshiftとの組み合わせはコスト効率が良いとは言えません。Redshiftはデータウェアハウスであり、トランザクションデータの処理にはオーバーヘッドが大きくなるため、この構成は最適ではありません。
C. ElastiCache for Redis + ECS (Fargate)
- ElastiCache for Redis はインメモリデータストアで、データアクセスの高速化を提供します。データをRDSからキャッシュすることは一部のパフォーマンス改善には役立ちますが、コスト削減には限界があります。
- Redisはコンテスト終了後にTTL（Time-To-Live）を設定してデータを自動的に削除することができますが、このアーキテクチャは、頻繁にデータをキャッシュしてクリーンアップするための追加のリソースを消費し、コスト削減に直結しない可能性があります。
D. DynamoDB + AWS Lambda
- DynamoDB はスケーラブルで、NoSQLデータベースとして非常に高性能です。コンテストエントリーのデータを保存し、TTL属性を使用してデータの有効期限を設定することで、コンテスト終了後に自動的にデータを削除できます。
- AWS Lambda は、サーバーレスコンピューティング環境で、イベント駆動型に非常に適しています。Lambdaを使用することで、コンテストの終了後のデータ処理や当選者の選定を簡素化できます。
- コンテストデータが不要になると、TTL属性により自動的に削除され、ストレージコストを抑えることができます。
最適な選択
最もコスト効率が高いのは D. DynamoDB + AWS Lambda です。以下の理由からです：
- DynamoDBはスケーラブルで、必要なデータを保存し、TTL機能で不要なデータを自動的に削除できます。
- AWS Lambdaはサーバーレスで、リソースをオンデマンドで利用するため、無駄なコストが発生しません。
- この組み合わせにより、運用コストを抑え、簡単にスケールでき、コンテストの終了後にはデータを自動的に削除できるため、最も効率的です。
このように、データベースの管理をシンプルにし、サーバーレスなアーキテクチャでコストを削減することが重要です。
434-AWS SAP AWS 「理論・実践・一問道場」ソース/デスティネーションチェック
理論
この問題に関連する汎用的知識は、ネットワークのトラフィック転送に関する設定や、特に Amazon EC2インスタンスのソース/デスティネーションチェックに関するものです。以下にその要点をまとめます。
1. ソース/デスティネーションチェック (Source/Destination Check)
- EC2インスタンスはデフォルトでソース/デスティネーションチェックが有効になっています。この設定により、インスタンスはそのトラフィックの送信元または宛先として機能する必要があります。
- プロキシインスタンスやネットワークのゲートウェイとして機能するインスタンスの場合、このチェックを無効にする必要があります。無効化すると、インスタンスは他のインスタンスのトラフィックを中継することができます。
2. 透明プロキシの実装
- プロキシインスタンスは、ネットワーク上でデータの中継を行うことを目的としています。EC2インスタンスが透明プロキシとして機能する場合、そのトラフィックを適切に転送するために、ソース/デスティネーションチェックを無効にすることがよくあります。
- 透明プロキシの一般的な使い方には、インターネットへのアクセス制御やセキュリティスキャンの実行が含まれます。
3. セキュリティグループとネットワーク
- セキュリティグループは、インスタンス間の通信を許可または拒否するための設定です。しかし、プロキシの問題はセキュリティグループの設定だけでは解決できません。プロキシインスタンスが他のインスタンスのトラフィックを適切に転送できるようにするためには、ソース/デスティネーションチェックを無効にする必要があります。
- セキュリティグループは通信のセキュリティを担保しますが、トラフィックの転送には影響を与えません。
4. Elastic Network Interface (ENI)
- EC2インスタンスには、複数のネットワークインターフェース（ENI）を追加できます。これにより、1つのインスタンスが複数のネットワークに接続できるようになります。ENIを追加することで、インスタンスのネットワーク接続性を強化できますが、プロキシとしての機能を提供するためには、やはりソース/デスティネーションチェックの無効化が必要です。
結論
- ソース/デスティネーションチェックを無効にすることで、EC2インスタンスが他のインスタンスのトラフィックを正しく転送できるようになります。特に、プロキシとして機能するインスタンスでは、この設定が不可欠です。
実践
略
一問道場
質問 #434
ある会社が新しいセキュリティ要件を実装しました。この新しい要件によれば、会社はVPC内のAWSインスタンスからのすべてのトラフィックをスキャンして、会社のセキュリティポリシーに違反していないか確認しなければなりません。このスキャンの結果、特定のIPアドレスへのアクセスをブロックすることができます。
この要件を満たすために、会社は透明なプロキシとして機能するAmazon EC2インスタンスのセットをプライベートサブネットにデプロイしました。会社はこれらのEC2インスタンスに承認されたプロキシサーバーソフトウェアをインストールしています。会社は、すべてのサブネットのルートテーブルを変更し、対応するプロキシソフトウェアをインストールしたEC2インスタンスをデフォルトルートとして使用するように設定しました。また、会社はセキュリティポリシーに準拠したセキュリティグループを作成し、これらのEC2インスタンスに割り当てています。
これらの設定にもかかわらず、EC2インスタンスのトラフィックはインターネットに正しく転送されていません。
この問題を解決するためにソリューションアーキテクトは何をすべきですか？
A. プロキシソフトウェアを実行しているEC2インスタンスでソース/デスティネーションチェックを無効にする。
B. プロキシEC2インスタンスに割り当てられたセキュリティグループに、同じセキュリティグループが割り当てられたインスタンス間でのすべてのトラフィックを許可するルールを追加する。このセキュリティグループをVPC内のすべてのEC2インスタンスに割り当てる。
C. VPCのDHCPオプションセットを変更し、DNSサーバーのオプションをプロキシEC2インスタンスのアドレスを指すように設定する。
D. 各プロキシEC2インスタンスに追加のElastic Network Interface（ENI）を割り当てる。これらのネットワークインターフェースのうち、1つはプライベートサブネットへのルートを持ち、もう1つはインターネットへのルートを持つようにする。
解説
この問題では、プロキシとして機能するAmazon EC2インスタンスがインターネットへのトラフィックを正しく転送できない問題について問われています。解決策として最も適切な選択肢は A です。以下に各選択肢について詳しく解説します。
A. プロキシソフトウェアを実行しているEC2インスタンスでソース/デスティネーションチェックを無効にする。
- 正解です。Amazon EC2インスタンスにはデフォルトでソース/デスティネーションチェックが有効になっています。これは、インスタンスがそのトラフィックの発信元または宛先である必要があることを意味します。プロキシインスタンスでは、別のインスタンスのトラフィックを転送するため、このチェックを無効にする必要があります。これにより、プロキシインスタンスがトラフィックを正常に中継できるようになります。
B. プロキシEC2インスタンスに割り当てられたセキュリティグループに、同じセキュリティグループが割り当てられたインスタンス間でのすべてのトラフィックを許可するルールを追加する。このセキュリティグループをVPC内のすべてのEC2インスタンスに割り当てる。
- 誤りです。セキュリティグループはネットワークのセキュリティを制御しますが、ソース/デスティネーションチェックが無効になっていない場合、プロキシインスタンスが正常にトラフィックを転送できません。セキュリティグループのルールを追加しても、ソース/デスティネーションチェックを無効にしない限り、トラフィックの転送はできません。
C. VPCのDHCPオプションセットを変更し、DNSサーバーのオプションをプロキシEC2インスタンスのアドレスを指すように設定する。
- 誤りです。DNSの設定を変更しても、トラフィックの転送に関する問題は解決しません。問題の根本的な原因は、ソース/デスティネーションチェックが有効であることです。この設定はDNS解決に関連するもので、トラフィックの転送を制御するものではありません。
D. 各プロキシEC2インスタンスに追加のElastic Network Interface（ENI）を割り当てる。これらのネットワークインターフェースのうち、1つはプライベートサブネットへのルートを持ち、もう1つはインターネットへのルートを持つようにする。
- 誤りです。ENIを追加しても、プロキシインスタンスが正常にトラフィックを転送するためには、ソース/デスティネーションチェックを無効にする必要があります。ネットワークインターフェースを追加することは、トラフィック転送の問題を解決するための直接的な方法ではありません。
結論:
A. ソース/デスティネーションチェックを無効にするが最も適切な解決策です。プロキシインスタンスが他のインスタンスのトラフィックを正常に転送するには、この設定が必須です。
435-AWS SAP AWS 「理論・実践・一問道場」幂等性
理論
1. CloudFormationのインポート機能
- CloudFormationのインポート機能では、既存のリソース（例：VPC、EC2インスタンス、S3バケットなど）を新しいCloudFormationスタックに取り込むことができます。この機能により、手動で作成したリソースをCloudFormationで管理できるようになり、インフラの自動化が可能になります。
- これにより、既存のインフラをCloudFormationテンプレートで管理することで、インフラの一貫性と追跡が容易になります。
2. インフラの自動化とインフラストラクチャコード（IaC）
- *インフラストラクチャコード（IaC）**は、インフラをコードとして定義し、バージョン管理する手法です。これにより、インフラのプロビジョニング、管理、更新を自動化できます。
- CloudFormationは、IaCの一環として、AWSリソースのプロビジョニングと管理を提供します。コードとしてインフラを記述することで、手動作業を削減し、エラーを防ぐことができます。
3. 幂等性の概念
- 幂等性は、同じ操作を複数回実行しても、システムの状態が変わらないことを意味します。CloudFormationは幂等性を持つため、同じテンプレートを何度実行しても、リソースの状態が常に一致します。この特性により、インフラの変更を安全かつ確実に行えます。
4. スタックとスタックセット
- スタックは、CloudFormationで定義したリソースの集合です。リソースはスタック内で一括して管理されます。
- スタックセットは、複数のリージョンやアカウントにまたがるスタックのデプロイメントを管理します。スタックセットは複数の環境に同じリソースをデプロイする際に有用ですが、既存リソースのインポートには適していません。
5. AWS CDK（Cloud Development Kit）
- AWS CDKは、AWSインフラをプログラムコードとして定義するためのツールです。これにより、開発者はより柔軟にAWSリソースをコードで管理できますが、既存のリソースを取り込むことは簡単ではなく、CloudFormationほどシンプルではない場合があります。
6. リソースの移行と管理
- リソースのインポートと移行は、手動で作成されたインフラを自動化された管理方法に統合する重要なステップです。CloudFormationやAWS CDKなどを活用して、既存インフラの状態をコードとして管理することで、運用の効率性を向上させ、エラーを防ぐことができます。
これらの概念を理解することで、インフラの自動化管理を効果的に行い、手動操作のリスクを減らすことができます。
実践
略
一問道場
問題 #435
ある会社は、手動で作成したVPCでソリューションを実行しています。会社はAWS CloudFormationを使用してインフラの他の部分をプロビジョニングしています。新たな要件により、会社はすべてのインフラを自動的に管理しなければならなくなりました。
この新しい要件を最小限の労力で満たすために、会社は何をすべきですか？
A. 新しいAWS Cloud Development Kit（AWS CDK）スタックを作成し、既存のVPCリソースと設定を厳密にプロビジョニングします。AWS CDKを使用してVPCをスタックにインポートし、VPCを管理します。
B. VPCを作成するCloudFormationスタックセットを作成します。スタックセットを使用してVPCをスタックにインポートします。
C. 新しいCloudFormationテンプレートを作成し、既存のVPCリソースと設定を厳密にプロビジョニングします。CloudFormationコンソールから、新しいスタックを作成して既存のリソースをインポートします。
D. VPCを作成する新しいCloudFormationテンプレートを作成します。AWS Serverless Application Model（AWS SAM）CLIを使用してVPCをインポートします。
解説
この問題の解説は、VPC（仮想プライベートクラウド）を自動化で管理する方法を選ぶことに関するものです。現状、VPCは手動で作成されており、他のインフラ部分はAWS CloudFormationを使ってプロビジョニングされています。会社の新しい要件は、すべてのインフラを自動で管理することです。
選択肢を順番に見てみましょう：
A. 新しいAWS Cloud Development Kit（AWS CDK）スタックを作成し、既存のVPCリソースと設定を厳密にプロビジョニングします。AWS CDKを使用してVPCをスタックにインポートし、VPCを管理します。
- 解説: AWS CDKはインフラストラクチャをコードとして定義できるツールです。CDKを使用して既存のVPCをスタックにインポートすることは可能ですが、VPC自体を手動で作成した場合、完全にインポートして管理するには手間がかかります。CDKはインフラをコードで管理するために便利ですが、この方法は最も簡単ではなく、既存リソースの取り込みにやや複雑な部分があるため、最適ではありません。
B. VPCを作成するCloudFormationスタックセットを作成します。スタックセットを使用してVPCをスタックにインポートします。
- 解説: CloudFormationスタックセットは、複数のリージョンやアカウントにわたってCloudFormationスタックをデプロイする機能です。しかし、スタックセット自体は新しいリソースの作成に適しているため、既存のVPCを「インポート」する方法としては不適切です。この選択肢では、既存のリソースをインポートすることができません。
C. 新しいCloudFormationテンプレートを作成し、既存のVPCリソースと設定を厳密にプロビジョニングします。CloudFormationコンソールから、新しいスタックを作成して既存のリソースをインポートします。
- 解説: CloudFormationを使用して、既存のVPCリソースを管理するために「インポート」機能を使用するのは良い方法です。CloudFormationでは、既存のリソースをテンプレートとしてインポートして管理することができます。この方法は、既存のVPCを自動化管理に取り込む最もシンプルで効果的な方法の1つです。
D. VPCを作成する新しいCloudFormationテンプレートを作成します。AWS Serverless Application Model（AWS SAM）CLIを使用してVPCをインポートします。
- 解説: AWS SAM（Serverless Application Model）はサーバーレスアプリケーションのデプロイに特化したツールです。VPCの作成や管理はSAMの範囲外であり、SAM CLIを使ってVPCをインポートすることは適切ではありません。この方法は問題の要件に合っていません。
最適な解決策:
最も適切な解決策は、C. 新しいCloudFormationテンプレートを作成し、既存のVPCリソースと設定を厳密にプロビジョニングします。CloudFormationコンソールから、新しいスタックを作成して既存のリソースをインポートしますです。
これにより、既存のVPCをCloudFormationで管理することができ、インフラの管理が自動化されます。CloudFormationは、既存リソースのインポートをサポートしており、この方法で最小限の労力でVPCを自動化管理することができます。
436-AWS SAP AWS 「理論・実践・一問道場」S3配信方法
理論
1. Amazon S3（Simple Storage Service）
- S3 は、スケーラブルで高耐久性を備えたオブジェクトストレージサービスです。ユーザーがデータをアップロードし、インターネット経由でアクセスできるようにするために広く利用されます。
- ゲームファイルや大容量のコンテンツをアップロードする場合、S3は特に効果的です。アクセス頻度 に応じて最適なストレージクラス（Standard、Infrequent Access、Glacierなど）を選ぶことができ、コストを最適化 できます。
2. Amazon CloudFront（コンテンツ配信ネットワーク）
- CloudFront は、グローバルなコンテンツ配信ネットワーク（CDN）サービスです。世界中のエッジロケーションにコンテンツをキャッシュして、エンドユーザーに低レイテンシでデータを提供することができます。
- S3バケットと組み合わせることで、コンテンツがS3からエッジロケーションにキャッシュされ、ユーザーの近くのサーバーから 提供されるため、ダウンロード速度 が大幅に向上します。
- さらに、スケーラビリティ と パフォーマンス の向上だけでなく、コスト効率 の面でも優れた選択肢です。CloudFrontはデータ転送量を最適化し、トラフィックの増加にも対応できます。
3. Amazon Route 53（DNSサービス）
- Route 53 は、AWSのスケーラブルで高可用性を備えたDNSサービスです。ウェブサイトやアプリケーションへのリクエストを効率よくルーティングするために利用されます。
- S3バケットのウェブサイトホスティング を使う場合、Route 53を利用してカスタムドメインを設定できます。これにより、ユーザーは直感的に覚えやすいURLを使ってコンテンツをダウンロードできます。
4. コンテンツ配信のパフォーマンスとコスト効率
- CDN（コンテンツ配信ネットワーク） を活用することで、グローバルなアクセスを受けるコンテンツのパフォーマンスを大幅に向上させることができます。CloudFrontは、コンテンツがエッジロケーションにキャッシュされるため、ダウンロード速度 が短縮され、アクセスするユーザーにとって快適な体験を提供します。
- CloudFrontは、帯域幅の使用量 に基づいて課金されるため、効果的なキャッシュ管理を行うことでコスト削減が可能です。
5. スケーラブルなストレージの設計
- ゲームのように大量のダウンロードが予想されるコンテンツを提供する際、スケーラブルなストレージ ソリューションが必要です。S3はその点で非常に優れており、リソースの追加や管理が簡単で、ユーザーの数に応じて自動的にスケーリングします。
- オンデマンドでのストレージとデータ転送の最適化 により、アクセス負荷の高い期間でも安定した配信が可能です。
6. Requestor Paysモード
- Requestor Paysモード は、S3バケットに対して設定できるオプションで、ユーザーがダウンロードを行う際にそのコストを負担させることができます。これにより、配信者側のコスト を削減することができますが、ユーザー側に負担をかけるため、使用する際には注意が必要です。
- ゲームのように大量のダウンロードが予想される場合、ユーザーにコストを負担させることで、運営側のコスト削減につながる可能性があります。
結論
- ゲームファイルの配信には、S3 と CloudFront を組み合わせることが、パフォーマンス向上とコスト効率の両方において最適な選択肢です。特に、グローバルなユーザー に対して高速で安定したダウンロードを提供するため、CloudFrontの使用が鍵となります。
- Route 53 を使ってDNS設定を行うことで、カスタムドメインを利用してアクセスしやすくすることも可能です。
実践
略
一問道場
ある会社が人気のあるビデオゲームの新しいリリースを開発し、それを公開ダウンロード用に提供したいと考えています。新しいリリースパッケージは約5GBのサイズです。会社は既存のリリースのダウンロードを、オンプレミスのデータセンターでホストされているLinuxベースの公開FTPサイトから提供しています。この新しいリリースは、世界中のユーザーによってダウンロードされると予想されています。会社は、ユーザーの場所に関係なく、改善されたダウンロードパフォーマンスと低い転送コストを提供するソリューションを希望しています。
次のうち、最も適したソリューションはどれですか？
A. ゲームファイルをAmazon EBSボリュームに保存し、Auto Scalingグループ内のAmazon EC2インスタンスにマウントします。EC2インスタンスにFTPサービスを設定し、Auto Scalingグループの前にアプリケーションロードバランサーを配置します。ユーザーにゲームダウンロードURLを公開します。
B. ゲームファイルをAmazon EFSボリュームに保存し、Auto Scalingグループ内のAmazon EC2インスタンスにマウントします。各EC2インスタンスにFTPサービスを設定し、Auto Scalingグループの前にアプリケーションロードバランサーを配置します。ユーザーにゲームダウンロードURLを公開します。
C. Amazon Route 53とAmazon S3バケットをウェブサイトホスティング用に設定します。ゲームファイルをS3バケットにアップロードし、Amazon CloudFrontを使ってウェブサイトを配信します。ユーザーにゲームダウンロードURLを公開します。
D. Amazon Route 53とAmazon S3バケットをウェブサイトホスティング用に設定します。ゲームファイルをS3バケットにアップロードし、S3バケットに対してRequester Paysを設定します。ユーザーにゲームダウンロードURLを公開します。
解説
この問題では、ゲームの新しいリリース（約5GB）を世界中のユーザーに対して高速かつコスト効率良く配信する方法を問うています。選択肢には、ゲームファイルの保存先や配信方法が提案されています。それぞれの選択肢を詳しく見てみましょう。
選択肢 A: Amazon EBSとEC2を使用
- ゲームファイルを Amazon EBSボリューム に保存し、Auto Scalingグループ 内の EC2インスタンス にマウントするという選択肢です。
- EC2インスタンスに FTPサービス を設定し、 アプリケーションロードバランサー を使ってスケールを調整します。
- これは、オンプレミス環境に近い形で、EC2インスタンスを利用してゲームを配信しようとするものですが、スケーラビリティ や パフォーマンス が限られるため、ダウンロード数が多い場合にはコストやパフォーマンス面で問題が発生する可能性があります。
選択肢 B: Amazon EFSとEC2を使用
- ゲームファイルを Amazon EFSボリューム に保存し、Auto Scalingグループ 内の EC2インスタンスにマウントして配信する提案です。
- こちらは、ファイル共有のための EFS を使っているため、複数のEC2インスタンスから同じファイルにアクセスすることができますが、EFSはパフォーマンス や コスト効率 の点で、大規模なダウンロードに最適ではありません。特に、S3やCloudFrontを使った配信に比べると効率が悪いです。
選択肢 C: Amazon S3とCloudFrontを使用
- Amazon S3 にゲームファイルをアップロードし、CloudFront でコンテンツ配信を行う提案です。
- CloudFront は、AWSのCDN（コンテンツ配信ネットワーク）サービスで、世界中のエッジロケーションからコンテンツを提供するため、ダウンロード速度 が非常に速く、コスト効率 も良好です。
- S3は非常にスケーラブル で、アクセス頻度に応じた自動スケーリングが行われるため、大規模なユーザーに対しても問題なく対応できます。
選択肢 D: Requester Pays付きのS3を使用
- Requester Pays は、ダウンロードしたユーザーが料金を負担するオプションですが、これを有効にすることで、配信コストを減らせる 可能性があります。しかし、ユーザーがアクセスする際に追加の設定が必要 となり、利用者の体験を悪化させるリスクがあります。
- また、CloudFrontを使用しない ため、ダウンロード速度 については選択肢Cに劣ります。
最も適切な解決策:
最も効率的で低コストな方法は 選択肢C です。S3とCloudFrontを使ってコンテンツ配信を行う方法は、スケーラビリティとパフォーマンスの両面で優れており、世界中のユーザーに高速で安定したダウンロード環境を提供できます。CloudFront を使用することで、コンテンツがエッジロケーションから提供され、ダウンロード速度が大幅に向上します。また、S3は自動的にスケールするため、アクセス量に応じて適切にリソースが割り当てられ、コストも最適化されます。
結論:
C. Amazon Route 53とAmazon S3バケットを使用して、CloudFrontを使った配信を行う が最適な選択肢です。
437-AWS SAP AWS 「理論・実践・一問道場」Auto Scaling
理論
1. Auto Scaling と Load Balancing
- Auto Scaling：Auto Scalingは、需要に応じてインスタンスの数を自動的に調整します。これにより、トラフィックが急増した場合でも自動的にリソースを追加でき、逆にトラフィックが減少した場合は無駄なリソースを削減できます。これにより、コスト効率とパフォーマンスを最大化できます。
- Application Load Balancer (ALB)：ALBは、複数のバックエンドインスタンスへのリクエスト分散を行います。これにより、トラフィックが複数のサーバーに分散され、負荷が均等に保たれます。高トラフィック時でも、リクエストを効率的に処理できます。
2. 高可用性の設計
- 複数のアベイラビリティゾーン (AZ)：AWSでは、複数のアベイラビリティゾーンを利用して高可用性を確保します。異なるAZにリソースを配置することで、1つのAZが障害を起こしても他のAZでサービスを継続できます。この設計は、ダウンタイムを最小限に抑えるために非常に重要です。
- 冗長性：複数のインスタンスを異なるAZに展開することで、冗長性が向上し、単一障害点を排除できます。Auto ScalingやALBと組み合わせることで、トラフィックの増加に対して動的に対応できます。
3. データベースのスケーラビリティ
- Amazon Aurora：Auroraは、MySQL互換の高可用性でスケーラブルなデータベースサービスです。読み取り専用のAuroraレプリカを使用することで、トラフィックの増加に対してデータベースのスケーラビリティを向上させることができます。また、Auroraは自動バックアップと高可用性機能を提供するため、データベースの耐障害性も強化されます。
4. 負荷分散とトラフィックの効率的な分散
- ロードバランサーの役割：トラフィックを複数のインスタンスに均等に分散させることで、リソースの過負荷を防ぎ、サービスの可用性を確保します。また、ウェブサーバーやアプリケーションサーバーが複数台運用されている場合、ALBを利用してヘルスチェックを行い、正常なインスタンスにのみトラフィックを送ることができます。
5. 高トラフィック時の戦略
- スケーリングと冗長性の組み合わせ：高トラフィックに対応するためには、スケーリングと冗長性を組み合わせた設計が必要です。例えば、Auto Scalingでインスタンス数を増やし、複数のAZに分散することで、急なトラフィック増加にも耐えられるシステムを構築できます。
6. コスト最適化
- 需要に基づいたリソース調整：Auto Scalingやインスタンスのスケールアップ・ダウン機能を使うことで、リソースを需要に基づいて効率的に調整し、無駄なコストを削減できます。特に、トラフィックが変動するアプリケーションにおいては、コストの最適化が重要です。
これらの知識を活用することで、アプリケーションの可用性、スケーラビリティ、パフォーマンスを向上させ、高トラフィックに耐えるインフラを構築できます。
実践
略
一問道場
問題：
ある企業がクラウドで運用しているアプリケーションには、データベースとウェブサイトが含まれています。ユーザーはウェブサイトにデータを投稿し、そのデータが処理されてからメールで返送されます。データはAmazon EC2インスタンス上のMySQLデータベースに保存されています。このデータベースは、2つのプライベートサブネットを持つVPC内で稼働しています。ウェブサイトはApache Tomcat上で単一のEC2インスタンスで実行され、別のVPCの1つのパブリックサブネットに配置されています。データベースとウェブサイトのVPC間には1つのVPCピアリング接続があります。ウェブサイトは過去1か月間、高トラフィックによるいくつかの障害に見舞われました。
アプリケーションの信頼性を高めるために、ソリューションアーキテクトが取るべきアクションはどれですか？（3つ選んでください。）
A. TomcatサーバーをAuto Scalingグループに配置し、複数のEC2インスタンスをApplication Load Balancerの背後に配置する。
B. 追加のVPCピアリング接続を提供する。
C. MySQLデータベースをAmazon Auroraに移行し、1つのAuroraレプリカを作成する。
D. データベースVPCに2つのNATゲートウェイを提供する。
E. TomcatサーバーをデータベースVPCに移動する。
F. ウェブサイトVPCに異なるアベイラビリティゾーンに追加のパブリックサブネットを作成する。
解説
この問題は、ウェブサイトのトラフィックによるダウンタイムを減らし、アプリケーションの信頼性を高めるための最適なアクションを選ぶ内容です。以下、選択肢ごとに説明します。
A. TomcatサーバーをAuto Scalingグループに配置し、複数のEC2インスタンスをApplication Load Balancerの背後に配置する。
- 正しい：高トラフィックに対する信頼性を高めるためには、ウェブサーバーがスケーリングできるようにすることが重要です。Auto Scalingグループを使用すると、トラフィックの増加に応じて自動的にEC2インスタンスを追加することができ、ウェブサイトの可用性を向上させます。また、Application Load Balancer (ALB) を使用することで、リクエストが複数のインスタンスに均等に分配され、パフォーマンスが向上します。
B. 追加のVPCピアリング接続を提供する。
- 不正解：現在、データベースVPCとウェブサイトVPCは1つのVPCピアリング接続で接続されていますが、信頼性向上に関してVPCピアリング接続を追加する必要はありません。VPCピアリング接続はトラフィックの流れを設定するためのものですが、トラフィックの高負荷に対する耐性強化には関係ありません。
C. MySQLデータベースをAmazon Auroraに移行し、1つのAuroraレプリカを作成する。
- 正しい：Amazon Auroraは高可用性、高スケーラビリティ、耐障害性を提供するデータベースサービスです。MySQLからAuroraに移行することで、データベースのパフォーマンスと可用性が大幅に向上します。Auroraレプリカを追加することで、読み取り専用トラフィックを分散でき、データベースのスケーラビリティも向上します。
D. データベースVPCに2つのNATゲートウェイを提供する。
- 不正解：NATゲートウェイは、プライベートサブネットからインターネットへの通信を可能にします。しかし、この状況では、ウェブサイトのトラフィックの増加やEC2インスタンスの可用性に直接関係する要素ではありません。NATゲートウェイの追加は、特にデータベースの信頼性を向上させるものではなく、この選択肢は不要です。
E. TomcatサーバーをデータベースVPCに移動する。
- 不正解：ウェブサーバーとデータベースサーバーを同じVPC内に移動することは、管理が簡素化される可能性がありますが、トラフィック負荷の問題や可用性の向上には直接的な影響はありません。むしろ、異なるVPCに分けておくことで、ネットワークのセキュリティや分離が強化される場合もあります。
F. ウェブサイトVPCに異なるアベイラビリティゾーンに追加のパブリックサブネットを作成する。
- 正しい：異なるアベイラビリティゾーンに追加のパブリックサブネットを作成することで、ウェブサイトの冗長性が高まります。もし1つのアベイラビリティゾーンがダウンした場合でも、他のアベイラビリティゾーンで動作しているサーバーにリクエストを分散できるため、可用性が向上します。
まとめ
ウェブサイトのトラフィック負荷と可用性を向上させるために取るべき最適なアクションは以下の通りです：
- A: Auto Scalingグループでインスタンスを自動的にスケール
- C: MySQLデータベースをAuroraに移行
- F: アベイラビリティゾーン間での冗長性を高めるための追加サブネットの作成
これらのアクションにより、アプリケーションのスケーラビリティと可用性が大幅に向上し、高トラフィックに耐える能力が高まります。
438-AWS SAP AWS 「理論・実践・一問道場」ALB 502ステータスコード
理論
1. カスタムエラーページの設定
AWSでアプリケーションのエラー時にカスタムエラーページを表示するには、主に以下の方法があります。
- Amazon CloudFront: CloudFrontは、カスタムエラーページを提供するのに非常に便利なサービスです。CloudFrontでは、カスタムエラーレスポンスを設定でき、特定のHTTPエラーステータス（例えば、502 Bad Gatewayや504 Gateway Timeout）に対して、カスタムエラーページを表示できます。これにより、ALB（Application Load Balancer）やその他のバックエンドサーバーがエラーを返した際に、ユーザーに対してより良いエラーページを提供できます。
- Amazon S3: Amazon S3を利用して静的なカスタムエラーページをホストし、エラーレスポンスとして返すことも可能です。S3の静的ウェブサイトホスティング機能を使って、特定のエラーページを設定できます。CloudFrontやALBでこのS3バケットをエラー時のリダイレクト先として指定できます。
2. ALB (Application Load Balancer) エラーページのカスタマイズ
ALB自体には、カスタムエラーページを提供するための直接的な機能はありません。代わりに、エラー時にリダイレクトを指定した別のサーバーまたはS3バケットにルーティングする方法が考えられます。この手法は、特定のエラーに対して別のサービスにリダイレクトする方法として、CloudFrontやLambda関数を利用することが一般的です。
3. Amazon Route 53 のヘルスチェック
Amazon Route 53は、DNS管理サービスとしても利用されます。Route 53は、DNSレコードに対してヘルスチェックを設定することができます。これにより、特定のインスタンスやリソースが正常かどうかを監視し、異常が検出された場合に他のリソースにリダイレクトする設定が可能です。
- ヘルスチェック: 通常の運用では、DNSのレコードにヘルスチェックを設定して、特定のサーバーが正常かどうかを監視します。もしヘルスチェックに失敗すると、Route 53は別のリソースを指し示すことができます。この機能を活用することで、高可用性のアーキテクチャを構築できます。
4. Amazon CloudWatch アラームとLambda
Amazon CloudWatch は、AWSリソースの監視とアラート機能を提供します。CloudWatchアラームを設定して、ALBや他のAWSサービスで発生したエラーを検知し、その結果に基づいて自動的に処理を行うことができます。例えば、502エラーが一定回数発生した場合に、AWS Lambdaを使ってリダイレクト先の変更や、カスタムエラーページの設定を動的に実行できます。
5. CloudFront のカスタムエラーページ設定
CloudFrontは、キャッシュやコンテンツ配信ネットワーク（CDN）として機能しますが、カスタムエラーページを設定することで、エラーが発生した場合でもユーザーに対して適切なエラーページを表示することができます。エラーページの設定は、CloudFrontのディストリビューションのエラーレスポンス設定で行います。
まとめ
- ALB 502エラーに対して、ユーザーにカスタムエラーページを表示したい場合は、CloudFrontやS3を活用する方法が最適です。CloudFrontでエラーレスポンスをカスタマイズし、S3にホストした静的なエラーページを表示することで、よりプロフェッショナルなユーザー体験を提供できます。
- Route 53のヘルスチェックは、冗長性を持たせるために有効ですが、エラーページのカスタマイズとは直接的には関係しません。
- CloudWatch アラームとLambdaを組み合わせて、エラー時の処理を自動化し、動的にカスタムエラーページを提供する仕組みも実装可能です。
これらの概念と技術を理解することで、AWS環境における信頼性やエラーハンドリングのスキルを向上させることができます。
実践
略
一問道場
ある小売企業がAWS上でeコマースアプリケーションを運営しています。アプリケーションは、Application Load Balancer（ALB）の背後でAmazon EC2インスタンス上で動作し、データベースバックエンドとしてAmazon RDS DBインスタンスを使用しています。Amazon CloudFrontは、ALBを指す1つのオリジンを設定し、静的コンテンツはキャッシュされています。Amazon Route 53はすべてのパブリックゾーンをホスティングしています。
アプリケーションの更新後、ALBは時々502ステータスコード（Bad Gateway）エラーを返します。根本的な原因は、ALBに返されるHTTPヘッダーが不正であることです。エラーが発生した後、ソリューションアーキテクトがウェブページを再読み込みすると、正常にページが表示されます。
企業がこの問題に取り組んでいる間、ソリューションアーキテクトは、標準のALBエラーページの代わりにカスタムエラーページを訪問者に提供する必要があります。
最も運用負荷が少ない方法でこの要件を満たすために必要な手順はどれですか？（2つ選んでください。）
A. Amazon S3バケットを作成し、S3バケットを静的ウェブページのホスティング用に設定します。カスタムエラーページをAmazon S3にアップロードします。
B. Amazon CloudWatchアラームを作成して、ALBのヘルスチェック応答がTarget.FailedHealthChecksで0より大きい場合にAWS Lambda関数を呼び出します。Lambda関数を設定して、ALBの転送ルールを公開されているウェブサーバーを指すように変更します。
C. 既存のAmazon Route 53レコードを変更して、ヘルスチェックを追加します。ヘルスチェックに失敗した場合のフォールバックターゲットを設定します。DNSレコードを変更して公開ウェブページを指すようにします。
D. Amazon CloudWatchアラームを作成して、ALBのヘルスチェック応答がElb.InternalErrorで0より大きい場合にAWS Lambda関数を呼び出します。Lambda関数を設定して、ALBの転送ルールを公開されているウェブサーバーを指すように変更します。
E. CloudFrontカスタムエラーページを設定して、カスタムエラーページを追加します。DNSレコードを変更して公開ウェブページを指すようにします。
解説
この問題は、AWSでホストされたeコマースアプリケーションにおいて、ALBが返す502エラーに対してカスタムエラーページを提供する方法を尋ねています。502エラーは、ALBがターゲットとなるEC2インスタンスと正常に通信できなかった場合に発生します。ソリューションアーキテクトは、このエラーが発生した際に、訪問者に標準のALBエラーページの代わりにカスタムエラーページを表示させる必要があります。
正しい選択肢：
A. Amazon S3バケットを作成し、S3バケットを静的ウェブページのホスティング用に設定します。カスタムエラーページをAmazon S3にアップロードします。
- S3バケットを使ってカスタムエラーページをホストするのは、運用負荷が最小で、かつコスト効率の良い方法です。ALBが502エラーを返す際に、カスタムエラーページとしてS3に保存されたHTMLページを表示することができます。この方法は、特別なサーバー設定を必要とせず、簡単に実装できます。
E. CloudFrontカスタムエラーページを設定して、カスタムエラーページを追加します。DNSレコードを変更して公開ウェブページを指すようにします。
- CloudFrontを使用して、ALB経由でのエラー発生時にカスタムエラーページを表示させることができます。CloudFrontは、リクエストに対するキャッシュ機能を提供し、エラーページを高速に配信できます。また、CloudFrontのカスタムエラーページの設定は、ALBとの連携でエラー発生時に自動的に切り替えられます。
なぜ他の選択肢は適切でないか：
B. Amazon CloudWatchアラームを作成して、ALBのヘルスチェック応答がTarget.FailedHealthChecksで0より大きい場合にAWS Lambda関数を呼び出します。Lambda関数を設定して、ALBの転送ルールを公開されているウェブサーバーを指すように変更します。
- このアクションは、ヘルスチェックの失敗時にLambda関数を使用して転送ルールを変更することですが、502エラーが発生した際にカスタムエラーページを表示する方法としては過剰であり、運用負荷が高くなります。また、エラーが発生した場合に動的に転送ルールを変更するのは不必要な複雑さを増加させます。
C. 既存のAmazon Route 53レコードを変更して、ヘルスチェックを追加します。ヘルスチェックに失敗した場合のフォールバックターゲットを設定します。DNSレコードを変更して公開ウェブページを指すようにします。
- ルーティングやフォールバックターゲットを設定することは、ALBの502エラーに対する解決策としては不適切です。この方法では、エラー発生時に別のサーバーを指し示すことになりますが、カスタムエラーページの提供には関係なく、リダイレクトなどの動作が追加されることになります。
D. Amazon CloudWatchアラームを作成して、ALBのヘルスチェック応答がElb.InternalErrorで0より大きい場合にAWS Lambda関数を呼び出します。Lambda関数を設定して、ALBの転送ルールを公開されているウェブサーバーを指すように変更します。
- こちらもBと同様に、ヘルスチェックの応答を元にLambda関数を呼び出し、転送ルールを変更する方法です。複雑すぎて、502エラーに対してカスタムエラーページを提供するために必要なシンプルなソリューションとは言えません。
結論：
カスタムエラーページを提供するために最も効率的で運用負荷の少ない方法は、A（Amazon S3バケットに静的なエラーページをホストする）とE（CloudFrontのカスタムエラーページ設定）です。
439-AWS SAP AWS 「理論・実践・一問道場」Amazon Aurora
理論
Amazon Auroraの移行方法
Amazon Auroraは、AWSが提供するフルマネージドのリレーショナルデータベースサービスで、MySQLおよびPostgreSQLとの互換性があります。Auroraはスケーラビリティ、パフォーマンス、および高可用性を提供しますが、既存のデータベースを別のアカウントやリージョンに移行する際には適切な方法を選択する必要があります。
1. Auroraのスナップショットとスナップショットの共有
- スナップショットはAuroraインスタンスの状態をバックアップする方法です。スナップショットを取得し、それを他のアカウントに共有することで、別のアカウントにAurora DBクラスターを作成できます。
- スナップショットを使用した移行は、最小限のダウンタイムを実現しやすい方法です。移行後に切り替えを行うだけで済むため、非常にシンプルで効率的な方法です。
2. AWS Database Migration Service（AWS DMS）
- AWS DMSを使用すると、異なるAWSアカウント間でのデータのリアルタイム同期が可能です。これにより、データ移行中もターゲットデータベースを使用し続けることができ、移行後に切り替える際のダウンタイムを最小限に抑えられます。
- DMSは、フルカットオーバーの前にデータ同期を行い、差分データの転送をリアルタイムで行うことで、切り替えをスムーズに行えるようにします。
3. AWS Backup
- AWS Backupは、バックアップを自動化し、データの保護を簡素化するためのサービスです。ただし、Auroraの移行においては、スナップショットを他のアカウントに直接共有する方法が適しており、AWS Backupはこの用途には向いていません。
4. 移行後の切り替え
- DNS切り替え（DNS Cutover）を行う際、移行完了後にターゲットデータベースに接続するようにアプリケーション設定を変更することが一般的です。この切り替えの際に、最小限のサービス中断を確保するための事前の準備（例えば、データ同期やスナップショットの取得）が重要です。
最適な移行戦略
- スナップショットの共有とAWS DMSを組み合わせることが、ダウンタイムを最小限に抑えつつ、移行を効率的に行う最良の方法です。スナップショットで初期状態を作成し、その後DMSを使用してデータをリアルタイムで同期させるアプローチが有効です。
まとめ
データベースの移行には複数のアプローチがありますが、Amazon Auroraの移行には、スナップショットの取得やAWS DMSを使用することで、最小限のダウンタイムで移行を行うことが可能です。これらの方法は、移行後の運用負担を軽減し、安定したサービス提供を実現します。
実践
略
一問道場
問題 #439
ある企業が、既存のAWSアカウントから新しいAWSアカウントに、同じAWSリージョン内でAmazon Aurora MySQL DBクラスターを移行したいと考えています。
両方のアカウントは、AWS Organizations内の同じ組織に所属しています。
企業は、DNSカットオーバーを新しいデータベースに実行する前に、データベースサービスの中断を最小限に抑える必要があります。
どの移行戦略がこの要件を満たしますか？（2つ選んでください。）
A. 既存のAuroraデータベースのスナップショットを取得し、そのスナップショットを新しいAWSアカウントと共有する。スナップショットから新しいアカウントでAurora DBクラスターを作成する。
B. 新しいAWSアカウントでAurora DBクラスターを作成し、AWS Database Migration Service（AWS DMS）を使用して、2つのAurora DBクラスター間でデータを移行する。
C. AWS Backupを使用して、既存のAWSアカウントからAuroraデータベースのバックアップを新しいAWSアカウントに共有する。スナップショットから新しいアカウントでAurora DBクラスターを作成する。
D. 新しいAWSアカウントでAurora DBクラスターを作成し、AWS Application Migration Serviceを使用して、2つのAurora DBクラスター間でデータを移行する。
解説
この問題では、Amazon Aurora MySQL DBクラスターを新しいAWSアカウントに移行する方法を選ぶことが求められています。主な要件として、データベースサービスの中断を最小限に抑えること、そしてDNSカットオーバーを新しいデータベースに行う前に移行を完了することです。以下は各選択肢の解説です。
A. 既存のAuroraデータベースのスナップショットを取得し、そのスナップショットを新しいAWSアカウントと共有する。スナップショットから新しいアカウントでAurora DBクラスターを作成する。
- 正解: この方法では、スナップショットを使って、最小限のダウンタイムで移行を行うことができます。スナップショットを新しいアカウントに共有し、そのスナップショットから新しいAurora DBクラスターを作成することで、比較的短期間でデータベースを移行できます。この方法は簡単で、ダウンタイムが最小限に抑えられるため、最も適切な方法です。
B. 新しいAWSアカウントでAurora DBクラスターを作成し、AWS Database Migration Service（AWS DMS）を使用して、2つのAurora DBクラスター間でデータを移行する。
- 正解: AWS DMSを使用すると、データをリアルタイムで移行できるため、移行中のサービス中断を最小限に抑えることができます。AWS DMSは、データベース間での継続的な同期を可能にするため、切り替え時のダウンタイムを短縮できます。この方法も低い中断で移行を行えるので、適切な方法です。
C. AWS Backupを使用して、既存のAWSアカウントからAuroraデータベースのバックアップを新しいAWSアカウントに共有する。スナップショットから新しいアカウントでAurora DBクラスターを作成する。
- 不正解: AWS Backupは主にバックアップとリストアに使用されますが、Auroraのスナップショットの共有には直接関係しません。Aurora DBのスナップショットを別のアカウントに直接共有するには、バックアップ機能ではなく、スナップショットの共有機能を使用する必要があります。したがって、こちらの方法は不適切です。
D. 新しいAWSアカウントでAurora DBクラスターを作成し、AWS Application Migration Serviceを使用して、2つのAurora DBクラスター間でデータを移行する。
- 不正解: AWS Application Migration Service（旧Server Migration Service）は主にEC2インスタンスの移行を対象としており、Aurora MySQLの移行には直接関与しません。Auroraの移行にはこのサービスは適していません。したがって、この方法は不適切です。
まとめ
この問題における最適な解決策は、選択肢AとBです。どちらもデータベースの中断を最小限に抑える方法であり、移行プロセスを効率的に完了できます。選択肢CとDは、適切なサービスを使用していないため不正解です。
440-AWS SAP AWS 「理論・実践・一問道場」AWS PrivateLink
理論
1. VPCピアリングとトランジットゲートウェイ
- VPCピアリング: VPCピアリングは、2つのVPC間で通信を可能にするための方法です。ただし、ピアリング接続の数が増えると管理が複雑になり、VPCが増えた場合、各VPC間でピアリング接続を設定し直す必要があるため、スケーラビリティに欠ける可能性があります。
- トランジットゲートウェイ (TGW): トランジットゲートウェイは、複数のVPC間での通信を一元化するサービスで、複数のVPCとオンプレミスの接続を効率的に管理できます。VPCが増えると、トランジットゲートウェイを使うことで、接続数を大幅に削減でき、管理が楽になります。新しいVPCを追加するのも簡単で、スケーラブルです。
2. AWS PrivateLink
- PrivateLink: AWS PrivateLinkは、セキュアでプライベートな接続を提供するサービスで、VPC間のトラフィックをインターネット経由でなく、AWSの内部ネットワーク経由で処理することができます。これにより、ネットワークのセキュリティを強化し、トラフィックの漏れを防ぐことができます。PrivateLinkは、特に一方向のトラフィック（例えば、管理VPCへのアクセス）をセキュアに処理したい場合に便利です。
3. ネットワークロードバランサー (NLB) とVPCエンドポイント
- NLB: ネットワークロードバランサーは、高性能でレイテンシが低いロードバランサーです。PrivateLinkで使用することにより、トラフィックを安全に、プライベートなネットワークでルーティングできます。
- VPCエンドポイント: VPCエンドポイントは、インターネットを経由せずに、AWSのサービスにアクセスするためのプライベートな接続ポイントです。これを使用することで、インターネット経由のトラフィックを削減し、セキュリティを強化できます。
4. AWS Organizations と複数のアカウントの管理
- AWS Organizations: 複数のAWSアカウントを一元的に管理するためのサービスです。これにより、アカウント間でのリソース共有や請求管理が簡単になります。大規模なSaaS企業などでは、複数のVPCを管理する際に役立ちます。
5. スケーラビリティと運用負荷の最小化
- スケーラビリティ: 大規模なアーキテクチャ（50以上のVPCなど）を運用する場合、スケーラブルなアーキテクチャ設計が求められます。トランジットゲートウェイやPrivateLinkの利用により、VPC間の通信を効率的に処理し、運用負荷を最小化できます。
- 運用負荷の最小化: 複数のVPCがある場合、個別の接続や管理が煩雑になりがちです。そのため、サービス間の接続の効率化や自動化を行うことが、運用の簡素化とコスト削減に繋がります。
まとめ
この問題では、複数のVPC間の効率的な接続と、セキュアでスケーラブルな方法を求めています。トランジットゲートウェイとPrivateLinkを使うことで、運用の負荷を最小限に抑えつつ、スケーラビリティとセキュリティを確保することができます。
実践
略
一問道場
問題 #440
トピック 1
あるSaaS（ソフトウェア・アズ・ア・サービス）会社が、顧客にメディアソフトウェアソリューションを提供しています。このソリューションは、複数のAWSリージョンとAWSアカウントにまたがる50のVPCにホストされています。これらのVPCのうち1つは管理VPCとして指定されています。VPC内のコンピューティングリソースは独立して動作しています。
会社は、新しい機能を開発しており、この機能はすべての50のVPCが相互に通信できることを要求します。また、各顧客のVPCから会社の管理VPCへの一方向のアクセスも必要です。管理VPCは、メディアソフトウェアソリューションのライセンスを検証するコンピューティングリソースをホストしています。
会社は、ソリューションのホストに使用するVPCの数が増加し続けると予想しています。
どの組み合わせの手順が、最小限の運用負荷で必要なVPC接続を提供しますか？（2つ選択してください。）
A. トランジットゲートウェイを作成し、会社のすべてのVPCおよび関連するサブネットをトランジットゲートウェイに接続します。
B. 会社のすべてのVPC間でVPCピアリング接続を作成します。
C. ライセンス検証用のコンピューティングリソースを指すネットワークロードバランサー（NLB）を作成します。AWS PrivateLinkエンドポイントサービスを作成し、各顧客のVPCに提供します。このエンドポイントサービスをNLBに関連付けます。
D. 各顧客のVPCにVPNアプライアンスを作成し、AWS Site-to-Site VPNを使用して会社の管理VPCと各顧客のVPCを接続します。
E. 会社の管理VPCと各顧客のVPCの間でVPCピアリング接続を作成します。
解説
A. トランジットゲートウェイを作成し、会社のすべてのVPCおよび関連するサブネットをトランジットゲートウェイに接続します。
- 正解の選択肢: トランジットゲートウェイは、複数のVPCを接続するための最適な方法です。これにより、VPC間での通信が一元化され、スケーラブルで管理が簡単になります。新しいVPCを追加しても、既存の接続を変更することなく簡単に拡張でき、運用負荷も最小限に抑えることができます。トランジットゲートウェイは、VPC数が多くなる場合でも非常に有効です。
C. ライセンス検証用のコンピューティングリソースを指すネットワークロードバランサー（NLB）を作成し、AWS PrivateLinkエンドポイントサービスを作成して各顧客のVPCに提供します。
- 正解の選択肢: このオプションは、顧客のVPCから管理VPCへの 一方向アクセス を提供するために最適です。AWS PrivateLinkを利用すると、セキュアなプライベート接続を確保しつつ、顧客のVPCから管理VPCに向けたアクセスを一方向で提供できます。これにより、セキュリティや管理の煩雑さを避けつつ、一方向のトラフィックを効率的に処理できます。
なぜB, D, Eは不適切か？
- B (VPCピアリング) は、VPCが増えると管理が非常に煩雑になるため、選択肢として適していません。50のVPCがある場合、ピアリング接続を手動で設定するのは非常に非効率的です。
- D (VPNアプライアンス) は、VPN接続の管理が煩雑で、複数のVPN接続を手動で管理することはスケーラビリティや効率性に欠けます。
- E (管理VPCと顧客VPC間のVPCピアリング) も同様に、管理の負担が大きくなり、ピアリングが増えると運用が複雑になります。
結論
A と C の組み合わせが最適な解決策です。これにより、VPC間の通信はスケーラブルで効率的に行われ、一方向のアクセスもセキュアかつ簡単に提供できます。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/17ad7ae8-88e2-80f0-8b19-d2c427c76f2e
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
