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

type

status

date

slug

summary

300-AWS SAP AWS 「理論・実践・一問道場」Athena port

理論

あるアプリケーションやシステムが依存している他のシステムやコンポーネントを、アプリケーション本体と一緒に同時に移行することを指します。これにより、移行後に依存関係が解消されないことによる問題（通信の遅延、データの不整合、アプリケーションの動作不良など）を防ぐことができます。

1. アプリケーションの依存関係の特定

アプリケーションをAWSに移行する際、アプリケーションが依存している他のサービスやコンポーネントを特定することが非常に重要です。これには以下の要素が含まれます：

データベース: アプリケーションがデータベースに依存している場合、データベースも同時に移行しないとシステムの整合性が崩れる。

外部サービス/API: サードパーティのサービスや内部APIが依存関係に含まれる場合、これらも同時に移行し、通信の問題を避ける必要があります。

2. 移行ツールの活用

AWSでは、依存関係を特定し、効率的に移行するために以下のツールが利用できます：

AWS Migration Hub: アプリケーションとその依存関係を可視化し、移行計画を立てるための中心的なツール。

AWS Application Discovery Service: 移行対象のインフラの依存関係を収集・分析するツール。

Network Access Analyzer: サーバー間の通信を分析し、依存関係を特定。

3. 同時移行の重要性

依存関係があるシステムを別々に移行すると、アプリケーションがデータベースに接続できない、外部APIとの通信に遅延が生じるなどの問題が発生する可能性があります。これを防ぐために、関連する全てのコンポーネントを一緒に移行することが推奨されます。

4. レイテンシとパフォーマンスの管理

移行時には、低レイテンシや高パフォーマンスが求められる依存関係もあります。例えば、ポート1000で通信を行うカスタムIPベースのプロトコルを使用するシステムでは、レイテンシが問題になるため、依存関係を同時に移行することが重要です。

Amazon Athenaでのデータ探索とクエリの活用

Amazon Athenaは、Amazon S3に格納されたデータに対してSQLクエリを実行するためのサービスです。Athenaはサーバーレスで運用されるため、インフラの管理が不要で、大量のデータに対して迅速にクエリを実行できます。Athenaを使ってサーバー間で転送されるデータを探索する方法について解説します。

1. Athenaの基本機能

Athenaは、S3に保存された構造化データ（CSV、Parquet、ORCなど）に対してクエリを実行できるサービスです。データはあらかじめS3にアップロードされ、Athenaを用いて直接SQLでクエリを実行できます。Athenaの特徴は以下の通りです：

サーバーレス: サーバーのセットアップや管理が不要で、クエリを実行するたびに必要なリソースが動的に提供されます。

SQLサポート: 標準的なSQLを使用してデータをクエリでき、熟練したDBAやアナリストがすぐに活用できます。

低コスト: クエリ実行ごとに課金されるため、使用した分だけのコストが発生します。

2. データ探索の有効化

Athenaを用いてデータ探索を行うためには、対象となるデータを事前にS3に保存し、Athenaにてクエリ可能な形式に変換しておく必要があります。例えば、サーバー間で転送されるデータ（例えばネットワークのログや通信データ）をAthenaで探索する場合、以下の手順が必要です：

データの収集と保存: サーバー間の通信データ（例えば、サーバーログやアクセスログ）をCloudWatch Logs、VPC Flow Logs、または他のソースからS3に送信します。このデータはAthenaで直接クエリできる形式に変換する必要があります。

Athenaテーブルの作成: Athenaでクエリを実行するためには、S3上のデータを参照するためのテーブルを作成します。例えば、サーバーログの形式に合わせて、CREATE EXTERNAL TABLE文を使用してテーブルを定義します。

データ探索の有効化: Athenaで「データ探索」を有効にするには、まずS3バケットからデータを指定し、クエリを実行できるように準備します。この時、ネットワークアクセスデータや通信データを含むログファイルなどを、Athenaで検索可能な形式に変換しておきます。

クエリ実行: Athenaでクエリを実行し、特定のポート（この場合はポート1000）で通信するサーバーを特定することができます。例えば、次のようなSQLクエリを使って、ポート1000で通信しているサーバーを検索します。

このクエリにより、ポート1000で通信しているサーバーやその通信履歴を特定できます。

3. Athenaの利用シナリオ

Athenaは、特に以下のシナリオに役立ちます：

ネットワークトラフィックの分析: サーバー間でどのようなデータがやり取りされているかを分析し、依存関係を特定する。

通信パターンの可視化: どのサーバーがどのサーバーと通信しているか、または特定のポート（例：ポート1000）で通信しているサーバーを特定する。

トラブルシューティング: 通信の遅延やネットワーク障害を調査する際に、どのサーバーが原因となっているのかを特定する。

4. ネットワークアクセスアナライザー（Network Access Analyzer）との併用

AWSでは、Network Access Analyzerを使ってサーバー間の通信を可視化することもできます。これにより、特定のポート（例：ポート1000）で通信しているサーバーを迅速に特定できます。AthenaとNetwork Access Analyzerを組み合わせることで、より精度高く依存関係を把握できます。

5. ネットワーク依存関係の移行計画

移行計画において、ポート1000で通信するサーバーを特定することは重要です。アプリケーションの移行時に、依存関係を同時に移行しないと通信の断絶やレイテンシの問題が生じる可能性があります。Athenaを使用して、どのサーバーが低レイテンシの通信を必要とするかを事前に把握し、同時に移行する必要があるサーバーを特定できます。

結論

Athenaを使ったデータ探索は、ネットワークトラフィックやサーバー間の依存関係を特定するために非常に強力なツールです。ポート1000のようなカスタムプロトコルで通信を行うサーバーを特定し、移行計画を立てる際に重要な情報を得ることができます。これにより、移行後のシステムでの問題を未然に防ぎ、スムーズな移行を実現することができます。

結論

アプリケーションの依存関係を特定し、それらを同時に移行することは、移行後のシステムの整合性とパフォーマンスを保つために非常に重要です。AWSのツールを活用して依存関係を可視化し、適切な移行戦略を立てることが求められます。

実践

略

一問道場

質問 #300

トピック 1

ある企業が複数のアプリケーションをAWSに移行する計画を立てています。しかし、企業は自社のアプリケーション全体を十分に把握していません。アプリケーション群は、物理サーバーと仮想マシン（VM）が混在しています。移行対象のアプリケーションの一つには、レイテンシに敏感な多くの依存関係があり、企業はそれらのすべてを特定していません。ただし、低レイテンシの通信には、ポート1000で動作するカスタムのIPベースのプロトコルが使われていることは把握しています。企業は、アプリケーションとその依存関係を同時にAWSに移行し、低レイテンシインターフェースも同時にAWSに移動させたいと考えています。企業はAWS Application Discovery Agentをインストールして数ヶ月間データを収集してきました。

企業がアプリケーションとその依存関係を特定のフェーズで移行するために必要な手順として、最も適切なものはどれですか？

A. AWS Migration Hubを使用して、アプリケーションをホストしているサーバーを選択し、ネットワークグラフを可視化して、アプリケーションとやり取りしているサーバーを見つけます。次に、Amazon Athenaでデータ探索を有効にし、サーバー間で転送されるデータをクエリして、ポート1000で通信するサーバーを特定します。その結果に基づいて移行グループを作成します。

B. AWS Application Migration Serviceを使用して、アプリケーションをホストしているサーバーを選択し、ネットワークグラフを可視化して、アプリケーションとやり取りしているサーバーを見つけます。その後、Application Migration Serviceでテストインスタンスを起動して受け入れテストを行い、問題がなければそのサーバーを基に移行グループを作成します。

C. AWS Migration Hubを使用して、アプリケーションをホストしているサーバーを選択し、Network Access Analyzerでデータ探索を有効にします。その後、Network Access Analyzerコンソールを使ってポート1000でアクセスしているサーバーを見つけ、移行グループを作成します。

D. AWS Migration Hubを使用して、アプリケーションをホストしているサーバーを選択し、AWS Application Discovery Agentを使ってAmazon CloudWatchエージェントをサーバーにプッシュします。収集されたCloudWatchログをAmazon S3にエクスポートし、Athenaでクエリしてポート1000で通信するサーバーを特定し、移行グループを作成します。

解説

この問題の解説では、AWSでのアプリケーションの依存関係を特定して、移行グループを作成するための最適な方法を選ぶことが求められています。特に、低レイテンシの通信に使用されるポート1000を基に依存関係を特定する方法が重要です。

正解: A

選択肢Aは最も適切なソリューションです。この選択肢では、次のように依存関係を特定します:

AWS Migration Hubを使用してサーバーを選択: まず、アプリケーションをホストしているサーバーを選択します。

ネットワークグラフを可視化: サーバー間の相互作用を示すネットワークグラフを使用して、どのサーバーがアプリケーションと通信しているかを特定します。

Amazon Athenaでデータ探索を有効にする: Athenaを使用して、サーバー間で転送されるデータをクエリします。これにより、ポート1000で通信するサーバーを特定できます。

移行グループの作成: Athenaで得られた結果を基に移行グループを作成し、必要なサーバーを一度に移行できるようにします。

この方法は、特定の通信ポート（ポート1000）に基づいて依存関係を特定するため、レイテンシに敏感な依存関係を把握しやすく、効率的に移行を進めることができます。

他の選択肢の分析

B. AWS Application Migration Service: この選択肢では、テストインスタンスを使用して受け入れテストを実施することを提案していますが、ネットワーク依存関係の特定には適していません。また、依存関係の調査や移行に必要な詳細な情報を得るためには、AthenaやNetwork Access Analyzerの方が適切です。

C. Network Access Analyzer: この選択肢はNetwork Access Analyzerを使用していますが、ポート1000に関連する依存関係を特定するためには、Athenaを使ったデータ探索の方が効果的です。また、Network Access Analyzerはネットワークアクセスの可視化には優れていますが、アプリケーションの依存関係を全体的に捉えるためには不十分です。

