29-AWS SAP「理論・実践・10問道場」

type

status

date

slug

summary

291-AWS SAP AWS 「理論・実践・一問道場」AWS Batch

理論

1. Amazon EC2の使用方法とインスタンスの料金モデル

Amazon EC2（Elastic Compute Cloud）は、オンデマンドでコンピュータリソースを提供するサービスです。EC2インスタンスの料金には、オンデマンド、リザーブド、スポットインスタンスの3つの主要な料金モデルがあります。

オンデマンドインスタンス: 使用した時間に基づいて課金される、最も柔軟なオプションです。短期間での使用には便利ですが、長期間の使用には高額になる可能性があります。

リザーブドインスタンス: 特定の期間（1年または3年）でインスタンスを予約することで、オンデマンドよりもコストを抑えることができます。ただし、事前に購入する必要があり、一定の柔軟性を欠くため、長期的な使用が確定している場合に有利です。

スポットインスタンス: AWSが未使用のキャパシティを利用して提供する、最もコスト効果の高いインスタンスオプションです。ただし、リソースが必要になった場合にはインスタンスが停止される可能性があるため、利用には慎重さが必要です。

2. AWS Batch

AWS Batchは、大規模なバッチ処理を簡単に実行するための完全マネージドサービスです。AWS Batchはジョブスケジューリング、コンテナ化された処理、インスタンスのスケーリングなどを管理し、インフラの管理負担を大幅に削減します。

スポットインスタンスの使用: AWS Batchではスポットインスタンスを使用することで、コスト効率をさらに向上させることができます。特に処理の優先度が低く、失敗しても再試行が可能なジョブに適しています。

バッチ処理のスケーリング: AWS Batchは、処理の負荷に応じてインスタンスの数を動的に調整するため、リソースの無駄を減らし、コストを削減することができます。

3. Amazon Kinesis Data Firehose

Amazon Kinesis Data Firehoseは、データストリーミングのための完全マネージド型サービスで、リアルタイムでデータを収集、変換、保存することができます。データをAmazon S3、Amazon Redshift、Amazon Elasticsearchなどに自動的にストリーミングすることができます。

データのストリーミングと保存: Kinesis Data Firehoseを使用すると、ストリーミングデータをリアルタイムで保存でき、処理を後で行うためにデータを一時的に保持することができます。これにより、データの即時処理や後処理のスケジュールが可能になります。

4. Amazon S3

Amazon S3（Simple Storage Service）は、スケーラブルで高可用性のあるオブジェクトストレージサービスです。バッチ処理や大規模データの保存に頻繁に使用されます。Kinesis Data Firehoseと組み合わせて使用することで、ストリーミングデータを効率的に保存し、後続の処理に利用することができます。

バッチ処理に適したストレージ: S3は、高いスループットとスケーラビリティを提供するため、バッチ処理や分析に非常に適しています。データの保存やアーカイブに使い、S3上のデータを他のサービス（例えばAWS Lambda、Redshiftなど）で処理することができます。

5. AWS Lambda

AWS Lambdaは、サーバーレスの計算サービスで、コードをイベントに基づいて自動的に実行します。これにより、サーバーの管理やスケーリングを気にせずに、イベント駆動型の処理を実行できます。

サーバーレス処理: AWS Lambdaを使用すれば、インフラを管理することなく、データの処理や統計の集計などを実行できます。例えば、KinesisやS3イベントをトリガーにしてLambda関数を実行することで、リアルタイムまたは定期的なデータ処理が可能です。

6. Amazon Redshift

Amazon Redshiftは、ペタバイト規模のデータウェアハウスソリューションで、大規模なデータの分析を高速で行うことができます。大量のデータを集約して、迅速にクエリを実行できるため、分析用途に最適です。

データ分析のためのデータストレージ: バッチ処理後の集計結果をRedshiftに保存し、データを迅速に分析することができます。Redshiftは高い並列処理能力を持ち、ビジネスインテリジェンス（BI）ツールやダッシュボードに活用することができます。

7. コスト最適化

AWSでは、リソースの利用効率を最適化することで、コスト削減が可能です。以下の方法でコスト効率を最大化できます。

スポットインスタンスの活用: 特に優先度が低く、停止しても問題ないジョブにスポットインスタンスを使用することで、コストを最大50％削減できます。

オートスケーリング: AWSのオートスケーリング機能を使用すると、需要に応じてインスタンス数を増減させ、リソースを無駄なく使用できます。

予約インスタンス: 長期的に安定したリソース需要がある場合、リザーブドインスタンスを使って割引を受けることができます。

結論

データのストリーミング処理やバッチ処理の設計において、コスト効率を最適化するための選択肢は、スポットインスタンスの利用やAWS Batch、Kinesis Data Firehoseを活用したアーキテクチャの選定です。これにより、柔軟性とコスト削減を両立させながら、大規模なデータ処理を効率的に行うことができます。

実践

触って理解するAWS Batchプチハンズオン

ちょっとしたバッチ処理であればLambdaを使って簡単に実現できますが、15分制限が大きな壁となるとき、以下の2つの記事のように複数Lambda, ECS, AWS Batchが選択肢になります。

https://zenn.dev/takamin55/articles/a44ba888ebca3a

一問道場

問題 #291

トピック 1

ある企業は、ストリーミング市場データを取り込み、処理しています。データの取り込み速度は一定です。毎晩行われる集計統計の計算には4時間かかります。この統計分析はビジネスにとって重要ではなく、特定の実行が失敗しても次回の実行でデータポイントを処理できます。

現在のアーキテクチャでは、1年間の予約をしたAmazon EC2リザーブドインスタンスのプールを使用しています。これらのEC2インスタンスはフルタイムで動作し、ストリーミングデータを取り込んでAmazon Elastic Block Store（Amazon EBS）ボリュームに保存しています。毎晩スケジュールされたスクリプトがEC2オンデマンドインスタンスを起動し、そのインスタンスで保存されたデータにアクセスして夜間の処理を行います。処理が完了するとスクリプトがインスタンスを終了します。

リザーブドインスタンスの予約が終了します。会社は、新しい予約を購入するべきか、別の設計を採用すべきかを決定する必要があります。

どのソリューションが最もコスト効果の高い方法となりますか？

A. 取り込みプロセスを変更し、Amazon Kinesis Data Firehoseを使用してデータをAmazon S3に保存します。毎晩のバッチ処理のためにスケジュールされたスクリプトでEC2オンデマンドインスタンスのフリートを起動し、処理が完了した後にインスタンスを終了します。

B. 取り込みプロセスを変更し、Amazon Kinesis Data Firehoseを使用してデータをAmazon S3に保存します。AWS Batchを使用し、スポットインスタンスを最大でオンデマンド価格の50％で使用して毎晩の処理を実行します。

C. 取り込みプロセスを変更し、EC2リザーブドインスタンスのフリートを3年間の予約でネットワークロードバランサー（NLB）の背後に配置します。AWS Batchを使用し、スポットインスタンスを最大でオンデマンド価格の50％で使用して毎晩の処理を実行します。

D. 取り込みプロセスを変更し、Amazon Kinesis Data Firehoseを使用してデータをAmazon Redshiftに保存します。Amazon EventBridgeを使用して、毎晩Amazon Redshiftをクエリして統計を生成するAWS Lambda関数をスケジュールします。

解説

この問題では、企業がデータ処理のコストを最適化するために、既存のEC2インスタンスのリザーブドインスタンスを使用する方法から、より効率的でコスト効果の高いアーキテクチャに移行する方法を検討しています。各選択肢について解説します。

A. Kinesis Data FirehoseとEC2オンデマンドインスタンス

アーキテクチャ: データはAmazon Kinesis Data Firehoseを使用してS3に保存され、毎晩EC2オンデマンドインスタンスでバッチ処理を行います。処理が完了した後、インスタンスは終了します。

評価: これはEC2インスタンスを使用し続ける選択肢であり、コストがかかりやすい可能性があります。EC2オンデマンドインスタンスは使用時間に応じて料金が発生するため、コストが高くなることがあります。

B. Kinesis Data FirehoseとAWS Batchスポットインスタンス

アーキテクチャ: データはKinesis Data FirehoseでS3に保存され、AWS Batchを使用してスポットインスタンスで毎晩の処理を実行します。スポットインスタンスの価格はオンデマンド価格の最大50％です。

評価: スポットインスタンスを使用することで、コストを大幅に削減できます。AWS Batchはスケーラブルで効率的な処理を行うため、コスト効率が良いです。処理が失敗してもデータが次回の処理に再利用できるため、スポットインスタンスの中断にも耐性があります。

C. EC2リザーブドインスタンスとAWS Batchスポットインスタンス

アーキテクチャ: EC2リザーブドインスタンスを3年間予約し、その後ろにネットワークロードバランサー（NLB）を配置します。AWS Batchを使い、スポットインスタンスで毎晩の処理を実行します。

評価: リザーブドインスタンスを使うことで一定のコスト削減は可能ですが、3年間の予約が固定されるため、柔軟性に欠けます。また、バッチ処理のためにスポットインスタンスを使っても、事前にリザーブドインスタンスを購入するコストが高くなる可能性があります。

D. Kinesis Data FirehoseとAmazon Redshift、AWS Lambda

アーキテクチャ: データはKinesis Data Firehoseを使用してAmazon Redshiftに保存され、Amazon EventBridgeで毎晩の処理をAWS Lambda関数にスケジュールします。Lambda関数がRedshiftをクエリして統計を生成します。

