note2

ｚバケット）
②S3オリジン（静的ホスティング）
③カスタムオリジン（カスタムオリジンとは一般的なWebサーバでありパブリックとプライベートの両方を扱うことができます。）

 

Auto ScalingでスケールアウトしたEC2インスタンスをスケールインする場合、デフォルトでは以下の順番で実行されます。
・インスタンス数（最も多いAZから優先）
・上記同条件の場合、起動設定が古いインスタンスがあるAZを優先
・起動設定が古いインスタンスが複数ある場合は、次の課金発生までの時間が最も短いインスタンスを優先
・次の課金発生までの時間が同じインスタンスが複数ある場合はランダム

VM Import/Export を使用すると簡単に、仮想マシンイメージを既存の環境から Amazon EC2 インスタンスにインポートしたり、オンプレミス環境にエクスポートしたりすることできます。この機能によって、元々持っていた仮想マシンを AWSに持ち込み、Amazon EC2 のインスタンスとしてすぐに使用できる状態とすることができます。これにより、IT セキュリティ・構成管理・コンプライアンス等、効率的に要件に合わせて仮想マシンを作成できます。
AWS Storage Gateway は、オンプレミスから実質無制限のクラウドストレージへのアクセスを提供するハイブリッドクラウドストレージサービスです。Storage Gateway を使用して、ストレージ管理を簡素化し主要なハイブリットクラウドストレージの仕組みを素早く構成することができるためコストを削減できます。
Snowball はセキュリティに考慮して設計されたデバイスを使用するペタバイト規模のデータ転送ソリューションで、AWS クラウド内外に大容量データを転送できます。

 

CloudFront では、GeoIP データベースを使い、地理的ディストリビューションの制限 機能を使うことができます、この機能を利用することで、ある国(地域)からのアクセスに対して 403 (アクセス拒否) のレスポンスを返すことが可能です。

 

AWS CLIを利用するために必要なものです。
・対象サービスの操作権限が付与されたIAMロール
・もしくはアクセスキーとシークレットアクセスキー
セキュリティの観点からアクセスキーでの認証より、IAMロールでの認証の方が適切と言えます。

 

「Kinesis Data Firehoseを利用してS3にログを蓄積し、Athenaを利用してログ解析を行う組み合わせ」が正解となります。
Amazon Kinesis Data Firehose は、アクセスログなどのストリーミングデータを各種データストアにロードできます。蓄積場所としてはAmazon S3、Amazon Redshift、Amazon Elasticsearch Service、Splunk などがあり、設問の要件では大量ログをコスト効率よく蓄積するためS3を選択することが最適です。
Amazon Athena ではAmazon S3 内のデータを標準 SQL を使用して簡単に分析できます。

 

Aレコード：ドメイン名からIPアドレスを解決するのはAレコード
CNAMEレコード：ドメイン名から別のドメイン名を参照するレコード
MXレコード：対象ドメイン宛のメール配送先ホスト名を定義するレコード
NSレコード：DNSで定義されるそのドメインについての情報の種類の一つで、ドメインのゾーン情報を管理するDNSサーバを定義するレコード

 

Amazon S3 は、データセンターのディスクに書き込まれるときにデータをオブジェクトレベルで暗号化し、ユーザがデータにアクセスするときに復号します。リクエストが認証され、ユーザがアクセス許可を持っていれば、オブジェクトが暗号化されているかどうかに関係なく同じ方法でアクセスできます。たとえば、署名付き URL を使用してオブジェクトを表示する場合、オブジェクトが暗号化されているかどうかは関係ありません。また、バケット内のオブジェクトを一覧表示する場合においても、オブジェクトが暗号化されているかどうかに関係なく、すべてのオブジェクトを表示することができます。

Amazon S3 で保管時のデータを保護するには、以下のようなオプションがあります。
・サーバー側の暗号化を使用する
オブジェクトをデータセンター内のディスクに保存する前に暗号化し, オブジェクトをダウンロードするときに復号するように Amazon S3 にリクエストします。
・クライアント側の暗号化を使用する
クライアント側でデータを暗号化し、暗号化したデータを Amazon S3 にアップロードします。この場合、暗号化プロセス、暗号化キーはユーザ側で管理します。

API Gatewayはクライアントからリクエストを受け取ってそれをバックエンドに渡すし、バックエンドからレスポンスを受け取ってクライアントに返すし、プロキシのような働きを行います。
ウェブページはバックエンドサービスのドメインとは別のドメインにあるため、API Gateway で CORS を有効にします。これは、クロスオリジンコールであり、セキュリティのためにブラウザによって制限されています。ドメイン間リクエストを許可するには、API Gateway で CORS を有効にする必要があります。
API のリソースが API 自身のドメイン以外のドメインからリクエストを受信する場合、リソース上の選択されたメソッドのクロスオリジンリソース共有(CORS)を有効にする必要があります。

 

Amazon EBS 暗号化 は、EBS ボリュームのために、独自のキー管理インフラストラクチャの構築、管理、および保護を必要としない、簡単な暗号化ソリューションを提供します。暗号化された EBS ボリュームを作成し、サポートされるインスタンスタイプにアタッチする場合、以下のタイプのデータが暗号化されます。
・ボリューム内の保存データ
・ボリュームとインスタンスの間で移動されるすべてのデータ
・ボリュームから作成されたすべてのスナップショット
・それらのスナップショットから作成されたすべてのボリューム
暗号化オペレーションは EC2 インスタンスをホストするサーバー上で実行され、インスタンスとそれに接続された EBS ストレージ間でのデータの保存と転送中のデータの両方のセキュリティを保証します。

 