D. Amazon CloudWatchエージェント: CloudWatchエージェントを使ってログを収集し、Athenaでクエリする方法もありますが、ログの収集と解析のための手順が増え、効率的ではありません。また、直接的なネットワーク通信の把握には向いていないため、選択肢Aの方が優れています。

結論

選択肢Aが最も効率的で適切な方法です。AWS Migration Hubでサーバーを選択し、ネットワークグラフを可視化して依存関係を明確にし、Athenaで通信データをクエリすることで、ポート1000で通信するサーバーを特定し、移行グループを迅速に作成できます。このアプローチは、依存関係を特定し、移行作業を最適化するために最も効果的です。

301-AWS SAP AWS 「理論・実践・一問道場」APIキーごとにクォータ

理論

1. Amazon API Gateway

Amazon API Gatewayは、AWS Lambdaなどのバックエンドサービスと連携して、HTTPリクエストを受けるAPIを構築するためのサービスです。API Gatewayには、リクエストの制限やスロットリング、認証、APIキーの管理など、複数の機能があります。

使用プラン: API Gatewayには「使用プラン（Usage Plan）」という機能があり、これを使って顧客ごとにリクエストの制限を設定できます。使用プランは、1分あたりや1日あたりの最大リクエスト数などを設定できるため、特定の顧客に異なるリクエストクォータを設定するのに適しています。

APIキーの管理: 各顧客に対してAPIキーを発行し、そのAPIキーを使用して顧客ごとにリクエストのトラッキングと制限を行うことができます。これにより、個々の顧客に対応したクォータ管理が可能になります。

2. Amazon API Gateway HTTP API vs REST API

API Gatewayには、HTTP APIとREST APIの2つの主なタイプがあります。どちらもAPIを作成するために使用できますが、いくつかの違いがあります。

REST API: より多機能で、特にリクエスト制限やクォータ管理の面では優れています。顧客ごとに詳細な設定が可能で、API Gatewayの「使用プラン」や「スロットリング」機能と組み合わせて、きめ細かい制御ができます。

HTTP API: よりシンプルで軽量なAPIを提供し、基本的な機能に特化しています。リクエスト制限やクォータ設定に関しては、REST APIよりも機能が少なく、複雑な管理が必要な場合には不向きです。

3. AWS LambdaとAPI Gatewayの連携

AWS Lambdaは、サーバーレスアーキテクチャを支えるサービスで、バックエンドのロジックを処理するために利用されます。Lambda関数は、API Gatewayを通じてHTTPリクエストを受け取ることができます。顧客ごとに異なるリクエストクォータを設定する場合、API Gatewayの使用プランを活用することで、各顧客のリクエスト数を制限し、Lambda関数を適切に管理することが可能になります。

4. AWS WAFを利用したリクエスト制限

AWS WAF（Web Application Firewall）は、Webアプリケーションに対する攻撃や不正なリクエストを防ぐためのサービスですが、これを使ってリクエストを制限することもできます。しかし、API Gatewayの使用プランを利用する方が、クォータ管理には適しています。WAFを利用した制限は、特定の条件を基にした制御が可能ですが、リクエストの数に基づいた細かい制限設定には限界があります。

5. Lambda関数の個別管理

Lambda関数を顧客ごとに分けて管理する方法もあります。例えば、顧客ごとに異なるLambdaエイリアスを作成し、エイリアスごとにスロットリング制限をかけることも考えられます。しかし、API Gatewayを使った方がより柔軟かつ効率的にクォータ管理ができるため、この方法は一般的にはあまり推奨されません。

結論

顧客ごとにリクエストのクォータを設定するには、Amazon API Gateway REST APIを使用する方法が最も適しています。API Gatewayの使用プラン機能を使うことで、顧客ごとに異なるリクエスト数を設定し、APIキーによるアクセス管理を行うことができるため、柔軟で効率的なクォータ管理が実現できます。

実践

略

一問道場

問題 #301

トピック 1

ある企業がAWS Lambda関数で実行されるアプリケーションを構築しています。数百人の顧客がこのアプリケーションを使用する予定です。この企業は、各顧客に対して特定の時間帯にリクエストのクォータを設定したいと考えています。クォータは顧客の使用パターンに合致させる必要があります。一部の顧客には、短期間でより高いクォータを提供する必要があります。

この要件を満たすソリューションはどれですか？

A. Amazon API Gateway REST APIを作成し、プロキシ統合を使用してLambda関数を呼び出します。各顧客に対して、適切なリクエストクォータを含むAPI Gatewayの使用プランを構成します。顧客に必要なAPIキーを使用プランから作成します。

B. Amazon API Gateway HTTP APIを作成し、プロキシ統合を使用してLambda関数を呼び出します。各顧客に対して、適切なリクエストクォータを含むAPI Gatewayの使用プランを構成します。ルートレベルでスロットリングを設定して、各使用プランに対してAPIキーを作成します。

C. 各顧客のためにLambda関数のエイリアスを作成し、適切なリクエストクォータと並行制限を設定します。各関数エイリアスに対してLambda関数URLを作成します。各顧客に関連するLambda関数URLを共有します。

D. VPC内にアプリケーションロードバランサー(ALB)を作成し、Lambda関数をALBのターゲットとして設定します。ALBのためにAWS WAFウェブACLを設定します。各顧客に対して、適切なリクエストクォータを含むルールベースのルールを設定します。

解説

この問題では、AWS Lambda関数を使用して実行されるアプリケーションのリクエストクォータを顧客ごとに管理する方法を尋ねています。要件は、顧客に応じた適切なリクエストクォータを設定し、短期間で異なるクォータを設定できることです。

各選択肢の解説

A. Amazon API Gateway REST APIを作成し、プロキシ統合を使用してLambda関数を呼び出す

適切な選択肢

API Gatewayの使用プラン機能を活用して、顧客ごとにリクエストクォータを設定できます。これにより、顧客ごとに異なるクォータを設定でき、顧客ごとに個別のAPIキーを提供することができます。これにより、リクエストの管理が柔軟になります。

理由: API Gatewayの使用プランとAPIキーによって、顧客ごとのリクエストクォータを細かく制御でき、要件に合致しています。

B. Amazon API Gateway HTTP APIを作成し、プロキシ統合を使用してLambda関数を呼び出す

API Gateway HTTP APIは、REST APIよりもシンプルで軽量なAPIを提供しますが、リクエストクォータの設定やルートレベルでのスロットリング管理に関しては、REST APIよりも柔軟性に欠ける部分があります。

理由: REST APIよりも機能が制限されているため、より詳細なクォータ管理が必要な場合には不向きです。

C. 各顧客のためにLambda関数のエイリアスを作成し、適切なリクエストクォータと並行制限を設定する

Lambda関数のエイリアスを使用することで、各顧客ごとに異なるエイリアスを使用してリソースを分離できますが、リクエストクォータの管理には手間がかかり、API Gatewayのように詳細な管理を行うことはできません。

理由: エイリアスと並行制限を使う方法は、クォータ管理には向いていません。Lambda関数単独でクォータを管理する機能は限られているため、API Gatewayのほうが適切です。

D. アプリケーションロードバランサー(ALB)を作成し、Lambda関数をターゲットとして設定する

ALBを使用することで、トラフィックをLambda関数にルーティングできますが、ALBとAWS WAFを使用してリクエストクォータを設定する方法は、API Gatewayの使用プランを使った方法よりも効果的ではありません。

理由: WAFでリクエスト制限を行うことは可能ですが、API Gatewayのように簡単にクォータを設定・管理できるわけではなく、実装が複雑になる可能性があります。

結論

選択肢Aが最適です。API Gateway REST APIを使用して、顧客ごとに異なるリクエストクォータを設定し、APIキーを利用してアクセスを管理する方法が、柔軟で管理が簡単です。

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

理論

1. AWSへの移行手法

オンプレミスのシステムをAWSに移行する方法はいくつかあります。それぞれの方法は、移行するシステムの種類（VM、データベース、ファイルシステムなど）や、移行する際の時間的制約、コスト、複雑さに応じて選択します。代表的な方法には以下があります。

a. AWS Application Migration Service (AWS MGN)

概要: AWS Application Migration Serviceは、オンプレミスのVMware環境や物理サーバーからAWSのEC2インスタンスにアプリケーションを移行するサービスです。このサービスは、移行を効率的に、ダウンタイムを最小限に抑えて行えるように設計されています。

主な特徴:

自動化されたレプリケーションによって、アプリケーションの移行がスムーズに行えます。
移行中にアプリケーションが稼働したまま移行できるため、ダウンタイムを最小限に抑えることが可能です。

b. VM Import/Export

概要: VMware環境の仮想マシン（VM）をAWSにインポートするためのツールです。これを使用すると、仮想マシンのイメージをS3にアップロードし、それをAmazon EC2インスタンスとして復元できます。

主な特徴:

仮想マシンをAWSに移行する際、移行後のインスタンスが元のVMとほぼ同じ環境で稼働することが保証されます。
仮想マシンの移行作業に手動作業が伴うため、移行するVMが非常に多い場合、手間がかかります。

c. AWS Snowball

概要: AWS Snowballは、大量のデータをAWSに移行するための物理的なデバイスです。これを使用すると、インターネット経由ではなく、専用デバイスを使ってデータを高速で移行できます。

主な特徴:

データセンターからAWSへのデータ移行時の帯域幅制限を回避するため、非常に大きなデータセット（TB単位）を迅速に移行できます。
AWS Direct Connectのような高帯域幅接続を用いても移行時間が長くなる場合、Snowballは特に有効です。

2. AWSのストレージサービス

移行時には、データの保管や転送のために適切なストレージサービスを選択する必要があります。

a. Amazon EFS (Elastic File System)

概要: EFSは、AWSクラウドでフルマネージドなファイルシステムを提供します。NFS（Network File System）に対応し、スケーラブルで可用性の高いファイルシステムです。

用途:

データのバックアップ、リストア、移行に利用されます。
複数のEC2インスタンスから同時にアクセス可能な共有ファイルシステムとして、アプリケーションのデータ共有に利用できます。

b. Amazon FSx for Lustre