評価: Lambda関数はサーバーレスでスケーラブルな処理を提供しますが、データの保存先としてAmazon Redshiftを選ぶことはオーバーヘッドが大きくなります。特に、統計の計算に特化した処理でない限り、Redshiftを使用するのはコストと管理の面で効率的でない可能性があります。

最もコスト効率の良い選択肢

B が最もコスト効率の良い選択肢です。Amazon Kinesis Data Firehoseを使用してデータをS3に保存し、AWS Batchをスポットインスタンスで実行することで、スケーラブルで低コストの処理を実現できます。スポットインスタンスの価格を最大50％削減できるため、コストの最適化が図れます。

結論

B が最もコスト効果の高い解決策です。

292-AWS SAP AWS 「理論・実践・一問道場」Transfer Family

理論

1. VPCエンドポイントの概要

VPCエンドポイントは、Amazon Virtual Private Cloud（VPC）内からAWSのサービス（Amazon S3やDynamoDBなど）にアクセスするためのプライベート接続を提供する機能です。VPCエンドポイントを使うことで、インターネットを経由せずにAWSのサービスへ直接アクセスできます。これにより、セキュリティが向上し、パフォーマンスが改善されます。

VPCエンドポイントには主に2種類あります：

インターフェースエンドポイント（Interface Endpoint）: 各AWSサービスのエンドポイントに対してVPC内でプライベートIPアドレスを割り当てて、インターネットを使わずにアクセスする方法。

ゲートウェイエンドポイント（Gateway Endpoint）: 主にAmazon S3やDynamoDBに対して、インターネットを経由せずにアクセスするためのエンドポイント。これらのサービス専用です。

2. インターネット向けVPCエンドポイント

通常、VPCエンドポイントはインターネットを使わずにAWSサービスにアクセスするために使用されますが、インターネット向けのVPCエンドポイントという表現について説明すると、以下のようなポイントがあります。

2.1. インターネット向けのVPCエンドポイントとは？

インターネット向けのVPCエンドポイントは、主に「インターネット越しにVPC内のサービスへアクセスするためのエンドポイント」を指す場合に使用されます。これには、VPC内のリソースをインターネット越しにアクセスできるようにする、例えばAWS Transfer Family（SFTPサーバー）などのサービスが含まれます。

この場合、AWSのインターネット向けVPCエンドポイントは、VPC内にデプロイされたサービスを、インターネットを経由して外部からアクセスできるように提供する構成です。エンドポイント自体は、VPCの外部の顧客やシステムからインターネットを通じて直接アクセスされます。

2.2. インターネット向けのVPCエンドポイントを使用する状況

AWS Transfer Family: インターネット経由でアクセスする必要があるSFTP/FTPサービスを提供する場合、AWS Transfer Familyがインターネット向けのアクセスに使用されることが多いです。この場合、インターネット向けのVPCエンドポイントを設定することで、セキュアな接続を外部に提供します。

静的なパブリックIP: インターネット向けのサービスに接続する場合、静的なIPアドレス（Elastic IP）を指定してアクセスすることができます。これにより、外部のクライアントが固定IPアドレスを許可する設定が可能です。

2.3. セキュリティの観点

インターネット向けにVPCエンドポイントを設定する際は、以下の点に注意が必要です：

セキュリティグループの設定: アクセス制御のため、適切なセキュリティグループ設定が必要です。外部アクセスを許可するIPアドレスやプロトコルを絞り込むことが求められます。

アクセスログの活用: 外部のアクセスを監視し、ログを活用してセキュリティ上の問題を特定します。AWSのログサービス（CloudWatchなど）を活用することが推奨されます。

3. インターネット向けエンドポイントとプライベートアクセスの違い

インターネット向けアクセス: 公開されているAWSのサービスに対し、インターネット越しにアクセスする構成。外部の顧客やシステムが直接アクセスできます。

プライベートアクセス（VPC内からのアクセス）: インターネットを経由せずにVPC内のサービスへアクセスするためのエンドポイント。セキュリティが強化され、インターネットを経由しないのでパフォーマンスの向上も期待できます。

4. 関連するサービス

AWS Transfer Family: SFTP/FTP/FTPSを使って、データ転送サービスを提供するフルマネージドのサービス。インターネット経由でアクセスする際に利用されます。

Elastic IP (EIP): インターネット向けアクセスに利用する静的IPアドレスを提供します。外部の顧客が固定のIPを使ってAWSリソースにアクセスする場合に便利です。

結論

インターネット向けのVPCエンドポイントは、特にインターネット越しに外部からAWSサービスにアクセスする場合に使用されます。特定のAWSサービス（例えばAWS Transfer Family）を公開する場合に、このようなエンドポイントを設定することで、セキュアに外部アクセスを管理できます。また、セキュリティやパフォーマンスの面でも優れた管理が可能です。

実践

略

一問道場

問題 #292

トピック 1

ある企業がオンプレミスのSFTPサイトをAWSに移行する必要があります。現在、このSFTPサイトはLinux VMで実行されており、アップロードされたファイルはNFS共有を通じて下流のアプリケーションに提供されています。AWSへの移行の一環として、ソリューションアーキテクトは高可用性を実現する必要があります。このソリューションは、外部ベンダーに静的なパブリックIPアドレスを提供し、そのIPアドレスを許可リストに追加できるようにする必要があります。企業は、オンプレミスのデータセンターとVPC間にAWS Direct Connect接続を設定しています。

どのソリューションが最も運用負荷を軽減し、要件を満たすでしょうか？

A. AWS Transfer Familyサーバーを作成し、インターネット向けのVPCエンドポイントを構成します。各サブネットにElastic IPアドレスを指定し、Transfer Familyサーバーを複数のアベイラビリティゾーンに展開されたAmazon Elastic File System（Amazon EFS）にファイルを保存するように構成します。既存のNFS共有にアクセスしている下流アプリケーションの設定を変更し、EFSエンドポイントをマウントするようにします。

B. AWS Transfer Familyサーバーを作成し、パブリックにアクセス可能なエンドポイントを構成します。Transfer Familyサーバーを複数のアベイラビリティゾーンに展開されたAmazon Elastic File System（Amazon EFS）にファイルを保存するように構成します。既存のNFS共有にアクセスしている下流アプリケーションの設定を変更し、EFSエンドポイントをマウントするようにします。

C. AWS Application Migration Serviceを使用して、既存のLinux VMをAmazon EC2インスタンスに移行します。EC2インスタンスにElastic IPアドレスを割り当て、Amazon Elastic File System（Amazon EFS）をEC2インスタンスにマウントします。SFTPサーバーをEFSにファイルを保存するように構成します。既存のNFS共有にアクセスしている下流アプリケーションの設定を変更し、EFSエンドポイントをマウントするようにします。

D. AWS Application Migration Serviceを使用して、既存のLinux VMをAWS Transfer Familyサーバーに移行します。Transfer Familyサーバーにパブリックにアクセス可能なエンドポイントを構成します。Transfer Familyサーバーを複数のアベイラビリティゾーンに展開されたAmazon FSx for Lustreファイルシステムにファイルを保存するように構成します。既存のNFS共有にアクセスしている下流アプリケーションの設定を変更し、FSx for Lustreエンドポイントをマウントするようにします。

解説

選択肢 A が最適である理由について整理します。

A. AWS Transfer Family + EFS (インターネット向けVPCエンドポイント)

構成内容:

AWS Transfer Familyサーバーを使用してSFTPサーバーを構築。

インターネット向けのVPCエンドポイントを設定し、外部ベンダーにアクセスを提供。

ファイルはAmazon Elastic File System (EFS) に保存し、EFSは複数のアベイラビリティゾーンにまたがって展開されることで高可用性を確保。

既存のNFS共有にアクセスする下流アプリケーションは、EFSエンドポイントをマウントしてファイルにアクセス。

このソリューションのメリット:

高可用性:

EFSはマネージドサービスであり、複数のアベイラビリティゾーンにまたがってデータを保存することで、高可用性が確保されます。

AWS Transfer Familyを使用することで、冗長性と可用性が確保され、インフラの運用負荷を最小限に抑えることができます。

低運用負荷:

AWS Transfer Familyはフルマネージドサービスであり、SFTPサーバーのインフラ管理やセキュリティの設定、スケーリングをAWSが管理します。そのため、管理の負担が大きく軽減されます。

EFSもフルマネージドサービスであり、ファイルシステムの管理やスケーリングをAWSが自動的に行います。

静的IPの提供:

インターネット向けのVPCエンドポイントを使用することで、外部ベンダーに静的なパブリックIPアドレスを提供できます。これにより、ベンダーが指定したIPアドレスに対してアクセスを許可することができます。

簡単な移行:

既存のNFS共有にアクセスする下流アプリケーションは、EFSエンドポイントをマウントするだけで、ほとんどの変更なしにAWS環境に移行できます。

他の選択肢と比較した場合の利点:

選択肢Aは、インフラ管理の複雑さを最小化しつつ、SFTPサーバーの高可用性を提供し、外部ベンダーに静的なIPアドレスを提供する要件を満たす最も効率的な方法です。

選択肢Bは、同様にEFSを使用しますが、インターネット向けエンドポイントを使用する点が異なります。どちらも高可用性を提供しますが、選択肢Aの方が明確に要件に沿っており、最も効率的な設計です。

結論:

選択肢Aが最適なソリューションです。AWS Transfer Familyのインターネット向けVPCエンドポイントを使って、静的IPアドレスを提供しつつ、EFSで高可用性を確保し、運用負荷を最小化します。このアプローチは、要件を満たす上で最もシンプルでコスト効率の良い方法です。