AWS CloudTrail は、AWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービスです。クロスアカウントアクセスは AWSのIT ガバナンス(企業のIT資産の監視・規律を守る仕組み）を提供し、一括請求を使用して部門アカウントを親企業のマスターアカウントにリンクすることで、コストの監視が可能です。

サービスコントロールポリシー (SCP) は、AWSの子アカウントのアクセス権を制御することができます。
AWSのマスターアカウント管理者は、サービスコントロールポリシー (SCP) を使用して、組織内のメンバーアカウントのアクセス権限を設定できます。SCP を使用すると、各メンバーアカウントのユーザーとロールがどの AWS サービスリソースおよび個々の API アクションにアクセスできるかを制限することができます。AWS Organizations がメンバーアカウントのサービス、リソース、または API アクションへのアクセスをブロックすると、そのアカウントのユーザーまたはロ ールはアクセスできません。このブロックは、メンバーアカウントの管理者が IAM ポリシーで明示的にそのようなアクセス許可をした場合でも有効です。

 

AWS Data Pipeline は、データの移動と変換を自動化するサービスです。AWS Data Pipeline はデータ駆動型のワークフローを定義して、タスクの正常な完了をトリガーにして、次のタスクを実行できます。AWS Data Pipeline はDynamoDBに設定することが可能であり、定期的なデータ取得タスクを設定させることができます。

DynamoDBストリームを有効化することで、DynamoDBテーブルへのデータ登録や更新などのイベントをトリガーとして、Lambda関数などを実行して処理することができます。これにより、DynamoDBのデータを取得することも可能ですが、定期的にデータ取得するような処理ではなく、イベント起動になってしまうため、要件に合致していません。

EC２インスタンスがIAMデータベース認証を利用してDB インスタンスにアクセスが可能です。この認証方法では、DB インスタンスに接続するときにパスワードではなく、認証トークンを使用します。認証トークンはAmazon RDS がリクエストに応じて生成する一意の文字列であり、AWS 署名バージョン 4 を使用して生成されます。各トークンには 15 分の有効期間があります。認証トークンは IAM を使用して外部的に管理されるため、ユーザー認証情報をデータベースに保存する必要はありません。

このシナリオでは、EC2インスタンスにホストされたデータベースサーバーの書き込みパフォーマンスを向上させることが求められています。 これを実現するには、インスタンスボリュームに標準のRAID 0構成を設定するか、EC2インスタンスのサイズを大きくします。

RAID 0とは、複数のストレージ（外部記憶装置）をまとめて一台の装置のように管理するRAID技術の方式（RAIDレベル）の一つで、複数の装置に均等にデータを振り分け、並行して同時に記録することで読み書きを高速化することができます。したがって、オプション２が正解となります。

SAML（Security Assertion Markup Language）はインターネット上で、IDやパスワードなどの認証情報を連携するためのXMLベースの仕様です。SAMLは主にエンタープライズアプリケーション間の認証で使われています。SAMLはMicrosoft Active Directoryを使用しているため、AWSクラウドへのAPIアクセス用にSAMLベースのフェデレーションを設定できます。

AWS Single Sign-Onなどのサービスを利用することで、SAMLによる認証の仕組みを実現することが可能です。AWS SSO は SAML IdP 機能を AWS Managed Microsoft AD または AWS SSO ディレクトリに追加します。それにより、ユーザーは、AWS マネジメントコンソール やサードパーティー製アプリケーションなど、SAML をサポートするサービスへの SSO が可能になります。

 

AWS Elastic Beanstalk はECSなどのDocker サービスと連携して、容量のプロビジョニング、負荷の分散、スケーリング、およびアプリケーションの状態の監視の詳細を自動化することができます。したがって、オプション３が正解となります。

ECSはDocker形式でのアプリケーション開発環境を構築することができるオーケストレーションサービスです。これを利用してAWSリソースの展開は可能ですが、リソースのプロビジョニング、負荷分散、オートスケーリング、監視、クラスター全体でのコンテナ配置などのタスクの自動化にはElastic Beanstalkとの連携が必要です。

シンプルルーティングはドメインで特定の機能を実行する単一のリソースがある場合に使用します。シンプルルーティングではトラフィックを複数インスタンスなどに分散してルーティングして、ランダムに制御されます。

RDSのインスタンスタイプにおいてIOPS性能が高いタイプを選択して高性能な処理が行えるように設定することで、ランダムＩ／Ｏ遅延を防ぐことができます。また、必要に応じてリードレプリカを増強させるのも良いでしょう。

ElastiCacheは高速データ処理に向いていますが、NoSQL型のデータベースの代表的なAWSサービスです。こちらもリレーショナルデータベースとして利用することはできません。

Amazon Athenaを利用することでAmazon S3 から直接データに対してクエリ処理が可能となります。その際には実行するクエリに対してのみ料金が発生し、各クエリでスキャンされるデータ量に基づいて課金されます。データの圧縮、分割、列形式への変換を行うと、大幅なコスト削減とパフォーマンス向上を実現でき、データ処理コストを抑えることができます。

RDSは一般的なリレーショナルデータベースとしてデータを中長期処理するために利用されます。データ処理を行って、短期間でデータを削除するといったライフサイクル管理には向いていません。

サーバーサイド暗号化を使用すると、Amazon S3 はオブジェクトをデータセンター内のディスクに保存する前に暗号化し、オブジェクトをダウンロードするときにS3側で自動で復号します。

S3 バケットに対して暗号化キーによるサーバーサイド暗号化 を有効化すると、各アクセスログファイルは、S3 バケットに保存される前に自動的に暗号化され、アクセス時に復号されます。したがって、ログも自動で暗号化されるため、S3バケットの暗号化と別に設定する必要はありません。

SSE-S3はAmazon S3 で管理された暗号化キーにより実施されるサーバーサイド暗号化です。ユーザーがキーに対するアクセス管理はできませんが、署名バージョン4によりアクセス制限が設定され、所有者であるAWSアカウントID以外からのアクセスを拒否します。SSE-S3は暗号化と復号化をS3が自動で実施してくれるため最も管理に手間がかからない暗号化方式であり、要件に合致します。

DynamoDBはそのままではリードレプリカを増やすことができません。後述するDAX を有効化することで、DAXクラスターは、1 つのみのプライマリノードと、0～9 個のリードレプリカノードを構成することができます。

Amazon Kinesis Data Firehose はストリーミングデータをデータレイクやデータストア、分析ツールに配信するサービスです。ストリーミングデータをキャプチャして変換しつつ、Amazon S3、Amazon Redshift、Amazon Elasticsearch Serviceにロードします。DynamoDBに配信することはできません

 

Amazon ECS はELBのいずれかのタイプのロードバランサ―を使用できます。Application Load Balancer は、HTTP/HTTPS (またはレイヤー 7) トラフィックをルーティングするために使用されます。Network Load Balancer と Classic Load Balancer は、TCP またはレイヤー 4 トラフィックをルーティングするために使用されます。

バケットに対するオブジェクト作成・更新・削除などのデータ処理のイベントをトリガーとしてレプリ ケーションが実行されます。クロスリージョンレプリケーション は、異なる AWS リージョンにある２つのバケット間でオブジェクトを自動的に非同期にコピーする機能です。クロスリージョンレプリケーションは同じ AWS アカウントが所有するバケットにも、異なるアカウントが所有するバケットにも設定できます。

AWS CloudHSMを利用した鍵管理により、EUなどの各国の厳しいセキュリティ基準を満たすことができます。AWS CloudHSMは安全なキーストレージや高パフォーマンスの暗号化オペレーションを AWS アプリケーションに対して簡単に追加できるようにするクラウドベースのハードウェアセキュリティモジュール (HSM) です。AWS CloudHSM では不正使用防止策が施された HSM へのシングルテナントアクセスを利用できます。HSM は暗号化モジュール向けの FIPS 140-2 レベル 3 標準に準拠しています。

Amazon Inspector は自動化されたセキュリティ評価サービスで、AWS にデプロイしたアプリケーションのセキュリティとコンプライアンスを向上させることができます。今回の用途には利用できません。

アクセス頻度は低いですが、管理担当者からの依頼に応じて即時にデータを参照できる必要があります。
S3 One Zone-IA は、アクセスが頻繁ではないデータをコストを押させて保存するのに最適なストレージクラスです。また、データ取り出しは通常の標準クラスと同じように即時に実行可能です。複数AZにデータを保存する標準クラスやStandard-IAとは異なり、S3 One Zone-IA は単一AZにデータを保存することによってコストを節約します。 したがって、データ冗長性は劣るため、バックアップのコピーや再作成可能なデータサマリーなど、アクセスが頻繁ではないデータを低価格に保存するのに向いています。Standard-IAとOne Zone-IAとを選ぶ基準は、保存されるデータの重要度です。ログファイルなどのマスターではないデータは、One Zone-IAを利用することがユースケースとして最適であるため、本件の要件に合致します。

/24の設定により、256個のIPアドレスを利用できます（実際はAWS側で予約されているIPアドレスも含まれます。）。これは200個のIPアドレスを利用する最適なIPアドレス数です。

 

オプション１は不正解です。/21の設定により、2048個ののIPアドレスを利用できるため、利用できる数が多すぎます。

オプション２は不正解です。/22の設定により、1024個ののIPアドレスを利用できるため、利用できる数が多すぎます。

オプション３は不正解です。/23の設定により、512個ののIPアドレスを利用できるため、利用できる数が多すぎます。

VPCのDNS hostnamesオプションが有効化されていないと、サブネットで起動されたインスタンスはDNS名を取得できません。

VPC 内で起動したインスタンスがパブリック IP アドレスに対応するパブリック DNS ホスト名を受け取るかどうか、および Amazon DNS サーバーを通じた DNS 解決が VPCに適用されるかは、VPCの操作で決定されます。VPCのDNS hostnamesオプションを有効化するためには、 enableDnsSupport 属性を「 true」 に設定した上で、enableDnsHostnames属性を「true」に設定して、VPC 内のインスタンスがDNS ホスト名を取得可能とします。

SQSを利用して可視性タイムアウトを設定することで、特定のインスタンスにおいて一定期間キューが処理されない場合に限り、可視性タイムアウトを超過するとスポットインスタンス側でキューが見えるようになり処理が実行されるようになります。この設定により、特定のEC2インスタンスでの処理が優先されるものの、可視性タイムアウトを超過した場合にのみ、別のインスタンスによって処理されるような設定することが可能です。これにより、特定のキューに対して特定のインスタンスでの処理を優先させて、複数のインスタンスでキューが処理されるのを防ぐことができます。

このシナリオでは、Glacierにデータ保存後、ボールトへのアクセス制御をポリシーとして設定して、そのポリシーが編集できないようにすることが要件となっています。Glacier のVault Lockでは、ボールトロックポリシーを使用して、Glacier の各ボールトに対するコンプライアンス管理を簡単に適用することができます。そして、ボールトロックを適用することで、そのポリシーが編集できないように設定することが可能です。

3enインスタンスはAmazon EC2 において GB あたりの料金が最も安価なストレージ最適化インスタンスです。このインスタンスタイプは数万 IOPS もの低レイテンシーなランダム I/O オペレーションには向いていません。

 

バンドID、アルバムID、ソングID、作曲者IDなどのデータをキーバリューストアとドキュメントモデル形式で保存することができるのはDynamoDBです。DynamoDB は、テーブル内の属性に対してさまざまなデータ型がサポートされています。

DynamoDBが保存できるデータ型は次のように分類できます。

 

■スカラー型

スカラー型は 1 つの値を表すことができます。スカラー型は、数値、文字列、バイナリ、ブール、および null です。

■ドキュメント型

ドキュメント型は JSON ドキュメントなどの入れ子の属性を持つ複雑な構造を表すことができます。

■セット型

セット型は複数のスカラー値を表すことができます。セット型は、文字セット、数値セット、およびバイナリセットです。

ストレージアクセスを分析し、適切なデータを適切なストレージクラスに移行する時期を判断することが必要です。

Amazon S3 分析のストレージクラス分析により、ストレージアクセスパターンを分析し、適切なデータを適切なストレージクラスに移行すべきタイミングを判断できます。ストレージクラス分析がフィルタリングされたデータセットのアクセスパターンを一定期間監視することで、ライフサイクルポリシーを設定することができます。

キャッシュされるべきデータがエッジロケーションにないため、オリジンサーバーへのアクセスが頻発しています。

この問題はCache-Controlのmax-ageディレクティブが低い値に設定されていることが主な原因です。キャッシュ保持期間が非常に短いためリクエストは頻繁にオリジンサーバーに送信されます。通常、CloudFrontは、指定したキャッシュ期間が経過するまで、エッジロケーションからオブジェクトを処理します。

キャッシュの有効期限が切れると、エッジロケーションがオブジェクトのユーザーリクエストを取得した際に、CloudFrontはリクエストをオリジンサーバーに転送して、キャッシュに最新バージョンのオブジェクトが含まれていることを確認します。max-ageディレクティブが低いとキャッシュへの確認が短いサイクルとなり、オリジンサーバーへの確認回数が増加します。

レガシーアプリケーションはマルチキャストネットワーキングに依存しており、AWSで確実に起動させるための特別な設定が必要です。

このレガシーアプリケーションはマルチキャストネットワーキングに依存しており、AWSで確実に起動させるためには、仮想オーバレイネットワークをインスタンスのOSレベルで起動させることが求められます。したがって、レガシーアプリケーションを移行するためにオーバーレイマルチキャストを使用することが必要となります。 オーバーレイ・マルチキャストとは，クライアント・パソコンにインストールしたアプリケーション・ソフトでマルチキャスト（1対多通信）を実現する技術です。

マルチキャストは、1対多のデータ配信を可能にするネットワーク機能です。1つ以上の送信元が、通常マルチキャストグループ内に存在する加入者にネットワークパケットを送信できます。 ただし、VPCはマルチキャストまたはブロードキャストネットワーキングをサポートしていないことに注意してください。

Lambda関数は実行数に応じて支払いが発生するため、 Lambda関数が無期限に実行されないようにタイムアウト設定がなされています。 指定されたタイムアウトに達するとLambda関数は実行を終了します。そのため、予想される実行時間に基づいてタイムアウト時間を設定することが必要となります。 デフォルトのタイムアウトは3秒で、AWS Lambdaのリクエストあたりの最大実行時間は900秒です。これは15分に相当します。よって、15分を超過した処理が発生すると計算処理が途中で終了してしまいます。

このシナリオでは、データ処理は約10分～15分間実行されており、計算結果に間違いが発生しているということが問題となっています。約10分～15分間実行される処理が15分で絶対に完了するという保証はないため、15分を超過した処理は計算処理の途中で終了している可能性があります。

 

複数のアベイラビリティーゾーンに設置された複数のEC2インスタンスに着信要求を均等に分散するELBの設定が必要です。

ロードバランサーのノードは、クライアントからのリクエストを登録済みターゲットに分散させます。ELBのクロスゾーン負荷分散を有効とすると、ロードバランサーノードは有効なすべてのアベイラビリティーゾーンの登録済みターゲットにトラフィックを分散します。したがって、複数のアベイラビリティーゾーンにわたって全EC2インスタンスに着信要求を均等に分散することが可能となります。

AWSのVPCとオンプレミス環境とをネットワーク接続するための方法は、次のようなサービスを利用します。

 

・Direct Connect

・IPsec VPN接続

・AWS VPN CloudHub

・サードパーティソフトウェアのVPNアプライアンス

 

日本のユーザーは東京リージョンのサーバーに接続し、韓国のユーザーはソウルのサーバーに接続する必要があります。

Route53の位置情報ルーティングを使用すると、ユーザーの位置情報、つまりDNSクエリの発信位置に基づいてトラフィックを処理するリソースを選択できます。 たとえば、ヨーロッパからのすべてのクエリをノルウェー地域のELBロードバランサーにルーティングして、アジア地域のクエリは東京リージョンのELBロードバランサ―にルーティングを設定することができます。

Route 53 コンソールで地理的近接性ルーティングによりユーザーとリソース間の物理的な距離に基づいてトラフィックをルーティングできます。地理的近接性ルーティングはAWSリソース位置とユーザーの距離の2点に応じたトラフィック制御により、リージョン範囲を区分けすることが可能です。地理的近接性に基づくため国を指定するといった対応ではありません。したがって、ヨーロッパからのすべてのクエリをフランクフルトの ELB ロードバランサーにルーティングするといった処理には位置情報ルーティングを使用する方が最適です。

 

マルチAZ構成のAmazon　RDSでは、プライマリデータベースのインスタンスがダウンした場合に管理者の介入なしにデータベース操作をできるだけ早く再開できるように、フェールオーバーが自動的に処理されます。 フェイルオーバーすると、Amazon RDSはDBインスタンスのCNAMEレコードをスタンバイから切り替えて、新しいプライマリに昇格します。

Amazon S3にバックアップまたは保存される全データは暗号化する必要があります

法に相互に排他的な3つのオプションがあります。

 

・Amazon S3管理キーでサーバーサイド暗号化を使用する（SSE-S3）

・AWS KMS管理キーを使用したサーバーサイド暗号化を使用する（SSE-KMS）

・顧客提供のキーを使用してサーバーサイド暗号化を使用する（SSE-C）

 

SSE-S3はAES-256暗号化を使用した暗号化方式です。SSE-Cはユーザーがユーザー自身の暗号化キーを使用することを可能にします。よって、AES-256を利用するという選択が正しいです。

 

EC２インスタンスとデータベース間の設定にIPアドレスが利用されている場合において、Auto Scalingのターミネーションポリシーが古いEC2インスタンスから削除される設定の場合に、既存インスタンスが削除されてしまIPアドレスが変更されてしまいます。IPアドレスが切り替わってしまうため、IPアドレス指定した連携が機能しなくなってしまいます。IPアドレスが異なるため残ったっインスタンスはデータベースに接続できません。

EC２インスタンスとデータベース間の設定にIPアドレスが利用されている場合において、EC2インスタンスにElastic IPが設定されていないと、インスタンスの起動時にIPアドレスが変更されてしまうため、データベースに接続できなくなってしまいます。

AutoScaling が起動したEC2インスタンスにデータベースと関連づいたEIPが付与される設定をしていないと、これらのインスタンスがデータベースにアクセスができなくなってしまいます

 

オプション２が正解となります。このシナリオでは、サーバー用のOSはLinux を利用しアプリケーションを構成し、運用ダッシュボードとLinux OSのバッチ配布の自動化が必要です。AWS Elastic Beanstalk は自動的にデプロイタスク (バッチ配布の自動化、容量のプロビジョニング、負荷分散、Auto Scaling、アプリケーションのヘルスモニタリングなど) を処理します。AWS Elastic BeanstalkによりアプリケーションがホストされるAWS リソースをユーザー側で完全に制御することができます。また、Elastic Beanstalkコンソールを運用ダッシュボードとして、環境の状態とアプリケーションの状態を一目で分かるように表示することができます。

 

オプション１は不正解です。CloudFormationはAWSのインフラストラクチャリソースをJSONとYAMLで記述してプロビジョニングするための共通言語を提供するサービスです。これは運用管理ダッシュボードなどは提供していません。

 

VPCフローログを有効化することで、EC2インスタンスとネットワークインターフェイスとの間で行き来する IP トラフィック情報をキャプチャできます。このデータをCloudWacthなどで集約することで、ログの中央管理が達成できます。

オプション４が正解となります。AWS には複数アカウントや複数リージョンにわたって、ログを収集、分析、表示するための、中央ロギングソリューションが用意されています。この仕組みを構築するためには、EC2インスタンスのログファイルおよび VPC フローログをキャプチャしていく必要があります。CloudWatchエージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集することができます。これにより、ログの中央管理が達成できます。

AWS CloudTrail はAWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービスです。AWS CloudTrailが取得ログはユーザーのログであり、要件に合致していません。

 

EC2インスタンスがヘルスチェックに失敗した場合、ロードバランサーは異常なインスタンスに新しいリクエストを送信せずに、既存のリクエストの完了を許可する必要があります。

Connection Drainingは既存の接続を開いたまま、登録解除または異常なインスタンスへのCLBのリクエスト送信を停止することができます。これにより、ロードバランサーは、登録解除または異常なインスタンスに対して行われた実行中のリクエストを完了するトラフィック処理を実施します。

ロードバランサーのConnection Drainingを有効にすると、インスタンスの登録解除を報告する前に、ロードバランサーが接続を維持する最大時間を指定できます。 最大タイムアウト値は1〜3,600秒に設定できます（デフォルトは300秒です）。 最大時間制限に達すると、ロードバランサーは登録解除インスタンスへの接続を強制的に閉じます。

Amazon EC2 instance store-backed AMIを使用してEC2インスタンスを作成すると、そのインスタンスのデータはインスタンスストアに保存されます。インスタンスストアボリューム上のデータはインスタンスの存続期間中のみ持続するため、インスタンスが終了するとデータは自動的に削除されます。
Route53のフェールオーバー設定のアクティブ／アクティブ構成によって、レイテンシールーティングなどのルーティングポリシーを利用してフェールオーバーを構成することができます。その場合は、アクティブ／アクティブ構成となり、設定された全リソースを平等に利用することができます。リソースが利用できなくなると、そのリソースを Route 53 が異常として検出し、以後、クエリへの応答に含めることを控えます。

 

その際に、あなたはEBSボリュームの保存データは保持したいと考えています。
インスタンスを終了すると、EC2 は接続されていた各 EBS ボリュームの DeleteOnTermination 属性 を使用して、ボリュームを存続させるべきか、削除すべきかを判断します。デフォルトでは、インスタンスのルートボリュームの DeleteOnTermination 属性が有効化されており、EC２インスタンスの削除とともにEBSも削除されてしますが、その他のボリュームタイプではDeleteOnTermination 属性は非有効化されています。インスタンスが停止してもルートボリュームを維持したい場合は、ルートボリュームの DeleteOnTermination 属性を非有効化することが必要です。それによって、インスタンス削除後にデータを存続させることが可能です。

 

他社と物理サーバーを共有してはいけないことになっています。更に同じAWSルートアカウントに属しているとしても、部署が違うIAMアカウント同士では物理サーバーを共有することができないようにする必要があります。

Dedicated Hostは物理的にサーバーを占有するインスタンスタイプです。Dedicated Hosts では、ユーザーはライセンス条項の範囲で、ソケット単位、コア単位、または VM ソフトウェア単位の既存のライセンスを利用できます。IAMユーザーやIAMグループが同じAWSアカウントに属していたとしても、権限が異なる別のIAMユーザーやIAMグループとは物理サーバーを共有しません。

 

DynamoDBはリアルタイムのデータ集計処理に使用できる、耐久性、拡張性、および可用性の高いデータストアです。AppSyncを使用して、DynamoDBのデータをリアルタイムで最新の状態に保つコラボレーションアプリを簡単に構築できます。 これにより、アプリケーションはAmazon DynamoDBのデータにアクセスしたり、EC２インスタンスやAWS Lambda関数がデータ処理を実行するなどの機能を実装することができます。したがって、DynamoDBとAppSyncとを連携して、リアルタイム処理機能を実装することが可能です。
リアルタイム行動分析やランキング処理にはAppSyncを利用することが最適です。

 

本環境DR環境（ディザスタリカバリ）と遠隔DR環境を別リージョンに設置して、その管理をRoute53で実施することで、他の選択肢よりもAWSのマネージドサービスを利用した自動フェイルオーバーが利用可能であり、DR対応を自動化することができます。したがって、オプション２が正解となります。

Route53を利用したDR環境の方式としては主に以下の２つが考えられます。

■コールドスタンバイ

Amazon S3をバックアップデータの格納先として利用します。

事前にシステムイメージをクラウド上に準備します。

災害発生時にクラウド上のシステムを起動し、Route53で切り替えることで復旧します。

投資コストを抑えられ、手軽に始めることがで

 

■ウォームスタンバイ

クラウドのスタンバイ環境にデータを常時レプリケーションします。

通常は、スタンバイ環境を最少構成で稼働させ、災害発生時は必要なキャパシティに変更します。

スタンバイ環境の運用が常時必要になりますが、Route53でシステム切り替えを素早く実行することができます

 

自動でトラフィックが別インスタンスに切り替えられましたが、その処理は停止してしまいました。IPアドレスが変更されてしまうことが原因のようです。

EC２インスタンスにELBやRoute53を構成していると、特定のEC2インスタンスに障害が発生した際に、ダウンタイムを最小にして待機系インスタンスに切り替えます。その際にホスト名を待機系のIPアドレスに向け直すと、DNS情報が伝播するまでに一定のダウンタイムが発生する可能性があります。

これを防止するためには、フローティングIPを利用してElastic IPアドレスをフローティングすることで即時に別のEC2インスタンスへとトラフィックを切り替えることができます。障害発生時には稼動系からElastic IPアドレスを外し、待機系インスタンスに割り当て直すことで瞬時にトラフィックの向け先を変更できます。

 

Auto Scalingを設定して高負荷処理への対応を出来るようにしました。しかしながら、ELBのヘルスチェックが異常を示しているにも関わらず、Auto ScalingによるEC2インスタンスの起動が実行されていません。

Auto Scalingは起動したインスタンスに対して、定期的なヘルスチェックを実行します。このへルスチェックにはEC2タイプとELBタイプの2つのタイプがあります。

EC2タイプでは、EC2のステータスがrunning以外の場合、またはシステムステータスがimpairedの場合に、このインスタンスを異常と判断します。

ELBタイプでは、インスタンスのステータスチェックとELBのヘルスチェックからインスタンスの状態を判断します。

したがって、Auto ScalingがEC2タイプのヘルスチェックを利用していると、ELBのヘルスチェックが異常を示しているにも関わらず、EC2インスタンス側のステータスの問題がなければAuto Scalingが実行されません。

 

現在、あなたはデータ取得機能を実装しています。Lambda関数を利用したデータ取得処理機能を実装して、HTMLからアクセスして利用する予定です。

このシナリオでは、Lambda関数を利用したデータ取得処理機能を実装して、Amazon API GatewayとLambda関数を統合することで、Lambda関数をHTMLからアクセスして利用することが求められています。

API Gateway は完全マネージド型サービスでAPI の作成、配布、保守、監視、保護が可能なサービスです。AWS Lambda で実行されるコードからデータ、ビジネスロジック、機能にアクセスするための「玄関」として機能する REST API および WebSocket API を作成できます。HTMLに直接書き込んでコードを呼び出すことも可能です。

 

コンテナを実行する仮想マシンのクラスターをプロビジョニングやスケールなどの設定が不要な方式をとりたいと考えています。

以前は、Amazon EKSとFargateの組合せは利用できませんでしたが、2019年12月より、AWS Fargate の上でKubernetesを利用できるようになりました。Amazon EKS と Fargateはインスタンスのプロビジョニング設定などを自動で構成してくれるため、AWS 上での Kubernetes ベースのアプリケーション開発やその管理を一定程度自動化してくれます。したがって、ECSとFargateの組合せよりも Kubernetesを利用することで、より自動化を達成することが可能です。

Fargate はコンテナを実行するために仮想マシンのクラスターをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、クラスターをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。

 

Step Functions サーバーレスのオーケストレーションサービスであり、 AWSリソースと組み合わせたワークフローを作成するサービスです。人間による操作を必要とするような長時間実行される、半自動化されたワークフローを作成することもできます。したがって、このワークフローに手動アクションを必要とするいくつかのタスクが存在する可能性があるためであり、手動アクションが処理されなければタスクは停滞することになります。

 

Route 53 ネームサーバーにALBを指定するために、Aliasターゲットの IP アドレスを伴う A レコード (IPv4 アドレスの場合) または AAAA レコード (IPv6 アドレスの場合) を設定します。したがって、オプション１と２が正解となります。

 

RDSはMyISAMはMySQLのストレージエンジンとして使用することはできません。 MySQLにおいて、推奨されるストレージエンジンはInnoDBです。ストレージエンジンとは、さまざまなテーブル型に対する SQL 操作を処理する MySQL コンポーネントです

 

Amazon EC2 でインスタンスを設定時にユーザーデータを設定することで、インスタンス起動時にスクリプトを実行できます。AWSではシェルスクリプトと cloud-init ディレクティブという2 つのタイプのユーザーデータを Amazon EC2 に渡すことができます。また、このデータはプレーンテキスト、ファイルまたは base64 でエンコードされたテキスト (API コールの場合) として、起動ウィザードに渡すこともできます。

 

SNSはマイクロサービスなどの分離を可能にする、高可用性で、耐久性に優れたセキュアな完全マネージド型 pub/sub メッセージングサービスです。プッシュ型の連携処理や通知機能の実装に利用します。

SNSはアプリケーションやコンポーネント間でのメッセージの送信と受信を繰り返す仕組みとして利用できます。SNSは pub-sub に対応しており、SNSトピックにメッセージを送信(publish)すると、トピックを購読(subscribe)しているsubscriberにメッセージが一斉配信されます。

SQSはポーリング処理を実施する際に利用されるものであり、並列処理などの分散処理時に利用するべきもので、イベントに連動したメッセージ通知にはSNSを利用することなります。

 

ユーザーの一時的なアクセスにはAWS STSを利用して権限を付与する仕組みを利用します。

ウェブ ID フェデレーションを使用することで、カスタムのサインインコードを作成したり、独自のユーザー ID を管理したりする必要がなくなります。その代わりに、アプリのユーザーはGoogleなどの外部 ID プロバイダーを使用してサインインすることができます。認証トークンを受け取ったら、そのトークンを AWS アカウントのリソースを使用するためのアクセス許可を持つ IAM ロールにマッピングし、AWS の一時的セキュリティ認証情報に変換することができます。IdP を使用すると、アプリケーションで長期的なセキュリティ認証情報を埋め込んで配布する必要がないため、AWS アカウントの安全性の維持に役立ちます。

 

DynamoDBへのデータ登録後、自動でLambda関数を起動してメタデータを登録することが望ましい構成です。そのためには、DynamoDBストリームという仕組みを使うことで、DynamoDBテーブルへのデータ登録をトリガーにしてLambda関数を起動することができます。また、Lambda関数は最大512MBまでのデータ容量を扱うことができます。したがって、オプション１が正解となります。

 

VPCにCIDRブロックを追加する際には以下の規則が適用されます。

 

– 許容ブロックサイズは、「/ 28」サブネットマスクから「/ 16」のサブネットマスクまでです。

– CIDRブロックは、VPCに関連付けられている既存のCIDRブロックと重複してはいけません。

 

したがって、/ 28から/ 16までの範囲内にある168.0.0.0/27のみが正解となります。

 

AWS SAMは、サーバーレスアプリケーション構築用のデプロイツールです。YAMLを使用して、サーバレスアプリケーションのLambda関数、API、データベース、イベントソースマッピングをモデリングします。AWS SAMはCloudFormationと連携してサーバレスアプリケーションを展開します。その際は、SAM が SAM 構文を AWS CloudFormation 構文に変換および拡張することで、サーバーレスアプリケーションの構築を高速化することができます。

AWS Database Migration Service を使用すると、オンプレミスにあるデータベースを短期間で安全に AWS に移行できます。今回の要件には利用できません。

オプション２は間違いです。AWS Server Migration Service は、オンプレミスの VMware vSphere、Microsoft Hyper-V/SCVMM、または Azure 仮想マシンの AWSに移行するツールです。今回の要件には利用できません。

オプション４は間違いです。Amazon SWF はステップまたは連続したステップがあるバックグラウンドジョブを構築、実行、スケールすることができるクラウド内の完全マネージド型の状態トラッカーおよびワークフローシステムです。今回の要件には利用できません。

 

EBSのスナップショットはEBSの利用状況に関係なく、非同期に作成することができます。したがって、オプション１の「EBSボリュームを通常通りに利用することができる。」が正しい答えになります。

ポイントインタイムスナップショットはすぐに作成されますが、スナップショットのステータスはスナップショットが完了するまで保留中になり、最初のスナップショット作成には実行完了まで数時間かかることがあります。進行中のスナップショットはボリュームへの進行中の読み書きによって影響されません。それ故に、スナップショットの取得最中であっても、EBSボリュームを使用することができます。

 

EC2インスタンスから Amazon EBS ボリュームをデタッチするには、明示的にデタッチする必要があります。ルートボリュームの場合は、デフォルト設定ではインスタンスの削除されると同時にボリュームが削除されてしまいます。

また、インスタンスが実行中の場合、先にインスタンスからボリュームをアンマウントする必要があります。 EBS ボリュームがインスタンスのルートデバイスである場合、ボリュームをデタッチする前に、インスタンスを停止することが求められます。したがって、古いEC2インスタンスを停止した上で、ボリュームをデタッチします。

 

AWS IoT Core は、インターネットに接続されたデバイスから、クラウドアプリケーションやその他のデバイスに簡単かつ安全に通信するためのマネージド型クラウドサービスです。AWS IoT Coreを利用してセンサーデバイスを利用した車両管理アプリケーションを容易に構築することが可能となります。

AWS IoT Core は数十億個のデバイスと数兆件のメッセージをサポートしており、それらのメッセージを AWS エンドポイントや他のデバイスに確実かつセキュアに処理してルーティングします。AWS IoT Core を使用すれば、アプリケーションがインターネットに接続されていない場合でも、すべてのデバイスを常に追跡して通信できます。

 

AutoScaling のDesired capacityのインスタンス数を増加させることで、一時的なリクエスト流入増加に備えて、現在のインスタンス数を手動で増やすことができます。Desired capacityを設定することで、既存の Auto Scaling グループのサイズはいつでも手動で変更して、稼働するインスタンス数を増減させることができます。

 

AWSの責任共有モデルでは、AWSは次のようなセキュリティ管理するように責任があります。

 

– 設備

– ハードウェアの物理的セキュリティ

– ネットワークインフラ

– 仮想化インフラストラクチャ

 

ユーザー側は次のようなセキュリティ管理に責任が求められます。

 

-Amazon Machine Images（AMI）

– オペレーティングシステム

– アプリケーション

– 輸送中のデータ

– 保管時のデータ

– データストア

– 資格情報

– ポリシーと設定

 

このサーバーではメモリ内の大きいビッグデータデータセットをリアルタイムで処理するワークロードに対して高速なパフォーマンスを実現することが必要です。

このシナリオでは、メモリ最適化インスタンスの適切なタイプを選択することが求められています。メモリ最適化インスタンスは、メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスを実現するように設計されています。

オプション３が正解となります。R5 インスタンスはメモリバウンドのワークロードに最適なインスタンスタイプです。優れたネットワークスループットおよびパケット率パフォーマンスを活用できるアプリケーションにおいて理想的なインスタンスです。

このインスタンスは、高パフォーマンスデータベース、ウェブ規模の分散型インメモリキャッシュ、中規模インメモリデータベース、リアルタイムビッグデータ分析、その他のエンタープライズアプリケーションなどに利用します。したがって、ビッグデータデータセットをリアルタイムで処理するワークロードに最適なインスタンスです。

A1 インスタンスは汎用インスタンスの１つです。スケールアウト型の Arm ベースのワークロードに最適なインスタンスタイプであり、大幅なコスト削減を実現できます。ビッグデータ処理向けのインスタンスではありません。

オプション２は不正解です。T3 インスタンスは汎用インスタンスの１つです。ベースラインレベルの CPU パフォーマンスを提供する次世代のバースト可能な汎用インスタンスタイプで、いつでも必要な時間だけ CPU 使用率をバーストさせる機能を備えています。これもビッグデータ処理向けのインスタンスではありません。

オプション４は不正解です。M5 インスタンスは汎用インスタンスの１つです。このファミリーは、バランスの取れたコンピューティング、メモリ、およびネットワークのリソースを提供し、多くのアプリケーションに適しています。これもビッグデータ処理向けのインスタンスではありません。

 

サインインページの URL に AWS アカウント IDではなく任意の名称を設定する場合は、アカウントのエイリアスを作成します。IAMユーザーアカウントのサインインページにエイリアスを設定すると、サインインページURLのアカウント ID と置き換わります。管理者はAWS マネジメントコンソール、AWS CLI、または AWS API を使用して、アカウントエイリアスを作成および管理できます。サインインページのデフォルトの URL は以下の形式となっています。

 

https://Your_AWS_Account_ID.signin.aws.amazon.com/console/

 

AWS アカウント ID に AWS アカウントエイリアスを作成すると、サインインページの URL は次のようになります。

 

https://Your_Alias.signin.aws.amazon.com/console/

 

Snowball はセキュリティを考慮して設計されたデバイスを使用して、ペタバイト規模のデータ転送を可能にします。このデバイスを利用してAWS クラウド内外に大容量データを転送できます。Snowball を使用すると、高いネットワークコスト、長時間かかる転送、セキュリティ面の懸念といった、大規模なデータ転送に関する一般的な課題を解決できます。データを簡単、迅速、安全に転送でき、高速インターネットによるデータ転送と比較して、コストは5 分の 1 ほどで済みます。

Snowball Edge Compute Optimized は、機械学習、フルモーション動画分析、分析、ローカルコンピューティングスタックなどのユースケースに強力なコンピューティングリソースを提供します。このデバイスは、S3 互換オブジェクトストレージまたは EBS 互換ブロックボリューム用に 42 TB の使用可能な HDD 容量を提供します。

Snowball Edge Storage Optimized デバイスは、大規模なデータ移行と定期的な転送ワークフロー、およびさらに高容量を必要とするローカルコンピューティングに適しています。Snowball Edge Storage Optimized は、ブロックボリュームと Amazon S3 互換オブジェクトストレージに 100TB の HDD 容量を提供します。しかしながら、利用可能なボリュームは80TBほどです。

 

したがって、100TBのデータを移行するためには、Snowball Edge Storage Optimized が少なくとも2台必要であり、他の選択肢では容量が不足しています。オプション３が正解となります。

 

CloudFront はユーザーに近い位置にあるエッジロケーションにキャッシュを保持することで、高速のコンテンツ配信を実施します。通常、ビューワーに最も高速に配信できるCloudFront エッジサーバーがエッジ処理を実施します。

CloudFrontはユーザーが初めてアクセスする画像については、オリジンサーバーからデータを取得して、エッジロケーションにあるCloudFrontサーバーにキャッシュを保持します。

ユーザーから再度その画像にアクセスがあった場合は、キャッシュサーバーにあるキャッシュデータを活用してユーザーに近いエッジサーバーからコンテンツを配信します。したがって、「エッジロケーション側にキャッシュとして保存されている画像にアクセスする。」が正解となります。

 

自社のシステムがAWSクラウドで基盤となるリソースを適切に管理できるようになります。
Amazon EC2はアンマネージド型のサービスであり、多くの管理がユーザーに委ねられています。したがって、Amazon EC2インスタンスを使用すると、ユーザーは作成したインスタンスのオペレーティングシステムにアクセスできます。

オプション２が正解となります。Amazon EMRはマネージド型のHadoopフレームワークを提供します。 しかしながら、Amazon EMRはEC2インスタンスを利用して構成されるため、Amazon EMRを構成するEC2インスタンスのオペレーティングシステムなどに、ユーザーはアクセス可能となります。

CloudFormationは１つのスタックの出力値を別のスタックに提供することで、スタック間を連動させてインフラを構成することが可能になります。スタック間で情報を共有するにはスタックの出力値をエクスポートします。スタックの出力値をエクスポートするには、スタックのテンプレートの Output セクションの Export フィールドを使用します。したがって、オプション１が正解となります。

オプション２は不正解です。CloudFormation スタックに既存のリソースをインポートすることが可能です。これはエクスポートされた出力値を別スタック側が利用する際に使われます。

 

Amazon SES の E メール送信機能を組み込むことで、一般ユーザーに対するアプリケーションからのメール通知機能を実装することができます。Amazon SES は、クラウドベースのメール送信サービスでマーケティング、通知、トランザクションに関する E メールを送信できるように設計されています。

Amazon S3 によってバケットポリシーが評価され適用された後、バケットの暗号化が適用されます。バケット暗号化設定を有効にしていても、暗号化情報なしの PUT リクエストを拒否するバケットポリシーがある場合、該当PUT リクエストは拒否されてしまうため、S3への暗号化したデータ登録に失敗してしまいます。

AWS Certificate ManagerでSSL証明書を作って、ELBに設定することで、証明書の費用が実質無料で安全なサイトが用意できます。これにより、クライアントとELB間のデータ保護が実施されます。

オプション２が正解となります。ALBを利用してリスナー設定にHTTPS(443)の設定を追加して、SSL証明書をダウンロードすることで、SSL証明書を設定することが出来ます。

 

EC2インスタンスがAMIインスタンスの起動シーケンスを開始すると、コスト請求が開始されます。インスタンスを終了させればコスト請求が終了します。よって、実行中のEC2インスタンスにはコストを要します。

オプション３が正解となります。停止したインスタンスには1時間ごとの使用料やデータ転送料金は請求されませんが、アタッチされているAmazon EBSボリュームのストレージに対して請求が発生します

 

VPCエンドポイント（ゲートウェイ型）を利用することで、インターネットアクセスを通さずにAWSネットワークからのアクセスでDynamoDBと接続することができます。

VPC エンドポイントはPrivateLink を使用する AWS サービスや VPC エンドポイントサービスにVPC をプライベートに接続する機能です。その際にインターネットゲートウェイ、NAT 、VPN や AWS Direct Connect を介した接続やパブリック IP アドレスは必要ありません。VPC と他のサービス間のトラフィックは、Amazon ネットワーク内で完結するためインターネットを経由することはありません。VPC エンドポイントには 2 種類あります。プライベートリンク型（インターフェイスエンドポイント）とゲートウェイ型です。

 

■VPCエンドポイント（ゲートウェイ型）は、ルートテーブルの指定されたターゲットとなるゲートウェイです。サポートされる AWS のサービスを宛先とするトラフィックをVPC内外で接続する際に使用します。以下の AWS のサービスがサポートされています。

・Amazon S3
・DynamoDB

 

■VPCエンドポイント（プライベートリンク型）は対象サービスを宛先とするトラフィックのエントリポイントとなるプライベート IP アドレスを持つ Elastic Network Interface です。以下のサービスがサポートされています。

 

・Amazon API Gateway

・Amazon CloudWatch

・Amazon CloudWatch Events

・Amazon CloudWatch Logs

・AWS CodeBuild

・Amazon EC2 API

・Elastic Load Balancing API

・AWS Key Management Service

・Amazon Kinesis Data Streams

・Amazon SageMaker ランタイム

・AWS Secrets Manager

・AWS Service Catalog

・Amazon SNS

・AWS Systems Manager

・他の AWS アカウントによってホストされるエンドポイントサービス

・サポートされる AWS Marketplace パートナーサービス

 

Amazon DynamoDB からデータを読み込むとき、ユーザーはその読み込みに対して結果的に整合性のある読み込みを設定するか、強い整合性を設定するかを指定できます。結果整合性モデルを選択すると、読み込みスループットが最大限に向上します。ただし、結果整合性読み込みでは最新の書き込み結果が反映されない可能性があります。したがって、今回の場合も更新したデータが反映される前に読込をしてしまい陳腐化したデータが閲覧されたものと考えられます。解決策としては、結果整合性モデルを強い整合性モデルに変更することになります。

DynamoDB には結果整合性のある読み込みに加えて、強い整合性のある読み込みをリクエストする柔軟性と制御が用意されています。強い整合性のある読み込みの結果には、読み込みの前に適切な応答を受け取ったすべての書き込みが反映されています。

 

DynamoDBのDAXを有効化することでインメモリDBを利用した高速処理を実施することができるようになります。これは古いデータを読み取る可能性を抑止することはできません。

 

満たすべき要件は、データが欠落しないこと、耐久性があること、およびデータを到着順にストリーミングすることです。Kinesisがこうした要件に基づいたデータ転送を可能にします。 Kinesis Data Streamsは一連のデータレコードを持つシャードのセットであり、各データレコードにはKinesis Data Streamsによって割り当てられたシーケンス番号があるため、 メッセージが失われず、重複されず、到着と同じ順序で伝送することが可能です。

 

オプション１は不正解です。SQSのデフォルトキューは単なる標準キューであり、FIFO（先入れ先出し）キューではないため順番が保証されません。 さらに、SQSは重複送信されないことを保証しません。

 

今回の問題は発注管理システムが重複した注文処理をしてしまうことです。これは人的ミスで注文を二回してしまうことが原因です。つまり、SQS側は二回のメッセージを別個のメッセージとして処理しており、SQS上ではメッセージに重複は発生してません。したがって、この問題の発生を防ぐには、SQSではなくStep functionサービスを使用する必要があります。Step Functionにより発注フローを作成して、二重の発注が発生しないようにプロセスを形成します。Step functionは、開発者が並行または順次のステップを持つバックグラウンドジョブを構築、実行、およびスケーリングするのに役立ちます

 

複数値回答ルーティングにより、Amazon Route 53 が DNS クエリに対する応答として複数の値 (ウェブサーバーの IP アドレスなど) を返すように設定できます。複数値回答ルーティングは各リソースが正常かどうかも確認するため、Route 53 は正常なリソースに値のみを返すことができます。したがって、EC２インスタンス単位での正常・非正常を判断してルーティングすることができます。これはロードバランサーに置き換わるものではありませんが、Route53が設定したインスタンスのトラフィックが正常であることをヘルスチェックした上で複数の IP アドレスを返すことができ、DNS を使用してアベイラビリティーとロードバランシングを向上させることができます。

 

このシナリオでは、AWSとオンプレミスの両方の環境にあるリソースから構成されるアプリケーションのために、分散アーキテクチャを構築することが求められており、両方の環境に適用可能なAWSサービスを選択することが必要となります。

分散アーキテクチャーはコンポーネントまたはレイヤーを相互に接続しながら独立して実行できるようにするコンピューティングアーキテクチャーの一種です。AWSサービスの中でSQSおよびAWS Step Functionsは、AWSで分散アーキテクチャを作成するために使用できるサービスです。 したがって、オプション１と２が正解となります。

Amazon SQSはアプリケーション間またはマイクロサービス間でのメッセージ通信を実現する信頼性が高く、スケーラビリティの高いホスト型キューを提供します。 Amazon SQSを使用すると、分散アプリケーションコンポーネント間でデータを移動したり、これらのコンポーネントを分離したりできます。

AWS Step Functionsは分散アプリケーションコンポーネント間での作業の調整を容易にするWebサービスです。

 

Amazon S3 バケットから配信するコンテンツへのアクセスを制限するには、CloudFrontの 署名付き URL または署名付き Cookie を作成してオブジェクトURLの閲覧権限を特定ユーザーに限定します。また、オリジンアクセスアイデンティティ (OAI) という特別な CloudFront ユーザーを作成してS3バケットへの直接的なアクセスを制限します。これにより、ユーザーは S3 バケットへの直接 URL を使用してファイルにアクセスすることはできなくなり、CloudFront を通じて提供するファイルへの安全なアクセスを維持することが可能となります。 したがって、オプション４が正解となります。

 

静的ウェブサイトをホストするにはAmazon S3バケットを設定し、ウェブサイトのコンテンツをバケットにアップロードします。こうすることてS3バケット内のHTMLファイルをベースにWEBサイトを公開することが可能です。

このWebサイトはバケットのAWSリージョン固有のWebサイトエンドポイントで利用できます。その際に、Pintorバスケットを利用すると以下のようなURLとなります。

 

pintor.s3-website-ap-northeast-1.amazonaws.com

 

ユーザーがAmazon API からのAPIリクエストを通じてサービスを呼び出した場合に、AWS X-Rayを使用してユーザーリクエストを追跡および分析できます。 API Gatewayは、すべてのAPI Gatewayエンドポイントタイプ（地域、エッジ最適化、プライベート）のAWS X-Rayトレースをサポートしています。そのため、 X-Rayが利用可能なすべてのリージョンにおいて、Amazon API GatewayにAWS X-Rayを使用してトレースデータを収集することが可能です

 

CloudWatchログにはアプリケーションのログ情報は取得されないため、これは不正解となります。アプリケーションのログ情報はX-rayをエージェントとして組み込んで有効化することで可能となります。X-Ray SDK for Java を使用して、収集した X-Ray セグメントからサンプリングされていない Amazon CloudWatch メトリクスを発行できます。

オプション４は不正解です。CloudTrailはユーザーとAPIのアクティビティログを取得する際に利用する機能です。AWS X-Ray は AWS CloudTrail と統合して、ユーザー、ロール、または AWS のサービスによって X-Ray で行われた API アクションを記録します。しかしながら、今回の要件にあるアプリケーションに設定するログ取得ではありません。

 

EBSは用途に応じてボリュームサイズやボリュームタイプを変更することができることが利点の一つです。

オプション２が正解となります。単一のEC2インスタンスのEBSボリュームは、インスタンス用のシステムドライブやデータベースアプリケーション用のストレージなどの頻繁に更新が必要なデータのプライマリストレージとして使用できます。また、継続的なディスクスキャンを実行するスループット重視のアプリケーションにも使用できます。 これらのEBSボリュームはEC2インスタンスの稼働期間とは無関係に維持されます。

 

オプション３は不正解です。アベイラビリティーゾーンでEBSボリュームを作成すると、そのゾーン内でのみ自動的に複製が生成されますが、別のAWSリージョンには複製されません。

オプション４は不正解です。EBSボリュームは同じアベイラビリティーゾーン内のEC2インスタンスにしかアタッチできないため、正しくありません。

 

RDSユーザーやEC２インスタンスへのアクセスを実施するEC２インスタンスなどはIAM ユーザーまたはIAMロールの認証情報と認証トークンを使用して、RDS DB インスタンスまたはクラスターに接続することができます。これはRDSインスタンスの作成時に「Enable IAM DB Authentication(IAMのDB認証を有効化することで利用できます。したがって、オプション１が正解となります。

 

オプション２は不正解です。暗号化を実施することとアクセス許可は無関係です。

オプション３は不正解です。セキュリティグループのトラフィック許可もアクセス可否において必要となりますが、これは認証情報を利用したアクセスとは異なるため、今回の要件には合致しません。

オプション４は不正解です。ネットワークACLがDBインスタンスがあるサブネットへのアクセスを許可している必要はありますが、これは認証情報を利用したアクセスとは異なるため、今回の要件には合致しません。

 

AWS Organizationsは、複数のAWSアカウントに対してポリシーを設定してアクセス権限を管理します。 AWS Organizationsでは複数アカウントをまとめたグループを作成し、アカウント作成を自動化し、それらのグループにサービスコントロールポリシー（SCP）を適用することが可能です。

AWS Organizationsを使用することで、カスタムスクリプトや手動プロセスを必要とせずに、複数のアカウントにわたってポリシーを集中管理できます。 これにより、複数のAWSアカウントにわたってAWSサービスの使用を一元的に制御するサービスコントロールポリシー（SCP）を作成できます。

IAMグループでは複数アカウントの管理はできません。

オプション２は不正解です。IAMインラインポリシーは実際のユーザー管理への利用は最適ではありません。

オプション４は不正解です。AWS Systems ManagerはAWSリソースの運用管理に利用する統合管理ツールです。ユーザー管理には利用されません。

ホストサーバーのOSなどに直接アクセスする必要がある特殊なワークロードを起動することになります

ベアメタルインスタンスを利用することで通常のクラウドサーバーでは不可能な、ホストコンピューターのOSなどにアクセスが可能とります。これにより、ベアメタルはユーザーは詳細なパフォーマンス分析ツールを利用するアプリケーションや、ベアメタルのインフラストラクチャへの直接アクセスを必要とする特殊なワークロード、仮想環境ではサポートされないレガシーのワークロード、そしてライセンス制限のあるティア1のビジネスクリティカルなアプリケーションを動かすことができます。したがって、オプション１が正解となります。

 

オプション２は不正解です。Dedicated Hostは物理的にサーバーを占有するインスタンスタイプです。Dedicated Hosts では、ライセンス条項の範囲で、ソケット単位、コア単位、または VM ソフトウェア単位の既存のライセンスを利用できます。同じAWSアカウントに属していたとしても、別のIAMグループとは物理サーバーを共有しません。

 

複数のAWSサービスをサーバーレスワークフローによって調整する対応を行っています。

AWS Step Functions を利用することで要件を達成できます。AWS Step FunctionsはAWS の複数のサービスをサーバーレスワークフローに整理して、プロセス処理を実行するアプリケーションを構築できます。ワークフローは一連のステップで構成され、あるステップの出力が次のステップへの入力になります。Step Functions は各ステップが自動的にトリガーおよび追跡され、エラーが発生した場合は再試行されるため、アプリケーションが意図したとおりの順序で実行されます。

Amazon SWF もAWS Step Functions と同じようにワークフローなどのプロセスを作成することができます。しかしながら、EC2インスタンスを利用したサーバーベースの機能であるためサーバーレスオーケストレーションを提供しません。

オプション３は不正解です。Lambdaはサーバーレスコンピューティングに使用されますが、複数のAWSサービスを利用したサーバーレスワークフローを構成することはできません。

オプション４は不正解です。AWS Batchは主にAWSで数十万のバッチコンピューティングジョブなどを効率的に実行するために使用されるため、正しくありません。

 

新規に作成したEBSボリュームをEC2インスタンスにアタッチ後にEB使用を開始するためは、そのボリュームにファイルシステムを作成することが必要です。したがって、オプション４が正解となります。

インスタンスにAmazon EBSボリュームをアタッチ後に任意のファイルシステムでボリュームをフォーマットしてからマウントすることが必要です。 EBSボリュームを使用可能にした後、他のボリュームにアクセスするのと同じ方法でEBSボリュームにアクセスできます。 このファイルシステムに書き込まれたデータはすべてEBSボリュームに書き込まれます。

管理を適切に実施するため、 IAMポリシー、タグ、RDS、API呼び出しなどの特定のAWSリソースを一意に指定して、リソース間の連携設定を実施することが必要です。
Amazonリソースネーム（ARN）によりAWSリソースを一意に識別します。 IAMポリシー、Amazon Relational Database Service（Amazon RDS）タグ、APIコールなど、AWS全体でリソースを明確に指定する必要がある際にはARNが必要です。ARNは以下のような形式で定義されています。
arn:partition:service:region:account-id:resource-id

 

CloudFormation スタックセットを利用するとCloudFormation テンプレート内に AWS リソースの設定を定義して、１つのテンプレートにより複数の AWS アカウントやリージョンにリソースを展開できます。クロスアカウントやクロスリージョンのシナリオを解決する AWS 機能のベースラインレベルのセットアップにこの機能を活用できます。一度セットアップしてしまえば、追加のアカウントやリージョンに対しても容易に展開することができます。

 

DynamoDBの特定のデータ領域にアクセス集中が発生し、DynamoDBへのセッションデータの登録処理が滞る事象が発生するようになりました。最も高速な処理を達成するための対応が求められています。
DynamoDB Accelerator(DAX) を有効化することで、1 秒あたりのリクエスト数が数百万件になる処理に対しても、ミリセカンドからマイクロセカンドへの最大 10 倍のパフォーマンス向上を実現します。今回のケースでは特定のデータへのアクセスが集中しているため、そのデータがキャッシュに保持されてアクセスがキャッシュ上で行われれば、処理性能を大幅に向上させることができます。

 

Amazon FSx for Windows ファイルサーバーはAccess Control Lists (ACLs)、シャドウコピー、ユーザークォータなど、Windows ネイティブファイルシステムの機能をサポートしているストレージタイプです。他のストレージタイプにはない機能であるため、Amazon FSxのみが正解となります。

 

RedshiftのWLM(Work Load Management)を利用することで、クエリ処理を実施する際に、クエリ処理をキューとして実行順序を定義することが可能です。WLMはRedshiftのクエリ処理に対して割り当てるRedshiftのリソースを指定する機能です。事前にWLMとしてキューを用意しておき、キューに対して割り当てるメモリの割合や並列度、タイムアウトの時間を指定することでクエリに対するリソース配分を決定したり、長時間実行されるクエリを止めてクラスタリソースを無駄遣いしないようにすることができます。したがって、オプション１が正解となります。

 

ランキングやレコメンデーションの実装に使う高性能なデータベースを探しています。
Amazon ElastiCacheは、クラウド内のインメモリデータストアまたはキャッシュのデプロイ、運用、および拡張を容易にするWebサービスです。 このサービスは、低速のディスクベースのデータベースに完全に依存するのではなく、高速の管理されたインメモリデータストアから情報を取得できるようにすることで、Webアプリケーションのパフォーマンスを向上させます。ランキングやレコメンデーションの実装に使うための便利な機能を有しており、本件のデータベースとして最適です。

 

このシナリオでは、バックエンドにハードコーディングされた静的IPアドレスを必要としているため、ELBではない方法でトラフィック分散などの高可用性とフォールトトレランスを適用する方法が求められています。

仮想のElastic IPアドレスを使用してEC2インスタンスに付与することが望ましいです。Elastic IPを使用してから、EC2インスタンスの状態をチェックするカスタムスクリプトを作成します。これにより、インスタンスが応答を停止した場合、スクリプトはElastic IPアドレスをスタンバイEC2インスタンスに切り替えることができます。これで、ELBを利用せずに高可用性とフォールトトレランスを適用することが可能となります。また、EC2インスタンスにElastic IPをインスタンスに適用して、プロキシサーバーを設置することで、外部システムとの連携時にIPアドレスを特定して連携することが可能となります。
ELBの利用が制限されているため、AutoScalingをそのまま適用することができません。まずはオプション１と２の対応が必要不可欠です。

このシナリオでは、AWSアカウントにデフォルトで「FullAWSAccess」が付与されている場合にどのように許可形式のSCPが機能するかが問われています。デフォルトで「FullAWSAccess」が付与されている場合は全てのリソースに対する全ての操作が明示的に許可されている状態となります。そこにホワイトリスト形式（特定の操作の許可を与えるポリシー）で特定のリソースに対する許可を与えても、「FullAWSAccess」が付与されているため、結局は全てのリソースに対する許可が継続します。
このように特定の権限範囲を付与するSCPを新規に設定したい場合は、そのSCPアタッチしたあとに「FullAWSAccess」をデタッチしなければ機能しません。したがって、オプション４が正解となります。

このケースでは「この場合のOU内のメンバーアカウントの権限状態」が問われています。メンバーアカウントはあくまでもAWSアカウントそのものですので、その権限範囲がSCPによって規定されることになります。しかしながら、IAMユーザーに操作権限を付与するためには、追加でIAMポリシーのEC2インスタンスの操作権限を付与することが必要です。

直接的にDDoS攻撃事態を回避する対策を実施する必要があります。
AWS Shieldはマネージド型のDDoS攻撃に対する保護サービスで、AWS で実行しているアプリケーションを保護します。直接的にDDoS攻撃を回避するにはWAFではなくAWS Sheildを設定することが優先されます。

オプション１は不正解です。AWS Firewall Manager は、ユーザーの複数のアカウントとアプリケーションにわたって一元的に AWS WAF ルールを設定、管理することを容易にするセキュリティ管理サービスです。

オプション２は不正解です。AWS WAF は、アプリケーションに対する一般的なウェブエクスプロイトからウェブアプリケーションを保護するウェブアプリケーションファイアウォールです。不正なアクセス処理に利用される点は一致しており、DDoS攻撃に直接対処するサービスではないため不正解です。

 

ネットワークアクセスコントロールリスト (ACL) は、1 つ以上のサブネットのインバウンドトラフィックとアウトバウンドトラフィックを制御するファイアウォールとして動作する、VPC 用のセキュリティのオプションレイヤーです。セキュリティの追加レイヤーを VPC に追加するには、セキュリティグループと同様のルールを指定したネットワーク ACL をセットアップできます。

ネットワークACLルールは低い値から高い値にかけて評価され、一致する許可/拒否ルールが設定されるとすぐに実行されます。したがって、オプション4が正解となります。

 

アベイラビリティーゾーンはデータセンターの集まりであり、リージョン内で物理的に区分され独立しています。 発電機や冷却装置などの一般的な障害ポイントとなる設備は可用性ゾーン間で共有されません。 AZは物理的に分離されているため、火災、竜巻、洪水などの極端な災害は単一のアベイラビリティーゾーンのみに影響します。

一方で、エッジロケーションは低レイテンシーを達成するためのキャッシュコンテンツを配信するための地理的ロケーションとなります。これはリージョンやAZとは独立して配置されています。CloudFrontはエッジロケーションを使用して、キャッシュされたコンテンツを最も近いロケーションに配信し、待ち時間を短縮します。 エッジロケーションと呼ばれるデータセンターのグローバルネットワークを通じてコンテンツを配信します。

 

Amazon S3では、データを別の分析システムに移動することなく、直接にS3データに対して高度なビッグデータ分析を実行できます。S3に保存されているデータを直接解析することができる機能／サービスは以下の３つです。

 

■Amazon S3 Selectは、Amazon S3バケット内のオブジェクト内のデータをより迅速かつ安価に分析および処理できるように設計されています。単純なSQL式を使用してAmazon S3のオブジェクトからデータのサブセットを取得する機能を提供することで機能します。しかしながら、これは簡単なデータ検索や抽出に利用される機能であるため、本件の高度なビッグデータ分析には利用できません。したがって、オプション３は不正解です。

■Amazon Athenaは標準のSQL式を使用してAmazon S3のデータを簡単に分析できるインタラクティブなクエリサービスです。Amazon S3のデータをポイントし、スキーマを定義し、標準のSQL式を使用してクエリを開始するだけです。ほとんどの結果は数秒以内に配信されます。したがって、オプション4が正解となります。

■Amazon RedshiftにはRedshift Spectrumも含まれており、Amazon S3のエクサバイトの非構造化データに対してSQLクエリを直接実行できます。取得されるデータに基づいてクエリの計算能力を自動的にスケーリングするため、データセットのサイズに関係なく、Amazon S3に対するクエリは高速に実行されます。したがって、オプション5が正解となります。

 

最初の数週間でトラフィックが非常に多くなる可能性があります。よって、ロードエラーが発生した場合、Webアプリケーションへのフェイルオーバーを設定する必要があります。
Route53のフェイルオーバールーティングを利用することで、ロードエラーが発生した場合に静的WebサイトへのDNSフェイルオーバーを実施できます。

オプション３が正解となります。CloudFrontディストリビューションではフェールオーバーオプションが提供されています。CloudFrontへのフェールオーバーは従来は Route 53 の DNS フェイルオーバー を利用して実装することが必要でした。しかしながら、CloudFront 側でフェイルオーバのコントロールが出来るようになりました。CloudFrontフェールオーバーオプションはサイト単位でのフェイルオーバではなく、オブジェクト単位でのフェイルオーバになります。

 

 

Amazon CloudFrontの料金はAWSからのデータ転送と、顧客へのコンテンツ配信に使用されるリクエストによって算出されます。前払いや固定プラットフォーム料金、長期契約、ダイナミックコンテンツのプレミアムなどの要件はありません。具体的にはAmazon CloudFrontのコストは以下の要素に基づいています。

 

-トラフィックの分散：データ転送とリクエストの価格はリージョンによって異なり、価格はコンテンツが配信されるエッジの場所によっても異なる

-リクエスト：リクエスト（HTTPまたはHTTPS）の数と種類、およびリクエストが行われた地域。

-データ転送アウト：Amazon CloudFrontエッジロケーションから転送されたデータの量

 

AWSサービスの中には1年~3年などの一定期間利用を予約することを前提に割引価格で購入可能になるオプションがあります。主なリザーブド購入オプションは以下のようなものがあります。

 

・EC2リザーブドインスタンス

・RDSリザーブドインスタンス

・ElastiCacheリザーブドノード

・DynamoDBリザーブドキャパシティ

・Redshiftリザーブドノード

 

Amazon EMR は大規模環境で大量のデータを迅速かつコスト効率よく処理できるビッグデータ処理用のプラットフォームです。Apache Spark、Apache Hive、Apache HBase、Apache Flink、Presto などのオープンソースのツールと、Amazon EC2 の動的なスケーラビリティおよび Amazon S3 によるスケーラブルなストレージを組み合わせて伸縮自在なデータ処理・分析エンジンを提供します。ペタバイト規模の分析が従来のオンプレミスクラスターと比べてわずかなコストで実行できます。主なユースケースは次の通りです。

 

・MACHINE LEARNING

・抽出、変換、読み込み (ETL)

・クリックストリーム分析

・リアルタイムストリーミング データ処理

・インタラクティブ分析

・ゲノミクス

オプション１が正解となります。この要件に沿ってワークロードをAWSに移行するためには、AWS Server Migration Service (SMS) を利用することが最適です。

SMSは数千のオンプレミスワークロードを従来よりも簡単に、かつ短時間で AWS に移行できるエージェントレスサービスです。AWS SMS では、ライブサーバーボリュームの増分レプリケーションの自動化、スケジュール設定、および追跡が可能なため、大規模なサーバーの移行作業を簡単に調整できます。

Snowballは大量データを移行する際に利用するサービス機器です。ワークロードをAWSに移行することはできません。

AWS Globel Accelerator は世界中の顧客に提供するアプリケーションの可用性とパフォーマンスを改善するネットワークサービスです。AWS 上のアプリケーションに対して固定エントリポイントとなる静的 IP アドレスを提供することで様々な AWS リージョン、アベイラビリティーゾーンの特定の IP アドレスの管理における複雑さを排除します。EC2 インスタンスを Global Accelerator に接続するには、Accelerator を作成し、EC2 インスタンス ID を使用するエンドポイントにEC2 インスタンスを追加するだけです。したがって、オプション１が正解となります。

 

デフォルトのポリシーを利用するとOldestLaunchConfigurationから実行されます。したがって、既存のEC2インスタンスから削除される可能性が高いです。

EC2で利用される一部のインスタンスタイプはインスタンスストアと呼ばれる直接接続されたブロックデバイスストレージを利用します。インスタンスストアのボリュームに格納されているデータは、インスタンスの停止、終了、またはハードウェアの障害によって永続化されないため、インスタンスストアは一時記憶に利用されます。したがって、オプション４が正解となります。

一方で、一時的ではないデータ保存の場合、またはデータを暗号化したい場合はEBSボリュームを使用することが必要です。EBSボリュームはインスタンスが停止してもデータを保持することができ、EBSスナップショットで容易にバックアップし、暗号化を実施することができます。

 

パブリックホストゾーンはインターネット上に公開されたDNSドメインレコードを管理するコンテナのことです。 ここにはexample.comなどのドメインのトラフィックをインターネットまたは特定のドメインでルーティングする情報を保持しています。したがって、オプション３と４はパブリックホストゾーンの特徴として正しい内容となります。

 

オプション１と２は不正解です。VPC同士が相互アクセス可能であればリージョンの異なるVPCでも、同じホストゾーンを利用可能なのはプライベートホストゾーンの説明です。プライベートサブネット内にあるドメインをルーティングするのもプライベートホストゾーンです。

 

セキュリティグループのルール設定として間違っている内容
上から番号順にルールが適用されるのはネットワークACLの特徴です。セキュリティグループは全てのルールを適用します。 したがって、オプション１が間違った説明となり、正解の選択肢です。

 

マルチパートアップロードを利用してアップロードできる個々のAmazon S3オブジェクトのサイズの範囲は最小0バイトから最大5テラバイトです。 1つのPUT操作でアップロードできる最大オブジェクトは5ギガバイトです。

 

AWS Managed Microsoft AD （ AWS Directory Service for Microsoft Active Directory）を利用して、AWS クラウド内にマネージド型 Active Directory を設置できます。これを利用して AWS と既存のオンプレミス Microsoft Active Directory の間で信頼関係を設定し、シングルサインオン (SSO) を構成することも可能です。

オプション３が正解となります。AD Connector を使用して、既存のオンプレミスの Microsoft Active Directory と連携してSSOを実現できます。ADとロールに割り当てられた IAM ポリシーに基づいてユーザーの AWS サービスへのアクセスを制御します。

 

ALBの選択するべき理由
・L７に対応

・URLのパスに基いてルーティングが可能なパスベースルーティングが可能

・WebSocketとHTTP/2のリクエストが利用可能

・1インスタンスに複数ポートを登録可能

・EC2インスタンスをターゲットグループに割り当てる際、複数ポートを個別のターゲットとして登録することが可能なため、ポートを利用するコンテナをロードバランシング可能

・ターゲットグループでのヘルスチェックが可能

・アクセスログが取得できる

・EC2と同様に削除保護が可能

・ALB自体が自動的にキャパシティを増減する

 

AWSリソースのタグ付け戦略のベストプラクティスは以下の通りです。

 

・タグには常に標準化された大文字と小文字を区別する形式を使用し、全リソースタイプにわたって一貫して利用します。

・リソースアクセス制御、コスト追跡、自動化、および組織の管理機能をサポートするためのタグディメンションを検討します。

・リソースタグの管理に役立つ自動化ツールを実装します。 Resource Groups Tagging APIはプログラムによるタグの制御を実施し、タグとリソースの自動管理、検索、フィルタリングが簡単になります。

・AWSリージョンごとに1つのAPIコールを使用することで、サポートされているすべてのサービスのタグデータのバックアップを簡素化します。

・タグを多く使いすぎてはいけません。

・ビジネス要件の変化に対応するためにタグを変更する際は、タグベースのアクセス制御、自動化、またはアップストリーム請求レポートに関連する影響を考慮してください。

 

Amazon VPCにはリモートの顧客ネットワークとVPCの間にIPsec VPN接続を作成するオプションがあります。AWS managed VPNを利用することで、オンプレミス環境とVPC間とのサイト間接続を実行することができます。したがって、オプション１が正解となります。
Direct Connectは専用線接続サービスとして、AWS側とオンプレミス環境とを接続することが可能ですが、VPCによる接続方法ではないため、要件に合致していません。

 

データセンターにある１エクサバイトのデータをAWSに移行するプロジェクトを実施することになりました。
AWS Snowmobile は超大容量データを AWS に移動するために使用できるエクサバイト規模のデータ転送サービスです。これはセミトレーラートラックが牽引する長さ 14 m の丈夫な輸送コンテナで、Snowmobile 1 台あたり 100 PB まで転送できます。エクサバイトサイズのデータを移行する際に利用します。Snowmobile を使うと、ビデオライブラリや画像リポジトリ、またはデータセンター全体まで、膨大な量のデータを簡単にクラウドに移動できます。したがって、オプション２が正解となります。

AWS Snowball Edge はデータ移行とエッジコンピューティングのデバイスです。統合されたストレージとコンピューティング機能を備えた 100 TB のデータ転送デバイスです。主にペタバイト規模のデータの移動に使用できます。エクサバイト規模のデータ転送には役割不足です。

SSLサーバー証明書を管理するにはどのAWSサービスを利用する必要性がありますか？ （2つ選択してください。）
AWS Certificate Manager（ACM）はSSL証明書を作成したり、外部プロバイダーから取得した証明書をインポートして管理するサービスです。

オプション２が正解となります。ACMでサポートされていないリージョンでは、HTTPS接続をサポートする必要がある場合は、IAMをSSL証明書マネージャーとして使用します。 IAMはすべてのリージョンでのSSL証明書のデプロイをサポートしていますが、AWSで使用するには外部プロバイダーからSSL証明書を取得する必要があります。

 

移行計画を立案するためにはサーバーの使用率データや依存関係のマッピングなどを実施する必要があります。
AWS Application Discovery Service は、オンプレミスデータセンター内のサーバーにエージェントをインストールすることで、データセンターの利用情報を収集することができるサービスです。これらの情報に基づいて、ユーザーの移行プロジェクト計画作成を支援します。 したがって、オプション３が正解となります。

データセンター移行計画には何千ものワークロードが存在し、多くの場合それらが相互に深く依存しあっています。サーバーの使用率データや依存関係のマッピングは、移行プロセス初期の重要なステップです。AWS Application Discovery Service は、サーバーの設定データ、使用状況データ、動作データなどを収集できます。 収集されたデータは、AWS Application Discovery Service のデータストアに暗号化形式で保存されます。このデータを CSV ファイルとしてエクスポートし、AWS で稼働した場合の総所有コスト (TCO) の見積もりや、AWS への移行計画に使用できます。検出したサーバーを AWS に移行し、AWS に移行する際の進捗を追跡できます。

AWS Server Migration Service (SMS) は、数千のオンプレミスワークロードを従来よりも簡単に、かつ短時間で AWS に移行できるエージェントレスサービスです。AWS SMS では、ライブサーバーボリュームの増分レプリケーションの自動化、スケジュール設定、および追跡が可能なため、大規模なサーバーの移行作業を簡単に調整できます。

AWS Database Migration Service を使用すると、データベースを短期間で安全に AWS に移行できます。移行中でもソースデータベースは完全に利用可能な状態に保たれ、データベースを利用するアプリケーションのダウンタイムを最小限に抑えられます。

 

Amazon EMR の中心的なコンポーネントはクラスターです。クラスターはEC2インスタンスのコレクションのことです。クラスター内の各インスタンスはノードと呼ばれます。各ノードはクラスター内での役割があり、ノードタイプと呼ばれます。Amazon EMR は各ノードタイプにさまざまなソフトウェアコンポーネントもインストールし、Apache Hadoop などの分散型アプリケーションでの役割を各ノードに付与します。 そして、クラスターにノードをセットアップする際にEC2 インスタンスのオンデマンドインスタンス、スポットインスタンス、またはリザーブドインスタンスを利用可能です。
Amazon EMR 内のスポットインスタンスは、オンデマンドの購入と比較して、低コストで Amazon EC2 インスタンス容量を購入できるオプションを提供します。Amazon EMRのクラスターに対して、スポットインスタンスを利用することで、オンデマンドと比較してコストを抑えることができます。このEMRの処理は短期間に頻繁に発生しますが、クラスター構成自体は一時的に利用することになります。したがって、スポットインスタンスを利用可能なケースです。

処理中に全てのインスタンスが90%のCPU使用率に達して、処理能力が急激に低下してしまいました。しかしながら、Auto ScalingグループはグループにEC2インスタンスを追加することはありませんでした。
この問題の最も可能性の高い原因
Auto Scalingのクールダウン期間では、 Auto Scaling グループが追加のインスタンスを起動または削除することが一定期間できなくなります。この期間はインスタンスのウォームアップ期間やその他のアプリケーションのニーズに基づいて設定できます。したがって、オプション４が正解となります。Auto Scalingグループは、単純なスケーリングポリシーを使用して動的にスケーリングした後、スケーリングアクティビティを再開する前にクールダウン期間が完了するのを待ちます。

Auto Scalingグループの最大サイズを5つと設定している場合は、既に5つのEC2インスタンスが起動しているため、新規インスタンスを起動することはできません。したがって、オプション１が正解となります。

２０１９年９月までリージョン内で実行できるオンデマンドインスタンス数の上限は、すべてのインスタンスファミリーを合わせて 20 個に制限されていましたが、2019年9月24日から、Amazon EC2 で vCPU ベースのオンデマンドインスタンス制限が適用されるようになりました。したがって、オプション６ではなく、５が正解となります。

 

Amazon QuickSight は、クラウド型のBIツールを提供する可視化ツールです。QuickSight はML Insights を含むインタラクティブなダッシュボードを簡単に作成して公開できます。ダッシュボードはあらゆるデバイスからアクセス可能で、アプリケーション、ポータル、ウェブサイトに埋め込むことができます。

Amazon QuickSightは機械学習（ML）と自然言語機能を活用してデータからより深い洞察を得るのに役立つML Insights機能があります。これらのすぐに使える強力な機能により、誰もが隠れた傾向や外れ値を発見し、主要なビジネスドライバーを特定し、技術的な専門知識やMLの経験を必要とせずに強力なwhat-if分析と予測を実行できます。

 

Glacier Deep Archiveは大量のデータ向けの長期ストレージをAWSの中で最も低価格で提供しています。データは 3 つ以上の AWS アベイラビリティゾーンにまたがって保存され、12 時間以内に取りだすことができます。

 

セキュリティ上の理由により、Redshiftクラスター間のすべてのトラフィックがインターネットを通過しないようにする必要があります。
Amazon Redshiftの拡張VPC ルーティングを使用すると、Amazon Redshift はクラスターとデータリポジトリ間のすべての COPY と UNLOAD トラフィックが Amazon VPC を通るよう強制します。これにより、VPC セキュリティグループ、ネットワークアクセスコントロールリスト (ACL)、VPC エンドポイント、VPC エンドポイントポリシー、インターネットゲートウェイ、ドメインネームシステム (DNS) サーバーなどのVPCの 機能をRedshiftで使用することができます。 これらの機能を使用して、Amazon Redshift クラスターと他のリソースの間のデータフローを詳細に管理できるようになり、VPC フローログを使って COPY と UNLOAD トラフィックを監視することができます。

 

CloudFrontを使用してホストされているWEB配信サービスを展開しています。ITセキュリティ部門はこのWeb配信を使用するアプリケーションのPCIコンプライアンスへの対応状況を監査しています。
WS責任共有モデルに基づいてPCIまたはHIPAA準拠のワークロードを実行している場合、監査のためには過去365日間のCloudFront使用状況データを記録することが重要です。使用状況データを記録するためにCloudFrontアクセスログを有効にして、CloudFront APIに送信されるリクエストをキャプチャできるようにする必要があります。したがって、オプション４と５が正解となります

 

Kinesis Data Firehoseを利用してS3にログを蓄積し、Athenaを利用してログ解析を行うことができます。そして、このデータ蓄積前に変換処理が必要となります。Kinesis Data FirehoseにLambda関数を設定して、データ変換を実施することが必要です。Amazon Kinesis Data Firehose では、データストアにロードする前にストリーミングデータを準備するよう設定できます。AWS マネジメントコンソールの Amazon Kinesis Data Firehose 配信ストリーム設定タブから、AWS Lambda 関数を選択します。この関数は、Amazon Kinesis Data Firehose で自動的にすべての入力データレコードに適用されます。

Amazon Kinesis Data Firehose はAWS マネジメントコンソールの Amazon Kinesis Data Firehose 配信ストリーム設定タブから、AWS Lambda 関数を選択します。つまりLambda関数と連携してデータ変換を実行します。

Amazon S3に静的ウェブサイトをホスティングできます。この静的ウェブサイトのルーティングをスケーリングするためにはRoute53と連携させることが必要です。Route53を利用してエイリアスレコードを作成してドメインのホストゾーンに追加し、pintor.com と www.pintor.com を対応する S3 バケットにマッピングします。エイリアスレコードでは、IP アドレスを使用する代わりに、Amazon S3 ウェブサイトエンドポイントを使用します。Amazon Route 53 によって、エイリアスレコードと、Amazon S3 バケットが存在する IP アドレスとのマッピングが維持されます。したがって、オプション１と２が正解となります。

S3というAWSサービスをドメイン設定するのはCNAMEレコードではなくエイリアスレコードにドメイン名を設定することが必要です。

 

EFSでは突然アクセスが増加するケースにはバーストスループットモードを選択します。バーストスループットモードではスループットがファイルシステムのサイズに合わせてスケールされ、ファイルベースの多数のワークロードの不規則な性質に対応するために、必要に応じて動的にバーストされます。これによって、EFSは一時的な高負荷に対応できるパフォーマンスを発揮することができます。

 

S3 の共有データセットへの大規模なデータアクセスの管理を簡素化するアクセス設定に S3 アクセスポイントを利用することが求められます。

Amazon S3 アクセスポイントは、S3 の共有データセットへの大規模なデータアクセスの管理を簡素化する機能です。アクセスポイントは、バケットにアタッチされた名前付きのネットワークエンドポイントで、S3 オブジェクトのオペレーション (GetObject や PutObject など) を実行するために使用できます。各アクセスポイントは基になるバケットにアタッチされたバケットポリシーと連動して機能するカスタマイズされたアクセスポイントポリシーを適用してアクセスを制御することが可能です。

Amazon S3 Transfer Acceleration を使用すると、クライアントと S3 バケットの間で長距離にわたるファイル転送を高速、簡単、安全に行えるようになります。

このバックアップ処理を効率的に集中管理する対応を行っています。AWS アカウントとリソース全体のバックアップアクティビティを設定および管理することが必要です。
AWS Backup はAWS Storage Gateway を使用して、オンプレミスおよび AWS サービス全体のデータのバックアップの一元化と自動化を簡単に実行できる、完全マネージド型のバックアップサービスです。バックアップポリシーを一元的に設定し、Amazon EBS ボリューム、Amazon RDS データベース、Amazon DynamoDB テーブル、Amazon EFS ファイルシステム、AWS Storage Gateway ボリュームなどの AWS リソースのバックアップアクティビティを監視できます。

Amazon DLMは、AmazonEBSボリュームとスナップショットの定期取得や管理を実施できます。しかしながら、これはのバックアップの一元管理を実施するサービスではないため正しくありません。

 

一部のWEB行動データは予測不能なアクセスパターンを持っており、蓄積方法が最適ではないことが判明しました。
保存するデータが予測不能なアクセスパターンを持っている場合は、S3 Intelligent-Tieringを利用することでストレージのコスト最適化を自動化することができます。 S3 Intelligent-Tieringには、高頻度と低頻度という2つのアクセス階層が組み込まれています。両階層はStandard(標準)ストレージクラスと同等の低レイテンシーを提供します。S3 Intelligent-Tiering はアクセスパターンをモニタリングして、連続30日間アクセスされていないデータを低頻度のアクセス階層に移動します。その後、そのデータがアクセスされた場合は、高頻度アクセス階層に自動的に戻されます。すなわち、アクセスパターンが変化するような状況でも、性能の影響なく利用料金を節約することができます。

データがあまりアクセスされないとほぼ確信している場合には、コスト節約の観点では、Standard-IA(標準-低頻度アクセス)の利用が最適となります。しかしながら、今回のようにアクセスパターンが予測できない場合や変わりうる場合、Intelligent-Teringが有効です。

 

RDSはファイルシステムとの連携がサポートされていないため、連携を実現するためにはEC2インスタンスにデータベースをインストールしてデータベースサーバーをカスタムで構築する必要があります。
RDSはPostgreSQL 11のサポートを開始しました。詳細は以下のページをご参照ください。

https://aws.amazon.com/jp/rds/postgresql/why-postgresql-11/

オプション２は不正解です。RDSでデータベースを構築しても特定のCRMと連携することは可能です。

オプション４は不正解です。RDSはEC2インスタンスとの連携やオンプレミスサーバーとの連携も構築可能です。

 

EBSボリュームの汎用SSDは同じAZ内のインスタンスにのみアタッチできます。別のAZのEBSにはアタッチできません。

アプリケーションの負荷テスト中に、AWS KMSリクエストが1秒あたりの制限を超えてしまい、エラーとなってしまいました。
暗号化のベストプラクティスに基づく最適な改善方法
AWS 暗号化 SDK は、言語固有の SDK とは別の暗号化専用のライブラリです。この暗号化ライブラリを使用すると、開発中のアプリケーションに対して暗号化のベストプラクティスによる暗号化の仕組みを簡単に実装できます。AWS 暗号化 SDKを利用することで、暗号化の制限を超過しないようなリクエスト処理の仕組みを構成して修正することで、現在のエラーを回避することが可能です。

 

IAMを使用してリソースのセキュリティを含む会社のクラウドインフラストラクチャのすべてを管理するように権限を割り当てました。
IAMを利用してセキュリティ上のベストプラクティスに沿うために、ユーザーの適切なアクセスレベルに応じたIAM 権限を設定することが必要です。そのため、AWS アカウントのセキュリティを向上させるには、IAM ポリシーを定期的に確認しモニタリングする必要があります。ポリシーにより、必要なアクションのみの実行に必要な最小限の権限が付与されていることを確認します。

 

スループットが最も早いEBSがアタッチされたEC2インスタンスに対して、MySQLソフトウェアをインストールしてデータベースとして利用しています。しかしながら、このデータベースの書き込みスループットが非常に遅いことがわかりました。
このシナリオでは、EC2インスタンスでホストされるデータベースの書き込みパフォーマンスを向上させることが求められています。Amazon EBS は標準的な RAID 設定はすべて使用できます。単一のボリュームで実現できる以上の I/O パフォーマンスを実現するため、RAID 0 では複数のボリュームをまとめてストライピング構成が実施できます。RAID０構成により、I/O がストライプ内のボリュームにわたって分散されます。ボリュームを追加すると、スループットと IOPS を追加したことになり、スループットを向上させます。

オプション５は正解となります。一部のEC2インスタンスタイプは、単一のEBSボリュームにプロビジョニングできるものよりも多くのI / Oスループットを駆動できます。EBSの RAID 0構成では複数のgp2、io1、st1、またはsc1ボリュームを結合して、これらのインスタンスで利用可能な帯域幅を使用できます。

AWS Lambdaは、DynamoDBから取得したデータに任意の集計をかける関数を開発することができます。これにより、特定期間の特定項目の集計を実施して、データを集計して抽出することが可能となります。

Amazon EMR は、オープンソースのフレームワークである Apache Spark と Hadoop を使用して、膨大な量のデータを迅速かつコスト効率よく処理して分析するサービスです。Amazon EMR および Hive を使用すると、DynamoDB に格納されているデータなど、大量のデータを迅速かつ効率的に処理できます。これはレポート作成ではなく、高速データ処理に利用される実装方式です。

 

顧客からの読取リクエストの急増によって、アプリケーションの表示が遅れたり、エラーとなるケースが多発しているようです。
この問題を解決するために、コストを度外視した最も高パフォーマンスな方法を選択してください。
このシナリオでは、アプリケーションのパフォーマンスが大きく低下し、特に読取パフォーマンスが低下していることが問題となっています。対応策としてはリードレプリカの増設、インスタンスタイプの高性能なタイプへの変更、キャッシュレイヤーでのElastiCacheの利用が考えられます。

この中でコストが高いものの、パフォーマンスが最も高いソリューションはElasticacheをキャッシュレイヤーに構成する方式です。ElastiCacheをRDSの前面に配置することで、RDSの読取処理が多いデータをキャッシュとして保持して、インメモリ上で高速処理することができます。インメモリDBであるElasticacheは他のDBと比較しても非常に高価ですが、性能が最も高いDBの一つです。したがって、オプション４が正解となります。
インスタンスタイプを高性能にすればするほど、RDSのパフォーマンスとコストが高くなります。しかしながら、これはElastiCacheに比較すれば最も高性能で高コストなわけではありません。

 

Amazon EFS は標準ストレージクラスと低頻度アクセスストレージクラス (EFS IA) という２つのストレージクラスを利用しています。EFS IA は、毎日アクセスしないファイルに対して最適化されたコスト効率の料金/パフォーマンスを提供します。ファイルシステムで EFS ライフサイクル管理を有効にするだけで、選択したライフサイクルポリシーに従ってアクセスしないファイルは、自動的かつ透過的に EFS IA に移されます。EFS IA ストレージクラスの費用は、たったの 0.025 USD/GB-月* です。したがって、オプション１が正解となります。
オプション２は不正解です。EFS IAを選択するのではなく、ライフサイクル管理を有効にして自動的にIAクラスへの移行するように設定することでEFS IAを利用します。

 

Amazon EFS は、幅広いワークロードに対応するために必要なスループット、IOPS、および低レイテンシーを提供できるように設計されており、汎用と最大 I/O の 2 種類のパフォーマンスモードを提供します。汎用モードは、ファイルシステムオペレーション単位で最小レイテンシーを実現するだけでなく、ランダムまたはシーケンシャル IO パターンでも同じ結果を得ることができます。したがって、最小レイテンシーを実現するためには汎用モードを選択することが必要です。
最大 I/O モードのファイルシステムは、ファイルオペレーションのレイテンシーがわずかに長くなる代わりに、スループットが高性能にスケールできます。

 

このアプリケーションは1年間にかけて週一回レポートを作成することが必要であり、そのためには24時間の処理時間をかけてレポート生成処理を実施することが求められています。
選択するべきインスタンスの購入オプションはどれ
スケジュールされたリザーブドインスタンス を購入するキャパシティー、または将来的に利用できるようにする予定はありません。キャパシティーを予約するには、代わりに オンデマンドキャパシティー予約 を使用します。割引料金については、Savings Plans を使用します。したがって、今回は購入オプションが問われているため、Savings Plansが回答となります。

このWEBアプリケーションはユーザーとリソースの地理的場所に基づいてリソースのトラフィックをルーティングすることが必要です。
この要件を満たすRoute53の設定方法を選択してください。
地理的近接性ルーティングは、Amazon Route 53 はユーザーとリソースの地理的場所に基づいてリソースのトラフィックをルーティングします。また、バイアスという値を指定することで、特定のリソースにルーティングするトラフィックの量を変更できます。バイアスはリソースにルーティングされるトラフィックのルーティング元である地理的リージョンのサイズを拡大または縮小します。地理的近接性ルーティングを設定するにはRoute 53 トラフィックフローを使用する必要があります。
一方で位置情報ルーティングはユーザーの位置情報（IPアドレスによる）基づいて特定のリージョンに対して、ルーティングさせる設定をすることができます。ユーザーとリソースに基づいた地理的近接性ルーティングと似ていますが、リソースに基づかない等で部分的に異なることを理解してください。したがって、オプション１と４は不正解です。

オプション３は不正解です。地理的近接性ルーティングはレコード設定では設定できないため、トラフィックフローを利用することが必要となります。

 

このシナリオでは、アプリケーションユーザーは世界中におり、すべてのユーザーがシステムを頻繁に使用しているわけではありません。したがって、一部リージョンで負荷が高くなっているため、Route53によるレイテンシールーティングを利用します。これにより、ユーザーによるリクエストをレイテンシーが低いリージョンにリダイレクトして、アプリケーションの処理を高速化します。

 

保存データは滅多に利用されない中長期保存用となりますが、利用する場合は１２時間以内にファイルを送信することが必要です。
このシナリオでは、データ分析の前後に発生する大量のデータを保存するためのコスト最適な方法が必要となっています。まずはデータをzipまたはtarファイルに圧縮することにより、データの保存コストを削減できます。保存データは12時間以内に取得できる必要があるため、Glacier よりもGlacier Deep Archiveに保存することでコストを抑えることができます。Glacier Deep Archiveはデータは ３ つ以上の AWS アベイラビリティゾーンにまたがって保存され、12 時間以内に取りだすことができます。したがって、オプション２が正解となります。

 

このシナリオでは、Webサーバーとアプリケーションサーバー、およびOracleデータベースで構成されるアプリケーションのデータのバックアップを実現することが求められています。このデータはデータベースとサーバーのファイルシステムの両方に保存されています。そして、2時間以内にデータベースの回復、サーバーディスクの復元、および個々のファイルの復元を実施することが必要です。
オプション３が正解となります。RDSを利用してOracleデータベースを起動して自動バックアップを設定することで、一定時間での定期的なバックアップ取得を実現します。

現在のアーキテクチャではVPCエンドポイントをそのまま使用できないようです。
VPCエンドポイントを利用してS３バケット内のコンテンツをシェアする方法を選択してください。
VPCエンドポイントはリージョン内のポイントであるため、リージョン外からはアクセスできません。したがって、エンドポイントを使用するには、使用されるリージョンに S3 クロスリージョンレプリケーションによってS3オブジェクトをコピーする必要があります。これによって、対象リージョンにS3オブジェクトをレプリケーションすることで、そのリージョンに対するVPCエンドポイントによるアクセスを構成します。

 

HTTP 503 レスポンスとは「サービスが利用できない」ときに表示されるエラーです。バージョニングを有効にしたバケットに対して 当該エラーが発生してしまう原因は、数百万のバージョンを有する1 つ以上のオブジェクトが存在している可能性があります。数百万のバージョンを持つオブジェクトがある場合、Amazon S3 は、過剰なリクエストトラフィックからユーザーを保護するためバケットへのリクエストを自動的に調整します。
この問題を回避するためには、ライフサイクル管理の「NonCurrentVersion」有効期限ポリシーと「ExpiredObjectDeleteMarker」ポリシーを有効にして、以前のバージョンのオブジェクトを期限切れにすることです。そして、バケット内に関連するデータオブジェクトが存在しないマーカーを削除します。

 

CloudTrailはアクティビティログを取得するサービスであり、アクティビティに関する監視に利用できます。しかしながら、ここで問われているのはIAMユーザーのアクティビティの不正ではなく、外部の第三者のアクセスに対する不正確認となっております。外部アクセスを許可している際に不正な利用が発生しないかを検証するためのツールは IAM Access Analyzerrになります。

オプション２は不正解です。サーバーアクセスのログには、バケットに対するリクエストの詳細が記録されます。サーバーアクセスのログは、多くのアプリケーションに役立ちます。たとえば、アクセスのログ情報は、セキュリティやアクセスの監査に役立ちます。これはオブジェクトのアクセスパターンを分析するものではありません。

オプション３は不正解です。Amazon S3 分析のストレージクラス分析を使用することにより、ストレージアクセスパターンを分析し、適切なデータをいつ適切なストレージクラスに移行すべきかを判断できます。

 

S3バケットの公開に対する制御はACLまたはバケットポリシーにより実行します。バケットポリシーはバケットのみに設定されるアクセス制御ですが、ACLはバケットとオブジェクトの両方に設定することができます。ACLではバケット単位のACLの設定に関係なくオブジェクト単位のACLが優先されるように設定されます。つまり、バケットACLでパブリックアクセスを許可しない設定することに加えて、オブジェクトについてもACLでパブリックアクセスを許可していないことが必要となります。

このようなACLの設定は非常に面倒であったため、追加されたのが S3のパブリックアクセス設定機能です。 S3 の パブリックアクセス設定機能は、バケットレベルまたはアカウントレベルで、すべてのオブジェクトへのパブリックアクセスをブロックできます。この機能でブロックを有効化することでS3バケット全体に対してパブリックアクセスを拒否することができます。したがって、オプション３が正解となります。

 

AI機能を実装するためにはGPUを利用可能なインスタンスを選択することが必要です。
AI機能にはGPUを利用することが最適です。GPUを選択するには高速コンピューティングインスタンスを利用します。高速コンピューティングインスタンスはハードウェアアクセラレーター を使用して、浮動小数点計算、グラフィックス処理、データパターン照合などの機能を、CPU で実行中のソフトウェアよりも効率的に実行します。ゲーミング処理やグラフィック処理、機械学習の処理にはこのインスタンスが最適です。

 

Amazon WorkSpaces は、マネージド型でセキュアな仮想デスクトップ ソリューションです。Amazon WorkSpaces を使うと、Windows または Linux のデスクトップを数分でセットアップできます。これを利用して、すばやくスケールすることで世界中のたくさんの従業員に仮想デスクトップを提供できます。 仮想デスクトップとすることでデータやデスクトップ構成をラックトップに保存することなく、集中管理することが可能となります。それによって、個人のPC紛失などによるデータ漏洩を防ぐことが可能です。

S3を利用したファイル共有を前提とした、会計システムをAWSにホストしています。この会計システムのファイルを他のドメインから連携して、利用する機能が必要です。
S3のCross-Origin Resource Sharing (CORS) を有効化すると、既にドメインが設定されているS3バケットを他のドメインに共有することが可能となります。CORSは特定のドメインにロードされたクライアントウェブアプリケーションが異なるドメイン内のリソースと通信する方法を定義します。これによって、Amazon S3 を使用して機能豊富なクライアント側ウェブアプリケーションを構築し、Amazon S3 リソースに対するクロスオリジンアクセスを選択的に許可することができます。したがって、オプション２が正解となります。

このシナリオでは、１つのAZにEC2インスタンスが設置されているため、AZ障害が発生した際にアプリケーション全体が停止してしまうリスクがあります。したがって、マルチAZ構成を実現するための最適な構成を選択することが必要です。

オプション１が正解となります。EC2インスタンスを別AZに起動して、ELBターゲットをAZを跨いで設定し、ELBがAZを跨いでEC2インスタンス間でトラフィックを制御します。これによって、１つのAZが停止した場合は、残ったAZでEC2インスタンスの処理を継続させることができます。

オプション２が正解となります。AutoScalingのスケーリンググループをAZ間を跨いで構成することで、１つのAZでのEC2インスタンスが停止したとした場合に、その処理負荷を生き残ったAZに新規インスタンスを起動させることで軽減させることができます。
Route53によりフェールオーバールーティングを設定することは可能ですが、これは２つのEC2インスタンス間での単純なアクティブ・パッシブ構成を実施することしかできません。つまり、プライマリーのインスタンスがダウンした際にセカンダリーに切り替えることができるだけです。このケースでは、ELBによって複数インスタンス間でのトラフィック分散を実現することが必要です。Route53のフェールオーバールーティングはアクティブパッシブ構成しかできません。つまり、１つをセカンダリーにして待機する構成しかできないためこれは災害復旧対策用の構成となります。今回は複数AZをまたいだトラフィック分散をすることでAZ障害への対応することが求められています。

 

ECSタスクのためのIAMロールを作成した上で、EC2コンテナではなくECSタスクに直接IAMロールを紐付けることで、安全なアクセス権限付与が可能となります。したがって、DynamoDBへの読取権限を付与したIAMロールをECSタスクに付与することで、ECSタスク上のEC2インスタンスからDynamoDBテーブルの読取オペレーションが実行可能となります。

 

Amazon S3 アクセスコントロールリスト (ACL) では、バケットとオブジェクトへのアクセスを管理できます。ACLにより、アクセスが許可される AWS アカウントまたはグループとアクセスの種類が定義されます。リソースに対するリクエストを受信すると、Amazon S3 は該当する ACL を調べて、必要なアクセス許可がリクエスタにあることを確認します。したがって、オプション４が正解となります。
バケットポリシーは、バケットに対してユーザーアクセス権限を設定するバケットに関するポリシーです。オブジェクト単位でのアクセス権限のコントロールにはACLを利用します。今回はオブジェクトへのアクセス権限の設定であるためACLが正解となります。

RDS MySQLデータベースから毎週同じクエリ処理を行いデータを集計して、レポートを生成するタスクを自動化しようと考えています。そこで、あなたはLambdaを連携したデータ集約関数を構築することにしました。
RDS プロキシはアプリケーションとRDSデータベースの間の仲介役として機能します。RDS プロキシは必要となるデータベースへのコネクションプールを確立および管理し、アプリケーションからのデータベース接続を少なく抑える機能です。
Lambda関数はRDSエンドポイントではなくRDSプロキシを利用して接続することが求められます。RDSプロキシはLambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングします。これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用できます。 RDSプロキシを利用せず、エンドポイントを利用するとLambda関数によってコネクションが多数発生して処理が上手くいかなくなってしまいます。

 

データレイヤーのDynamoDB領域に一時的なアクセス集中があり、書込処理能力が落ちてしまうトラブルが発生しています。コスト効果の良いソリューション

DynamoDBをマルチAZ構成で起動する機能はないため不適格です。また、「グローバルセカンダリーインデックスを付与する」と読取クエリ処理が効率化できるようになりますが、今回の要件には不十分な対応となります。

 

RDS MySQL DBインスタンスが70％のCPU使用率に達すると、アプリケーションは応答しなくなることが分かりました。
この問題を解決するためにデータ層の拡張方法はどれ
Amazon RDSリードレプリカは、DBインスタンスのパフォーマンスと耐久性を強化します。このレプリケーション機能を使用すると、読み取りが多いデータベースワークロードに対して、単一のDBインスタンスの容量制限を超えて弾力的にスケールアウトすることが容易になります。

オプション３は正解となります。シャーディングはデータベース内の複数のテーブルにデータを分割するための一般的な概念です。リクエスト増加などで単一のマスターDBの運用で限界がある場合に、 一定のルールに従いデータを複数のDBに振り分けることでアクセスを分散させることができます。

 

Amazon EFS はNFSv4 プロトコル経由で従来のファイルアクセス許可するファイルストレージです。Amazon EC2 インスタンスとオンプレミスサーバーの数千の接続に安全なアクセスを同時に提供します。Amazon EC2 インスタンスはAZ、リージョン、VPC にかけてファイルシステムにアクセスできます。また、オンプレミスサーバーは AWS Direct Connect あるいは AWS VPN を介してアクセスできます。したがって、オプション３が正解となります。

 

EBSのRAID１構成は耐障害性が I/O パフォーマンスより重要な場合に利用されるストレージ構成です。１つのEBSボリュームが故障したとしてもデータの消失を防ぐことができ、RTO1分以内の回復が可能です。

Amazon EBS はインスタンスでの冗長性確保のため、RAID 1 では 2 つのボリュームを同時にミラーリングできます。 Amazon EBS ボリュームのデータは、同じアベイラビリティーゾーン内の複数のサーバーにレプリケートされます。これは、コンポーネントの 1 つに障害が発生したことが原因でデータが失われるのを防ぐためです。このレプリケーションにより、一般的なコモディティディスクドライブに比べて Amazon EBS ボリュームの信頼性は10 倍に高まります。

 

VPC内のEC2インスタンスがソフトウェアの更新のために外部のサードパーティのURLからアクセスすることが必要です。セキュリティ要件として、EC2インスタンスに対して、その他のアウトバウンド接続を明示的に拒否する必要があります。
プロキシサーバーはクライアントからの要求をフィルターし、製品の更新に関連する要求のみを許可して、特定のソフトウェア更新以外のすべての要求をフィルタリングできます。
このシナリオではVPCのインスタンスにインターネットアクセスが必要であり、ソフトウェアの更新のみにアクセスを制限する必要があります。また、他のアウトバウンド接続を明示的に拒否することも求められています。そのため、制限なくインターネットにアクセスできないようにするために、EC2インスタンスをプライベートサブネットに配置する必要があります。また、クライアントマシンからの要求をフィルタリングするためのロジックが必要となるため、その制御にはプロキシサーバーを利用します。

 

このCloudFormationテンプレートでは前半で RegionMap内で、Mapping関数の参照元が設定されています。

 

RegionMap:

ap-northeast-1:

hvm: “ami-0792756bc9edf3e63”

ap-southeast-1:

hvm: “ami-0162da29310cc18f6”

 

この内容が、PropertiesにあるMapping関数によって引用させることになります。

 

Properties:

ImageId: !FindInMap [RegionMap, !Ref ‘AWS::Region’, hvm]

 

この引用方法としては、CloudFormationテンプレートが利用されたリージョンに応じてAMIを設定するという引用の仕方を実行します。したがって、オプション２が正解となります。

 

このシナリオではCloudFrontとカスタムオリジン間のHTTPS通信を設定する必要があり、オリジンがELBではない要件となっているため、信頼できるCAによって証明書が発行される必要があります。そして、そのCA証明書をオリジンとCloudFrontエッジ側の両方に利用して、HTTPSによるデータ通信を可能にすることが求められます。したがって、オプション３が正解となります。

■ビューアとCloudFront間のHTTPS Comodo、DigiCert、Symantec、またはその他のサードパーティプロバイダーなどの信頼できる認証局（CA）によって発行された証明書を使用できます。また、AWS Certificate Manager（ACM）が提供する証明書も使用できます
■CloudFrontとカスタムオリジン間のHTTPS オリジンがELB ロードバランサー以外のオリジンの場合、信頼されたサードパーティー認証機関 (CA) (Comodo、DigiCert、Symantec など) によって署名された証明書を使用する必要があります。
オプション１と４は不正解です。オリジンがELBではない要件となっているため、AWS Certificate Manager（ACM）ではなく信頼できるCAによって証明書が発行される必要があります。 ただし、ACM for Nitro Enclaves を利用することで、プライベート SSL/TLS 証明書を使用できるようにする Enclaves アプリケーションを利用してACMの証明書を設定することは可能です。今回のそのような構成は問われていないため不正解となります。

 

Amazon Redshift はクラスターに対してデータベースの暗号化を有効にして、保管データを保護できます。クラスターに対して暗号化を有効にすると、クラスターとそのスナップショットのデータブロックとシステムメタデータが暗号化されます。

Amazon Redshift は暗号化キーの階層を使用してデータベースを暗号化します。AWS Key Management Service (AWS KMS) またはハードウェアセキュリティモジュール (HSM) のいずれかを使用して、この階層の最上位の暗号化キーを管理できます。Amazon Redshift で暗号化に使用するプロセスはキーの管理方法によって異なります。したがって、オプション２が正解となります。

Amazon Redshift はAWS KMSと統合されており、暗号化を構成できます。しかしながら、HSM は統合されていません。HSM を使用するときは、クライアントとサーバーの証明書を使用して、Amazon Redshift と HSM との間で信頼された接続を設定する必要があります。したがって、オプション３が正解となります。

 

ボトルネックとなっているNATゲートウェイによるアドレス変換処理を高可用にするために２つ以上のアベイラビリティゾーンの複数のパブリックサブネットに対して複数のNATゲートウェイを構成する必要があります。これにより、１つのアベイラビリティゾーンが停止した場合でも、他のNATゲートウェイがインターネットトラフィックを処理できるようになります。 したがって、オプション２が正解となります。

また、NATゲートウェイを複数AZに展開した後は、それぞれのNATゲートウェイに対して、各AZにおいてプライベートサブネットへのルートテーブルでのルート設定を実施することが必要です。したがって、オプション４も正解となります。

 

この要件を満たすコスト最適な構成は、メッセージ処理においてSQSを利用して、オンデマンドのEC2インスタンスを処理サーバーとしつつ、インスタンスの可用性を高めるためにAutoScalingを構成します。AutoScalingには最も値段の安いスポットインスタンスを利用することが最適となります。
長期的な利用が不明確なシステム処理であるため、処理サーバーにはリザーブドインスタンスやスケジュールドリザーブドインスタンスは不向きです。

 

Amazon EC2 M5 インスタンスは、次世代の Amazon EC2 汎用コンピューティングインスタンスです。M5 インスタンスは、さまざまなワークロード向けに、コンピューティング、メモリ、ネットワーキングリソースをバランスよく提供しています。したがって、選択肢にあるM5インスタンスを利用してプレイスメントグループを設定することが最適です。

新しい EC2インスタンスを起動する場合、EC2は相関性のエラーを最小限に抑えるために、すべてのインスタンスが基盤となるハードウェアに分散されるようにインスタンスを配置します。プレイスメントグループを使用することで、ワークロードのニーズに対応するために独立したインスタンスのグループのプレイスメントに影響を与えることができます。この設定は先にプレイスメントグループを構成した上で、その中でインスタンスタイプとインスタンス数を決定します。
T3 インスタンスは、ベースラインレベルの CPU パフォーマンスを提供する次世代のバースト可能な汎用インスタンスタイプです。これはクラスタープレイスメントグループによる設定ができないインスタンスタイプです。

 

S3バケットからコンテンツが配信されるユーザーのIPアドレス範囲が限定されていないためセキュリティ上問題となっています。そこで、特定のユーザーに配信可能な方式に変更する必要があります。
CloudFront 署名付き URL または署名付き Cookie を作成して Amazon S3 バケット内のファイルへのアクセスを制限します。その上で、S3バケットに直接アクセスできないようにオリジンアクセスアイデンティティ (OAI) という特別な CloudFront ユーザーを作成して配布に関連付けて、CloudFront が OAI を使用してファイルにアクセスしてユーザーに提供できるようにアクセス許可を構成します。これによって、署名を有するユーザーのみに限定してコンテンツを配信することが可能です。

 

基本的にEBSは複数のEC2インスタンスにアタッチすることができないストレージタイプです。しかしながら、2020年2月より Multi-Attach 機能が追加されました。Amazon EBS プロビジョンド IOPS io1またはio2 ボリュームを利用している場合のみMulti-Attach を有効化して、単一のボリュームを同じアベイラビリティーゾーン内の最大 16 個の AWS Nitro システムベースの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに同時にアタッチできます。

Multi-Attach を使用すると、複数のライターからのストレージの一貫性を管理するアプリケーションの可用性を簡単に高めることができます。アタッチされた各インスタンスには、共有ボリュームに対する完全な読み込み／書き込み権限があります。マルチアタッチを使用するアプリケーションは、ストレージの一貫性のために IO フェンスを提供する必要があります。

—————————————-
Snowball Edge Storage Optimizedは最大で100TBの容量がありますが、利用可能な領域は80TBです。したがって、90TBのデータ移行には2つ使う必要があります。また、Snowball のストレージ容量は80 TB（72 TB使用可能）であり、90TBのデータ転送には2つ利用します。しかしながら、現在はSnowBall利用は推奨されておらず、AWSではSnowball Edgeの利用が求められています。
現在AWSではSnowBallの仕様は推奨されておらず、Snowball Edgeの利用が求められています。

このシステムはコールセンターのピーク時には非常に負荷が高まりますが、その負荷発生の周期が一定ではありません。
このシナリオでは、EC2インスタンスのWEBサーバーとOLTP処理を行うデータベースの両方をスケーラブルな構成によって可用性を高める必要があります。したがって、複数のアベイラビリティーゾーンにまたがるEC2インスタンスにAuto ScalingグループとELBを設定することが基本対応となります。また、データベースは不規則なピーク処理が発生することからAuroraサーバレスを利用します。 この中で回答にはデータベースの構成が求められているため、オプション３が正解となります。

Aurora Serverless は不規則な負荷に自動でスケーリングすることが可能なRDBです。DB インスタンスクラスのサイズを指定せずにデータベースエンドポイントを作成し、データベースエンドポイントがプロキシフリートに接続されます。このプロキシフリートでは、ワークロードをルーティングする先のリソースのフリートがオートスケーリングされます。プロキシフリートを使用すると、最小と最大のキャパシティー仕様に基づいて Aurora Serverless がリソースを自動的にスケールすることができます。

 

このシナリオでは、ECサイトは単一リージョン内の複数AZに跨いで複数のEC2インスタンスがホストされており、ELBによるトラフィック分散が設定されていますが、AutoScalingが設定されてないため高負荷時にダウンする可能性があります。

オプション１が正解となります。複数AZを指定したAuroScalingグループを作成し、それをELBターゲットグループに設定することで、複数AZにEC2インスタンスをスケーリングすることができるようになります。ELBによって既存AZのインスタンスに異常があれば、ヘルスチェックで確認され、その後AutoScalingが停止したAZにあったEC2インスタンスの代わりに別AZにEC2インスタンスを起動します。

testb1
—————————————————–
災害発生時に対処するため別リージョンでデータを利用できるようにする
最も回復性が速い方式

->AuroraはプライマリーとなるDBクラスターが設置されているリージョンとは異なるリージョンにリードレプリカを作成することができます。
障害回復機能を向上させて、読み取り操作をユーザーに近いリージョンに拡張しつつ、元のリージョンから別のリージョンへの移行を容易にすることができます。

—————————————————–
高いスループット処理性能
最も費用対効果の高いEBSのストレージタイプ

->スループット最適化HDD
スループット最適HDDは高いスループット性能を誇りますが、プロビジョンドIOPS SSDに比較して安いものの性能は劣ります。コスト最適を優先させる場合はこちらを選択します。

—————————————————–
スタックベースの展開モデルを用意する対応
アプリケーションのサーバーやデータベースに対して異なるレイヤーが必要とされています。

->AWS OpsWorks Stacks
OpsWorks Stacksを使用すると、負荷分散、データベース、アプリケーションサーバーなど、さまざまなレイヤーを含むスタックとしてアプリケーションをモデル化できます。

NG
スタックベースで異なるレイヤーを用意するにはCloudFormationよりもOpsWorksで詳細な設定をすることが望ましいです。

—————————————————–
API Gateway権限管理

->API の呼び出し等を API コール元に許可するためには、 IAM ポリシーを作成して設定することが必要です。

NG
-STSは一時的な認証許可をあたえる機能であり、中長期的なアクセス権限を付与するためには不適切です。
-IAMアクセスキーではなく、IAMユーザーやIAMロールによる権限管理が必要となります

—————————————————–
以下の前半のステートメントによって、examplebucketに対する全てのユーザーからの全ての「アクション」を拒否しています。

 

“Effect”: “Deny”,

 

“Principal”: “*”,

 

“Action”: “s3:*”,

 

“Resource”: “arn:aws:s3:::examplebucket/*”,

後半のステートメントにおいて、許可されたIP アドレスの範囲として 54.240.143.0/24 を指定しています。Condition ブロックでは、NotIpAddress 条件と aws:SourceIpを使用しています。ここではNotIpAddress 条件を利用しているため、54.240.143.0/24 以外のIPアドレスを指定しています。

 

“Condition”: {

 

“NotIpAddress”: {“aws:SourceIp”: “54.240.143.0/24”}

 

}

 

したがって、このバケットへのリクエストが指定された IP アドレス範囲以外である場合に、この S3 バケット内のオブジェクトに対する「アクセス」が拒否されます。

—————————————————–
オンプレミス環境からAWSへの移行
72時間でデータ移行を完了させる必要

ー>AWS サイト間 VPN (Site-to-Site VPN) 接続
インターネットプロトコルセキュリティ (IPsec) 通信を使用して 2 点間に暗号化された VPN トンネルを作成することができます。

NG
Direct ConnectやSnowballを発注して移行を週末に実施することは困難です。なぜならば、AWS側との調整する時間が必要となり、この時点からAWSにこれらの機器を発注しても間に合いません。唯一即時に実施できる手段がVPN接続設定です。

—————————————————–
初期ストレージ容量が8 TBの高可用性リレーショナルデータベースが必要です。
要件として データ量が毎日10 GBずつ増加することが予測されています。
データ処理向けに並列処理が必要があります。

->Redshiftは大量データの保存や並列処理によるパフォーマンス向上が可能
Redshiftはクラウド内で完全に管理されたペタバイト規模のリレーショナルデータベース型のデータウェアハウスサービス

NG
Aurora MySQL 並列クエリは、データ集約的なクエリの処理に関連する I/O と計算の一部を並列処理することができます。しかしながら、業務解析システムという要件を鑑みると、AuroraよりもRedshiftが最適である

—————————————————–
S3オブジェクトをユーザーに提供するアプリケーション
永続的に外部リンクを利用できないように対応する必要があります。

-> AWS WAFのReferer制限によって直接にURLリンクを参照することを制限することができます。
AWS WAF は、CloudFront に転送される HTTP および HTTPS リクエストをモニタリングして、コンテンツへのアクセスを制御可能にするウェブアプリケーションファイアウォールです。

NG
今回は外部の直接リンク設定を不許可にする設定を求めている問題となっています。署名付きCookieや署名付きURLはアクセス権限の制限をすることができますが、【リンク自体を利用することは可能】です。しかしながら、直接リンクを禁止することはできないため、正しくありません。
—————————————————–
「WEB層」では柔軟でスケーラブルなアーキテクチャ構成を実現する必要があります。

->EC2インスタンスに対してAuto ScalingとELBを設定する
ELBがトラフィックを複数インスタンスに分散することで冗長性を高め、かつAutoScalingが高負荷時のスケーリングを自動で実行してくれます。

NG
・WEB層において柔軟でスケーラブルなアーキテクチャ構成を実現することが要件ですので、「データベース層」にあるRDSのマルチAZ構成の設定は正しくありません。
・Route53によるフェイルオーバールーティングは要件に合致していません。フェイルオーバールーティングは耐障害性を向上させますが、パフォーマンスを向上させるわけではありません

—————————————————–
SQSからトランスコードジョブを引き出すEC2ワーカーインスタンスを使用してこの仕組みを構築する予定です。
この仕組みを実現するためのSQSの説明

ー>SQSキューによって複数EC2インスタンスによる【並行処理】が可能となり、負荷【分散】や処理プロセスの最適化を達成することができます。
AWSリソースの【水平方向】のスケーリングに役立ちます

—————————————————–
VPCのサブネットにパブリックIPを付与したEC2インスタンスをセットアップしています。
しかし、あなたはインターネットを介してEC2インスタンスに接続することができませんでした。
セキュリティグループは正しく設定されているようです。

->セキュリティグループとネットワークACLが適切な許可設定にされていること、
および設置されているサブネットのルートテーブルにインターネットゲートウェイへのエントリがあることを確認する必要があります。

NG
Elastic IPは必須ではありません。

—————————————————–
ユーザーが誤ってS3バケット内のオブジェクトを削除してしまう懸念があります。
業務に影響を与えてはいけません。

->
MFA認証を有効化
毎回MFA認証が求められるため、操作ミスによる削除を防ぐ
バージョニング機能を有効化
削除されたファイルを戻す

NG
S3バケットは初期設定でオブジェクトを削除できない設定が可能ですが、これは初期設定時のみに利用可能です。既に利用しているS3バケットの設定を変更することはできません。また、データ削除の操作が必要なケースもあるため、本ケースでは不適切です。

—————————————————–
データベースとしてRDSインスタンスを利用することを計画しています。
データベースに保存されるデータを確実に暗号化する必要があります。

->データベースの暗号化は、データベースの作成中に行うことができます。
Amazon RDS DB インスタンスとスナップショットを暗号化するためには、Amazon RDSのDB インスタンス設定メニューにある暗号化オプションを有効化します。

—————————————————–
オンプレミスにあるアプリケーションサーバーにiSCSIデバイスにより接続する
移行後はAWS上のストレージをプライマリー

ー>「ストレージゲートウェイのキャッシュ型ボリューム」を使用すると、頻繁にアクセスされるデータをローカルに保持しながら、Amazon S3をプライマリデータストレージとして使用できます。

—————————————————–
ワーカープロセスの信頼性を高めるため利用すべきサービス

ー>Amazon SQSはシステムの分散処理化に使用されます。
キュー内にワーカープロセスの動画処理要求を格納して、非同期処理による確実な処理実行を可能にします。

—————————————————–
SQSキューとLambdaを使用して、AWSクラウドのサーバーレス構成を利用したいと計画しています。

->Lambda関数が他のAWSリソースにアクセスする必要がある場合は、そのサービスに対するアクセス権限を付与するIAMロールがLambda関数に設定されている必要があります。

—————————————————–
PostgreSQLデータベースをAWSに移行
データ量は15TBを超えており、1日のトランザクション量としては【10,000アクセス】を超える大量処理
自動バックアップのためにレプリカを設定して可用性を高める

->Amazon Aurora は、MySQL および PostgreSQL と互換性のあるクラウド向けのリレーショナルデータベース
データ量が15TBを超えており、1日のトランザクション量は10,000アクセスを超えます。したがって、RDSやEC2インスタンスベースのPostgreSQLでは不十分
Amazon Aurora は RDSを使った完全マネージド型サービスであるため、ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップといった時間のかかる管理タスクが自動化されます。

—————————————————–
「ステートレス」であり、かつコスト最適なアプリケーションを構築したい
処理能力に応じた拡張性も付与したい

->Lambdaファンクションはステートレスなアプリケーション処理をコスト最適に達成できます。
ステートレスアプリケーションはシステム上のやり取りの状態情報が不要なため、セッション情報が格納されていないアプリケーションのことです。そのため、同じ入力が与えられたときに、どのエンドユーザに対しても同じ応答を提供するアプリケーションとなります。

—————————————————–
Amazon Elastic Transcoderを利用してトランスコードプロセスを実行
コスト最適なバックログ処理用のインスタンスタイプ

ー>スポットインスタンス
バックログの発生を抑えるためにトランスコード処理用のインスタンスを一時的に増加させて対応したい
スポットインスタンスは通常、バッチ処理ジョブなどの一時的な処理に利用されます。

—————————————————–
書き込み操作がどのような状況下でも失われないようにする対応

ー>
「保留中のデータベースへの書き込みリクエスト」を、【SQS】キューに格納して非同期に処理することができます。
DynamoDBのデータ処理実行には【Lambda】と連携しつつキューによるDB処理を実行することも可能です。

NG
DynamoDBの書込処理に対してSQSキューだけでは、分散処理プロセスを実行できません。SQSをトリガーにしたLambda関数が必要不可欠です。

—————————————————–
請求情報とコスト管理ダッシュボードで確認することのできる内容

=>「予算」「概算請求」「コストエクスプローラー」

NG
ポリシーは請求情報とコスト管理ダッシュボードで管理されるものではなく、IAM（Identity and Access Management）で管理されるものです。請求情報とコスト管理ダッシュボードで確認することはできません。

—————————————————–
高可用性リレーショナルデータベース

ー>選択肢の中でリレーショナルデータベースは、Amazon Auroraのみ

NG
Amazon Redshiftはクラウドで利用できるDWH（データウェアハウス）サービス

—————————————————–
サブネットを追加する必要があります。
どのようにVPCに新しいサブネットを作成するか

->VPC 作成時に割り当てる CIDR ブロックがプライマリ CIDR となり、後から追加するのがセカンダリ CIDR になります。VPC の CIDR ブロックの拡張を行うためには、セカンダリ CIDR ブロックを割り当てることで、セカンダリ CIDR の範囲を使ったサブネットが新規に利用可能になります。
NG
・「既存のサブネットの CIDRブロック範囲を縮小して、新しいサブネットのための IP アドレス空間を確保する。」
→既存の IP アドレス空間が縮小してしまうため、最善な策ではないため間違いです。
—————————————————–
スタンダードリザーブドインスタンスの特徴
・同じリージョン内でアベイラビリティーゾーンを変更する
・予約したスコープ(リージョンまたアベイラビリティゾーン)を変更する。
・EC2-VPC と EC2-Classic を切り替える
・同じインスタンスタイプ内でインスタンスサイズを変更する
・インスタンスのタイプは固定です。
→スタンダードリザーブドインスタンスは、インスタンスサイズを変更することはできますが、「タイプ」を変更することはできず固定になります。
・「システムの総保有コスト(TCO)の削減に有効である。」
→オンデマンドインスタンスと比較して割引がありコスト削減が可能であるため、正解です。
・「Auto Scaling によって起動されたインスタンスに適用できます。」
→適用できるため、正解です。
■補足
・AZ 間での移行については、現在は可能です。また、リザーブドインスタンスのScopeに「Region」を選択された場合、「キャパシティの予約」は行われません。キャパシティの予約を目的としてリザーブドインスタンスを購入されている場合は、Scopeに「Region」ではなく「Availability Zone」を選択する必要があります。

—————————————————–
ユーザーの誤操作による偶発的な EC2 インスタンスの削除を阻止

->「DisableApiTermination 属性を有効にする。」
インスタンスがコンソール、CLI、または API を使用して終了できるかどうかを制御します。デフォルトでは、インスタンスの削除保護は無効になっています。

—————————————————–
6つのEC2インスタンスにリクエストが分散されるようにElastic Load Balancerで構成されています。
各EC2インスタンスは、Amazon DynamoDBテーブルからデータを取得します。
ワークロードの高可用性を担保する最適な方法

->1つのリージョン内の 2 つのアベイラビリティーゾーンにインスタンスを配置することにより、アプリケーションの可用性を高めることができます。

NG
「最低 2 つのアベイラビリティーゾーンにわたって DynamoDB テーブルをプロビジョニン グする。」
→DynamoDB は AWS 管理の高可用性サービスであるため間違いです。
「2つのリージョンの少なくとも2つのアベイラビリティーゾーンにわたって EC2 インスタ ンスを均等にプロビジョニングする。」
→ELB はリージョン間でトラフィックをルーティングできないため間違いです。
「Elastic Load Balancer をプロビジョニングして、複数のアベイラビリティーゾーンにリクエストを分散する。
」→ELB は、接続されているインスタンスに応じて、アベイラビリティーゾーン全体に負荷を分散するため間違いです。

—————————————————–
買収後の企業が所有しているオンプレミス上の複数のアプリケーションの、AWS移行
50TBのデータ転送
安全なネットワーク接続と一貫したスループットが必要

->「AWS Snowball を利用し、AWSへのデータ転送を行い、各社 Direct Connect 経由でアプリケーションに接続する」
-50TB などの大容量データの転送には、AWS Snowball　が適しています。10TB 未満の場合、Snowboall は費用対効果の観点で最適な選択ではないケースがあります。
-【安全なネットワーク接続や一貫したスループット】が必要な場合、VPN よりも 【Direct Connect】 が適しています。

—————————————————–
Auto Scalingについて、誤っている説明

->Auto ScalingでスケールアウトしたEC2インスタンスをスケールインする場合、デフォルトでは以下の順番で実行されます。
・インスタンス数（最も多いAZから優先）
・上記同条件の場合、起動設定が古いインスタンスがあるAZを優先
・起動設定が古いインスタンスが複数ある場合は、次の課金発生までの時間が最も短いインスタンスを優先
・次の課金発生までの時間が同じインスタンスが複数ある場合はランダム

—————————————————–
デプロイとプロビジョニングの両方ができる AWS のサービス

->Elastic Beanstalk
アプリケーションをアップロードするだけで、Elastic Beanstalk は容量のプロビジョニング、ロードバランシング、スケーリング、およびアプリケーション状態モニタリングを自動的に処理します。
NG
CodeDeployはデプロイのみ、CloudFormationはプロビジョニングのみとなります。

—————————————————–
EBS 上にあるファイルを暗号化
不適切なもの

->既存EBSボリュームの暗号化設定を変更することはできないため、「EC2インスタンス停止後、EBSボリュームの暗号化設定を行う」が不正解

既存EBSボリュームを暗号化するために、以下の順で作業を実施します。
1. 既存EBSボリュームのスナップショットを取得
2. 取得したスナップショットを、[EBS暗号化] を有効化しコピー
3. コピーしたスナップショット(暗号化済み)から EBS ボリュームを作成
4. EC2インスタンスから既存EBSボリュームをデタッチする
5. EC2インスタンスに作成した EBSボリューム(暗号化済み)をアタッチする
—————————————————–
WEBサーバはEC2インスタンス、ELBとAutoScallingグループ
静的コンテンツはAmazonS3
CloudFrontによる配信
Webページの平均読み込み時間をさらに短縮するための対策

->回答では、RDSの読み取り処理を向上させる手段を選択
・「ユーザセッション情報と頻繁に発行されるDBクエリを保存するためにElastiCacheを使用し、データベースの負荷を軽減する。」
・「データベースへの読み込み負荷を分散させるために、RDS DBインスタンスにリードレプリカを追加する。」

NG
-「RDSのマルチAZ構成にすることで、データベースの負荷を軽減する。」は不正解です。RDSのマルチAZ構成により可用性が高めることができますが、パフォーマンスは改善しません。
-「Route53を追加して、マルチバリューのルーティングによる負荷分散を実施し、データベースの負荷を軽減する。」は、Route53の複数値回答ルーティングは各リソースが正常かどうかも確認するため、Route 53 は正常なリソースの値のみを返します。アベイラビリティーとロードバランシングを向上させることができます。しかしながら、データ処理の性能向上には利用できません。

—————————————————–
「EC2」のバックアップを取得する際に利用するサービス

->EBSスナップショットはEBSボリュームのバックアップをAmazon S3にバックアップすることができます。
AMI（Amazon Machine Images）は、「EC2」のバックアップを取得する際に利用されるサービスです。

—————————————————–
AWS Trusted Advisor でチェックできない推奨項目

ー>「アクセス制御に関する推奨項目」が正解
Trusted Advisor は、「コスト最適化」「パフォーマンス」「セキュリティ」「耐障害性」「サービスの制限」といったチェックカテゴリが存在します。
—————————————————–
Cloudwatchの標準メトリクスでモニタリングできるもの

ー>標準メトリクスでは、OSの外から測定できるメトリクスしか取得できません。
また、よく混同されがちなケースですが、メモリ利用率などといったOS内でしか測定できないメトリクスはカスタムメトリクスで取得する必要があるので基本的な監視項目を検討する場合にはカスタムメトリクスを設定しましょう。

—————————————————–
Node.jsアプリケーションの処理
毎分5件から毎分5,000件以上にリクエストが増える

->AWS Lambda はサーバーレスコンピューティングサービスであり、プログラムコードの実行基盤をAWSサービスとして提供します。
Node.js アプリケーションを AWS Lambda で実行できます。
必要な時だけプログラムを実行することができ、1日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的に実行

—————————————————–
大規模なAmazon S3の【共有データセットのアクセス管理】を簡易にしたい

->「Amazon S3 アクセスポイントを利用するように設定する。」
アクセスポイントは、バケットに付与されたネットワークエンドポイントの名前で、S3 オブジェクトのオペレーション (GetObject や PutObject など) を実行できます

NG
-「S3 transfer accelerationを利用するように設定する。」は不正解です。Amazon S3 Transfer Acceleration を使用すると、クライアントと S3 バケットの間のファイル転送を高速、簡単に行える
—————————————————–
AWS CloudFront でオリジンサーバとして設定できるもの

ー>CloudFrontのオリジンサーバは、以下の３種類
①S3オリジン（バケット）
②S3オリジン（静的ホスティング）
③カスタムオリジン（カスタムオリジンとは一般的なWebサーバでありパブリックとプライベートの両方を扱うことができます。）

—————————————————–
別のアベイラビリティゾーンに2つ目のAmazon EC2 インスタンスとAmazon EBS ボリュームを作成しApplication Load Balancer 配下に2つのAmazon EC2インスタンスを配置しました。
Webサイトにアクセスする際に全てのドキュメントが表示されない
解決するためのソリューション

->「両方の EBS ボリュームから Amazon EFS にデータをコピーします。新しいドキュメントは Amazon EFSされるようアプリケーションを変更します。」
Amazon EBS ボリュームはインスタンス間で共有できないため、すべてのインスタンスでAmazon EFS のような共有ファイルシステムを使用するのが理想的です。

—————————————————–
単一のアベイラビリティゾーンに複数のAmazonEC2インスタンスを構成してゲームを提供しています。
本ゲームはレイヤー4のプロトコル

ー>「複数のアベイラビリティーゾーンのインスタンスを自動的に追加または削除する Auto Scaling グループを設定します。」

NG
・「EC2 インスタンスの前に Application Load Balancer を設定します。」
→Application Load Balancer はレイヤー 4 プロトコルをサポートしていないため間違いです。
—————————————————–
【読取処理】の性能を拡張する方法

ー>「ElasticCacheをRDSの前に設置して、キャッシュ処理を導入する方法」
「RDSのリードレプリカを追加して、読取処理を分散化する方法」が正解となります。
NG
-「RDSへのアクセス集中を軽減するためにSQSにより処理しきれない処理を待機させる方法」は不正解です。
SQSキューは読取処理ではなく、書き込みなどのタスク処理を並列化する際に利用されます。読取処理の負荷分散ではリードレプリカを利用することが必要です。

—————————————————–
Amazon S3の特徴として誤っている物

-> 「保存データは自動的に複数のリージョンに分散されて安全に保存される」
Amazon S3はグローバルサービスですが、データはリージョンごとに保存される仕様です。複数のリージョンに保存されるのではなく、「複数のアベイラビリティゾーンに保存される」と理解しましょう。

—————————————————–
データベースにはMySQL
勤務時間中にリアルタイムレポートを生成する
AWSに移行後、アプリケーションのパフォーマンスを改善するソリューション

ー>Amazon Aurora は MySQL との互換性を提供し、リードレプリカを使用してレポートのニーズに合わせてプライマリデータベースから負荷をオフロードできます。

■Amazon RDS リードレプリカ
Amazon RDS リードレプリカによって、RDS データベース (DB) インスタンスのパフォーマンスが向上します。リードレプリカを使用すると、読み取り頻度の高いデータベースのワークロードに対して、柔軟にスケールアウトできます。DB インスタンスのレプリカを複数作成し、アプリケーションの読み取りトラフィックを複数のDBインスタンスレプリカから取得することにより、全体の読み込みスループットを向上させることができます。
■Amazon Aurora のリーダーエンドポイント
リーダーエンドポイントを使用して別のアベイラビリティーゾーンにある複数の Aurora レプリカを配置し、読み取りワークロードの読み取り専用エンドポイントに接続すれば DB クラスターからの読み取り専用クエリで高可用性を確保することができます。また、リーダーエンドポイントは DB クラスターにある Aurora レプリカへの接続を負荷分散します。
—————————————————–
ネットワークの遅延を考慮し、【ユーザのロケーションに近いリージョン】にアクセスができるようトラフィックをルーティングする

ー>地理的近接性ルーティングは、【リソースの場所に基づいて】トラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する場合に使用

NG
一方で位置情報ルーティングは【ユーザーの位置情報（IPアドレスによる）】基づいて特定のリージョンに対して、ルーティングさせる設定をすることができます。ユーザーとリソースに基づいた地理的近接性ルーティングと似ていますが、【リソースに基づかない】等の違いがあります。
—————————————————–
Auto Scaling を利用している
EC2 インスタンスタイプを変更する場合の、正しい方法

->「新たなインスタンスタイプを含む起動構成を新規作成し、既存の起動構成と置き換える」が正解となります。

NG
-「Auto Scaling グループの設定を変更し、インスタンスタイプを追加する」について、インスタンスタイプは起動構成の中で指定するものであるため、Auto Scaling グループから設定を変更することはできません。
-「既存の起動構成を変更し、インスタンスタイプを置き換える」について、起動構成は作成後に変更不可であるため、インスタンスタイプの置き換えはできません。
-「新たなインスタンスタイプで起動構成を作成後、既存の Auto Scaling グループに追加する」について、Auto Scaling グループに指定できる起動構成は一つのみであるため、追加することはできません。
—————————————————–
Auto Scalingの設定において、AMI IDの情報は次のうちどれに使用されますか？

->起動設定とは、EC2 インスタンスを起動するために Auto Scaling グループで使用されるインスタンスの設定テンプレートです。
指定する情報には、Amazon マシンイメージ (AMI) の ID、インスタンスタイプ、キーペア、1 つ以上のセキュリティグループ、ブロックデバイスマッピングなど
—————————————————–
不正検知・防御システム(IDS・IPS)
IPSを使用してインターネットからのトラフィックを保護する最適な方法と2つ

->IPS (Intrusion Prevention System)は、不正侵入防止システムである。
インスタンスまたは【リバースプロキシ層】に 【IDS/IPS エージェント】を実装することで解決できます。

■以下は誤りになります。
「各サブネット内のインスタンスのネットワークインタフェースカードをプロミスキャスモードに切り替え、ネットワークトラフィックを分析します。」
→AWS はプロミスキャスモードを設定することができず、各 VPC、サブネットはそれ用のトラフィックのみを受信します。
「ウェブアプリケーションのフロントに SSL リスナーを持つ ELB を実装します。」
→SSL を使用した ELB は IDS/IPS として機能しないため間違いです。
—————————————————–
EC2インスタンス上のゲストOS内にあるログを収集し監視を始めたい

ー>CloudWatch Logs により、使用中のすべてのシステム、アプリケーション、AWS サービスからのログを、スケーラビリティに優れた 1 つのサービスで一元管理することができます。
ログの収集や監視の観点で最も適しています。
エージェントをインストールすることで、EC2インスタンス内のログを収集・通知も実施可能です。

NG
「AWS CloudTrail」は監査目的で各アカウントの操作状況を記録するサービスです。
—————————————————–
秒間数百ほどの急激なリクエスト増も想定されます
将来増加する可能性も
データは Key-Value 形式で保存され検索する

ー>「AWS Lambda と Amazon DynamoDB を利用する」が正解です。
AWS Lambda では、対応するリクエストの数が、1 日あたり数個から 1 秒あたり数千のレベルまで自動的にスケーリングされます。そのため、「秒間数百ほどの急激なリクエスト増」への対応にも適しています。
【Auto Scaling は伸縮性の面で、AWS Lambda に劣ります。】

データベースの選択は、”Key-Value 形式” とあるため、完全マネージド型の NoSQL データベースサービスである、DynamoDB が適しています。MySQL(Aurora) は、完全マネージド型のリレーショナルデータベースエンジンとなります。
—————————————————–
【共有ストレージレイヤー】はすべてのEC2インスタンスから【同時にマウントおよびアクセス】(->EFS)することができます。
非常に高いスループットが求められますが、レイテンシは問題になりません。

->最大I/OモードのEFSを使用するとスループットは高まりますが、代わりにファイル操作のレイテンシ（遅延）がわずかに高まります。

NG
S3では、同時にマウントおよびアクセスできませんので不正解です。
EBSはインスタンス間で共有できないので不正解です。
—————————————————–
オンプレミスのストレージをAWSのストレージへと移行する

->AWS DataSync は、オンプレミスストレージと Amazon EFS 間でデータを迅速かつ簡単に移動することができるマネージド型のデータ転送サービスです。

NG
-AWS バックアップはAmazon EFS ファイルシステムの中央管理とバックアップの自動化が簡単にできるフルマネージド型のバックアップサービスであるため、不正解です。
-AWS Server Migration Service は、オンプレミスの VMware vSphere、Microsoft Hyper-V/SCVMM、または Azure 仮想マシンの AWS クラウドへの移行を自動化するサービスであるため、不正解です。
-AWS Direct ConnectはオンプレミスのサーバーとAWSを専用の回線でつなぐサービスです。
—————————————————–
低レイテンシーかつ高スループットな【ブロックストレージ】

->「Amazon EBS ボリューム
ブロックストレージとしては、EC2 インスタンスストア と EBS ボリュームの 2 つがありますが、EC2 インスタンスストアは EC2 インスタンスが停止してしまうとデータ損失が起こるなど一時的な利用のみが推奨されています。一方で、EBSボリュームについては、SSD も選択でき、低レイテンシーかつ高スループットが期待できる EBS 最適化インスタンスと併せて利用することも可能です。
—————————————————–
ゲームユーザの行動データ解析処理を高速に行える
最適な【データベース】処理の設計を行う必要

ー>「ElastiCacheによるキャッシュ処理を実装する。」
インメモリデータストアを、シームレスにデプロイ、運用、スケールできます。
高スループットかつ低レイテンシーなインメモリデータストアからデータを取得して、大量のデータを扱うアプリケーションを構築したり、既存のアプリケーションのパフォーマンスを改善したりすることが可能

NG
「EMRによる高速処理を実装する。」は不正解です。Amazon EMR は、オープンソースのフレームワークである Apache Spark と Hadoop を使用して、膨大な量のデータを迅速かつコスト効率よく処理して分析するサービスです。ゲームユーザー行動データの解析処理には利用できなくはないですが、【データベースではない】ため、比較するとElastiCacheの方が適したユースケースとなり要件により合致しているため、不正解となります。
—————————————————–
デフォルトで一つのリージョンに作成できるサブネットの上限数
->デフォルトの制限は、１リージョンあたり200サブネット
—————————————————–
企業ウェブサイト（www.yourcompany.com）から、バックエンドサーバ（services.yourcompany.com）
APIをJavaSscriptを実装してブラウザで呼び出すと、次のエラーが表示
The same origin policy disallows reading the remote resource

->API Gateway で CORS を有効にする必要
API のリソースが API 自身のドメイン以外のドメインからリクエストを受信する場合、リソース上の選択されたメソッドのクロスオリジンリソース共有(CORS)を有効にする必要があります。
—————————————————–
もう片方のアカウントで作成した S3 バケットへの操作権限を渡したい

->「バケットポリシー及びユーザーポリシーにて、もう片方のアカウントのアクセス許可を付与する」が正解です。別のAWSアカウントに自分が所有するS3バケットへのアクセス利用を許可したい場合、バケットポリシー及びユーザーポリシーの両方の許可設定が必要です。
—————————————————–
【EC2 インスタンス 間】のネットワークのレイテンシーを最小限に抑える
->クラスタープレイスメントグループ
—————————————————–
インスタンスが終了するとログが削除されます。システム管理者は障害が発生した根本原因を特定するためにログが削除されないようにする必要があります。

ー>統合 CloudWatch Logs エージェントをインストールすると、Amazon EC2 のログファイルを CloudWatch Logs にアップロードすることができます。
—————————————————–
数百万人のテレビ番組の視聴者が投票した結果を収集する
投票は、モバイルデバイスを使用し、リアルタイムで【集計】する必要
高パフォーマンスとシームレスな拡張性が必要となります。

ー>【Amazon DynamoDB】 の主な機能はデータを格納するデータストアのため正解です。また、耐久性があり、スケーラブルで、可用性の高いデータストアをリアルタイム集計を提供できます。

NG
「Amazon Kinesis」→Amazon Kinesis を使用してデータを一時的に保存できます。一方で、リアルタイムの集計では、【データストアに移動する必要がある】ため間違いです。
—————————————————–
開発者がAWSコンソールにアクセスできるために必要なAWSの機能

ー＞AD Connector、IAM ロール
-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 を発行することができます。
—————————————————–
S3 の API を呼び出し、オブジェクトの格納と読み込みを実施
アプリケーションからインターネットへのアウトバウンド通信の制限が必要
セキュリティポリシーを満たすために必要な設計

->「ゲートウェイ VPC エンドポイントを S3 用に作成し、アプリケーションからアクセスする」、
「インタフェース VPC エンドポイントを S3 用に作成し、アプリケーションからアクセスする」が正解
-VPC エンドポイントでは、AWS PrivateLink を使用する AWS のサービスや VPC エンドポイントサービスに VPC をプライベートに接続できます。
-VPCのエンドポイントには、インターフェース型とゲートウェイ型の2種類があり、S3 もエンドポイントはゲートウェイ型とインターフェース型(2021年2月リリース)があります。なお、ゲートウェイ型のエンドポイントは、S3 と DynamoDB の 2 つです。

プライベートサブネット上に S3 バケットは作成できません。また、同じリージョンに S3 バケットを作成しても、インターネット経由でのアクセスが必要となります。
—————————————————–
EC2インスタンスに付与できるタグの上限
->1リソースあたりにつけることが出来るタグの最大数は 50個まで
・キーは最大128 文字まで。
・値は最大256 文字まで。
また、大文字と小文字は区別されます。
—————————————————–
testB6
—————————————————–
EFSのファイルデータが増加した
どのようにしてコストを削減

->EFS ライフサイクル管理を有効にする
—————————————————–
S3バケット
403 Access Denied

->Amazon S3 アクセスコントロールリスト (ACL) では、バケットとオブジェクトへのアクセスを管理できます。
—————————————————–
EC2インスタンスは一般的なワークロードに対して利用され、その際に【複数のインスタンス間での通信】が多数発生
最も費用対効果の高いインスタンス構成

->【プレイスメントグループを設定した上で】、M5インスタンス群を起動する。
-M5 インスタンスは、さまざまなワークロード向けに、コンピューティング、メモリ、ネットワーキングリソースをバランスよく提供しています。

NG
-T3 インスタンスは、ベースラインレベルの CPU パフォーマンスを提供する次世代のバースト可能な汎用インスタンスタイプです。これは【クラスタープレイスメントグループによる設定ができない】インスタンスタイプです。
-【先にプレイスメントグループを構成した上で】、その中でインスタンスタイプとインスタンス数を設定することが必要です。
—————————————————–
データベースのバックアップは定期的に実施することで回復性を担保することが必要

ー>RDSを利用してOracleデータベースを起動して自動バックアップを設定することで、一定時間での定期的なバックアップ取得を実現します。

NG
RMANはOracle が作成したOracleデータベース用に提供されるバックアップおよびリカバリマネージャです。データベースのバックアップ、復元、および回復機能を提供し、高可用性と災害復旧の懸念に対処します。これを利用すればOracleデータベースのバックアップは自動化することができます。

NG
-AWSではRMANを利用したバックアップ設定は可能ですが、Amazon RDS は DB インスタンスへのシェルアクセスを提供していません。また、高度な特権を必要とする特定のシステムプロシージャやテーブルへのアクセスを制限しています。
-ライフサイクルポリシーによるバックアップはRDSでは設定できません。
—————————————————–
S3 リクエストに対する
HTTP 503 レスポンス

ー>ライフサイクル管理
HTTP 503 レスポンスとは「サービスが利用できない」ときに表示されるエラーです。バージョニングを有効にしたバケットに対して 当該エラーが発生してしまう原因は、数百万のバージョンを有する1 つ以上のオブジェクトが存在している可能性があります。
この問題を回避するためには、ライフサイクル管理の「NonCurrentVersion」有効期限ポリシーと「ExpiredObjectDeleteMarker」ポリシーを有効にして、以前のバージョンのオブジェクトを期限切れにすることです。
—————————————————–
RDS MySQLデータベースから毎週同じクエリ処理を行いデータを集計
Lambdaを連携したデータ集約関数を構築

ー>RDSプロキシを利用
Lambda関数はRDSエンドポイントではなくRDSプロキシを利用して接続することが求められます。RDSプロキシはLambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングします。これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用できます。 RDSプロキシを利用せず、エンドポイントを利用するとLambda関数によってコネクションが多数発生して処理が上手くいかなくなってしまいます。
—————————————————–
Redshiftデータベースのデータを確実に暗号化する

=>AWS Key Management Service (AWS KMS)
またはハードウェアセキュリティモジュール (HSM) のいずれかを使用

NG
-SSL/TSLは通信の暗号化に利用します。Redshift内のデータの暗号化には利用できません。
-CSEはクライアントサイド暗号化の略称です。Redshiftではサーバーサイド暗号化を利用します。
—————————————————–
オンプレミスのWEBサーバーとOracleデータベースを利用して構築
OracleデータベースをAWSに移行して、DBインスタンスに障害が発生した場合でもWebサイトが引き続き利用可能にする可用性

=>RDSにオラクルデータベースタイプのインスタンスを起動して、マルチAZを構成します。
この構成により、データベースサーバーに障害が発生した場合でもWebサイトの可用性を高めることが可能です。

NG
EC2インスタンスによるELBとAutoScalingによる構成だけでは、AZ障害には弱いため不適切です。
—————————————————–
testB2
—————————————————–
毎週定期的なタイミングでDynamoDBからセッションデータを取得して、レポート生成処理

->AWS Data Pipeline は、データの移動と変換を自動化するサービスです。AWS Data Pipeline はデータ駆動型のワークフローを定義して、タスクの正常な完了をトリガーにして、次のタスクを実行できます。AWS Data Pipeline はDynamoDBに設定することが可能であり、定期的なデータ取得タスクを設定させることができます。

NG
DynamoDBストリームを有効化することで、DynamoDBテーブルへのデータ登録や更新などのイベントをトリガーとして、Lambda関数などを実行して処理することができます。これにより、DynamoDBのデータを取得することも可能ですが、【定期的にデータ取得するような処理ではなく】、イベント起動になってしまうため、要件に合致していません。
—————————————————–
EC2インスタンスが【固有のプロファイル認証情報】を利用してRDS【データベースにアクセス】できるようにする必要があります。

ー>EC２インスタンスが【IAMデータベース認証】を利用してDB インスタンスにアクセスが可能です。この認証方法では、DB インスタンスに接続するときにパスワードではなく、認証トークンを使用します。認証トークンはAmazon RDS がリクエストに応じて生成する一意の文字列であり、AWS 署名バージョン 4 を使用して生成されます。各トークンには 15 分の有効期間があります。認証トークンは IAM を使用して外部的に管理されるため、ユーザー認証情報をデータベースに保存する必要はありません。
—————————————————–
オンプレミスネットワークとAWSの両方に、システムをホスト
Active Directoryの資格情報を使用して、全ユーザーが両方の環境のリソースにアクセスできる設定

ー>SAML（Security Assertion Markup Language）はインターネット上で、IDやパスワードなどの認証情報を連携するためのXMLベースの仕様です。SAMLは主にエンタープライズアプリケーション間の認証で使われています。SAMLはMicrosoft Active Directoryを使用しているため、AWSクラウドへのAPIアクセス用にSAMLベースのフェデレーションを設定できます。

NG
AWS OrganizationsにActive Directory機能はありません。
—————————————————–
【DBインスタンス】のプロセスまたはスレッドがCPUとメモリをどのように使用しているかを常時モニタリング

ー>RDSの拡張モニタリングを有効化することが必要です。これにより、DBインスタンスのOSのリアルタイムメトリックスが確認できるようになります。 RDSコンソールを使用してDBインスタンスのメトリクスを表示でき、CloudWatch Logsからの拡張モニタリングを利用することができます。 デフォルトでは、拡張モニタリングメトリクスは30日間CloudWatch Logsに保存されます。

NG
Amazon CloudWatchはデータベースインスタンスのCPU使用率を監視可能ですが、【デフォルトではRDSインスタンスの各データベースプロセスによって消費されるCPU帯域幅と合計メモリの割合が提供されません】。
—————————————————–
リソースの【プロビジョニング、負荷分散、オートスケーリング、監視、クラスターのコンテナ配置などのタスクを自動的に処理】することが求められています。

ー>AWS Elastic Beanstalk はECSなどのDocker サービスと連携して、【容量のプロビジョニング、負荷の分散、スケーリング、およびアプリケーションの状態の監視の詳細を自動化】することができます。

NG
ECSはDocker形式でのアプリケーション開発環境を構築することができるオーケストレーションサービスです。これを利用してAWSリソースの展開は可能ですが、【リソースのプロビジョニング、負荷分散、オートスケーリング、監視、クラスター全体でのコンテナ配置などのタスクの自動化にはElastic Beanstalkとの連携が必要】です。
—————————————————–
EC2インスタンスを利用して、社内業務システム
【社内サーバーの稼働状況ログ】を取得

ー>EC2インスタンスのデフォルトメトリクス以外の詳細なログ情報を取得するためには、CloudWatchの２つのサービスを利用する必要があります。
１つは【CloudWatchエージェント】です。このエージェントを対象のEC２インスタンスにインストールすることで、CloudWatchによりサーバー内部の詳細なログが取得できるようになります。
2つ目のサービスは【CloudWatch Logs】です。CloudWatch Logsは取得したログを集約することができ、EC2インスタンスのログ管理を実施することができます。

NG
AWS CloudTrail は、AWSアカウントの【ガバナンス、コンプライアンス、運用監査、リスク監査】を行うためのサービスです。AWS CloudTrail を利用してEC２インスタンスのログは取得できません。
—————————————————–
【一時的に】セッションデータ処理量が大きくなっており、DynamoDBのスループットが低下している
コスト最適な対応方法

ー＞DynamoDBの【Auto Scaling】を導入して、テーブルとグローバルセカンダリインデックス（GSI）の容量増加を自動化できます。DynamoDB Auto Scalingはテーブルとインデックスを監視して、アプリケーショントラフィックの変化に応じて自動的にスループットを調整します。 これにより一時的な負荷増加に対して、DynamoDBテーブル処理パフォーマンスの管理が容易になり、アプリケーションの可用性を最大化しつつ、DynamoDBのコストを削減することができます。

NG
-DynamoDBはそのままでは【リードレプリカを増やすことができません】。後述するDAX を有効化することで、DAXクラスターは、1 つのみのプライマリノードと、0～9 個のリードレプリカノードを構成することができます。
-DynamoDB Accelerator(DAX) を有効化することで、DynamoDBテーブルはミリセカンドからマイクロセカンドへの最大 10 倍のパフォーマンス向上を実現します。DAXはキャッシュを利用しているため特定のデータへの処理が高い場合などに【中長期的】な性能向上のために対策としては正しいです。しかしながら、【キャッシュDBは高コスト】であるため、コスト最適という要件に合致させるためには、本件ではAuto Scalingによる処理負荷に対するスケーリングを優先して実行します。
—————————————————–
ECSで【トラフィックを制御】することが必要です。

Amazon 【ECS はELBのいずれかのタイプのロードバランサ―を使用できます】。Application Load Balancer は、HTTP/HTTPS (またはレイヤー 7) トラフィックをルーティングするために使用されます。Network Load Balancer と Classic Load Balancer は、TCP またはレイヤー 4 トラフィックをルーティングするために使用されます。

NG
FargateはECSのコンピュートエンジンとなる起動タイプの１つです。これはEC２インスタンスの代わりに利用されるものであり、設定を自動化することができます。これは【ECSのトラフィックを制御するためには利用されません】。
—————————————————–
WEBアプリケーションのプロビジョニング方式を簡易にする仕組み
Auto Scalingを適用
Docker
アプリケーションのバージョン管理や状態の監視の詳細を自動化

ー>AWS Elastic BeanstalkはELBと Auto Scalingを利用してスケーラブルのデプロイを自動化することが可能です。また、AWS Elastic Beanstalkはアプリケーションのバージョン管理を自動化することもできます。AWS Elastic BeanstalkはAmazon ECSなどのDockerにホストされたWEBアプリケーションの展開もサポートしています。
—————————————————–
レガシーアプリケーションは【マルチキャストネットワーキングに依存】しており、
AWSで確実に起動させるための特別な設定

このレガシーアプリケーションは【マルチキャストネットワーキングに依存】しており、AWSで確実に起動させるためには、【仮想オーバレイネットワークをインスタンスのOSレベルで起動させること】が求められます。したがって、レガシーアプリケーションを移行するためにオーバーレイマルチキャストを使用することが必要となります。 オーバーレイ・マルチキャストとは，クライアント・パソコンにインストールしたアプリケーション・ソフトでマルチキャスト（1対多通信）を実現する技術です。

NG
VPC拡張ルーティングはRedshiftの機能です。今回の要件には無関係です。
—————————————————–
Redshiftクラスターのデータフローを厳密に管理することでセキュリティを向上
Redshiftクラスターのすべての【COPYおよびUNLOADトラフィックを監視】することです。

ー>Redshiftクラスターに対する【拡張VPCルーティングを有効】にすることで、VPCに出入りするRedshiftクラスターのすべてのCOPYおよびUNLOADトラフィックを監視することができます。
Redshiftは拡張VPC ルーティングを使用すると、Redshift はクラスターとデータリポジトリ間のすべての COPY と UNLOAD トラフィックがVPC を通るよう強制します。
—————————————————–
ローカルストレージ上のTB規模のデータセットに対して順次読込と書込アクセスを必要とするワークロード

ー＞ストレージ最適化インスタンスは、ローカルストレージ上の非常に大きなデータセットへの高負荷な読込処理および書込処理を必要とするワークロード用に設計されています。これらは、毎秒数万の低遅延のランダムI / O（IOPS）をアプリケーションに提供するように最適化されています。
—————————————————–
test
—————————————————–
—————————————————–
複数のコンポーネントを含む大規模な標準化されたアーキテクチャを複数回構築する
リソースのプロビジョニングを自動化する方法

->CloudFormationを使用するとテキストの記述内容に従い、必要なリソースを全リージョン / アカウントにわたって作成できます
NG
・Elastic Beanstalkは、Webアプリケーションの構築と管理を支援するPaaSサービスです。
・AWS OpsWorksは、非常に動的なアプリケーションを構築および運用し、変更を即座に伝達するのに役立つ構成管理サービスです。
・AWS CodeDeployは、Amazon EC2インスタンス、オンプレミスのインスタンス、AWS Lambda関数など各種アプリケーションの展開を自動化するサービスです
—————————————————–
2週間稼働する必要がないAmazon EC2インスタンスのコストを節約する
Amazon EC2インスタンスをシャットダウンして再開してもデータが存在できる方法

->インスタンスを休止状態にすると、メモリの内容が Amazon EBS ルートボリュームに保存されます。インスタンスが再起動すると、メモリの内容が再ロードされます。
—————————————————–
予期せぬアクセス集中に耐えるための施策

->予期せぬアクセス集中にはAmazon Cloudfrontが有効となります。
CloudfrontはCDNサービスであり、オリジンサイト（本来のサイト）ではなくキャッシュサーバがリクエストに応答します。そのため、オリジンサイトはアクセスをアクセス集中を避けることができます。

NG
Auto Scalingという選択肢も、アクセス集中には有効ですが、CPUが90%を超えた場合など、何かのトリガーをきっかけにスケールするため、急なアクセス集中に対応することはできず、一時的にシステムがダウンしてしまうかもしれません。
—————————————————–
各Webサーバはセッション情報を保持しないようにする必要
利用するサービスとして【間違っているもの】

ー>ELBはロードバランサーのサービスのため、ログイン情報をステートレスに保持することはできず誤りとなります。
—————————————————–
障害による停止時間を減らすために、
特定の箇所にユーザーのアクセスを誘導する方式

ー>AWS Globel Accelerator は、世界中の顧客に提供するアプリケーションの障害による停止時間の割合と応答性能を改善するネットワークサービスです。AWS に構築したアプリケーションに対して、ユーザーアクセスの誘導先として使用する固定のエンドポイントを用意し、静的 IP アドレスを付与することでグローバルなアクセスの管理を簡素化します。
—————————————————–
本番環境のインスタンスを誤って削除させないようにする最適な方法

「インスタンスに本番環境用の識別タグを付けします。本番タグでインスタンスへの 削除す る API 呼び出しを明示的に拒否して、従業員にリソースレベルのアクセス権限を追加します。」
「インスタンスに本番環境用の識別タグを付けします。開始、停止、再起動の API 呼び出しのみを許可し、インスタンスを削除する呼び出しを禁止します。」

NG
「ユーザーの IAM ポリシーを変更して、EC2 インスタンスを削除する前に MFA を要求します。」
→MFA はユーザーがインスタンスを削除することを防ぐことができないため間違いです。セキュリティの追加レイヤーを追加するだけです。
—————————————————–
AWS CLIを利用するために必要な権限情報

ー>AWS CLIで操作する対象サービスの操作権限を付与された【IAMロール】
AWS CLIを利用するために必要なものです。
・対象サービスの操作権限が付与された【IAMロール】
・もしくは【アクセスキーとシークレットアクセスキー】
セキュリティの観点からアクセスキーでの認証より、IAMロールでの認証の方が適切と言えます。
—————————————————–
マイクロサービス間連携の仕組み

ー>マイクロサービス化されたコンポーネント間の処理を連携するにはSQSを利用したポーリング処理が最適となります。

NG
「最初の処理結果が完了するとSNSがイベント通知して、EC2インスタンスが処理を継続する。」は不正解です。SNSもメッセージング通知によって、前の処理イベントをトリガーとしてイベント通知処理による連携を実施することができます。しかしながら、コンポーネント処理間の連携を確実に実行するには並列処理による負荷分散が可能なSQSが最適です。SNSはイベント通知を起点としたトリガーとして利用し、【実処理はSQSに連携してポーリングするというのが標準】的なAWSでのアーキテクチャ構成となります。
—————————————————–
この単一のAZの障害が発生し、サービスが停止するトラブルが発生しました。
可用性を確保する方法を次の中から2つ

ー＞「EC2インスタンスを別AZに起動して、ELBターゲットをAZを跨いで設定する。」
「AutoScalingのスケーリンググループを複数のAZを跨いで構成する。」

NG
「EC2インスタンスを別AZに起動して、Route53によりフェールオーバールーティングを設定する。」は不正解です。Route53によりフェールオーバールーティングを設定することは可能ですが、これは2つのEC2インスタンス間でのフェールオーバー構成を実施することしかできません。今回は【ELBで複数インスタンス間でのトラフィック分散】を実現することが最適な構成となります。
—————————————————–
AWS CloudFront でオリジンサーバとして設定できるもの

ー>選択肢の全て
CloudFrontのオリジンサーバは、以下の３種類に分類することができます。
オリジンサーバとは、コンテンツを配信する元となっているサーバのことです。
①S3オリジン（バケット）
②S3オリジン（静的ホスティング）
③カスタムオリジン（カスタムオリジンとは一般的なWebサーバでありパブリックとプライベートの両方を扱うことができます。）
—————————————————–
Cloudwatch Logsのログを【Lambdaへ連携する】場合、最適な機能・サービス

ー>Cloudwatch Logsの【サブスクリプション機能】を利用すると、Lamdaへログを連携することができます。
これにより特定のログが発生した場合に、Lambda関数で処理を実行するような構成を実装することができます。
—————————————————–
SQS を使用する際に【空の受信レスポンス】が大量に発生

ー>【ロングポーリング 】を使用すると、【すぐにメッセージを受信】できるようなり、不要なネットワークの負荷を軽減することができます。
■Amazon SQS ショートポーリングとロングポーリング
キューからのメッセージを処理するプロセスは、ショートポーリング使用するか、ロングポーリングを使用するかによって異なります。Amazon SQS はデフォルトでショートポーリングを使用して、サーバーのサブセットに対して(重み付けされたランダム分散に基づいて) クエリを実行し、利用できるメッセージがあるかどうかを調べます。ロングポーリング を使用すると、キューが到着するとすぐにメッセージを受信できるようになります。
—————————————————–
CloudTrail ログを監査のために有効
このログは暗号化し、ログが改ざんされていないかを確認する必要があります。

->
CloudTrail は、デフォルトで、S3 のログを暗号化します。
CloudTrail ログファイルの整合性の検証を有効にします。
Amazon S3 に保存されている CloudTrail ログはサーバー側の暗号化を使用することができます。また、CloudTrail は、ログが改ざんされていないかどうかを検証する機能もあります。
—————————————————–
Application Load Balancer（ALB）のアクセスログをログファイルとして保存し、
ホストされたHadoopサービスを使用して処理

ー>ALBのアクセスログをS3バケットにデータを保存するように構成できます。
EMRは、Amazon EC2およびAmazon S3で構成された【Hadoopフレームワーク】を利用します。

NG
・ALBのアクセスログをDynamoDBに配信するように設定することはできないため不正解です。
—————————————————–
1時間ごとに【複数】AZの 【EC2 インスタンス】によって分析及び更新
リリース後6ヶ月間はデータ量が増加し続けると予想

ー>Amazon EFS ファイルシステムを作成し、データを格納。アプリケーションが動作する EC2 インスタンスで NFS マウントする
EFS は複数リージョンの【複数 EC2 インスタンスから同時にマウント】でき、各 EC2 インスタンスからの【同時データ処理】に適しています。

NG
S3 標準 – IA クラスでの格納も、アクセス頻度の少ないデータに適用されるものとなるため、今回の条件を満たしているとは言えません。
—————————————————–
データベースには、DynamoDBを利用 
一時的な集中アクセスが発生した場合にもデータベースへの書込処理能力が落ちないようにする

ー＞
-SQSを使用するとクラウドアプリケーションのコンポーネントを分離して調整することが簡単で費用対効果が良くなります。SQSを利用することで、キューイングによってDynamoDBへの処理負荷を下げることができます。
-DynamoDBにAuto Scalingを適用し、一時的なアクセス集中に対応できるように構成する。も正解となります。DynamoDBにAuto Scalingを設定することで、一時的な負荷に対して処理性能をスケーリングすることで高負荷に対応することができます。
—————————————————–
2 つのパブリックサブネットと 2 つのプライベートサブネットを含むAmazon VPC
EC2インスタンスに外部のインターネットからアクセスすることができません
EC2インスタンスはプライベートサブネットで起動しており、Webサービス（80ポート、443ポートを利用）を実行しています。

->「パブリックサブネットにApplication Load Balancer を起動し、エンドポイントにEC2インスタンスを設定します。外部の DNS 解決が Application Load Balancer に向けられるようにします。」
インターネットに面した Application Load Balancer は、ALB を指す外部 DNS を使用して、基盤となる EC2 インスタンスを公開するのに役立ちます。
—————————————————–
作成済みのAuto Scalingグループに既存のEC2インスタンスをアタッチしたい
アタッチ対象の EC2 インスタンスが満たす必要のない条件

ー>「アタッチ対象の EC2 インスタンスがアタッチ先の秘密鍵を保持していること」が正解（条件として当てはまらない）となります。

アタッチするインスタンスは次の条件を満たす必要があります。
・インスタンスが running 状態であること。
→「アタッチ対象の EC2 インスタンスが実行状態であること」は正しい条件となります
・インスタンスの起動に使用する AMI が引き続き存在していること。
→「アタッチ対象の EC2 インスタンスのAMIが存在すること」は正しい条件となります
・インスタンスが他の Auto Scaling グループのメンバーではないこと。
→「アタッチ対象の EC2 インスタンスが別のAuto Scalingにアタッチされていないこと」は正しい条件となります
・インスタンスは、Auto Scaling グループで定義されているいずれかのアベイラビリティーゾーンに起動されます。
・Auto Scaling グループにアタッチした標準ロードバランサーがある場合、インスタンスとロードバランサーが両方とも EC2- または同じ VPC にあることが必要です。Auto Scaling グループにアタッチしたターゲットグループがある場合は、インスタンスおよびロードバランサーは両方とも同じ VPC にあることが必要です。
—————————————————–
サーバを構築することなく
SQLクエリを使ってS3に格納されたデータを分析する

ー>Amazon Athenaを使用すると、SQLを使用して【Amazon S3のデータを対話的に分析する】ことができます。Athenaは【サーバーレス】のサービスであり利用者がサーバを管理する必要はありません。利用料金はクエリ実行に対してのみ課金されます。

NG
・Amazon RedShiftは大量のデータ分析に使用するサービスですが、S3のデータを分析することはできません。
—————————————————–
ELBがEC2インスタンスが異常であると判断し接続は削除しましたが、インスタンスは起動したままで終了されていないことがわかりました。

ー>「ELBヘルスチェックタイプがASGに選択されていないため、インスタンスがELBによって異常であると判断され、サービスから削除されたことを認識しないため」
・ELBを使用する場合は、AutoScalingの設定でELBヘルスチェックを有効にするのが最善の方法です。
ELBヘルスチェックを有効にしない場合、EC2ステータスチェックはELBが正常でないと判断したインスタンスも正常であると判断してしまいます。
この場合インスタンスはELBによってサービスから削除されますが、Auto Scalingによって終了されず起動されたままとなります。
—————————————————–
本番、開発、検証の3つのVPCを構成
検証VPCは開発VPCと本番VPCの両方にピアリング接続
プログラムのリリースを開発環境から本番環境に移行するための時間を短縮することを検討しています。

ー>「適切なルートとともに開発と本番の間に新しいピアリング接続を作成する。」
AWSのVPCの仕様（制約）により、 VPCまたぐ通信はできません。つまりVPC(開発)とVPC(本番)は VPC(検証)を経由して相互に直接トラフィックを送信することはできないため、「開発VPCに本番VPCへの適切なルートテーブルの設定変更を行う。」は不正解です。 VPC(開発)と VPC(本番)の間で直接トラフィックをルーティングするには、両者間にピアリング接続を作成する必要があります。
—————————————————–
オンプレミスとAWS間のVPN 接続
VPN 接続状態（アップまたはダウン）を監視する必要

ー>AWS VPN のステータスを、CloudWatch のメトリクスデータでモニタリングできます。VPNの状態は、CloudWatch メトリクスの 【TunnelState】 のブール値として定義されています。ブール値が 0 の場合はトンネルがダウン状態、1 の場合はトンネルがアップ状態であることを示します。
■補足:VPN トンネルでは、他にも次のメトリクスを使用できます。
TunnelDataIn：VPN トンネルを介した接続の AWS 側で受信したバイト数。
—————————————————–
レスポンス遅延が報告されており、原因はアクセスの集中

ー>「Multi-AZ デプロイメントの Amazon Aurora (MySQL) のクラスターを構築し、複数のリードレプリカを保持する。 また、リーダーエンドポイントを作成し、レポート表示の処理時はこれを利用する」

今回レポートの表示（データの読み取り）がアクセス過多のため遅延を引き起こしているため、複数のデータベースで処理できるよう、Aurora の【リードレプリカ】と【リーダーエンドポイント】機能の利用が適しています。
—————————————————–
非常に読み取り処理が多い、
サイズの小さいデータベース用
【オンライントランザクション処理(OLTP)】

->OLTP の要件には、継続的な高スループットのIOPS SSD が推奨されており、【プロビジョンド IOPS SSD (io1)】が適しています。
—————————————————–
中央ロギングによる運用管理

->【VPCフローログ】を有効化することで、EC2インスタンスとネットワークインターフェイスとの間で行き来する IP トラフィック情報をキャプチャできます。このデータをCloudWacthなどで集約することで、ログの中央管理が達成できます。
-EC2インスタンスのログファイルおよび VPC フローログをキャプチャしていく必要があります。【CloudWatchエージェント】を使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集することができます。これにより、ログの中央管理が達成できます
—————————————————–
異常が発生しているインスタンスへのトラフィックを回避する
異常が発生していない場合は、冗長化されたアプリケーション構成を平等に利用する

ー>「Route53のフェールオーバー設定のアクティブ／アクティブ構成」によって、レイテンシールーティングなどのルーティングポリシーを利用してフェールオーバーを構成することができます。

NG
Route 53 を使用して DNS フェイルオーバーを設定するには、作成するレコードのタイプ (加重エイリアス、フェイルオーバー、レイテンシーなど) をノードごとに指定します。つまり、【フェールオーバールーティングではないルーティングポリシーにもフェールオーバーを設定することが可能】です。
—————————————————–
ELBのヘルスチェックが異常を示しているにも関わらず、Auto ScalingによるEC2インスタンスの起動が実行されていません。

ー>「Auto ScalingでELBのヘルスチェックを利用する」
Auto Scalingは起動したインスタンスに対して、定期的なヘルスチェックを実行します。このへルスチェックにはEC2タイプとELBタイプの2つのタイプがあります。

EC2タイプでは、EC2のステータスがrunning以外の場合、またはシステムステータスがimpairedの場合に、このインスタンスを異常と判断します。

ELBタイプでは、インスタンスのステータスチェックとELBのヘルスチェックからインスタンスの状態を判断します。

したがって、【Auto ScalingがEC2タイプのヘルスチェックを利用していると】、ELBのヘルスチェックが異常を示しているにも関わらず、EC2インスタンス側のステータスの問題がなければ【Auto Scalingが実行されません】。
—————————————————–
Docker
プロビジョニングやスケールなどの設定が不要な方式
最も自動化を達成できうるコンテナサービスの組合せ

->「Amazon EKS＋Fargate」
以前は、Amazon EKSとFargateの組合せは利用できませんでしたが、2019年12月より、AWS Fargate の上でKubernetesを利用できるようになりました。Amazon EKS と Fargateはインスタンスのプロビジョニング設定などを自動で構成してくれるため、AWS 上での Kubernetes ベースのアプリケーション開発やその管理を一定程度自動化してくれます。したがって、【ECSとFargateの組合せよりも Kubernetesを利用することで、より自動化を達成することが可能】です。
Fargate はコンテナを実行するために仮想マシンのクラスターをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、クラスターをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。
—————————————————–
サーバレスアーキテクチャを社内で新規採用して、
AWS Lambda、API Gateway、およびDynamoDBを単一のスタックで構成

->【AWS SAM】は、サーバーレスアプリケーション構築用のデプロイツールです。YAMLを使用して、サーバレスアプリケーションのLambda関数、API、データベース、イベントソースマッピングをモデリングします。AWS SAMはCloudFormationと連携してサーバレスアプリケーションを展開します。その際は、SAM が SAM 構文を AWS CloudFormation 構文に変換および拡張することで、サーバーレスアプリケーションの構築を高速化することができます。

NG
AWS Database Migration Service を使用すると、オンプレミスにあるデータベースを短期間で安全に AWS に移行できます。今回の要件には利用できません。

AWS Server Migration Service は、オンプレミスの VMware vSphere、Microsoft Hyper-V/SCVMM、または Azure 仮想マシンの AWSに移行するツールです。今回の要件には利用できません。

Amazon SWF はステップまたは連続したステップがあるバックグラウンドジョブを構築、実行、スケールすることができるクラウド内の完全マネージド型の状態トラッカーおよびワークフローシステムです。今回の要件には利用できません。
—————————————————–
デフォルトで保存データを暗号化しているサービス

ー＞【AWS Storage Gateway】と【Amazon Gracier】です。
AWS Storage Gatewayによって保存されたすべてのデータは、デフォルトでAmazon S3管理暗号化キー（SSE-S3）を使用してサーバー側で暗号化されます。

Amazon Glacierはデフォルトで保存データを暗号化し、SSLによる安全なデータ転送をサポートします。
—————————————————–
403エラーが発生して、HTMLが表示されませんでした。

->「バケットポリシーを設定する。」
S3バケットの静的WEBホスティングにおいてHTMLオブジェクトにアクセスする際にオブジェクトの読み取りアクセス許可が付与されていない場合は、ウェブサイトエンドポイントから HTTP レスポンスコード 403 (Access Denied) が返されます。

静的WEBホスティングを利用するためには、S3静的ウェブホスティング機能を有効化します。次にIndex.htmlを設定することでWEBサイトの設定が完了します。しかしながら、加えてインターネットからのアクセスが許可されるアクセス管理設定が必要となります。
したがって、【パブリックアクセスブロックの無効化】することと、【バケットポリシーの設定】により、インターネットからのバケットへのs3:GetObject を設定する必要があります。

NG
【パブリックアクセス許可設定を有効化するのではなく】、【パブリックアクセスブロックの無効化】する設定が必要です。
—————————————————–
TCPプロトコルに依存するアプリケーション

->クラシックロードバランサは、
HTTPやHTTPS以外の【TCPプロトコル】上で動作するプロトコルにも対応することができます。

NG
アプリケーションロードバランサは、HTTP / HTTPS トラフィックの負荷分散
—————————————————–
RDS MYSQLデータベースから定期的にデータを集計して、自動的にレポートを生成するタスクを実装
Lamdba関数を用いて実装

ー>「RDSプロキシを利用し、データベースに流れるトラフィックを処理する。」
RDSプロキシは、Lambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングします。これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用できます。

NG
「Lambda関数をSQSによるポーリング処理と連携してRDSへのデータ処理を行う。」は不正解です。Lambda関数だけで処理分散化が可能であるため、SQSポーリング処理と連携してRDSへのデータ処理を分散化するといった構成は非効率です。
—————————————————–
オンプレミスのデータセンタとAWSが接続されているハイブリッドグラウド環境
コスト効率が良く高可用性・高パフォーマンスな接続が出来るソリューション

ー>「Accelerated サイト間 VPN を利用する。」

NG
「VPCエンドポイントを利用する。」は不正解です。VPC エンドポイントは、AWS PrivateLink がサポートされている AWS サービスや VPC エンドポイントサービスに VPC をプライベートに接続できます。これはAWS内部のリソース間接続用の仕組みであるため不正解です。
—————————————————–
負荷テスト中に、AWS KMSリクエストが1秒あたりの制限を超えてしまい、エラーとなってしまいました。
暗号化のベストプラクティスに基づく最適な改善方法

->「AWS暗号化SDKを使用する方法」

NG
「AWS KMS SDKを利用する方法」は不正解です。
AWS KMS SDKといったツールキットはありません。
—————————————————–
常にCPU使用率が約100％

->【CloudFront】を利用することでエッジロケーションにコンテンツをキャッシュし、利用者がアクセスした際には物理的に最も近いエッジロケーションから応答します。これにより、オリジンとなっているEC2インスタンスへのアクセス負荷を軽減することができます。
—————————————————–
約10％は最初の3日間に1回アクセスされますが、30日後にはほとんどアクセスされません
月次報告書は保持し続ける必要

->「Amazon S3 【標準 低頻度アクセス】のストレージクラスに月次報告書をアップロードします。バケット上にライフサイクル設定を設定して、
30 日後に月次報告書を Amazon S3 【Glacier】 に移行します。」
Amazon S3 標準報告書の約 10 %は最初の 3日間に 1 回アクセスされるため、必要に応じてすぐにアクセスできる必要があります。Amazon S3 Glacier はアクセスまできるまで時間がかかるため一時保管として適しません。また、Amazon S3 標準 低頻度アクセスのストレージクラスはすぐにアクセスできますが、取り出し料金が GB あたり発生します。30 日の保管期間があるため S3 標準 よりもS3 標準 低頻度の方がコスト面で有利です。
—————————————————–
EC2インスタンスにアクセスキーを持たせてDynamoDBにアクセス
よりセキュアに改善

->「そのテーブルにアクセスする権限を持つ IAM ロールを作成し、そのロールを使用してすべてのインスタンスを起動する。」
アクセスキーを使うと、誰でも同じレベルのリソースにアクセスできてしまいます。そのため長期的に有効なアクセスキーではなく、一時的な認証方法であるIAMロール割り当ての方がよりセキュアとされています。
—————————————————–
ボリュームを暗号化するための手順

ー>「(1)暗号化されていないボリュームのスナップショットを作成する。 (2)スナップショットをコピーし、暗号化したスナップショットを作成する。 (3)暗号化されたスナップショットからボリュームを作成する。」
スナップショットを作成する手順を踏むことでボリュームを暗号化することができます。暗号化されていないボリュームを直接暗号化することはできません。
暗号化されたスナップショットは、AWSマネジメントコンソールでも作成できますし、AWS CLIを使ってスナップショットのコピーコマンド（ec2 copy-snapshot）に「–encrypted」オプションを渡す方法でも作成することができます。
—————————————————–
万が一 EC2 が停止した場合にも単独で再実行できるように作られています。

ー>「スポットインスタンス を選択する」が正解です。スポット
インスタンスは AWS の予備リソースを使用して起動でき、リソース状況によっては中断されてしまう可能性のある購入オプションです。一方でオンデマンドインスタンスと比較し、最大 90% オフの節約が可能です。また、今回のアプリケーションのように、単独で実行される（ステートレス）かつ、停止した場合でも再実行で整合性を保証できる（フォールトトレラント）、柔軟性の高いアプリケーションに適しています。
—————————————————–
責任共有モデル　ユーザの責任範囲

ー>「アカウントによる権限管理」
我々AWS利用者は、
データの管理 (暗号化を含む)、
アセットの分類、
IAM を利用した適切な権限の適用
について責任を負います。
—————————————————–
ウェブサーバーのイメージの 【AMI ID を使用して起動設定】を作成します。
新しく作成された起動設定と、複数のアベイラビリティーゾーンを使用した 2 つのウェブサーバーの希望する容量を使用して、
【Auto Scaling グループ】を作成します。
【ALB】 を使用して Auto Scaling グループ全体でトラフィックをルーティングします。
—————————————————–
OUに対しては、FullAccess権限
DynamoDBへの全権限は拒否

->「DynamoDB以外の操作が全て実施できる。」
デフォルトでは「FullAWSAccess」が付与されている場合、全リソースに対する全操作が明示的に許可されている状態となります。そこに、【ブラックリスト形式】で特定の操作を拒否すると、【対象リソースの操作が拒否】されるものの、【その他のリソースについては「FullAWSAccess」が維持】された状態となります。つまり、DynamoDB以外の操作が全て実施できることになります。
—————————————————–
ログを蓄積し、分析する仕組み

->「Kinesis Data Firehoseを利用してS3にログを蓄積し、Athenaを利用してログ解析を行う組み合わせ」
Amazon Kinesis Data Firehose は、アクセスログなどのストリーミングデータを各種データストアにロードできます。蓄積場所としてはAmazon S3、Amazon Redshift、Amazon Elasticsearch Service、Splunk などがあり、設問の要件では大量ログをコスト効率よく蓄積するためS3を選択することが最適です。

NG
Lambdaを利用してS3にログを蓄積することも実装次第では可能ですが、専用サービスであるAmazon Kinesis Data Firehoseを利用する方が効率的です。
—————————————————–
AmazonSQSキューを使用して、EC2インスタンスにデータを配信
AWSのアーキテクチャを利用して配信データをアーカイブする

->[データを S3 バケットに記録する Lambda 関数に加えて、Amazon SNS トピックを使用してデータを SQS キューに展開します。]
SNS を使用して Lambda と SQS の両方に拡散できます。Lambda はデータのアーカイブに役立ち、EC2 インスタンスを変更せずに同じ SQS キューからのデータを処理できます。
—————————————————–
プライベートサブネットとパブリックサブネット

->[サブネットのルートテーブルを確認する。これにインターネットゲートウェイ(0.0.0.0/0)への経路が追加されているかいないかで判断する。]
—————————————————–
AWSアカウントの全てのリソースのAPI呼び出しの証跡を確認

->AWS CloudTrail
CloudTrailを有効にすると、AWS全体のAPI呼び出しに関連するイベントの履歴を記録できます。この履歴を利用することで、AWSアカウント上での操作を追跡することができ、セキュリティ分析やリソース変更等の操作を確認することができます。

NG
Amazon API Gateway
—————————————————–
他の部門のリソースとを分けて管理したい
ITガバナンスとコストの監視を行える仕組み

->
[AWS 一括請求を使用して、部門のAWSアカウントを親企業の【マスターアカウント】にリンクする。]
[部門のAWSアカウントのすべての企業 IT 管理者に対して IAM 【クロスアカウントアクセス】を有効にする。]

NG
・「企業の AWS アカウント内の部門ごとに個別の VPC を作成する。」
→個別の VPC を作成するだけでは、追加のタグ付けとセキュリティ管理が必要になり、コスト監視ができないため間違いです。
—————————————————–
マイクロサービス型の【分散システム】
マイクロサービス1の処理後にマイクロサービス2に処理が引き渡されます。
マイクロサービス間【連携】

->[マイクロサービス1からSQSによるキューイング処理を用いて、マイクロサービス2に連携する。]

NG
「マイクロサービス1からSNSによるメッセージ通知を用いて、マイクロサービス2に連携する。」は不正解です。SNSもメッセージング通知によって、前の処理イベントをトリガーとしてイベント通知処理による連携を実施することができます。しかしながら、【コンポーネント処理間の連携を確実に実行するには並列処理による負荷分散が可能なSQSが最適】です。SNSはイベント通知を起点としたトリガーとして利用し、実処理はSQSに連携してポーリングするというのが標準的なAWSでのアーキテクチャ構成となります。

—————————————————–
低レイテンシーかつ高スループットな【ブロックストレージ】

->「Amazon EBS ボリュームを利用する」
【ブロックストレージ】としては、【EC2 インスタンスストア】 と 【EBS ボリューム】の 2 つがありますが、EC2 インスタンスストアは EC2 インスタンスが停止してしまうとデータ損失が起こるなど一時的な利用のみが推奨されています。一方で、EBSボリュームについては、SSD も選択でき、低レイテンシーかつ高スループットが期待できる EBS 最適化インスタンスと併せて利用することも可能です。なお、Amazon EFS はファイルストレージで、S3 はオブジェクトストレージとなります。
—————————————————–
AWSに移行後は、Amazon 　【EBSに保存されたデータを暗号化】する

ー>「AWS の管理キーで【暗号化された EBS ストレージボリューム】を使用します。」
Amazon EBS 暗号化 は、EBS ボリュームのために、独自のキー管理インフラストラクチャの構築、管理、および保護を必要としない、簡単な暗号化ソリューションを提供します。【暗号化された EBS ボリューム】を作成し、サポートされるインスタンスタイプにアタッチする場合、以下のタイプのデータが暗号化されます。
・ボリューム内の保存データ
・ボリュームとインスタンスの間で移動されるすべてのデータ
・ボリュームから作成されたすべてのスナップショット
・それらのスナップショットから作成されたすべてのボリューム
暗号化オペレーションは EC2 インスタンスをホストするサーバー上で実行され、インスタンスとそれに接続された EBS ストレージ間でのデータの保存と転送中のデータの両方のセキュリティを保証します。

NG
「AWS Key Management Service を使用し、暗号化されたデータを Amazon S3 に移動します。」
→Amazon S3 は要件と異なるため間違いです。
—————————————————–
オンプレミスのシステムをAWSに移行するにあたり、最も速く実現できるサービス

ー>AWS SMS(Server Migration Service)が正解となります。
SMSは数千のオンプレミスのソフトウェアを従来よりも簡単に、かつ短時間で AWS に移行できるサービスです。プログラムによる監視を必要とせず、停止せずにサーバーの増分複製の自動化、スケジュール設定、および追跡が可能なため、大規模なサーバーの移行作業を簡単に調整できます。

NG
・AWS DMS（AWS Database Migration Service）
一般的に利用されている商用・オープンソースのデータベースとの間でデータを移行するために使用されます。
・AWS ADS（AWS Application Discovery Service）
オンプレミスサーバーのAWSへの移行計画を作成するときにサーバーの設定データ、使用状況データ、動作データを検出するために使用されます。
・Snowball
大量データを移行する際に利用するサービス機器です。
また、AWS SMSは移行プロセス中に使用したストレージリソースの分を除き、無料です。
—————————————————–
APIを呼び出すLambda関数の作成

->「すべての Amazon RDS インスタンスのリストを表示する権限を持つ IAM ロールを作成して Lambda 関数ヘアタッチします。」
IAMロールとは、ユーザーやグループではなく、EC2などのAWSのサービスや他のアカウントに対してにAWS の操作権限を付与するための仕組みです。
Lambda 関数に Amazon RDS インスタンスをリストを表示させる権限を持つ IAM ロールを割り当てる必要があります。

NG
「IAM アクセスキーとシークレットキーを作成し、Lambda 関数に保存します。」
→アクセスキーの使用は推奨されないため間違いです。
—————————————————–
ほとんどのユーザーが、特定のユーザーグループに属しながら自分のパスワードを変更する機能を制限する最良の方法

->「ユーザーが自分のパスワードを変更できないようにIAM【パスワードポリシー】の設定を変更します。ユーザーが自分のパスワードを変更し、特定のユーザーグループに【アタッチ】できる【IAMポリシー】を作成します」
・パスワードの長さや複雑さなどを強制するための【パスワードポリシー】を定義できます（すべてのユーザーに適用）。
・パスワードを変更する機能を制限する【IAMポリシー】をユーザーを含むグループに【アタッチ】する必要があります。

NG
・IAMロールを使用してこの機能を実行することはできません。
・AWS STSは一時的なAWSリソースへのアクセスの都度、動的に一時的な認証情報を発行するサービスです。IAMユーザーのパスワードポリシーの制御には使用されません。
—————————————————–
ウェブサイトのDNSレコードは、Amazon Route 53 で設定
ドメインのDNSレコードは、 Application Load Balancer (ALB)を指定
WEBサイトにアクセスできない際に、バックアップ用の静的エラーページに誘導する

->[Route 53 アクティブ/パッシブフェイルオーバー設定を使用します。Route 53 ヘルスチェックで ALB エンドポイントに異常があると判断された場合、Amazon S3 バケット内でホストされている静的エラーページにトラフィックを転送します。]
Amazon Route53 アクティブ/パッシブフェイルオーバー設定は、プライマリトラフィックをアクティブ な ALB に設定し、ヘルスチェックが失敗した場合に、S3 に切り替えることができます。

→「アクティブ/アクティブ」は、すべてのリソースを利用可能にする場合のため間違いです。リソースが利用できなくなると、Route 53 はそのリソースが異常であることを検知し、リソースが異常なリソースにリクエストを送信しなくなります。
→レイテンシーに基づくルーティングは、複数の AWS リージョンにリソースがあり、レイテンシ 一の最も小さいリージョンにトラフィックをルーティングする場合に使用するため間違いです。
—————————————————–
データベースの負荷が増大し、処理しきれない課題が生じています。
投票結果がタイムリーに処理されることを【保証】する費用対効果の高い方法

->SQS は疎結合を提供し、データベースキューの【バッファー】として機能します。また、スパイクは一時的なものであるため、RDBMS を拡張する必要はありません。
—————————————————–
単一のEC2インスタンス
高可用性と拡張性の両方を実現する最適な方法

->[ウェブサーバーのイメージの AMI ID を使用して起動設定を作成します。
新しく作成された起動設定と、【複数のアベイラビリティーゾーン】を使用した 2 つのウェブサーバーの希望する容量を使用して、Auto Scaling グループを作成します。
【ALB】を使用して 【Auto Scaling グループ全体でトラフィックをルーティング】します。]

NG
→Route 53 は、Auto Scaling グループ全体のトラフィックのルーティングに使用できないため間違いです。
→Auto Scaling グループには、同じリージョン内の複数のアベイラビリティーゾーンからの EC2 インスタンスを含めることができます。一方で、複数のリージョンを含めることができないため間違いです。
—————————————————–
データの IOPS に対して課金が発生する EBS ボリュームタイプ

->「プロビジョンド IOPS SSD の利用」が正解です。
プロビジョンド IOPS SSD (io1 および io2) ボリュームは、ストレージのパフォーマンスと整合性の影響を受けやすい I/O 負荷の高いワークロード、特にデータベースワークロードのニーズを満たすように設計されています。また、プロビジョンド IOPS SSD は、プロビジョニングした容量 (GB/月)
及び 1 か月あたりの IOPS (1 秒あたりの入力/出力オペレーションの数) について利用料が発生します。
—————————————————–
Redshiftクラスターが障害となった場合の対策を用意する必要があり
プライマリクラスタがダウンした場合でも即座に利用できることが求められています。

->「Redshiftクラスターのクロスリージョンスナップショットを有効化する。」
Redshiftクラスターのクロスリージョンスナップショットすることで、プライマリクラスターがダウンした場合に備えて即座に利用できる構成を維持することができます。クラスターのスナップショットを自動的に別のリージョンにコピーするように Amazon Redshift を設定できます。スナップショットがクラスターのプライマリリージョンで作成されると、セカンダリリージョンにコピーされます。これらは、それぞれソースリージョンおよびコピー先リージョンと呼ばれます。別のリージョンにスナップショットのコピーを保存することで、プライマリリージョンに影響が及んだ場合に最新のデータからクラスターを復元できるようになります。

NG
「CloudFormationを利用してクラスター構成を自動復元化する。」は不正解です。CloudFormationを利用してRedShiftアーキテクチャの構成を自動化することは可能ですが、【起動時に設定することになる】ため、クラスターダウンに備えるためには【自動スナップショット取得を有効化する】対応が必要となります。
—————————————————–
1 つのEC2 インスタンスがキューからのメッセージを受け取り処理
顧客数増大から来月のトラフィック量が10 倍に増える見込み
設計の見直しが最も必要であると思われるコンポーネント

->[データを登録するEC2インスタンス]
まずはじめに、問題文には【1つのEC2 インスタンス】との記載に注意しましょう。このため真っ先にスケーリングできるように設計を見直すコンポーネントはEC2と判断できます。
また、AWS ではAWS Auto Scalingという機能を提供しており、簡単にスケーリングを行うことができます。
しかし、予期せぬスケールアップの影響で請求金額が膨大な物になる可能性がある点に注意しましょう。
—————————————————–
バックアップ処理を【集中管理】するための、最適なAWSサービス

->「AWS Backup」が正解となります。
AWS Backup は、AWS Storage Gateway を使用して、オンプレミスおよび AWS サービス全体のデータのバックアップの自動化を簡単に実行できる完全マネージド型のバックアップサービスです。バックアップポリシーを一元的に設定し、Amazon EBS ボリューム、Amazon RDS データベース、Amazon DynamoDB テーブル、Amazon EFS ファイルシステム、AWS Storage Gateway ボリュームなどの AWS リソースのアクティビティ（履歴）を監視することができます。

NG
「Amazon DLM」は不正解です。Amazon DLMはEBS ボリュームのSnapshotの生成・削除の【ライフサイクルを自動化】できるサービスです。
しかし、【バックアップの一元管理を実施するサービスではない】ため正しくありません。
—————————————————–
サーバを構築することなくSQLクエリを使ってS3に格納されたデータを分析する

->Amazon Athenaを使用すると、SQLを使用してAmazon S3のデータを対話的に分析することができます。Athenaはサーバーレスのサービスであり利用者がサーバを管理する必要はありません。利用料金はクエリ実行に対してのみ課金されます。

NG
・Amazon RedShiftは大量のデータ分析に使用するサービスですが、S3のデータを分析することはできません。
—————————————————–
データベース層に対してはアプリケーションサーバからのトラフィックのみを許可したい

->[アプリケーションサーバーのセキュリティグループからデータベースのトラフィックを許可するようにデータベースのセキュリティグループを構成します。]
データベースのセキュリティグループをアプリケーションサーバーの【セキュリティグループ】からの トラフィックを許可するように構成できます。

NG
「データベースのサブネットにネットワーク ACL を構成して、アプリケーション層サブネッ トからすべてのインバウンドのデータベースのトラフィックを拒否します。」
「データベースのセキュリティグループを設定して、アプリケーションサーバーの IP アドレ スからデータベースのトラフィックを許可します。」
→NACL はステートレスであり、相互へのアウトバウンドおよびインバウンドトラフィックを許可する必要があるため間違いです。
—————————————————–
本ゲームは【レイヤー4のプロトコル】を利用してユーザに提供します。
アーキテクチャの高可用性と費用対効果の高いソリューション

->
「EC2 インスタンスの前に 【Network Load Balancer】 を設定します。」
「複数のアベイラビリティーゾーンのインスタンスを自動的に追加または削除する Auto Scaling グループを設定します。」

NG
・「EC2 インスタンスの前に Application Load Balancer を設定します。」
→Application Load Balancer は【レイヤー 4 プロトコルをサポートしていない】ため間違いです。
—————————————————–
必要なIPアドレスは5つ以下
このサブネットのCIDRにて最も適切な設定

->「/28」のプライベートサブネット」
使用可能なIPアドレスの数については、AWSでは/28が最小のCIDR単位となっております。
—————————————————–
EC2で構成されたWEBサイトをSSL化する方法

->[ELBにAWS Certificate Manager（ACM）で発行したSSL証明書をインストールし、EC2の手前に設置する]
AWSサービスを利用してWEBサイトをSSL化する場合、ELBにSSL証明書をインストールしEC2の手前にELBを設置します。
SSL証明書は、AWS Certificate Manager（ACM）で無料で発行することもできますが、外部CAで発行したSSL証明書を設定することも可能です。

NG
[AWS Certificate Manager（ACM）でSSL証明書を有効化する]
—————————————————–
S3バケットに新しいオブジェクトをアップロードすると検出するアプリケーションがあります。S3バケットに新しいオブジェクトがアップロードされたことをLambda関数をトリガーにして、オブジェクトのメタデータをAmazon DynamoDBテーブルとAmazon RDS for PostgreSQLデータベースに書き込みます。
高可用性を確保するために最適な方法

->[Amazon RDS for PostgreSQL データベースでマルチ AZ 配置を有効する。]
Oracle、PostgreSQL、MySQL、MariaDB DB インスタンスのマルチ AZ 配置では、Amazon のフェイルオーバーテクノロジーが使用されます。SQL Server DB インスタンスでは SQL Server データベースのミラーリング (DBM) が使用されます。

NG
「Amazon S3 バケットでクロスリージョンレプリケーションを有効にします。」
→Amazon S3 は 99.99 % の可用性を提供し、データは複数の施設に複製されるため間違いです。
—————————————————–
ALBを選択するべき理由について説明してください。（2つ選択してください。）

ー>「ターゲットグループでのヘルスチェックが可能であるため」と「パスベースルーティング（URLのパスに基づいてアクセスを特定のインスタンスに誘導すること）が可能であるため」が正解となります。
ALBの特徴は以下の通りです。
・L７に対応
【・パスベースルーティングが可能】
・WebSocketとHTTP/2のリクエストを受付るL７に対応
・1インスタンスに複数ポートを登録可能
・EC2インスタンスをターゲットグループに割り当てる際、複数ポートを個別のターゲットとして登録することが可能なため、特定の処理を複数ポートで負荷分散することができる
【・ターゲットグループでのヘルスチェックが可能】
・アクセスログの情報追加
・EC2と同様に削除保護が可能
・ALB自体が自動的にキャパシティを増減
可能
ELBにはALB, NLB, CLBの三種類があり、それぞれ異なる特徴を持っています。用途に応じた最適な選択を心がけましょう。
—————————————————–
【ネットワークインターフェース間のトラフィック情報
保存したログAmazon CloudWatch を使用してトラフィック情報の異常を監視
トラフィック情報を保持するソリューション

ー>VPC フローログは、VPC の【ネットワークインターフェイス】を通過するネットワークトラフィック情報を保存する機能です。フローログデータは Amazon CloudWatch Logs と Amazon S3 を使用して保存されます。フローログのデータは、Amazon CloudWatch Logs を使用して保存することで、トラフィック情報の表示や異常を監視します。
—————————————————–
セキュリティグループとネットワークACLの違いを説明した文章として、正しい

->[セキュリティグループはステートフルで、ネットワークACLはステートレスです。]
両方ともEC2インスタンスを外部から守る等の使われ方がありますが、細かい制御を追求する場合にはネットワークACLでは全トラフィックを許可して、セキュリティグループで細かい設定をするケースが多くなります。
ステートフル：ルールで許可された通信の戻りの通信も自動的に許可される
ステートレス：通信の行き（アウトバウンド）と戻り（インバウンド）で、ルールの設定が必要
—————————————————–
必要なパッチをダウンロードする場合を除いて、このサーバーはインターネットに接続できないようにする

->[データベースをプライベートサブネット内に構築して、NATインスタンスをルートテーブルに設定する。]
パブリックサブネットに設置されたEC2インスタンスはアウトバウンドトラフィックを直接にインターネット側に送信できますが、プライベートサブネットに設置されたEC2インスタンスはそれができません。
代わりに、プライベートサブネットに設置されたインスタンスは、パブリックサブネットに設置された【ネットワークアドレス変換 (NAT) ゲートウェイを使用して、インターネット側にトラフィックを返すことができます】。
これによって、データベースサーバーは、NATインスタンスを通じてインターネットに接続してソフトウェアアップデートを行うことができますが、インターネットからはデータベースサーバーへの接続を確立できません。

NG
「データベースをプライベートサブネット内に構築して、セキュリティグループで【アウトバウンドトラフィックのみ】を許可する。」
データベースをプライベートサブネット内に構築した上で、セキュリティグループではインバウンドトラフィックの制御を実施します。
—————————————————–
このIAMポリシーでは、EC2の全てのアクションを許可していますが、「リザーブドインスタンス関連の全ての操作」および「全てのインスタンスに関する終了操作」を禁じています。

 

前半のステートメントでは、全てのEC2に対して、許可を行っています。これはフルアクセス権限となっています。

 

{

“Action”: “ec2:*”,

“Effect”: “Allow”,

“Resource”: “*”

},

 

後半のステートメントでは、「リザーブドインスタンスのあらゆるアクション」と「全てのEC2インスタンスの終了させるアクション」に限定して、拒否する設定がされています。

 

“Effect”: “Deny”,

“Action”: [

“ec2:*ReservedInstances*”,

“ec2:TerminateInstances”

],

“Resource”: “*”

 

結果的に、この設定では、「リザーブドインスタンスに対するあらゆるアクション」と、「全てのEC2インスタンスに対してインスタンス終了処理」ができないことになり、オプション３が正解となります。
—————————————————–
アップデートがオブジェクトに対して同じキー名で設定する場合、そのアップデータの反映はどのようになりますか？

->「S3は強い整合性モデルを利用しているため、反映に誤差が生じることはない」
S3は強い整合性モデルを利用しているため、反映に誤差が生じることはありません。２０２０年１２月まで、S3は結果整合性モデルを利用していました。 したがって、アップデートがオブジェクトに対して同じキー名で設定されており、オブジェクトの更新が同じキーに対して行われると、更新直後の読み取りリクエストには更新内容が反映されていない可能性がありました。しかしながら、現在は強い整合性モデルが利用されているため、こうした齟齬が発生することはなくなりました。
—————————————————–
業務解析システム
高可用性リレーショナルデータベース
データ量が毎日10 GBずつ増加
並列処理が必要

->業務解析システム用のデータベースには【Redshift】が最適です。Redshiftは大量データの保存や【並列処理】によるパフォーマンス向上が可能であり、要件を満たすことができます。Redshiftはクラウド内で完全に管理されたペタバイト規模の【リレーショナルデータベース型】のデータウェアハウスサービスです。 Redshiftは数百ギガバイトのデータからペタバイト以上に【拡張できます】。 Redshift はテーブルの行をコンピューティングノードに分配するので、データを並列処理できます。 Redshift は各テーブルに対して適切な分散キーを選択することにより、データの分配を最適化して、ワークロードを分散し、ノード間のデータの移動を最小限にできます。

NG
Aurora MySQL 並列クエリは、データ集約的なクエリの処理に関連する I/O と計算の一部を並列処理することができます。しかしながら、【業務解析システムという要件を鑑みると、AuroraよりもRedshiftが最適】であるため、そちらが優先されるシナリオとなります。
—————————————————–
CloudFront 　コスト　算出

->「CloudFront エッジロケーションの場所」
「CloudFront へのリクエスト数」
「CloudFront からのデータ転送量（アウトバウンド）」

1) CloudFront エッジロケーションの場所
エッジロケーションの場所、つまり地域によって料金設定が異なります。
2) CloudFront へのリクエスト数
HTTP (HTTPS) のリクエスト数で金額が決まります
3) CloudFront からのデータ転送量（アウトバウンド）
各エッジロケーションから転送されるデータ量によって金額が決まります。
—————————————————–
運用監視ログを5年間保存する必要があります。

->Amazon S3 Glacier ボールトにログを保存し、ボールトロック機能を使用します。
S3 Glacier のボールトロックでは、ボールトロックポリシー(ファイル削除、などの変更を禁止するポリシー)を使用して、オブジェクトを管理することができます。
ボールトロックを利用して運用監査ログを保存します。ボールロックポリシーは一度ロックされると変更できなくなり、S3 Glacier では、指定したコンプライアンスコントロールによって明示的に許可されているデータ操作のみが許可されます。ボールトロックでは、ロックされたポリシーを削除または変更できないようにすることもできます。

NG
・「Amazon S3 バケットにログを保存し、保存したバケットで MFA Delete を有効にします。」
→MFA Delete が有効になっている場合は、オブジェクトバージョンの削除をできなくすることができます。一方で、運用監査ログを Amazon S3 に5年間保管するのはコストが高いため間違いです。
—————————————————–
ELBをパブリックサブネットに配置しその後ろにEC2を配置
適切なサブネットのタイプ

->プライベートサブネットになります。
EC2で構築したサービスをインターネットに公開する場合、通常はEC2インスタンスをパブリックサブネットに配置する必要があります。
ただしこの問題のケースの場合、EC2の前にパブリックサブネットに配置されたELBがあるので。インターネットからのアクセスはELBが受けることになります。
EC2にはELBからのみアクセスを許可しておけばよいため、セキュリティの観点からEC2インスタンスは「プライベートサブネット」に配置することが正解となります。
—————————————————–
ある AWS アカウントに対して、もう片方のアカウントで作成した S3 バケットへの操作権限を渡したい

->「バケットポリシー及びユーザーポリシーにて、もう片方のアカウントのアクセス許可を付与する」が正解です。
別のAWSアカウントに自分が所有するS3バケットへのアクセス利用を許可したい場合、バケットポリシー及び【ユーザーポリシー】の両方の許可設定が必要です。
—————————————————–
オンプレミスのデータセンタ内のMySQLサーバに接続するWEBアプリケーションをDockerコンテナで実装
システムの管理と展開を容易にするために役立つサービスを利用したい

->[WEBアプリケーション用の 【AWS Elastic Beanstalk】 で動作する単一コンテナの Docker 環境、およびデータベース用の Amazon RDS for MySQL を採用する。]
[WEBアプリケーションに Amazon 【ECS】、データベースに Amazon RDS for MySQL を採用する。]
—————————————————–
オンプレミス環境においてC＃プログラミング言語でコーディングされている定期実行ジョブをAWSに移行する

->「AWS Lambdaを使用して対象ジョブを稼働させる方法」が正解となります。
LambdaではC＃プログラミング言語でコードを実行する機能があります。Lambda はサーバー管理の手間なくコードを実行できるコンピューティングサービスです。AWS Lambdaは必要時にのみコードを実行し、1 日あたり数個のリクエストから 1 秒あたり数千のリクエストまで自動的に拡張できます。
NG
AWS ConfigやDynamoDBやAWS Batchでは、C＃プログラミング言語のジョブをホストすることはできません。
—————————————————–
どのワークロードにElastic Beanstalkを適用するべきかを検討しています。

->
-WEBアプリケーションを展開する際にElastic Beanstalkを利用しますので、「Amazon RDSを利用したWEBアプリケーションへの適用を検討する。」が正解となります。
-また、実行時間の長いワーカープロセスをElastic Beanstalkのワーカー環境の作成で展開することができますので、「実行時間の長いワーカープロセスへの適用を検討する。」が正解となります。

NG
「エンタープライズデータウェアハウスのワークロードへの適用を検討する。」は不正解です。エンタープライズデータウェアハウスのワークロードには、Redshiftによる設定や、SQSとの連携などで設定することが最適です。
「静的WEBサイトの表示への適用を検討する。」は不正解です。静的ウェブサイトはS3やEC2インスタンスをシンプルに利用することが最適です。
「深夜に1回実施されるBatch処理への適用を検討する。」は不正解です。深夜に1回実施されるBatch処理は、AWS Batchなどの機能を利用してシンプルに構成できる機能です。Elastic BeansStalkで想定するワーカープロセスは複雑なタスク内容をワーカーアプリケーションとして実装する際に利用します。「実行時間の長いワーカープロセス」などは最適ですが、「深夜に1回実施されるBatch処理」には別の仕組みを利用することが求められます。
—————————————————–
企業ウェブサイト（www.yourcompany.com）から、バックエンドサーバ（services.yourcompany.com）
APIGatewayとLambdaで実装
The same origin policy disallows reading the remote resource

->[API Gateway で CORS を有効にする。]
API Gatewayはクライアントからリクエストを受け取ってそれをバックエンドに渡すし、バックエンドからレスポンスを受け取ってクライアントに返すし、【プロキシのような働きを行います。】
ウェブページはバックエンドサービスのドメインとは別のドメインにあるため、API Gateway で CORS を有効にします。これは、クロスオリジンコールであり、セキュリティのためにブラウザによって制限されています。ドメイン間リクエストを許可するには、API Gateway で CORS を有効にする必要があります。
【API のリソースが API 自身のドメイン以外のドメインからリクエストを受信する場合、リソース上の選択されたメソッドのクロスオリジンリソース共有(CORS)を有効にする必要があります。】
—————————————————–
ストリームデータを、バッチ処理を使って分析するシステム
取得したデータは夜間に Amazon Redshift に【転送】し、分析
最小限の労力と、運用コスト　最も適している AWS サービスの組み合わせ

->「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」を使います。
—————————————————–
各リージョンのリソースが相互にアクセスできる

->「リージョン間VPCピアリングを使用し、網の目のように各VPCが相互に接続される構成を実装する。」
・異なるリージョンのVPC間でもピア接続（VPCピアリング）を作成できます。
異なるリージョンのVPC間で送信されるデータは暗号化されます（トラフィック料金が適用されます）
【「すべてのVPCが互いに直接通信する」】という要件を満たすためには、【網の目のように各VPCが相互に接続される構成】としなければなりません。中心となるVPCを一つ決めて各VPCと接続する構成では、他のVPCを中継しての接続（推移的なピアリング）を行うことはできないため、要件を満たすことができません。

NG
VPCエンドポイントは、VPCからサポートされているAWSサービスとプライベートに接続するためのサービスですが、【VPCとVPCの接続は提供していません】。
—————————————————–
外部から【アプリケーションログ】を監視できる

->「CloudWatch Logs を利用する」が正解です。
CloudWatch Logs は、アプリケーション、AWS サービスからのログを一元管理できる、スケーラビリティに優れたサービスです。たとえば、CloudWatch Logs は【アプリケーションログ】に存在するエラーの数をトラッキングし、エラー率が指定のしきい値を超えたときに管理者に通知を送ることができます。
—————————————————–
NoSQL データベース
可能な限り低遅延

->「I3タイプで構築する」が正解です。
I3 は、ストレージ最適化インスタンスの一つです。
ストレージ最適化インスタンスは、数万回の 【低レイテンシー】とランダム I/O オペレーション/秒 (IOPS) をアプリケーションに提供するように最適化されています。
その中でも I3 は、【NoSQL データベース】 や リレーショナルデータベース、高頻度オンライントランザクション処理 (OLTP) システムなどが利用用途として推奨されています。

NG
なお、「A1」は、旧世代のインスタンスタイプで、「T2」は、汎用インスタンス、「R5」は、メモリ最適化インスタンスの一つです。
—————————————————–
他のアジアリージョンでバックアップ構成を迅速に起動する
事前に作成されたAMIを利用してEC2インスタンスを設置

->「AMIを別リージョンにコピーする方法」と、「バックアップ用リージョンのアプリケーション構成のAuto ScalingグループのAMI IDに設定する方法」が正解となります。
このシナリオでは、ホットスタンバイやウォームスタンバイなどの構成をメインとは別のリージョンに構築するような対応が必要となります。

この構成を実現するためには、Amazon EC2 インスタンスの Amazon マシンイメージ (AMI) を作成し、別の AWS リージョンにその AMI をコピーします。
また、バックアップ用のリージョンにおいて【Auto Scalingグループ】が設定することが必要な場合は、そこで利用されている起動設定のAMI IDに既存構成のAMIを利用する必要があります。その場合は、新しいAMIを指定してあらためてAutoScalingグループを設定し直して下さい。
NG
CloudFormationに別リージョンにおけるAMI IDをセットアップすることで、別リージョンでのインフラ構成を展開するための準備をすることも可能ですが、本件は【即時起動が要件】となっていルため不正解です。
—————————————————–
【オンプレミス】で暗号化キーを生成・管理することが必要

->オンプレミスで暗号化キーを生成および管理する必要があるため、【ユーザ提供のキー】によるサーバ一側の暗号化 (SSE-C)を使用します。
—————————————————–
SNS（Simple Notification Service）
利用することのできるエンドポイント

->SNSのエンドポイントとは、SNSから送信されるメッセージの受信方法のことを指しています。エンドポイントには、HTTP/HTTPS、AWS Lambda、Eメール、SQS、SMS、モバイルプッシュ通知を利用することができます。
【XMLは利用することができません。】
—————————————————–
CloudFrontを使用したWEB配信サービスのPCIコンプライアンス（クレジットカードのデータのセキュリティを向上するために策定した業界標準）への対応状況

->「CloudFront 【APIに送信されるリクエスト】を取得する対応」と
「CloudFront【アクセスログ】を有効化する対応」が正解となります。
—————————————————–
ロードバランサを使用してもHTTPヘッダーを変更せずにリクエストをWebサーバへ転送したい

->【NetworkLoad Balancer】 はレイヤー 4 の TCP で動作するため、ヘッダーを変更せずにリクエストをバックエンドインスタンスに転送することができます。

NG
・「Classic Load Balancer」
・「Application Load Balancer」
→Classic Load Balancer と Application Load Balancer は、レイヤー7 で機能し、ヘッダーを変更できるため間違いです。
—————————————————–
VPC に割り当てるサブネットの特性を2つ

->
「各サブネットは、単一のアベイラビリティーゾーンにマッピングされる。」
「デフォルトサブネットはパブリックサブネットで、メインルートテーブルがインターネット ゲートウェイにルーティングされる。」

NG
「/25 の CIDR ブロックマスクはサポートされている最小の範囲です。」
→サブネットの最小サイズは 【/28】のため間違いです。 VPCよりも大きなサブネットにすることはできません。
—————————————————–
EC2のCPU使用率をなるべく一定に保つ方法

->AutoScalingで、EC2インスタンスの集合グループを作成することができます。
CPU使用率を一定に保つ方法が問われているため、【Auto Scaling】が最適となります。
例えば、CPUを30%-40%の範囲で保つようにするためには、40%を超えたらスケールアウトし、20%を下回ったらステールインするように設定することが可能です。
—————————————————–
APIを呼び出すLambda関数

->「すべての Amazon RDS インスタンスのリストを表示する権限を持つ IAM ロールを作成して Lambda 関数ヘアタッチします。」
Lambda 関数に Amazon RDS インスタンスをリストを表示させる権限を持つ IAM ロールを割り当てる必要があります。

NG
「IAM アクセスキーとシークレットキーを作成し、Lambda 関数に保存します。」
→アクセスキーの使用は推奨されないため間違いです。
—————————————————–
このデータはリアルタイムに使用され、顧客がサイトをクリックした滞在時間や広告のクリック率を増やすために利用されます。

->[セッションごとのウェブクリックを Amazon Kinesis にプッシュし、Kinesis ワーカーを 使用して行動分析します。]
要件を満たすためにリアルタイムのデータキャプチャと分析が必要です。Amazon Kinesis は Kinesis ワーカーを使用してリアルタイムデータの収集と分析に役立ちます。
—————————————————–
MS Active Directoryを社内で利用
AWS Directory ServiceによりAWSとオンプレミス環境のユーザー管理を統合することが必要

->
「AWS Managed Microsoft ADを利用して、Microsoft Active Directory(AD) を【構築】する設定」
「AD Connectorにより【既存の】Active Directoryと連携する設定」
AWS Managed Microsoft ADを利用すれば、 AWS と既存のオンプレミス Microsoft Active Directory の間で信頼関係を設定し、シングルサインオン (SSO) を使っていずれかのドメインのリソースへのアクセス権を、ユーザーとグループに提供することができます。
AD Connector を使用して、既存のオンプレミスの Microsoft Active Directory のユーザーやグループにもロールを割り当てることができます。これらのロールは、そのロールに割り当てられた IAM ポリシーに基づいてユーザーの AWS サービスへのアクセスを制御します。
—————————————————–
ユーザーセッション情報を保存するために適切なサービスまたは機能

->Amazon DynamoDB は、ユーザーのセッション情報を保存し、スケーラブルな低レンテンシーなアクセスを提供する理想的な保存先です。

NG
→「Amazon Simple Queue Service (SQS)」 は、完全マネージド型のメッセージキューイングサービスのため間違いです。
—————————————————–
セキュリティグループとネットワークACLの違い

->セキュリティグループはステートフルで、ネットワークACLはステートレスです。
両方ともEC2インスタンスを外部から守る等の使われ方がありますが、細かい制御を追求する場合にはネットワークACLでは全トラフィックを許可して、セキュリティグループで細かい設定をするケースが多くなります。
ステートフル：ルールで許可された通信の戻りの通信も自動的に許可される
ステートレス：通信の行き（アウトバウンド）と戻り（インバウンド）で、ルールの設定が必要
—————————————————–
Redshiftクラスター間のすべてのトラフィックがインターネットを通過しないようにする

->「拡張VPCルーティングを利用する方法」が正解となります。
Amazon Redshiftの拡張VPC ルーティングを使用すると、Amazon Redshift はクラスターとデータリポジトリ間のすべての通信が特定のVPC を通るよう強制することができます。
—————————————————–
アプリケーションはファイルからメタデータを抽出します。
処理するファイルのサイズは【通常約4GB】
通常一つのファイルを処理するのに数秒かかりますが、処理がほとんどない時間もあれば短時間で複数のアップロードが行われる時間もあり

->「S3バケットにファイルを保存しS3イベント通知を使用してLambda関数を呼び出して処理する方法」が、不定期に処理が発生するアプリケーションで最もコスト効率のよい方法です。

NG
SQSキューでJava用の拡張クライアントライブラリを使用すると、メッセージをS3に保存することができ、2GBまでのメッセージを取り扱う事ができますが、4GBのファイルを扱うことはできません。そのため、不正解です。
—————————————————–
DynamoDBでテーブルの読み書き容量を制御する機能

->プロビジョニングされたスループット容量
読み取り/書き込みキャパシティーモードは、テーブルを作成するときに設定でき、後で変更することもできます。
・オンデマンド
・プロビジョニング済み (デフォルト、無料利用枠の対象)
プロビジョニング済みを選択すると、予め利用者が予測される読み書きの回数を指定しその必要な分の性能が確保されます。この場合、確保された性能に対して課金されます。
—————————————————–
トラフィック量に応じてデータ処理性能を自動拡張できるルーティング設定された静的ウェブサイトを構築する

->「Route53をS3の静的ウェブホスティングに設定する方法」と「エイリアスレコードを利用してドメインをリダイレクトする方法」が正解となります。
Amazon S3とRoute53を組み合わせることで静的ウェブサイトを配信できます。具体的には、Route53を利用してエイリアスレコードを作成してドメインのホストゾーンに追加し、pintor.com と www.pintor.com を対応する S3 バケットにマッピングします。エイリアスレコードでは、IP アドレスを使用する代わりに、Amazon S3 ウェブサイトエンドポイントを使用します。
—————————————————–
企業の合併プロジェクト
共有VPC内に構築したAmazon Redshiftにアクセスできるネットワークを制

->[Amazon Redshiftクラスター用のセキュリティグループを作成し、特定のネットワークからのアクセスを許可する。]
共有VPCを利用した際のアクセス制御は、VPC内での制御となるため【セキュリティグループ】での設定が正解となります。
共有VPCを利用する事により、管理する VPCの数を結果的に減らす事に繋がり、アクセスコントロールを一元化する事が出来ます。
共有VPCは、グループ会社や事業部単位で複数のAWSアカウントを利用しているケースにおいて、非常に有用なサービスと言えます。
—————————————————–
ECサイトを運用するA社では毎週、毎月及び四半期ごとの傾向を伴う販売量や収益を正確に予測する販売予測
予測結果は【可視化】して表示する機能

->Amazon QuickSight は、ML Insights を含むインタラクティブなダッシュボードを簡単に作成して公開できるBIツールです。
—————————————————–
RDSの自動バックアップの保存期間について正しいものを2つ選べ
問題4の解説：
RDSの自動バックアップの保存期間には0～35を指定することができます。0を指定した場合は、自動バックアップされなくなり、自動バックアップを行う場合は1～35日の保存期間を設定できます。
—————————————————–
RDSのバックアップについて正しいものを2つ選べ
問題5の解説：
RDSはデフォルトで自動バックアップを毎日取得してくれる。取得したスナップショットはS3に保存され、DBインスタンス削除時に自動バックアップで取得したスナップショットは削除されるが、手動で取得したスナップショットは削除されない。[学習ポイント]RDSのバックアップについては1～2問は出題される問題なので、重点的に内容確認をしましょう。
—————————————————–
問題3の解説：
EBSスナップショットは、初回はフルバックアップで、２回目以降は差分バックアップになります。復元には、最新の差分バックアップファイルのみあれば、復元可能という点がよく問われるので覚えておきましょう。
—————————————————–
問題2の解説：
スポットインスタンスの停止時(STOP)は、RAMデータが維持されますが、終了時(Terminate)は、インスタンス自体が削除されるのでRAMデータは削除されます。只、どちらも場合もEBSのデータは維持されます。 スポットインスタンスの挙動については、毎回2～3問は出題される問題なので、ポイントを押さえておきましょう。
—————————————————–
問題3の解説：
S3のバージョンニング機能を利用すると、誤削除などを行ってしまっても、削除前のオブジェクトを参照できるというメリットがありますが、複数バージョンのオブジェクト分の容量についての課金が発生するという点がポイントとなります。
—————————————————–
問題4の解説：
セキュリティグループの設定内容変更の反映は、EC2インスタンスの再起動が必要です。
—————————————————–
よく出題されるポイント：EBSスナップショットは非同期で行われるので、取得開始時はE2からデタッチした状態で取得開始し、 取得開始後は、EC2インスタンスにアタッチした状態でスナップショット作成を継続して問題ない。頻出問題
—————————————————–
プライマリDBが停止した場合に、スタンバイDBがプライマリDBとは異なるIPアドレスで自動起動するが、 DBへのアクセスパスも自動的に切り替わるので、アプリケーションはDBの切り替わりを意識することなくサービスの継続が可能
問題3の解説：
RDSのマルチAZ構成の最大の利点としては、ユーザーが意識をすることなく、フェイルオーバーできるというのが大前提としてあり、ここはよく問われる箇所。
—————————————————–
スポットインスタンスの動作について正しいものを3つ選べ

スポットインスタンスが停止(STOP)される際は、シャットダウンされずに、RAM データは維持され、終了(Terminate)される際は、RAM は消去され、インスタンスが削除されます。

スポットインスタンスが停止(STOP)される際も、終了(Terminate)される際も、EBSデータは維持される。

スポットインスタンス価格が入札価格を超えた場合、2分前に通知が行われた後、該当インスタンスは自動的に停止(STOP) or 終了(Terminate)が行われる。

不正解
スポットインスタンスが停止(STOP)される際は、EBSデータは維持され、終了(Terminate)される際は、EBSデータ は消去されます。

問題4の解説：
スポットインスタンスにて入札価格が市場価格を下回った場合の動作については頻出する問題。停止(STOP)時と終了(Terminate)時で挙動が異なるので注意。
—————————————————–
問題5の解説：
よく出題されるポイント：スポットインスタンスが終了(Terminate)した場合は、該当インスタンスを再起動することはできない。 スポットインスタンスが停止(STOP)した場合、該当インスタンスは手動では再起動できないが、価格が再度入札額以下になった際に自動で再起動される。
—————————————————–
アカウントAで作成したVPC①とアカウントBで作成したVPC②を同一ネットワーク上にあるがごとく通信を行うために適用するのに正しいものを選択せよ。

EBS最適化オプションを適用する
プレイスメントグループを作成する
VPCピアリングを適用する
VPCエンドポイントを作成する

問題2の解説：
VPCピアリングを適用することで、同一ネットワーク上にあるようにL3スイッチでVPC間の通信が可能になります。
—————————————————–
EC2インスタンスにアタッチされているEBSについての挙動について正しいものを2つ選択せよ
該当EC2インスタンスの削除時に、該当のEBSボリュームも削除される(EC2のDeleteOnTerminationがTrue)

該当EC2インスタンスの削除時に、該当のEBSボリュームも削除される(EC2のDeleteOnTerminationがFalse)

EC2インスタンスとEBSに依存関係はないので、EC2インスタンスを削除しても、EBSボリュームが削除されることはない
EC2にアタッチされているEBSを個別に削除することはできない

問題2の解説：
EC2削除時にDeleteOnTerminationがTrueの場合に、EBSも削除される。アタッチされているEBSを個別に削除することはできない。
—————————————————–
Lambdaに定義した関数を起動するための正しいトリガーを2つ選択せよ
S3にオブジェクトが格納された時
EC2が起動した時
API Gatewayにリクエストが届いた時
Glacierにオブジェクトが格納された時
問題3の解説：
Lambda関数が起動するトリガーは複数あり、S3やAPIGatewayがユースケースとしてよく紹介されます。それ以外にもトリガーが複数あるので押さえておきましょう。頻出問題です。
—————————————————–
新システムの導入に伴い、システムの監視を行う必要があります。CloudWatch(CloudWatch/CloudWatchLogs/CloudWatchEvents)で実現できることを全て選択せよ。

EC2のＣＰＵ使用率が70％以上になった場合に、ＳＮＳと連動してメール通知をする。
オンプレのサーバーのアプリケーションログを監視し、特定の文言が出力された場合に、ＳＮＳと連動してメール通知をする。
ＥＣ2上のサーバーのログを監視し、特定の文言が出力された場合に、ＳＮＳと連動してメール通知をする。
AutoScalingがEC2インスタンスを増減させたら、指定したLambda関数を実行する。
問題1の解説：
CloudWatchは本試験の頻出問題。CloudWatchLogsやCloudWatchEventsの内容も問われるので、実現できることを整理しておく必要がある。CloudWatchのエージェントを導入すれば、オンプレサーバー上の監視も可能。4つの選択肢の全てか実現可能です。
—————————————————–
EC2に対してEBSをアタッチしようと思います。 可能な構成を2つ選択せよ。
既に他のEC2にアタッチされているEBSをアタッチする
B
EC2とは別のAZに作成されているEBSをアタッチする
EC2とは同じAZに作成されているEBSをアタッチする
EC2とは別のAZに作成されているEBSのスナップショットをEC2と同じAZに作成してアタッチする
問題2の解説：
アタッチ済のEBSは、他のインスタンスに紐づけは不可。別のAZのEBSもアタッチ不可だが、スナップショットで同じインスタンスに作成したものとのアタッチは可能。
—————————————————–
システム稼働前は、使用量が正確に分からないの、システムの使用量に合わせてEBSを拡張/縮小することで適したリソースでの 運用を実現しようと思います、以下、実現できない選択肢を1つ選択せよ。
大きめのEBSをアタッチしておき、後で縮小を行う
小さめのEBSをアタッチしておき、後で拡大を行う
標準ボリュームタイプのEBSをアタッチしておき、後でタイプの変更を行う
小さめのEBSを複数アタッチしておき、後で不要分のデタッチを行う
問題5の解説：
EBSの拡張・タイプ変更は可能だが、縮小はできないことがよく問われるので、覚えておきましょう。
—————————————————–
オンプレのサーバー上で管理しているデータファイルを、災害時に備えてAWS上にバックアップをしたいと思い、StarageGatewayを使用しようとしています。 オンプレサーバー上にデータを保存しているシステムのパフォーマンスが落ちることが許容されるが、災害直前の状態のデータをAWS上のＳ3に対してAPI経由でですぐ参照できることが必須条件となります。 この要件に最も適したゲートウェイのタイプを選択せよ。
ファイルゲートウェイ
ボリュームゲートウェイ(キャッシュ型)
ボリュームゲートウェイ(保管型)
D
テープゲートウェイ
問題1の解説：
ボリュームゲートウェイでS3に格納されるのはスナップショット形式のため、S3のAPI経由でのデータ参照はできません。災害を考慮した問題はよく出題されるのでポイントを押さえておきましょう。
—————————————————–
StorageGatewayのファイルゲートウェイを利用して、オンプレミスサーバーのデータをAWSへ移行しようと思います。 正しい記述を2つ選択せしょ。
A
ファイルゲートウェイを使用することで、オンプレミスのファイルサーバーへ配置したデータを、数時間のタイムラグでS3に格納することができる。
ファイルゲートウェイを使用することで、オンプレミスのファイルサーバーへ配置したデータを非同期だが、ほぼリアルタイムでS3に格納することができる。
ファイルゲートウェイ経由でS3に格納されたデータはS3のAPIで参照可能。
D
ファイルゲートウェイ経由でS3に格納されたデータはS3のAPIでの参照はできない。
問題3の解説：
SStorageGatewayは頻出で問われる機能です。 ファイルゲートウェイ、ボリュームゲートウェイ、テープゲートウェイの特徴について押さえておきましょう。ファイルゲートウェイは非同期だがほぼリアルタイムにS3へデータ格納が可能で、格納したデータはAPI経由でアクセス可能となるのが特徴です。
—————————————————–
StorageGatewayのボリュームゲートウェイを利用して、オンプレミスサーバーのデータをAWSへ移行しようと思います。 正しい記述を2つ選択せしょ。
キャッシュ型ボリュームを利用することで、参照頻度の高いファイルを高速でS3から取得することができる。
キャッシュ型ボリュームを利用することで、参照頻度の高いファイルは高速でオンプレ上から取得し、キャッシュ上にないファイルはS3から取得することができる。
C
保管型ボリュームを利用することで、ほぼリアルタイムにS3にデータを格納することができるが、参照・更新に時間がかかる。
保管型ボリュームを利用することで、オンプレミス上のファイルのスナップショットを定期的にS3に格納することができる。
問題4の解説：
キャッシュ型ボリュームと保管型ボリュームの違いは頻出問題です。 キャッシュ側はS3に格納したファイルにアクセスできるのに対し、保管型はスナップショットをS3に格納しているのでS3に格納したデータにアクセスするには、スナップショットからEBSを作成してEC2にアタッチする必要があります。
—————————————————–
これまでオンプレミス上のアプリケーションサーバーとOracleで連携していたシステムを、AWS上のEC2をアプリケーションサーバー、DBサーバーをRDS(Oracle)とする構成に変更しようと思います。 オンプレのOraleからRDS(Oracle)に変更することで注意すべき点で正しいものを2つ選択せよ。
Oracleから提供されるパッチなどは、これまでのオンプレ上の運用と変わらず、任意のタイミングでパッチを充てることが可能。
Oracleから提供されるパッチなどが強制的に充てられることがある。
C
定期的なバックアップは、これまでのオンプレの運用と同様に設定する必要がある。
定期的なバックアップは、設定1つで自動バックアップを行うことが可能。
問題1の解説：
RDSについては、より詳細な内容が質問されるようになりました。 マネージドサービスのため、RDSを利用することにより大幅に管理コストを下げることができます。但し、バッチなども半強制的に充てられてしまうので、注意が必要です。
—————————————————–
AMAZON Redshiftを導入するのに最も相応しい案件内容を1つ選択せよ。
大量のデータをリアルタイムに一括登録する業務
B
頻繁に参照処理を行う業務
大量のデータに対してバッチ処理などで分析を行う業務
D
少量のデータをリアルタイムに頻繁に登録する業務
問題2の解説：
Redshitはカラムナ志向のデータベースで、集計処理に威力を発揮するデータべースです。 データの登録・更新は他のDBに比べて時間がかかります。
—————————————————–
複数のバッチプログラムが存在し、それらを決められた順序で実行し、並列処理/分散処理も定義可能としたいという要件を実現するために適したサービスを2つ選択せよ。
CloudFormation
SWF
C
SES
StepFunctions
問題4の解説：
かつては問題にあるようの要件を実現するためのサービスはSWFだけでしたが、新たにStepFunctionsがサービス開始され、SWFと同様のことを実現できるようになりました。SWFよりもStepFunctionsの方が可視性に優れているという特徴を押さえておきましょう。
—————————————————–
これまでオンプレ上で構築していたCI環境の保守にコストが掛かるようになってきたので、AWS上にCI環境を作成しようと思います。 以下の中からCI環境構築に必要なサービスの組み合わせを1つ選択せよ。
A
Kinesis DataPipeline
B
SWF StepFunctions
ElasticBeanstalk CloudFormation
CodeCommit CodeBuild CodeDeploy CodePipeline CodeStar
問題5の解説：
CI環境構築のためのサービスとして odeCommit/CodeBuild/CodeDeploy/CodePipeline /CodeStarのそれぞれの役割を押さえておきましょう
—————————————————–
あなたは以下の要件を満たすシステムの構築の依頼を受けました。 DBに使用するサービスとして最も適しているものを選択せよ。 [要件1]1つのAZで障害が発生しても止まらない高可用性 [要件2]時間帯によって処理可能なスループットをダウンタイムなしに変更可能 [要件3]大量のデータを蓄積して高速な検索が可能 [要件4]データのフォーマットを意識しない
Redshift
DynamoDB
C
RDS(Oracle)
RDS(Aurora)
問題2の解説：
DynamoDBの内容についても詳細を問われるようになりました。 大きなポイントは、ダウンタイムなしにスループットの設定が変更できるという特徴があり、また、自動的に3つのAZにデータが保存されるので高可用性を保つことができます。
—————————————————–
新規構築するシステムのDBにDynamoDBを採用しようと思います。 DynamoDBで実現可能なことを3つ選択せよ。
ダウンタイムなしにスループットの変更が可能
有効期限を過ぎたデータの自動削除
追加・更新・削除の履歴を保持可能
データセットをメモリ上で保持する
問題4の解説：
DynamoDBの特徴を問う問題は、そこそこ出題されます。スループットの変更が可能なのは大きな特徴ですが、その他に、データの自動削除、更新履歴の保持が特徴となっています。 データセットをメモリ上で保持するのは、ElastiCacheの説明になります。
—————————————————–
問題3正解！だけど、正解率が少し下がっちゃったね・・・（＞＜）
EC2インスタン上のアプリケーションの負荷テストを行う際の注意事項について正しいものを2つ選択せよ。
申請には最低2日程度必要
Dos/DDosシミュレータの利用は禁止
申請できるテスト実施期間は最長24時間
実施できるインスタンスタイプが限られている
問題3の解説： 申請できるテスト実施期間は最長48時間で、 申請には2週間程度必要。m1.small,t1.micro,nanoのタンスタイプは申請負荷となっています。また、Dos/DDosシミュレータの利用は禁止です。
—————————————————–
新規に作成するアプリケーションのDBにAMAZON AURORAを採用しようと思います。 AMAZON AURORAの特徴について正しいものをすべて選択せよ。
DBインスタンス作成と同時にクラスタが作成される。
インスタンス作成時に容量の指定は必要なく、自動で拡張されていく。
クラスタは同一リージョン内の複数AZで構成される
クラスタ上の各ボリュームは自動で同期される。
問題4の解説： すべて正しい特徴です。 AMAZON AURORAは耐障害性、高可用性に優れたデータベースで、特徴も多いので、それぞれのポイントを押さえておきましょう。
—————————————————–
あなたが担当するシステムでは、データストアにDynamoDBを利用している。 このシステムを保守運用する上で、考慮すべき内容として誤っているものを1つ選択せよ。
データストアの容量は最初に決めた容量を拡張できないので、定期定期にデータ削除が必要。
B アクセス数に応じて自動でスケールアウトしてくれる
データストアの容量は拡張可能で、閾値を決めて、それを超えた場合に拡張するなどの自動拡張設定も可能
Rest API経由でのデータ操作が可能
問題1の解説： DynamoDBの特徴としては、スキーマレス、容量拡張可能性、自動スケールアウト、高スループットなどが挙げられます。またNONSQLのDBでは基本的にはトランザクションは管理できませんが、一定の条件下でトランザクションの管理も行えます。

—————————————————–
問題1正解！だけど、正解率が少し下がっちゃったね・・・（＞＜）
あなたが担当するシステムでは、データストアにDynamoDBを利用している。 このシステムを保守運用する上で、考慮すべき内容として誤っているものを1つ選択せよ。
データストアの容量は最初に決めた容量を拡張できないので、定期定期にデータ削除が必要。
B アクセス数に応じて自動でスケールアウトしてくれる
データストアの容量は拡張可能で、閾値を決めて、それを超えた場合に拡張するなどの自動拡張設定も可能
Rest API経由でのデータ操作が可能
問題1の解説： DynamoDBの特徴としては、スキーマレス、容量拡張可能性、自動スケールアウト、高スループットなどが挙げられます。またNONSQLのDBでは基本的にはトランザクションは管理できませんが、一定の条件下でトランザクションの管理も行えます。
問題2正解
オンプレミスで稼働しているシステムがあります。このシステムはファイルサーバーに対して業務データを蓄積していますが、耐障害性を考慮してEFSの利用を検討しています。 EFSを利用する上で正しい記述を１つ選べ。
A オンプレのシステムからEFSを利用することはできないので、オンプレのAPサーバーもEC2などに移管する必要あり
オンプレのAPサーバーからEFSへのデータ登録は可能
C 最初に決めた容量サイズから変更ができないので注意が必要
D 単一のAZでのみデータが保存されるので、耐障害性としては弱い
問題2の解説： EFSの特徴としては、容量無制限、複数のEC2から接続可能、３つのAZに分散してのデータ保存などが挙げられます。 EBSと対比しての特徴を押さえておきましょう。
問題3正解
単一のEC2上で稼働しているWEBシステムがあります。このシステムのアクセス数が増えてきているため、複数のEC2上にこのシステムをスケールアウト稼働させ、ELBのAutoScalingにてアクセスを振り分けようと思います。 これまでは、cookieを用いたセッション管理を行ってきましたが、AutoScalingを考慮して、なおかつパフォーマンス的にも優れた管理方法として、最も適したものを１つ選択せよ。
A RDSにてセッション情報を一元管理する
B S3にてセッション管理を一元管理する
ElastiCacheにてセッション情報を一元管理する
D SQSにてセッション情報を一元管理する
問題3の解説： セッション管理に関する頻出問題です。 AutoScalingでの構成を考えると、複数のEC2でのセッション情報を1ヵ所で管理する必要があります。問題文の要件として、パフォーマンスに優れたという点を考慮すると、ElastiCacheが最も適しています。RDSやS3でも管理はできますが、ElastiCacheと比べるとパフォーマンスとしては落ちます。
問題4不正解
AutoScaling機能を利用してEC2のスケールアウトとスケールインを行っている。 この際に自動でスケールインしたEC2のでEBSデータを消さずに保持する場合に適切な方法を１つ選択せよ。
EBSスナップショットを取得する
EBSミラーリングを実施する
EBSのDeleteOnTerminationをtrueに設定する
EBSのDeleteOnTerminationをfalseに設定する
問題4の解説： EBSのDeleteOnTerminationをfalseにすることで、自動スケールインされた場合にEBSデータを消さずに残すことができます。 EBSスナップショットを取得することで、ある時点でのデータを残すことはできますが、スケールインが行われた時点でのデータを残すことはできません。EBSミラーリングを行うことで、各EBSデータを連動することはできますが、それらのEBSデータもスケールイン時に削除されてしまうので不適合です。
—————————————————–
これまでオンプレミス環境で、GitHub、Jenkins等を連携させてCI環境を構築しているシステムがあります。 このシステムを今度AWSのEC2上に移管することを検討しており、それに伴い、CI環境もAWSのサービスを用いて構築しようと思います。 CI環境を実現するサービスの説明として正しものを1つ選択せよ。
A CodeBuildは、ソースコードを管理するGitリポジトリサービス
B CodeCommitは、Jenkinsと同様なソースコードのビルド＆テストサービス
CodePipelineは、ソースコード管理、ソースコードビルド＆テスト、デプロイを行う3つのサービスを連携させるためのサービス
D CodeDeployはソースコードを管理するGitリポジトリサービス
問題1の解説： AWS上でCI環境を構築するためのサービス群を問う問題は意外と出題されます。CodeCommit、CodeBuild、CodeDeployとそれらを連携させるCodePipelineと、さらにこれら4つを利用するCI環境を自動構築するCodeStarについて、それぞれの役割を押さえておきましょう
—————————————————–
DynamoDBを用いたシステムを構築する上で考慮すべき内容で正しいものを1つ選択せよ。
データを特定するプライマリキーは必ずパーティションキー＋ソートキーで構成される
パーティションキー＋ソートキーをプライマリキーとすることで、トランザクション管理が可能になる
セカンダリインデックスを用いることで検索の高速化が可能になるが、コストも増えるので注意が必要
D プライマリキーはパーティションキー単独でも構成できるが、パーティションキー単独で構成した場合、検索処理のインデックスとしては機能しない
問題2の解説： DynamoDBでの設計はRDBでの設計と全く異なるので、そこを問う問題は頻出です。 特に、プライマリキーについては、正しくポイントを押さえておきましょう。プライマリキーは、パーティションキー単独で構成するか、単独で情報を一意にできないのであれば、パーティションキー＋ソートキーという組み合わせで構成することも可能です。また、プライマリキーはインデックスとしても利用されますが、検索性能が満たせない場合は、セカンダリインデックスを使用して、検索高速化を実現できるが、コストは増加するので注意が必要。
—————————————————–
ElastiCacheを用いたシステムを構築する上で考慮すべき内容で正しいものを２つ選択せよ。
A メモリ上でのみデータを管理するので、データの永続化が必要な業務には使用することができない。
B Memcache版ElastiCacheもResdis版ElastiCacheもデータ暗号化の機能がある
万が一データが消えても業務に影響のないデータ処理の高速化に特化するのであれば、Memcache版ElastiCacheを採用すべき
Memcache版ElastiCacheもResdis版ElastiCacheもクラスタ構成が実現できるが、マスター/スタンバイといった冗長構成が実現できるのは、Resdis版ElastiCacheのみ
問題3の解説： ElastiCacheに関する出題は、以前はシンプルな問題だけでしたが、最近では、Memcache版ElastiCacheもResdis版ElastiCacheの特徴についても問われる様になってきました。 高性能に特化するのであれば、Memcache版。冗長性やデータの永続化や暗号化というポイントを実現するのであれば、Resdis版ElastiCacheと覚えておきましょう。
—————————————————–
あなたはメールマガジンの配信をSimple Email Service(SES)を用いて行うシステムを運用しています。 SESを運用してメール配信を行う上で気をつけるべき内容として正しいものを全て選べ

宛先不明などで未達のメールの割合が一定水準以上になると、配信停止になる
送信先で該当メールがスパムメールという報告が一定の割合以上になると、配信停止になる
メールコンテンツの質が低い場合、配信停止になる可能性がある
過去数日間に宛先不明で未達の送信先アドレス情報に対して、再度配信を行った場合、メール配信は行われない
問題4の解説： 全て正解です。 SESはスパムメールと認識されにくい仕組みを提供すると共に、ある一定の基準を満たさないとメール配信が停止されてしまいます。配信したが未達だった割合、スパムメールと報告された割合が基準以上になった場合や、コンテンツの質が低い場合にも配信停止になる可能性があります。
—————————————————–
あなたは既存のレガシーシステムを、Lambdaを利用したアーキテクチャーに作り替えようとしています。 この際に考慮すべきLamdaの特徴のうち、正しいものを2つ選択せよ。
1回の呼び出しで実行できる最大処理時間が決まっているので、最大処理時間を超える既存処理は処理を分割するなど処置を行う必要がある
大量アクセスが来た際に、リクエストが滞留しないように、スケールアウト設定を行う必要がある
Lambdaを起動している間、料金が課金されるので、こまめに停止を行う必要がある
処理速度を速めたい場合、割り当てるメモリを増やすことで実現できるが、料金は高くなるので注意が必要
問題5の解説： Lambdaの特徴に関する問題は頻出問題です。 1回の呼び出しで実行できる最大処理時間が決まっているので、それを超えるような処理は、分割するなどの設計が必要となります。 Lambdaはリクエスト量によって自動でスケールアウトするので、スケールアウト設定を行う必要はありません。 また、Lambdaに起動停止の概念はありません。 処理速度を速めたい場合は、メモリ割り当てを増やすことで処理速度を速めることができるようになりますが、その分料金が高くなるので注意が必要です。
—————————————————–
システムAがSQSに登録したメッセージを取得して後続処理を行っているシステムBがあります。 他のトランザクション処理の関係上、システムAがSQSにメッセージを登録してから、30秒後以降にシステムBがメッセージ取得をする必要がある場合に、正しい手段を2つ選択せよ。
可視性タイムアウトを利用して、SQS登録してから30秒間は該当メッセージの取得ができないようにする
遅延キューを利用して、SQS登録してから30秒間は該当メッセージの取得ができないようにする
メッセージタイマーを利用して、SQS登録してから30秒間は該当メッセージの取得ができないようにする
ロングポーリングを利用して、SQS登録してから30秒間は該当メッセージの取得ができないようにする
問題3の解説： 遅延キューもしくはメッセージタイマーの機能を利用することで、SQSにメッセージが登録されてから一定時間後以降にのみメッセージ取得ができるように設定することができます。 遅延キューはこのキューに登録されたメッセージが全て一定時間後にしか取得ができなくなります。メッセージタイマーは、メッセージ毎に遅延処理を設定できる機能になります。
—————————————————–
あなたが担当しているシステムの開発を行う際に、現状、複数の開発用の環境を構築や、環境構成の変更をメンテナンスするために時間と労力が掛かっています。 このコストを削減するために、環境構築の自動化を図りたいと考えています。以下のうち、2つのサービスを組み合わせてこの要件を実現可能なサービスを2つ選択せよ。
A AWS EMR
B AWS StepFunctions
AWS OpsWorks
AWS CloudFormation
問題1の解説： 構成管理の自動化を実現するには、OpsWorks とCloudFormationがあります。2つのサービスは構成管理の自動化という意味では同様な役割ですが、自動化する対象が以下の様に異なりますので、組み合わせて使用している方も多くいます。 OpsWorkはChefを利用してミドルウェア/アプリケーションなどの構築の自動化を可能にするサービスです。CloudFormationは、EC2/S3/RDS/VPCなどのAWSの複数のサービスを連携させての自動構築を可能にするサービスです。
—————————————————–
問題2の解説： IAMポリシーに関する問題です。
ポリシーには大きく分けて2つの種類があり、「インラインポリシー」と「管理ポリシー」があります。
インラインポリシーは対象ごとにそれぞれ付与します。例えば、ユーザー１とユーザー2にポリシーAを付与する場合は、それぞれのユーザーに対して、それぞれポリシーAを付与します。
管理ポリシーは複数のユーザーやグループに対して付与します。例えば、先の例ですと、1つのポリシーAをユーザー1とユーザー2に対して、まとめて付与できます。
—————————————————–
システムAとシステムBがあり、システムAがSQSに登録した情報をシステムBが情報取得して処理を行う場合、SQSに不整合なデータが登録された場合、システムBがこのデータを取得するリクエストを行った際に、データ不整合のためデータ取得できず、次の取得リクエストでも同様にデータ取得できずということを 繰り返してしまう可能性を無くすために、必要な対応を1つ選択せよ。

処理できないメッセージがあった場合、指定回数失敗した際に、別のキューにメッセージを移動する機能は「デッドレターキュー」という機能です。この機能を利用することで、問題にあるようなシチュエーションを回避することが可能になります。
—————————————————–
EC2から作成したAMIに関する問題です。 EC2をAMI化しても、AMIに対する課金は行われます。また作成したAMIは手順を踏めば他のユーザーに対して販売することも可能になります。また、EC2を別リージョンに移行する場合にも、AMI化して別リージョンにコピーすることで実現できます。
—————————————————–
問題1の解説： EC2から他のAWSリソースにアクセスする際は、シークレットアクセスキーとアクセスキーをアクセス時に渡すことで実現できますが、セキュリティ的にあまり良いとはいえず、IAMロールを付与することで、シークレットアクセスキーとアクセスキーの明示的な引渡しなしにアクセスが可能になります
—————————————————–
問題2の解説： IAMロールを利用することで、googleやFacebookのアカウントでAWSリソースにアクセスが可能になります(WEB IDフェデレーション)。また、会社などのADアカウントでもAWSリソースにアクセスが可能になります(IDフェデレーション)。そして、AアカウントのユーザーからBアカウントのリソースにアクセスするというクロスアカウントアクセスも可能になります。メールアドレスではAWSリソースにはアクセスできません。
—————————————————–
DynamoDBを採用する上で、パフォーマンスの良さと、非定型のデータ格納とトレードオフで考慮しなければいけない特徴で正しいものを1つ選択せよ。

DynamoDBをはじめとするNonSQLDBのプラスの特徴としては、高性能、非定型データの格納をまず挙げることができます。但し、引き換えにトレードオフとしてトランザクション管理ができないことを考慮して採用を検討する必要があります。NonSQLのDBでトランザクション管理できる製品も出てきていますが、DynamoDBはトランザクション管理は対応していません。
—————————————————–
S3に格納するデータの暗号化/複合化を問う問題です。 暗号化はクライアントサイドで行うのか、サーバーサイドで行うかで大きく2つに分かれます。 今回の要件のサーバーサイドの暗号化では、①S3がキーの管理を行う②ユーザーが指定したキーで複合化を行う③KMSでキーの管理を行うの３通りあります。
—————————————————–
セキュリティ性の高いデータを格納しているS3があります。万が一、このS3のアクセスキーが漏洩してしまっても、 第3社からアクセスできないように、アクセス元のサーバーを制限したいと思います。 以下から正しい選択肢を1つ選択せよ。
A Route53でアクセス可能なサーバーのIPアドレスを指定する
S3のBucketPolicyでBucketにアクセス可能なサーバーのIPアドレスを指定する
ACLでアクセス可能なサーバーのIPアドレスを指定する
D IAMポリシーでアクセス可能なサーバーのIPアドレスを指定する
問題5の解説： アクセスキーが漏洩しても、第3者にアクセスを許さないようにするのはS3ではよく行う設定になります。S3のBucketPolicyで設定するのが正解になります。
—————————————————–
メッセージが失われず、重複されず、メッセージが到着と同じ順序でEMRで処理されることが要件

-> Kinesis Data Streamsは一連のデータレコードを持つシャードのセットであり、各データレコードにはKinesis Data Streamsによって割り当てられたシーケンス番号があるため、 メッセージが失われず、重複されず、到着と同じ順序で伝送することが可能です。
—————————————————–
—————————————————–
—————————————————–
—————————————————–