概要: 高速なファイルシステムで、特に高性能な計算処理や大規模なデータ解析に最適です。LustreファイルシステムをAWSで利用できます。

用途:

分散コンピューティング環境や大規模なデータ分析において、データの高速処理が求められる場合に使用します。

c. AWS DataSync

概要: AWS DataSyncは、オンプレミスとAWS間、またはAWS内の異なるサービス間でのデータ転送を効率的に行うためのサービスです。

用途:

大量のデータをS3、EFS、FSxなどのAWSサービスに転送する際に使用します。
移行のスピードを最大化し、エラーや中断を防ぎます。

3. データ転送と帯域幅の最適化

オンプレミスからAWSへのデータ転送には、以下の方法を用いて帯域幅や転送時間を最適化します。

AWS Direct Connect: 専用線を利用して、オンプレミスとAWS間の高帯域幅接続を実現します。これにより、クラウドに大量のデータを高速かつセキュアに転送できます。

AWS Snowball: 非常に大きなデータ（TB単位）をネットワーク経由で転送するのではなく、物理デバイスを利用して転送する方法です。これにより、インターネット経由での転送にかかる時間を大幅に短縮できます。

結論

オンプレミスのVMやデータをAWSに移行する際は、AWSの移行ツール（Application Migration Service、VM Import/Export、Snowball）と、ストレージサービス（EFS、DataSync）をうまく組み合わせて、移行を迅速かつ効率的に進めることが求められます。

実践

略

一問道場

問題 #302

ある企業が、オンプレミスのVMwareクラスタにある120台の仮想マシン（VM）をAWSに移行する予定です。これらのVMはさまざまなオペレーティングシステムと多くのカスタムソフトウェアパッケージをインストールしています。さらに、企業には10TBのサイズを持つオンプレミスのNFSサーバーがあります。企業はAWSへの移行のために10 GbpsのAWS Direct Connect接続を設定しています。

どのソリューションが最も短時間でAWSへの移行を完了しますか？

オンプレミスのVMをエクスポートして、Amazon S3バケットにコピーします。

VM画像をAmazon S3に格納した後、VM Import/Exportを使用してAMIを作成します。

AWS Snowball Edgeデバイスを注文し、NFSサーバーのデータをデバイスにコピーします。

NFSサーバーのデータをNFSが設定されたAmazon EC2インスタンスに復元します。

AWS Application Migration Serviceを設定して、VMwareクラスタへの接続を確立します。

VMのレプリケーションジョブを作成します。

Amazon Elastic File System（Amazon EFS）ファイルシステムを設定します。

AWS DataSyncを使用して、Direct Connect接続を通じてNFSサーバーのデータをEFSファイルシステムにコピーします。

AWS上でVMをAmazon EC2インスタンスとして再作成し、必要なソフトウェアパッケージをインストールします。

Amazon FSx for Lustreファイルシステムを設定します。

AWS DataSyncを使用して、Direct Connect接続を通じてNFSサーバーのデータをFSx for Lustreファイルシステムにコピーします。

2台のAWS Snowball Edgeデバイスを注文し、VMとNFSサーバーのデータをデバイスにコピーします。

デバイスからAmazon S3バケットにデータがロードされた後、VM Import/Exportを実行します。

Amazon Elastic File System（Amazon EFS）ファイルシステムを作成し、Amazon S3からEFSファイルシステムにNFSサーバーのデータをコピーします。

解説

この問題に関して、最も効率的かつ時間を短縮できる移行方法を選択する必要があります。それぞれの選択肢を詳しく見てみましょう。

A.

VM Import/Export: オンプレミスのVMをエクスポートしてAmazon S3にコピーし、そこからAMIを作成する方法です。これにより、仮想マシンをAWS EC2インスタンスとして復元できます。

AWS Snowball Edge: 10TBのNFSデータを手動でコピーするために使用しますが、10TBのデータを移動するのに時間がかかる可能性があります。AWS Snowball Edgeは、移行が非常に大きなデータセットに適していますが、他の方法に比べて時間がかかる場合があります。

B.

AWS Application Migration Service: VMwareクラスタに直接接続して、VMのレプリケーションジョブを実行します。これにより、オンプレミスのVMをAWSに効率的に移行することができます。

Amazon EFS + AWS DataSync: NFSサーバーのデータを直接Amazon EFSにコピーするため、データの移行が非常にスムーズです。EFSは、AWS上でスケーラブルなファイルシステムを提供し、直接的なデータ転送が可能です。

C.

Amazon EC2 + Amazon FSx for Lustre: EC2インスタンスを使用してVMを再作成し、ソフトウェアパッケージをインストールします。これは非常に手間がかかり、さらにAmazon FSx for Lustreは、高速で低レイテンシーのファイルシステムですが、移行の複雑さが増します。

AWS DataSync: FSx for Lustreにデータをコピーするために使用されますが、この手法は他のオプションに比べて時間を要する可能性があります。

D.

AWS Snowball Edge: 2台のSnowball Edgeを使用して、VMとNFSサーバーのデータをAWSに転送します。データがS3にアップロードされた後、VM Import/Exportを使用してVMを復元します。データ転送と移行が行われますが、2台のSnowball Edgeを使用する必要があるため、複雑度とコストが増加します。

最適な選択肢はBです。

理由:

AWS Application Migration Serviceを使用して、VMwareクラスタ内のVMを直接レプリケーションできます。これにより、VMの移行が効率的かつ高速に行われます。

Amazon EFSとAWS DataSyncを組み合わせて、NFSサーバーのデータを直接AWSにコピーすることができます。EFSはスケーラブルで、NFS互換のファイルシステムとして、オンプレミスのデータを高速かつ安全に移行するのに最適です。

他の選択肢は、手動での移行手順や追加の機器（Snowball Edge）の使用が必要となり、時間とコストがかかります。

したがって、Bが最も効率的で、最短時間での移行を実現できる方法です。

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

理論

1. データ暗号化の基本

データ暗号化は、データが送受信される際に不正アクセスを防ぐための方法です。暗号化により、第三者がデータを傍受しても、内容を理解できないようにします。

対称暗号化 vs 非対称暗号化

対称暗号化：データを暗号化するための鍵（暗号鍵）と復号化するための鍵（復号鍵）が同じです。例えば、AWS KMSの対称キーを使った暗号化がこれに該当します。

非対称暗号化：暗号化用の鍵と復号化用の鍵が異なります。公開鍵で暗号化し、秘密鍵で復号化します。これは、RSA暗号方式のような方式です。

2. AWSの暗号化サービス

AWSは、データの暗号化を管理するためにいくつかのツールを提供しています。

AWS KMS (Key Management Service)

AWS KMSは、対称鍵や非対称鍵の作成、管理、使用を行うサービスです。データの暗号化や復号化を簡単に管理できます。KMSは、AWS内で安全に鍵を保管し、アクセス制御を設定できます。

Lambda@Edge

Lambda@Edgeは、CloudFrontと連携して、エッジロケーションでコードを実行するサービスです。これを使うと、ユーザーのリクエストやレスポンスを動的に処理できます。データの暗号化・復号化など、リクエスト/レスポンスをカスタマイズするために利用されます。

3. CloudFrontと暗号化

CloudFrontは、コンテンツ配信ネットワーク（CDN）サービスで、コンテンツをエンドユーザーに高速に配信します。データがCloudFrontを通過する際に、暗号化を行うためには、公開鍵と秘密鍵のペアを利用することが一般的です。公開鍵を使ってCloudFrontでデータを暗号化し、秘密鍵を使ってデータ処理マイクロサービスで復号化する方法が多く採用されます。

4. セキュリティ要件

データの機密性：データが適切に暗号化され、第三者がアクセスできないようにする。

アクセス制御：誰が暗号化されたデータにアクセスできるかを制限する。データ処理マイクロサービスだけが復号化できるように鍵を管理します。

暗号鍵の管理：秘密鍵を厳密に管理し、必要なサービスやユーザーだけがアクセスできるようにします。これにより、データのセキュリティを確保します。

5. 最適なアプローチ

データを暗号化する際には、最小限のアクセス権限の原則に従い、復号化できるのは特定のサービスやユーザーに限定します。例えば、非対称鍵を使って、CloudFrontでデータを暗号化し、データ処理マイクロサービスが秘密鍵で復号化する方法が最も適切です。

Lambda@Edgeなどのツールを使う場合、必要以上に複雑化しないように注意し、シンプルで管理しやすいセキュリティアーキテクチャを設計することが大切です。

まとめ

AWSでのデータ暗号化において、非対称暗号化（RSAキー対など）を使用することで、公開鍵でデータを暗号化し、秘密鍵で復号化する方法が一般的です。CloudFrontとRSA暗号方式を組み合わせることで、安全にデータを転送し、復号化は特定のマイクロサービスだけに許可できます。この方法はシンプルで、セキュリティ要件を満たす効果的なアプローチです。

実践

略

一問道場

質問 #303

あるオンラインアンケート会社は、アプリケーションをAWSクラウドで実行しています。アプリケーションは分散型で、Amazon Elastic Container Service（Amazon ECS）クラスターで実行されているマイクロサービスで構成されています。このECSクラスターは、アプリケーションロードバランサー（ALB）のターゲットです。ALBは、Amazon CloudFrontディストリビューションのカスタムオリジンです。

この会社には、機密データを含むアンケートがあります。機密データはアプリケーション内を移動する際に暗号化する必要があります。また、そのデータを復号化できるのは、アプリケーションのデータ処理マイクロサービスだけである必要があります。

この要件を満たすソリューションはどれですか？

A. データ処理マイクロサービス専用の対称AWS Key Management Service（AWS KMS）キーを作成します。フィールドレベルの暗号化プロファイルと構成を作成し、そのKMSキーと構成をCloudFrontのキャッシュ動作に関連付けます。

B. データ処理マイクロサービス専用のRSAキー対を作成します。公開鍵をCloudFrontディストリビューションにアップロードします。フィールドレベルの暗号化プロファイルと構成を作成し、その構成をCloudFrontのキャッシュ動作に追加します。