293-AWS SAP AWS 「理論・実践・一問道場」AZサブネットのリサイズ

理論

1. Amazon VPC (Virtual Private Cloud) とサブネット管理

Amazon VPCは、AWSのクラウド内に仮想的なネットワーク環境を構築するためのサービスです。このVPCは、インターネットと接続されたり、プライベートな内部ネットワークを構成したりできます。VPC内で使用するIPアドレスの範囲をCIDR (Classless Inter-Domain Routing) ブロックを使って定義します。

CIDRブロック: CIDRはIPアドレスの範囲を指定する方法で、通常はVPC全体のIP範囲やサブネットのIP範囲を設定するために使用されます。例えば、10.0.0.0/23というCIDRブロックは、10.0.0.0から10.0.1.255までのIPアドレス範囲を意味します。

サブネット: VPC内に配置される小さなネットワークのことです。サブネットもCIDRブロックを使用して、使用するIPアドレスの範囲を定義します。VPC内のサブネットを複数作成することで、トラフィックの隔離や冗長性を確保できます。

2. Auto Scaling とネットワークの設定

Auto Scalingは、AWS上でのインスタンスの数を自動的に調整するためのサービスです。通常、EC2インスタンスを自動的に増減させることで、トラフィックの変動に対応し、コストを最適化します。

Auto Scaling グループ: Auto Scalingグループは、指定された数のEC2インスタンスを維持するために、自動的にインスタンスを起動したり停止したりするグループです。インスタンスは、ターゲットとしているサブネットに配置され、適切なアベイラビリティゾーン(AZ)内で冗長性を持つように設定されます。

アベイラビリティゾーン: AWSは、各リージョン内に複数のアベイラビリティゾーン(AZ)を提供しており、これにより、高可用性を確保するために、リソースを複数の物理的に分離されたデータセンターに分散配置することができます。

3. サブネットサイズとCIDRの制約

サブネットのCIDRの制限: VPC内のサブネットのCIDRブロックは、一度作成すると変更できません。そのため、CIDRブロックを変更したい場合は、新しいサブネットを作成し、インスタンスを新しいサブネットに移行する必要があります。

サブネットのサイズ変更方法: サブネットのサイズを変更するには、既存のサブネットを削除して新しいCIDRブロックでサブネットを再作成する必要があります。これを行う際には、インスタンスの移行やネットワーク設定の更新が必要です。

4. ネットワーク設計のベストプラクティス

冗長性と可用性の確保: ネットワーク設計において、複数のアベイラビリティゾーン(AZ)を利用することで、高可用性を確保できます。例えば、Auto Scalingグループを複数のAZにまたがるように設定することで、あるAZで障害が発生しても他のAZでインスタンスが稼働し続けるようにできます。

IPアドレスの最適化: VPCのCIDRブロックは適切なサイズを選択することが重要です。必要以上に大きなCIDRブロックを割り当てると、IPアドレスが無駄に使われてしまい、リソースの浪費を招く可能性があります。一方で、CIDRブロックが小さすぎると、将来的な拡張に対応できなくなることがあります。

5. サブネットの設計と管理

サブネットを分割する: 必要に応じて、VPC内のIPアドレス範囲を小さなサブネットに分割することで、リソースを適切に管理できます。例えば、パブリックサブネットとプライベートサブネットに分け、インターネットアクセスが必要なリソースと内部専用のリソースを分けて管理できます。

セキュリティとアクセス制御: サブネットごとに異なるセキュリティグループやネットワークACLを適用することで、リソース間のアクセス制御を強化できます。特定のサブネットからインターネットへのアクセスを制限したり、特定のインスタンスのみがアクセスできるようにすることが可能です。

結論

AWS VPC、Auto Scaling、CIDRブロック、およびサブネットの管理は、AWS環境でスケーラブルで高可用性のアーキテクチャを設計するための基本的な要素です。サブネットのCIDR変更やネットワーク設計の最適化を理解しておくことは、安定した運用を実現するために非常に重要です。

実例

以下は、元々のVPC構成と提案された変更後のVPC構成を比較した表です。

サブネット名	元のCIDR	提案された変更後のCIDR	範囲
VPC CIDR	10.0.0.0/23	10.0.0.0/23	10.0.0.0 〜 10.0.1.255
AZ1サブネット	10.0.0.0/24	10.0.0.0/25	10.0.0.0 〜 10.0.0.127
AZ2サブネット	10.0.1.0/24	10.0.0.128/25	10.0.0.128 〜 10.0.0.255
AZ3サブネット	なし	10.0.1.0/25	10.0.1.0 〜 10.0.1.127

比較ポイント:

VPC CIDR は変更なし（10.0.0.0/23の範囲のまま）。

AZ1 サブネット と AZ2 サブネット の範囲をそれぞれ 10.0.0.0/24 から 10.0.0.0/25 と 10.0.1.0/24 から 10.0.0.128/25 に変更し、各サブネットに対して利用可能なIPアドレス範囲を半分に縮小します。

AZ3 サブネット は新規で作成され、CIDR は 10.0.1.0/25 に設定され、既存のアドレス空間から IP 範囲を割り当てています。

これにより、VPC内のサブネットの配置を3つのAZに広げ、可用性を確保しつつ、アドレス空間を有効に活用します。

実践

略

一問道場

問題 #293

ソリューションアーキテクトは、Amazon EC2 インスタンスが Auto Scaling グループ内で運用されているワークロードを管理しています。VPC アーキテクチャは 2 つのアベイラビリティゾーン（AZ）にまたがっており、それぞれの AZ にサブネットがあり、Auto Scaling グループはこれらのサブネットをターゲットにしています。VPC はオンプレミス環境と接続されており、接続の中断はありません。Auto Scaling グループの最大インスタンス数は 20 です。VPC の IPv4 アドレスは次の通りです：

VPC CIDR: 10.0.0.0/23

AZ1 サブネット CIDR: 10.0.0.0/24

AZ2 サブネット CIDR: 10.0.1.0/24

展開後、リージョンに 3 番目の AZ が利用可能になりました。ソリューションアーキテクトは、追加の IPv4 アドレス空間を使わず、サービスのダウンタイムなしで新しい AZ を採用したいと考えています。この要件に最も適した解決策はどれですか？

A. Auto Scaling グループを AZ2 サブネットのみを使用するように更新します。AZ1 サブネットを削除して再作成し、元のアドレス空間の半分を使用します。Auto Scaling グループが新しい AZ1 サブネットを使用するように調整します。インスタンスが正常であれば、Auto Scaling グループを AZ1 サブネットのみを使用するように調整します。現在の AZ2 サブネットを削除し、元の AZ1 サブネットのアドレス空間の後半を使用して新しい AZ2 サブネットを作成します。元の AZ2 サブネットのアドレス空間の半分を使って新しい AZ3 サブネットを作成し、Auto Scaling グループをすべての新しいサブネットをターゲットにするように更新します。

B. AZ1 サブネット内の EC2 インスタンスを終了します。AZ1 サブネットを削除して再作成し、アドレス空間の半分を使用します。Auto Scaling グループを新しいサブネットに更新します。この操作を 2 番目の AZ に対しても繰り返します。AZ3 に新しいサブネットを作成し、Auto Scaling グループを 3 つの新しいサブネットをターゲットにするように更新します。

C. 同じ IPv4 アドレス空間を持つ新しい VPC を作成し、各 AZ に 1 つずつサブネットを定義します。既存の Auto Scaling グループを更新して、新しい VPC のサブネットをターゲットにします。

D. Auto Scaling グループを AZ2 サブネットのみを使用するように更新します。AZ1 サブネットを更新し、アドレス空間の半分を使います。Auto Scaling グループを AZ1 サブネットを使うように調整します。インスタンスが正常であれば、Auto Scaling グループを AZ1 サブネットのみを使用するように調整します。現在の AZ2 サブネットを更新し、元の AZ1 サブネットのアドレス空間の後半を割り当てます。元の AZ2 サブネットのアドレス空間の半分を使って新しい AZ3 サブネットを作成し、Auto Scaling グループをすべての新しいサブネットをターゲットにするように更新します。

解説

この問題では、既存の VPC に新しいアベイラビリティゾーン（AZ）が追加され、その AZ を追加するために必要な変更を検討しています。要求事項としては、追加のIPv4アドレス空間を使用せず、サービスのダウンタイムなしで新しい AZ を採用することです。

以下に各選択肢の解説を行います。

A の解説

選択肢 A は、既存のサブネットを変更して新しい AZ を利用する方法です。この選択肢では、以下のように進めます：

AZ2 サブネットのみを使用するように Auto Scaling グループを更新し、次に AZ1 サブネットを更新します。これにより、サービスがダウンしないように段階的に進めることができます。

元の AZ1 サブネットを削除して半分のアドレス空間を使い、新しい AZ1 サブネットを作成します。

AZ2 サブネットの後半のアドレス空間を使って新しい AZ2 サブネットを作成します。

最後に、新しい AZ3 サブネットを作成して、Auto Scaling グループがすべての新しいサブネットをターゲットにするように更新します。

これにより、新しい AZ を追加するために 既存のサブネットの変更や新しいサブネットの作成を行うことができます。重要なのは、この方法では既存のアドレス空間内で新しい AZ を追加し、サービスのダウンタイムなしで変更を進める点です。

B の解説

