「EC2インスタンスを別AZに起動して、Route53によりフェールオーバールーティングを設定する。」は不正解です。Route53によりフェールオーバールーティングを設定することは可能ですが、これは2つのEC2インスタンス間でのフェールオーバー構成を実施することしかできません。今回はELBで複数インスタンス間でのトラフィック分散を実現することが最適な構成となります。
「EC2インスタンスを別AZに起動して、ELBのスティッキーセッションを有効化する。」は不正解です。ELBのスティッキーセッションを有効化すると、同じユーザーのセッションは特定のEC2インスタンスでの処理を継続することができますが、問題の回答とは異なります。
「Amazon S3のバケットポリシーを設定する。」は不正解です。バケットポリシーは、バケットに対してユーザーアクセス権限を設定するバケットに関するポリシーです。オブジェクト単位でのアクセス権限のコントロールにはACLを利用します。今回はオブジェクトへのアクセス権限の設定であるためACLが正解となります。
「CloudFront を使ってコンテンツを提供するように設定を変更し、制限を設ける国からのアクセスを拒否する」が正解です。CloudFront では、GeoIP データベースを使い、地理的ディストリビューションの制限 機能を使うことができます、この機能を利用することで、ある国(地域)からのアクセスに対して 403 (アクセス拒否) のレスポンスを返すことが可能です
AWS Import/Export とは、大量のデータを物理ストレージデバイスから AWS に転送するのに使用できるサービスです。
ポータブルストレージドライブを AWS に引き渡すと、AWS Import/Export サービスでAmazon の高速内部ネットワークを使用してお客様のストレージデバイスからデータを直接インポートしたり、エクスポートしたりすることができます。
ただし、AWS Import/Export では Glacier ストレージクラスのデータを直接エクスポートする機能はサポートしていません。これらのオブジェクトをエクスポートするには、一度S3などにオブジェクトを復元しそのデータをエクスポートするような対応をとる必要があります
「Amazon S3 Transfer Accelerationを利用する。」が正解となります。Amazon S3 Transfer Acceleration を使用すると、クライアントと S3 バケットの間で、長距離にわたるファイル転送を高速、簡単、安全に行えるようになります。Transfer Acceleration では、Amazon CloudFront の世界中に分散したエッジロケーションを利用しています。エッジロケーションに到着したデータは、最適化されたネットワークパスで Amazon S3 にルーティングされます。これによりグローバルに効果的なファイル転送が可能となります。
「CloudFrontを利用したエッジ処理を利用する。」は不正解です。CloudFrontを利用したエッジ処理は配信を効率的にする方法であり、アップロードには利用できません。
AutoScaling を使用した ELB はオンデマンドのスケーリング機能を提供します。また、 CloudFront を使用してキャッシュすると、パフォーマンスが向上し、ウェブサーバーの負荷が軽減されます。
■以下は誤りになります。
「Amazon S3 マルチパートアップロードを使用して、アップロード時間を改善する。」 →Amazon S3 マルチパートアップロードはアップロード時間を改善するだけで、ウェブパフォーマンスの改善には役立たないため間違いです。
Amazon DynamoDB は、オンラインゲーム利用者の状態情報を整合性を保ち保存することができる集中ストレージを提供し、シームレスにスケーリングすることができます。
■以下は誤りになります。
「Amazon S3」
→Amazon S3 は条件付き更新を提供せず、状態情報を保存するのに適していないため間違いです。
「Amazon RDS」
→Amazon RDS はシームレスに拡張されないため間違いです。
「Amazon Redshift」
→Amazon Redshift はデータウェアハウジングであり、状態情報の保存には適していないため間違いです。
「Redshift」が正解となります。Redshiftは列指向データベースであり列集計に優れているDWHとして利用できます。よって、レポーティングやBIに活用できます。Redshiftは高速でシンプルかつ費用対効果の高いデータウェアハウスサービスです。小規模利用からペタバイト単位の構造化データまで、複雑な分析クエリを実行でき、スケールアウトも容易に行うことができます。
「ElastiCache」は不正解です。ElastiCacheはインメモリ型DBとしてキャッシュ処理が可能となりますが、BIやDWHとしての機能はありません。
「Amazon Aurora」は不正解です。Amazon Auroraは高性能なRDBSですが、BIやDWHとしての機能はありません。
「DynamoDB」は不正解です。DynamoDBは高性能なNoSQL型のKVSですが、BIやDWHとしての機能はありません。
1) Amazon Kinesis Video Streams
2) Amazon Kinesis Data Streams
3) Amazon Kinesis Data Firehose
4) Amazon Kinesis Data Analytics
この中で、リアルタイムでストリーミング処理が可能なものは 2) と 3) になりますが、今回の場合何らかのデータストアにストリーミングデータを保存する要件はなく、単純にストリーミングデータをリアルタイム処理したい場合は 2) の Amazon Kinesis Data Streams が適しています。
RDSプロキシは、高可用性フルマネージド型データベースプロキシです。
「RDSプロキシを利用し、データベースに流れるトラフィックを処理する。」が正解となります。RDS プロキシはアプリケーションとRDSデータベースの間の仲介役として機能します。RDS プロキシは、必要となるデータベースへのコネクションプールを確立および管理し、アプリケーションからのデータベース接続を少なく抑える機能です。RDS プロキシは、Lambda関数からデータベースに直接流れるすべてのデータベーストラフィックを処理します。
Lambda関数はデータベースインスタンスではなくRDSプロキシを利用して接続することが求められます。RDSプロキシは、Lambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングします。これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用できます。
「Lambda関数をSQSによるポーリング処理と連携してRDSへのデータ処理を行う。」は不正解です。Lambda関数だけで処理分散化が可能であるため、SQSポーリング処理と連携してRDSへのデータ処理を分散化するといった構成は非効率です。
「LambdaをRDSに連携して、データ処理を実施する関数を作成する。」は不正解です。Lambda関数はRDSを直接利用することが可能ですが、同時実行されることでコネクションを多数確立することになり、プロキシを利用しないとデータセッションが効率的に継続させることができません。
「RDSのスティッキーセッションを有効化する。」は不正解です。RDSのスティッキーセッションという機能はありません。
パフォーマンスが大きく低下し、特に読取パフォーマンスが低下している問題です。リードレプリカの増設、インスタンスタイプの高性能なタイプへの変更、ElastiCacheの併用が考えられます。コストを要するものの、パフォーマンスが高いソリューション方式はElasticacheを利用した方式です。ElastiCacheをRDSの前面に配置することでRDSの読取処理が多いデータをキャッシュとして保持できます。インメモリDBであるElasticacheは他のDBと比較しても非常に高価ですが、性能が最も高いDBの一つです。したがって「RDSの前面にElastiCacheを配置する。」が正解となります。
「RDSのリードレプリカを使用する。」は不正解です。RDS リードレプリカを使用することでデータベース (DB) インスタンスのパフォーマンスと耐久性が向上しますが、ElastiCasheほどの効果は見込めません。
「RDSのAutoScaling機能をオンする。」は不正解です。RDSのオートスケーリングはストレージ容量を増加させる機能であり、パフォーマンスを向上する仕組みではありません。
Elastic Beanstalk は、Java、.NET、PHP、Node.js、Python、Ruby、Go および Docker を使用して開発されたウェブアプリケーションやサービスを、Apache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするためのサービスになります。
Elastic Beanstalk は自動的にデプロイメントの詳細 (容量のプロビジョニング、負荷分散、Auto Scaling、アプリケーションのヘルスモニタリングなど) を処理します。Elastic BeanstalkのユースケースとしてはWEBアプリケーションやワーカー環境などの構築によく用いられます。したがって、WEBアプリケーションを展開する際にElastic Beanstalkを利用しますので、「Amazon RDSを利用したWEBアプリケーションへの適用を検討する。」が正解となります。
AWS Transit Gatewayは、中央ハブを介して VPC とオンプレミスネットワークを接続できます。
「AWS Transit Gatewayの利用」が正解となります。AWS Transit Gateway を使用すれば、中央のゲートウェイからネットワーク上にある Amazon VPC、オンプレミスのデータセンター、リモートオフィスそれぞれに単一の接続を構築して管理することができます。Transit Gateway がハブの役割を果たし、トラフィックがスポークのように接続されたネットワーク間のルーティングを制御します。このようなハブアンドスポーク型では、各ネットワークを Transit Gateway にのみ接続する必要があり、他のすべてのネットワークに接続する必要がないため、大幅に管理を簡略化して運用コストを削減できます。新たに VPC を追加する場合は、Transit Gateway に接続するだけで、同じ Transit Gateway に接続されている他のネットワークにも自動的につながります。このように接続が簡単なため、成長に合わせてネットワークを難なくスケールできます。
PS (Intrusion Prevention System)は、不正侵入防止システムである。ネットワークやサーバーを監視し、不正なアクセスを検知して管理者に通知する役割を担うシステムとしてIDS(Intrusion Detection System:不正侵入検知システム)があります。
インスタンスまたはリバースプロキシ層に IDS/IPS エージェントを実装することで解決できます。
■以下は誤りになります。
「各サブネット内のインスタンスのネットワークインタフェースカードをプロミスキャスモードに切り替え、ネットワークトラフィックを分析します。」
→AWS はプロミスキャスモードを設定することができず、各 VPC、サブネットはそれ用のトラフィックのみを受信します。
「ウェブアプリケーションのフロントに SSL リスナーを持つ ELB を実装します。」
→SSL を使用した ELB は IDS/IPS として機能しないため間違いです。
「リザーブドインスタンス を選択する」が正解です。リザーブドインスタンスは、1~3 年の期間、インスタンスタイプとリージョンを含む一定のインスタンス設定を守ることにより Amazon EC2 コストを削減する購入オプションで、今回のような負荷が常時一定で、リソースの増強が不要(インスタンスタイプを変更する可能性が低い)な場合に適しています。
「S3 標準 – 低頻度アクセス を利用する」が正解です。S3 標準 – 低頻度アクセス(IA: infrequent access)のストレージクラスは、存続期間が長く、アクセス頻度の低いデータ用に設計されています。また、S3 標準と同じ高い耐久性、高スループット、低レイテンシーを低価格のストレージ料金(GB 単位)および取り出し料金(GB 単位)で提供します。今回のような、不定期にアクセスされる、アクセス頻度の高くないデータの保存先として適しています。
S3 標準では費用対効果は高いとは言えず、S3 低冗長化ストレージは冗長化レベルが下がるため、あまり推奨できません。S3 Glacier は取り出しに時間を要し、アーカイブとしての用途が想定されているため、今回の要件に適しているとは言えません。
「クラスタープレイスメントグループをアベイラビリティゾーン内に構成し、当該グループで EC2 インスタンスを動作させる」が正解です。通常 EC2 インスタンスのハードウェアへの配置は、AWS 側で可能な限り分散させらます。一方で、ユーザ側のニーズに応じて、物理配置をコントロールする機能が用意されています。それをプレイスメントグループと呼び、問題の、HPCのような低レイテンシーかつ高いスループットの要件を満たすためにはクラスタープレイスメントグループを利用します。他にもパーティションプレイスメントグループ、スプレッドプレイスメントグループといったグループが利用可能です。
Amazon RDSはリージョンサービスであるため、マルチリージョンに展開して可用性を高めることが出来ません。
しかし、AZ単位で跨ぐ事は可能であり、各AZ間も地理的に十分離れている事が保証されているため、安全性は担保されています。その他選択肢は間違いです。
データをキャッシュできるインメモリ型が特徴である⇨ElastiCacheの説明になります。
Amazon Redshiftとは、AWSが提供するデータウェアハウスサービスです。
データウェアハウス(DWH)というのは、さまざまなデータ源からデータを収集・統合・蓄積し、分析のため保管しておくシステムです。一般的なRDBMSとは違って、継続的な書き込みや更新よりも一括でデータを書き込み分析のため大容量データを読み出すという処理に最適化されています。
Redshiftを使うと、保存されている大規模なデータに対して分析クエリを実行できます。Amazon S3 に保存されているデータに対しても分析クエリを直接実行することができます。
「バケットポリシー及びユーザーポリシーにて、もう片方のアカウントのアクセス許可を付与する」が正解です。別のAWSアカウントに自分が所有するS3バケットへのアクセス利用を許可したい場合、バケットポリシー及びユーザーポリシーの両方の許可設定が必要です。
「Amazon DynamoDB のリザーブドキャパシティを購入する」「Amazon Redshift のリザーブドノードを購入する」及び「Amazon ElastiCache のリザーブドノードを購入する」が正解です。これらのサービスや EC2 に加え、RDS のリザーブド DB インスタンス、Elastic search Service のリザーブドインスタンスなどがリザーブド購入オプションとして存在します。
S3 Standard-IA とS3 One-Zone-IAのストレージクラスは、存続期間が長く、アクセス頻度の低いデータ用に設計されています。
このシナリオにおける問題を解決する最良の方法は、S3でライフサイクルポリシーを作成して古い写真をInfrequent Accessストレージクラスに移動し、ストレージのコストを下げることです。写真は6カ月たつとアクセス頻度が減少するので、Infrequent Accessストレージクラスをアクセス頻度の低いデータを保存するのに適したストレージクラスとして選択します。 したがって、「S3のライフサイクルポリシーを設定して、Standardクラスから一定期間を経過するとStandard-IAクラスへと移行する。」が正解となります。
「S3のライフサイクルポリシーを設定して、一定期間が経過するとS3 StandardクラスからRRS(低冗長化ストレージ)へとデータを移行する。」は不正解です。RRSは現在はAWSに非推奨ストレージとなっています。
「S3のライフサイクルポリシーを設定して、一定期間が経過するとS3 StandardクラスからGlacierへとデータを移行する。」は不正解です。Glacierへの移行は長期保存用データになるため、すぐにアクセスが必要なファイルには不適切です。このソリューションを実装すると、ユーザーは古い写真データを取得するのに長時間待たなければなりません。迅速にアクセス可能な設定でも最大5分かかることになり、ユーザーのクレームにつながる可能性があります。
「S3のライフサイクルポリシーを設定して、Standardクラスから一定期間を経過するとOne-Zone-IAクラスへと移行する。」は不正解です。One-Zone-IAはInfrequent Accessストレージクラスの1つですが、複数AZにオブジェクトを分散して冗長化しないため可用性が低い分、値段が安いストレージタイプとなっています。
Amazon RDS for PostgreSQL はスタンドアロン DB インスタンスであり、マルチ AZ 配置を有効にすることで高可用性を提供できます。
Amazon RDS は、マルチ AZ 配置を使用して DB インスタンスの高可用性およびフェイルオーバーサポートを提供します。Amazon RDS は複数の異なるテクノロジーを使用してフェイルオーバーサポートを提供します。Oracle、PostgreSQL、MySQL、MariaDB DB インスタンスのマルチ AZ 配置では、Amazon のフェイルオーバーテクノロジーが使用されます。SQL Server DB インスタンスでは SQL Server データベースのミラーリング (DBM) が使用されます。
■以下は誤りになります。
「Amazon S3 バケットでクロスリージョンレプリケーションを有効にします。」
→Amazon S3 は 99.99 % の可用性を提供し、データは複数の施設に複製されるため間違いです。
「アプリケーションがデプロイされている各アベイラビリティーゾーンに Lambda 関数を作 成します。」
→AWS Lambda はサーバーをプロビジョニングまたは管理せずにコードを実行できるため間違いです。
「Amazon DynamoDB テーブルの DynamoDB ストリームを作成します。」
→DynamoDB はサーバーレスであり、プロビジョニング、パッチ適用、管理するサーバーは不要です。可用性とフォールトトレランス機能が組み込まれているため間違いです。
汎用SSDは、コストと性能バランスが良く、開発環境やテスト環境など、幅広い用途での利用に適しています。
「汎用SSD」が正解となります。汎用SSDは幅広いトランザクションワークロードに対応できる価格とパフォーマンスのバランスが取れたSSDです。200GBのRDSを利用している小規模なシステムであることが分かります。ピーク時間が4時間ほど集中しているものの高速アクセスは必要ないと考えると汎用SSDで対応可能と判断できます。
「スループット最適化HDD」は不正解です。スループット最適化HDDは高いスループットを必要とするアクセス頻度の高いワークロード向けの低コストの HDD ボリュームであり、こちらもスループットで高い性能が期待しつつ、プロビジョンドIOPS SSDよりも低コストで実現することができます。コスト最適を求める場合に選択します。今回の要件ではスループット性能は特に求められていないため不適切です。
「EFS」は不正解です。Amazon EFS は、レイテンシーの影響を受けやすい単一スレッドのワークロードに可能な限り高いスループットを必要とする、高度に並列化されたスケールアウト型ワークロードの多様なユースケースをサポートするのに利用します。今回の要件では最適なEBSボリュームを選択する必要があります。
「EBSプロビジョンドIOPS SSD」は不正解です。プロビジョンドIOPSはレイテンシーの影響が大きいトランザクションワークロード向けに設計された極めてパフォーマンスの高い SSD ボリュームです。コストが高いですが最も高い性能が期待できます。今回の要件ではI/O性能やスループット性能は特に求められていないため不適切です。
「コールドHDD」は不正解です。EBSのコールドHDDはアクセス頻度の低いワークロード向けに設計された極めて低コストの HDD ボリュームです。今回の要件ではアクセス頻度が低いボリューム利用は求められていません。
Auto Scalingでは、SQSのキューサイズ(メッセージの数)に応じて、EC2インスタンスを増やす仕組みを作ることができます。
「SQSキューサイズを確認するAutoScalingトリガーを構成して対応する。」が正解となります。SQSキューの需要の変化に応じて Auto Scaling グループをスケールすることができるため、SQSキューサイズを確認するAutoScalingトリガーを構成することで、SQSキューサイズに応じてEC2インスタンスのAutoScalingを実行できます。
Amazon SQS キューのアクティビティに応じたスケーリングを検討するシナリオはいくつかあります。今回はユーザーがイメージをアップロードしてオンラインで使用できるウェブアプリケーションです。このケースではアプリケーションは処理のためイメージの raw ビットマップデータを Amazon SQS キューに配置します。イメージが処理され、処理されたイメージはユーザーから確認できる場所に発行されます。したがって、SQSキューサイズの増加に応じたAutoScalingを設定することで、イメージ処理がひっ迫しないようにスケールすることができます。
AWS DataSync は、オンプレミスストレージと Amazon EFS 間でデータを迅速かつ簡単に移動することができるマネージド型のデータ転送サービスです。
DataSync を使用すれば、オープンソースツールと比べて最大 10 倍の速度で、データセットを AWS Direct Connect またはインターネット経由で転送できます。アプリケーションを変更したり、API に書き込む必要はありません。
このサービスは、1 回のデータ移行、定期的な同期、およびデータの保護と復元のレプリケーションに使用できます。
AWS バックアップはAmazon EFS ファイルシステムの中央管理とバックアップの自動化が簡単にできるフルマネージド型のバックアップサービスであるため、不正解です。
AWS Server Migration Service は、オンプレミスの VMware vSphere、Microsoft Hyper-V/SCVMM、または Azure 仮想マシンの AWS クラウドへの移行を自動化するサービスであるため、不正解です。
AWS Direct ConnectはオンプレミスのサーバーとAWSを専用の回線でつなぐサービスです。
AWS DKRは存在しないため、不正解です。
インスタンスストアは無料となります。
インスタンスストアは、頻繁に変更される情報 (バッファ、キャッシュなど) の一時ストレージに最適です。
■EBS
EC2インスタンスストアとネットワーク接続
単一のAZ内で冗長化
ボリューム拡張可能
従量課金
■インスタンスストア
ホストコンピュータのストレージを利用
冗長化されない
ボリューム拡張不可能
無料
Amazon Gracierは、アクセス頻度の低いデータのアーカイブと長期バックアップのための安全で耐久性が高く低コストなストレージです。
S3と比較してデータ保管にかかるコストを大幅に抑えることができますが、データの取り出しの際には費用がかかります。
取り出しオプションは以下のものがあります。
迅速 — 迅速取り出しではデータが必要になった場合、すばやくアクセスできます。通常 1〜5 分以内で使用可能になります。
標準 — 標準取り出しでは、数時間以内にすべてのデータにアクセスできます。通常、標準取り出しは 3〜5 時間で完了します。(デフォルト設定)
大容量 — 大容量取り出しは、S3 Glacier の最も安価な取り出しオプションであり、これを使用して大量のデータ (ペタバイトのデータを含む) を 1 日以内に低コストで取得できます。通常、大容量取り出しは 5〜12 時間で完了します。
コンバーティブルでしか変更できない設定は以下のとおりです。
・インスタンスファミリー
・OS
・テナンシー
・支払オプション
したがって、インスタンスのファミリー変更が正解となります。
なお、コンパーティブルでは変更できる設定が多いため、割引率が低く設定されています。
Accelerated VPN connectionは、オンプレミスネットワークから利用者のゲートウェイデバイスに最も近いAWSエッジロケーションにトラフィックをルーティングするサービスになります。
「Accelerated サイト間 VPN を利用する。」は正解となります。Accelerated サイト間VPNは Global Acceleratorを利用したサイト間VPN です。VPNの通信は AWS グローバルネットワークを経由して接続されるため、 高可用性・高パフォーマンスが維持されます。VPCにおいてAcceleration を有効にすると、AWS グローバルネットワークを使用してパフォーマンスを向上させられます。カスタマーゲートウェイデバイスのトラフィックは、最も近い AWS エッジロケーションを経由してルーティングされ、AWS の VPN エンドポイントに到達します。
「AWS Storage Gatewayを接続する。」は不正解です。AWS Storage Gateway は、オンプレミスから実質無制限のクラウドストレージへのアクセスを提供するハイブリッドクラウドストレージサービスです。Storage Gateway を使用して、ストレージ管理を簡素化し、ハイブリットクラウドストレージの用途でコストを削減できます。
「VPCエンドポイントを利用する。」は不正解です。VPC エンドポイントは、AWS PrivateLink がサポートされている AWS サービスや VPC エンドポイントサービスに VPC をプライベートに接続できます。これはAWS内部のリソース間接続用の仕組みであるため不正解です。
「Direct Connectを利用してオンプレミス環境とAWSとを接続したハイブリッド環境を設定する。」は不正解です。AWS Direct Connect はプレミスから AWS への専用ネットワーク接続の構築を簡単に行えるソリューションです
Trusted Advisorを利用することで、使用率の高い全てのEC2インスタンスを検出することができます。
Trusted Advisor は AWS で利用している EC2 や RDS などのサービスを「コスト」「セキュリティ」「パフォーマンス」「耐障害性」「サービスの制限」について、ベストプラクティスに基づいたアドバイスを自動的に行なってくれるサービスです。
「アクセス制御に関する推奨項目」が正解(Trusted Advisor によって推奨されない観点)です。Trusted Advisor は、「コスト最適化」「パフォーマンス」「セキュリティ」「耐障害性」「サービスの制限」といったチェックカテゴリが存在します。
「AMIを別リージョンにコピーする方法」と、「バックアップ用リージョンのアプリケーション構成のAuto ScalingグループのAMI IDに設定する方法」が正解となります。
このシナリオでは、ホットスタンバイやウォームスタンバイなどの構成をメインとは別のリージョンに構築するような対応が必要となります。
この構成を実現するためには、Amazon EC2 インスタンスの Amazon マシンイメージ (AMI) を作成し、別の AWS リージョンにその AMI をコピーします。
また、バックアップ用のリージョンにおいてAuto Scalingグループが設定することが必要な場合は、そこで利用されている起動設定のAMI IDに既存構成のAMIを利用する必要があります。その場合は、新しいAMIを指定してあらためてAutoScalingグループを設定し直して下さい。
「バックアップ用のリージョンのELBのAMI IDを変更する方法」は不正解です。
ELBにはAMI IDは設定しません。
「スナップショットを別リージョンにコピーする方法」は不正解です。
スナップショットはEBSのコピーだけであり、AMIはEBSのコピーとインスタンスの設定の両方が含まれています。
「CloudFormationに別リージョンにおけるAMI IDをセットアップする方法」は不正解です。
CloudFormationに別リージョンにおけるAMI IDをセットアップすることで、別リージョンでのインフラ構成を展開するための準備をすることも可能ですが、本件は即時起動が要件となっていルため不正解です。
AWS Lambdaなどで、AMIを別リージョンに自動でバックアップするような機構を構築するという手段もあリます。
「Amazon EBS ボリュームを利用する」が正解です。ブロックストレージとしては、EC2 インスタンスストア と EBS ボリュームの 2 つがありますが、EC2 インスタンスストアは EC2 インスタンスが停止してしまうとデータ損失が起こるなど一時的な利用のみが推奨されています。一方で、EBSボリュームについては、SSD も選択でき、低レイテンシーかつ高スループットが期待できる EBS 最適化インスタンスと併せて利用することも可能です。なお、Amazon EFS はファイルストレージで、S3 はオブジェクトストレージとなります。
・ASGはEC2インスタンスを起動する際に一定の時間を必要とするため、EC2インスタンスが起動するまでにメッセージが失われないようにどこかに保存しておく必要があります。これは疎結合・分離を実現する典型的な使用例で、SQSはまさにこの目的のために設計されています。
・Amazon Simple Queue Service(Amazon SQS)は処理待ちのメッセージを保存するメッセージキューを提供するWebサービスです。SQSはコンピューター間で転送中のメッセージを保存するために、信頼性が高く拡張性の高いホスト型キューを提供します。
・メッセージが256KBを超えなければSQSに保存するのが最も基本的な方法です。256KBを超えるような場合は、拡張クライアントライブラリを使用してS3にメッセージを保存できます。
・ELBは背後のEC2インスタンスにリクエストを分散するのに役立ちますが、ASGのメッセージ処理に間に合うような十分な速度でスケーリングすることができないため、適切な対策ではありません。
「ターゲットグループでのヘルスチェックが可能であるため」と「パスベースルーティング(URLのパスに基づいてアクセスを特定のインスタンスに誘導すること)が可能であるため」が正解となります。
ALBの特徴は以下の通りです。
・L7に対応
・パスベースルーティングが可能
・WebSocketとHTTP/2のリクエストを受付るL7に対応
・1インスタンスに複数ポートを登録可能
・EC2インスタンスをターゲットグループに割り当てる際、複数ポートを個別のターゲットとして登録することが可能なため、特定の処理を複数ポートで負荷分散することができる
・ターゲットグループでのヘルスチェックが可能
・アクセスログの情報追加
・EC2と同様に削除保護が可能
・ALB自体が自動的にキャパシティを増減
可能
ELBにはALB, NLB, CLBの三種類があり、それぞれ異なる特徴を持っています。用途に応じた最適な選択を心がけましょう。
「Multi-AZ デプロイメントの Amazon Aurora (MySQL) のクラスターを構築し、複数のリードレプリカを保持する。 また、リーダーエンドポイントを作成し、レポート表示の処理時はこれを利用する」が正解です。Amazon Aurora では DBインスタンスで、クラスターを構成することができ、各DBインスタンスに負荷分散することができる、エンドポイントを作成可能です。今回レポートの表示(データの読み取り)がアクセス過多のため遅延を引き起こしているため、複数のデータベースで処理できるよう、Aurora のリードレプリカとリーダーエンドポイント機能の利用が適しています。なお、スケーラビリティでは DynamoDB も優れていますが、NoSQL のためアプリケーションの改修が必須となりますし、最適とは言えません。
単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。 サポートされているインスタンスタイプとともにプレイスメントグループを使用すると、アプリケーションが低レイテンシーの 10 Gbps (ギガビット/秒) ネットワークに参加できるようになります。
「プレイスメントグループを設定した上で、M5インスタンス群を起動する。」が正解となります。 Amazon EC2 M5 インスタンスは、次世代の Amazon EC2 汎用コンピューティングインスタンスです。M5 インスタンスは、さまざまなワークロード向けに、コンピューティング、メモリ、ネットワーキングリソースをバランスよく提供しています。したがって、選択肢にあるM5インスタンスを利用してプレイスメントグループを設定することが最適です。
新しい EC2 インスタンスを起動する場合、EC2 サービスは、相関性のエラーを最小限に抑えるために、すべてのインスタンスが基盤となるハードウェアに分散されるようにインスタンスを配置します。プレイスメントグループを使用することで、ワークロードのニーズに対応するために独立したインスタンスのグループのプレイスメントに影響を与えることができます。この設定は先にプレイスメントグループを構成した上で、その中でインスタンスタイプとインスタンス数を決定します。
「プレイスメントグループを設定した上で、T3インスタンス群を起動する。」と「T3インスタンス群を起動した上で、プレイスメントグループを構成する。」は不正解です。T3 インスタンスは、ベースラインレベルの CPU パフォーマンスを提供する次世代のバースト可能な汎用インスタンスタイプで、いつでも必要な時間だけ CPU 使用率をバーストさせる機能を備えています。しかしながら、クラスタープレイスメントグループによる設定ができないインスタンスタイプとなっています。
「M5インスタンス群を起動した上で、プレイスメントグループを構成する。」は不正解です。プレイスメントグループの設定は先にプレイスメントグループを構成した上で、その中でインスタンスタイプとインスタンス数を決定することが必要です。
Cross-Origin Resource Sharing(CORS)は、特定のドメインにロードされたクライアントウェブアプリケーションが異なるドメイン内のリソースと通信する方法を定義することが出来ます。
S3のCross-Origin Resource Sharing (CORS) を有効化すると、他のドメインへのS3リソースの共有が可能となります。CORSは特定のドメインにロードされたクライアントウェブアプリケーションが異なるドメイン内のリソースと通信する方法を定義します。これによって、Amazon S3 を使用して機能豊富なクライアント側ウェブアプリケーションを構築し、Amazon S3 リソースに対するクロスオリジンアクセスを選択的に許可することができます。したがって、「S3のCORS(Cross-Origin Resource Sharing)を有効化する。」が正解となります。
「Amazon S3 Transfer Accelerationを利用する。」は不正解です。Amazon S3 Transfer Acceleration を使用すると、クライアントと S3 バケットの間で、長距離にわたるファイル転送を高速、簡単、安全に行えるようになります。
「事前署名付きURLを利用したコンテンツ共有を実装する。」は不正解です。S3の事前署名付き URL を作成した場合、そのURLの有効期限内での特定プロジェクトの共有ができます。これはアクセス制御全般を実施するのではなく、オブジェクトの制限付き共有で利用するものです。
「STSによる一時認証情報を利用する。」は不正解です。STSによる一時認証情報によって、S3へのアクセス許可を設定することはアプリ機能として可能ではありますが、S3バケットの共有であればCORSを利用する方が容易に設定可能です。
SNSのエンドポイントとは、SNSから送信されるメッセージの受信方法のことを指しています。エンドポイントには、HTTP/HTTPS、AWS Lambda、Eメール、SQS、SMS、モバイルプッシュ通知を利用することができます。
XMLは利用することができません。
マルチパートアップロードは、API を使用して大容量オブジェクトをいくつかに分けてアップロードすることができます。
「Amazon S3のマルチパートアップロードを利用する。」が正解となります。マルチパートアップロード API を使用すると、大容量オブジェクトをいくつかに分けてアップロードできるようになります。この API では、新しい大容量オブジェクトをアップロードしたり、既存オブジェクトのコピーを作成したりできます。
「Amazon S3のクロスリージョンレプリケーションの設定を有効化する。」は不正解です。Amazon S3のクロスリージョンレプリケーションの設定を有効化することで、データの冗長性を高めることができますが、アップロードとは無関係です。
「S3の高速アップロードを有効化をする。」は不正解です。Amazon S3の高速アップロードという機能はありません。
「S3のアップロードレプリケーションの設定を有効化する。」は不正解です。Amazon S3のアップロードレプリケーションという機能はありません。
「CloudFront エッジロケーションの場所」、「CloudFront へのリクエスト数」および「CloudFront からのデータ転送量(アウトバウンド)」の 3 つが正解です。Amazon CloudFrontの料金は、AWS からのデータ転送と、ユーザーへのコンテンツ配信に使用されるリクエストによって算出されます。
1) CloudFront エッジロケーションの場所
エッジロケーションの場所、つまり地域によって料金設定が異なります。
2) CloudFront へのリクエスト数
HTTP (HTTPS) のリクエスト数で金額が決まります
3) CloudFront からのデータ転送量(アウトバウンド)
各エッジロケーションから転送されるデータ量によって金額が決まります。
スティッキーセッションが正解となります。
スティッキーセッションは、同じユーザの同じセッションのアクセスを全て、同じEC2インスタンスに送信する機能です。
ELBの負荷分散機能は配下のEC2の負荷に応じて、複数のEC2インスタンスにアクセスを振り分ける機能であるため不正解です。
Connection Drainingは登録解除されるか異常が発生したインスタンスへの新規リクエスト送信を中止する機能であるため不正解です。
SSL Terminationは ELBにSSL Terminationを設定して、ロードバランサー側でSSL認証を行ってくれる機能であるため不正解です。
「スティッキー」という単語は「粘着する」という意味があるため、同じユーザーの同じセッションのアクセスは「粘着的に」同じEC2に送信すると考えれば覚えやすいでしょう。
「複数のRDS DBインスタンスを構築し、データをShardingする。」は正解となります。Shardingはデータベース内の複数のテーブルにデータを分割するための一般的な概念です。水平分割(horizontal partitioning)とも。 リクエスト増加などで単一のマスターDBの運用で限界がある場合に、 一定のルールに従いデータを複数のDBに振り分けることでアクセスを分散させることができます。
「RDS DBインスタンスにAuto Scalingグループを設定し、CloudWatchでCPU利用状況に応じてスケーリングを行う。」は不正解です。2019年6月より、RDSのストレージに対するAuto Scalingが利用可能となりました。これにより、増加するデータベースのワークロードに応じてストレージ容量がダウンタイムなしで自動的にスケールされます。しかしながら、あくまでのストレージ容量のスケーリングのため、不正解となります。
「RDS DBインスタンスに対してマルチAZ構成を有効にする。」は不正解です。マルチAZ構成は一方のAZのRDSが停止した際にもう一方のRDS DBに移行することが出来るという冗長化構成であって、もしものときにシステムを停止させないために取る構成です。読み取り速度の性能が向上することはありません。
MFAとは多要素認証のことです。MFA Deleteを有効にすると削除時に追加認証を求められるようにすることができ、誤削除を予防できます。また、S3でバージョン管理を有効することでファイルの過去のバージョンが自動で保存されるため、誤って削除された場合にもファイルを復元することができます。
アクセスキーを使うと、誰でも同じレベルのリソースにアクセスできてしまいます。そのため長期的に有効なアクセスキーではなく、一時的な認証方法であるIAMロール割り当ての方がよりセキュアとされています。
「CloudFront」が正解です。Cloud Front は、静的及び動的な Web コンテンツの配信を高速化するサービスです。エッジロケーションは、世界各地にあるAWSのデータセンターで、CloudFront はユーザが最も低レイテンシーとなるエッジロケーションからコンテンツを提供かつキャッシュしてくれるサービスとなります。また CloudFront は CDN(Content Delivery Network)の位置づけとなっています。
「Parameters セクション」が正解です。実行時に (スタックを作成または更新するとき)、テンプレートに渡すことができる値を指定します。Description セクション は、テンプレートの説明を記入するセクションで、Resources セクションは
必ず記載しなければならない AWS のリソース (EC2 や S3) 及びプロパティを含むセクションとなります。Outputs セクションは、スタックのプロパティを確認すると返される値について説明します。
「Address キー」が正解(存在しないキー)です。Egress キーはアウトバウンド(出ていく)またはインバウンド(入ってくる) トラフィックに対するものなのかを判断します。Cidrblock キーは送信先(アウトバウンドの場合)あるいは、送信元(インバウンドの場合)の IP を CIDR 表記で記載します。(例: 172.16.0.0/24) RuleAction キーは拒否するか許容するかのいずれかを指定します。
「AWS Elastic Beanstalk を使用する」が正解です。Elastic Beanstalk を使用すると、アプリケーションを実行しているインフラストラクチャについて知識を得なくても、AWS クラウドでアプリケーションのデプロイと管理を簡単に行うことができます。アプリケーションをアップロードするだけで、Elastic Beanstalk は容量のプロビジョニング、ロードバランシング、スケーリング、およびアプリケーション状態モニタリングを自動的に処理します。
CodeDeployはデプロイのみ、CloudFormationはプロビジョニングのみとなります。
「AWS Lambdaを使用して対象ジョブを稼働させる方法」が正解となります。
LambdaではC#プログラミング言語でコードを実行する機能があります。Lambda はサーバー管理の手間なくコードを実行できるコンピューティングサービスです。AWS Lambdaは必要時にのみコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的に拡張できます。
そのほかの選択肢は不正解です。
AWS ConfigやDynamoDBやAWS Batchでは、C#プログラミング言語のジョブをホストすることはできません。
CloudWatchイベントや、その他S3のイベント等をトリガーにしてLambda関数を起動するよう設定することで、定期的なジョブの実行が可能になります。
Aレコード:ドメイン名からIPアドレスを解決するのはAレコード
CNAMEレコード:ドメイン名から別のドメイン名を参照するレコード
MXレコード:対象ドメイン宛のメール配送先ホスト名を定義するレコード
NSレコード:DNSで定義されるそのドメインについての情報の種類の一つで、ドメインのゾーン情報を管理するDNSサーバを定義するレコード
Amazon Kinesis でストリーミングデータをリアルタイムで収集、処理、分析することが簡単になるため、インサイトを適時に取得して新しい情報に迅速に対応できます。
データレコードはKinesisストリームに加えられてからデフォルトで24時間以内までアクセスできるように設定されています。現行のアーキテクチャ構成では、ストリームデータは処理のために週末にS3に送信されます。そのためS3に即時に送信していないため24時間超過したデータはアクセスできず、全てのデータが送られていない状況が発生してしまっている可能性が高いです。したがって、「デフォルトでは、データレコードがKinesisストリームに投入されてから24時間以内までアクセスできるように設定されている。」が正解となります。
「デフォルトでは、S3は限られた24時間以内のデータのみを蓄積する設定を行っている。」は不正解です。S3ではなく、「ストリームデータからS3に送信される際にトラブルが生じている。」は不正解です。ストリームデータからS3に送信される際にトラブルが生じている場合は、処理エラーが発生していることが即時に確認されます。本件はデータ処理が正常に動いているため正しくありません。
「KinesisストリームによるIoTデータ取得の設定範囲が限定的になっている。」は不正解です。KinesisストリームによるIoTデータ取得の設定範囲が限定的になっているかどうかは、IoTデータ取得範囲の仕様決定となるため、正しくありません。
■Amazon S3 Glacierは保管されるデータはすべて、サーバー側で暗号化されます。Amazon Glacier によって、キー管理とキー保護が自動的に行われます。Amazon Glacier では、ブロック暗号の中で最も強力である 256 ビット Advanced Encryption Standard (AES-256)が使用されます。256 ビットは、AES に対して定義されているキーサイズの中で最大です。キーをお客様自身で管理する場合は、データを暗号化してからアップロードする必要があります。
AWS Storage Gateway サービスにより、オンプレミスの環境と AWS クラウドの間でハイブリッドストレージが実現されます。このサービスでは、オンプレミスのエンタープライズアプリケーションと、Amazon のブロックおよびオブジェクト型クラウドストレージサービスを利用したワークフローが、業界標準のストレージプロトコルを通してシームレスに統合されます。頻繁にアクセスされるデータはオンプレミスでキャッシュして低レイテンシーのパフォーマンスを実現する一方で、データは Amazon クラウドストレージサービスに、安全かつ耐久性に優れた方法で保存されます。最適化されたデータ転送メカニズムと帯域幅管理機能を備えているため、信頼性の低いネットワークでも利用可能で転送されるデータ量は最小限になります。ユースケースとしては、バックアップとアーカイブ、災害復旧、クラウド内ワークロードのための S3 へのデータ移動、階層化されたストレージなどが挙げられます。
「RDSのインスタンスタイプを低性能なものに変更し、リードレプリカを利用する。」が正解となります。
RDSの読み取りキャパシティを向上させために、以下のような 3 つの対応が考えられます。
1) RDS リードレプリカの利用
2) 高性能なインスタンスタイプに変更してスケールアップする
3) ElastiCacheをRDSの前面に配置する
この中で、最もコストがかからないのは 1) です。AWS マネジメントコンソールを使用して、リードレプリカを既存の DB インスタンスに簡単に追加可能(AWS マネジメントコンソールで、[Create Read Replica] を実行)です。Amazon RDS for MySQL、MariaDB、PostgreSQL、Oracle では、各 DB インスタンスに最大 5 個のリードレプリカを追加できます。 2)、3) は 1) と比較すると、コストが高くなります。したがって、「RDSのインスタンスタイプを低性能なものに変更し、リードレプリカを利用する。」がコスト削減と性能アップを両立させる最適な方法となります。
既存EBSボリュームの暗号化設定を変更することはできないため、「EC2インスタンス停止後、EBSボリュームの暗号化設定を行う」が不正解となります。
暗号化されていない既存のボリュームまたはスナップショットを直接暗号化する方法はありませんが、ボリュームまたはスナップショットを作成することで暗号化できます。
既存EBSボリュームを暗号化するために、以下の順で作業を実施します。
1. 既存EBSボリュームのスナップショットを取得
2. 取得したスナップショットを、[EBS暗号化] を有効化しコピー
3. コピーしたスナップショット(暗号化済み)から EBS ボリュームを作成
4. EC2インスタンスから既存EBSボリュームをデタッチする
5. EC2インスタンスに作成した EBSボリューム(暗号化済み)をアタッチする
NoSQLはRDBのようにテーブル構造に固定することなく、さまざまな形式のデータをそのまま格納できます。
「DynamoDB」が正解となります。DynamoDBはスキーマレスなNoSQLデータベースであり、セッションデータを大量に保存するのに適しています。Amazon DynamoDBでは、AWS内部通信を通じてAZ跨ぎのレプリケーションが自動で行われているため、データ損失することはありません。また、I/Oスループットを調節することができるため、高負荷なWebアプリケーションにも対応させることができます。
「RDS」は不正解です。RDSはSQL型のリレーショナルデータベースであり、顧客データなどの業務データ処理に向いています。セッションデータを管理することも可能ですが、ユースケースとしてDynamoDBのほうがセッション管理に向いているため最適ではありません。
「EBS」は不正解です。EBSはストレージであり、データ管理には向いていません。
「S3」は不正解です。S3はストレージであり、データ管理には向いていません。
Amazon Lexが正解となります。
Amazon Lex は、音声やテキストを使用して対話できる機能をアプリケーションに簡単に追加できるサービスです。Amazon Lex では、音声のテキスト変換には自動音声認識 (ASR)、テキストの意図認識には自然言語理解 (NLU) という高度な深層学習機能が使用できます。
Amazon Polly は不正解です。
Amazon Pollyは文章をリアルな音声に変換するサービスです。発話できるアプリケーションを作成できるため、全く新しいタイプの音声対応製品を構築できます。
Amazon SageMakerは不正解です。
Amazon SageMakerは機械学習モデルを迅速に構築、トレーニング、デプロイできるフルマネージドサービスで、機械学習モデルの構築ステップの全てに対応しています。
Amazon Rekognitionは不正解です。
Amazon Rekognition は画像分析と動画分析の機能をアプリケーションに簡単に追加できるサービスです。Rekognition API に画像または動画を与えるだけで、物体検出や高精度の顔分析および顔認識を行うこともできます。
Amazon LexやRekognitionではAPIが提供されるので、対話機能や画像認識機能を付与したいアプリケーション側からリクエストを送ることで期待する結果をレスポンスとして受診することが出来ます。
AWSではサービス間の連携をAPIで行います。APIを利用するためにはAPI認証情報(アクセスキー、シークレットアクセスキー)が必要になりますが、セキュリティの観点からGithubやプログラムファイルの中にAPI認証情報を直接保存するべきではありません。
API認証情報を使うことなくサービスにアクセスするために、対象サービスへの許可設定をしたIAMロールをEC2インスタンスに割り当てる方法が推奨されています。この方法であればAPI認証情報を直接保存する必要はありません。
共有VPCを利用した際のアクセス制御は、VPC内での制御となるためセキュリティグループでの設定が正解となります。
共有VPCを利用する事により、管理する VPCの数を結果的に減らす事に繋がり、アクセスコントロールを一元化する事が出来ます。
共有VPCは、グループ会社や事業部単位で複数のAWSアカウントを利用しているケースにおいて、非常に有用なサービスと言えます。
test
システムが疎結合であるという事は、あるシステムに障害が発生して稼働を止めてしまっても影響が出ないという事です。
そのため、疎結合にすると初期コストが高くなる場合がほとんどです。
疎結合の対義語である密結合とは、一台のサーバーで全てのサービスが稼働している様な状態です。
密結合の場合、コストを安く抑えられますが機能の置き換えが難しくなる点に注意しましょう。
Amazon EBSスナップショットはリージョンを跨いでコピーすることができます。
スナップショットは増分バックアップです。つまり、最後にスナップショットを作成した時点から、ボリューム上で変更のあるブロックだけが保存されます。
また、スナップショットは取得開始時点のデータを取得します。そのため取得中に変更した内容はスナップショットに反映されません。
Amazon Redshiftは高速でシンプルかつ費用対効果の高いサービスになります。
「Redshift」が正解となります。Redshiftは列指向データベースであり列集計に優れているDWHとして利用できます。よって、レポーティングやBIに活用できます。Redshiftは高速でシンプルかつ費用対効果の高いデータウェアハウスサービスです。小規模利用からペタバイト単位の構造化データまで、複雑な分析クエリを実行でき、スケールアウトも容易に行うことができます。
「ElastiCache」は不正解です。ElastiCacheはインメモリ型DBとしてキャッシュ処理が可能となりますが、BIやDWHとしての機能はありません。
「Amazon Aurora」は不正解です。Amazon Auroraは高性能なRDBSですが、BIやDWHとしての機能はありません。
「DynamoDB」は不正解です。DynamoDBは高性能なNoSQL型のKVSですが、BIやDWHとしての機能はありません。
・ELBを使用する場合は、AutoScalingの設定でELBヘルスチェックを有効にするのが最善の方法です。
ELBヘルスチェックを有効にしない場合、EC2ステータスチェックはELBが正常でないと判断したインスタンスも正常であると判断してしまいます。
この場合インスタンスはELBによってサービスから削除されますが、Auto Scalingによって終了されず起動されたままとなります。
ヘルスチェックの猶予期間の設定では、ヘルスチェックを実行する前に新しいインスタンスが立ち上がるまでの猶予(ウォームアップする)期間を設定することができます。
クラシックロードバランサは、複数のAmazon EC2インスタンスにおける基本的な負荷分散を行うのに最適なロードバランサです。L4レイヤーで負荷分散するため、HTTPやHTTPS以外のTCPプロトコル上で動作するプロトコルにも対応することができます。ただし、 クラシックロードバランサは現在は使用を推奨されていません。
アプリケーションロードバランサは、HTTP / HTTPS トラフィックの負荷分散に最適なロードバランサです。Webサイトのロードバランサとして使用する場合はこのロードバランサが推奨されます。L7レイヤーで負荷分散します。高度なルーティング機能、マイクロサービス、およびコンテナベースのアーキテクチャが必要なアプリケーションに最適です。
CloudFront を使用すると、特定のタイプのファイルを自動的に圧縮して、ビューワーでサポートされていれば、その圧縮ファイルを提供することができます。
ビューワーがリクエストヘッダーに Accept-Encoding: gzip を含めるようのリクエストした場合は、CloudFront が自動的に特定のタイプのファイルを圧縮し圧縮ファイルを供給するように設定できます。コンテンツが圧縮されるとファイルが小さくなるため、ダウンロード時間が短縮されます。場合によっては、オリジナルの 4 分の 1 以下のサイズになることがあります。特に、JavaScript および CSS ファイルでは、ダウンロード時間が短縮されると、ユーザーにウェブページが表示されるまでの時間が短縮されます。また、CloudFront のデータ転送コストは供給されたデータの総量に基づくので、圧縮ファイルを供給すると、非圧縮ファイルを供給するよりもコストが安くなります。
「エッジロケーションによるファイル圧縮処理を実施して経費削減を行う。」が正解となります。オリジンからファイルを取得するときに、CloudFront は各エッジロケーションでファイルを圧縮します。コンテンツを圧縮するように CloudFront を設定すると、既にエッジロケーションにあるファイルは圧縮しません。
「CloudFrontによるキャッシュ保持期間を短縮して経費削減を行う。」は不正解です。CloudFrontによるキャッシ保持期間を短縮してしまうと、キャッシュの有効期限が短くなり、オリジンサーバーからのファイル取得が多くなることで逆にコストが上がる可能性があります。
「オリジンサーバーに設定したS3による配信コンテンツの圧縮処理を実施して経費削減を行う。」は不正解です。S3による配信コンテンツの圧縮処理という機能はありません。
「Lambda@Edgeによるファイル圧縮処理を実施して経費削減を行う。」は不正解です。Lambda@Edgeによるファイル圧縮処理ではなく、CloudFrontのgzip圧縮によってエッジロケーションでファイル圧縮を実施します。
AWS Snowmobileが正解となります。
AWS Snowmobile は、超大容量データを AWS に移動するために使用できるエクサバイト規模のデータ転送サービスです。セミトレーラートラックが牽引する長さ 14 m の丈夫な輸送コンテナで、Snowmobile 1 台あたり 100 PB まで転送できます。Snowmobile を使うと、ビデオライブラリや画像リポジトリ、またはデータセンター全体まで、膨大な量のデータを簡単にクラウドに移動できます。
AWS Snowball は、安全なデバイスを使用して AWS クラウドの内外に大量のデータを転送するペタバイト規模のデータ転送サービスであるため不正解です。
現在はSnowBall Edgeの利用が推奨されており、利用することはありません。
Direct Connectはデータ転送用のサービスではなく、専用線接続サービスであるため不正解です。
AWS Snowball Edge は統合されたストレージとコンピューティング機能を備えた 100 TB のデータ転送デバイスであり、エクサバイト規模のデータ転送には役割不足であるため不正解です。
設問のケースのような一時的なデータの移行ではなく、継続的に送受信が必要な場合はDirect Connectが適切であると言えるでしょう。
・ALBのアクセスログをS3バケットにデータを保存するように構成できます。Amazon EMRは、企業、研究者、データアナリスト、開発者が膨大な量のデータを簡単かつコスト効率よく処理できるようにするウェブサービスです。EMRは、Amazon EC2およびAmazon S3で構成されたHadoopフレームワークを利用します。
・KinesisもEC2も、ホストされたHadoopサービスを提供するサービスではないため不正解です。
・ALBのアクセスログをDynamoDBに配信するように設定することはできないため不正解です。
Amazon DynamoDBにはテーブルで読み込みおよび書き込みを処理するための読み込み/書き込みキャパシティーモードが 2つあります。
読み取り/書き込みキャパシティーモードは、読み取りおよび書き込みスループットの課金方法と容量の管理方法を制御します。
読み取り/書き込みキャパティーモードは、テーブルを作成するときに設定でき、後で変更することもできます。
・オンデマンド
・プロビジョニング済み (デフォルト、無料利用枠の対象)
プロビジョニング済みを選択すると、予め利用者が予測される読み書きの回数を指定しその必要な分の性能が確保されます。この場合、確保された性能に対して課金されます。
5TBが正解となります。
個々のAmazon S3オブジェクトのサイズの範囲は、最小0バイトから最大5テラバイトです。 1つのPUT操作でアップロードできる最大オブジェクトは5ギガバイトです。
マルチパートアップロードとは、大きいサイズのオブジェクトをいくつかに分けてアップロードする方式を指します。
・異なるリージョンのVPC間でもピア接続(VPCピアリング)を作成できます。
異なるリージョンのVPC間で送信されるデータは暗号化されます(トラフィック料金が適用されます)
「すべてのVPCが互いに直接通信する」という要件を満たすためには、網の目のように各VPCが相互に接続される構成としなければなりません。中心となるVPCを一つ決めて各VPCと接続する構成では、他のVPCを中継しての接続(推移的なピアリング)を行うことはできないため、要件を満たすことができません。
VPCエンドポイントは、VPCからサポートされているAWSサービスとプライベートに接続するためのサービスですが、VPCとVPCの接続は提供していません。
ソフトウェアVPN製品を使用してVPC間のプライベート接続を構成することもできますが、この構成を行う場合構築や運用の手間と費用がかかり、帯域幅や遅延などネットワーク上の成約も考慮する必要があるため最良のソリューションとはいえません。
レイテンシールーティングは、最小のレイテンシーで利用できる AWS エンドポイントにユーザをルーティングすることができます。
Route53のレイテンシルーティングを利用して、最適なリージョンにルーティングする。が正解となります。このシナリオでは、アプリケーションユーザーは世界中におり、すべてのユーザーがシステムを頻繁に使用しているわけではなく、一部リージョンで負荷が高くなっているため、Route53によるレイテンシールーティングを利用します。これにより、ユーザーによるリクエストをレイテンシーが良くリクエストに近いリージョンにリダイレクトして、アプリケーションの処理を高速化します。
Route53の位置情報ルーティングを利用して、最適なリージョンにルーティングする。は不正解です。位置情報ルーティングはユーザーの位置情報に基づいてトラフィックをルーティングする場合に使用します。これは処理能力に基づいたルーティングではないため、不適切です。また、DynamoDBは、データ容量に対するオートスケーリングを有効化することなく、マネージド型サービスとして自動でデータ容量が拡張されます。
CloudFrontを利用して、最適なリージョンに配信する。は不正解です。CloudFrontを利用して、最適なリージョンに配信することは本件では求められていません。
Route53のフェールオーバールーティングを利用して、最適なリージョンにルーティングする。は不正解です。Route53のフェールオーバールーティングではなく、レイテンシルーティングによってレイテンシーの相違に基づいた最適なルーティングを設定することができます。
S3 Glacier Deep Archiveは、低コストの Amazon S3 クラウドストレージクラスで、データのアーカイブや長期バックアップに使用できます。
このシナリオでは、データ分析の前後に発生する大量のデータを保存・利用するためのコスト最適な方法が必要となっています。まずはデータをzipまたはtarファイルに圧縮することにより、データの保存コストを削減できます。保存データは12時間以内に取得できる必要があるため、Glacier よりもGlacier Deep Archiveに保存することでコストを抑えることができます。Glacier Deep Archiveはデータは 3 つ以上の AWS アベイラビリティゾーンにまたがって保存され、12 時間以内に取りだすことができるため、「単一のGlacier Deep Archiveに保存する。」が正解となります。
「単一のGlacier (迅速読取オプション)に保存する。」は不正解です。Glacier ではなくGlacier Deep Archiveが最適なストレージタイプです。また、Amazon Athenaはデータ解析用サービスですので、そこにデータを保存し、検索するといったことはできません。
完成したデータセットを圧縮して単一のGlacier (標準)に保存するは不正解です。Glacier ではなくGlacier Deep Archiveが最適なストレージタイプです。S3 Selectで検索することは可能ですが、DynamoDBを利用した検索手法の方が高速に実施することが可能です。
「単一のS3 One-Zone-Infrequent Accessに保存する。」は不正解です。圧縮ファイルに関連付けられたアーカイブIDなどのメタデータをS3に保存するのではなく、DynamoDBを利用する方が最適です。また、Glacier Selectを利用するために、圧縮ファイルに関連付けられたアーカイブIDなどのメタデータを別に保存する必要がありません。
・S3バケットにファイルを保存しS3イベント通知を使用してLambda関数を呼び出して処理する方法が、不定期に処理が発生するアプリケーションで最もコスト効率のよい方法です。
KinesisデータストリームはEC2インスタンスを必要とするので、ファイルを受信していない状態でもインスタンスを起動しておく必要があります。「処理した分のみ課金されるLambdaと安価なストレージであるS3バケットの組み合わせ」ほどコスト効率がよくないため不正解です。
SQSキューでJava用の拡張クライアントライブラリを使用すると、メッセージをS3に保存することができ、2GBまでのメッセージを取り扱う事ができますが、4GBのファイルを扱うことはできません。そのため、不正解です。
なお、SQSキューの通常の最大メッセージサイズは256KBです。
EC2インスタンスを使用してEBSボリュームのデータを処理する方式はEC2インスタンスの稼働時間とEBSのプロビジョニングされた時間に対して費用がかかりコスト効率が高くないため不正解です。
「ELBとのデータ通信においてSSL/HTTPSを利用する方法」と「ストレージやデータベースの暗号化を実施する方法」が正解となります。
SSL / TLSプロトコルを使用するロードバランサーを利用することで、クライアント・サーバー間のトラフィック暗号化が可能になります。
また、AWSではストレージやデータベースに対してシンプルな暗号化ソリューションを提供しており、ストレージ内の保存データ・S3への転送データなどにデータ保護が可能になります。
他の選択肢は誤りです。
IAMによるストレージやDBへのアクセス制御とセキュリティグループによるデータベースへのアクセス制御は、データ保護には無関係です。
AWSの暗号化サービスとしては
S3内の保存データに対する暗号化機能もサポートされており、コンソールでの操作で簡易に実現できます。
AWS SMS(Server Migration Service)が正解となります。
SMSは数千のオンプレミスのソフトウェアを従来よりも簡単に、かつ短時間で AWS に移行できるサービスです。プログラムによる監視を必要とせず、停止せずにサーバーの増分複製の自動化、スケジュール設定、および追跡が可能なため、大規模なサーバーの移行作業を簡単に調整できます。
以下の選択肢は全て不正解となります。
・AWS DMS(AWS Database Migration Service)
一般的に利用されている商用・オープンソースのデータベースとの間でデータを移行するために使用されます。
・AWS ADS(AWS Application Discovery Service)
オンプレミスサーバーのAWSへの移行計画を作成するときにサーバーの設定データ、使用状況データ、動作データを検出するために使用されます。
・Snowball
大量データを移行する際に利用するサービス機器です。
また、AWS SMSは移行プロセス中に使用したストレージリソースの分を除き、無料です。
Amazon DynamoDB は、数ミリ秒台のパフォーマンスを実現するkey-valueおよびドキュメントデータベースです。データは3箇所のAZに保存されます。
DynamoDB は、1 日に 10 兆件以上のリクエストを処理することができ、毎秒 2,000 万件を超えるリクエストをサポートしているほどの高性能なデータベースとなります。しかしながら、リレーショナルデータベースではないためテーブルの結合といった検索の仕方が出来なかったり空文字の利用が出来ないといったデメリットがあります。
課金ベースルーティングは存在しないため不正解です。他の選択肢のルーティングは提供されています。概要は以下の通りです。
レイテンシーベースルーティングは、最もレイテンシーの低いリソースへルーティングします。
位置情報ルーティングは、接続元から地理的に近いリソースへルーティングします。
シンプルルーティングは、指定されたレコードの情報に従ってルーティングします。
SQL Server DB インスタンスでは SQL Server の製品が備えているデータベースミラーリング (DBM)の機能が使用されます。
Oracle、PostgreSQL、MySQL、MariaDB DB インスタンスのマルチ AZ 配置では、Amazon のフェイルオーバーテクノロジーが使用されます。
・ASGはEC2インスタンスを起動する際に一定の時間を必要とするため、EC2インスタンスが起動するまでにメッセージが失われないようにどこかに保存しておく必要があります。これは疎結合・分離を実現する典型的な使用例で、SQSはまさにこの目的のために設計されています。
・Amazon Simple Queue Service(Amazon SQS)は処理待ちのメッセージを保存するメッセージキューを提供するWebサービスです。SQSはコンピューター間で転送中のメッセージを保存するために、信頼性が高く拡張性の高いホスト型キューを提供します。
・メッセージが256KBを超えなければSQSに保存するのが最も基本的な方法です。256KBを超えるような場合は、拡張クライアントライブラリを使用してS3にメッセージを保存できます。
・ELBは背後のEC2インスタンスにリクエストを分散するのに役立ちますが、ASGのメッセージ処理に間に合うような十分な速度でスケーリングすることができないため、適切な対策ではありません。
単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。 サポートされているインスタンスタイプとともにプレイスメントグループを使用すると、アプリケーションが低レイテンシーの 10 Gbps (ギガビット/秒) ネットワークに参加できるようになります。
「プレイスメントグループを設定した上で、M5インスタンス群を起動する。」が正解となります。 Amazon EC2 M5 インスタンスは、次世代の Amazon EC2 汎用コンピューティングインスタンスです。M5 インスタンスは、さまざまなワークロード向けに、コンピューティング、メモリ、ネットワーキングリソースをバランスよく提供しています。したがって、選択肢にあるM5インスタンスを利用してプレイスメントグループを設定することが最適です。
新しい EC2 インスタンスを起動する場合、EC2 サービスは、相関性のエラーを最小限に抑えるために、すべてのインスタンスが基盤となるハードウェアに分散されるようにインスタンスを配置します。プレイスメントグループを使用することで、ワークロードのニーズに対応するために独立したインスタンスのグループのプレイスメントに影響を与えることができます。この設定は先にプレイスメントグループを構成した上で、その中でインスタンスタイプとインスタンス数を決定します。
「プレイスメントグループを設定した上で、T3インスタンス群を起動する。」と「T3インスタンス群を起動した上で、プレイスメントグループを構成する。」は不正解です。T3 インスタンスは、ベースラインレベルの CPU パフォーマンスを提供する次世代のバースト可能な汎用インスタンスタイプで、いつでも必要な時間だけ CPU 使用率をバーストさせる機能を備えています。しかしながら、クラスタープレイスメントグループによる設定ができないインスタンスタイプとなっています。
「M5インスタンス群を起動した上で、プレイスメントグループを構成する。」は不正解です。プレイスメントグループの設定は先にプレイスメントグループを構成した上で、その中でインスタンスタイプとインスタンス数を決定することが必要です。
「拡張VPCルーティングを利用する方法」が正解となります。
Amazon Redshiftの拡張VPC ルーティングを使用すると、Amazon Redshift はクラスターとデータリポジトリ間のすべての通信が特定のVPC を通るよう強制することができます。
「VPCコネクションを利用する方法」は不正解です。
VPCコネクションとしてはVPCピアリングという仕組みがありますが、VPC間の接続に利用されるものであり、設問との要件とは無関係です。
「NATゲートウェイを利用する方法」は不正解です。
NATゲートウェイは外部から接続できないインスタンスからのインターネットアクセスを可能にする機能であり、設問の要件とは無関係です。
「VPCエンドポイントを利用する方法」は不正解です。
VPCエンドポイントを利用することで、VPC外のサービスとの接続や連携ができるようになります。これも設問の宝剣とは無関係です。
拡張 VPC ルーティングが有効でない場合、Amazon Redshift はクラスターとデータリポジトリ間のすべての通信をインターネット経由で送受信します。
SNSのエンドポイントとは、SNSから送信されるメッセージの受信方法のことを指しています。エンドポイントには、HTTP/HTTPS、AWS Lambda、Eメール、SQS、SMS、モバイルプッシュ通知を利用することができます。
XMLは利用することができません。
S3 Selectは、オブジェクトからデータの一部分のみを取り出すことができます。
S3 Selectが正解となります。S3 Selectを利用すれば、クエリ (query-in-place) サービスを使用して、S3 オブジェクト (および AWS の他のデータセット) 全体に対してデータ分析を実行します。S3 Select はオブジェクト全体ではなくオブジェクトデータのサブセットを取得することで、クエリのパフォーマンスを最大 400% 向上させることもできます。
Amazon Redshift Spectrumは不正解です。Amazon Redshift Spectrumを使うことで、Amazon Simple Storage Service (S3)上に置かれたファイルをRedshiftにロードしたり特殊な準備をすることなく、高度なクエリを実行することが可能になります。オブジェクト全体ではなくオブジェクトデータのサブセットを取得した分析を実行するものではないため、正しくありません。また、Amazon Redshift Spectrumは主にビッグデータをS3に蓄積して解析するためのビッグデータソリューションとして利用することを目的としています。
Amazon Athenaは不正解です。Amazon Athena はインタラクティブなクエリサービスで、Amazon S3 内のデータを標準 SQL を使用して簡単に分析できます。Amazon AthenaもS3データに対するSQL解析が可能なツールですが、複雑なクエリや機械学習による推論を実行できるなど、S3 Selectよりも高度な分析に利用することになります。
Amazon CloudSearchは不正解です。Amazon CloudSearch は AWS クラウドにおけるマネージド型サービスであり、ウェブサイトまたはアプリケーション向けの検索ソリューションを容易かつコスト効率良く設定、管理、スケールできます。
セキュリティグループは、インスタンスへのアクセス制御をテンプレート化できる機能です。
SSH ポートの番号は 22 であり、セキュリティグループはステートフルです。アウトバウンドルールにかかわらず、許可されたインバウンドトラフィックのアウトバウンドへの通信、またその逆を許可する応答を出します。そのため、「接続元の IP から TCP ポート 443 を介してアウトバウンドトラフィックを許可するように セキュリティグループを設定します。」が正解になります。
違いは以下の通りです。
セキュリティグループ:インスタンス単位で設定するファイアウォール
ネットワークACL:サブネット単位で設定するファイアウォール
それぞれ、アウトバウンドとインバウンドのルールを設定して利用します。
両方ともEC2インスタンスを外部から守るものではあるのですが、細かい制御を追求する場合にはネットワークACLでは全トラフィックを許可して、セキュリティグループで細かい設定をするケースが多くなります。
AWS Well-Architected フレームワークは、以下の5つの柱で構成されています。
・運用上の優秀性
・セキュリティ
・信頼性
・パフォーマンスの効率
・コスト最適化
このフレームワークを通じて、アーキテクチャーに関するベストプラクティスを学ぶことができるようになっています。
Amazon DynamoDB はマネージド型のNoSQLデータベースサービスです。SQSメッセージでキューした後にDynamoDBに書き込みを行う。が正解となります。DynamoDBはスケーラブルですが、費用対効果の高いソリューションを実現するためにはSQSによるメッセージング構成にすることで問題の状況に対応できます。SQSを使用するとクラウドアプリケーションのコンポーネントを分離して調整することが簡単で費用対効果が良くなります。SQSを利用することで、キューイングによってDynamoDBへの処理負荷を下げることができます。
DynamoDBにAuto Scalingを適用し、一時的なアクセス集中に対応できるように構成する。も正解となります。DynamoDBにAuto Scalingを設定することで、一時的な負荷に対して処理性能をスケーリングすることで高負荷に対応することができます。
DynamoDBをマルチAZ構成で起動する機能はないため不適格です。また、「グローバルセカンダリーインデックスを付与する」と読取クエリ処理が効率化できるようになりますが、今回の要件には不十分な対応となります。
DynamoDBの書き込みキャパシティを増強して、一時的なアクセス集中に対応できるように構成することは可能ですが、一時的なアクセス集中に対する方策としては、コスト効率が悪い対応となります。
Amazon Redshitは、クラウド内のフルマネージド型、ペタバイト規模のデータウェアハウスサービスです。Amazon Redshift では、クラスターに対してデータベースの暗号化を有効にして、保管時のデータを保護できます。クラスターに対して暗号化を有効にすると、クラスターとそのスナップショットのデータブロックとシステムメタデータが暗号化されます。
Amazon Redshift では、暗号化キーの階層を使用してデータベースを暗号化します。AWS Key Management Service (AWS KMS) またはハードウェアセキュリティモジュール (HSM) のいずれかを使用して、この階層の最上位の暗号化キーを管理できます。Amazon Redshift で暗号化に使用するキーの管理方法が重要です。したがって、「AWS KMSを利用して暗号化を実施する。」が正解となります。
Amazon Redshift は自動的に AWS KMS に統合されますが、HSM には統合されません。HSM を使用するときは、クライアントとサーバーの証明書を使用して、Amazon Redshift と HSM との間で信頼された接続を設定する必要があります。したがって、「Amazon Redshift と HSM との間でクライアントとサーバーの証明書を使用した信頼された接続を設定する。」が正解となります。
スナップショットを作成する手順を踏むことでボリュームを暗号化することができます。暗号化されていないボリュームを直接暗号化することはできません。
暗号化されたスナップショットは、AWSマネジメントコンソールでも作成できますし、AWS CLIを使ってスナップショットのコピーコマンド(ec2 copy-snapshot)に「–encrypted」オプションを渡す方法でも作成することができます。
Amazon RDS はマネージド型リレーショナルデータベースです。RDSのマルチAZ配置(DBインスタンスのスタンバイを別のAZに配置する)機能を有効化する。が正解となります。Amazon RDS は、マルチ AZ 配置を使用して DB インスタンスの高可用性およびフェイルオーバーサポートを提供します。RDS コンソールを使用すると、DB インスタンスを作成する際にマルチ AZ を有効化するだけでマルチ AZ 配置を作成できます。コンソールを使用し、DB インスタンスを変更してマルチ AZ オプションを指定することで、既存の DB インスタンスをマルチ AZ 配置に変換できます。AWS CLI または Amazon RDS API を使用してマルチ AZ 配置を指定することもできます。
別AZにEC2(踏み台サーバー)を構築し、RDSへのアクセスを可能にする。が正解となります。パブリックサブネットにある踏み台サーバーをマルチAZ構成にして、RDSへのアクセスできる構成を冗長化します。これによって、AZ障害によって踏み台サーバー自体が停止した時にも対応できるようにします。
他選択肢について、
Route53を利用したフェールオーバー構成によって、マルチリージョンな構成が可能となりますが、AZ障害への対応にはマルチAZ構成で十分です。
RDSのマルチAZ構成はバックアップからRDSを複製する必要はありません。マルチAZを有効化するだけで実現可能です。
NATゲートウェイによるアドレス変換はRDSに対しては必要ありません。
Amazon Auroraサーバレスは、アプリケーションニーズに応じて、自動的に起動、シャットダウン、および容量を拡大または縮小することができます。「Auroraサーバレスを利用し、オンライントランザクションの負荷分散を行う。」が正解となります。このシナリオでは、EC2インスタンスのWEBサーバーとOLTP処理を行うデータベースの両方をスケーラブルで高可用性な構成にする必要があります。したがって、複数のアベイラビリティーゾーンにまたがるEC2インスタンスにAuto ScalingグループとELBを設定することが基本対応となります。これに加えて、データベースは、不規則なピーク処理が発生することからAuroraサーバレスを利用します。
Auroraサーバレスでは、DB インスタンスクラスのサイズを指定せずにデータベースエンドポイントを作成できます。最小と最大のキャパシティーを設定し、データベースエンドポイントがプロキシフリートに接続されます。このプロキシフリートでは、ワークロードをルーティングする先のリソースのフリートがオートスケーリングされます。プロキシフリートを使用すると、最小と最大のキャパシティー仕様に基づいて Auroraサーバレスがリソースを自動的にスケールするため、接続が途切れることはありません。
「Route53を利用したRDSのフェールオーバー構成を利用し、オンライントランザクションの負荷分散を行う。」は不正解です。Route53によるフェールオーバー設定によって、EC2インスタンスやRDSをマルチリージョン構成に展開することが可能ですが、マルチAZ構成を利用することが基本的な設定となります。また、今回は不規則な需要に対する処理としてAuroraサーバレスが最適となります。
「Auroraのマルチクラスター構成を利用し、オンライントランザクションの負荷分散を行う。」と「RDSをマルチAZ構成で利用し、オンライントランザクションの負荷分散を行う。」は不正解です。2019年6月より、RDSのストレージに対するAuto Scalingが利用可能となりました。これにより、増加するデータベースのワークロードに応じてストレージ容量がダウンタイムなしで自動的にスケールされます。しかしながら、あくまでのストレージ容量のスケーリングのため、不正解となります。要件に合致するのはAuroraサーバレスになります。
コンバーティブルでしか変更できない設定は以下のとおりです。
・インスタンスファミリー
・OS
・テナンシー
・支払オプション
したがって、インスタンスのファミリー変更が正解となります。
なお、コンパーティブルでは変更できる設定が多いため、割引率が低く設定されています。
「RDSはファイルシステムとの連携はサポートされていないため、EC2インスタンスを利用する」が正解となります。
データベースシステムとファイルシステムの連携を実現するためにはEC2インスタンスにデータベースをインストールしてデータベースサーバーをカスタムで構築する必要があります。
「RDSはPostgreSQL 11をサポートしていないため、EC2インスタンスにマイグレーションする」は不正解です。
RDSはPostgreSQL 11のサポートを開始しました。詳細は以下のページをご参照ください。
https://aws.amazon.com/jp/rds/postgresql/why-postgresql-11/
「CRMとの連携のためオンプレミスデータベースを利用する」は不正解です。
RDSでデータベースを構築しても特定のCRMと連携することは可能です。
「RDSはオンプレミスのWEBサーバーとの連携はサポートされていないため、EC2インスタンスを利用する」は不正解です。
RDSはEC2インスタンスとの連携やオンプレミスサーバーとの連携も構築可能です。
基本的にRDSはフルマネージドであるため、DB管理システム、バージョン、外部連携で細かい仕様がある場合はEC2に構築するのが適切な場合もあります。
AWS Lambda API またはコンソールを使用して、関数を作成することができます。
このシナリオでは、画像処理を実行するEC2インスタンスの処理性能が不足していることがわかります。ここでは、EC2インスタンスのAutoScalingは全体的な処理時間を短縮し、SQSはコマンド/タスクをEC2インスタンスのグループに分散することで、可用性を高めることができます。また、EC2インスタンスのタイプをより性能が高いものに向上させることで、処理性能を上げることも可能です。したがって、これらの要素を取り入れた「SQSを利用してEC2インスタンスによる並行処理ができるようにする。」と「AutoScalingグループに利用したEC2インスタンスにより処理ができるようにする。」とEC2インスタンスのインスタンスタイプを変更する。は正しいオプションとなっています。
「EC2インスタンスの代わりにLambda関数による処理ができるようにする。」は正しくないアーキテクチャ構成となるため正解となります。Lambda関数によって処理をするためには、画像処理ソフトウェアを実行するにはサーバーとしてのEC2インスタンスが必要となるため、正しくありません。仮にAPIであるAmazon Rekognition ImageをLambda関数で呼び出す処理であれば、Lambda関数による処理に変更することで高パフォーマンスな対応が可能となります。しかしながら、本件の要件では画像識別ソフトウェアの利用を継続することのため適さない内容となります。
・ALBのアクセスログをS3バケットにデータを保存するように構成できます。Amazon EMRは、企業、研究者、データアナリスト、開発者が膨大な量のデータを簡単かつコスト効率よく処理できるようにするウェブサービスです。EMRは、Amazon EC2およびAmazon S3で構成されたHadoopフレームワークを利用します。
・KinesisもEC2も、ホストされたHadoopサービスを提供するサービスではないため不正解です。
・ALBのアクセスログをDynamoDBに配信するように設定することはできないため不正解です。
「Parameters セクション」が正解です。実行時に (スタックを作成または更新するとき)、テンプレートに渡すことができる値を指定します。Description セクション は、テンプレートの説明を記入するセクションで、Resources セクションは
必ず記載しなければならない AWS のリソース (EC2 や S3) 及びプロパティを含むセクションとなります。Outputs セクションは、スタックのプロパティを確認すると返される値について説明します。
Amazon Auroraサーバレスは、アプリケーションニーズに応じて、自動的に起動、シャットダウン、および容量を拡大または縮小することができます。「Auroraサーバレスを利用し、オンライントランザクションの負荷分散を行う。」が正解となります。このシナリオでは、EC2インスタンスのWEBサーバーとOLTP処理を行うデータベースの両方をスケーラブルで高可用性な構成にする必要があります。したがって、複数のアベイラビリティーゾーンにまたがるEC2インスタンスにAuto ScalingグループとELBを設定することが基本対応となります。これに加えて、データベースは、不規則なピーク処理が発生することからAuroraサーバレスを利用します。
Auroraサーバレスでは、DB インスタンスクラスのサイズを指定せずにデータベースエンドポイントを作成できます。最小と最大のキャパシティーを設定し、データベースエンドポイントがプロキシフリートに接続されます。このプロキシフリートでは、ワークロードをルーティングする先のリソースのフリートがオートスケーリングされます。プロキシフリートを使用すると、最小と最大のキャパシティー仕様に基づいて Auroraサーバレスがリソースを自動的にスケールするため、接続が途切れることはありません。
「Route53を利用したRDSのフェールオーバー構成を利用し、オンライントランザクションの負荷分散を行う。」は不正解です。Route53によるフェールオーバー設定によって、EC2インスタンスやRDSをマルチリージョン構成に展開することが可能ですが、マルチAZ構成を利用することが基本的な設定となります。また、今回は不規則な需要に対する処理としてAuroraサーバレスが最適となります。
「Auroraのマルチクラスター構成を利用し、オンライントランザクションの負荷分散を行う。」と「RDSをマルチAZ構成で利用し、オンライントランザクションの負荷分散を行う。」は不正解です。2019年6月より、RDSのストレージに対するAuto Scalingが利用可能となりました。これにより、増加するデータベースのワークロードに応じてストレージ容量がダウンタイムなしで自動的にスケールされます。しかしながら、あくまでのストレージ容量のスケーリングのため、不正解となります。要件に合致するのはAuroraサーバレスになります。
AWS VPN のステータスを、CloudWatch のメトリクスデータでモニタリングできます。VPNの状態は、CloudWatch メトリクスの TunnelState のブール値として定義されています。ブール値が 0 の場合はトンネルがダウン状態、1 の場合はトンネルがアップ状態であることを示します。
■補足:VPN トンネルでは、他にも次のメトリクスを使用できます。
TunnelDataIn:VPN トンネルを介した接続の AWS 側で受信したバイト数。
・Amazon Athenaを使用すると、SQLを使用してAmazon S3のデータを対話的に分析することができます。Athenaはサーバーレスのサービスであり利用者がサーバを管理する必要はありません。利用料金はクエリ実行に対してのみ課金されます。
・Amazon RedShiftは大量のデータ分析に使用するサービスですが、S3のデータを分析することはできません。
・AWS Glueは、データ分析のサービスではなく、データの抽出、変換、読み込み(ETL)の機能で、データ分析を行うためのデータを準備する際に、データの加工を効率的に行うためのサービスです。S3のデータの分析には使用されません。
・AWS Data Pipelineは、データを処理したり移動したりするためのサービスです。AWS上のサーバとストレージサービスとの間や、AWSとオンプレミスのデータソースとの間でのデータ処理・転送を支援します。
データベースの負荷を軽減するためには、ElastiCacheとRDSリードレプリカを使うことが有効です。
Amazon ElastiCache を使うことで管理されたインメモリシステムを使って高速な情報取得を可能にすることができます。データベースで低速なディスクを使用していたとしてもその性能に全面的に依存することなく、ウェブアプリケーションのパフォーマンスを向上させることができます。
また、参照が多いアプリケーションの場合、書き込み用のマスターと別に参照用のリードレプリカを用意しておくことで読み込み処理が書き込み処理に影響なくパフォーマンスを向上させます。
Amazon S3 Transfer Accelerationを使用すると、クライアントと S3 バケットの間で、高速、簡単、安全にファイルを長距離転送できるようになります。
「Amazon S3 Transfer Accelerationを利用する。」が正解となります。Amazon S3 Transfer Acceleration を使用すると、クライアントと S3 バケットの間で、長距離にわたるファイル転送を高速、簡単、安全に行えるようになります。Transfer Acceleration では、Amazon CloudFront の世界中に分散したエッジロケーションを利用しています。エッジロケーションに到着したデータは、最適化されたネットワークパスで Amazon S3 にルーティングされます。これによりグローバルに効果的なファイル転送が可能となります。
「CloudFrontを利用したエッジ処理を利用する。」は不正解です。CloudFrontを利用したエッジ処理は配信を効率的にする方法であり、アップロードには利用できません。
「Route53による位置情報ルーティングを利用する。」は不正解です。Route53による位置情報ルーティングは ユーザーの位置に基づいてトラフィックをルーティングする場合に使用します。
「Amazon S3 マルチパートアップロードを利用する。」は不正解です。マルチパートアップロード API を使用すると、大容量オブジェクトをいくつかに分けてアップロードできるようになります。この API では、新しい大容量オブジェクトをアップロードしたり、既存オブジェクトのコピーを作成したりできます。これは大きなファイルをアップロードする手法になります。
Amazon EFS は 、共有可能なファイルストレージを提供し、複数のサーバーからアクセスさせることができます。
■Amazon EFS
Amazon Elastic File System (Amazon EFS) は、AWS クラウドサービスおよびオンプレミスリソースで使用するための、NFS ファイルシステムが提供されます。DISK容量は、自動で拡大および縮小されるため、DISK容量の管理を行う必要がありません。
Amazon EFS は、コンテンツ管理システムと、アプリケーション (ウェブサイト、オンライン出版、アーカイブなど) の情報を保存して処理するウェブ配信アプリケーションに利用できるファイルシステムを提供します。
■以下は不正解です。
・「AWS Storage Gateway(ボリュームゲートウェイ)」
→AWS Storage Gateway は既存のオンプレミス環境を AWS クラウドに接続するハイブリッドクラウドストレージサービスであるため間違いです
・「Amazon EBS」
→Amazon EBS ボリュームはインスタンスに接続されており、一部のインスタンスタイプを除いてサーバー間で共有できないため間違いです。また、自動的にストレージを拡張することもできません。
· 「Amazon S3」
→Amazon S3 はオブジェクトストレージであるため間違いです。
既存EBSボリュームの暗号化設定を変更することはできないため、「EC2インスタンス停止後、EBSボリュームの暗号化設定を行う」が不正解となります。
暗号化されていない既存のボリュームまたはスナップショットを直接暗号化する方法はありませんが、ボリュームまたはスナップショットを作成することで暗号化できます。
既存EBSボリュームを暗号化するために、以下の順で作業を実施します。
1. 既存EBSボリュームのスナップショットを取得
2. 取得したスナップショットを、[EBS暗号化] を有効化しコピー
3. コピーしたスナップショット(暗号化済み)から EBS ボリュームを作成
4. EC2インスタンスから既存EBSボリュームをデタッチする
5. EC2インスタンスに作成した EBSボリューム(暗号化済み)をアタッチする
CloudFrontは、ウェブサイト、API、動画コンテンツ、その他の資産を配信するグローバルコンテンツ配信ネットワーク(CDN)です。
CloudFrontを利用することでエッジロケーションにコンテンツをキャッシュし、利用者がアクセスした際には物理的に最も近いエッジロケーションから応答します。これにより、オリジンとなっているEC2インスタンスへのアクセス負荷を軽減することができます。
・パスワードの長さや複雑さなどを強制するためのパスワードポリシーを定義できます(すべてのユーザーに適用)。
・パスワードを変更する機能を制限するIAMポリシーをユーザーを含むグループにアタッチする必要があります。
・IAMロールを使用してこの機能を実行することはできません。
・AWS STSは一時的なAWSリソースへのアクセスの都度、動的に一時的な認証情報を発行するサービスです。IAMユーザーのパスワードポリシーの制御には使用されません。
VPC の開発と本番間の通信は、検証経由で通信することはできません。また、ピアリング接続の前提条件:「VPC はすべて、同じ AWS アカウントに存在し、重複する CIDR ブロックはありません。」は満たされています。従って、「適切なルートとともに開発と本番の間に新しいピアリング接続を作成します。」が正解になります。
AWSのVPCの仕様(制約)により、 VPCまたぐ通信はできません。つまりVPC(開発)とVPC(本番)は VPC(検証)を経由して相互に直接トラフィックを送信することはできないため、「開発VPCに本番VPCへの適切なルートテーブルの設定変更を行う。」は不正解です。 VPC(開発)と VPC(本番)の間で直接トラフィックをルーティングするには、両者間にピアリング接続を作成する必要があります。
「オンデマンドインスタンス」が正解となります。オンデマンドインスタンスは利用時間に応じて、決められた料金を支払う通常のインスタンス利用形態です。
スケジュールドリザーブドインスタンスは1 年間にわたり毎日、毎週、または毎月指定された開始時間で繰り返すパターンで購入できましたが、AWSの方針により利用ができなくなりました。
そのため、問題文のような定期的なスケジュール処理に対しては、今後は「オンデマンドキャパシティー予約」または「Savings Plans」を利用します。
「リサーブドインスタンス」は不正解です。リザーブドインスタンスは「1年間」「3年間」と期間を決めてEC2インスタンスを「Reserved(予約)」する事で通常にEC2インスタンスを利用するよりも格安にインスタンスを使うことができます。初期予算によって「全額前払い」「一部前払い」「前払いなし」とプランを選択して使うことができます。WEBアプリケーションを数年間にわたり長期運用する場合、リザーブドインスタンスを利用することでコストを大幅に削減できます。
「スポットインスタンス」は不正解です。スポットインスタンスはオンデマンドより低価格で利用できます。スポットインスタンス は割引価格をリクエストできるため、Amazon EC2 のコストを大幅に削減できます。スポットインスタンス の時間単位の使用料金はスポット料金と呼ばれます。
デフォルトでは、S3 オブジェクトの所有者はそれをアップロードした AWS アカウントです。これは、バケット所有者が他のアカウントである場合にも当てはまります。オブジェクトへのアクセス権を取得するには、オブジェクト所有者が明示的にあなた (バケット所有者) にアクセス権を付与する必要があります。 オブジェクト所有者は、オブジェクトのアクセスコントロールリスト (ACL) を更新することによって、バケット所有者にオブジェクトのフルコントロールを付与できます。オブジェクト所有者は、put 操作または copy 操作中、またはオブジェクトがバケットに追加された後に ACL を更新できます。したがって、オプション1が正解となります。
オプション1は不正解です。Snowballは実際にAWSから機器を借りてきて実行することが必要であり、それをAWS側に物理的に送付する時間が必要となります。データ量が多い場合に便利ですが、今回のように短時間での移行には向いていません。
オプション3が正解となります。Amazon VPC で起動するインスタンスは、デフォルトではオンプレミスネットワークと交信できません。お使いのデータセンターや支店のネットワークを AWS サイト間 VPN (Site-to-Site VPN) 接続のあるクラウドに安全に拡張できます。この接続ではインターネットプロトコルセキュリティ (IPsec) 通信を使用して 2 点間に暗号化された VPN トンネルを作成します。この接続設定は、オンプレミス環境のネットワーク機器と設定がわかっていれば、AWSコンソール上で短時間で容易に準備することが可能です。今週末の金曜日から月曜日にかけて72時間でデータ移行を完了させる時間内に実現可能なソリューションです。
エラーコード 500 内部エラーは、Amazon S3 がその時点ではリクエストを処理できないことを示しています。エラーコード 503 Slow Down は一般的には、S3 バケットが許容できるリクエスト率を超えて、非常に高いことを示しています。Amazon S3 は分散しているサービスであるため、非常に低い割合の 5xx エラーはこのサービスの正常な使用中に発生する場合があります。Amazon S3 からの 5xx エラーを返すすべてのリクエストは、再試行される必要があり、Amazon S3 へリクエストするアプリケーションはこれらのエラーから復旧する耐障害メカニズムを持っていることが推奨されます。5xx エラーを解決または回避するには、以下の手順をお試しください。 ・リクエストするアプリケーションの再試行メカニズムを有効にする・リクエスト率を徐々に増やすようにアプリケーションを設定する・複数のプレフィックスにオブジェクトを分散する。 したがって、オプション3が正解となります。
ボリュームゲートウェイを利用することでS3とオンプレミスとを容易に接続することが可能です。保管型ボリュームを使用すると、プライマリストレージのコストを大幅に節約し、プライマリーストレージをオンプレミスに置いたままS3へと拡張することができます。 頻繁にアクセスされるデータへの低遅延アクセスも維持します。したがって、オプション4が正解となります。 一方でキャッシュ型ボリュームはAWSのS3をプライマリーとして利用する場合に使用します。したがって、オプション3は不正解です。 他のオプションは、ストレージの拡張には利用できないため、不正解です。
AWS WAF (Web Application Firewall) を利用し Cloudfront でのリファラル制御を実装することができます。AWS WAF は、CloudFront に転送される HTTP および HTTPS リクエストをモニタリング可能にし、コンテンツへのアクセスを制御可能にするウェブアプリケーションファイアウォールです。クエリ文字列からの実行またはクエリ文字列の値をリクエストする IP アドレスのような、指定した条件に基づいて、CloudFront はリクエストされたコンテンツまたは HTTP 403 ステータスコード (禁止) のリクエストのいずれかに対応します。したがって、オプション2が正解となります。 CloudFrontの署名付きURLと署名付きCookieは同じ基本機能を提供しており、コンテンツにアクセスできるユーザーを制御できます。 しかしながら、直接リンクを禁止するという意味では正しくありません。したがって、オプション1と3は不正解です。 S3へのアクセス処理を暗号化することで、配信を制限するといった対応はできません。
オプション2が正解となります。EBSのスナップショット取得のライフサイクルポリシーを設定できます。Amazon Data Lifecycle Manager (Amazon DLM)を使用するとEBSのバックアップであるスナップショットの作成、保存、削除を自動化できます。 定時バックアップをスケジュールして貴重なデータを保護します。
ステートレスアプリケーションとは以前のシステム上のやり取りについての状態情報が不要なため、セッション情報が格納されていないアプリケーションのことです。 そのため、同じ入力が与えられたときに、どのエンドユーザにも同じ応答を提供するアプリケーションとなります。よって、Lambdaファンクションを利用してステートレスな処理をサービス化することでコスト最適を達成できる可能性が高いです。
必要に応じて管理者の指示に従って10時間以内に取得するという要件から、標準取り出しが最適な設定となります。 標準 — 標準取り出しでは、数時間以内にすべてのアーカイブにアクセスできます。通常、標準取り出しは 3〜5 時間で完了します。標準取り出しは、取り出しオプションを指定しないで取り出しリクエストを行った場合にデフォルトで適用されます。 迅速取り出しでは、アーカイブのサブセットが迅速に必要になった場合にデータにすばやくアクセスできます。最大規模のアーカイブ (250 MB 以上) を除くすべてのアーカイブについては、迅速取り出しでアクセスしたデータは通常 1〜5 分以内で使用可能になります。プロビジョンドキャパシティーは、迅速取り出しの取得容量を必要なときに利用できることを保証します。迅速取り出しは取り出し性能が超過しており、設定は標準取り出しで十分です。 大容量取り出しは、Glacier の最も安価な取り出しオプションであり、これを使用して大量のデータ (ペタバイトのデータを含む) を 1 日以内に取得できます。通常、大容量取り出しは 5〜12 時間で完了します。 これは10時間以内に対応できません。
Aliasレコードを作成してCloudFront配信を指定することがAWSでの設定方法となります。 通常のRoute 53レコードは標準のDNSレコードですが、ALIASレコードはDNS機能に対するRoute 53固有の拡張機能を提供します。 IPアドレスまたはドメイン名の代わりに、ALIASレコードにはCloudFrontディストリビューション、Elastic Beanstalk環境、ELB Classic、Application、またはNetwork Load Balancer、静的Webサイトとして設定されているAmazon S3バケットへのポインタ、または 同じホストゾーン内の別のRoute 53レコードを設定することができます。
NATゲートウェイは、NATインスタンスの代わりに使用できるマネージド型サービスで、AWS側で拡張性などが保証されておりボトルネックの改善につながります。 NATインスタンスのインスタンスタイプを変更したりスケールすることも検討できますが、それでも問題が将来発生しないことを保証するものではありません。
オプション2が正解となります。リザーブドインスタンスの価格メリットは、購入したリザーブドインスタンスの総数に基づいて、支払人アカウント(またはインスタンスを予約したアカウント)だけでなく、一括請求グループの一部であるすべてのアカウントに適用されるため、購入したリザーブドインスタンスの数分だけその価格メリットが適用されます。その場合の条件として、各アカウントが利用するインスタンスが、同じゾーンの同じインスタンスサイズであることが必要です。
Auto Scalingの起動時に問題が発生すると、起動グループ内の1つ以上のAuto Scalingプロセスを中断して再開することができます。 これは、Auto Scalingプロセスを起動せずに、Webアプリケーションの設定上の問題やその他の問題を調べてからアプリケーションに変更を加える場合などに利用できます。
ストレージゲートウェイのキャッシュ型ボリュームを使用すると、頻繁にアクセスされるデータをストレージゲートウェイでローカルに保持しながら、S3をプライマリデータストレージとして使用できます。これは今回はキャッシュ型が要件に合致するため、オプション1が正解となります。 キャッシュ型ボリュームは、オンプレミスのストレージインフラストラクチャをスケールする必要性を最小限に抑えます。同時に、アプリケーションからは引き続き、頻繁にアクセスするデータへの低レイテンシーなアクセスが可能になります。作成できるストレージボリュームのサイズは最大 32 TiB で、それを iSCSI デバイスとしてオンプレミスのアプリケーションサーバーにアタッチすることが可能です。ゲートウェイは、書き込まれたデータを Amazon S3 に作成されたストレージボリュームに保存し、最近読み込まれたデータはオンプレミスのストレージゲートウェイのキャッシュに保持して、バッファストレージにアップロードします。
インターネットアクセスを制限するにはプライベートサブネット内にインスタンスを設置した上で、NATインスタンスを通じたインターネットへのアクセスのみに制限することで、容易に実現が可能となります。したがって、オプション4が正解となります。 パブリックサブネットのインスタンスはアウトバウンドトラフィックを直接インターネットに送信できますが、プライベートサブネットのインスタンスはできません。代わりに、プライベートサブネットのインスタンスは、パブリックサブネットに存在するネットワークアドレス変換 (NAT) ゲートウェイかNATインスタンスを使用して、インターネットにアクセスできます。データベースサーバーは、NATインスタンスを通じてインターネットに接続してソフトウェアアップデートを行うことができますが、インターネットからはデータベースサーバーへの接続を確立できません。
どのインスタンスが本番インスタンスでどのインスタンスが開発インスタンスであるかを定義するタグを簡単に追加して、IAMポリシーを介してアクセスを制御するときにこれらのタグに応じたアクセス権限を付与することができます。したがって、オプション1が正解となります。 IAMグループなどのIAMポリシーによって制御できると考えられるかもしれませんが、その場合はサービス単位でのアクセス権限許可設定となるため、本番用インスタンスや開発用インスタンスなどの用途別の制御はできません。よってタグ情報によって区別した上で利用範囲を制限する必要があります。IAMだけで設定を行っているオプション2と4は不正解です。 セキュリティグループを設定して本番用EC2インスタンスへのアクセスを制限するといった権限管理はできません。したがってオプション3は不正解です。
オプション3は間違いです。暗号化キーを配布して特定ユーザーに画像共有を許可するといった設定はありません。
オプション4は間違いです。EFSによってデータ共有はインスタンス間のデータ共有が可能になるものであり、外部にデータを公開するサービスとしてはS3を利用する方が適切です。
Amazon Elastic Transcoderでの動画編集を利用すると、ジョブは、パイプラインで受け付けた順に処理が開始されます。ジョブの変換準備ができると、入力ファイルサイズ、解像度、ビットレートなど多くの変数が変換速度に影響します。例えば、10 分の動画に iPhone 4 プリセットを使用する場合の期間は約 5 分です。多数のジョブを受け付けると、ジョブはバックログ (キュー) に登録されます。 このシナリオでは、バックログの発生を抑えるために処理に利用するEC2インスタンスを一時的に増加させて対応したいというのが要件となります。このような処理は一時的に発生するものなので、使用するのに最適なインスタンスはスポットインスタンスです。 スポットインスタンスは通常、バッチ処理ジョブで使用されます。 これらのジョブは、年間を通して存続しないため、入札したり、要求に応じて割り当てや割り当て解除を行うことができます。したがって、オプション3が正解となります。
これらのEC2インスタンスがインターネットを介して通信するためには、セキュリティグループとネットワークACLが適切な許可設定にされていることと、ルートテーブルにインターネットゲートウェイへのエントリがあることを確認する必要があります。したがって、オプション1が正解となります。 2) 不正解です。インターネットからアクセスするためにはElastic IPは必須ではありません。 3) 不正解です。インターネットからアクセスするためにはセカンダリーIPは必須ではありません。 4) 不正解です。NATゲートウェイはプライベートサブネットにあるEC2インスタンスへのアクセスに利用しますの、正しくありません。
プレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。プレイスメントグループを設定すると、グループで設定されたインスタンス間のネットワーク遅延を最小限に抑えることができます。設定は同じリージョン内のVPC にまたがって設定することができます。
プレイスメントグループには、「クラスター」「スプレッド」「パーティション」の3つの種類があります。
ネットワーク遅延の最小化、ネットワークスループットの最大化、またはその両方から利点が得られるアプリケーションや、ネットワークトラフィックの大部分がグループのインスタンス間で発生するような場合、クラスタープレイスメントグループが推奨されます。
「ELBとのデータ通信においてSSL/HTTPSを利用する方法」と「ストレージやデータベースの暗号化を実施する方法」が正解となります。
SSL / TLSプロトコルを使用するロードバランサーを利用することで、クライアント・サーバー間のトラフィック暗号化が可能になります。
また、AWSではストレージやデータベースに対してシンプルな暗号化ソリューションを提供しており、ストレージ内の保存データ・S3への転送データなどにデータ保護が可能になります。
他の選択肢は誤りです。
IAMによるストレージやDBへのアクセス制御とセキュリティグループによるデータベースへのアクセス制御は、データ保護には無関係です。
AWSの暗号化サービスとしては
S3内の保存データに対する暗号化機能もサポートされており、コンソールでの操作で簡易に実現できます。
違いは以下の通りです。
セキュリティグループ:インスタンス単位で設定するファイアウォール
ネットワークACL:サブネット単位で設定するファイアウォール
それぞれ、アウトバウンドとインバウンドのルールを設定して利用します。
両方ともEC2インスタンスを外部から守るものではあるのですが、細かい制御を追求する場合にはネットワークACLでは全トラフィックを許可して、セキュリティグループで細かい設定をするケースが多くなります。
Amazon Data Pipelineは、データの移動と変換を自動化するサービスです。問題文に挙げられている様な、Amazon RDSからAmazon S3へのデータ移動を、定められたタスクスケジュールのルールに則って実行する事が出来るデータを転送するためのサービスです。Amazon RDS以外の利用例としては、ウェブサーバーのログを毎日S3にアーカイブしたいといった用途にも利用する事が出来ます。
良く使用される前提条件やパイプラインテンプレートがあらかじめ用意されており、S3へのデータのアーカイブやSQLクエリの定期実行などがあります。
回答以外の選択肢に挙げられているサービスの概要は以下の通りです。
Amazon kinesis:ストリーミングデータをリアルタイムで処理できるサービス
AWS CloudFormation:インフラをプロビジョニングするサービス
AWS OpsWorks:Chefやpuppetを利用して、サーバ構成を自動化できるサービス
マルチAZ構成とは複数のAZを使用するシステム構成になります。
このシナリオでは、1つのAZにEC2インスタンスが設置されているため、AZ障害が発生した際にアプリケーション全体が停止してしまうリスクがあります。したがって、マルチAZ構成を実現するための最適な構成を選択することが必要です。
「EC2インスタンスを別AZに起動して、ELBターゲットをAZを跨いで設定する。」が正解となります。EC2インスタンスを別AZに起動して、ELBターゲットをAZを跨いで設定することで、ELBがAZを跨いでEC2インスタンス間でトラフィックを制御してくれます。これによって、1つのAZが停止した場合は、残ったAZでEC2インスタンスの処理を継続させることができます。
「AutoScalingのスケーリンググループを複数のAZを跨いで構成する。」が正解となります。AutoScalingのスケーリンググループをAZ間を跨いで構成することで、1つのAZでのEC2インスタンスが停止したとした場合に、その処理負荷を生き残ったAZに新規インスタンスを起動させることで軽減させることができます。
「AutoScalingの起動設定を複数のAZを跨いで構成する。」は不正解です。AutoScalingの起動設定はAutoScalingで起動するインスタンスタイプなどの設定となります。
「EC2インスタンスを別AZに起動して、Route53によりフェールオーバールーティングを設定する。」は不正解です。Route53によりフェールオーバールーティングを設定することは可能ですが、これは2つのEC2インスタンス間でのフェールオーバー構成を実施することしかできません。今回はELBで複数インスタンス間でのトラフィック分散を実現することが最適な構成となります。
「EC2インスタンスを別AZに起動して、ELBのスティッキーセッションを有効化する。」は不正解です。ELBのスティッキーセッションを有効化すると、同じユーザーのセッションは特定のEC2インスタンスでの処理を継続することができますが、問題の回答とは異なります。
「AWS Managed Microsoft ADを利用して、Microsoft Active Directory(AD) を構築する設定」が正解となります。
AWS Managed Microsoft ADを利用すれば、 AWS と既存のオンプレミス Microsoft Active Directory の間で信頼関係を設定し、シングルサインオン (SSO) を使っていずれかのドメインのリソースへのアクセス権を、ユーザーとグループに提供することができます。
「AD Connectorにより既存のActive Directoryと連携する設定」も正解となります。
AD Connector を使用して、既存のオンプレミスの Microsoft Active Directory のユーザーやグループにもロールを割り当てることができます。これらのロールは、そのロールに割り当てられた IAM ポリシーに基づいてユーザーの AWS サービスへのアクセスを制御します。
「Simple ADにより既存のActive Directoryと連携する設定」は間違いです。
Simple AD を利用することで、AWSに新規にディレクトリサービスを立ち上げることができます。
これにより、ユーザーアカウントやグループメンバーシップの管理、グループポリシーの作成および適用、Amazon EC2 インスタンスへの安全な接続を行うことができるだけでなく、Kerberos ベースのシングルサインオン (SSO) を使用できます。
「AWS Managed Microsoft ADを利用して、既存のActive Directoryと連携する設定」は間違いです。
AWS Managed Microsoft ADではなくAD Connector を使用して、既存のActive Directoryと連携します。
「AWS Snowball を利用し、AWSへのデータ転送を行い、各社 Direct Connect 経由でアプリケーションに接続する」が正解です。50TB などの大容量データの転送には、AWS Snowball が適しています。10TB 未満の場合、Snowboall は費用対効果の観点で最適な選択ではないケースがあります。また、安全なネットワーク接続や一貫したスループットが必要な場合、VPN よりも Direct Connect が適しています。VPN はインターネット経由ですが、Direct Connect は専用線が提供されるため、費用面の優先度が高くない場合は、Direct Connect が適していると言えます。
「CloudFront ディストリビューションを作成し、オリジンをS3バケットとする」が正解となります。Cloud Front は、静的及び動的な Web コンテンツの配信を高速化するサービスです。エッジロケーションは、世界各地にあるAWSのデータセンターで、CloudFront はユーザが最も低レイテンシーとなるエッジロケーションからコンテンツを提供かつキャッシュしてくれるサービスとなり、今回のケースでの利用に適しています。
「プロビジョンド IOPS SSD の利用」が正解です。プロビジョンド IOPS SSD (io1 および io2) ボリュームは、ストレージのパフォーマンスと整合性の影響を受けやすい I/O 負荷の高いワークロード、特にデータベースワークロードのニーズを満たすように設計されています。また、プロビジョンド IOPS SSD は、プロビジョニングした容量 (GB/月)
及び 1 か月あたりの IOPS (1 秒あたりの入力/出力オペレーションの数) について利用料が発生します。
マイクロサービスアーキテクチャでは、アプリケーションは独立した複数のコンポーネントとして構築されます。各コンポーネントは、1 つのサービスとして個別にアプリケーションプロセスを実行します。
このシナリオでは、EC2インスタンス間でコンポーネントが分割されたマイクロサービス間で処理が引き渡される分散アーキテクチャの実装方法が問われています。このようなマイクロサービス化されたコンポーネント間の処理を連携するにはSQSを利用したポーリング処理が最適となります。Amazon Simple Queue Service (SQS) は、完全マネージド型のメッセージキューイングサービスで、マイクロサービス、分散システム、およびサーバーレスアプリケーションの切り離しとスケーリングが可能です。SQS を使用すると、あらゆる量のソフトウェアコンポーネント間でメッセージを送信、保存、受信できます。したがって、「最初の処理結果をSQSキューが受け取って、ポーリング処理によりEC2インスタンスが処理を継続する。」が正解となります。
「最初の処理結果をEC2インスタンスが直接受け取って処理を継続する。」は不正解です。EC2インスタンスから直接にEC2インスタンスへと連携させると密結合なアーキテクチャ構成となるため、これは推奨されていない方式です。
「最初の処理結果が完了するとSNSがイベント通知して、EC2インスタンスが処理を継続する。」は不正解です。SNSもメッセージング通知によって、前の処理イベントをトリガーとしてイベント通知処理による連携を実施することができます。しかしながら、コンポーネント処理間の連携を確実に実行するには並列処理による負荷分散が可能なSQSが最適です。SNSはイベント通知を起点としたトリガーとして利用し、実処理はSQSに連携してポーリングするというのが標準的なAWSでのアーキテクチャ構成となります。
「最初の処理結果がLambdaイベントによってEC2インスタンスに通知される。」は不正解です。Lambdaイベントによって通知するといった処理はありません。
Elastic Load Balancing は、受信したトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に自動的に分散させます。
インターネットに面した Application Load Balancer は、ALB を指す外部 DNS を使用して、基盤となる EC2 インスタンスを公開するのに役立ちます。
■以下は誤りになります。
「EC2 インスタンスに接続されたセキュリティグループでポート 80 の HTTP トラフィック とポート 443 の HTTPS トラフィックを許可します。外部の DNS 解決が EC2 インスタンスの IP アドレスに向けられるようにします。」→プライベートサブネットのインスタンスはインターネットに接続されていないため間違いです。
「プライベートサブネットで NAT ゲートウェイを起動し、デフォルトルートを NAT ゲート ウェイに変更し、パブリック Elastic IP アドレスを NAT ゲートウェイにアタッチします。 外部の DNS 解決が Elastic IP アドレスに向けられるようにします。」→NAT ゲートウェイはプライベートインスタンスからインターネットへのトラフィックのルーティングに役立つため間違いです。インターネットからプライベートインスタンスの EC2 インスタンスにトラフィックをルーティングすることはできません。
「プライベートサブネットの Auto Scaling グループにEC2インスタンスを構成します。外部の DNS 解決が Auto Scaling グループに向けられるようにします。」
→Auto Scaling は EC2 インスタンスを外部に公開するサービスではなく、単にスケーリングす るサービスのため間違いです。また、DNS は Auto Scaling グループを指すことはできません。
AWS DataSyncが正解となります。
AWS DataSync は、オンプレミスストレージと Amazon EFS 間でデータを迅速かつ簡単に移動することができるマネージド型のデータ転送サービスです。
DataSync を使用すれば、オープンソースツールと比べて最大 10 倍の速度で、データセットを AWS Direct Connect またはインターネット経由で転送できます。アプリケーションを変更したり、API に書き込む必要はありません。
このサービスは、1 回のデータ移行、定期的な同期、およびデータの保護と復元のレプリケーションに使用できます。
AWS バックアップはAmazon EFS ファイルシステムの中央管理とバックアップの自動化が簡単にできるフルマネージド型のバックアップサービスであるため、不正解です。
AWS Server Migration Service は、オンプレミスの VMware vSphere、Microsoft Hyper-V/SCVMM、または Azure 仮想マシンの AWS クラウドへの移行を自動化するサービスであるため、不正解です。
AWS Direct ConnectはオンプレミスのサーバーとAWSを専用の回線でつなぐサービスです。
AWS DKRは存在しないため、不正解です。
「Amazon DynamoDB のリザーブドキャパシティを購入する」「Amazon Redshift のリザーブドノードを購入する」及び「Amazon ElastiCache のリザーブドノードを購入する」が正解です。これらのサービスや EC2 に加え、RDS のリザーブド DB インスタンス、Elastic search Service のリザーブドインスタンスなどがリザーブド購入オプションとして存在します。
Amazon S3のアクセスコントロールリスト(ACL)では、バケットとオブジェクトへのアクセスを管理することができます。
Amazon S3の各バケットとオブジェクトには、サブリソースとして ACL がアタッチされています。リソースに対するリクエストを受信すると、Amazon S3 は該当する ACL を調べて、必要なアクセス許可がリクエスタにあることを確認します。したがって、「Amazon S3 ACLを設定する。」が正解となります。
「セキュリティグループを設定する。」を設定する。は不正解です。S3にセキュリティグループは設定できません。
「CloudFrontにおける Referer制限を設定する。」は不正解です。CloudFrontではなくWAFのReferer制限がありますが、これはIPアドレスにマッチした先にデータをコンテンツ配信する仕組みです。
「Amazon S3のバケットポリシーを設定する。」は不正解です。バケットポリシーは、バケットに対してユーザーアクセス権限を設定するバケットに関するポリシーです。オブジェクト単位でのアクセス権限のコントロールにはACLを利用します。今回はオブジェクトへのアクセス権限の設定であるためACLが正解となります。バケットポリシーでの拒否設定をされていれば、ACLでも拒否されますが、今回の問題では本内容は問われていないため、不正解となります。
・S3バケットにファイルを保存しS3イベント通知を使用してLambda関数を呼び出して処理する方法が、不定期に処理が発生するアプリケーションで最もコスト効率のよい方法です。
KinesisデータストリームはEC2インスタンスを必要とするので、ファイルを受信していない状態でもインスタンスを起動しておく必要があります。「処理した分のみ課金されるLambdaと安価なストレージであるS3バケットの組み合わせ」ほどコスト効率がよくないため不正解です。
SQSキューでJava用の拡張クライアントライブラリを使用すると、メッセージをS3に保存することができ、2GBまでのメッセージを取り扱う事ができますが、4GBのファイルを扱うことはできません。そのため、不正解です。
なお、SQSキューの通常の最大メッセージサイズは256KBです。
EC2インスタンスを使用してEBSボリュームのデータを処理する方式はEC2インスタンスの稼働時間とEBSのプロビジョニングされた時間に対して費用がかかりコスト効率が高くないため不正解です。
「プロビジョンド IOPS SSD を指定する」が正解です。プロビジョンド IOPS SSD (io1 および io2) ボリュームは、ストレージのパフォーマンスと整合性の影響を受けやすい I/O 負荷の高いワークロード、特にデータベースワークロードのニーズを満たすように設計されています。汎用SSDは、gp2 と gp3 の 2 種類があり様々なワークロードに対応できるボリュームタイプです。スループット最適化HDDは、Amazon EMR、ETL、データウェアハウス、ログ処理など、サイズの大きなシーケンシャルワークロードに適しています。コールドHDD は、 スループット最適化 HDD ボリュームに類似していますが、アクセスの頻度の低いデータをサポートするように設計されています。
「AWS Lambda と Amazon Kinesis Data Firehose」が正解です。Amazon Kinesis は、基本的には動画やデータのストリームをリアルタイムで収集、処理、分析するものですが、さらに以下 4 種類のサービスに枝分かれします。
1) Amazon Kinesis Video Streams
2) Amazon Kinesis Data Streams
3) Amazon Kinesis Data Firehose
4) Amazon Kinesis Data Analytics
この中で、リアルタイムでストリーミング処理が可能なものは 2) と 3) になりますが、Amazon Redshift にデータを転送する要件があるため、3) Amazon Kinesis Data Firehose を選択します。また Amazon Redshift のデータの処理については、費用対効果を高めるため、「AWS Lambda」を使います。
デフォルトの制限は、1リージョンあたり200サブネットとなります。
VPCやErastic IPなど、AWSへリクエストすれば上限を緩和することできるサービスもありますが、リージョンあたりのサブネット上限数は変更不可となっています。
Amazon CloudWatch Logsは、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、AWS CloudTrail、Route 53、ログファイルの監視、保存、アクセスができます。統合 CloudWatch Logs エージェントをインストールすると、Amazon EC2 のログファイルを CloudWatch Logs にアップロードすることができます。CloudWatch Logs はアプリケーションログに存在するエラーの数を監視し、エラー率が指定のしきい値を超えたときやエラーステータスの発生数をカウントして管理者に通知を送ることができます。検索した値が見つかると、CloudWatch Logs は CloudWatch メトリクスにデータをレポートします。ログデータは、転送時や保管時に暗号化されます。統合 CloudWatch エージェントでは、以下が可能です。
・Amazon EC2 インスタンスからメトリクスを収集することができます。
・オンプレミスサーバーのメトリクスを収集することができます。AWS によって管理されていないサーバーからも収集することができます。
・カスタムメトリクスは、StatsD および collectd プロトコルを使用して、アプリケーションまたはサービスからメトリクスを取得するこができます。StatsD は、Linux サーバーと、Windows Serverをサポートしています。collectd は、Linux サーバーでのみサポートされています。
・Linux または Windows Server を実行している Amazon EC2 インスタンスおよびオンプレミスサーバーから、ログを収集します。
■以下は不正解です。
・「インスタンスストアボリュームを使用してログファイルを保存します。」
→インスタンスストアは、インスタンス用の一時的なブロックストレージを提供します。インスタンスストア上のデータは、関連付けられたインスタンスが起動中の時のみ維持されます。インスタンスが再起動された場合、その再ブートが意図的なものでも、意図せずに行われたとしても、インスタンスストアのデータは維持されます。ただし、次のいずれの状況では、インスタンスストアのデータは失われます。
・基盤となるディスクドライブで障害が発生した
・インスタンスが停止した
・インスタンスが終了した
インスタンスが終了した場合にデータが失われるため、間違いです。
・「AWS CloudTrail を使用して Amazon EC2 インスタンスからログを取得します。」
→AWS CloudTrail は、 アカウントのガバナンス、コンプライアンス、および運用とリスクの監査を行うためのサービスです。ユーザー、ロール、または AWS のサービスによって実行されたアクションは、CloudTrail にイベントとして記録されます。AWS CloudTrail を用いてインスタンス上のOS層のログの取得はできません。
・「スケジュールに従ってトリガーする CloudWatch イベント ルールを使用して、定期的な Amazon EBS スナップショットを作成します。」
→定期的な Amazon EBS スナップショットの作成は、常にログを取得できていないことから不適切です。
「EMRの処理ノードに対してスポットインスタンスを選択する方法」が正解となります。
Amazon EMR はEC2インスタンスのクラスター(複数まとめたもの)と、クラスター内の各インスタンスであるノードで構成されます。
以下の通り、各ノードはクラスター内での役割に応じて「ノードタイプ」が分かれており、処理を分散させることができます。
・マスターノード:ノード間のタスク分担などの調整を行う
・コアノード:タスクを実行し、クラスター上のデータ保存場所にデータを保存する
・タスクノード:実際に割り当てられたタスクを実行する
クラスターをセットアップする際にEC2 インスタンスの購入オプションとしてスポットインスタンスを選択することで、オンデマンドの購入と比較して低コストで Amazon EC2 インスタンスを購入できます。
スポットインスタンスは価格の変動により予想外に終了する可能性があるため注意しましょう。
「アクセス制御に関する推奨項目」が正解(Trusted Advisor によって推奨されない観点)です。Trusted Advisor は、「コスト最適化」「パフォーマンス」「セキュリティ」「耐障害性」「サービスの制限」といったチェックカテゴリが存在します。
CloudFrontのオリジンサーバは、以下の3種類に分類することができます。
オリジンサーバとは、コンテンツを配信する元となっているサーバのことです。
①S3オリジン(バケット)
②S3オリジン(静的ホスティング)
③カスタムオリジン(カスタムオリジンとは一般的なWebサーバでありパブリックとプライベートの両方を扱うことができます。)
DNSレコードとは、ゾーン情報を管理するネームサーバーのサーバー名を定義するレコードです。
「CNAMEレコードを作成する。」が正解となります。 ドメインを別のドメインに関連付けるためにはCNAMEレコードを利用します。CNAMEレコードは別名に対する正式名を指定するためのリソースレコードです。CNAMEリソースレコードを設定すると、ドメイン名を別名に置き換えることができます。
「Aレコードを作成する。」は不正解です。AレコードはドメインまたはサブドメインをIPアドレスに紐づけるために利用します。ドメイン名を切り替える設定の場合は、Aレコードを用いることも可能ですが、名前解決の関連付けには利用できないため不正解となります。
「エイリアスレコードを作成する。」は不正解です。エイリアスレコードを使用すると、CloudFrontディストリビューションやAmazon S3バケットなど、選択したAWSリソースにトラフィックをルーティングできます。 サードパーティのウェブサイトはこれらを制御できないため、これらのウェブサイトには該当しません。
「AAAAレコードを作成する。」は不正解です。 AAAAレコードとは、特定のホスト名に対応するIPv6アドレスを定義するレコードです。
「ゴールデンイメージを利用するアプローチ」と「ブートストラップを利用するアプローチ」が正解となります。
■ブートストラップ(Bashシェルスクリプトの利用)
Amazon EC2インスタンスやAmazon Relational Database(Amazon RDS)DBインスタンスなどのAWSリソースを起動するとき、Bashシェルスクリプトを利用して自動で設定を反映することができます。
■ゴールデンイメージ
Amazon EC2インスタンス、Amazon RDS DBインスタンス、Amazon Elastic Block Store(Amazon EBS)ボリュームなどの特定のAWSリソースタイプは、ゴールデンイメージ(既存のリソースのスナップショット)から複製できます。
ブートストラップアプローチと比較すると、ゴールデンイメージは起動時間を短縮し、構成サービスまたはサードパーティのリポジトリへの依存関係を削除します。これは、需要の変化への応答として追加のリソースを迅速かつ確実に起動できるようにする自動スケーリング環境で重要です。
「スナップショットを利用するアプローチ」は不正解です。
スナップショットで複製できるのはEBSのみです。
「普段使っているAMIを利用するアプローチ」は不正解です。
ゴールデンイメージはAMIの最適な版です。そのため、同じAMIを利用することになりますが、ゴールデンイメージという回答がある中で、普段使っているAMIという選択では不十分です。
「レプリケーションを利用するアプローチ」は不正解です。
インスタンスを直接的にレプリケートすることはできないため、結局はAMIを作成して、他リージョンで展開するなどの対応が必要となります。
AWSにはEC2 Image Builderというサービスもあり、ゴールデンイメージの作成、管理、展開を迅速かつ簡単に自動化することができます。
インスタンスにタグを付け、ユーザーがインスタンスの開始/停止を明示的に許可しても、インスタンスの削除を拒否することで防ぐことができます。
■以下は誤りになります。
「EC2 インスタンスを削除する前に MFA を要求するようにユーザーの IAM ポリシーを変更 し、従業員の MFA アクセスを無効にします。」
「ユーザーの IAM ポリシーを変更して、EC2 インスタンスを削除する前に MFA を要求します。」
→MFA はユーザーがインスタンスを削除することを防ぐことができないため間違いです。セキュリティの追加レイヤーを追加するだけです。
・ALBのアクセスログをS3バケットにデータを保存するように構成できます。Amazon EMRは、企業、研究者、データアナリスト、開発者が膨大な量のデータを簡単かつコスト効率よく処理できるようにするウェブサービスです。EMRは、Amazon EC2およびAmazon S3で構成されたHadoopフレームワークを利用します。
・KinesisもEC2も、ホストされたHadoopサービスを提供するサービスではないため不正解です。
・ALBのアクセスログをDynamoDBに配信するように設定することはできないため不正解です。
Amazon ElastiCache は、Memcached と互換性のあるインメモリ key-value ストアサービスで、キャッシュやデータストアとして使用できます。
「データベース層のセッション処理にElastiCache Memcachedを利用する。」が正解となります。WEBアプリケーションをホストするEC2インスタンスに対して、AutoScalingを設定します。データベース層のセッション処理にElastiCache Memcachedを利用して、CloudWatchによるモニタリングを実施し、リードレプリカを設定したRDSをデータベースとして利用する構成とします。このシナリオでの最適なオプションは、Elasticache、Cloudwatch、およびRDSリードレプリカの組み合わせを使用することです。ウェブサーバーは、読み取り操作にElastiCache Memcachedを使用し、トラフィックの変動を監視してそれに応じてスケールイン/スケールアウトするように自動スケーリンググループに通知するCloudWatchを使用します。さらに、RDSのリードレプリカを使用して、読み取りが多いワークロードを処理します。
Memcached はマルチスレッドであるため、複数の処理コアを使用できます。これは、コンピューティング性能をスケールアップすることで、より多くの操作を処理できることを意味します。
オプション1が正解となります。AWS OpsWorks Stacksを使用すると、AWSおよびオンプレミスでアプリケーションとサーバーを管理できます。 OpsWorks Stacksを使用すると、負荷分散、データベース、アプリケーションサーバーなど、さまざまなレイヤーを含むスタックとしてアプリケーションをモデル化できます。 2) 不正解です。スタックベースで異なる環境を用意するにはCloudFormationよりもOpsWorksで詳細な設定をすることが望ましいです。 3) 不正解です。CodePipeline は完全マネージド型の継続的デリバリーサービスで、素早く確実性のあるアプリケーションとインフラストラクチャのアップデートのための、パイプラインのリリースを自動化します。これ自体では環境設定ができないため正しくありません。 4) 不正解です。Elastic Beanstalk は、Java、.NET、PHP、Node.js、Python、Ruby、Go および Docker を使用して開発されたウェブアプリケーションやサービスを、Apache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするための、使いやすいサービスです。これもインフラのレイヤー毎の展開には利用しません。
オプション2は不正解です。Direct Connect接続は物理的にAWS側と専用線接続を実施します。これはAWSへの申請と設定などが必要不可欠となり、準備が間に合わない可能性があります。
オプション3が正解となります。Amazon VPC で起動するインスタンスは、デフォルトではオンプレミスネットワークと交信できません。お使いのデータセンターや支店のネットワークを AWS サイト間 VPN (Site-to-Site VPN) 接続のあるクラウドに安全に拡張できます。この接続ではインターネットプロトコルセキュリティ (IPsec) 通信を使用して 2 点間に暗号化された VPN トンネルを作成します。この接続設定は、オンプレミス環境のネットワーク機器と設定がわかっていれば、AWSコンソール上で短時間で容易に準備することが可能です。今週末の金曜日から月曜日にかけて72時間でデータ移行を完了させる時間内に実現可能なソリューションです。
Lambdaファンクションを使用するときに他のリソースにアクセスする必要がある場合は、Lambdaが利用するサービスへのアクセス権限を付与するIAMロールが設定されている必要があります。したがって、オプション3が正解となります。 Lambda API やリソース (関数やレイヤーなど) へのアクセスを管理するにはIAMを使用します。Lambda を使用したアカウントのユーザーやアプリケーションのアクセス許可は、IAM ユーザー、グループ、またはロールに適用できるアクセス許可ポリシーで管理します。Lambda リソースを使用する他のアカウントや AWS のサービスにアクセス許可を付与するには、リソース自体に適用するポリシーを使用します。 詳細は以下のサイトを参照ください。 https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-sqs-example.html
すぐ活用できるデータとして蓄積する場合はS3標準ストレージを利用することが最適です。その上で、バージョニングはバケットレベルで行われ、オブジェクトの以前のバージョンの復元に使用できます。したがって、オプション1が正解となります。バージョニングとは、同じバケット内でオブジェクトの複数のバリアントを保持する手段です。バージョニングを使用して、Amazon S3 バケットに格納されたあらゆるオブジェクトのあらゆるバージョンを、格納、取得、復元することができます。バージョニングを使用すれば、意図しないユーザーアクションからもアプリケーション障害からも、簡単に復旧できます。 2) 不正解です。EBSでは耐久性のあるストレージとしてS3に比較して不適切であり、かつデータ共有にも向いていないため、オプション2は不正解です。 3) 不正解です。S3にはスナップショットの機能はないため、オプション3は不正解です。 4) 不正解です。RDSはリレーショナルデータベースであり、耐久性と可用性のあるストレージとしての要件に合致していません。
Auto Scalingの起動時に問題が発生すると、起動グループ内の1つ以上のAuto Scalingプロセスを中断して再開することができます。 これは、Auto Scalingプロセスを起動せずに、Webアプリケーションの設定上の問題やその他の問題を調べてからアプリケーションに変更を加える場合などに利用できます。
AWS CloudTrail は、AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービスです。クロスアカウントアクセスは AWSのIT ガバナンス(企業のIT資産の監視・規律を守る仕組み)を提供し、一括請求を使用して部門アカウントを親企業のマスターアカウントにリンクすることで、コストの監視が可能です。
■以下は不正解です。
・「AWS CloudTrail ログおよび Amazon CloudWatch Logs をメンバーアカウントの各 Amazon S3 バケットにログを書き込みを行う。」→複数のアカウントからのログを単一の S3 バケットに保存し、IT ガバナンスのために CloudTrail を使用し、コスト監視のために CloudWatchアラートを使用する方が良いため間違いです。
・「企業の AWS アカウント内の部門ごとに個別の VPC を作成する。」
→個別の VPC を作成するだけでは、追加のタグ付けとセキュリティ管理が必要になり、コスト監視ができないため間違いです。
・「AWS 一括請求を使用して、部門アカウントのルートアカウントのアクセスを無効にする。」
→AWS 一括請求を使用するためにはメンバーとなるAWSアカウントをリンクさせておく必要があります。ルートアクセスを無効にすることはAWSを利用する際のベストプラクティスだけであり、間違いです。
AWS Import/Export とは、大量のデータを物理ストレージデバイスから AWS に転送するのに使用できるサービスです。
ポータブルストレージドライブを AWS に引き渡すと、AWS Import/Export サービスでAmazon の高速内部ネットワークを使用してお客様のストレージデバイスからデータを直接インポートしたり、エクスポートしたりすることができます。
ただし、AWS Import/Export では Glacier ストレージクラスのデータを直接エクスポートする機能はサポートしていません。これらのオブジェクトをエクスポートするには、一度S3などにオブジェクトを復元しそのデータをエクスポートするような対応をとる必要があります。
AutoScaling を使用した ELB はオンデマンドのスケーリング機能を提供します。また、 CloudFront を使用してキャッシュすると、パフォーマンスが向上し、ウェブサーバーの負荷が軽減されます。
■以下は誤りになります。
「Amazon S3 マルチパートアップロードを使用して、アップロード時間を改善する。」 →Amazon S3 マルチパートアップロードはアップロード時間を改善するだけで、ウェブパフォーマンスの改善には役立たないため間違いです。
「Amazon Route 53 を使用して、トラフィックを正しいリージョンにルーティングする。」 →Amazon Route 53 はルーティングに役立つため間違いです。パフォーマンスのスケーリングや改善には役立ちません。
「すべての静的ファイルをマルチ AZ 配置 の Amazon Aurora データベースに保存する。」 →Amazon Aurora は静的ファイル保管用ストレージではないため間違いです。
AWS CLIを利用するために必要なものです。
・対象サービスの操作権限が付与されたIAMロール
・もしくはアクセスキーとシークレットアクセスキー
セキュリティの観点からアクセスキーでの認証より、IAMロールでの認証の方が適切と言えます。
※参考
AWS アクセスキーを管理するためのベストプラクティス
また、WEBブラウザでアクセスするページのUIは変わることがあるため、同じオペレーションで継続して管理するためにはAWS CLIを利用した方が良い場合があります。
Amazon Redshiftクラスターは、リーダーノードとコンピューティングノードから構成されます。
「Redshiftクラスターのクロスリージョンスナップショットを有効化する。」が正解となります。Amazon Redshiftは高速でシンプルかつ費用対効果の高いデータウェアハウスサービスです。小規模利用からペタバイト単位の構造化データまで、複雑な分析クエリを実行でき、スケールアウトも容易に行うことができます。Amazon Redshift データウェアハウスは、ノードと呼ばれるコンピューティングリソースの集合体であり、これらはクラスターと呼ばれるグループを構成します。各クラスターは、1 つの Amazon Redshift エンジンを実行し、1 つ以上のデータベースを含みます。
Redshiftクラスターのクロスリージョンスナップショットすることで、プライマリクラスターがダウンした場合に備えて即座に利用できる構成を維持することができます。クラスターのスナップショットを自動的に別のリージョンにコピーするように Amazon Redshift を設定できます。スナップショットがクラスターのプライマリリージョンで作成されると、セカンダリリージョンにコピーされます。これらは、それぞれソースリージョンおよびコピー先リージョンと呼ばれます。別のリージョンにスナップショットのコピーを保存することで、プライマリリージョンに影響が及んだ場合に最新のデータからクラスターを復元できるようになります。
「CloudFormationを利用してクラスター構成を自動復元化する。」は不正解です。CloudFormationを利用してRedShiftアーキテクチャの構成を自動化することは可能ですが、起動時に設定することになるため、クラスターダウンに備えるためには自動スナップショット取得を有効化する対応が必要となります。
「RedshiftクラスターをマルチAZ構成に変更する。」は不正解です。Amazon Redshift はシングル AZ 配置のみをサポートしています。
「RedshiftクラスターのスナップショットをS3に保存する設定を行う。」は不正解です。この質問では、RedShiftのクラスターがダウンする場合に備えた設定方法が問われているため、自動スナップショットがクラスターに対して有効にするという設定が必要です。有効にすると実施的にはS3に保存されることになりますが、S3に保存するという操作や設定をユーザー側で実施できるわけではないため、誤りとなります。
「ゲートウェイ VPC エンドポイントを S3 用に作成し、アプリケーションからアクセスする
」、「インタフェース VPC エンドポイントを S3 用に作成し、アプリケーションからアクセスする」が正解です。VPC エンドポイントでは、AWS PrivateLink を使用する AWS のサービスや VPC エンドポイントサービスに VPC をプライベートに接続できます。VPCのエンドポイントには、インターフェース型とゲートウェイ型の2種類があり、S3 もエンドポイントはゲートウェイ型とインターフェース型(2021年2月リリース)があります。なお、ゲートウェイ型のエンドポイントは、S3 と DynamoDB の 2 つです。
プライベートサブネット上に S3 バケットは作成できません。また、同じリージョンに S3 バケットを作成しても、インターネット経由でのアクセスが必要となります。
「EMRの処理ノードに対してスポットインスタンスを選択する方法」が正解となります。
Amazon EMR はEC2インスタンスのクラスター(複数まとめたもの)と、クラスター内の各インスタンスであるノードで構成されます。
以下の通り、各ノードはクラスター内での役割に応じて「ノードタイプ」が分かれており、処理を分散させることができます。
・マスターノード:ノード間のタスク分担などの調整を行う
・コアノード:タスクを実行し、クラスター上のデータ保存場所にデータを保存する
・タスクノード:実際に割り当てられたタスクを実行する
クラスターをセットアップする際にEC2 インスタンスの購入オプションとしてスポットインスタンスを選択することで、オンデマンドの購入と比較して低コストで Amazon EC2 インスタンスを購入できます。
スポットインスタンスは価格の変動により予想外に終了する可能性があるため注意しましょう。
「AWS暗号化SDKを使用する方法」が正解となります。
AWS 暗号化 SDK は言語固有の SDK とは別の暗号化ライブラリです。この暗号化ライブラリを使用すると、アプリケーションで暗号化のベストプラクティスをより簡単に実装できます。AWS 暗号化 SDK は Amazon S3 専用ではなく、任意の場所にデータを保存または復号するために使用できます。
「AWS KMS SDKを利用する方法」は不正解です。
AWS KMS SDKといったツールキットはありません。
「IAM暗号化APIコールを設定する方法」は不正解です。
IAM暗号化APIコールというものはありませんが、必要に応じてIAMを使用してポリシーを設定できます。
「AWS CloudHSMを使用する方法」は不正解です。
AWS CloudHSM は、AWS クラウドで暗号化キーを簡単に生成できるモジュールです。
また、KMSリクエストの1秒あたりの制限(クオータ)の緩和をリクエストすることもできます。その際は、AWS側に申請することとなります。
「CloudFront を使ってコンテンツを提供するように設定を変更し、制限を設ける国からのアクセスを拒否する」が正解です。CloudFront では、GeoIP データベースを使い、地理的ディストリビューションの制限 機能を使うことができます、この機能を利用することで、ある国(地域)からのアクセスに対して 403 (アクセス拒否) のレスポンスを返すことが可能です。
・ALBのアクセスログをS3バケットにデータを保存するように構成できます。Amazon EMRは、企業、研究者、データアナリスト、開発者が膨大な量のデータを簡単かつコスト効率よく処理できるようにするウェブサービスです。EMRは、Amazon EC2およびAmazon S3で構成されたHadoopフレームワークを利用します。
・KinesisもEC2も、ホストされたHadoopサービスを提供するサービスではないため不正解です。
・ALBのアクセスログをDynamoDBに配信するように設定することはできないため不正解です。
AWS Managed VPNが正解となります。
AWS managed VPNを利用することで、オンプレミス環境とVPC間のサイト間でIPsec VPN接続を実行することができます。
AWS Direct VPNは不正解です。
AWS Direct VPNというサービスはありません。
NATゲートウェイは不正解です。
NATゲートウェイは外部から接続できないインスタンスからのインターネットアクセスを可能にする機能です。
Direct Connectは不正解です。
Direct Connectは専用線接続サービスとして、AWS側とオンプレミス環境とを接続することが可能ですが、VPCによる接続方法ではありません。
AWS Managed VPNはオンプレミスの企業ネットワークの拡張や、遠隔地間の安全な通信などの利用を想定されています。
AWS Transit Gatewayは、中央ハブを介して VPC とオンプレミスネットワークを接続できます。
「AWS Transit Gatewayの利用」が正解となります。AWS Transit Gateway を使用すれば、中央のゲートウェイからネットワーク上にある Amazon VPC、オンプレミスのデータセンター、リモートオフィスそれぞれに単一の接続を構築して管理することができます。Transit Gateway がハブの役割を果たし、トラフィックがスポークのように接続されたネットワーク間のルーティングを制御します。このようなハブアンドスポーク型では、各ネットワークを Transit Gateway にのみ接続する必要があり、他のすべてのネットワークに接続する必要がないため、大幅に管理を簡略化して運用コストを削減できます。新たに VPC を追加する場合は、Transit Gateway に接続するだけで、同じ Transit Gateway に接続されている他のネットワークにも自動的につながります。このように接続が簡単なため、成長に合わせてネットワークを難なくスケールできます。
その他のオプションは全て間違った設定方式や、存在しない設定方式のため不正解となります。
Amazon DynamoDBにはテーブルで読み込みおよび書き込みを処理するための読み込み/書き込みキャパシティーモードが 2つあります。
読み取り/書き込みキャパシティーモードは、読み取りおよび書き込みスループットの課金方法と容量の管理方法を制御します。
読み取り/書き込みキャパティーモードは、テーブルを作成するときに設定でき、後で変更することもできます。
・オンデマンド
・プロビジョニング済み (デフォルト、無料利用枠の対象)
プロビジョニング済みを選択すると、予め利用者が予測される読み書きの回数を指定しその必要な分の性能が確保されます。この場合、確保された性能に対して課金されます。
・AWSサービスを活用することで、データウェアハウス(データを蓄積していく保存場所)にデータをロードすることなく、S3のデータに対して高度な分析クエリを直接実行できます。
・データレイクに格納されたデータ資産の分析のためには、AthenaとRedshift Spectrumの両方を使用することができます。通常、Athenaは特定のデータ検出とSQLクエリを実行するために使用します。Redshift Spectrumを使用すると、多数のユーザーが同時に分析レポートを発行したり、より複雑な検索クエリ、分析シナリオに使用できます。
AWS Lambdaは、任意の処理(機能)を実行するためのサーバーレステクノロジー(いわゆるFaaS)で、分析クエリを実行するための最適なソリューションではありません
AWS Glueはデータの加工などを行う、ETL(抽出・変換・格納)サービスであり、主にデータを分析する前に使うサービスです。
RAID0は、書き込みするデータを分割して同時に複数のハードディスクに書き込むことで速度を向上します。「EBSボリュームを追加し、RAID 0構成する。」は正解となります。このシナリオでは、EC2インスタンスでホストされるデータベースの書き込みパフォーマンスを向上させることが求められています。Amazon EBS では、標準的な RAID 設定が使用できます。単一のボリュームよりも高い I/O性能を実現するため、RAID 0 では複数のボリュームをまとめてストライピング構成が実施できます。ボリュームを追加すると、スループットと IOPS を追加することになり、スループットが向上します。
「データベースをホストしているEC2インスタンスのインスタンスタイプを変更する。」は正解となります。 一部のEC2インスタンスタイプ(gp2、io1、st1、またはsc1ボリューム)は、RAIDを構成することで単一のEBSボリュームよりも高いI / Oスループットを出すことが可能です。
「EBSボリュームのボリュームタイプをプロビジョンドIOPSに変更する。」は不正解です。シナリオにあるように、既にEBSは最もスループットが高いもの(プロビジョンドIOPS)を選択しています。
「EC2インスタンスを利用しているVPCの拡張ネットワークを有効化する。」は不正解です。拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。EC2インスタンスのネットワークパフォーマンスを向上させることができますが、根本的な解決ではありません。
「EC2インスタンスを利用しているVPCのエンドポイントを有効化する。」は不正解です。VPCエンドポイントではスループット最適化することはできません。
AWS Lambda はサーバーレスコンピューティングサービスであり、プログラムコードの実行基盤をAWSサービスとして提供します。AWS Lambda はショートバーストを処理し、必要な処理時間のみプログラム実行環境を提供することができます。また、Node.js アプリケーションを AWS Lambda で実行できます。AWS Lambda は必要な時だけプログラムを実行することができ、1日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的に実行基盤のリソースが拡張されるため、毎分5件のリクエストから毎分 5,000 件以上のリクエストを処理できます。
■以下は不正解です。
・「ピーク負荷を処理するために EC2 インスタンスのサイズを変更します。」
→Lambda と比較してコストが高いため間違いです。
・「Amazon ElasticCacheを利用します。」
→ Amazon ElastiCache は、インメモリデータストアおよびキャッシュサービスです。用途が異なるので間違いです。
・「EC2 インスタンス用の Auto Scaling グループを作成します。」
→Auto Scaling は機能します。突発的なリクエストの増加に対応できないため間違いです。
AD Connector は、ActiveDirectoryに対するアクセス要求をオンプレミスの Microsoft Active Directory へリダイレクトするのに使用するディレクトリゲートウェイです。
AWS Directory Service によって、IAM ロールを Microsoft AD または Simple AD のユーザーやグループに割り当てることができます。また、AD Connector を使用して既存のオンプレミス のMicrosoft Active Directory のユーザーやグループも割り当てられます。ユーザのアクセス制御は、 IAM ポリシーに基づきます。AWS Directory Service は、ユーザーがActiveDirectoryの認証情報を用いたサインインに使用するための固有の URL を発行することができます。
■以下は不正解になります。
・AWS Directory Service →AD Connector を用いるため間違いです。
・IAM グループ
・IAM ユーザー
→IAM ユーザーと IAM グループは ID フェデレーションを許可しないため間違いです
CloudFront ディストリビューションを作成して、コンテンツを配信する場所と、コンテンツ配信の追跡と管理の方法を CloudFrontで設定します。Amazon CloudFront はグローバルユーザーに静的コンテンツと動的コンテンツの両方に低レイテンシーアクセスを提供でき、Route 53 と連携する設定ができます。
■ドメイン名を使用したトラフィックの Amazon CloudFront ウェブディストリビューションへのルーティング
ウェブコンテンツの配信を高速化する場合、Amazon CloudFront、AWS コンテンツ配信ネットワーク (CDN) を使用できます。CloudFront は、エッジロケーションのグローバルネットワークを利用し、ウェブサイト全体動的、静的、ストリーミングのコンテンツを配信できます。コンテンツのリクエストは、ユーザーから見て最もレイテンシーが小さいエッジロケーションに自動的にルーティングされます。
■以下は不正解です。
・「ユーザーに最も近いリージョンの Amazon S3 バケットでWEBサイトをホストし、ALB と EC2 インスタンスを削除します。次に、S3 バケットを指すように Amazon Route 53 でDNSレコードを更新します。」 →S3 バケットは静的なウェブサイトのホスティングに適しているため間違いです。動的コンテン ツを提供することはできません。
・「同じWEBアプリケーションをホストする EC2 インスタンスを、ユーザーに近い異なるリ ージョンで新たに立ち上げます。次に、リージョン間 VPC ピアリングを使用して、同じ ALB にインスタンスを登録します。」 →ALB は同じリージョン内のトラフィックをルーティングするため間違いです。
・「ALB の Amazon Route 53 レイテンシーに基づくレコードを作成します。次に、より大きなサイズのインスタンスタイプで新しい EC2 インスタンスを起動し、そのインスタンスを ALB に登録します。」→Route53 レイテンシーに基づくルーティングは、全世界のリージョンで提供しているアプリケーションに適しており、ユーザから最も近いリージョンから応答を返すことができます。複数の AWS リージョンにリソースがあり、遅延を極力少なくする要件が求められる場合に利用します。
「EBSボリュームは同じAZ内のインスタンスにのみアタッチできる。」が正解となります。
「EBSボリュームを複数インスタンスにアタッチできる。」は不正解です。
EBSボリュームは一つのインスタンスにのみアタッチできます。
「EBSボリュームは同じリージョンのインスタンスであればアタッチできる。」、「EBSボリュームは同じVPCのインスタンスにのみアタッチできる。」は不正解です。
EBSボリュームは同じAZ内のインスタンスにのみアタッチできます。
Webアプリケーションにおいて、複数インスタンスかsら利用されるストレージとしてはEFSやS3などの選択肢もあります。要件に応じて最適なサービスを選択しましょう。
この問題の正解はプライベートサブネットになります。
EC2で構築したサービスをインターネットに公開する場合、通常はEC2インスタンスをパブリックサブネットに配置する必要があります。ただしこの問題のケースの場合、EC2の前にパブリックサブネットに配置されたELBがあるので。インターネットからのアクセスはELBが受けることになります。EC2にはELBからのみアクセスを許可しておけばよいため、セキュリティの観点からEC2インスタンスは「プライベートサブネット」に配置することが正解となります。
「最大5つのリードレプリカを利用した高速読み込みが可能」が間違った内容であるため正解となります。
Amazon Auroraは最大15のリードレプリカを利用した高速読み込みが可能です。
「PostgreSQL10.4と互換性がある」と「MySQL5.7と互換性がある」は正しい内容です。
Amazon AuroraはAWS完全マネージド型のリレーショナルデータベースエンジンで、MySQL および PostgreSQL と互換性があります。MySQL と PostgreSQL が、高級な商用データベースのスピードおよび信頼性と、オープンソースデータベースのシンプルさとコスト効率を併せ持っています。既存の MySQL および PostgreSQL データベースで現在使用しているコード、ツール、アプリケーションを Aurora でも使用できます。更にAurora では MySQL のスループットの 5 倍、PostgreSQL のスループットの 3 倍を実現することも可能です。
「可用性は99.99%である」も正しい内容です。
Amazon Aurora は 3 つのアベイラビリティーゾーンにわたってユーザーのデータを 6 個複製し、継続的に Amazon S3 にバックアップすることで、可用性が 99.99% を超えるように設計されています。インスタンスのフェイルオーバー(障害発生時の別サーバーへの切り替え)は通常 30 秒未満で完了します。また、数秒で過去のある時点の状態にDBを戻すこともできます。Global Database を使用すれば、単一の Aurora データベースを複数の AWS リージョンで利用できるため、ローカルで高速な読み取りと迅速な災害復旧が可能になります。
標準メトリクスでは、OSの外から測定できるメトリクスしか取得できません。
また、よく混同されがちなケースですが、メモリ利用率などといったOS内でしか測定できないメトリクスはカスタムメトリクスで取得する必要があるので基本的な監視項目を検討する場合にはカスタムメトリクスを設定しましょう。
データベースの暗号化は、データベースの作成中に行うことができます。保管時の Amazon RDS DB インスタンスとスナップショットを暗号化するには、Amazon RDS DB インスタンスの暗号化オプションを有効にします。保管時に暗号化されるデータには、DB インスタンス、自動バックアップ、リードレプリカ、スナップショットの基本的なストレージが含まれます。
オプション1が正解となります。AWS OpsWorks Stacksを使用すると、AWSおよびオンプレミスでアプリケーションとサーバーを管理できます。 OpsWorks Stacksを使用すると、負荷分散、データベース、アプリケーションサーバーなど、さまざまなレイヤーを含むスタックとしてアプリケーションをモデル化できます。 2) 不正解です。スタックベースで異なる環境を用意するにはCloudFormationよりもOpsWorksで詳細な設定をすることが望ましいです。 3) 不正解です。CodePipeline は完全マネージド型の継続的デリバリーサービスで、素早く確実性のあるアプリケーションとインフラストラクチャのアップデートのための、パイプラインのリリースを自動化します。これ自体では環境設定ができないため正しくありません。 4) 不正解です。Elastic Beanstalk は、Java、.NET、PHP、Node.js、Python、Ruby、Go および Docker を使用して開発されたウェブアプリケーションやサービスを、Apache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするための、使いやすいサービスです。これもインフラのレイヤー毎の展開には利用しません。
このシナリオでは、APIゲートウェイの権限管理として、開発者、IT管理者、およびユーザーに適切なレベルの権限を与えて管理する必要があり、API Gatewayに対するアクセス権限の設定方法が問われています。IAMポリシーを利用したアクセス権限でAmazon API Gatewayへのアクセスを制御します。したがって。オプション2が正解となります。 Amazon API Gatewayへのアクセスを IAM アクセス権限で制御するには、 2 つの API Gateway コンポーネントプロセスへのアクセスを制御します。 API の呼び出しや API キャッシュの更新を API コール元に許可するには、IAM ユーザー認証が有効な API メソッドを呼び出すことを、特定の API コール元に許可する IAM ポリシーを作成する必要があります。API 開発者は、メソッドの authorizationType プロパティを AWS_IAM に設定して、呼び出し元が認証対象の IAM ユーザーのアクセスキーを送信することを要求します。次に、このポリシーを、API コール元としての IAM ユーザー、ユーザーが属する IAM グループ、またはユーザーが引き受ける IAM ロールにアタッチします。
オプション1は不正解です。Snowballは実際にAWSから機器を借りてきて実行することが必要であり、それをAWS側に物理的に送付する時間が必要となります。データ量が多い場合に便利ですが、今回のように短時間での移行には向いていません。
Lambdaファンクションを使用するときに他のリソースにアクセスする必要がある場合は、Lambdaが利用するサービスへのアクセス権限を付与するIAMロールが設定されている必要があります。したがって、オプション3が正解となります。 Lambda API やリソース (関数やレイヤーなど) へのアクセスを管理するにはIAMを使用します。Lambda を使用したアカウントのユーザーやアプリケーションのアクセス許可は、IAM ユーザー、グループ、またはロールに適用できるアクセス許可ポリシーで管理します。Lambda リソースを使用する他のアカウントや AWS のサービスにアクセス許可を付与するには、リソース自体に適用するポリシーを使用します。 詳細は以下のサイトを参照ください。 https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-sqs-example.html