C. データ処理マイクロサービス専用の対称AWS Key Management Service（AWS KMS）キーを作成します。Lambda@Edge関数を作成し、その関数を使用してKMSキーで機密データを暗号化するようにプログラムします。

D. データ処理マイクロサービス専用のRSAキー対を作成します。Lambda@Edge関数を作成し、その関数を使用してRSAキー対の秘密鍵で機密データを暗号化するようにプログラムします。

解説

質問の要点：

アプリケーションは AWSクラウド 上で実行され、Amazon ECS クラスターでマイクロサービスとして動作しています。

機密データはアプリケーション内で移動する際に 暗号化 する必要があります。

そして、そのデータを復号化できるのは アプリケーションのデータ処理マイクロサービスだけ である必要があります。

この要件を満たすために最も適切なソリューションはどれかを問う質問です。

各選択肢の解説：

A. データ処理マイクロサービス専用の対称AWS KMSキーを作成します。フィールドレベルの暗号化プロファイルと構成を作成し、そのKMSキーと構成をCloudFrontのキャッシュ動作に関連付けます。

AWS KMS（Key Management Service） を使って対称キーを作成し、暗号化と復号化を行う方法です。

ただし、この方法ではデータの 暗号化と復号化をKMSが管理 するため、データ処理マイクロサービスだけ が復号化できるという要件を完全には満たせません。

KMSキーは複数のリソース（ECS、CloudFrontなど）からアクセス可能 になり、特定のマイクロサービスにのみ復号化を許可することはできません。

B. データ処理マイクロサービス専用のRSAキー対を作成します。公開鍵をCloudFrontディストリビューションにアップロードします。フィールドレベルの暗号化プロファイルと構成を作成し、その構成をCloudFrontのキャッシュ動作に追加します。

RSAキー対（公開鍵と秘密鍵）を使用する方法です。

公開鍵はCloudFrontにアップロードされ、データがCloudFrontを通過する際にデータを暗号化します。

秘密鍵はデータ処理マイクロサービス専用にして、これだけがデータを復号化できるようにします。

この方法は、要件に完全に適合しています。「データを復号化できるのはデータ処理マイクロサービスだけ」という要件を満たすため、秘密鍵の管理をデータ処理マイクロサービスに限定できます。

C. データ処理マイクロサービス専用の対称AWS KMSキーを作成します。Lambda@Edge関数を作成し、その関数を使用してKMSキーで機密データを暗号化するようにプログラムします。

この方法では、Lambda@Edge を使ってデータを暗号化し、AWS KMSを使って暗号化キーを管理します。

Lambda@Edgeを使う理由は不明確で、暗号化と復号化の処理が CloudFrontエッジロケーション で行われるため、データの流れが複雑になり、効率的ではない可能性があります。

また、Lambda@Edgeを使うことで データ処理マイクロサービス専用の復号化 を実現するのが難しくなります。単純に RSAキー対 を使う方が明確でシンプルです。

D. データ処理マイクロサービス専用のRSAキー対を作成します。Lambda@Edge関数を作成し、その関数を使用してRSAキー対の秘密鍵で機密データを暗号化するようにプログラムします。

ここでも RSAキー対 を使用していますが、Lambda@Edge を使って秘密鍵でデータを暗号化しようとしています。

秘密鍵 は復号化専用で、データの暗号化には公開鍵を使うのが正しい方法です。秘密鍵で暗号化するのは誤った使用方法です。

さらに、Lambda@Edgeを使う必要がないため、この方法も過剰で複雑です。

結論：

B が最も適切な選択肢です。

RSA公開鍵暗号方式を使用し、公開鍵でデータを暗号化し、秘密鍵で復号化するという方法が、要件を満たす最もシンプルで効果的な方法です。

データ処理マイクロサービス専用に秘密鍵を管理でき、データの暗号化と復号化の制御が明確に行えます。

これが選択肢 B の正当性の理由です。

304-AWS SAP AWS 「理論・実践・一問道場」DHCPオプションセット

理論

VPC内のDNS設定とプライベートホステッドゾーン

Amazon Web Services (AWS) のVirtual Private Cloud (VPC)を使用している場合、DNSの設定は非常に重要です。VPC内のリソースが正しく通信できるようにするためには、DNS解決を適切に設定する必要があります。以下は、VPC内でDNS解決を管理するための主要なポイントです。

1. DNSサポートの有効化

enableDnsSupport属性を有効にすると、VPC内のインスタンスがDNSを使用して名前解決を行うことができます。この属性が無効の場合、VPC内のインスタンスはDNSを使用できません。

2. パブリックDNSホスト名の設定

enableDnsHostnames属性を有効にすることで、VPC内のインスタンスにパブリックDNS名を付与することができます。これにより、インスタンスがインターネットに公開されている場合、そのインスタンスにパブリックホスト名が自動的に割り当てられます。

3. プライベートホステッドゾーン

プライベートホステッドゾーンは、VPC内でのみ名前解決されるDNSゾーンを提供します。これにより、VPC内のインスタンスがプライベートなDNS名前解決を行えるようになります。

プライベートホステッドゾーンは、通常、VPCに関連付けて使用します。これにより、VPC内のリソースがDNSクエリをそのプライベートホステッドゾーンで解決できます。

4. DHCPオプションセット

VPCのDHCPオプションセットの主な役割の1つは、インスタンスのネットワーク設定に関連するパラメータ、特に**時間サーバー（NTPサーバー）やドメインネームサーバー（DNSサーバー）**を設定することです。

デフォルト設定

DNSサーバー：

デフォルトでは、AWSはVPC内のインスタンスにAmazon提供のDNSサービス（AmazonProvidedDNS）を提供します。このサービスは、AWS内で使用されるドメイン（例えば、ec2.internal）や外部ドメイン（例えば、google.com）を解決できます。

時間サーバー（NTP）：

デフォルトでは、VPC内のインスタンスはAWSが提供するNTPサーバーを使用して、システム時間を同期します。

カスタム設定

もし、独自のDNSサーバーや外部のNTPサーバー（例えば、企業内のDNSや時間同期サーバー）を使用する必要がある場合、DHCPオプションセットでそれらの設定を変更することができます。これにより、VPC内のインスタンスは、AWSのデフォルトのサービスではなく、指定した外部のDNSサーバーやNTPサーバーを使用するようになります。

意味：

AmazonProvidedDNS は、AWSが提供するDNSサーバーで、通常、VPC内のインスタンスがインターネットや内部ドメイン名（例: ec2.internal）を解決するために使用します。

この設定をVPCのDHCPオプションセットに追加すると、そのVPC内のすべてのインスタンスがこのDNSサーバーを使用して名前解決を行うことになります。

具体的には：

AmazonProvidedDNS は、VPC内のインスタンスがインターネット上のホスト名（例: www.example.com）を解決するために使用されるDNSサーバーです。

また、AWS内部で動作しているサービスやリソース（例: EC2インスタンスやALBなど）のドメイン名（例: ec2.internal）を解決するためにも使われます。

例：

VPC内でインスタンスがインターネットのウェブサイトにアクセスする場合、AmazonProvidedDNS サーバーを使用してそのウェブサイトのIPアドレスを解決します。

AmazonProvidedDNS は、ec2.internal ドメインに関連するインスタンスやリソースの名前解決もサポートします。

まとめ

デフォルトでは、AWSはDNSサーバーとNTPサーバーを提供しますが、特別なニーズがある場合（例えば、社内DNSやNTPサーバーを使いたい場合）は、それらをDHCPオプションセットでカスタマイズすることができます。

DHCPオプションセットは、VPC内のインスタンスに対してこれらの設定を統一的に提供する方法です。

5. DNSクエリの管理

VPC内でDNS解決を管理するために、プライベートホステッドゾーンを作成してVPCに関連付けます。これにより、プライベートなDNS名前解決を行い、インターネットに公開しないリソースに対しても名前解決が可能になります。

6. DNSとインターネットアクセス

VPC内のインスタンスがインターネットにアクセスする場合、パブリックIPアドレスを持つインスタンスは、対応するパブリックDNS名を使用してアクセスできます。このDNS名は、enableDnsHostnamesを有効にすることで自動的に割り当てられます。

よくある課題と解決策

DNS解決の失敗: DNS解決がうまくいかない場合、enableDnsSupportやenableDnsHostnamesの設定を確認しましょう。また、DHCPオプションセットが正しく設定されていることを確認することも重要です。

パブリックIPのDNS名の不一致: enableDnsHostnamesが無効だと、インスタンスにパブリックDNS名が割り当てられません。この設定を有効にすることで、インスタンスのパブリックDNS名が自動的に割り当てられます。

まとめ

enableDnsSupport と enableDnsHostnames を適切に設定することは、VPC内でのDNS解決において非常に重要です。

プライベートホステッドゾーンを作成してVPCに関連付けることで、プライベートDNS名前解決を実現できます。

AmazonProvidedDNS を利用することで、AWSのデフォルトDNSサーバーが利用可能となり、インターネット接続を持つインスタンスにも対応するDNS解決が提供されます。

実践

VPCのDHCPオプションセットを使ってEC2のDNS/NTPサーバ設定を試してみる | DevelopersIO

VCP の DHCP オプションセットを利用して EC2 インスタンス（Amazon Linux 2）に対して DNS/NTP サーバの設定を行います

https://dev.classmethod.jp/articles/dhcp-option-set-dns-ntp/

一問道場

質問 #304

ソリューションアーキテクトが既存のVPCのDNS戦略を決定しています。VPCは10.24.34.0/24のCIDRブロックを使用するようにプロビジョニングされています。VPCはまた、Amazon Route 53 ResolverをDNSに使用しています。新たに要求されている要件は、DNSクエリがプライベートホステッドゾーンを使用する必要があることです。また、パブリックIPアドレスを持つインスタンスは、対応するパブリックホスト名を受け取る必要があります。

この要件を満たし、VPC内でドメイン名が正しく解決されることを保証するソリューションはどれですか？

A.

プライベートホステッドゾーンを作成する。