選択肢 B は、まず既存のインスタンスを終了して、新しいサブネットを作成し、Auto Scaling グループを更新する方法です。これにより、サービスが停止し、インスタンスの再起動が必要になります。また、手順としても非常に煩雑で、ダウンタイムが発生する可能性が高いです。従って、ダウンタイムなしという要件には適していません。

C の解説

選択肢 C は、新しい VPC を作成して、既存の Auto Scaling グループを新しい VPC に移行する方法です。この方法では、完全に新しい VPC を作成するため、既存のリソースやサブネットの設定を再構成し直さなければなりません。さらに、既存の EC2 インスタンスやネットワーク設定の移行には時間と手間がかかり、ダウンタイムが避けられないため、最も運用負荷が高い方法です。

D の解説

選択肢 D は、選択肢 A と似ていますが、Auto Scaling グループを調整する際にインスタンスを停止しないような手順となっています。ステップとしては、AZ1 サブネットとAZ2 サブネットを順番に更新し、その後 AZ3 サブネットを作成します。ただし、この方法でも、アドレス空間の管理やサブネットの変更に時間がかかり、他の選択肢と比べて最も手順が多いため、他の方法より複雑です。

結論

最も適切な解決策は A です。選択肢 A は、新しい AZ を追加するための最も効率的な方法で、既存の VPC 内で作業を行い、サービスのダウンタイムなしで新しい AZ を導入できるからです。

294-AWS SAP AWS 「理論・実践・一問道場」チャージバックモデル

理論

チャージバックモデルとは、企業や組織が使ったリソース（例えば、コンピュータやサーバー、クラウドサービス）に対して、どの部署やチームがどれくらい使ったのかを計算し、その分の料金を請求する仕組みです。

例で説明します：

例えば、会社で複数の部署がクラウドサービス（AWSなど）を使っているとします。それぞれの部署がサーバーを使ったり、データを保存したりします。チャージバックモデルを使うと、各部署は自分たちが使った分だけ料金を支払うことになります。

なぜこれが重要なのか：

公平性：各部署が使ったリソースに応じて料金を支払うので、無駄にリソースを使わなくなります。

コスト管理：各部署が自分の使っているリソースに対して責任を持つことで、コストを意識して使うようになります。

メリット：

各部署のリソース使用量が明確になる

使った分だけ支払うので、無駄を減らせる

各部署がリソースの使い方を見直すようになる

デメリット：

リソース使用量を追跡するための管理が少し手間

料金を支払うことに対して不満が出ることもある

まとめ：チャージバックモデルは、各部署が使ったリソースに応じて料金を請求する仕組みで、リソースを効率的に使い、コストを管理するのに役立ちます。

タグの使用と管理におけるベストプラクティス

AWSでは、リソースに「タグ」を設定することで、コストの追跡やリソースの管理が容易になります。タグはキーと値のペアで設定でき、リソースに関する情報（例えば、プロジェクト名、部門、所有者など）を追跡するために使用されます。タグを適切に設定することは、以下のような目的に役立ちます。

コスト管理: AWS Cost ExplorerやAWS Cost and Usage Reportを使用して、リソースごとのコストをタグに基づいて分析することができます。これにより、どの部門やプロジェクトがどれだけのコストを発生させているかを把握し、コスト最適化の手助けとなります。

リソース管理: タグを利用してリソースをグループ化し、リソースの所有者や関連するプロジェクトに基づいて整理できます。これにより、リソースの管理が簡素化され、運用が効率的になります。

セキュリティとコンプライアンス: タグを利用して特定のリソースのアクセス制御を行うことができます。例えば、特定のタグを持つリソースに対して特別なアクセス許可を設定したり、タグに基づいて監査を実施することができます。

タグの強制方法

AWSでは、リソースにタグを必須化する方法がいくつか提供されています。特に、AWS Organizationsやサービスコントロールポリシー（SCP）、タグポリシーなどが有効です。

1. タグポリシー (Tag Policies)

タグポリシーを使用すると、AWS Organizations内でタグの設定を強制することができます。これにより、組織全体で一貫性のあるタグ付けを強制でき、特定のリソースに必要なタグを設定することができます。タグポリシーは、以下のようなタグ付けルールを定義できます。

タグキーと値: どのタグキーとその値が有効かを定義できます。

タグの付与の義務化: 特定のリソースタイプに対してタグ付けを必須化できます。

2. サービスコントロールポリシー (SCP)

サービスコントロールポリシーは、AWS Organizations内でリソース作成や操作を制限するために使用されます。SCPを使用して、リソース作成時に特定のタグが必要であることを強制することができます。例えば、cloudformation:CreateStackのようなAPI操作を制限し、タグが適切に付与されていない場合、操作が拒否されるように設定できます。

3. IAMポリシー

IAMポリシーを使用して、特定のアクション（例：cloudformation:CreateStack）を実行する際に必要なタグが付与されていない場合、操作を拒否することができます。この方法は、特定のユーザーやロールに対して個別にポリシーを適用する場合に有効です。

4. AWS Service Catalog

AWS Service Catalogを使用して、CloudFormationスタックを管理する方法もあります。Service Catalogでは、タグをオプションとして設定することができます。リソースの作成時にタグを強制する設定が可能で、これを利用してタグの一致を制御できます。

コスト管理のためのタグの活用

AWSのタグは、リソースのコスト管理にも非常に有用です。AWS Cost ExplorerやCost and Usage Reportでは、タグを使用してコストをフィルタリングし、どのプロジェクトや部門がどれだけのリソースを消費しているかを詳細に追跡することができます。これにより、リソース使用状況を把握し、適切なコスト最適化策を講じることができます。

まとめ

AWSリソースにタグを適切に設定し、それを強制する方法にはいくつかの選択肢があります。タグポリシーやサービスコントロールポリシーを利用することで、タグの一貫性を維持し、リソース管理やコスト管理を効率的に行うことができます。特に、課金モデルに基づいてリソースを管理する場合、タグは非常に強力なツールとなり、コストの最適化に役立ちます。

実践

略

一問道場

質問 #294

ある企業は、AWS Organizationsを使用してAWSアカウントを管理しています。また、企業はAWS CloudFormationを使用してすべてのインフラをデプロイしています。財務チームはチャージバックモデルを構築したいと考えており、各事業部門に対して事前に定義されたプロジェクト値のリストを使ってリソースにタグを付けるよう依頼しました。財務チームは、AWS Cost ExplorerのAWS Cost and Usage Reportを使ってプロジェクト別にフィルタリングした際に、非準拠のプロジェクト値を見つけました。企業は新しいリソースにプロジェクトタグを必須にしたいと考えています。

この要件を最も労力をかけずに満たす方法はどれですか？

A. 組織の管理アカウントで、許可されたプロジェクトタグの値を含むタグポリシーを作成します。cloudformation:CreateStack API操作でプロジェクトタグが付与されていない場合、その操作を拒否するSCPを作成します。このSCPを各OUに適用します。

B. 各OUで許可されたプロジェクトタグの値を含むタグポリシーを作成します。cloudformation:CreateStack API操作でプロジェクトタグが付与されていない場合、その操作を拒否するSCPを作成します。このSCPを各OUに適用します。

C. AWS管理アカウントで許可されたプロジェクトタグの値を含むタグポリシーを作成します。cloudformation:CreateStack API操作でプロジェクトタグが付与されていない場合、その操作を拒否するIAMポリシーを作成します。このポリシーを各ユーザーに適用します。

D. AWS Service Catalogを使ってCloudFormationスタックを製品として管理します。タグオプションライブラリを使用してプロジェクトタグの値を制御します。このポートフォリオを組織内のすべてのOUと共有します。

解説

この問題では、企業がプロジェクトタグの準拠を強制したいという要件に対して、最も労力をかけずに実現できる方法を選択する必要があります。各選択肢について解説します。

A. タグポリシーとSCPの組み合わせ

タグポリシー: 組織の管理アカウントでタグポリシーを作成し、許可されたプロジェクトタグの値を定義します。これにより、すべてのAWSリソースに適切なタグが付けられることが保証されます。

SCP: cloudformation:CreateStack API操作に関して、プロジェクトタグが付与されていない場合、その操作を拒否するサービスコントロールポリシー（SCP）を作成し、各OUに適用します。これにより、新しいリソースが作成される際に必ずプロジェクトタグが付与されることを強制できます。

このアプローチは、最小限の労力でタグの遵守を強制する方法として効果的です。タグポリシーで具体的なタグの値を定義し、SCPで操作を制限するため、管理の負担が少なく、効率的です。

B. 各OUでタグポリシーを作成し、SCPで制限

タグポリシー: 各OUごとにタグポリシーを作成する必要があります。これにより、各OUに対して異なるタグポリシーを適用することが可能ですが、管理の手間が増える可能性があります。

SCP: Aと同じように、SCPを利用してcloudformation:CreateStack操作にプロジェクトタグがない場合、リソース作成を拒否します。

この方法も効果的ですが、管理の手間が増え、Aよりも少し複雑になります。

C. タグポリシーとIAMポリシーの組み合わせ

タグポリシー: 管理アカウントで許可されたプロジェクトタグを定義する点はAと同様です。

IAMポリシー: 各ユーザーに対してIAMポリシーを作成し、cloudformation:CreateStack API操作がプロジェクトタグを持っていない場合、その操作を拒否します。

この方法は、ユーザーごとに個別のポリシーを設定する必要があり、管理が煩雑になるため、AとBよりも手間がかかります。

