type
status
date
slug
summary
tags
category
icon
password
521-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
理論
1. VPCエンドポイント
- VPCエンドポイントは、Amazon VPC内からAWSサービス（例：Amazon S3、AWS Systems Manager）にプライベートにアクセスするためのリソースです。
- VPCエンドポイントを使用することで、インターネットを経由せずに、AWSリソースへのアクセスができます。これによりセキュリティが向上し、データ転送が高速化します。
2. VPCピアリング
- VPCピアリングは、異なるVPC間でプライベートIPアドレスを使って通信を行うための接続方法です。
- 一方のVPCから別のVPCに直接アクセスすることができ、セキュアな接続を確立できます。ただし、VPCピアリングは設定が複雑になることがあり、特に複数のVPCを接続する場合には注意が必要です。
3. AWS Systems Manager (SSM)
- AWS Systems Managerは、AWSのインフラを管理するためのサービスです。パッチ管理や設定管理、リモートコマンドの実行、インスタンス管理などが行えます。
- パッチマネジメントでは、EC2インスタンスに対して自動的にパッチを適用することができます。これにより、手動でのパッチ管理の手間を減らし、セキュリティを向上させます。
4. Amazon S3
- *Amazon S3 (Simple Storage Service)**は、オブジェクトストレージサービスで、データを安全に保存するための場所を提供します。
- S3には、VPCエンドポイントを使用してプライベートにアクセスすることができます。これにより、インターネット経由でアクセスすることなく、安全にデータをやり取りできます。
5. トランジットゲートウェイ
- トランジットゲートウェイは、複数のVPCやオンプレミスネットワークを接続するためのサービスです。大規模なネットワークを統合管理でき、VPC間やVPCとオンプレミスの接続を一元化できます。
これらのサービスを適切に組み合わせることで、セキュアで効率的なAWSインフラ管理が可能になります。
実践
略
一問道場
問題 #521
ある企業が、アプリケーションアカウント内のAmazon EC2インスタンスのパッチ管理方法を変更しています。現在、企業はインターネット経由で、アプリケーションアカウント内のVPCのNATゲートウェイを使用してインスタンスにパッチを適用しています。企業は、コアアカウント内の専用のプライベートVPCに設定されたEC2インスタンスをパッチソースリポジトリとして使用しています。企業は、AWS Systems Manager Patch Managerを使用し、コアアカウント内のパッチソースリポジトリを使用してアプリケーションアカウント内のEC2インスタンスにパッチを適用したいと考えています。
企業は、アプリケーションアカウント内のすべてのEC2インスタンスがインターネットにアクセスするのを防ぐ必要があります。また、アプリケーションデータが保存されているAmazon S3へのアクセスが必要です。さらに、アプリケーションアカウント内のEC2インスタンスは、Systems Managerおよびコアアカウント内のプライベートVPCにあるパッチソースリポジトリへの接続が必要です。
どの解決策がこれらの要件を満たすでしょうか？
選択肢:
A.
- アウトバウンドトラフィックをポート80でブロックするネットワークACLを作成します。
- アプリケーションアカウント内のすべてのサブネットにネットワークACLを関連付けます。
- アプリケーションアカウントおよびコアアカウント内にカスタムVPNサーバーを実行するEC2インスタンスを1台ずつデプロイします。
- VPNトンネルを作成してプライベートVPCにアクセスします。
- アプリケーションアカウントのルートテーブルを更新します。
B.
- Systems ManagerおよびAmazon S3用のプライベートVIFを作成します。
- アプリケーションアカウント内のVPCからNATゲートウェイを削除します。
- トランジットゲートウェイを作成してコアアカウント内のパッチソースリポジトリEC2インスタンスにアクセスします。
- コアアカウントのルートテーブルを更新します。
C.
- Systems ManagerおよびAmazon S3用のVPCエンドポイントを作成します。
- アプリケーションアカウント内のVPCからNATゲートウェイを削除します。
- パッチソースリポジトリEC2インスタンスにアクセスするためにVPCピアリング接続を作成します。
- 両方のアカウントのルートテーブルを更新します。
D.
- インバウンドトラフィックをポート80でブロックするネットワークACLを作成します。
- アプリケーションアカウント内のすべてのサブネットにネットワークACLを関連付けます。
- トランジットゲートウェイを作成してコアアカウント内のパッチソースリポジトリEC2インスタンスにアクセスします。
- 両方のアカウントのルートテーブルを更新します。
解説
Cの解説：
- VPCエンドポイントを使用して、Systems ManagerとAmazon S3へのプライベート接続を確保します。これにより、アプリケーションアカウント内のEC2インスタンスはインターネットにアクセスせず、S3やSystems Managerにアクセスできます。
- VPCピアリング接続を使用して、コアアカウントのパッチソースリポジトリにアクセスするための接続を作成します。この方法は、インターネット接続を避けつつ、プライベートネットワークを通じてアクセスできるため、要件に適しています。
他の選択肢との比較：
- BではプライベートVIF（Virtual Interface）を使用する提案があり、これも可能ですが、VPCエンドポイントを使用する方がシンプルで効率的です。
- AとDは、構成が複雑であり、要件に合わない部分があるため不適切です。
Cの選択肢は、セキュアでシンプルな接続方式を提供し、要求された要件（インターネットアクセスなし、必要なサービスへのアクセス）を満たす最適な方法です。
522-AWS SAP AWS 「理論・実践・一問道場」明確なアクセス制御 リージョンVPC
理論
1. VPCピアリング接続:
- VPCピアリング接続は、異なるVPC間でプライベートIPアドレスを使って通信を可能にする方法です。これにより、VPC内のリソースが他のVPCのリソースにアクセスできます。
- 単一リージョンまたはクロスリージョンで使用でき、接続されたVPC間での通信は、インターネットを介さずに行われるため、セキュリティ面での利点があります。
2. VPCピアリング接続の制限:
- 一度に2つのVPC間のみ接続可能です。複数のVPCを接続する場合、各VPC間に個別のピアリング接続を作成する必要があります。
- ルートテーブルの設定が重要です。VPCピアリング接続を作成した後、各VPCのルートテーブルにピアリング接続を経由するルートを追加する必要があります。
3. トラフィックのルーティング:
- ルートテーブルは、VPC内でトラフィックをどこに送るかを決定する設定です。VPC間で通信する場合、正しいルートを設定しないと、通信が失敗します。
- ピアリング接続を使う場合の注意: VPC間の通信を明示的に許可するため、両方のVPCのルートテーブルで適切な設定が必要です。
4. AWSトランジットゲートウェイ:
- トランジットゲートウェイは、複数のVPCやオンプレミスのネットワークを接続するための中央集約型のネットワークサービスです。これにより、VPC間のトラフィックを簡単に管理できますが、ピアリング接続と比べてコストが高く、設定も複雑になることがあります。
5. VPCピアリング vs トランジットゲートウェイ:
- VPCピアリング接続は、少数のVPCをシンプルに接続するのに適しています。
- トランジットゲートウェイは、複数のVPCやオンプレミス環境と接続する場合に効果的ですが、コストと管理の観点でより複雑になります。
ポイント:
- 少数のVPC間で通信が必要な場合は、VPCピアリング接続がシンプルでコスト効果が高い。
- 複数のVPC間で広範囲な接続が求められる場合、トランジットゲートウェイの方が適している場合がありますが、コスト面や複雑さに注意が必要です。
実践
略
一問道場
問題 #522
アメリカの企業（US企業）はヨーロッパの企業を買収しました。両企業はAWSクラウドを使用しています。US企業はマイクロサービスアーキテクチャを用いた新しいアプリケーションを開発しました。このアプリケーションは、us-east-2リージョンの5つのVPCにホストされています。アプリケーションは、eu-west-1リージョンの1つのVPCにあるリソースにアクセスできる必要があります。ただし、アプリケーションは他のVPCにはアクセスできないようにする必要があります。両リージョンのVPCはCIDR範囲が重複していません。すべてのアカウントはすでにAWS Organizations内で統合されています。
どのソリューションが最もコスト効率よくこれらの要件を満たしますか？
A. eu-west-1リージョンに1つのトランジットゲートウェイを作成します。us-east-2のVPCとeu-west-1のVPCをトランジットゲートウェイに接続します。トラフィックがトランジットゲートウェイを通るように、各VPCで必要なルートエントリを作成します。
B. 各リージョンに1つのトランジットゲートウェイを作成します。関与するサブネットを各リージョンのトランジットゲートウェイに接続します。トラフィックが各トランジットゲートウェイを通るように、関連するルートテーブルに必要なルートエントリを作成します。2つのトランジットゲートウェイをピアリングします。
C. すべてのVPC間でフルメッシュのVPCピアリング接続構成を作成します。トラフィックがVPCピアリング接続を通るように、各VPCで必要なルートエントリを作成します。
D. us-east-2の各VPCとeu-west-1のVPC間にVPCピアリング接続を1つずつ作成します。トラフィックがVPCピアリング接続を通るように、各VPCで必要なルートエントリを作成します。
解説
選択肢 D の解説を詳しくします。
問題の要件:
- US企業がホストするアプリケーションは、us-east-2リージョンの5つのVPCに展開されており、eu-west-1リージョンの1つのVPCにあるリソースにのみアクセスする必要があります。
- 他のVPCにはアクセスできないようにしたいという制限があります。
- CIDR範囲は重複していないため、VPC間の接続は可能です。
選択肢D: 各VPC間でVPCピアリング接続を作成
構成:
- us-east-2リージョン内の各VPC（5つのVPC）とeu-west-1リージョンのVPC（1つのVPC）間でVPCピアリング接続を作成します。
- 各VPCに適切なルートエントリを設定し、トラフィックが指定されたVPC間を通るようにします。
利点:
- 明確なアクセス制御:
各VPC間での通信をピアリング接続を通じて明確に制御できます。特定のVPC間だけに通信を許可できるため、セキュリティ要件に合致します。
- シンプルな構成:
ピアリング接続は比較的シンプルで直接的にVPC間を接続できます。各VPCのルートテーブルで適切に設定すれば、特定のVPC間だけの通信が実現できます。
デメリット:
- 複数のピアリング接続:
us-east-2の5つのVPCとeu-west-1のVPC間にピアリング接続を作成する必要があります。これにより、接続数が増え、管理が煩雑になる可能性があります。
- ルートテーブルの管理:
各VPCのルートテーブルに適切なエントリを設定する必要があります。誤った設定をすると、予期しないトラフィックがルーティングされる可能性があります。
- トラフィック制御の手間:
複数のピアリング接続を管理する場合、トラフィックのルーティングや通信経路の確認が必要となるため、VPCが増えると管理が少し煩雑になります。
選択肢Dが適している理由:
- この選択肢では、特定のVPC間にピアリング接続を設定することで、トラフィックが必要なVPCのみ通過するように管理できます。
- 5つのVPCをすべて一度に接続する必要はなく、最小限のVPC間でピアリング接続を設定するだけで済むため、コストと管理負担を抑えることができます。
他の選択肢と比較:
- A はトランジットゲートウェイを使用する方法で、1つのゲートウェイを設定することで複数のVPCを接続できますが、ピアリング接続と比べるとコストや構成が複雑になる場合があります。
- B や C では、複数のリージョンでトランジットゲートウェイを使用したり、フルメッシュのVPCピアリング接続を設定したりするため、これらの方法よりも管理が煩雑で高コストになります。
結論:
選択肢 D は、特定のVPC間のみ接続を許可し、余分なリソースやコストを避けながら効率的に要求を満たすため、最もシンプルでコスト効果の高い方法です。
523-AWS SAP AWS 「理論・実践・一問道場」SES
理論
1. Amazon SES（Simple Email Service）
- Amazon SESは、企業が大量のメールを送信するためのフルマネージドなメール送信サービスです。ユーザーに通知メールやマーケティングメールを送信する際に使用されます。
- SESは、メール送信の配信状況やエラーメッセージ、開封状況などのログを生成します。これらのログは、トラブルシュートや分析に役立ちます。
2. SES設定セットとログ管理
- SES設定セットは、送信したメールに関連する詳細なログを収集するための設定です。これにより、配信ステータス、エラー、受信者の反応（開封、クリックなど）を記録できます。
- SES設定セットを使用すると、メールの送信履歴をAmazon S3バケットに保存し、後で分析することができます。
3. Amazon Athena
- Amazon Athenaは、S3に保存されたデータに対してSQLライクなクエリを実行できるインタラクティブなクエリサービスです。Athenaを使用することで、データをS3に格納したままで高速に分析できます。
- SESログをS3に保存し、Athenaでクエリを実行すれば、受信者、件名、送信時間などに基づいて詳細な検索が可能です。
4. ログの保存とクエリの仕組み
- SESのログは、S3バケットに保存した後、Athenaを使って簡単にクエリできます。これにより、特定の期間に送信されたメールの詳細を検索することができます。
- SESでのログ保存先にはS3が一般的に使われ、Athenaや他の分析ツールを使ってデータを解析します。
5. Amazon CloudTrailとCloudWatch
- Amazon CloudTrailは、AWSアカウントでのAPI呼び出しや操作を記録するサービスであり、SESの配信ログとは直接関係しません。CloudTrailは主にAWSサービスの操作履歴を追跡します。
- Amazon CloudWatchは、アプリケーションやインフラのモニタリングを行うためのサービスで、CloudWatch Logsは主にメトリクスやアラームのために使用され、SESの送信ログとは異なります。
ポイント
- SESログの管理には、設定セットを使ってログを収集し、Athenaで分析を行う方法が効果的です。
- SESとS3、Athenaを組み合わせることで、簡単にログを保存し、必要な情報を検索できます。
この知識を活用することで、メール送信に関する詳細な分析とトラブルシューティングが効率的に行えるようになります。
実践
略
一問道場
問題 #523
ある旅行会社が、ユーザーにメール通知を送信するためにAmazon Simple Email Service (Amazon SES)を使用してウェブアプリケーションを構築しました。会社は、メール配信の問題をトラブルシュートするためにログ記録を有効にする必要があります。また、受信者、件名、送信時間に基づいて検索できる機能が必要です。
この要件を満たすためにソリューションアーキテクトが取るべき手順はどれですか？（2つ選んでください）
A. Amazon SESの設定セットを作成し、Amazon Data Firehoseを宛先として指定します。ログをAmazon S3バケットに送信するオプションを選択します。
B. AWS CloudTrailログを有効にし、ログの宛先としてAmazon S3バケットを指定します。
C. Amazon Athenaを使用して、Amazon S3バケット内のログを受信者、件名、送信時間でクエリします。
D. Amazon CloudWatchロググループを作成し、Amazon SESを構成してログをそのロググループに送信します。
E. Amazon Athenaを使用して、Amazon CloudWatch内のログを受信者、件名、送信時間でクエリします。
解説
目標:
- メール配信の問題をトラブルシュートするためにログを有効化。
- 受信者、件名、送信時間に基づいてメールのログを検索できる機能を実装。
要件に対応する方法:
A. Amazon SES設定セットとAmazon Data Firehoseを使用してログをS3バケットに送信
- Amazon SES設定セットは、Amazon SESのログを管理するための方法の1つです。設定セットを使用して、配信状況の詳細なログを収集できます。
- Amazon Kinesis Data Firehoseを宛先として設定すると、リアルタイムでデータをAmazon S3にストリーミングできます。これにより、メールの送信情報を収集し、後でクエリを実行できます。
- S3バケットに保存されたログは、後でクエリを実行するために使用でき、受信者や送信時間、件名を基に検索できます。
C. Amazon Athenaを使用してS3バケット内のログをクエリ
- Amazon Athenaは、S3バケットに保存されたデータに対してSQLライクなクエリを実行できるサービスです。S3に保存されたSESログファイルに対して、受信者、件名、送信時間などを条件にクエリを行えます。
- Athenaを使用すれば、必要な情報を簡単に検索できます。
他の選択肢の理由:
B. AWS CloudTrailログを有効にし、S3バケットに送信
- AWS CloudTrailはAWSアカウントでのAPI呼び出しやイベントを記録するサービスですが、Amazon SESの配信ログや詳細なメール送信情報をCloudTrailで直接収集することはできません。したがって、CloudTrailはこの要件には適していません。
D. Amazon CloudWatchロググループを作成し、SESにログを送信
- Amazon SES自体は、CloudWatchにメール送信の詳細なログを送る機能を持っていません。SESのログはCloudWatch Logsに送信できないため、この選択肢は適用外です。
E. Amazon Athenaを使用してCloudWatch内のログをクエリ
- CloudWatchは主にシステムのメトリクスやアラーム用のサービスであり、SESの配信ログは通常CloudWatchに格納されません。したがって、CloudWatch内のログをAthenaでクエリすることはできません。
結論:
- AとCの組み合わせが最も効果的です。SESの設定セットを使用してログを収集し、その後、Athenaを使ってS3内のログデータをクエリして、受信者、件名、送信時間などの情報を検索することができます。
524-AWS SAP AWS 「理論・実践・一問道場」Trusted Advisor
理論
AWS EC2インスタンスの過小利用を検出して停止する方法
AWS（Amazon Web Services）の利用において、EC2インスタンスはクラウド環境の基盤を支える重要なリソースですが、長期間使用されていないインスタンスや低利用率のインスタンスがコストの無駄を引き起こすことがあります。そのため、過小利用のEC2インスタンスを自動的に検出して停止することは、コスト効率を改善するための重要な手段です。
1. AWS Trusted Advisorを使用した低利用率のインスタンス検出
AWS Trusted Advisorは、AWS環境の最適化に役立つ推奨事項を提供します。Trusted Advisorの「低利用のEC2インスタンス」レポートは、CPU利用率が低いインスタンスを自動的に検出するために使用されます。これにより、リソースが過剰に消費されているインスタンスを発見し、停止を検討できます。
2. Amazon CloudWatchによるリソース監視
Amazon CloudWatchは、EC2インスタンスのパフォーマンスメトリクス（CPU利用率、ネットワークI/Oなど）をリアルタイムで監視します。CloudWatchアラームを設定して、低利用のインスタンスを特定することができます。これらのメトリクスを基に、Lambda関数を呼び出してインスタンスを停止する自動化が可能です。
3. Amazon EventBridgeによる自動化
Amazon EventBridgeは、AWSサービス間でイベントをトリガーするサービスです。EventBridgeを使うことで、低利用インスタンスに関連するアクション（例えば、インスタンス停止）を自動的に実行するルールを作成できます。例えば、Trusted AdvisorやCloudWatchで検出された低利用のインスタンスを停止するためのイベントルールを設定することができます。
4. タグを活用したフィルタリング
インスタンスにタグを付けることで、部門やビジネスユニットごとにリソースを管理できます。これにより、過小利用インスタンスを部門ごとに識別して停止することが可能になります。例えば、「環境」や「ビジネスユニット」などのタグを使って、対象インスタンスをフィルタリングし、必要なインスタンスのみを停止することができます。
5. AWS Lambdaでの自動化
AWS Lambdaを活用することで、コードを使ってEC2インスタンスを自動的に管理できます。例えば、CloudWatchメトリクスやEventBridgeイベントに基づいて、インスタンスの停止や開始を自動化するLambda関数を作成することができます。
まとめ
過小利用のEC2インスタンスを特定して停止するためには、AWSのさまざまなツール（Trusted Advisor、CloudWatch、EventBridge、Lambda）を組み合わせて利用することが重要です。これにより、コスト削減と運用の効率化を図ることができます。
実践
略
一問道場
質問 #524
ある企業はAWSに移行し、AWSビジネスサポートを利用しています。この企業は、AWSアカウント全体でAmazon EC2インスタンスのコスト効率を監視したいと考えています。EC2インスタンスには、部門、ビジネスユニット、および環境のタグが付けられています。開発用EC2インスタンスはコストが高いが、利用率は低いです。
この企業は、過去14日間のうち4日以上、平均CPU利用率が10％以下、ネットワークI/Oが5MB以下であった開発用EC2インスタンスを検出して停止する必要があります。
どのソリューションが最も運用負荷を抑えてこの要件を満たしますか？
A. 部門、ビジネスユニット、および環境のタグに基づいてEC2インスタンスの利用率を監視するためにAmazon CloudWatchダッシュボードを構成します。Amazon EventBridgeルールを作成して、AWS Lambda関数を呼び出し、過小利用の開発用EC2インスタンスを停止します。
B. AWS Systems Managerを構成してEC2インスタンスの利用率を追跡し、過小利用のインスタンスをAmazon CloudWatchに報告します。CloudWatchデータを部門、ビジネスユニット、および環境のタグでフィルタリングします。Amazon EventBridgeルールを作成して、AWS Lambda関数を呼び出し、過小利用の開発用EC2インスタンスを停止します。
C. AWS Trusted Advisorが報告するEC2インスタンスの低利用率を検出するためにAmazon EventBridgeルールを作成します。ルールを設定して、AWS Lambda関数を呼び出し、部門、ビジネスユニット、および環境のタグでデータをフィルタリングし、過小利用の開発用EC2インスタンスを停止します。
D. 毎日実行されるAWS Lambda関数を作成して、すべてのEC2インスタンスの利用率データを取得します。データをAmazon DynamoDBテーブルに保存します。Amazon QuickSightダッシュボードを作成し、DynamoDBテーブルをデータソースとして使用して、過小利用の開発用EC2インスタンスを識別し停止します。
解説
正解は C です。
C. AWS Trusted Advisorが報告するEC2インスタンスの低利用率を検出するためにAmazon EventBridgeルールを作成します。ルールを設定して、AWS Lambda関数を呼び出し、部門、ビジネスユニット、および環境のタグでデータをフィルタリングし、過小利用の開発用EC2インスタンスを停止します。
解説:
- AWS Trusted Advisor は、EC2インスタンスのリソースが過剰に使用されているかどうかに関する推奨事項を提供します。特に、低利用率のインスタンスを検出するために便利です。
- EventBridge でトリガーを設定し、AWS Lambda を呼び出して、過小利用の開発用EC2インスタンスを停止することができます。
- タグによるフィルタリング も可能で、部門、ビジネスユニット、環境に基づいてインスタンスを識別できます。
他の選択肢に比べて、Trusted Advisorを活用することで、過小利用のインスタンスを効率的に検出し、自動で停止する流れが簡素化され、運用負荷を最小限に抑えることができます。
525-AWS SAP AWS 「理論・実践・一問道場」Auto Scaling
理論
AWSにおけるスケーラブルなアーキテクチャ設計とコスト効率の最適化
AWSでは、アプリケーションがスムーズに運用されるように、リソースのスケーラビリティとコスト効率を確保するためのさまざまな方法があります。特に、EC2インスタンスや負荷分散のリソースを適切にスケールさせることは、アプリケーションのパフォーマンス向上とコスト削減に重要です。
1. Auto ScalingとElastic Load Balancing (ELB)
- Auto Scalingは、アプリケーションの負荷に応じてEC2インスタンスの数を自動的に増減させる仕組みです。これにより、トラフィックが増加しても、アプリケーションがスムーズにスケールアウトして、過剰にリソースを消費せずに効率的に処理できます。逆に、負荷が低くなると、リソースを自動で縮小し、コストを削減します。
- *Elastic Load Balancer (ELB)**は、トラフィックを複数のインスタンスに分散させ、アプリケーションのパフォーマンスを向上させます。ネットワークロードバランサー（NLB）やアプリケーションロードバランサー（ALB）がよく使用され、適切な選択はアプリケーションの特性に応じて異なります。
2. EC2インスタンスの購入オプション
- オンデマンドインスタンス: 必要なときにリソースを即座に使用できる柔軟な方法ですが、コストが高くなる可能性があります。
- リザーブドインスタンス: 長期間（1年または3年）にわたって使用する予定のインスタンスに対して、事前に予約することで割引を受けられるオプションです。安定した使用が見込まれるリソースに最適です。
- スポットインスタンス: 需要が低い時に、未使用のEC2インスタンスを割安な価格で購入できるオプションです。ただし、インスタンスが中断される可能性があるため、可用性が高いことが求められない場合に適しています。
3. Auto Scalingの設定
Auto Scalingグループを適切に設定することで、アプリケーションのリソースのスケーリングを効率的に管理できます。例えば、最小容量を低めに設定し、最大容量を高めに設定することで、通常の負荷に合わせてリソースを抑え、ピーク時に必要なインスタンス数を自動で増やすことができます。これにより、スケーラビリティを確保しつつ、無駄なコストを削減できます。
4. 価格最適化のための戦略
- リザーブドインスタンスの活用: 長期間にわたって稼働する予定のアプリケーションに対しては、リザーブドインスタンスを利用することでコストを削減できます。定期的な使用が予測されるリソースには特に有効です。
- スポットインスタンスの活用: 高度なスケーラビリティを必要とする一時的なタスクやワークロードには、スポットインスタンスを活用することでコストを削減できます。中断される可能性があるため、安定した稼働が必要な場合には適さないことを留意する必要があります。
5. パフォーマンスとコストのバランス
AWSでは、パフォーマンスとコストの最適化をバランスよく実現するために、さまざまなリソースとサービスを活用することが重要です。Auto Scalingや負荷分散の技術を組み合わせることで、トラフィックの増加に応じて適切にリソースを追加し、ピーク時でもパフォーマンスを維持しながらコストを最適化できます。
まとめ
AWSでのアーキテクチャ設計では、スケーラビリティとコスト効率の最適化が鍵となります。Auto ScalingやElastic Load Balancer、インスタンスの購入オプションを適切に活用することで、アプリケーションのパフォーマンスを維持しつつ、運用コストを最小限に抑えることができます。
実践
略
一問道場
質問 #525
ある企業がAWS上でプロジェクト用のアプリケーションをホスティングしています。このプロジェクトは今後3年間実行される予定です。アプリケーションは、ネットワークロードバランサー（NLB）のターゲットグループに登録された20のAmazon EC2オンデマンドインスタンスで構成されています。インスタンスは2つのアベイラビリティゾーンに分散されています。アプリケーションはステートレスで、24時間365日稼働します。
ユーザーからアプリケーションの応答が遅いという報告を受けています。パフォーマンスのメトリクスでは、通常のアプリケーション利用時にインスタンスのCPU使用率が10%であることが示されています。しかし、ピーク時にはCPU使用率が100%に達し、通常数時間続きます。
この企業はアプリケーションの応答が遅くなる問題を解決するための新しいアーキテクチャを必要としています。
最もコスト効率よくこの要件を満たす解決策はどれですか？
A. Auto Scalingグループを作成し、Auto ScalingグループをNLBのターゲットグループにアタッチします。最小容量を20、希望容量を28に設定します。20インスタンス分のリザーブドインスタンスを購入します。
B. リクエストタイプを「request」とするSpot Fleetを作成します。TotalTargetCapacityパラメータを20に設定し、DefaultTargetCapacityTypeパラメータを「On-Demand」に設定します。Spot Fleet作成時にNLBを指定します。
C. リクエストタイプを「maintain」とするSpot Fleetを作成します。TotalTargetCapacityパラメータを20に設定し、DefaultTargetCapacityTypeパラメータを「Spot」に設定します。NLBをアプリケーションロードバランサー（ALB）に置き換えます。
D. Auto Scalingグループを作成し、Auto ScalingグループをNLBのターゲットグループにアタッチします。最小容量を4、最大容量を28に設定します。4インスタンス分のリザーブドインスタンスを購入します。
解説
この問題は、アプリケーションのパフォーマンス向上とコスト効率を最適化するために、スケーラブルなソリューションを導入する方法を尋ねています。アプリケーションのインスタンスは、通常時には低いCPU使用率（10%）で動作し、ピーク時にCPU使用率が100%になることがわかっています。問題は、ピーク時に十分なリソースを提供しつつ、コストを抑える方法です。
各選択肢を見ていきましょう：
A. Auto Scalingグループを作成し、Auto ScalingグループをNLBのターゲットグループにアタッチします。最小容量を20、希望容量を28に設定します。20インスタンス分のリザーブドインスタンスを購入します。
- 評価: Auto Scalingグループを使用して、需要に応じてインスタンスの数を自動的に調整するアプローチです。最小容量を20、希望容量を28に設定することで、通常の利用時とピーク時の負荷に対応できます。また、リザーブドインスタンスを購入することで、長期的にコストを削減できます。
- 問題点: 希望容量が28に設定されているため、常に28インスタンス分のリソースを使用することになります。これではピーク時を除いてオーバープロビジョニングとなり、コスト効率が悪化します。
B. リクエストタイプを「request」とするSpot Fleetを作成します。TotalTargetCapacityパラメータを20に設定し、DefaultTargetCapacityTypeパラメータを「On-Demand」に設定します。Spot Fleet作成時にNLBを指定します。
- 評価: Spot Fleetを使用して、インスタンス数を必要に応じて調整する方法です。
TotalTargetCapacityが20に設定されており、オンデマンドインスタンスを使用するため、ピーク時のリソース需要に対応できます。しかし、Spotインスタンスはコスト効率が良いものの、価格が変動するため、安定したリソース供給には向いていません。また、Spotインスタンスは中断されるリスクもあります。
- 問題点: 本番環境では、Spotインスタンスの中断リスクがアプリケーションのパフォーマンスに影響を与える可能性があるため、安定性が必要なシステムには向いていません。
C. リクエストタイプを「maintain」とするSpot Fleetを作成します。TotalTargetCapacityパラメータを20に設定し、DefaultTargetCapacityTypeパラメータを「Spot」に設定します。NLBをアプリケーションロードバランサー（ALB）に置き換えます。
- 評価:
maintainリクエストタイプでは、Spotインスタンスを使用して、所定のリソース数を維持するように設定できます。しかし、Spotインスタンスは中断される可能性があり、NLBをALBに変更することが要件に関係ないので、コスト効率に寄与しない可能性があります。
- 問題点: Spotインスタンスの使用は依然として中断リスクがあり、ALBへの変更がアーキテクチャに影響を与える可能性があります。従って、信頼性の高い解決策ではありません。
D. Auto Scalingグループを作成し、Auto ScalingグループをNLBのターゲットグループにアタッチします。最小容量を4、最大容量を28に設定します。4インスタンス分のリザーブドインスタンスを購入します。
- 評価: この方法では、Auto Scalingグループを使用して、最小容量を4、最大容量を28に設定することで、ピーク時に柔軟に対応できます。4インスタンス分のリザーブドインスタンスを購入することで、最も安定したリソース供給ができます。オートスケーリングにより、リソースの過剰プロビジョニングを避けつつ、ピーク時に必要な容量を確保できます。
- 最もコスト効率的な解決策: リザーブドインスタンスを購入することでコスト削減が可能です。また、最小容量を4に設定することで、通常時にはリソースを節約し、ピーク時には最大容量を28に拡張して対応します。これにより、スケーラビリティとコスト効率が最適化されます。
結論:
最もコスト効率的で柔軟に対応できる解決策は D です。Auto Scalingを使用して、最小容量を4、最大容量を28に設定し、リザーブドインスタンスを購入することで、通常時のコストを抑えつつ、ピーク時の需要にも対応できます。
526-AWS SAP AWS 「理論・実践・一問道場」AWS IoT Core
理論
1. AWS IoT Core
AWS IoT Coreは、クラウド上でのIoTデバイスとの接続とデータ送信を管理するサービスです。センサーデータやデバイスからのデータをリアルタイムで処理し、他のAWSサービス（例: Lambda, S3, DynamoDBなど）と連携することができます。これにより、IoTデバイスからのデータを効率的に取り込み、処理することが可能です。
- 用途: センサーデータの収集、デバイスとの双方向通信、データのルーティング。
2. AWS Lambda
AWS Lambdaは、サーバーレスでコードを実行できるサービスです。データをリアルタイムで処理したり、トリガーに基づいて自動的に実行される関数を作成できます。Lambdaは、データの強化（エンリッチ）や変換を行う場合に非常に役立ちます。
- 用途: データの変換、強化、フィルタリング、S3などの他のサービスへの書き込み。
3. Amazon Kinesis Data Firehose
Kinesis Data Firehoseは、データストリームを収集、処理、および配信するサービスです。通常、大量のデータをリアルタイムで受け取り、他のストレージサービス（例: S3、Redshift、Elasticsearch）に転送します。Kinesis Data Firehoseはバッファリングの設定（最大15分）を行うため、リアルタイム性が重要なシナリオでは遅延が発生する可能性があります。
- 用途: データのリアルタイム配信、バッファリング、ストレージへの転送。
4. Amazon S3
Amazon S3は、オブジェクトストレージサービスであり、大規模なデータの保存、バックアップ、およびアーカイブに使用されます。センサーデータなどの大容量の非構造化データを格納するのに適しています。
- 用途: データの永続的保存、分析用データのストレージ、アーカイブ。
データの強化（エンリッチ）
データの強化とは、元のデータに新たな情報を追加するプロセスです。センサーデータにメタデータを付加したり、外部ソースからの情報を統合することで、データをさらに価値あるものにします。例えば、センサーの温度データに場所やタイムスタンプ、デバイスIDを追加することがこれに当たります。
- 使用例: センサーデータの補完、外部データとの統合、異常検知。
適切なアーキテクチャの選択
IoTデータの収集と処理においては、データの遅延やコスト、スケーラビリティを考慮する必要があります。AWS IoT CoreとLambdaを組み合わせる方法は、シンプルで低遅延であり、コスト効率も高いといった特徴があります。一方、Kinesis Data Firehoseや他のストリーミングサービスは、大規模なデータの処理やリアルタイム配信が求められる場合に適していますが、設定や管理が複雑になることがあります。
要点まとめ
- AWS IoT Core でセンサーデータを収集し、AWS Lambda でリアルタイム処理（データの強化など）を行う。
- データは、Amazon S3 などのストレージに送信して保存する。
- コスト効率と処理速度を最適化するために、シンプルなアーキテクチャを選択することが重要。
実践
略
一問道場
質問 #526
企業は、工場からセンサーのデータを収集して送信するアプリケーションを構築しています。このアプリケーションは、AWS IoT Coreを使用して、数百のデバイスからデータをAmazon S3データレイクに送信します。データをAmazon S3にロードする前に、データを強化（エンリッチ）する必要があります。
アプリケーションは、毎秒5回センサーのデータを送信します。新しいセンサーデータは、アプリケーションがデータを収集してから30分以内にAmazon S3に利用可能である必要があります。他のアプリケーションはAWS IoT Coreからのセンサーデータを処理していません。
この要件を最もコスト効率よく満たす解決策はどれですか？
A. AWS IoT Coreでトピックを作成してセンサーデータを取り込みます。AWS Lambda関数を作成してデータを強化し、データをAmazon S3に書き込みます。AWS IoTルールアクションを設定してLambda関数を呼び出します。
B. AWS IoT Core Basic Ingestを使用してセンサーデータを取り込みます。AWS IoTルールアクションを設定してデータをAmazon Kinesis Data Firehoseに書き込みます。Kinesis Data Firehoseのバッファリング間隔を900秒に設定します。Kinesis Data Firehoseを使用してAWS Lambda関数を呼び出し、データを強化します。Kinesis Data Firehoseを設定してデータをAmazon S3に配信します。
C. AWS IoT Coreでトピックを作成してセンサーデータを取り込みます。AWS IoTルールアクションを設定してデータをAmazon Timestreamテーブルに送信します。AWS Lambda関数を作成してTimestreamからデータを読み込みます。Lambda関数を設定してデータを強化し、Amazon S3に書き込みます。
D. AWS IoT Core Basic Ingestを使用してセンサーデータを取り込みます。AWS IoTルールアクションを設定してデータをAmazon Kinesis Data Streamsに書き込みます。Kinesis Data Streamsからデータを処理して強化する消費者AWS Lambda関数を作成します。Lambda関数からS3のPutObject API操作を呼び出して、データをAmazon S3に書き込みます。
解説
この問題では、センサーデータを収集し、AWS IoT Coreを使ってデータをAmazon S3に送信する前に、データを「強化（エンリッチ）」する必要があるという要件に基づいたソリューションを求めています。センサーデータは、通常、ストレートな測定値（温度、湿度、圧力など）であり、これを単に保存するだけではなく、価値を加えてから保存する必要があります。
各選択肢の評価
A. Lambda関数を使ってデータを強化してS3に書き込む
- プロセス: センサーデータをAWS IoT Coreで取り込み、AWS Lambda関数を使ってデータを強化し、その後、S3にデータを保存する方法です。
- 評価: シンプルで効果的な方法です。AWS Lambdaは非常に柔軟で、データの強化（変換、フィルタリング、メタデータ追加など）を簡単に行うことができます。この方法は、要件に従ってデータをS3に迅速に書き込むため、コスト効率も良好です。
- 適切な理由: Lambdaを使ってデータをリアルタイムで処理し、S3に迅速にデータを保存できるため、要件（30分以内にデータをS3に格納）に十分に対応できます。
B. Kinesis Data Firehoseを使ってデータを強化
- プロセス: AWS IoT CoreからデータをKinesis Data Firehoseに送信し、そこでLambdaを使ってデータを強化し、その後S3に配信する方法です。
- 評価: Kinesis Data Firehoseはバッファリング機能を提供しており、大量のデータを効率よく転送できますが、Kinesisのバッファリングインターバル（最大900秒）や設定が30分以内の遅延要件に対して十分に適切かどうかを慎重に考える必要があります。また、Firehoseの設定により、データ転送時にわずかな遅延が生じる可能性があります。
- 問題点: 30分以内にデータをS3に保存するという要件を満たすためには、Kinesisのバッファリングインターバルが適切でなければなりません。遅延が問題となる可能性があります。
C. Timestreamを使ってデータを強化
- プロセス: AWS IoT CoreからAmazon Timestreamにデータを送信し、その後Lambdaを使ってデータを強化してS3に書き込む方法です。
- 評価: Amazon Timestreamは時系列データの処理に特化したサービスであり、センサーのデータには有効ですが、このケースではデータを強化するという要件に対しては過剰な処理になります。Timestreamは時系列データを保存するためのサービスで、強化（エンリッチ）処理に必要な柔軟性は少ないため、過剰なアーキテクチャになりがちです。
- 問題点: 追加のサービス（Timestream）を導入することで、シンプルで効率的な処理方法を見失う可能性があります。
D. Kinesis Data Streamsを使ってデータを強化
- プロセス: AWS IoT CoreからKinesis Data Streamsにデータを送信し、消費者Lambda関数でデータを強化してS3に書き込む方法です。
- 評価: Kinesis Data Streamsは非常にリアルタイムでデータをストリーミングできますが、設定や管理が少し複雑になることがあります。また、データの強化処理が複雑であるため、Lambda関数を多く使う必要があり、オーバーヘッドが大きくなる可能性があります。
- 問題点: Kinesis Data Streamsは非常に高性能ですが、Lambdaの消費者関数やストリームの管理が煩雑になるため、シンプルな解決策を望む場合には向いていないかもしれません。
結論:
最もコスト効率が良い解決策は A です。AWS IoT Coreを使用してセンサーデータを取り込み、そのデータをLambda関数で強化してから直接S3に保存する方法は、シンプルでありながら、必要な処理を効果的に行えます。Lambdaは非常に柔軟で、データをリアルタイムで処理し、すぐにS3に保存できるため、30分以内のデータ更新要件にも適しています。
527-AWS SAP AWS 「理論・実践・一問道場」S3アクセスポイント
理論
S3アクセスポイントは特にVPC内でのアクセス管理に便利ですが、複数アカウント間でアクセスする際に直接必要とは言えません。このシナリオではVPCエンドポイントを使用する方が適切です。
別のAWSアカウントのVPCにおいて、EC2インスタンスからS3にアクセスするために、ゲートウェイVPCエンドポイントを作成することが必要です。これにより、インターネット経由ではなく、VPC内で直接S3にアクセスできます。
実践
略
一問道場
問題 #527
ある企業が多数のIoTデバイスからデータを収集しています。そのデータはAmazon S3データレイクに保存されています。データサイエンティストは、別のAWSアカウント内のVPCの2つのパブリックサブネットで実行されているAmazon EC2インスタンスで分析を行っています。データサイエンティストは、EC2インスタンスからデータレイクにアクセスする必要があります。EC2インスタンスには、すでにAmazon S3へのアクセス権限を持つロールが割り当てられています。企業のポリシーによれば、IoTデータにアクセスできるのは承認されたネットワークのみです。
この要件を満たすために、ソリューションアーキテクトが取るべき手順の組み合わせはどれですか？（2つ選択してください。）
A. データサイエンティストのVPCに対してAmazon S3のゲートウェイVPCエンドポイントを作成する。
B. データレイクのためにデータサイエンティストのAWSアカウントでS3アクセスポイントを作成する。
C. EC2インスタンスのロールを更新し、s3:GetObjectアクションを許可するポリシーを追加します。条件キー
s3:DataAccessPointArnの値が有効なアクセスポイントARNの場合に許可します。D. VPCルートテーブルを更新し、S3トラフィックをS3アクセスポイントにルーティングする。
E. S3バケットポリシーを追加し、条件キー
s3:DataAccessPointArnの値が有効なアクセスポイントARNの場合にs3:GetObjectアクションを許可する。解説
このシナリオにおける要件は、データサイエンティストが特定のネットワーク（すなわちVPC）からのみAmazon S3データレイクにアクセスできることです。そのため、最も重要な点はアクセスの制限です。ポリシーによって、特定のVPCのみがデータにアクセスできるようにする必要があります。解答を選ぶために要件を満たす方法を見ていきます。
選択肢の検討：
- A. データサイエンティストのVPCに対してAmazon S3のゲートウェイVPCエンドポイントを作成する。
- 正解です。 ゲートウェイVPCエンドポイントを使用することで、インターネットを経由せずに、VPC内から直接S3にアクセスすることができます。これにより、アクセスがネットワーク内に限定され、承認されたVPCからのみS3データレイクにアクセス可能になります。
- B. データレイクのためにデータサイエンティストのAWSアカウントでS3アクセスポイントを作成する。
- 不正解です。 アクセスポイントは特にVPC内からアクセスを管理するためのもので、必ずしもVPCエンドポイントを使用してアクセスを制限する要件には合いません。この場合、アクセスポイントは利用しない方がよいです。
- C. EC2インスタンスのロールを更新し、s3:GetObjectアクションを許可するポリシーを追加します。条件キー
s3:DataAccessPointArnの値が有効なアクセスポイントARNの場合に許可します。 - 不正解です。
s3:DataAccessPointArnの条件を追加することは、特定のアクセスポイント経由でのアクセスに制限するためのものですが、VPCに対するアクセス制限に必要なアクションではありません。この条件は必要ありません。
- D. VPCルートテーブルを更新し、S3トラフィックをS3アクセスポイントにルーティングする。
- 不正解です。 VPCのルートテーブルを更新してS3のトラフィックをアクセスポイントにルーティングすることは、必要な手順ではありません。エンドポイントで十分に管理できます。
- E. S3バケットポリシーを追加し、条件キー
s3:DataAccessPointArnの値が有効なアクセスポイントARNの場合にs3:GetObjectアクションを許可する。 - 正解です。 S3バケットポリシーにおいて、アクセスポイントARNを条件にアクセスを制限することで、特定のVPCまたはネットワークからのみアクセスできるようにすることが可能です。
結論
要件を満たすためには、以下の手順を取るべきです：
- A: ゲートウェイVPCエンドポイントを作成することで、VPC内からインターネットを経由せずにS3にアクセスできるようにする。
- E: S3バケットポリシーに条件を追加し、特定のアクセスポイントからのアクセスのみを許可する。
よって、正解は A と E です。
528-AWS SAP AWS 「理論・実践・一問道場」Migration Evaluator
理論
総所有コスト（TCO）評価
総所有コスト（TCO）は、ITインフラストラクチャをクラウドに移行する際の全体的なコストを評価するための重要な指標です。TCO評価には、オンプレミスのシステムとクラウドベースのシステム（例えばAWS）の運用コストを比較することが含まれます。主に以下の要素を考慮します。
1. オンプレミスのコスト要素
- ハードウェアコスト：サーバー、ストレージ、ネットワーク機器などの初期費用。
- 運用コスト：施設管理、電力、冷却、スタッフによるメンテナンス費用。
- ソフトウェアライセンス：使用しているソフトウェアやライセンスの費用。
2. クラウド（AWS）コスト要素
- コンピューティング：EC2インスタンスやLambdaの使用料金。
- ストレージ：S3、EBS、Glacierなどのストレージサービス費用。
- ネットワーキング：データ転送、VPN、Direct Connectなどのコスト。
- データベース：Amazon RDS、Auroraなどのデータベースサービス利用料金。
3. TCO評価ツール
AWSなどのクラウドプロバイダーは、TCO評価を支援するツールを提供しています。例えば、AWS Migration Evaluator（旧称TCO Calculator）は、オンプレミス環境とAWS環境のコストを比較し、移行後の予想コストを見積もるツールです。このツールは、移行に必要なリソースやコスト削減の機会を特定し、詳細なコストレポートを提供します。
4. TCO評価のプロセス
- データ収集：オンプレミスのインフラストラクチャに関するデータを収集します（使用しているハードウェア、ソフトウェア、運用コストなど）。
- シナリオ設定：クラウド環境に移行した場合のシナリオを設定します。例えば、EKSへの移行やRDSの利用を考慮します。
- コスト計算：移行後のクラウド環境でのコストを算出し、オンプレミスとの比較を行います。
5. 移行後の価値
TCO評価はコストだけでなく、クラウドへの移行がもたらす長期的な価値（例えば、スケーラビリティ、柔軟性、可用性、運用の簡素化など）も考慮に入れるべきです。クラウドへの移行がコスト削減と運用効率の向上にどれだけ貢献するかを評価することが重要です。
TCO評価を行うことで、企業は移行の実行可能性を理解し、コストとリスクを適切に管理することができます。
実践
略
一問道場
問題 #528
ある企業がウェブサイトをAWSに移行したいと考えています。ウェブサイトはコンテナを使用しており、オンプレミスの自己管理型Kubernetesクラスターにデプロイされています。ウェブサイトのデータはすべてオンプレミスのPostgreSQLデータベースに保存されています。
企業は、オンプレミスのKubernetesクラスターをAmazon Elastic Kubernetes Service (Amazon EKS) クラスターに移行することを決定しました。EKSクラスターはEKS管理ノードグループを使用し、ノード数は静的に設定されます。また、オンプレミスのデータベースをAmazon RDS for PostgreSQLデータベースに移行します。
ソリューションアーキテクトは、このワークロードの移行前に総所有コスト（TCO）を見積もる必要があります。
どのソリューションが必要なTCO情報を提供しますか？
A. Migration Evaluatorにアクセスをリクエストし、Migration Evaluator Collectorを実行してデータをインポートします。シナリオを設定し、Migration EvaluatorからQuick Insightsレポートをエクスポートします。
B. AWS Database Migration Service（AWS DMS）をオンプレミスのデータベースに対して起動し、評価レポートを生成します。EKS移行のコストについてAWS Pricing Calculatorで見積もりを作成します。
C. AWS Application Migration Serviceを初期化し、オンプレミスのサーバーをソースサーバーとして追加します。テストインスタンスを起動し、Application Migration ServiceからTCOレポートを出力します。
D. AWS Cloud Economics Centerのウェブページにアクセスして、AWS Cloud Value Frameworkを評価します。Cloud Value FrameworkからAWSのコストと使用状況レポートを作成します。
解説
この問題は、**総所有コスト（TCO）**を見積もる方法に関するものです。TCOは、企業がAWSに移行する際にかかる総コストを評価するために重要な指標です。解答の選択肢を評価して、どの方法が最も適切かを見ていきましょう。
各選択肢の評価：
A. Migration Evaluatorにアクセスをリクエストし、Migration Evaluator Collectorを実行してデータをインポートします。シナリオを設定し、Migration EvaluatorからQuick Insightsレポートをエクスポートします。
- 正解です。
- Migration Evaluator（以前の「TCO Calculator」）は、AWSへの移行に関するTCO情報を提供するツールです。このツールを使うことで、企業が現在のインフラストラクチャのコストと、AWSへの移行後のコストを比較することができます。Migration Evaluatorは、オンプレミスの環境からデータを収集し、AWSでの運用コストを推定するための強力なツールです。
- Quick Insightsレポートをエクスポートすることで、移行に関するコストの詳細な分析を取得できます。
B. AWS Database Migration Service（AWS DMS）をオンプレミスのデータベースに対して起動し、評価レポートを生成します。EKS移行のコストについてAWS Pricing Calculatorで見積もりを作成します。
- 不正解です。
- AWS DMSは、データベース移行を支援するツールであり、TCOの見積もりを直接提供するものではありません。DMSはデータベースの移行を行うツールであり、コスト評価の目的には使用されません。
- AWS Pricing Calculatorを使ってEKSのコスト見積もりを行うことはできますが、TCOを全体的に見積もるためには、移行シナリオの全体的なコストを考慮するツール（Migration Evaluator）が必要です。
C. AWS Application Migration Serviceを初期化し、オンプレミスのサーバーをソースサーバーとして追加します。テストインスタンスを起動し、Application Migration ServiceからTCOレポートを出力します。
- 不正解です。
- AWS Application Migration Service（旧称「CloudEndure Migration」）は、実際の移行作業を支援するサービスであり、TCOを見積もるためのツールではありません。これは、オンプレミスのサーバーをAWSに移行するために使用されるもので、移行後のインフラコストの見積もりを提供するものではありません。
D. AWS Cloud Economics Centerのウェブページにアクセスして、AWS Cloud Value Frameworkを評価します。Cloud Value FrameworkからAWSのコストと使用状況レポートを作成します。
- 不正解です。
- AWS Cloud Economics CenterやAWS Cloud Value Frameworkは、企業がクラウド移行の価値を評価するためのフレームワークを提供しますが、これはTCOの見積もりには特化していません。具体的なコスト見積もりを行うツール（Migration Evaluator）とは異なり、価値のフレームワークに重点を置いています。
結論
Aが正解です。AWS Migration Evaluatorを使用して、オンプレミスのインフラとAWS環境のコストを比較し、移行後のTCOを見積もることができます。このツールは、AWSへの移行を計画する際に非常に有用で、コストのシミュレーションと分析を提供します。
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
理論
AWSでのコスト最適化に関する重要な知識
AWSでのコスト最適化は、効率的なリソース使用と無駄な支出を避けることを目的としています。以下は、コスト最適化に関連する重要な要素です。
1. VPCエンドポイント
- ゲートウェイVPCエンドポイントを使用することで、VPC内のサービス（例: S3）間のトラフィックがAWSネットワーク内で直接処理され、データ転送コストが削減されます。
- NATゲートウェイを使う場合、インターネットを経由するためコストが発生しますが、VPCエンドポイントを使用すればその費用を削減できます。
2. Auto Scaling
- 予測スケーリングではトラフィックの増加を事前に予測してリソースを自動的にスケールしますが、スケジュールスケーリングに切り替えることで、特定の時間帯に合わせてリソースを調整できます。イベントやピークトラフィックが事前に分かっている場合、スケジュールスケーリングがコスト効率の面で優れています。
3. Spotインスタンスとオンデマンドインスタンス
- Spotインスタンスを使用することで、コストを大幅に削減できますが、インスタンスが突然終了するリスクもあります。予測可能なトラフィックの場合、Spotインスタンスを活用し、リスク管理を行うことができます。
- オンデマンドインスタンスは、柔軟性がありますが、長期的な使用では高コストになる可能性があるため、リソース需要に応じて最適な選択をすることが重要です。
4. S3 Transfer Acceleration
- S3 Transfer Accelerationは、データ転送の速度を改善するための機能ですが、コスト削減には直接的な影響はありません。インターネット越しの転送が多い場合に役立ちますが、VPC内でのトラフィックはVPCエンドポイントの方が効率的です。
結論
コスト最適化には、VPCエンドポイント、スケーリングポリシー、Spotインスタンスの活用が効果的です。また、コスト削減だけでなく、可用性や柔軟性も考慮し、リソースの最適化を行うことが重要です。
実践
略
一問道場
問題 #529
あるイベント会社がAWS上でチケット販売プラットフォームを運営しています。顧客はプラットフォーム上で自分のイベントを設定し、スケジュールします。これらのイベントは、プラットフォームへのトラフィックを大きく増加させます。会社は、各顧客のイベントの日時を把握しています。
会社は、プラットフォームをAmazon Elastic Container Service (Amazon ECS) クラスター上で運営しています。ECSクラスターは、Auto Scalingグループ内のAmazon EC2オンデマンドインスタンスで構成されています。Auto Scalingグループは予測スケーリングポリシーを使用しています。
ECSクラスターは、チケット資産をダウンロードするためにAmazon S3バケットに頻繁にリクエストを行います。ECSクラスターとS3バケットは同じAWSリージョンおよび同じAWSアカウント内にあります。ECSクラスターとS3バケット間のトラフィックは、NATゲートウェイを経由します。
会社は、プラットフォームの可用性を低下させることなく、コストの最適化を図りたいと考えています。
これらの要件を満たすために実行すべきステップの組み合わせはどれですか？（2つ選択してください。）
A. S3バケットのためにゲートウェイVPCエンドポイントを作成する。
B. 新しいECSキャパシティプロバイダーを追加し、Auto ScalingグループのSpotインスタンスを使用します。新しいキャパシティプロバイダー戦略に既存のキャパシティプロバイダー戦略と同じ重みを設定します。
C. スケーリングポリシーの適用期間に合わせて、適切なインスタンスタイプのオンデマンドキャパシティ予約を作成する。
D. S3バケットでS3 Transfer Accelerationを有効にする。
E. 予測スケーリングポリシーをスケジュールスケーリングポリシーに置き換える。
解説
A. S3バケットのためにゲートウェイVPCエンドポイントを作成する。
- 正解です。
- ゲートウェイVPCエンドポイントを作成すると、ECSクラスターとS3間のトラフィックがAWSの専用ネットワークを経由して流れることになります。これにより、NATゲートウェイを通る必要がなくなり、データ転送コストを削減できます。また、セキュリティ面でも、インターネットを経由せず、AWS内で直接データのやり取りができるため、より安全な通信が可能となります。
E. 予測スケーリングポリシーをスケジュールスケーリングポリシーに置き換える。
- 正解です。
- 予測スケーリングポリシーは、トラフィックの増加を事前に予測して自動的にスケーリングを行う方法ですが、スケジュールスケーリングポリシーを使用することで、イベントの日時が分かっているため、コストを最適化できます。スケジュールスケーリングを設定することで、特定の時間に合わせてリソースを自動的にスケールし、無駄なリソースの利用を減らせます。イベントが予測可能であるならば、スケジュールスケーリングの方がよりコスト効率的です。
他の選択肢について
- BのSpotインスタンスの利用はコスト削減には効果的ですが、既存の予測スケーリングポリシーのままでも十分に対応可能な場合があります。Spotインスタンスの使用には一部リスクがあるため、必ずしも最適な選択とは限りません。
- Cのオンデマンドキャパシティ予約は、予約を前払いすることで割引を受けられますが、柔軟性に欠け、予測スケーリングを上回るコスト最適化にはつながりません。
- DのS3 Transfer Accelerationは、データ転送を速くするための機能ですが、コスト最適化には直接的な関係がありません。特に、AWS内のトラフィックであれば、ゲートウェイVPCエンドポイントの方が効率的です。
結論
したがって、A（ゲートウェイVPCエンドポイントの作成）とE（予測スケーリングポリシーをスケジュールスケーリングポリシーに置き換える）が最適解となります。この組み合わせで、コスト最適化を達成し、可用性を維持しながらトラフィックを効率的に処理できます。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/180d7ae8-88e2-80be-9c67-eaae2e61331f
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