VPCのenableDnsSupport属性とenableDnsHostnames属性を有効にする。

VPCのDHCPオプションセットを更新し、domain-name-servers=10.24.34.2を含める。

B.

プライベートホステッドゾーンを作成する。

プライベートホステッドゾーンをVPCに関連付ける。

VPCのenableDnsSupport属性とenableDnsHostnames属性を有効にする。

新しいVPCのDHCPオプションセットを作成し、domain-name-servers=AmazonProvidedDNSを設定する。

新しいDHCPオプションセットをVPCに関連付ける。

C.

VPCのenableDnsSupport属性を無効にし、enableDnsHostnames属性を有効にする。

新しいVPCのDHCPオプションセットを作成し、domain-name-servers=10.24.34.2を設定する。

新しいDHCPオプションセットをVPCに関連付ける。

D.

プライベートホステッドゾーンを作成する。

プライベートホステッドゾーンをVPCに関連付ける。

VPCのenableDnsSupport属性を有効にする。

VPCのenableDnsHostnames属性を無効にする。

VPCのDHCPオプションセットを更新し、domain-name-servers=AmazonProvidedDNSを含める。

解説

この質問では、VPC内でDNSクエリが正しく解決されるように設定を行う方法を尋ねています。新しい要件として、以下が求められています：

DNSクエリはプライベートホステッドゾーンを使用すること。

パブリックIPアドレスを持つインスタンスは、対応するパブリックホスト名を持つこと。

解説：

プライベートホステッドゾーンの作成と関連付け:

プライベートホステッドゾーンは、VPC内のインスタンスがクエリするDNSレコードを管理します。DNSクエリをプライベートホステッドゾーンに解決させるためには、このゾーンをVPCに関連付ける必要があります。

VPCのDNS設定:

enableDnsSupport属性は、VPC内でDNS解決を有効にするための設定です。これを有効にすると、VPC内のインスタンスがDNSを使用できるようになります。

enableDnsHostnames属性は、インスタンスにパブリックDNS名を付与する設定です。これを有効にすることで、インスタンスがパブリックIPを持っている場合、そのインスタンスに対応するパブリックDNS名を割り当てることができます。

DHCPオプションセットの設定:

VPC内のインスタンスが使用するDNSサーバーを指定するために、DHCPオプションセットを使用します。domain-name-serversを設定することで、DNSサーバーを指定できます。AmazonProvidedDNSはAWSのデフォルトのDNSサーバーであり、これを設定すると、AmazonのDNSサービスを使用できます。

各選択肢の評価：

プライベートホステッドゾーンを作成し、enableDnsSupportとenableDnsHostnamesを有効にする点は適切です。しかし、domain-name-servers=10.24.34.2を指定するのは間違いです。AmazonProvidedDNSを使うべきです。

正しいソリューションです。プライベートホステッドゾーンを作成してVPCに関連付け、enableDnsSupportとenableDnsHostnamesを有効にし、DHCPオプションセットでAmazonProvidedDNSを指定しています。この設定により、要求を満たします。

enableDnsSupportを無効にするのは誤りです。これにより、DNS解決が無効になります。enableDnsHostnamesを有効にするのは正しいですが、enableDnsSupportは有効にする必要があります。

enableDnsHostnamesを無効にするのは誤りです。これにより、パブリックIPを持つインスタンスに対応するパブリックDNS名が割り当てられません。enableDnsSupportは有効にする必要があります。

結論：

正しい解答は B です。この設定は、プライベートホステッドゾーンを作成し、VPCに関連付け、必要なDNS設定を適切に行う方法を提供しています。

305-AWS SAP AWS 「理論・実践・一問道場」 Concurrency Scaling

理論

Amazon Redshift のスケーリングと負荷対策

Amazon Redshift を使っていると、突然クエリが増えてCPU使用率が高くなることがあります。そのような場合に役立つ機能や対策をまとめました。

1. スケーリングの方法

Redshift は、負荷が増えた時にリソースを増やして対応できます。以下の3つが主な方法です：

クラシックリサイズ (Classic Resize)

クラスター全体のサイズを変える方法。

特徴: 大規模な変更ができるが、時間がかかり、その間クラスターが停止する。

適している場面: 長期的にリソースを増やしたい時。

エラスティックリサイズ (Elastic Resize)

クラスターを停止せずに素早くリソースを増やす方法。

特徴: 迅速だが、急激な負荷増加に完全には追いつけない場合がある。

適している場面: 一時的にリソースを増やしたい時。

Concurrency Scaling (同時実行スケーリング)

クエリが増えた時だけ、自動で追加リソースを使う機能。

特徴: 必要な時にだけ課金され、コスト効率が良い。クエリが減ると自動でリソースを解放。

適している場面: 短時間のクエリ集中に対応したい時。

2. CPU負荷が高い時の対策

クエリを最適化する

無駄な結合や計算を減らす。
データを事前に整理（ETL）する。

外部サービスで処理を分散する

Amazon EMR や AWS Glue で、Redshift 以外のサービスに負荷を分ける。

モニタリングと自動化

Amazon CloudWatch でCPU使用率を監視し、閾値を超えたら通知やリサイズを自動化する。

3. コストを抑える方法

ピーク時だけリソースを増やす

Concurrency Scaling を使えば、必要な時だけリソースが追加され、コストを抑えられる。

長期利用ならリザーブドノードを使う

長期間使う場合、予約購入することで割引を受けられる。

4. ベストな選択肢

短期的な負荷増加には Concurrency Scaling が最適。

自動対応で、常にクエリを処理しながらコストも抑えられる。

長期的な需要増加には Elastic Resize や リザーブドノード を検討。

これらを活用すれば、Redshift のパフォーマンスを維持しつつ、コスト効率を最大化できます！

実践

略

一問道場

質問 #305

トピック 1

あるデータ分析会社が、いくつかのリザーブドノードで構成される Amazon Redshift クラスターを使用しています。このクラスターでは、従業員チームが詳細な監査分析レポートを作成しているため、予期しない使用量の急増が発生しています。このレポートを生成するクエリは複雑な読み取りクエリであり、CPU 集中型です。

ビジネス要件として、クラスターは常に読み取りおよび書き込みクエリに対応できる必要があります。

ソリューションアーキテクトは、この急増する使用量に対応するための最もコスト効率の良いソリューションを考案する必要があります。

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

選択肢:

A. Amazon EMR クラスターをプロビジョニングし、複雑なデータ処理タスクをオフロードする。

B. AWS Lambda 関数をデプロイし、Amazon CloudWatch でクラスターの CPU メトリクスが 80% に達した際に、クラシックリサイズ操作を使用して Amazon Redshift クラスターに容量を追加する。

C. AWS Lambda 関数をデプロイし、Amazon CloudWatch でクラスターの CPU メトリクスが 80% に達した際に、エラスティックリサイズ操作を使用して Amazon Redshift クラスターに容量を追加する。

D. Amazon Redshift クラスターの Concurrency Scaling 機能をオンにする。

解説

この問題は、Amazon Redshift クラスターで発生する急激な使用量の増加にどのように対応するかを問うものです。要件を満たすために、以下のポイントを考慮して選択肢を評価します。

要件の整理

常時対応: クラスターは、読み取りクエリと書き込みクエリを常にサービスできる必要があります。

コスト効率: ソリューションは、コスト効率が高い必要があります。

負荷対応: CPU 使用率が急上昇する場合、対応する仕組みが必要です。

選択肢の評価

A. Amazon EMR クラスターをプロビジョニングし、複雑なデータ処理タスクをオフロードする。

メリット: EMR は複雑なデータ処理に適しており、Redshift の負荷を軽減できます。

デメリット: 新しい EMR クラスターの設定と管理には時間とコストがかかります。また、読み取り/書き込みクエリを同時に処理するという要件には完全には適合しません。

評価: 必要以上のリソースを投入するため、コスト効率が低い。

B. AWS Lambda 関数を使用して、クラシックリサイズ操作で容量を追加する。

メリット: クラスターに容量を追加することで、使用量の増加に対応できます。

デメリット: クラシックリサイズ操作は時間がかかり、クラスターが一時的にオフラインになる場合があります。常時対応の要件に違反する可能性があります。

評価: 要件に合致せず、不適切。

C. AWS Lambda 関数を使用して、エラスティックリサイズ操作で容量を追加する。

メリット: エラスティックリサイズは、クラスターを停止せずに迅速に容量を拡張できます。

デメリット: Lambda を用いた自動化には設計と管理のコストがかかります。また、急激な使用量の増加を即座に処理できるわけではありません。

評価: ある程度の柔軟性があるが、コスト効率の面で最適解ではない。

D. Amazon Redshift クラスターの Concurrency Scaling 機能をオンにする。

メリット: Concurrency Scaling は、クラスターのスケーリングを自動的に行い、読み取りクエリの処理能力を動的に増加させます。この機能は必要な場合にのみ料金が発生するため、コスト効率が高いです。また、クラスターは停止しないため、常時対応の要件を満たします。

デメリット: Concurrency Scaling は、主に読み取りクエリに対応します。書き込み負荷が大幅に増加した場合には対処できません。

評価: このユースケースでは、最もコスト効率が高く、要件を満たしています。

正解: D. Amazon Redshift クラスターの Concurrency Scaling 機能をオンにする。

理由:

Concurrency Scaling は、必要な場合にのみスケーリングし、クエリのパフォーマンスを維持しながらコストを最小限に抑えます。また、読み取り/書き込みクエリの同時処理を妨げることもありません。このため、最適な選択肢となります。

306-AWS SAP AWS 「理論・実践・一問道場」S3パスが`aws:username`

理論

AWS S3 は大規模なデータストレージのためのオブジェクトストレージサービスで、非常に柔軟でスケーラブルなデータ管理を提供します。しかし、機密データやアクセス制限が重要な場合、適切なアクセス管理と監査が必要です。以下は、S3のアクセス管理、監査、そしてセキュリティに関連する重要なコンセプトと機能です。

1. S3のアクセス管理方法

IAMポリシーとS3バケットポリシー