D. AWS Service Catalogとタグオプションライブラリの使用

AWS Service Catalog: CloudFormationスタックを製品として管理し、タグオプションライブラリを使用してタグの管理を制御する方法です。これにより、事前に定義されたプロジェクトタグが適用されますが、Service Catalogを利用する設定が必要です。

タグオプションライブラリ: タグの管理を簡単にするためのオプションですが、Service Catalogの使用自体が少し高度であり、特にリソースの管理に慣れていないチームにとっては複雑かもしれません。

この方法は、他の選択肢と比べてやや手間がかかる可能性があり、最も簡単な方法ではありません。

最適解

Aが最も労力をかけずに要件を満たす解決策です。タグポリシーを使って一貫性を確保し、SCPでプロジェクトタグの付与を強制することで、管理負担を最小限に抑えつつ、タグの遵守を確実にすることができます。

295-AWS SAP AWS 「理論・実践・一問道場」

理論

1. Amazon EC2 インスタンスの選定

Amazon EC2 (Elastic Compute Cloud) インスタンスは、仮想サーバーとしてクラウド内で実行される計算リソースです。アプリケーションに最適なインスタンスタイプを選択することは、コスト削減とパフォーマンスの最適化において非常に重要です。

インスタンスタイプの選び方:

CPU、メモリ、ストレージの要件を把握: アプリケーションの性能要件に基づき、必要なリソース（CPU、メモリ、ディスク）を特定します。例えば、データベースや計算集約型のアプリケーションでは、CPU性能やメモリ容量が重要となります。

コスト対効果の分析: インスタンスタイプにはさまざまな価格帯があり、最も高いパフォーマンスを提供するインスタンスを選ぶことが必ずしもコスト効率が良いわけではありません。過剰なリソースを避け、適切なインスタンスを選択することが重要です。

2. Auto Scaling の活用

Auto Scaling は、アプリケーションの需要に応じて EC2 インスタンスの数を自動的に調整する機能です。これにより、トラフィックの増加や減少に対応してリソースをスケールすることができます。

Auto Scaling グループの設計と運用のベストプラクティス:

適切なスケーリングポリシーの設定: Auto Scaling グループでは、スケールイン（インスタンス数の減少）とスケールアウト（インスタンス数の増加）のポリシーを設定できます。トラフィックの急増に対応できるように、スケールアウトのポリシーを設定し、リソースが過剰に使用される前に新しいインスタンスを立ち上げます。

CloudWatch メトリクスの監視: EC2 のリソース使用率（CPU 使用率やメモリ使用率）をモニタリングし、Auto Scaling ポリシーをトリガーします。これにより、負荷に応じたスケーリングが自動的に行われ、コストの最適化とパフォーマンスの維持が実現します。

3. 最適なインスタンスタイプの選定方法

インスタンスタイプはさまざまなカテゴリーに分かれています。用途に応じて最適なタイプを選択することが重要です。以下は代表的なインスタンスタイプです。

汎用型 (General Purpose):

t3, m5 など。バランスの取れた CPU、メモリ、ネットワーク性能を提供。
一般的なウェブアプリケーションや開発環境に適している。

コンピューティング最適化型 (Compute Optimized):

c5 など。高い CPU パフォーマンスが必要な計算集約型アプリケーションに適している。
データ解析や大規模なバックエンド処理に使用。

メモリ最適化型 (Memory Optimized):

r5, x1e など。メモリ容量が大きく、メモリ集約型のアプリケーションに最適。
高速キャッシュ、インメモリデータベースなどに利用される。

ストレージ最適化型 (Storage Optimized):

i3, d2 など。大規模なデータ処理やストレージが必要なアプリケーションに最適。
高速なローカルストレージを提供。

GPU インスタンス (Accelerated Computing):

p3, g4 など。機械学習やディープラーニング、グラフィックス処理に特化している。

4. Auto Scaling グループの最適化

Auto Scaling グループを効果的に管理するためには、以下のポイントに注意することが重要です。

インスタンスタイプの多様性を持たせる: 特に利用率が低い場合、複数のインスタンスタイプを Auto Scaling グループで使用することが有効です。例えば、少しリソースが少ないインスタンスタイプを使用してコストを削減することができます。

インスタンスの最適化: 必要なリソースの過不足を防ぐために、利用率が低いインスタンスを削減し、より適切なインスタンスに切り替えることが求められます。

スケーリングポリシーの調整: リソース使用量のモニタリングを基に、インスタンス数の自動調整が行われます。負荷に応じて適切にスケールイン/スケールアウトを設定することが重要です。

5. Cost Optimization の手法

EC2 コスト削減のための方法として、以下の手法があります。

スポットインスタンスの利用: 需要が低い時に提供されるスポットインスタンスを利用することで、コストを大幅に削減できます。

リザーブドインスタンスの利用: 長期間にわたって特定のインスタンスを使用する予定がある場合、リザーブドインスタンスを選択することで、コストを予測可能にし、割引を受けることができます。

スケーリングポリシーによる効率化: 自動スケーリングにより、必要なリソースのみを使用することで、無駄なコストを削減できます。

これらの知識を活用することで、EC2 のインスタンス選定や Auto Scaling の最適化を通じて、効率的な運用とコスト削減を実現できます。

実践

略

一問道場

問題 #295

トピック 1

あるアプリケーションが、Amazon EC2 インスタンスにデプロイされており、Auto Scaling グループで実行されています。Auto Scaling グループの設定は、1 種類のインスタンスのみを使用しています。CPU とメモリの利用率のメトリクスから、インスタンスが過少利用されていることがわかります。ソリューションアーキテクトは、EC2 コストを恒久的に削減し、利用率を向上させるソリューションを実装する必要があります。将来的に構成変更の回数を最小限に抑えながら、この要件を満たすソリューションはどれですか？

A. 現在のインスタンスと似た特性を持つインスタンスタイプをリストアップし、そのリストから複数のインスタンスタイプを使用するように Auto Scaling グループのローンチテンプレート構成を変更する。

B. アプリケーションの CPU およびメモリ利用率の情報を使用して、要件に合ったインスタンスタイプを選択する。新しいインスタンスタイプを追加し、Auto Scaling グループの構成を変更する。現在のインスタンスタイプは構成から削除する。

C. アプリケーションの CPU およびメモリ利用率の情報を使用して、Auto Scaling グループのローンチテンプレートの新しいリビジョンに CPU およびメモリ要件を指定する。現在のインスタンスタイプは構成から削除する。

D. AWS Price List Bulk API から適切なインスタンスタイプを選択するスクリプトを作成する。選択したインスタンスタイプを使用して、Auto Scaling グループのローンチテンプレートの新しいリビジョンを作成する。

解説

この問題は、Auto Scaling グループにおける EC2 コストの削減とインスタンスの効率的な利用を目指すソリューションを求めています。解説を行いながら、それぞれの選択肢を確認しましょう。

各選択肢の評価

この選択肢は、複数のインスタンスタイプを使用するアプローチですが、インスタンスの利用率が過少であることがわかっている場合に、特性の似たインスタンスを選ぶだけでは最適なコスト削減が達成できません。CPU とメモリの利用率が低いという問題を解決するためには、インスタンスタイプをより適切なものに変更する方が良いでしょう。

不適切

これは、現行のインスタンスタイプが過剰にリソースを提供していることを前提に、適切なインスタンスタイプに変更するアプローチです。この方法はインスタンスのコスト削減と利用率の向上に有効です。新しいインスタンスタイプの追加後、既存のインスタンスタイプを削除するため、構成変更が最小限で済みます。

適切

この選択肢では、インスタンスタイプそのものではなく、CPU とメモリの要件を指定するというアプローチです。しかし、Auto Scaling グループではインスタンスタイプの選定が必要であり、CPU とメモリの単独設定だけでは十分に効果的ではありません。

不適切

AWS Price List Bulk API を使用してインスタンスタイプを選定する方法は、コスト削減を狙う場合には適切なアプローチに思えるかもしれませんが、コスト以外の要素（CPU とメモリの利用状況）に基づく最適化が十分に行われない可能性があります。コスト削減は重要ですが、アプリケーションのパフォーマンス要件も考慮する必要があります。

不適切

正しい答え

Bが最も適切な選択肢です。アプリケーションの利用率情報を基に最適なインスタンスタイプを選択し、Auto Scaling グループを効率的に構成することで、コスト削減と利用率向上を実現できます。

296-AWS SAP AWS 「理論・実践・一問道場」AWS Backup

理論

1. バックアップのスケジュール設定と管理の簡便さ

AWS Backupは、AWSリソース（例えば、Amazon AuroraやDynamoDB）のバックアップを自動化し、スケジュールに基づいて定期的にバックアップを作成できます。これにより、手動でバックアップを作成する必要がなく、運用負担を軽減できます。

2. コスト効率

AWS Backupは、バックアップのストレージに関連するコストを最小限に抑えることができます。特に、復旧時間が緩い場合や、バックアップデータをセカンダリリージョンに保存する場合に、低コストで確実なバックアップを提供します。

データがセカンダリリージョンで使用される頻度が低ければ、コストはさらに低く抑えられます。

3. 復旧時間が緩いケース

RTOが緩い場合、すぐにシステムを復旧する必要がないため、バックアップからの復旧で十分対応可能です。この場合、バックアップデータを手動または一部自動的にリストアすることで、復旧するまでの時間を柔軟に設定できます。

4. バックアップの保存場所

