type
status
date
slug
summary
tags
category
icon
password
221-AWS SAP AWS 「理論・実践・一問道場」EC2リソース最適化
理論
EC2インスタンスのリソース最適化
AWSでは、クラウドリソースを最適に管理するために、過少利用されているインスタンスを特定し、コスト削減やパフォーマンス向上を図ることが重要です。EC2インスタンスは、CPUやメモリの使用状況に応じて、必要なスペックにダウンサイジングすることができます。
AWS Cost Explorerによるリソース最適化
AWS Cost Explorerは、インスタンスの使用状況に基づいて、リソースの最適化やコスト削減の推奨を提供する強力なツールです。Cost Explorerのリソース最適化機能では、インスタンスのCPUやメモリの使用状況を監視し、過少利用のインスタンスに対してダウンサイジングを推奨します。このツールは、複数のAWSアカウントを持つ組織全体のインスタンスを一括で分析することができ、コスト削減の一助となります。
AWS Systems ManagerによるCloudWatchエージェントの管理
AWS Systems Managerは、複数のEC2インスタンスに対してCloudWatchエージェントを簡単にインストール、管理、構成するためのサービスです。CloudWatchエージェントは、EC2インスタンスのメトリクスを収集し、リソース利用状況を詳細に監視するために使用されます。これにより、インスタンスが過少利用されているかどうかを正確に把握することができます。
推奨されるアクション
- 過少利用のインスタンスの特定: AWS Cost Explorerのリソース最適化機能を使用して、過少利用のEC2インスタンスを特定します。
- ダウンサイジングの推奨を実施: EC2インスタンスのリソース最適化推奨を確認し、必要に応じてインスタンスをダウンサイジングします。
- 効率的な管理: AWS Systems ManagerでCloudWatchエージェントを導入し、複数のインスタンスのメトリクスを一元的に管理することで、効率的にリソースを最適化できます。
実践
略
一問道場
質問 #221
トピック 1
ある企業がAWS Organizationsを使用してAWSアカウントを管理しています。この企業は、CPUやメモリの使用状況が過少利用されているすべてのAmazon EC2インスタンスのリストを必要としています。また、これらの過少利用インスタンスをどのようにダウンサイジングするかについての推奨も必要です。
最も手間のかからない解決策はどれですか？
- A. すべてのEC2インスタンスにAWS MarketplaceからCPUおよびメモリ監視ツールをインストールし、結果をAmazon S3に保存します。その後、Pythonスクリプトを実行して過少利用インスタンスを特定します。ダウンサイジングの推奨事項については、EC2インスタンスの価格情報を参照します。
- B. すべてのEC2インスタンスにAWS Systems Managerを使用してAmazon CloudWatchエージェントをインストールします。AWS Cost Explorerからリソース最適化の推奨を取得し、組織の管理アカウントで過少利用インスタンスのダウンサイジングに関する推奨事項を使用します。
- C. すべてのEC2インスタンスにAWS Systems Managerを使用してAmazon CloudWatchエージェントをインストールします。AWS Cost Explorerからリソース最適化の推奨を取得し、組織内の各アカウントで過少利用インスタンスのダウンサイジングに関する推奨事項を使用します。
- D. すべてのEC2インスタンスにAWS Systems Managerを使用してAmazon CloudWatchエージェントをインストールします。AWS Lambda関数を作成して、すべてのEC2インスタンスからCPUおよびメモリの使用状況を抽出し、結果をAmazon S3にファイルとして保存します。その後、Amazon Athenaを使用して過少利用インスタンスを特定し、ダウンサイジングの推奨事項についてはEC2インスタンスの価格情報を参照します。
解説
この問題では、過少利用のEC2インスタンスを特定し、それらをダウンサイジングするための推奨を取得する方法を求められています。
最も効率的かつ手間のかからない方法を選ぶ必要があります。以下に各選択肢について解説します。
A. AWS MarketplaceのCPUおよびメモリ監視ツールをインストールし、S3に結果を保存。Pythonスクリプトで過少利用インスタンスを特定。EC2インスタンスの価格情報を参照する。
- 問題点: この方法では手動のスクリプト作成やツールのインストール、データの保存が必要で、手間がかかる上に、AWSのネイティブな推奨機能を活用できていません。最も効率的ではありません。
B. AWS Systems Managerを使用してCloudWatchエージェントをインストールし、Cost Explorerからリソース最適化の推奨を取得。
- メリット: AWS Cost Explorerは、過少利用インスタンスのリソース最適化の推奨を自動で提供します。この方法は、推奨を迅速に取得できるため、効率的です。管理アカウントを使って、組織全体のアカウントから推奨を一括で取得できる点も利点です。
C. AWS Systems Managerを使用してCloudWatchエージェントをインストールし、各アカウントでCost Explorerから推奨を取得。
- 問題点: Bの方法と非常に似ていますが、各アカウントから推奨を取得する必要があり、管理が煩雑になります。特に多くのアカウントがある場合、推奨の取得が面倒になる可能性があります。
D. AWS Systems Managerを使用してCloudWatchエージェントをインストールし、LambdaでCPUおよびメモリ使用状況を抽出し、S3に保存。Athenaで過少利用インスタンスを特定。
- 問題点: この方法では、Lambda関数やAthenaの設定など、かなりの手間がかかり、AWSのネイティブなリソース最適化機能を使用していないため、最も効率的ではない方法です。
最適な選択肢:
Bが最も効率的です。AWS Systems ManagerでCloudWatchエージェントをインストールした後、AWS Cost Explorerを使用してリソースの最適化推奨を自動で取得できます。この方法は最小の手間で済み、組織全体のインスタンスの最適化が可能です。
222-AWS SAP AWS 「理論・実践・一問道場」トラフィックをEC2インスタンス経由
理論
AWS VPCでトラフィックをEC2インスタンス経由にする理由と課題
背景：問題の設定
ある企業がVPC内外のすべてのネットワークトラフィックを3台のEC2インスタンス経由で処理し、分析ソフトウェアを実行しています。このような構成を取る理由や課題について、以下で解説します。
1. すべてのトラフィックをEC2インスタンス経由にする目的
- セキュリティの強化
- トラフィックを一元的に検査し、外部からの不正アクセスや内部の異常な通信を検知・遮断する。
- IDS/IPS（侵入検知/防止システム）やファイアウォールを導入することで、セキュリティリスクを軽減。
- トラフィックの可視化と管理
- トラフィックの量やパターンを監視し、ネットワークのボトルネックや異常を特定。
- 運用データを基に、ネットワーク設計や負荷分散を最適化。
- 拡張性と柔軟性
- トラフィック分析やセキュリティルールをアップデートしやすく、新たな要件にも柔軟に対応可能。
2. 設定方法のポイント
- ルーティング設定
VPCのルートテーブルで、VPC内部や外部インターネットへのすべてのトラフィックを、3台のEC2インスタンス（またはそのENI: Elastic Network Interface）に向ける。
- NATゲートウェイまたはゲートウェイ型ロードバランサ（GWLB）の活用
VPC内外の通信を最適に制御するため、NATやGWLBを使ってトラフィックをEC2インスタンスに転送。
- Auto Scalingとルートの更新
- Auto Scalingでインスタンスを置き換える場合、新しいインスタンスのENIにルートを更新する必要がある。
- このために、CloudWatchアラームやLambda関数を活用し、自動的にルート更新を行う仕組みを構築。
3. 課題と解決策
- 課題：インスタンス置き換え時のルート更新
Auto Scalingによってインスタンスが置き換えられても、ルートが古いインスタンスを指したままになると、トラフィックが正しく処理されなくなる。
- 解決策
- CloudWatchとLambdaの連携：インスタンスの異常を監視し、置き換え後にルートテーブルを新しいインスタンスに自動更新。
- ゲートウェイ型ロードバランサの導入：GWLBを活用し、インスタンスの追加や置き換えを抽象化する。
4. まとめ
このような構成は、セキュリティと可視化を重視したネットワーク設計において非常に重要です。ただし、インスタンスの置き換えに伴うルートの管理や設定の自動化が不可欠です。AWSが提供するツール（CloudWatch、Lambda、GWLBなど）を活用することで、より堅牢で効率的なシステムを構築できます。
実践
略
一問道場
問題 #222
トピック 1
ある企業は、VPCを出入りするトラフィックを検査するカスタムネットワーク分析ソフトウェアパッケージを実行したいと考えています。この企業は、AWS CloudFormationを使用して、Auto Scalingグループ内の3つのAmazon EC2インスタンスにこのソリューションを展開しました。すべてのネットワークルーティングは、トラフィックをEC2インスタンスに向けるように設定されています。
分析ソフトウェアが停止すると、Auto Scalingグループはインスタンスを置き換えますが、インスタンスの置き換えが行われてもネットワークルートは更新されません。
この問題を解決するためのステップの組み合わせはどれですか？（3つ選んでください）
- A. EC2ステータスチェックメトリクスに基づくアラームを作成し、Auto Scalingグループが障害のあるインスタンスを置き換えるようにする。
- B. CloudFormationテンプレートを更新して、EC2インスタンスにAmazon CloudWatchエージェントをインストールする。CloudWatchエージェントを構成して、アプリケーションのプロセスメトリクスを送信する。
- C. CloudFormationテンプレートを更新して、EC2インスタンスにAWS Systems Managerエージェントをインストールする。Systems Managerエージェントを構成して、アプリケーションのプロセスメトリクスを送信する。
- D. カスタムメトリクスの障害シナリオに対するアラームをAmazon CloudWatchで作成する。アラームがAmazon Simple Notification Service (Amazon SNS)トピックにメッセージを送信するように設定する。
- E. Amazon SNSメッセージに応答するAWS Lambda関数を作成し、そのインスタンスをサービスから外す。ネットワークルートを更新して、置き換えられたインスタンスに指すようにする。
- F. CloudFormationテンプレートに条件を記述して、インスタンスが置き換えられるとネットワークルートを更新する。
解説
選択肢 B, D, E も問題の解決に有効です。以下にそれぞれの選択肢について詳しく説明します。
- B. CloudFormationテンプレートを更新して、EC2インスタンスにAmazon CloudWatchエージェントをインストールする。CloudWatchエージェントを構成して、アプリケーションのプロセスメトリクスを送信する。
→ CloudWatchエージェントを使って、アプリケーションのメトリクスを監視することができます。これにより、インスタンスの状態やアプリケーションのパフォーマンスを監視し、障害を早期に発見することが可能になります。
- D. カスタムメトリクスの障害シナリオに対するアラームをAmazon CloudWatchで作成する。アラームがAmazon Simple Notification Service (Amazon SNS)トピックにメッセージを送信するように設定する。
→ CloudWatchのカスタムメトリクスを使って、インスタンスの障害を検出し、SNSメッセージを送信することで、インスタンスの障害が発生したことを通知します。この通知を利用して適切な対応が可能になります。
- E. Amazon SNSメッセージに応答するAWS Lambda関数を作成し、そのインスタンスをサービスから外す。ネットワークルートを更新して、置き換えられたインスタンスに指すようにする。
→ SNSメッセージを受け取るLambda関数がネットワークルートを更新し、新しいインスタンスに向けてトラフィックをルーティングします。これにより、インスタンスが置き換えられた後も、ルーティングが自動的に更新されることになります。
これらのステップを組み合わせることで、インスタンスの障害時にトラフィックが新しいインスタンスに向けて自動的に再ルーティングされ、ネットワークの設定も適切に更新されます。
223-AWS SAP AWS 「理論・実践・一問道場」Service Auto Scaling
理論
ECSでのブルー/グリーンデプロイメントとオートスケーリングに関する基本知識
Amazon Elastic Container Service（ECS）を使用してアプリケーションを運用する際、以下のポイントが重要です。この知識は、アプリケーションの信頼性、スケーラビリティ、更新プロセスの効率を向上させるための基本となります。
1. ブルー/グリーンデプロイメント
ブルー/グリーンデプロイメントは、新しいバージョン（グリーン）を既存のバージョン（ブルー）と並行してデプロイする方法です。以下のメリットがあります：
- ダウンタイムの最小化：トラフィックを切り替えるだけで新しいバージョンを即座に反映可能。
- 安全なロールバック：問題が発生した場合、簡単に元のバージョン（ブルー）に戻せます。
ECSでは、Application Load Balancer（ALB） や Network Load Balancer（NLB） を使ってトラフィックを新旧のサービス間で切り替えます。ALBは、アプリケーション層のルーティングやHTTPS対応に適しているため、マイクロサービスアーキテクチャでは一般的に推奨されます。
2. ロードバランサーの選択
- Application Load Balancer（ALB）：HTTP/HTTPSを利用するアプリケーションに最適。パスベースやホストベースのルーティングが可能。
- Network Load Balancer（NLB）：低レイテンシが求められるTCP/UDPトラフィック向け。
問題文では「HTTPSプロトコル」を使用するため、ALB の採用が適切です。
3. オートスケーリング
アプリケーションの需要に応じて、ECSタスクを自動的に増減させる仕組みです。ECSでは以下の2種類のスケーリングがあります：
- Cluster Auto Scaling：ECSクラスター内のEC2インスタンスの台数を調整する。
- Service Auto Scaling：個々のECSサービス（タスク）の数を調整する。
AWS Fargate では、EC2インスタンス管理が不要なため、Service Auto Scaling が適用されます。CloudWatchアラームをトリガーとしてスケールアップ/スケールダウンを行うことで、効率的なリソース利用が可能です。
4. 具体的な構成例
- ロードバランサー：ALBを使用し、各サービスへのトラフィックをルーティング。
- デプロイ方法：ECSサービスをブルー/グリーンデプロイメントタイプに設定。
- スケーリング：Service Auto Scalingを構成し、CloudWatchアラームをトリガーとしてタスク数を自動調整。
これらの設定を組み合わせることで、大規模なユーザー需要に対応しながら安全にアプリケーションを更新することが可能です。
実践
略
一問道場
質問 #223
トピック 1
ある企業が、マイクロサービスをベースとした新しいオンデマンド動画アプリケーションを開発しています。このアプリケーションは、ローンチ時に500万人のユーザーが利用し、6か月後には3000万人のユーザーが利用する予定です。
企業は、このアプリケーションを AWS Fargate 上で Amazon Elastic Container Service (Amazon ECS) を使用してデプロイしました。アプリケーションは HTTPS プロトコル を使用する ECS サービスによって開発されました。
ソリューションアーキテクトは、このアプリケーションに ブルー/グリーンデプロイメント を使用して更新を実装する必要があります。このソリューションでは、各 ECS サービスへのトラフィックをロードバランサー経由で分配する必要があります。また、アプリケーションは Amazon CloudWatch アラーム に応じてタスク数を自動的に調整する必要があります。
どのソリューションがこれらの要件を満たしますか？
選択肢
A. ECS サービスをブルー/グリーンデプロイメントタイプと Network Load Balancer を使用するように設定します。需要に応じたタスク数を満たすため、サービスごとのタスク数のクォータ増加をリクエストします。
B. ECS サービスをブルー/グリーンデプロイメントタイプと Network Load Balancer を使用するように設定します。各 ECS サービスに Cluster Autoscaler を使用して Auto Scaling グループを実装します。
C. ECS サービスをブルー/グリーンデプロイメントタイプと Application Load Balancer を使用するように設定します。各 ECS サービスに Cluster Autoscaler を使用して Auto Scaling グループを実装します。
D. ECS サービスをブルー/グリーンデプロイメントタイプと Application Load Balancer を使用するように設定します。各 ECS サービスに Service Auto Scaling を実装します。
解説
問題の解説
この問題では、以下の条件を満たすソリューションを選ぶ必要があります：
- ブルー/グリーンデプロイメント：新しいバージョンへの安全な切り替えが可能で、ロールバックも容易。
- トラフィックの分配：ECSサービスへのトラフィックをロードバランサーを通じて管理。
- オートスケーリング：Amazon CloudWatchアラームに基づいてタスク数を自動的に調整。
各選択肢の検討
A.
- Network Load Balancer (NLB) を使用してブルー/グリーンデプロイメントを実現。
- タスク数のクォータ増加をリクエストすると記載されていますが、具体的なオートスケーリング設定については言及がありません。
- NLBはHTTPSプロトコルのルーティングには適していないため、選択肢として不適切です。
B.
- NLB と Cluster Auto Scaling を使用。
- Cluster Auto Scaling は ECS クラスター内の EC2 インスタンスの台数を管理するもので、AWS Fargate の場合には適用されません。
- AWS Fargate ではクラスター管理を行わないため、この選択肢も不適切です。
C.
- Application Load Balancer (ALB) と Cluster Auto Scaling を使用。
- ALB は HTTPS プロトコルをサポートしており適切ですが、Cluster Auto Scaling は AWS Fargate に適用されません。
- Service Auto Scaling を指定していないため、この選択肢も不適切です。
D.
- ALB と Service Auto Scaling を使用。
- ALB は HTTPS プロトコルに対応し、Service Auto Scaling は Fargate 環境に適用可能。
- ブルー/グリーンデプロイメントの要件を満たし、CloudWatch アラームをトリガーにしたスケーリングにも対応できるため、この選択肢が最適です。
正解：D
補足解説
- ロードバランサーの選択：HTTPSプロトコルを使用しているため、アプリケーション層でのルーティングが可能な ALB を選ぶべきです。
- スケーリングの選択：AWS Fargate では EC2 インスタンスの管理は不要なため、タスクレベルでスケーリングを行う Service Auto Scaling が適切です。
- ブルー/グリーンデプロイメント：ECSサービスがサポートしているブルー/グリーンデプロイメントタイプを使用することで、安全にアプリケーションの更新を行えます。
この解答により、アプリケーションのパフォーマンスと運用効率を最大限に高めることができます。
224-AWS SAP AWS 「理論・実践・一問道場」Step Functions
理論
1. Step Functionsの本質
- 複雑なワークフローを管理するために使用されます。複数のAWSサービスや処理を順番に実行したり、条件に応じて分岐させることができます。
- 状態管理ができ、エラーハンドリングやリトライ機能も簡単に組み込めます。
- 状態遷移の追跡が可能なので、処理の進行状況を可視化できます。
2. Lambdaの本質
- 単一のイベント駆動型処理を実行するために使用されます。短時間で終了するタスクを実行するのに適しています。
- 簡単な処理やイベントに応じた動作を行うのには最適ですが、複雑なワークフローの管理や状態遷移の追跡には不向きです。
3. 適切なツールの選択
- Step Functionsは、複数の処理を順番に実行する必要がある場合、または状態遷移やエラーハンドリングが重要な場合に最適です。
- Lambdaは、簡単な処理や短時間で完了するタスクをトリガーに基づいて実行するのに向いています。
4. 重要な選択基準
- 複雑なワークフローや状態管理が必要ならStep Functions。
- シンプルな処理や迅速なイベント駆動型アクションにはLambda。
例えば、ECRのスキャン結果に基づくタグ削除と通知送信の2つの処理を順番に実行し、エラーハンドリングを組み込む必要があるため、Step Functionsが適切です。
実践
略
一問道場
質問 #224
トピック 1
ある企業が AWS クラウドでコンテナ化されたアプリケーションを運用しています。このアプリケーションは Amazon Elastic Container Service (Amazon ECS) を使用して、Auto Scaling グループ内の Amazon EC2 インスタンスで実行されています。また、企業は Amazon Elastic Container Registry (Amazon ECR) を使用してコンテナイメージを保存しています。新しいイメージバージョンがアップロードされると、そのイメージに一意のタグが付与されます。
企業は、新しいイメージバージョンの脆弱性とセキュリティの問題を検査するソリューションを必要としています。このソリューションは、Critical または High の重大な問題が見つかったイメージタグを自動的に削除し、その削除が発生した際に開発チームに通知する必要があります。
要件を満たすソリューションはどれですか？
A. リポジトリで「プッシュ時にスキャン（scan on push）」を設定します。スキャンが完了したら、Critical または High の検出結果があるイメージについて、Amazon EventBridge を使って AWS Step Functions のステートマシンを起動します。このステートマシンで該当するイメージタグを削除し、Amazon Simple Notification Service (Amazon SNS) を通じて開発チームに通知します。
B. リポジトリで「プッシュ時にスキャン（scan on push）」を設定し、スキャン結果を Amazon Simple Queue Service (Amazon SQS) に送信します。新しいメッセージが SQS キューに追加されると、AWS Lambda 関数を起動します。この Lambda 関数で、Critical または High の問題が検出されたイメージタグを削除し、Amazon Simple Email Service (Amazon SES) を使って開発チームに通知します。
C. 毎時手動でイメージスキャンを開始するように AWS Lambda 関数をスケジュールします。スキャンが完了したら、Amazon EventBridge を使って別の Lambda 関数を起動します。2 番目の Lambda 関数で、Critical または High の問題が検出されたイメージタグを削除し、Amazon Simple Notification Service (Amazon SNS) を使って開発チームに通知します。
D. リポジトリで「定期的なスキャン（periodic image scan）」を設定し、スキャン結果を Amazon Simple Queue Service (Amazon SQS) に送信します。SQS キューに新しいメッセージが追加されると、AWS Step Functions のステートマシンを起動します。このステートマシンで Critical または High の問題が検出されたイメージタグを削除し、Amazon Simple Email Service (Amazon SES) を使って開発チームに通知します。
解説
A. リポジトリで「プッシュ時にスキャン（scan on push）」を設定し、EventBridge を使って AWS Step Functions を呼び出し、タグ削除と通知
- scan on pushは、コンテナイメージがECRにプッシュされるたびに自動的にスキャンを実行するオプションです。
- EventBridgeを使って、スキャン結果が完了した後に自動的に AWS Step Functions ステートマシンを呼び出し、Critical または High の問題が見つかった場合にタグを削除します。
- 最後に、SNSで開発チームに通知します。
これは、最も適切な選択肢です。なぜなら、自動化されたワークフローで脆弱性スキャン、タグ削除、通知を実行するために、AWSのサービス（EventBridge, Step Functions, SNS）を組み合わせており、要件に完全に一致します。
B. プッシュ時にスキャンを設定し、SQS にスキャン結果を送信し、Lambda でタグ削除と通知
- SQSを利用して、スキャン結果をキューに送信し、そのメッセージをトリガーにLambda関数を実行してタグを削除します。
- SESを使って通知を送信します。
この方法も有効ですが、Lambda と SQSを使った実装は少し複雑になります。SNSではなくSESで通知を送る点が若干の違いです。
C. 定期的なスキャンと EventBridge と Lambda 関数によるタグ削除と通知
- 定期的なスキャンをスケジュールして、定期的にイメージをチェックします。
- スキャンが完了すると、EventBridgeで別の Lambda 関数をトリガーしてタグ削除し、通知を行います。
この方法は **「手動でのスキャン開始」**を必要とし、スキャンの頻度に応じてタグ削除が行われるため、より手動的で効率が悪くなります。さらに、スキャンのタイミングが必ずしも新しいイメージがプッシュされたタイミングと一致しない可能性があるため、要件にぴったり合致しない可能性があります。
D. 定期的なスキャン、SQS、Step Functions によるタグ削除と通知
- 定期的なスキャンを設定して、結果を SQS に送信し、そのメッセージをトリガーに Step Functions を使ってタグ削除し、SES で通知します。
こちらも手動でのスキャン開始と同様に効率が悪く、スキャン結果が即座に反映されないため、Aよりも適していません。
結論：
最も効率的で、要件を満たす選択肢は A です。「scan on push」 を使ってスキャンを自動的に実行し、EventBridge でプロセスを自動化することが、脆弱性のあるイメージを見逃すことなく迅速に対応するための最適なアプローチです。
225-AWS SAP AWS 「理論・実践・一問道場」Compute Savings Plan
理論
1. 使用量の予測性と柔軟性
- リザーブドインスタンス (RI): 予測可能な需要に基づいて、特定のインスタンスサイズとタイプに対して割引が適用されます。長期間にわたる一定の需要が見込まれる場合に最適です。
- セービングプラン (Savings Plan): 柔軟性が高く、使用量が変動する場合でも最適化可能です。EC2だけでなく、FargateやLambdaなど、複数のサービスに適用できます。
2. Compute Savings Planの重要性
- Compute Savings Planは、より広範なサービスに適用できるため、柔軟にコストを削減でき、需要の変動に強いです。
- EC2インスタンスの需要が変動する組織には、特定のインスタンスに縛られないCompute Savings Planが最適です。
3. 最適化のアプローチ
- 使用パターンに応じて、固定のリソースに対する割引（RI）か、複数のリソースに対する柔軟な割引（Savings Plan）を選択します。
- Compute Savings Planは、使用量が変動する場合や複数のサービスを使う場合に最適な選択です。
具体的には、AWSのセービングプランには2種類あります：
- Compute Savings Plan:
- これは、EC2インスタンス、AWS Fargate、AWS Lambdaに適用できる柔軟な割引プランです。
- どのインスタンスタイプやリージョンを使うかに関係なく、これらのリソースを使用する場合にコストを削減できます。
- 使用量が予測しにくい、もしくは変動が大きい環境に最適です。
- EC2 Instance Savings Plan:
- これは、特定のEC2インスタンスタイプ（インスタンスサイズ、OS、リージョン）に対して適用される割引プランです。
- より予測可能な使用量に基づいて、特定のインスタンスに対してコストを削減したい場合に最適です。
Compute Savings Planは、柔軟性があり、変動するワークロードや複数のAWSサービスを利用する場合に特に効果的です。
実践
略
一問道場
質問 #225
トピック 1
ある企業は、AWSで多くのワークロードを実行しており、AWS Organizationsを使用してアカウントを管理しています。ワークロードは、Amazon EC2、AWS Fargate、およびAWS Lambdaでホストされています。いくつかのワークロードは需要が予測できないものもあり、アカウントはある月に高い使用量を記録し、他の月には低い使用量を記録します。
企業は、今後3年間で計算コストを最適化したいと考えています。ソリューションアーキテクトは、各アカウントの6ヶ月間の平均使用量を取得し、使用量を計算しました。
この企業全体のコンピューティング使用量に対して、最もコスト削減ができる解決策はどれですか？
A. 組織全体で、最も一般的なEC2インスタンスのサイズと数に合わせて、リザーブドインスタンスを購入する。
B. 管理アカウントから、管理アカウントレベルでの推奨に基づいて、組織全体のコンピュートセービングプランを購入する。
C. 過去6ヶ月間のデータに基づいて、EC2の使用量が高かった各メンバーアカウントごとにリザーブドインスタンスを購入する。
D. 過去6ヶ月間のEC2使用データに基づいて、管理アカウントから各メンバーアカウント向けにEC2インスタンスセービングプランを購入する。
解説
最適なコスト削減手段の選定
企業がAWSの計算リソースのコストを最適化するためには、需要の予測が難しい場合や使用量にムラがある場合に柔軟性のある方法が最適です。
各選択肢の解説
- A: 組織全体でリザーブドインスタンスを購入
- リザーブドインスタンスは、特定のインスタンスタイプに対して長期間の割引を提供します。ただし、需要が予測できない場合、リザーブドインスタンスは柔軟性が低く、余分なリソースが発生する可能性があります。
- 不適切です。
- B: コンピュートセービングプランを購入
- コンピュートセービングプランは、EC2、AWS Fargate、AWS Lambdaなど、複数のAWSサービスに適用され、柔軟性を持ちつつコスト削減が可能です。使用量の変動がある場合に最も効果的です。
- 最適な選択肢です。
- C: 各メンバーアカウントでリザーブドインスタンスを購入
- 各アカウントごとにリザーブドインスタンスを購入するのは、予測不能な需要がある場合に柔軟性が欠けるため、コスト削減に最適ではありません。
- 不適切です。
- D: EC2インスタンスセービングプランを購入
- EC2インスタンスセービングプランはEC2専用で、使用量に応じた割引を提供しますが、コンピュートセービングプランの方が、複数のサービスに対応し柔軟性が高いため、こちらの方が有利です。
- 不適切です。
結論
最も柔軟でコスト削減に適した方法は、コンピュートセービングプランを購入することで、これにより予測不可能な需要に対応しつつ、複数のサービスにわたってコストを最適化できます。
226-AWS SAP AWS 「理論・実践・一問道場」AWS Budgets
理論
以下は、AWS Cost and Usage Report (CUR)とAWS Budgetsの簡潔な比較です：
特徴 | AWS Cost and Usage Report (CUR) | AWS Budgets |
目的 | 詳細なコストと使用量のデータ収集と分析 | コストや使用量の予算管理とアラート通知 |
データの詳細度 | 非常に詳細（サービスごとのコスト・使用量データ） | 予算に基づいた簡略的な監視 |
通知機能 | 他ツールと連携して通知可能 | 設定した予算の超過時に直接通知 |
用途 | コスト分析、リソース最適化 | 予算管理、コスト警告 |
保存先 | Amazon S3にCSV/Parquet形式で保存 | AWS Budgetsダッシュボードや通知 |
- CURは詳細なコスト分析に、AWS Budgetsは予算管理とアラート通知に適しています。
実践
略
一問道場
質問 #226
トピック
ある企業には数百のAWSアカウントがあります。企業は、AWS Organizationsで全てのアカウントを管理しています。すべての機能が有効になっています。
財務チームは、AWSのコストに対して日々の予算を割り当てています。財務チームは、組織のAWSコストが割り当てられた予算の80％を超えた場合、メール通知を受け取る必要があります。
ソリューションアーキテクトは、コストを追跡し、通知を配信するソリューションを実装する必要があります。
どのソリューションがこれらの要件を満たしますか？
A. 組織の管理アカウントでAWS Budgetsを使用して、日次の予算を作成します。アラートのしきい値を設定し、その値を80％に設定します。Amazon Simple Notification Service (Amazon SNS)を使用して財務チームに通知します。
B. 組織の管理アカウントで、AWS Trusted Advisorの組織ビュー機能を設定します。コスト最適化のための組織ビューのレポートを作成します。しきい値を80％に設定します。通知の設定を行い、財務チームのメールアドレスを追加します。
C. 組織をAWS Control Towerに登録します。オプションのコスト管理ガードレールを有効にします。ガードレールのパラメータを80％に設定します。通知の設定を行い、Amazon Simple Notification Service (Amazon SNS)を使用して財務チームに通知します。
D. メンバーアカウントを設定し、AWS Cost and Usage Reportを組織の管理アカウントのAmazon S3バケットに毎日保存します。Amazon EventBridgeを使用して、毎日Amazon Athenaクエリをスケジュールして組織のコストを計算します。Athenaを設定して、コストが80％を超える場合にAmazon CloudWatchアラートを送信します。Amazon Simple Notification Service (Amazon SNS)を使用して財務チームに通知します。
解説
この問題は、AWSでのコスト管理に関連しています。具体的には、複数のAWSアカウントを管理している組織内で、設定した予算の80%を超えた場合に通知を受け取る方法を問う内容です。
解説として、次のように進めます：
正解はAです。
選択肢Aでは、次のステップを踏んでいます：
- AWS Budgetsを使用して予算を作成します。これは、AWSコストがどのくらいかを追跡するツールで、設定した金額や期間に基づいてアラートを発行する機能があります。
- 予算期間を「日次」に設定し、アラートしきい値を**80%**に設定します。これにより、コストが80%を超えるとアラートが発行されます。
- Amazon SNS（Simple Notification Service）を使用して、通知をメールで送る設定を行います。
他の選択肢について
- 選択肢B（AWS Trusted Advisor）：
- AWS Trusted Advisorは、コスト最適化、セキュリティ、フォルトトレランスなどをチェックしますが、予算管理には使用しません。コストに関するアラート機能も制限があります。
- 選択肢C（AWS Control Tower）：
- AWS Control Towerは、複数アカウントの管理を簡素化するためのサービスですが、コスト予算のアラート機能を提供するものではありません。したがって、予算通知には不適切です。
- 選択肢D（Cost and Usage Report + Athena + EventBridge）：
- *AWS Cost and Usage Report (CUR)**は、詳細な使用量やコストデータを提供しますが、これを使ってアラートを直接発行するのは手間がかかります。AthenaとEventBridgeを使った方法は、かなり複雑でコストや使用量の管理が難しくなります。
なぜAが最適なのか？
AWS Budgetsは、コストや使用量に基づいて予算を設定し、指定したしきい値を超えた際に通知を送る機能を持っています。この問題で求められている要件（予算の80%超過で通知）は、まさにAWS Budgetsを使用することで簡単に実現できます。
227-AWS SAP AWS 「理論・実践・一問道場」S3転送アクセラレーション
理論
1. S3 Transfer Acceleration
- 概要: S3転送アクセラレーションは、インターネット経由でS3バケットにデータを効率的にアップロードするサービスです。ユーザーの近くにあるCloudFrontエッジロケーションを使用して、データ転送を最適化します。
- 目的: 地理的に離れた場所にいるユーザー（例えば、ヨーロッパのユーザー）が、米国東部（us-east-1）リージョンにあるS3バケットにデータをアップロードする際の遅延を軽減します。
- 利点: 転送速度が向上し、アップロード時の遅延が減少します。
2. CloudFrontとその役割
- 概要: CloudFrontは、AWSのコンテンツ配信ネットワーク（CDN）で、静的コンテンツ（画像、ビデオなど）をエッジロケーションにキャッシュして配信します。これにより、ユーザーの地理的な位置に関係なく、コンテンツが高速に提供されます。
- 適用範囲: CloudFrontは主にコンテンツの「ダウンロード」を最適化するために使用され、データの「アップロード」に対する効果はありません。
3. マルチパートアップロードとその用途
- 概要: S3のマルチパートアップロードは、大きなファイルを分割して並行してアップロードする技術です。これにより、大きなデータのアップロードを効率化できます。
- 適用範囲: マルチパートアップロードは、特にファイルサイズが大きい場合に効果がありますが、地理的な遅延やアップロードの速度には直接的な効果はありません。
4. EC2オートスケーリングとスケーリングの重要性
- 概要: EC2オートスケーリングは、アプリケーションの負荷に応じてEC2インスタンスの数を増減させる機能です。これにより、処理能力が効率的に確保されます。
- 適用範囲: EC2オートスケーリングは、サーバーのリソース管理や負荷分散には有効ですが、データ転送やアップロードの速度には影響しません。
結論
- S3 Transfer Accelerationは、地理的な遅延を解消するために最も効果的な方法です。特に、遠隔地からのアップロードに関しては、ユーザーの近くのエッジロケーションを利用して転送速度を最適化します。
- CloudFrontやマルチパートアップロードはアップロードの最適化には直接関係しませんが、ダウンロードの速度向上や大きなファイルの取り扱いには有用です。
このように、遅延問題を解決するためには、転送速度を最適化するための適切なAWSサービスの利用が重要です。
実践
略
一問道場
質問 #227
トピック 1
ある会社は、北アメリカとヨーロッパのユーザー向けにアートワークのオークションサービスを提供しています。この会社は、us-east-1リージョンのAmazon EC2インスタンスでアプリケーションをホストしています。アーティストは、自分の携帯電話から高解像度の大きな画像ファイルをアップロードして、us-east-1リージョンに作成した中央のAmazon S3バケットに保存します。ヨーロッパのユーザーから、画像のアップロードが遅いという報告があります。
ソリューションアーキテクトは、画像アップロードプロセスのパフォーマンスを向上させるにはどうすればよいでしょうか？
A. アプリケーションをS3マルチパートアップロードを使用するように再展開する。
B. Amazon CloudFrontディストリビューションを作成し、アプリケーションをカスタムオリジンとして指す。
C. バケットをS3転送アクセラレーションを使用するように設定する。
D. EC2インスタンスのオートスケーリンググループを作成し、スケーリングポリシーを作成する。
解説
この問題は、ヨーロッパのユーザーが画像アップロード時に遅延を感じているという状況です。遅延の原因は、アメリカ東部（us-east-1）リージョンにあるS3バケットに直接アップロードするため、ヨーロッパからのデータ転送距離が長くなることです。これにより、アップロード速度が遅くなります。
各選択肢を見ていきます：
A. アプリケーションをS3マルチパートアップロードを使用するように再展開する。
- 誤り：S3のマルチパートアップロードは、ファイルを分割して並行アップロードするため、大きなファイルのアップロードを効率化するためのものですが、ヨーロッパのユーザーの遅延を改善する方法ではありません。遅延の問題は、地理的な距離によるものであり、マルチパートアップロードでは直接解決しません。
B. Amazon CloudFrontディストリビューションを作成し、アプリケーションをカスタムオリジンとして指す。
- 誤り：CloudFrontはコンテンツ配信を最適化するためのサービスで、主に静的コンテンツ（画像、CSS、JSファイルなど）のキャッシュを地理的に分散したエッジロケーションに配置することでパフォーマンスを向上させます。画像のアップロードには効果的ではないため、この選択肢は不適切です。
C. バケットをS3転送アクセラレーションを使用するように設定する。
- 正解：S3転送アクセラレーションは、インターネット経由でS3バケットにデータを高速でアップロードするためのサービスです。このサービスは、アップロードするデータをAmazon CloudFrontのエッジロケーションを経由して最適な経路で転送するため、ユーザーが地理的に離れている場合でもアップロード速度を向上させます。これにより、ヨーロッパのユーザーのアップロードパフォーマンスが改善されます。
D. EC2インスタンスのオートスケーリンググループを作成し、スケーリングポリシーを作成する。
- 誤り：オートスケーリングは、負荷に応じてEC2インスタンスの数を調整するためのものですが、アップロードの遅延とは無関係です。画像のアップロード速度はネットワーク帯域や転送プロトコルに関連しており、EC2インスタンスのスケーリングでは改善できません。
結論
S3転送アクセラレーション（選択肢C）は、遅延を解消するために最も適切な選択肢です。これにより、地理的に離れた場所からでも効率的にデータをアップロードでき、ヨーロッパのユーザーが直面しているパフォーマンス問題を解決できます。
228-AWS SAP AWS 「理論・実践・一問道場」EKS マネージドノードグループ
理論
こちらがECS FargateとEKSマネージドノードグループの簡潔な比較表です。
特徴 | ECS Fargate | EKS マネージドノードグループ |
管理の簡便さ | フルマネージド、インフラ管理不要 | ノード管理は必要だが、マネージドサービスで簡素化 |
スケーラビリティ | 自動スケーリング、リソースに応じて動的に拡張 | Kubernetesでスケーリング管理、自動化可能 |
インフラ管理 | 完全にAWSが管理 | ノードの管理が必要だが、EKSで簡略化 |
コスト管理 | 実行したリソース分のみ課金（サーバーレス） | EC2インスタンス料金、オーバーヘッドあり |
適用例 | シンプルなアプリケーション、サーバーレス | 複雑なアプリケーション、大規模なクラスター |
柔軟性 | サーバー管理が不要 | 高い柔軟性、カスタマイズ可能 |
対応するコンテナオーケストレーション | ECS（AWS独自） | Kubernetes（EKSによるマネージド） |
ECS Fargateはサーバーレスで、インフラの管理不要で簡単にスケーリングできる一方、EKSマネージドノードグループはKubernetesの柔軟性を活かして、より大規模かつ複雑なアプリケーションに対応できます。
マルチティアWebアプリケーションに関して、ECS FargateとEKSマネージドノードグループのどちらが適切かは、アプリケーションの規模、複雑さ、スケーラビリティ要求などに依存しますが、以下の要素を基に選択できます。
ECS Fargateが適している場合:
- シンプルでサーバーレスな環境が必要な場合:
- インフラ管理を最小限に抑え、開発に集中したい場合。
- アプリケーションが比較的単純で、コンテナオーケストレーションを管理する必要がない場合。
- 管理の負担を減らしたい場合:
- ECS Fargateは、コンテナインフラの管理をAWSが代行するため、オペレーショナルオーバーヘッドを減らしたい場合に最適です。
- 動的スケーリングが必要な場合:
- Fargateはリソースを自動で管理し、必要に応じてスケールするため、動的なリソース要件を持つマルチティアWebアプリケーションに向いています。
EKSマネージドノードグループが適している場合:
- Kubernetesの利点を活かしたい場合:
- 複雑なアプリケーションやマイクロサービスアーキテクチャの管理を行いたい場合。特に、Kubernetesの高度な機能（例: デプロイメント、ローリングアップデート、サービスディスカバリ、自己修復機能）を利用したい場合に適しています。
- 高いカスタマイズ性と柔軟性が必要な場合:
- EKSはKubernetesで動作し、柔軟なカスタマイズが可能です。たとえば、複数の異なるタイプのアプリケーション（Webサーバ、バックエンドAPI、データベースサーバ）を同じクラスター内で管理する場合に便利です。
- 大規模なマルチティアアーキテクチャが必要な場合:
- EKSは、スケーラビリティの高い大規模なシステムや、データベースやキャッシュなどの他のバックエンドサービスと連携する複雑なアーキテクチャに向いています。
結論
- ECS Fargateは、シンプルで運用負荷を軽減したいマルチティアWebアプリケーションに最適です。特に、インフラの管理やKubernetesの詳細な設定を気にせず、スケーラブルで柔軟なリソース配分が必要な場合に最適です。
- EKSマネージドノードグループは、より複雑で柔軟なマルチティアアーキテクチャを管理し、高度なオーケストレーションやカスタマイズを行いたい場合に適しています。
アプリケーションの規模や運用のニーズに合わせて選択することが重要です。
実践
略
一問道場
質問 #228
トピック 1
ある企業が、オンプレミスのデータセンターからAWSにマルチティアWebアプリケーションを移行し、コンテナ化したいと考えています。アプリケーションにはWeb、アプリケーション、データベースの各ティアが含まれています。企業は、アプリケーションを障害に強く、スケーラブルにする必要があります。頻繁にアクセスされるデータは、アプリケーションサーバー間で常に利用できる必要があります。フロントエンドWebサーバーはセッションの永続性を必要とし、トラフィックの増加に対応するためにスケールする必要があります。
どのソリューションが、最小限の運用オーバーヘッドでこれらの要件を満たすでしょうか？
A. Amazon Elastic Container Service (Amazon ECS)をAWS Fargateで実行し、頻繁にアクセスされるデータはWebおよびアプリケーションティア間で共有されるように、Amazon Elastic File System (Amazon EFS)を使用する。フロントエンドWebサーバーのセッションデータはAmazon Simple Queue Service (Amazon SQS)に保存する。
B. Amazon Elastic Container Service (Amazon ECS)をAmazon EC2で実行し、フロントエンドWebサーバーのセッションデータをキャッシュするためにAmazon ElastiCache for Redisを使用する。複数のアベイラビリティゾーンに分散したEC2インスタンスにAmazon Elastic Block Store (Amazon EBS)をMulti-Attachで使用する。
C. Amazon Elastic Kubernetes Service (Amazon EKS)でアプリケーションを実行し、EKSにマネージドノードグループを使用する。WebサーバーとアプリケーションをReplicaSetsで実行し、Amazon Elastic File System (Amazon EFS)を作成して、すべてのEKSポッドにEFSファイルシステムをマウントし、フロントエンドWebサーバーのセッションデータを保存する。
D. Amazon Elastic Kubernetes Service (Amazon EKS)でアプリケーションをデプロイし、EKSにマネージドノードグループを使用する。WebサーバーとアプリケーションをKubernetesのデプロイメントとして実行し、フロントエンドWebサーバーのセッションデータをAmazon DynamoDBテーブルに保存する。アプリケーションがデプロイされる際に、すべてのアプリケーションがマウントするAmazon Elastic File System (Amazon EFS)ボリュームを作成する。
解説
この問題に関する解説は以下の通りです。
シナリオ：
企業が複数のレイヤー（Web、アプリケーション、データベース）からなるアプリケーションをコンテナ化して、オンプレミスからAWSへ移行したいと考えています。アプリケーションの可用性とスケーラビリティを確保する必要があります。さらに、頻繁にアクセスされるデータはアプリケーションサーバ間で常に利用可能でなければなりません。フロントエンドのWebサーバはセッションの保持が必要で、トラフィックの増加に応じてスケールできる必要があります。
主要な要件：
- アプリケーションのスケーラビリティ - 負荷に応じてスケールできる。
- フォールトトレランス - 高可用性を確保する。
- セッション管理 - フロントエンドWebサーバはセッションを維持しなければならない。
- データの共有 - 頻繁にアクセスされるデータをWebとアプリケーション層間で共有。
各選択肢の説明：
A. ECS + AWS Fargate + EFS + SQS
- Amazon ECS（Elastic Container Service） を利用してFargate上でアプリケーションを実行し、Amazon EFS を利用して頻繁にアクセスされるデータを共有する。
- ただし、SQS はセッション管理には不適切です。セッションデータはキューではなく、セッションストレージに保存するべきです。
- セッション情報はキューに保存せず、ElastiCache や DynamoDB に保存する方が適切です。
- SQS は非同期処理向けであり、セッション管理には不向きなので、この選択肢は不適切です。
B. ECS + EC2 + ElastiCache + EBS
- Amazon ECS をEC2上で運用し、ElastiCache for Redis を使用してセッションデータをキャッシュします。EBS（Elastic Block Store）はEC2インスタンスのストレージですが、EBSを複数のインスタンスで共有するのは困難であり、特にEBSのMulti-Attachは一部の特殊なユースケースに対応しています。
- このソリューションはスケーラビリティやフォールトトレランスを高めることができますが、EBSの管理やスケーリングの難しさが問題です。
- そのため、EFS の方がスケーラブルで管理が簡単です。
C. EKS + EFS + セッションデータ
- Amazon EKS（Elastic Kubernetes Service）を使用してアプリケーションを管理し、EFS を使用してデータの共有を実現します。さらに、EKS のポッド間で共有されるセッションデータの保存場所として DynamoDB を使用します。
- この構成は、スケーラビリティとフォールトトレランスを確保しつつ、EFS と DynamoDB を活用して効率的にデータの共有とセッション管理を行います。
- EKS による Kubernetes の管理、DynamoDB のセッションデータの保存、EFS による共有ストレージの利用は、スケーラブルで信頼性の高いアーキテクチャです。
D. EKS + EFS + DynamoDB + セッションデータ
- EKS を使用してアプリケーションを管理し、EFS と DynamoDB を使用してデータの共有とセッションデータの保存を行います。
- EFS はアプリケーション層とWeb層間でデータを共有するために利用され、DynamoDB はセッションデータを高速かつスケーラブルに管理するために使用されます。
- EKS の管理ノードグループを使用することで、運用のオーバーヘッドが軽減され、アプリケーションのスケーリングと可用性が確保されます。
- この選択肢が最適です。
結論：
選択肢 D は、スケーラビリティ、フォールトトレランス、セッション管理の要件を最も効果的に満たしており、運用オーバーヘッドが最小限で済みます。EKS、EFS、DynamoDB の組み合わせは、コンテナ化されたアプリケーションにおける最適な解決策です。
229-AWS SAP AWS 「理論・実践・一問道場」CDC
理論
本質的な知識: データベースの移行方法とゼロダウンタイムの実現
CDC（Change Data Capture）とは、データベースにおける変更内容をリアルタイムで追跡し、記録する技術です。具体的には、データベースの更新、削除、挿入が行われたときに、その変更を検出し、記録します。
例で説明すると：
- ある顧客情報がデータベースに登録されているとします。
- その顧客の住所が変更された場合、CDCは「顧客情報が変更された」というデータの変更を検出します。
- この変更されたデータを、他のシステム（たとえば、データウェアハウスや別のデータベース）に即座に転送したり、同期させることができます。
CDCの利点：
- リアルタイム性: データベースの変更を即座に検出して転送できるので、データの同期がリアルタイムで行えます。
- 効率的なデータ移行: 完全なデータを移行するのではなく、変更があったデータだけを追跡するため、データ移行が効率的に行えます。
使用シーン：
- データの同期や、異なるシステム間でのデータのリアルタイム複製を行う場合に使われます。たとえば、AWS DMS（Database Migration Service）や、ETL（Extract, Transform, Load）処理でよく利用されます。
- ゼロダウンタイム移行: データベース移行において、ダウンタイムを最小限に抑えることが重要です。これには、データのリアルタイム同期や、**変更データキャプチャ（CDC）**技術が有効です。
- AWS Database Migration Service (AWS DMS):
- AWS DMSは、データベースの移行を行うために設計されたサービスで、変更データキャプチャ（CDC）を使って、ソースとターゲット間でリアルタイムの同期を実現します。
- 移行中でもデータベースは稼働し続け、最小限のダウンタイムで移行できます。
- AWS RDS for Microsoft SQL Server:
- RDS for SQL Serverは、フルマネージド型のデータベースサービスで、運用負担を減らしつつ、スケーラビリティや高可用性が確保されます。
- RDSへの移行には、AWS DMSを使用することで、ほぼゼロダウンタイムでの移行が可能です。
- レプリケーションとスキーマ変換:
- ネイティブのレプリケーションや、スキーマ変換ツール（AWS SCT）を使う方法もありますが、AWS DMSほど簡単にスケールするわけではなく、ダウンタイムのリスクがあります。
要点
- AWS DMSを利用することで、リアルタイムのデータ同期とゼロダウンタイムでのデータ移行を実現できる。
- これにより、ミッションクリティカルなシステムでも業務に支障をきたさずに移行を進めることができます。
実践
略
一問道場
問題 #229
トピック 1
ソリューションアーキテクトは、AWSに重要なMicrosoft SQL Serverデータベースを移行する計画を立てています。これらのデータベースはレガシーシステムであり、ソリューションアーキテクトはそれらをモダンなデータアーキテクチャに移行します。ソリューションアーキテクトは、ほぼゼロダウンタイムでデータベースを移行する必要があります。
どのソリューションがこれらの要件を満たすでしょうか？
A. AWSアプリケーションマイグレーションサービスとAWSスキーマ変換ツール（AWS SCT）を使用します。マイグレーション前にインプレースアップグレードを実行します。マイグレーション後、データをAmazon Aurora Serverlessにエクスポートします。切り替え後、アプリケーションをAmazon Auroraにポイントします。
B. AWSデータベースマイグレーションサービス（AWS DMS）を使用してデータベースをリホストします。ターゲットとしてAmazon S3を設定します。変更データキャプチャ（CDC）レプリケーションを設定します。ソースとターゲットが完全に同期されたら、データをAmazon S3からAmazon RDS for Microsoft SQL Server DBインスタンスにロードします。
C. ネイティブのデータベース高可用性ツールを使用します。ソースシステムをAmazon RDS for Microsoft SQL Server DBインスタンスに接続します。レプリケーションを設定します。データレプリケーションが完了したら、ワークロードをAmazon RDS for Microsoft SQL Server DBインスタンスに移行します。
D. AWSアプリケーションマイグレーションサービスを使用します。データベースサーバーをAmazon EC2でリホストします。データレプリケーションが完了したら、データベースを切り離し、Amazon RDS for Microsoft SQL Server DBインスタンスに移動します。データベースを再接続し、ネットワーキングを切り替えます。
解説
この問題の解説は以下の通りです。
要件:
- ほぼゼロダウンタイムでデータベースを移行する。
- 重要なMicrosoft SQL ServerデータベースをAWSに移行し、モダンなデータアーキテクチャに対応させる。
選択肢ごとに解説します。
A. AWSアプリケーションマイグレーションサービスとAWSスキーマ変換ツール（AWS SCT）を使用する
- AWS Application Migration Serviceは、サーバーやアプリケーションをAWSに移行するためのサービスであり、データベース移行には必ずしも最適ではありません。
- AWS Schema Conversion Tool（SCT）はデータベースのスキーマ変換を支援しますが、実際のデータ移行やゼロダウンタイムの要件には不向きです。
- Aurora Serverlessへのエクスポートは、従来のSQL ServerからAuroraへの移行において問題が多く、最適ではありません。
不適切です。
B. AWS DMSを使用してデータベースをリホストする
- *AWS Database Migration Service（AWS DMS）は、データベースの移行に特化したサービスで、特に変更データキャプチャ（CDC）**を使用して、リアルタイムでデータの同期を行うことができます。
- S3をターゲットに設定し、同期が完了した後に、Amazon RDS for SQL Serverへロードすることで、ほぼゼロダウンタイムで移行できます。
- この方法は、データベースの移行作業を中断せず、ダウンタイムを最小限に抑えるための最適な方法です。
適切です。
C. ネイティブのデータベース高可用性ツールを使用
- ネイティブのデータベース高可用性ツール（例えばSQL Serverのレプリケーション）は、SQL Serverに組み込まれた機能を使用して移行する方法です。
- これにより、データベースを同期することができますが、AWSへの移行にはAWS固有のサービス（例えばRDS）が必要です。
- さらに、データベースの接続を切り替える際にダウンタイムが発生する可能性があります。
不適切です。
D. AWSアプリケーションマイグレーションサービスを使用してEC2にリホスト
- AWSアプリケーションマイグレーションサービスを使ってEC2インスタンスにリホストし、レプリケーションを行う方法です。最終的にRDSに移行しますが、この方法では一度EC2上で動かしてから切り替えを行うため、ダウンタイムのリスクがあります。
- この方法ではゼロダウンタイムを実現するのが難しく、効率的な方法ではありません。
不適切です。
結論:
Bが最適です。AWS DMSを使うことで、データベースをリアルタイムで同期させ、ほぼゼロダウンタイムで移行することができます。
230-AWS SAP AWS 「理論・実践・一問道場」クロスゾーン負荷分散
理論
AWSのデータ転送のコスト
AWSでは、同じアベイラビリティゾーン内での通信は無料で行える場合が多いですが、異なるアベイラビリティゾーン間でのデータ転送には費用がかかります。これがAWSのコストを予想以上に高くする要因の1つです。
クロスゾーン負荷分散（Cross-Zone Load Balancing）
AWSのNetwork Load Balancer（NLB）では、デフォルトでクロスゾーン負荷分散機能が有効になっており、異なるアベイラビリティゾーン間にリクエストを均等に分配します。この機能が有効だと、トラフィックが複数のAZに渡るため、その分データ転送コストが増加します。
- オフにするメリット: クロスゾーン負荷分散を無効にすると、リクエストが同じAZ内のインスタンスに分配されるため、AZ間のデータ転送がなくなり、コストを削減できます。
エンドポイントの最適化
サービス提供者と消費者のアプリケーションが異なるAZに配置されている場合、通信のために多くのデータ転送が発生します。しかし、サービス消費者のリソースがローカルのAZ特有のエンドポイントを使うように設定することで、同じAZ内で通信を行い、コストの削減が可能です。
ベストプラクティス
- アベイラビリティゾーンを意識した設計: サービス提供者とサービス消費者を同じAZ内に配置することにより、内部通信の最適化を図る。
- クロスゾーン負荷分散を無効にする: 必要ない場合はクロスゾーン負荷分散を無効にして、AZ間の不要なデータ転送を避ける。
- エンドポイントの最適化: ローカルDNSを使って、リソースが同じAZ内で接続するように設定する。
これらの対策により、AWSのリソース間で発生する不要なデータ転送を減らし、コストを効果的に削減できます。
実践
略
一問道場
問題 #230
トピック 1
ある企業のソリューションアーキテクトが、複数のアプリケーション環境のコストを分析しています。この環境は、単一のAWSリージョン内の複数のアベイラビリティゾーンに展開されています。最近の買収後、企業はAWS Organizationsで2つの組織を管理しています。企業は、1つの組織内でAWS PrivateLinkを利用したVPCエンドポイントサービスとして複数のサービスプロバイダアプリケーションを作成しました。企業は、他の組織内で複数のサービスコンシューマアプリケーションを作成しました。
データ転送費用が予想以上に高く、ソリューションアーキテクトはコストを削減する必要があります。ソリューションアーキテクトは、開発者がサービスを展開する際に従うべきガイドラインを推奨する必要があります。これらのガイドラインは、環境全体のデータ転送コストを最小限に抑えるものでなければなりません。
どのガイドラインがこれらの要件を満たしますか？（2つ選択）
A. AWS Resource Access Managerを使用して、サービスプロバイダアプリケーションをホストするサブネットを組織内の他のアカウントと共有する。
B. サービスプロバイダアプリケーションとサービスコンシューマアプリケーションを同一の組織内のAWSアカウントに配置する。
C. すべてのサービスプロバイダアプリケーションの展開で、Network Load Balancerのクロスゾーン負荷分散を無効にする。
D. サービスコンシューマコンピュートリソースが、エンドポイントのローカルDNS名を使用してアベイラビリティゾーン固有のエンドポイントサービスを利用することを確認する。
E. 組織の予定されているアベイラビリティゾーン間データ転送使用量に対して適切なカバレッジを提供するSavings Planを作成する。
解説
この問題では、AWSのデータ転送コストを削減するために、複数のアベイラビリティゾーン（AZ）間でのデータ転送を最小化する方法を求められています。具体的には、AWSのサービス（特にVPCエンドポイントサービスとネットワークロードバランサー）を使用して、サービス間のデータ転送コストをどのように抑えるかという点が焦点です。
問題の状況：
- 会社は複数のAWSアカウントを使用しており、1つの組織でサービス提供者アプリケーション（AWS PrivateLink）を管理しています。
- 他の組織ではサービス消費者アプリケーションが運用されており、これらのアプリケーション間のデータ転送コストが予想よりも高い。
解決策：
この問題を解決するために、次の2つの方針が必要です：
- サービス間でのデータ転送をできるだけ減らすこと。
- 異なるアベイラビリティゾーン間のデータ転送を最小限に抑えること。
各選択肢の説明：
- A. AWS Resource Access Managerを使用して、サービス提供者アプリケーションのサブネットを他のアカウントと共有： これにより、データ転送が同じVPC内で完結し、AZ間の転送が減少する可能性があります。しかし、これは必ずしもコスト削減に直結しません。
- B. サービス提供者アプリケーションとサービス消費者アプリケーションを同じ組織内に配置： これも有効ですが、必ずしもデータ転送コストの削減に直接的に貢献するとは限りません。
- C. サービス提供者アプリケーションのネットワークロードバランサーでクロスゾーン負荷分散を無効にする： クロスゾーン負荷分散を有効にすると、異なるAZ間でトラフィックが分散され、データ転送コストが増加します。これを無効にすることで、トラフィックが同じAZ内で完結するようにでき、コスト削減に繋がります。
- D. サービス消費者コンピューティングリソースが、エンドポイントのローカルDNS名を使用して、特定のAZのエンドポイントサービスを使用するように設定する： サービス消費者が特定のAZ内のエンドポイントにアクセスするように設定することで、AZ間のデータ転送を防ぎ、コスト削減に繋がります。
- E. 組織の予定されたAZ間データ転送使用に対する十分なカバレッジを提供するSavings Planを作成： Savings Planはコスト削減に役立ちますが、データ転送コストの削減という直接的な効果は期待できません。したがって、この選択肢は最適ではありません。
最適な解決策：
- *C（クロスゾーン負荷分散を無効にする）とD（ローカルDNS名を使用する）**は、どちらもアベイラビリティゾーン間のデータ転送を削減する直接的な方法です。これらの対策によって、サービス間のデータ転送が同じAZ内で完結し、コスト削減が可能になります。
結論：
最適な選択肢はCとDです。これにより、サービス間のデータ転送が効率化され、不要なコストを削減することができます。
- Author:minami
- URL:http://preview.tangly1024.com/private-license/172d7ae8-88e2-8043-9588-f894c4ddb433
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