IAMポリシー: ユーザーやグループに対して、特定のアクション（例えば、S3バケットの読み取りや書き込み）の許可・拒否を定義できます。これにより、アクセス範囲をきめ細かく制御できます。

例: aws:username を使ってユーザー固有のアクセス制御を行う（Aの選択肢）。

S3バケットポリシー: バケット単位でアクセス制御を行うためのポリシーです。特定のユーザーやIPアドレス、アクションに対するアクセス権限を設定できます。

例: バケットポリシーで特定のIAMグループにアクセス権を付与する。

S3バケットのパスベースアクセス制御

バケット内の特定のオブジェクトやフォルダにアクセスできるかどうかを、プレフィックス（パス）で制限することができます。これにより、各ユーザーが自分のフォルダのみアクセスするように設定することが可能です。

例: ユーザーusernameに対して、s3://bucket-name/username/ プレフィックスのオブジェクトにのみアクセス許可を与える。

2. アクセス監査とログ管理

AWS CloudTrail

CloudTrailは、AWSサービスで発生したAPIコールを記録するサービスで、アクセス監査に非常に役立ちます。S3バケットへのアクセスや変更もログとして残ります。

オブジェクトレベルのイベント: CloudTrailは、S3のオブジェクトの作成、読み取り、削除、更新などの詳細な操作を記録することができます。これを利用して、誰がどのオブジェクトにアクセスしたか、いつアクセスしたかを追跡できます。
レポート生成: CloudTrailのログは、Amazon Athenaや他の分析ツールを使用して簡単にクエリし、レポートを生成することができます。

S3サーバーアクセスログ

サーバーアクセスログは、S3バケットのアクセスに関する基本的な情報（誰がどのオブジェクトにアクセスしたか）を記録します。これにより、アクセス元のIPアドレスや、どのオブジェクトがリクエストされたかなどを知ることができますが、詳細なオブジェクトレベルの情報（例えば、オブジェクトの読み取りや書き込みの詳細）は記録されません。

Amazon Athena

Athenaは、S3バケット内のデータを直接クエリできるサーバーレスのインタラクティブクエリサービスです。CloudTrailやS3のサーバーアクセスログのデータを効率的にクエリし、必要な情報を抽出することができます。

3. 監査レポートの自動化

AWS Lambda と CloudWatch

Lambdaを利用して、自動的に監査ログを収集したり、CloudWatchと連携させることができます。例えば、CloudTrailのログをリアルタイムで監視し、特定のアクションが行われた場合に通知を送るといったことが可能です。

定期的なレポート生成

Athenaで定期的にレポートを自動生成する仕組みを組み合わせることで、運用負荷を減らし、レポートを自動で作成・保存できます。

4. セキュリティのベストプラクティス

暗号化とコンプライアンス

S3では、サーバーサイド暗号化（SSE）やクライアントサイド暗号化を使用して、データを保護できます。コンプライアンス要件を満たすためには、これらの機能を利用してデータを暗号化し、機密性を保つことが重要です。

SSE-S3やSSE-KMSを使用して、データを保存時に暗号化することができます。

アクセス制御リスト（ACL）

ACLは、S3オブジェクトに対して個別にアクセス権限を設定するために使用されますが、細かいアクセス制御が可能である一方、IAMポリシーと組み合わせて使う方がより効率的です。

5. コスト最適化

バケットポリシーとIAMポリシーの使い分けによって、アクセス制限を最小限に保ちながら、運用コストを抑えることができます。詳細な監査ログやアクセスログの収集にはコストがかかるため、必要な情報だけを収集する設計が重要です。

まとめ

AWS S3を利用する場合、アクセス管理と監査は非常に重要です。IAMポリシーやバケットポリシーを組み合わせることで、データへのアクセスをきめ細かく制御でき、CloudTrailやAthenaを利用して、必要な監査ログを収集し、レポートを生成することができます。これにより、コンプライアンス要件を満たし、データセキュリティを高めつつ、運用負荷を最小限に抑えることができます。

実践

略

一問道場

問題 #306

研究センターがAWSクラウドへ移行し、オンプレミスでの1PBのオブジェクトストレージをAmazon S3バケットに移行しました。100人の科学者が、このオブジェクトストレージを使って業務関連のドキュメントを保存しています。それぞれの科学者はオブジェクトストア内に個人用フォルダを持っています。全ての科学者は1つのIAMユーザーグループのメンバーです。

研究センターのコンプライアンス責任者は、科学者が互いの作業にアクセスできることを懸念しています。また、どの科学者がどのドキュメントにアクセスしたかを報告する厳格な義務があります。この報告を担当するチームはAWSの経験が少なく、運用上の負担を最小限に抑えた即時利用可能なソリューションを求めています。

ソリューションアーキテクトがこれらの要件を満たすために取るべきアクションはどれですか？（2つ選択）

A. 各ユーザーに読み取りおよび書き込みアクセスを付与するアイデンティティポリシーを作成する。S3パスがaws:usernameで始まるプレフィックスであることを条件として追加する。このポリシーを科学者のIAMユーザーグループに適用する。

B. AWS CloudTrailでトレイルを設定し、S3バケット内の全オブジェクトレベルのイベントをキャプチャする。トレイルの出力を別のS3バケットに保存する。Amazon Athenaを使用してログをクエリし、レポートを生成する。

C. S3サーバーアクセスログを有効化し、別のS3バケットをログ配信先として設定する。Amazon Athenaを使用してログをクエリし、レポートを生成する。

D. 科学者のIAMユーザーグループに所属するユーザーに読み取りおよび書き込みアクセスを付与するS3バケットポリシーを作成する。

E. AWS CloudTrailでトレイルを設定し、S3バケット内の全オブジェクトレベルのイベントをキャプチャしてAmazon CloudWatchに書き込む。Amazon Athena CloudWatchコネクターを使用してログをクエリし、レポートを生成する。

解説

解説: AWS S3でのアクセス制御と監査対応

この問題では、以下の2つの要件を満たす必要があります：

各科学者が自分のフォルダのみアクセスできるようにする。

どの科学者がどのドキュメントにアクセスしたかを記録・報告できる仕組みを提供する。

選択肢の分析

A. IAMアイデンティティポリシーを使用してフォルダアクセスを制限する

内容: S3パスにaws:username（IAMユーザー名）をプレフィックスとして追加する条件を設定し、アクセス制限を実現する。

メリット: 科学者が他人のフォルダにアクセスできないようにする効果的な方法。IAMポリシーで柔軟に制御できる。

結論: 正解。この設定により、各ユーザーのアクセス範囲を個別に制限できる。

B. AWS CloudTrailを使い、オブジェクトレベルのイベントをキャプチャしてS3に保存し、Athenaで分析する

内容: CloudTrailを設定してS3バケット内のオブジェクトレベルのイベントを記録。ログをAthenaでクエリしてアクセスレポートを生成する。

メリット: 高い柔軟性があり、詳細なログが保存される。Athenaを使えば容易にレポートを生成できる。

結論: 正解。CloudTrailとAthenaの組み合わせは、アクセス監査に最適なソリューション。

C. S3サーバーアクセスログを使用して監査レポートを生成する

内容: S3のサーバーアクセスログ機能を有効化し、Athenaでログをクエリして分析。

問題点: サーバーアクセスログは基本的な情報しか含まれない。CloudTrailほど詳細なオブジェクトレベルのデータが得られない。

結論: 不正解。必要な監査要件を満たすには不十分。

D. S3バケットポリシーを使ってアクセスを制御する

内容: バケットポリシーでIAMユーザーグループにアクセスを付与。

問題点: グループ全体にアクセスを許可するため、各ユーザーのフォルダ制限が実現できない。

結論: 不正解。フォルダ単位のアクセス制限ができない。

E. CloudTrailのログをCloudWatchに書き込み、Athena CloudWatchコネクターでレポートを生成する

内容: CloudTrailのログをCloudWatchに保存し、Athenaコネクターを使用してクエリ。

問題点: CloudWatchログへの書き込みはコストが高く、Athenaコネクターの使用は複雑。運用負担が大きい。

結論: 不正解。要件である「運用負担を最小限に抑える」に合わない。

正解: A と B

A: 各科学者が他人のフォルダにアクセスできないよう制御するための方法。

B: 誰がどのデータにアクセスしたかを記録・監査するための方法。

この2つを組み合わせることで、アクセス制限と監査要件の両方を満たすコスト効率の良いソリューションを実現できます。

308-AWS SAP AWS 「理論・実践・一問道場」バックアップ種類

理論

バックアップ種類の比較表

以下は、主要なバックアップ方法（フルバックアップ、増分バックアップ、差分バックアップ、スナップショットバックアップ）の特徴を比較した表です。

バックアップ種類	定義	特徴	利点	欠点	主な用途
フルバックアップ	データ全体を定期的にバックアップする方法。	- バックアップデータが完全。 - 復元が簡単で迅速。	- 一度のバックアップで完全なデータを確保可能。 - 復元時に追加の操作が不要。	- バックアップサイズが大きい。 - 実行に時間がかかる。	小規模システムや、完全なデータの定期的バックアップが必要な環境。
増分バックアップ	最後のバックアップ以降に変更されたデータのみを保存。	- バックアップサイズが小さい。 - 実行時間が短い。	- ストレージコストを削減可能。 - バックアップ頻度を高く設定できる。	- 復元時にフルバックアップおよびすべての増分データが必要。 - 復元が複雑化する可能性。	高頻度のバックアップが必要なシステムや、大規模なデータセット。
差分バックアップ	最後のフルバックアップ以降に変更されたデータを保存。	- バックアップサイズが中程度。 - 増分バックアップより復元が簡単。	- 必要なバックアップデータが少ない。 - 復元時の複雑性が低い。	- バックアップサイズが徐々に大きくなる。	変更頻度が比較的低いデータや、中規模のシステム。
スナップショット	データ全体の状態を特定の時点で保存する方法。実際には変更ブロックのみを保存することが多い。	- フルバックアップのように見えるが、実際は効率的に保存。 - 復元が迅速。	- 保存が効率的で、高頻度バックアップに適している。 - AWSではストレージコストを最適化。	- スナップショットの保持期間や管理が重要。	クラウド環境（例：Amazon RDSやEBS）のバックアップや、仮想化環境。