AWS Backupは、バックアップデータを異なるリージョンに保存することができるため、災害時には別のリージョンから復旧することができます。この機能により、シンプルなバックアップ戦略で高可用性を確保できますが、リアルタイムでのレプリケーションを必要とするシナリオには向いていません。

5. ディザスタリカバリの簡易化

システム全体のバックアップを管理し、復旧作業を効率的に行うためのツールを提供しますが、即座に復旧するための高可用性やレプリケーションが要求されるシステムには向かない場合もあります。

適用ケース：

復旧が緩いプロジェクトや、予算を抑えつつシンプルな災害復旧が求められる場合にはAWS Backupが最適です。例えば、データベースのバックアップを定期的に取得し、問題発生時に少し時間をかけてリストアすることが許容されるシナリオには適しています。

まとめ：

AWS Backupは、復旧時間や復旧ポイントに厳しい要件がない場合に非常に有効な選択肢です。コストを抑えながらシンプルで効果的なバックアップソリューションを提供し、復旧が緩いケースに適しています。

実践

略

一問道場

問題 #296

トピック 1

ある企業は、Amazon Elastic Container Service（Amazon ECS）とAmazon API Gatewayを使用してコンテナ化されたアプリケーションを実装しています。アプリケーションデータはAmazon AuroraデータベースとAmazon DynamoDBデータベースに保存されています。企業はAWS CloudFormationを使用してインフラのプロビジョニングを自動化し、AWS CodePipelineを使用してアプリケーションのデプロイを自動化しています。

ソリューションアーキテクトは、RPO（復旧ポイント目標）2時間、RTO（復旧時間目標）4時間を満たす災害復旧（DR）戦略を実装する必要があります。

どのソリューションが最もコスト効果的にこれらの要件を満たしますか？

A. AuroraグローバルデータベースとDynamoDBグローバルテーブルを設定して、データベースをセカンダリAWSリージョンにレプリケートします。プライマリリージョンとセカンダリリージョンで、Regionalエンドポイントを持つAPI Gateway APIを構成します。DRシナリオ時にセカンダリリージョンへのトラフィックをルーティングするためにAmazon CloudFrontのオリジンフェイルオーバーを実装します。

B. AWS Database Migration Service（AWS DMS）、Amazon EventBridge、AWS Lambdaを使用して、AuroraデータベースをセカンダリAWSリージョンにレプリケートします。DynamoDBデータベースをセカンダリリージョンにレプリケートするためにDynamoDB Streams、EventBridge、Lambdaを使用します。プライマリリージョンとセカンダリリージョンで、Regionalエンドポイントを持つAPI Gateway APIを構成します。Amazon Route 53フェイルオーバールーティングを実装して、プライマリリージョンからセカンダリリージョンへのトラフィックの切り替えを行います。

C. AWS Backupを使用してAuroraデータベースとDynamoDBデータベースのバックアップをセカンダリAWSリージョンに作成します。プライマリリージョンとセカンダリリージョンで、Regionalエンドポイントを持つAPI Gateway APIを構成します。Amazon Route 53フェイルオーバールーティングを実装して、プライマリリージョンからセカンダリリージョンへのトラフィックの切り替えを行います。

D. AuroraグローバルデータベースとDynamoDBグローバルテーブルを設定して、データベースをセカンダリAWSリージョンにレプリケートします。プライマリリージョンとセカンダリリージョンで、Regionalエンドポイントを持つAPI Gateway APIを構成します。Amazon Route 53フェイルオーバールーティングを実装して、プライマリリージョンからセカンダリリージョンへのトラフィックの切り替えを行います。

正解

正解は C です。

選択肢Cでは、AWS Backupを使用してAuroraとDynamoDBのバックアップを別リージョンに保存し、RPO（復旧ポイント目標）2時間、RTO（復旧時間目標）4時間の要件を満たすコスト効率の良い方法を提供します。この方法では、バックアップからの迅速な復元が可能で、要件に適合します。

297-AWS SAP AWS 「理論・実践・一問道場」CloudFrontキャッシュヒット率を向上

理論

CloudFrontキャッシュヒット率を向上させる方法

Amazon CloudFrontは、アプリケーションのパフォーマンスを向上させるために使用されるコンテンツ配信ネットワーク（CDN）です。しかし、設定や実装が適切でない場合、キャッシュヒット率が低下し、期待通りのパフォーマンスが得られないことがあります。本記事では、CloudFrontのキャッシュヒット率を向上させるための汎用的な知識を解説します。

キャッシュヒット率とは？

キャッシュヒット率は、CloudFrontエッジロケーションがリクエストに応じてキャッシュ済みコンテンツを提供できた割合を示します。キャッシュヒット率が高いほど、エンドユーザーのリクエストを迅速に処理でき、オリジンサーバーの負荷も軽減されます。

キャッシュヒット率が低下する原因

クエリ文字列の不規則性

クエリ文字列が異なる順序で指定されたり、大小文字が混在していると、CloudFrontは異なるリクエストとして扱います。

例: example.com/page?key1=value1&key2=value2 と example.com/page?key2=value2&key1=value1 は別々にキャッシュされる。

Cookieやヘッダーの不要なバリエーション

キャッシュキーに含まれるCookieやHTTPヘッダーが多すぎる場合、同じコンテンツであっても異なるリクエストとして処理されます。

頻繁なコンテンツ更新

キャッシュされたオブジェクトが頻繁に更新されると、キャッシュの利用率が低下します。

TTL（Time To Live）が短すぎる

オブジェクトのキャッシュ期間が短い場合、キャッシュが有効な期間が限られるため、ヒット率が低下します。

キャッシュヒット率を向上させる方法

1. クエリ文字列の正規化

クエリ文字列の順序や大小文字を統一することで、同一のリクエストがキャッシュに一致するようにします。

解決方法: Lambda@Edgeを利用して、リクエストのクエリ文字列を正規化します。

クエリパラメータを名前順に並べ替え。
小文字に変換。

2. キャッシュキーの最適化

キャッシュキーに含める要素を最小限に抑えます。

設定変更:

必要ないCookieやヘッダーをキャッシュキーから除外。
クエリ文字列の特定のパラメータのみをキャッシュキーに含める。

3. TTLの調整

キャッシュの有効期間（TTL）を適切に設定します。

長期間変更がない静的コンテンツには長いTTLを設定。

動的コンテンツには短いTTLを設定するか、キャッシュ無効化を検討。

4. CloudFrontのキャッシュ行動を制御

CloudFrontの設定を調整して、不要なバリエーションを減らします。

クエリ文字列の大文字小文字を区別しないように設定。

必要に応じて、Origin Request Policyを活用してリクエスト属性を制御。

5. Cache Invalidationの最小化

頻繁なキャッシュ無効化（Invalidation）はキャッシュの有効性を低下させます。必要な場合のみInvalidateを実行し、影響を限定します。

6. 圧縮と圧縮ヘッダーの統一

圧縮されたバージョン（gzipやbrotli）がキャッシュに影響を与えないように、圧縮関連のヘッダーを統一します。

実践例: Lambda@Edgeを使った正規化

以下は、Lambda@Edgeを利用してクエリ文字列を正規化する例です。

Node.jsコード例

適用手順

AWS Lambdaでコードを作成。

Lambda@EdgeのトリガーをCloudFrontの「ビューワリクエスト」に設定。

デプロイ後、キャッシュヒット率をモニタリング。

まとめ

CloudFrontのキャッシュヒット率は、Webアプリケーションのパフォーマンスに直結します。

短期的な対応: Lambda@Edgeでクエリ文字列を正規化。

長期的な最適化: キャッシュキーやTTLの設定を見直し、キャッシュ行動を効率化。

これらの方法を活用することで、キャッシュヒット率を向上させ、エンドユーザーの体験を向上させることができます。

実践

略

一問道場

問題 #297

トピック1

ある企業が、グローバルなスケーラビリティとパフォーマンス向上のためにAmazon CloudFrontを活用した複雑なWebアプリケーションを運用しています。しかし、時間が経つにつれてユーザーから「アプリケーションが遅くなっている」との報告が寄せられるようになりました。

運用チームの調査によると、CloudFrontのキャッシュヒット率が徐々に低下していることが判明しました。キャッシュのメトリクスレポートを見ると、一部のURLでクエリ文字列の順序が不規則で、時には大文字と小文字が混在していることや、小文字だけで指定されることがあることがわかりました。

キャッシュヒット率をできるだけ早く改善するには、ソリューションアーキテクトはどの対応を取るべきでしょうか？

A. Lambda@Edgeを利用して、クエリパラメータを名前順に並べ替え、小文字に統一する関数をデプロイします。この関数はCloudFrontのビューワリクエストトリガーで実行されるように設定します。

B. CloudFrontディストリビューションの設定を更新して、クエリ文字列パラメータを使ったキャッシュを無効化します。

C. ロードバランサーの後ろにリバースプロキシを配置し、アプリケーションで生成されるURLを処理して、小文字に統一します。

D. CloudFrontディストリビューションの設定を更新し、クエリ文字列を大文字小文字を区別しない形で処理するよう指定します。

解説

この問題では、Amazon CloudFrontのキャッシュヒット率を向上させるための最適な方法を検討します。キャッシュヒット率の低下は、クエリ文字列が不規則な順序で、大小文字が混在していることが原因です。以下に各選択肢について解説します。

A. Lambda@Edgeを利用して、クエリパラメータを並べ替え、小文字に統一する

概要: Lambda@Edgeを使い、CloudFrontのリクエスト時にクエリ文字列を名前順に並べ替え、小文字に統一します。これにより、同じURLが常に一貫した形式でキャッシュに保存されるようになります。

利点:

リアルタイムでリクエストを正規化するため、キャッシュヒット率が大幅に改善されます。
クライアントやバックエンドに変更を加える必要がありません。

適用性: クエリ文字列がバラバラな順序や大小文字の違いでキャッシュが効かない場合、最も直接的で効率的な解決策です。

結論: 最適な選択肢。

B. CloudFrontディストリビューションを更新して、クエリ文字列パラメータを使ったキャッシュを無効化する

概要: クエリ文字列を無視して、すべてのリクエストを同じキャッシュエントリにマッピングします。

利点:

クエリ文字列が異なる場合でもキャッシュが効くようになります。

欠点:

クエリ文字列に応じた応答（例: 検索やフィルタリング結果）が異なる場合、正しいレスポンスが返されなくなります。

適用性: クエリ文字列が結果に影響を与えない場合には有効ですが、今回のケースでは不適切です。

結論: 不適切。

C. ロードバランサーの後ろにリバースプロキシを配置し、URLを小文字に統一する

概要: アプリケーション側でリバースプロキシを導入し、すべてのリクエストURLを小文字に変換します。

利点:

クエリ文字列の一貫性を保てる。

欠点:

新しいインフラ（リバースプロキシ）の導入にコストと時間がかかります。
CloudFrontのキャッシュレベルで解決する方が効率的。

適用性: アプリケーション側で制御が必要な場合には有効ですが、今回はCloudFrontで対応する方が適切です。

結論: 非効率的で不適切。

D. CloudFrontディストリビューションを更新し、クエリ文字列を大小文字区別なしで処理する

概要: CloudFrontの設定を変更して、大小文字を区別しない形でクエリ文字列を処理します。

利点:

大小文字の違いによるキャッシュミスを防ぐ。

欠点:

クエリ文字列の順序の違いには対応できません。
ヒット率の向上が限定的。

適用性: クエリ文字列が大小文字だけの違いで不一致を起こしている場合には有効ですが、今回はそれ以上の問題（順序の違い）があるため不十分です。

結論: 部分的には有効ですが、最適解ではありません。

結論: Aが最適解

Lambda@Edgeを使用してクエリ文字列を正規化する方法が、今回のケースにおいて最も効率的で効果的です。キャッシュヒット率を最大限に向上させるために、大小文字や順序の違いをすべて統一する処理をCloudFrontのリクエストレベルで行えるためです。

298-AWS SAP AWS 「理論・実践・一問道場」DMSでCDCタスク

理論

災害復旧（Disaster Recovery）におけるデータレプリケーションの戦略

災害復旧（Disaster Recovery, DR）は、自然災害やシステム障害などの予期せぬ事態に備え、システムやデータを迅速に復旧するための計画や実装を指します。ここでは、AWSを活用した低コストで効果的なDR戦略に焦点を当てます。

基本用語

RPO（Recovery Point Objective）: データが失われても許容できる時間の最大値。例えば、RPOが1時間の場合、復旧時に最大1時間分のデータ損失が許容される。

RTO（Recovery Time Objective）: システムやサービスを復旧するのに必要な時間。例えば、RTOが1時間の場合、サービスが停止しても1時間以内に復旧する必要がある。

AWSを活用したデータレプリケーション手法

1. Auroraグローバルデータベース

概要: Auroraグローバルデータベースは、データを複数のAWSリージョン間でほぼリアルタイムに同期します。プライマリリージョンでの書き込み操作がセカンダリリージョンに1秒未満でレプリケートされます。

適用例: 高速な復旧（低RPO）が求められる場合。

利点:

レプリケーションが非常に高速。
セカンダリリージョンのデータを読み取り専用として活用可能。

欠点:

コストが高い。
高度な要件がない場合にはオーバースペックになることも。

2. AWS DMSを利用したデータレプリケーション

概要: AWS Database Migration Service（DMS）は、変更データキャプチャ（CDC）機能を使用して、データの継続的なレプリケーションを実現します。ターゲットとしてAmazon S3や別リージョンのデータベースを指定可能。

適用例: RPOが1時間程度で許容される場合、またはコスト効率が重視される場合。

利点:

低コスト。
柔軟なターゲット設定（例: S3, DynamoDB）。
運用が比較的簡単。

欠点:

レプリケーションには若干の遅延が発生する。
データ復元時に追加作業が必要な場合がある。

3. スナップショットとバックアップを利用

概要: AuroraやRDSの自動バックアップ機能を活用し、定期的にデータを他リージョンにコピーする。手動スナップショットの運用も可能。

適用例: データ復旧に即時性が求められない場合。

利点:

コストが非常に低い。
操作が簡単。

欠点:

データ損失が大きくなる可能性がある（RPOが長い）。
手動作業が多くなる場合がある。

低コストかつ効果的な選択肢の比較

手法	RPO	RTO	コスト	適用例
Auroraグローバルデータベース	数秒以内	数分	高い	ミッションクリティカルなアプリケーション
AWS DMS + CDC	数分～1時間	1時間程度	低い	災害復旧のコスト効率を重視したアプリケーション
スナップショットとバックアップ	数時間	数時間	非常に低い	データ損失のリスクが比較的許容されるシステム

実用的なアプローチ

要件に応じて選択:

ミッションクリティカルなシステムでは、Auroraグローバルデータベースが最適。
コスト効率を重視する場合は、AWS DMSを活用。
データ復元が迅速である必要がない場合は、スナップショットを利用。

モニタリング: Amazon CloudWatchやAWS Configを活用して、レプリケーションの状態やRPO/RTOの達成状況を監視。

定期的な演習: DR戦略を実行可能に保つために、定期的なテストを実施する。

まとめ

AWSではAuroraグローバルデータベース、AWS DMS、スナップショットなど、多様な手法を活用して災害復旧計画を構築できます。要件に応じて最適なソリューションを選択し、費用対効果を最大化することが重要です。

実践

略

一問道場

問題 #298

ある会社が、単一のAWSリージョンでECアプリケーションを運用しています。このアプリケーションは、Amazon Aurora MySQL DBクラスタ（5ノード）を使用して顧客情報や最近の注文情報を保存しています。このDBクラスタは、一日を通じて大量の書き込みトランザクションを処理します。

この会社は、Auroraデータベースのデータを別のリージョンに複製して、災害復旧要件を満たす必要があります。会社のRPO（復旧目標時点）は1時間です。

以下の解決策のうち、最も低コストでこの要件を満たすものはどれですか？

選択肢

A. AuroraデータベースをAuroraグローバルデータベースに変更し、別のリージョンに2つ目のAuroraデータベースを作成する。

B. AuroraデータベースにBacktrack機能を有効にする。AWS Lambda関数を作成して、データベースのスナップショットを別のリージョンに毎日コピーするように設定する。

C. AWS Database Migration Service（AWS DMS）を使用する。DMSの変更データキャプチャ（CDC）タスクを作成し、Auroraデータベースから別のリージョンのAmazon S3バケットに進行中の変更を複製する。

D. Auroraの自動バックアップを無効にする。バックアップの頻度を1時間に設定し、別のリージョンを宛先リージョンとして指定する。Auroraデータベースをリソース割り当てとして選択する。

解説

この問題の要件は以下の通りです：

災害復旧のためのデータレプリケーションが必要。

RPO（復旧目標時点）は1時間。これは、最大で1時間以内に失われたデータを復元できる必要があることを意味します。

最も低コストなソリューションを選択する必要がある。

各選択肢の解説

A. Auroraグローバルデータベースを利用する

Auroraグローバルデータベースは、複数のリージョン間でデータをほぼリアルタイムでレプリケートできます。このソリューションは、高い可用性と低いRPO（通常1秒未満）を提供しますが、グローバルデータベースのコストは高く、低コスト要件に適していません。

コスト: 高い

要件の適合性: RPO要件は満たすが、コストが最適でない。

B. Backtrack機能を有効にしてスナップショットをコピー

BacktrackはAurora MySQLのデータを特定の時点に「巻き戻す」機能で、通常、データ修復用に使用されます。ただし、Backtrack自体は別リージョンへのデータレプリケーションを提供しません。また、スナップショットのコピーをLambda関数で管理するソリューションは運用が複雑であり、リアルタイム性が不足してRPO 1時間を満たす可能性が低いです。

コスト: 中程度

要件の適合性: 複雑でRPO要件を満たしにくい。

C. AWS DMSでCDCタスクを使用

AWS Database Migration Service（DMS）は、Aurora MySQLのデータ変更（CDC: Change Data Capture）を検出し、指定されたターゲット（ここでは別リージョンのS3）にレプリケートできます。この方法は低コストであり、変更の追跡によりRPO 1時間以内を実現することも可能です。ただし、S3をターゲットに選んだ場合、直接のクエリは難しくなり、復旧時にデータをAuroraに戻す必要があります。

コスト: 低い

要件の適合性: コスト効率が高く、RPO要件を満たす。

D. Auroraの自動バックアップを無効にして手動バックアップを設定

この方法は、1時間ごとにデータをバックアップして別リージョンにコピーするものですが、バックアップのプロセス自体が遅く、RPO 1時間を満たす可能性が低いです。また、バックアップ復元のプロセスが手動で行われる可能性が高いため、災害復旧時に復元が遅れる可能性があります。

コスト: 低い

要件の適合性: RPO要件を満たしにくい。

正解: C. AWS DMSでCDCタスクを使用