バックアップの選択ポイント

システム規模とデータ量

小規模なシステムではフルバックアップが効果的。

データ量が多い場合は増分または差分バックアップを検討。

復元の迅速性

復元が重要なシステムではフルバックアップまたはスナップショットが推奨。

ストレージコストの最適化

ストレージコストを抑えたい場合は増分バックアップやスナップショットが適している。

クラウド環境での使用

AWSやAzureなどのクラウドではスナップショット機能が一般的。

この比較を基に、バックアップ要件に最適な方法を選択することができます。

Amazon RDSスナップショット管理とAWS Backupの活用方法

データベースのバックアップ管理は、システムの信頼性と可用性を確保する上で非常に重要です。特に、複数アカウント環境や大規模なシステムでは、一元化された管理と運用負荷の削減が求められます。本記事では、Amazon RDSのスナップショット管理とAWS Backupを活用したベストプラクティスについて説明します。

1. Amazon RDSのスナップショットとは

Amazon RDSは、データベースの完全なバックアップを作成する「スナップショット」機能を提供します。RDSスナップショットは以下の2種類に分類されます：

自動スナップショット

スケジュールに従い自動で作成されます。

保持期間を設定できますが、通常は最大35日間。

手動スナップショット

必要に応じて手動で作成。

手動で削除しない限り無期限に保存されます。

2. AWS Backupを使用した一元管理

AWS Backupは、Amazon RDSを含む様々なAWSリソースのバックアップを一元的に管理できるサービスです。以下の特徴がAmazon RDSのスナップショット管理を効率化します：

主な機能

柔軟なバックアップスケジュール

任意の頻度（例：6時間ごと）でスナップショットを自動作成可能。

保持ポリシーの設定

必要に応じた期間（例：30日間）でスナップショットを保存。

タグベースの管理

タグを使用して対象リソースを自動選定。

クロスアカウント管理

AWS Organizationsを利用して複数アカウントのバックアップを一元化。

3. RDSスナップショット管理のベストプラクティス

AWS Backupでのバックアップポリシーの作成

バックアッププランを作成し、以下の要素を設定：

スケジュール（例：6時間ごと）
保持期間（例：30日間）

RDSインスタンスにタグを付与し、タグを基にプランを適用。

クロスアカウントバックアップの有効化

AWS Backupの「クロスアカウント管理」機能をオンにして、複数アカウント間での一元管理を実現。

バックアップのモニタリング

AWS Backupコンソールを使用して、バックアップの進捗や失敗を確認。

必要に応じてAmazon EventBridgeを利用し、バックアップ失敗時に通知を設定。

コスト管理

不要なスナップショットを削除し、ストレージコストを最小化。

S3へのバックアップコピーを検討して、長期保存コストを削減。

4. RDSスナップショットの注意点

整合性の確保

スナップショットはデータベースの一貫性を保つよう設計されていますが、トランザクションが多い環境では、バックアップ前にデータベースをフラッシュすることを推奨します。

復元時間

スナップショットからの復元は通常のリストアプロセスより時間がかかる可能性があります。

5. 複数アカウント環境でのメリット

AWS Backupのクロスアカウント機能は、以下の課題を解決します：

スナップショット管理の一元化

各アカウントでの設定作業を削減。

運用の効率化

コンソール1つで全アカウントのスナップショットをモニタリング可能。

セキュリティとコンプライアンス

組織全体のバックアップ状況を可視化することで、ポリシー遵守を確認。

6. AWS Backupと他の選択肢の比較

機能	AWS Backup	手動スナップショット	DLM (Data Lifecycle Manager)
自動化	高い	低い	高い
保持期間の柔軟性	高い	中程度	高い
クロスアカウント管理	可能	不可能	不可能
モニタリングの容易さ	高い	低い	中程度
運用負荷	低い	高い	中程度

まとめ

Amazon RDSのスナップショットを効率的に管理するには、AWS Backupの活用が最適です。特に複数アカウント環境では、クロスアカウント機能により運用負荷を最小限に抑えつつ、一元的に管理できます。また、AWS Backupはコスト効率も高いため、長期的な運用でも優れた選択肢となります。

AWSのネイティブサービスを活用し、信頼性の高いバックアップ管理を実現しましょう！

実践

略

一問道場

質問 #308

ソリューションアーキテクトが、Amazon RDS DBインスタンスのスナップショットを取得するプロセスをレビューしています。

現在、会社は自動スナップショットを毎日取得し、それを7日間保持しています。

ソリューションアーキテクトは、6時間ごとにスナップショットを取得し、それを30日間保持するソリューションを提案する必要があります。会社はAWS Organizationsを使用してすべてのAWSアカウントを管理しています。また、RDSスナップショットの状態を統合的に確認できる方法を求めています。

以下のうち、最小限の運用負荷で要件を満たすソリューションはどれですか？

A. AWS Backupでクロスアカウント管理機能を有効にします。頻度と保持要件を指定するバックアッププランを作成します。DBインスタンスにタグを追加し、タグを使用してバックアッププランを適用します。AWS Backupを使用してバックアップのステータスを監視します。

B. Amazon RDSでクロスアカウント管理機能を有効にします。頻度と保持要件を指定するスナップショットグローバルポリシーを作成します。管理アカウントのRDSコンソールを使用してバックアップのステータスを監視します。

C. AWS CloudFormationでクロスアカウント管理機能を有効にします。管理アカウントから、AWS Backupのバックアッププランを含むCloudFormationスタックセットをデプロイします。このバックアッププランには頻度と保持要件が含まれています。管理アカウントにAWS Lambda関数を作成してバックアップのステータスを監視します。また、各アカウントでこのLambda関数をスケジュール実行するAmazon EventBridgeルールを作成します。

D. 各アカウントでAWS Backupを設定します。頻度と保持要件を指定するAmazon Data Lifecycle Managerライフサイクルポリシーを作成します。ターゲットリソースとしてDBインスタンスを指定します。各メンバーアカウントのAmazon Data Lifecycle Managerコンソールを使用してバックアップのステータスを監視します。

解説

質問の要件

スナップショットの頻度と保持期間

6時間ごとにスナップショットを取得する。

30日間保持する。

統合的な監視

AWS Organizationsを活用し、複数アカウントのスナップショット状態を統合的に確認する。

運用負荷の最小化

手動設定や複雑な管理を避け、運用の簡略化が求められる。

選択肢の分析

A. AWS Backupでクロスアカウント管理を有効化

メリット

AWS Backupはバックアップの頻度や保持期間を細かく指定可能。
クロスアカウント機能を使うことで、複数アカウントのバックアップ管理を一元化。
タグを活用するため、新しいDBインスタンスが追加されても自動でバックアップ対象にできる。
AWS Backupコンソールで状態を簡単に監視可能。

デメリット

特に目立った欠点なし。運用負荷が最小限に抑えられる。

B. Amazon RDSでクロスアカウント管理を有効化

メリット

RDSネイティブのグローバルポリシーにより、頻度や保持期間を簡単に指定可能。
RDSコンソールを使えば管理が比較的シンプル。

デメリット

RDSには「クロスアカウント管理」のネイティブ機能が現在存在しない。
AWS Backupよりも設定や管理に制約が多い。

C. AWS CloudFormationとLambdaを使用

メリット

CloudFormationスタックセットを使うことで、複数アカウントへの設定を自動展開可能。
Lambda関数とEventBridgeでバックアップ状況を定期監視。

デメリット

セットアップが複雑で運用負荷が高い。
AWS Backupに比べて管理が煩雑で、本質問の「運用負荷最小化」の要件に適合しない。

D. Amazon Data Lifecycle Manager (DLM) を使用

メリット

各アカウントでDLMを設定し、頻度や保持期間を柔軟に管理可能。

デメリット

各アカウントごとにDLM設定が必要で、一元管理ができない。
AWS Backupに比べて運用負荷が高い。

結論: 最適な選択肢は A

理由:

AWS Backupのクロスアカウント管理機能を使うことで、複数アカウントのバックアップを一元化できる。

タグを利用して対象リソースを自動管理できるため、追加設定が不要。

AWS Backupコンソールを使えば簡単に状態を監視でき、運用負荷が最小限に抑えられる。

309-AWS SAP AWS 「理論・実践・一問道場」`sts:AssumeRole`

理論

AWSでのクロスアカウントアクセスと`sts:AssumeRole`の基本

AWSで複数のアカウントを管理する際、特定のアカウントのユーザーが別のアカウントのリソースにアクセスするためには、sts:AssumeRoleを使用します。以下にその重要なポイントを簡単に説明します。

`sts:AssumeRole`の基本

sts:AssumeRole は、AWSのセキュリティトークンサービス（STS）が提供する操作で、あるIAMユーザーや役割が別の役割を引き受け、その役割の権限を一時的に得ることができます。

この操作を通じて、ユーザーは別のアカウントのリソースにアクセスしたり、管理者がアクセス権を一時的に付与したりすることができます。

クロスアカウントアクセスを設定するための主な手順

信頼ポリシーの設定（ターゲット役割の設定）

クロスアカウントアクセスを許可するため、ターゲット役割（例えば、Account Bの役割）の信頼ポリシーに、アクセスを許可するアカウントまたはユーザーを指定します。

例：

アイデンティティポリシーの設定（ユーザーの設定）

元のアカウント（例えば、Account A）のユーザーに対して、sts:AssumeRoleを実行するための権限を設定します。

例：

役割の引き受け

ユーザーがsts:AssumeRoleを実行して一時的なセキュリティトークンを取得し、ターゲットアカウントのリソースにアクセスできるようになります。

重要なポイント

信頼ポリシー：ターゲット役割の信頼ポリシーで、どのアカウントやユーザーが役割を引き受けられるかを定義します。

アイデンティティポリシー：リクエスト元のユーザーや役割に、sts:AssumeRoleを実行する権限を与える必要があります。

最小権限の原則：アクセスを必要最小限に抑えるように設定することがセキュリティ向上に繋がります。

`sts:AssumeRole`を使う理由

セキュリティ：一時的なアクセス権を付与することで、長期間のアクセス権の漏洩リスクを減らすことができます。

柔軟性：複数アカウント間でアクセスを制御するのに役立ちます。信頼ポリシーに基づいて細かいアクセス制御が可能です。

これらの手順と概念を理解しておくことで、AWS環境内で安全かつ効率的にリソースを管理できます。

実践

略

一問道場

Question #309

トピック 1

ある企業がAWS Organizationsを使用してマルチアカウント構成を採用しています。このアカウント構成の現在のセキュリティ設定には、SCP（サービスコントロールポリシー）、リソースベースポリシー、アイデンティティベースポリシー、トラストポリシー、セッションポリシーが含まれています。

ソリューションアーキテクトは、Account A のIAMユーザーが Account B のロールを引き受けることを許可する必要があります。

ソリューションアーキテクトがこの要件を満たすために実行する必要があるステップの組み合わせはどれですか？（3つ選択）

A. Account A のSCPを設定してアクションを許可する。

B. リソースベースポリシーを設定してアクションを許可する。

C. Account A のユーザーに対するアイデンティティベースポリシーを設定してアクションを許可する。

D. Account B のユーザーに対するアイデンティティベースポリシーを設定してアクションを許可する。

E. Account B のターゲットロールに対するトラストポリシーを設定してアクションを許可する。

F. セッションポリシーを設定してアクションを許可し、GetSessionToken API操作でプログラム的に渡すことを許可する。

解説:

IAMユーザーが別のアカウントのロールを引き受けるための設定手順

AWS Organizations内のマルチアカウント構成で、IAMユーザーが1つのアカウント（Account A）から別のアカウント（Account B）のロールを引き受けるには、以下の設定が必要です。

必須ステップの詳細

1. アイデンティティベースポリシーの設定 (選択肢C)

設定内容:

Account A のIAMユーザーにアイデンティティベースポリシーを設定し、sts:AssumeRoleアクションを許可する必要があります。
このポリシーにより、IAMユーザーがAccount Bのロールを引き受けることが可能になります。

例: IAMユーザーのポリシー

2. トラストポリシーの設定 (選択肢E)

設定内容:

Account B のターゲットロールにトラストポリシーを設定し、Account A のIAMユーザーまたはその所属アカウントを信頼するように設定します。
トラストポリシーは、ロールの信頼関係を定義し、ロールを引き受けるエンティティ（ユーザーやアカウント）を指定します。

例: ターゲットロールのトラストポリシー

または、Account A 全体を信頼する場合:

3. SCPの設定 (選択肢A)

設定内容:

Account A で適用されるSCP（サービスコントロールポリシー）がsts:AssumeRoleアクションを明示的に許可するか、少なくともブロックしないように設定されている必要があります。
SCPはOrganizations内のすべてのポリシーよりも優先されるため、許可を忘れるとポリシーの設定が無効になります。

例: SCPポリシー

他の選択肢について

B. リソースベースポリシーを設定する

リソースベースポリシーはS3バケットなどに対して使用されるもので、IAMロールには適用されません。そのため、この選択肢は不適切です。

D. Account BのIAMユーザーにアイデンティティベースポリシーを設定する

Account BでIAMユーザーを使用する要件は提示されておらず、ターゲットはロールの設定です。この選択肢は不要です。

F. セッションポリシーを設定する

セッションポリシーは一時的な権限をさらに制限する場合に使用されますが、このケースでは特に要件として求められていません。

正解

A. SCPの設定

C. Account AのIAMユーザーにアイデンティティベースポリシーを設定

E. Account Bのロールにトラストポリシーを設定

310-AWS SAP AWS 「理論・実践・一問道場」AWS Storage Gateway

理論

オンプレミスとクラウドを統合するストレージソリューション: AWS Storage GatewayとS3の活用方法

企業がデータ管理を行う際、オンプレミス環境とクラウド環境を組み合わせたハイブリッドなソリューションを選択することが一般的になっています。その中で、AWS Storage GatewayとAmazon S3は、多くの企業が採用する強力なツールです。本記事では、AWS Storage Gatewayの各種類とS3のストレージクラスについて解説し、要件に応じた最適な組み合わせを提案します。

AWS Storage Gatewayの種類

AWS Storage Gatewayは、オンプレミス環境とAWSクラウドをシームレスに接続するハイブリッドストレージサービスです。以下の3種類があります。

1. ファイルゲートウェイ (File Gateway)

主な用途: ファイルベースのデータの保存とバックアップ

対応プロトコル: NFS, SMB

特徴:

オンプレミスのアプリケーションはファイルシステムをそのまま利用可能。
データはAmazon S3に保存され、必要に応じてS3のストレージクラスに移行可能。
バックアップやアーカイブに最適。

2. ボリュームゲートウェイ (Volume Gateway)

主な用途: ブロックストレージの保存

対応プロトコル: iSCSI

特徴:

アプリケーションのブロックデータをAWSに保存。
スナップショットはAmazon S3またはAmazon EBSに保存される。
データベースや仮想マシンのバックアップに適しているが、NFSには対応していない。

3. テープゲートウェイ (Tape Gateway)

主な用途: テープベースのバックアップとアーカイブの移行

対応プロトコル: iSCSI（仮想テープライブラリを提供）

特徴:

既存のバックアップアプリケーションとの互換性を保ちながら、仮想テープを使用してデータをクラウドに保存可能。
データはAmazon S3に保存され、最終的にはS3 GlacierまたはS3 Glacier Deep Archiveに移行可能。

Amazon S3のストレージクラス

Amazon S3は、コスト、パフォーマンス、アクセス頻度に応じて複数のストレージクラスを提供しています。以下が主なストレージクラスの概要です。

1. S3 Standard

特徴: 高い耐久性、低レイテンシー、頻繁なデータアクセスに適している。

コスト: 高い

2. S3 Standard-Infrequent Access (S3 Standard-IA)

特徴: アクセス頻度が低いデータ向け。低いストレージコストと高い耐久性。

用途: 月に1～2回程度アクセスするデータに最適。

コスト: 中程度

3. S3 Glacier

特徴: アーカイブ用の低コストストレージ。データ取得には数分～数時間。

用途: 頻繁にはアクセスしないが、迅速な復元が必要なデータに適している。

コスト: 低い

4. S3 Glacier Deep Archive

特徴: 最も低コストなアーカイブストレージ。データ取得には最大12時間。

用途: 数ヶ月～数年間アクセスしないアーカイブデータに適している。

コスト: 最も低い

要件に応じたソリューションの選択

1. NFS互換が必要で、アーカイブ後の低コストを重視

推奨ソリューション:

ファイルゲートウェイ + S3 Glacier Deep Archive
この組み合わせは、NFSプロトコルをサポートしつつ、アーカイブ後に最小限のコストでデータを保管することが可能です。災害復旧時に数日待つことが許容される場合に最適です。

2. 頻繁なアクセスが想定されるデータのバックアップ

推奨ソリューション:

ファイルゲートウェイ + S3 Standard-IA
頻繁なデータアクセスを前提としながらも、S3 Standardよりも低コストな選択肢です。

3. テープベースの既存環境をクラウドに移行

推奨ソリューション:

テープゲートウェイ + S3 Glacier
既存のバックアッププロセスを変更せずにクラウドアーカイブを実現できます。

まとめ

AWS Storage GatewayとAmazon S3の組み合わせは、オンプレミスとクラウドを統合したハイブリッドストレージソリューションを構築する上で非常に有効です。要件に応じて適切なゲートウェイタイプとストレージクラスを選択することで、コストを最小化しつつ、高い効率性と信頼性を確保できます。

企業の特定のユースケースに基づいて、これらの選択肢を評価し、最適な構成を実現してください。

実践

略

一問道場

質問 #310

ある企業がオンプレミスのファイルストレージソリューションをバックアップするためにAmazon S3を利用したいと考えています。この企業のオンプレミスのファイルストレージソリューションはNFSをサポートしており、新しいソリューションもNFSをサポートする必要があります。また、バックアップファイルを5日後にアーカイブしたいと考えています。災害復旧のためにアーカイブされたファイルが必要になった場合、この企業はファイルを取得するのに数日待つことを許容しています。

この要件を最も費用対効果の高い形で満たすソリューションはどれですか？

A. AWS Storage GatewayのファイルゲートウェイをS3バケットと関連付けてデプロイします。オンプレミスのファイルストレージソリューションからファイルをファイルゲートウェイに移動します。5日後にファイルをS3 Standard-Infrequent Access（S3 Standard-IA）に移行するS3ライフサイクルルールを作成します。

B. AWS Storage GatewayのボリュームゲートウェイをS3バケットと関連付けてデプロイします。オンプレミスのファイルストレージソリューションからファイルをボリュームゲートウェイに移動します。5日後にファイルをS3 Glacier Deep Archiveに移行するS3ライフサイクルルールを作成します。

C. AWS Storage GatewayのテープゲートウェイをS3バケットと関連付けてデプロイします。オンプレミスのファイルストレージソリューションからファイルをテープゲートウェイに移動します。5日後にファイルをS3 Standard-Infrequent Access（S3 Standard-IA）に移行するS3ライフサイクルルールを作成します。

D. AWS Storage GatewayのファイルゲートウェイをS3バケットと関連付けてデプロイします。オンプレミスのファイルストレージソリューションからファイルをファイルゲートウェイに移動します。5日後にファイルをS3 Glacier Deep Archiveに移行するS3ライフサイクルルールを作成します。

解説

この質問は、オンプレミスのファイルストレージをバックアップするためにAmazon S3とAWS Storage Gatewayを利用し、指定された条件（NFSサポート、アーカイブ後の低コスト、災害復旧時の数日間の待機可能性）を満たす最適な構成を選択する問題です。各選択肢を確認し、要件に合うかどうかを解説します。