このソリューションは以下の理由で最適です：

低コストである（DMSとS3を利用）。

RPO 1時間以内を満たすことが可能（CDCを使用したリアルタイムに近いレプリケーション）。

管理の複雑さが他の選択肢と比べて低い。

補足

Auroraグローバルデータベース（選択肢A）は最も高性能ですが、コストが高く、ローコストの要件に適していません。

RPOがさらに厳しい要件（例えば、数分以内）が求められる場合は、選択肢Aが選ばれる可能性があります。

299-AWS SAP AWS 「理論・実践・一問道場」AWS Systems Manager

理論

AWS EC2の高可用性アーキテクチャとスケーラビリティの実現方法

AWSで高可用性とスケーラビリティを実現するためには、適切なインフラストラクチャの設計が不可欠です。特に、Amazon EC2やAmazon Auroraなどのサービスを活用することで、アプリケーションの負荷に応じた柔軟な対応が可能になります。ここでは、EC2インスタンスのスケーラビリティを高め、ダウンタイムを減少させるための方法について紹介します。

1. EC2インスタンスのオートスケーリング

オートスケーリングは、アプリケーションのトラフィックや負荷に応じて、インスタンスを自動的に追加または削除するAWSの機能です。これにより、CPU使用率が高くなる場合に自動的に新しいインスタンスを起動し、トラフィックが減少するときにはインスタンスを縮小できます。

ポイント:

CPU使用率のモニタリング: EC2インスタンスのCPU使用率を監視し、一定のしきい値を超えるとスケーリングをトリガーする設定を行います。

Auto Scalingグループ: 複数のインスタンスをグループ化し、そのグループに基づいてスケーリングを行う設定をします。

2. Amazon Auroraの高可用性とスケーラビリティ

Amazon Auroraは、リレーショナルデータベースの管理をAWSが提供するサービスで、MySQLやPostgreSQLと互換性があります。高可用性、スケーラビリティ、そして自動バックアップ機能が組み込まれており、アプリケーションのパフォーマンスを向上させるために重要です。

Auroraの特長:

Multi-AZ展開: データベースインスタンスが複数のアベイラビリティゾーンに展開されるため、障害時にもアプリケーションの可用性を確保できます。

AuroraのAuto Scaling: Auroraは、ワークロードに応じて自動的に読み取り専用のインスタンスを追加することができ、リードスループットを向上させます。

Aurora Global Databaseを使用すれば、複数のリージョンでデータベースをレプリケートし、災害復旧を実現できます。

3. AMI (Amazon Machine Image) と Systems Managerを活用したパッチ管理

手動でパッチをインストールする場合、ダウンタイムが発生するリスクがあります。AWS Systems Managerを活用すれば、インスタンスのパッチを自動的に適用できます。特に、SSM (AWS Systems Manager) Agentを使用することで、インスタンスにリモートでアクセスし、パッチや構成の管理を一元化できます。

SSMを使用したパッチ管理のメリット:

ダウンタイムの削減: インスタンスを手動で停止せずにパッチを適用できます。

セキュリティとコンプライアンス: 定期的なパッチ適用を自動化することで、セキュリティリスクを低減できます。

4. AWS Auto Scalingと負荷分散 (Elastic Load Balancer)

*Elastic Load Balancer (ELB)**を使って、複数のEC2インスタンスにトラフィックを分散することができます。これにより、単一のEC2インスタンスに過度な負荷がかかるのを防ぎ、可用性を高めることができます。

ELBとAuto Scalingの連携:

トラフィック分散: ELBは、リクエストを適切にEC2インスタンスにルーティングします。

スケーリングポリシーの設定: Auto Scalingグループで設定したポリシーに基づき、ELBがトラフィックの負荷を新しいインスタンスに分配します。

5. マルチAZおよびマルチリージョン戦略

高可用性を確保するためには、複数のアベイラビリティゾーン(AZ)やリージョンにわたる展開が重要です。特に、Amazon Aurora Global DatabaseやCross-Region Replicationを使用することで、リージョン間での災害復旧も可能になります。

マルチAZの利点:

耐障害性: アベイラビリティゾーン障害にも耐えられる。

データの冗長化: データベースインスタンスのレプリケーションにより、データ損失を防ぎます。

マルチリージョンの利点:

災害復旧: 主要リージョンがダウンしても、別のリージョンから迅速にリカバリ可能。

地理的な最適化: ユーザーに最も近いリージョンでアプリケーションを提供できます。

まとめ

AWSのサービスを駆使して高可用性とスケーラビリティを実現するためには、Auto Scaling、Elastic Load Balancer、Auroraの可用性機能、そしてAWS Systems Managerなどの管理ツールを組み合わせることが効果的です。これらのサービスを適切に設計し、リソースを自動でスケールすることで、アプリケーションのパフォーマンスを最適化し、ダウンタイムを最小限に抑えることが可能です。

実践

略

一問道場

問題 #299

トピック 1

ある企業のソリューションアーキテクトが、数年前にデプロイされたAWSのワークロードを評価しています。

現在、アプリケーション層はステートレスで、1つの大きなAmazon EC2インスタンス上で動作しており、このインスタンスはAMIから起動されています。

アプリケーションはデータをMySQLデータベースに保存しており、このデータベースも1台のEC2インスタンス上で動作しています。

アプリケーションサーバーのEC2インスタンスはCPU使用率が頻繁に100%に達し、その結果、アプリケーションが応答しなくなることがあります。また、手動でパッチを適用しており、この作業が原因で過去にダウンタイムが発生しました。

企業は、このアプリケーションを高可用性にする必要があります。

最小限の開発時間で要件を満たすためのソリューションはどれですか？

A. アプリケーション層を既存のVPC内でAWS Lambda関数に移行します。Application Load Balancerを作成してLambda関数間でトラフィックを分散します。また、Lambda関数をスキャンするためにAmazon GuardDutyを使用します。データベースはAmazon DocumentDB（MongoDB互換）に移行します。

B. EC2インスタンスタイプをより小型でGraviton対応のものに変更します。既存のAMIを使ってAuto Scalingグループのローンチテンプレートを作成します。Application Load Balancerを構築して、Auto Scalingグループ内のインスタンス間でトラフィックを分散します。また、Auto ScalingグループがCPU使用率に基づいてスケールするように設定します。データベースはAmazon DynamoDBに移行します。

C. アプリケーション層をDockerを使ったコンテナに移行し、Amazon Elastic Container Service（Amazon ECS）で実行します。ECSはEC2インスタンス上で動作させます。Application Load Balancerを作成して、ECSクラスター内のトラフィックを分散します。ECSクラスターがCPU使用率に基づいてスケールするよう設定します。データベースはAmazon Neptuneに移行します。

D. AWS Systems Managerエージェント（SSMエージェント）を導入した新しいAMIを作成します。このAMIを使ってAuto Scalingグループのローンチテンプレートを作成し、小型のインスタンスを使用します。Application Load Balancerを作成して、Auto Scalingグループ内のインスタンス間でトラフィックを分散します。また、Auto ScalingグループがCPU使用率に基づいてスケールするように設定します。データベースはAmazon Aurora MySQLに移行します。

解説

この問題の焦点は、アプリケーションを高可用性にしつつ、開発コストを最小限に抑えることです。それぞれの選択肢について検討してみましょう。

A. AWS LambdaとAmazon DocumentDBへの移行

評価:

AWS Lambdaはステートレスなアプリケーションに適しており、インフラの管理を減らせます。しかし、既存のアプリケーションをLambda関数に移行するには、大幅なコード変更が必要です。
また、データベースをAmazon DocumentDBに移行することも開発コストが高く、MySQLとの互換性を損なう可能性があります。

結論: 大幅なコード変更が必要なため「開発時間が最小限」という要件に合いません。

B. Graviton対応の小型インスタンスとDynamoDBへの移行

評価:

Graviton対応のインスタンスを使用することでコスト効率は向上しますが、現在のCPU負荷を解消するためには小型インスタンスでは不十分です。
データベースをDynamoDBに移行する場合、リレーショナルデータベースであるMySQLから非リレーショナルデータベースへの移行が必要になり、大規模なアプリケーション変更が必要です。

結論: DynamoDBへの移行には高い開発コストがかかるため、不適切です。

C. DockerとAmazon ECSへの移行

評価:

Dockerを使ってアプリケーションをコンテナ化し、ECSで実行することでスケーラビリティを向上できます。
ただし、アプリケーションをコンテナに移行するには開発時間がかかり、データベースをAmazon Neptuneに移行することも大きな変更を必要とします。

結論: 大幅な設計変更が必要なため、「最小限の開発時間」に合致しません。

D. Auto ScalingグループとAurora MySQLへの移行

評価:

Auto Scalingグループを使用することで、CPU使用率に応じてインスタンスを自動的にスケールアウト/スケールインできます。これにより、現在の高負荷状態を解消し、高可用性を実現します。
新しいAMIにAWS Systems Managerエージェントを含めることで、手動パッチ作業を自動化し、ダウンタイムを削減できます。
Aurora MySQLは既存のMySQLと互換性があるため、データベース移行の開発コストを最小限に抑えつつ、高可用性とスケーラビリティを提供します。

結論: 最小限の開発時間で高可用性を実現できる最適な選択肢です。

正解: D

理由:

Auto ScalingグループとAurora MySQLを組み合わせることで、最小限の開発コストで高可用性とスケーラビリティを達成できます。

AWS Systems Managerエージェントを使用することで、運用タスクの効率化も可能です。