この記事について
AWSの公式は認定試験の対策として10問の練習問題を公開している。しかし、それの解説は非常に短く学習者にとってはなんとも言えない気持ちになる。この記事では各問題の解説を詳細に記載した。
公式練習問題集のリンク
解説
ここから解説を書いていきます。
問題1
NATゲートウェイは、プライベートサブネット内の EC2 インスタンスがインターネットにアクセスするための「ゲート(門)」の役割を果たします。通常、プライベートサブネットにあるインスタンスはセキュリティのため、インターネットに直接アクセスできません。しかし、ソフトウェアパッチをダウンロードするには、インターネット接続が必要です。NAT ゲートウェイを構成すると、プライベートサブネット内のインスタンスは NATゲートウェイを通じてインターネットにアクセスできるようになります。この設定により、外部からのアクセスをブロックしつつ、内部からのアクセスのみを許可します。また、インターネットへのトラフィックをNATゲートウェイに向けるためには、プライベートサブネットのルートテーブルを設定する必要があります。これにより、すべてのインターネット向けトラフィックが自動的にNATゲートウェイを経由するようになります。
要点まとめ:
NATゲートウェイは、プライベートサブネット内のインスタンスが安全にインターネットにアクセスするための「中継役」です。ルートテーブルの設定により、インスタンスからのインターネット通信がNATゲートウェイを通るようになります。この仕組みによって、インターネットからの直接アクセスを防ぎながら、必要なインターネットアクセスを確保できます。
問題2
EC2インスタンスを休止状態にすることによって、2週間の一時休業中に発生するコストを削減することができます。休止モードでは、インスタンスのメモリ内容(実行中のアプリケーションや開いているファイルなど)がAmazon Elastic Block Store (EBS)のルートボリュームに保存されます。このモードを利用すると、以下のような動作と料金体系になります。休止モードの動作メモリの保存:休止状態にすることで、インスタンスのメモリ内容はEBSボリュームに保存されます。これは、インスタンスを再開した際に、前回の状態をそのまま復元するために必要です。インスタンスの停止: メモリが保存された後、インスタンスは完全に停止します。停止状態では、CPUやネットワークは使用されず、インスタンスは終了しますが、メモリ内容は保持されます。再起動時の復元:インスタンスを再起動すると、保存されたメモリ内容がEBSボリュームから復元され、インスタンスは以前と同じ状態で作業を再開できます。これは、パソコンの「スリープ」や「休止状態」に似た動作です。料金について計算リソースの料金: 休止モード中は、通常のEC2インスタンスのCPUやRAMなどの計算リソースに対する料金は発生しません。これは、インスタンスが停止状態にある場合と同様です。EBSボリュームの料金: ただし、インスタンスのメモリ内容を保存するために利用しているEBSボリュームには、休止状態であってもストレージ料金が発生します。
問題3
この問題では、プライベートIPアドレスを持つEC2インスタンスに障害が発生した場合に、トラフィックを迅速にスタンバイのEC2インスタンスに切り替えるためのソリューションを設計する必要があります。選択肢Cは、この要件を最も効果的に満たす方法です。
セカンダリElastic Network Interface(ENI)の利用Elastic Network Interface (ENI):
ENIは、AWSにおける仮想ネットワークカードです。EC2インスタンスに複数のENIをアタッチすることで、1つのインスタンスが複数の IPアドレスを持つことが可能になります。セカンダリENIを利用することで、トラフィックの柔軟な管理が可能になります。障害発生時の対応: プライマリEC2インスタンスにセカンダリENIをアタッチしておき、スタンバイインスタンスに障害が発生した場合に備えます。プライマリインスタンスに障害が発生した場合、セカンダリ ENI をプライマリインスタンスからデタッチして、スタンバイのEC2インスタンスにアタッチします。これにより、スタンバイインスタンスが元のプライマリインスタンスと同じIPアドレスを持つことになり、トラフィックは自動的にスタンバイインスタンスに切り替わります。なぜこのアプローチが適しているのか迅速な切り替え:
セカンダリENIを利用することで、障害発生時にネットワークインターフェイスをすぐに別のインスタンスに切り替えることができます。これにより、ダウンタイムを最小限に抑えることができ、モニタリングアプリケーションが速やかに復旧します。プライベートIPの保持:
セカンダリENIを切り替えることで、プライベートIPアドレスが変更されないため、アプリケーションやシステムの他の部分でIPアドレスの変更を考慮する必要がありません。これにより、切り替え後もシームレスにサービスを提供し続けることができます。柔軟なネットワーク管理:ENIは独立したリソースであり、EC2インスタンスのライフサイクルに依存しません。そのため、ENIを自由に移動でき、ネットワークの柔軟性を高めることができます。他の選択肢との比較 選択肢 A:
Application Load Balancer (ALB)を使用する方法ですが、ALBは主にHTTP/HTTPSトラフィックに適しており、TCP/UDPトラフィックや特定のプライベートIPアドレスを必要とする場合には適していません。また、ALBの構成変更には一定の時間がかかるため、迅速な切り替えには不向きです。選択肢 B:
DHCPオプションセットを使用してIPアドレスを再割り当てする方法ですが、これは実現が複雑であり、またIPアドレスの変更が発生するため、既存の接続や設定に影響を与える可能性があります。選択肢 D:
Elastic IPを利用する方法ですが、Elastic IPはパブリックIPアドレスであり、プライベートIPアドレスに依存するこのシナリオでは適していません。
問題4
この問題では、分析会社が提供するウェブ解析サービスのJavaScriptスクリプトが、ユーザーのウェブページからAmazon S3バケットに対して認証済みのGETリクエストを行う必要があります。しかし、通常、ウェブブラウザはセキュリティ上の理由から、異なるドメイン間でのリソース共有を制限します。これを「クロスオリジンリソース共有 (Cross-Origin Resource Sharing, CORS)」と呼びます。CORS(クロスオリジンリソース共有)とは?クロスオリジンリソース共有 (CORS):CORSは、ウェブブラウザが異なるオリジン(ドメイン、プロトコル、ポート)からのリソース (例: API や画像、スタイルシートなど)にアクセスする際の制御を提供するセキュリティ機構です。デフォルトでは、ブラウザはセキュリティの観点から、異なるオリジンからのリソースへのアクセスを制限します。CORS が必要な理由:
サービスが提供されるウェブページと Amazon S3バケットは、異なるオリジンに属している可能性があります。たとえば、ユーザーのウェブページが「example.com」にホストされているのに対し、Amazon S3バケットが「s3.amazonaws.com」にホストされている場合、これは異なるオリジン間の通信となります。この場合、CORS を設定しないと、ブラウザはセキュリティ上の理由でこのリクエストをブロックします。CORSの設定による解決方法 CORS ポリシーの設定:Amazon S3バケットに CORSポリシーを設定することで、指定されたオリジンからのリクエストを許可することができます。具体的には、S3バケットに対して許可されたオリジンからの HTTPリクエスト(この場合は GET リクエスト)を受け入れるためのCORSルールを設定します。HTTP ヘッダーの役割:
CORSを有効にすることで、Amazon S3バケットは特定のHTTPヘッダー(例えば、Access-Control-Allow-Origin)をレスポンスに含め、ブラウザに対してこのリクエストが許可されていることを示します。これにより、ブラウザは異なるオリジン間でのリソース共有を許可し、JavaScript スクリプトが正常に機能するようになります。他の選択肢との比較選択肢B(S3バージョニングを有効にする):
S3バージョニングは、オブジェクトのバージョン管理機能を提供しますが、CORSとは関係がありません。この設定を有効にしても、ブラウザのクロスオリジン制限を回避することはできません。選択肢C(署名付きURLを提供する):
署名付きURLは、認証された一時的なアクセスを提供するための方法ですが、CORSの問題を直接解決するものではありません。署名付き URLを使用しても、CORSが適切に設定されていない場合、ブラウザはリクエストをブロックします。選択肢D(パブリック実行権限を許可するようにバケットポリシーを設定する):
パブリック実行権限を設定することは、誰でも S3 バケットにアクセスできるようにすることで あり、セキュリティリスクを伴います。さらに、この設定はCORSとは直接関連がないため、異な るオリジン間での通信の問題を解決できません。
問題5
顧客提供の暗号化キー(SSE-C)を使用したサーバー側の暗号化SSE-C(Server-SideEncryptionwithCustomer-ProvidedKeys)とは、サーバー側の暗号化であり、データを保存する際にAmazonS3が顧客が提供する暗号化キーを使用してデータを暗号化します。この方法を選択する場合、次のようなプロセスが行われます。
データのアップロード時:顧客はPUTリクエストに暗号化キーを含めます。この暗号化キーは、データを暗号化するために使用されます。AmazonS3は、提供されたキーを使用してデータを暗号化し、クラウドに保存します。データのダウンロード時:GETリクエストを行う際には、再度同じ暗号化キーを提供する必要があります。AmazonS3は、提供されたキーを使用してデータを復号し、リクエストしたユーザーにデータを返します。このプロセスにより、データがクラウド上に保存されている間も、常に顧客が提供したキーを使用してデータが暗号化されることが保証されます。AmazonS3は、暗号化キー自体を保存しないため、顧客がキーを管理する必要があります。
クライアント側の暗号化クライアント側の暗号化では、データは顧客の環境(オンプレミスなど)で暗号化され、その後クラウドにアップロードされます。この方法を選択する場合、次のようなプロセスが行われます。
データの暗号化:データをクラウドにアップロードする前に、顧客自身が持っている暗号化キーを使用してデータを暗号化します。暗号化データのアップロード:暗号化されたデータは、そのままAmazonS3にアップロードされます。クラウド側では追加の暗号化は行われません。データの復号化:ダウンロード後、顧客が保存している暗号化キーを使用してデータを復号化します。クライアント側の暗号化を使用することで、データがクラウドに到達する前に暗号化が行われるため、データの暗号化プロセスに対する完全な制御を維持できます。顧客は暗号化キーを完全に管理でき、クラウドサービスプロバイダは暗号化キーにアクセスできないため、セキュリティが強化されます。
他の選択肢との比較SSE-S3(AmazonS3で管理された暗号化キーを使用したサーバー側の暗号化):AmazonS3が暗号化キーを管理しますが、オンプレミスに保存されたキーを使用する要件を満たしていません。
SSE-KMS(AWSKMSで管理された暗号化キーを使用したサーバー側の暗号化):AWSKeyManagementService(KMS)を使用してキーを管理しますが、キー管理の一部がAWSに委ねられます。これもオンプレミスのキー管理要件を完全には満たしていません。
AWSLambdaを使用してデータを暗号化する:AmazonS3イベントによりトリガーされたLambda関数でデータを暗号化することは可能ですが、S3に保存されたデータを暗号化するための他の手段と比較すると複雑です。また、Lambda関数が実行されるタイミングや設定によっては、要件を完全には満たせない可能性があります。
問題6
オンデマンドインスタンスをデプロイする(選択肢A)オンデマンドインスタンスは、AWSのEC2インスタンスの一種で、必要なときにいつでも起動して利用できる柔軟なリソースです。利用時間に応じて課金されるため、短期間だけリソースを追加したい場合に最適です。
柔軟性:オンデマンドインスタンスは、特定の期間だけリソースを追加するのに最適です。需要が増加する月末の期間中だけ追加のインスタンスをデプロイし、必要なくなったら停止または終了することで、リソースを効率的に管理できます。安定性:オンデマンドインスタンスは、AWSが提供する最も安定したインスタンスの一つです。スポットインスタンスと異なり、中断されるリスクがなく、確実に稼働し続けるため、継続的な処理が求められるジョブに適しています。コスト効率:実行秒数に応じて課金されるため、必要な分だけ支払うことになります。月末の需要増加時のみ利用することで、余分なコストを抑えながらリソースを確保できます。他の選択肢との比較選択肢B(追加のリザーブドインスタンスを予約する):リザーブドインスタンスは長期間使用することでコスト削減効果が得られる一方、初期投資が大きく、短期間の需要増加には向いていません。特に月末だけ一時的に必要なリソースには、コスト効率が悪いです。
選択肢C(スポットインスタンスをデプロイする):スポットインスタンスは、オンデマンドインスタンスよりも低価格で利用できるメリットがありますが、市場価格の変動によってインスタンス
が中断されるリスクがあります。ジョブが中断できないこのシナリオでは、スポットインスタンス
は適切ではありません。
選択肢D(EC2インスタンスのサイズを増やす):リソースの規模を増やすことは一つの方法ですが、これにはリソースの全体的な増強が必要となり、コストが高くなります。また、恒常的な需要増加が見込まれない限り、オンデマンドインスタンスを活用した方が経済的です。
問題7
課題の概要オンライン投票システムでは、ユーザーからの投票がAmazonEC2インスタンスに送られ、そのデータがAmazonRDSデータベースに書き込まれます。しかし、短期間に大量のリクエストが送られてくるため、データベースは全てのリクエストにリアルタイムで対応できなくなります。これにより、データベースの過負荷やシステム全体のパフォーマンス低下が懸念されます。
選択肢C(AmazonSQSとワーカーインスタンスの利用)最も効率的なソリューションとし
て、**AmazonSimpleQueueService(AmazonSQS)**を活用する方法が提案されています。AmazonSQSの役割:
SQSは、メッセージキューイングサービスです。これを利用することで、フロントエンドアプリ
ケーションは投票リクエストを直接データベースに送るのではなく、まずSQSキューにメッセージとして送信します。この手法により、投票データはまずキューに蓄積され、データベースへの書き込み処理を非同期に行うことができます。キューによるバッファリング:
SQSキューに投票データを蓄積することで、データベースへの直接的な負荷が軽減されます。これにより、フロントエンドはデータベースの処理能力に関わらず、リクエストを高速で処理し続けることが可能です。キューを利用することで、リクエストを受け付けるスピードとデータベースがデータを書き込むスピードのギャップを埋めることができ、システム全体のスケーラビリティが向上します。ワーカーインスタンスの役割:
別途プロビジョニングされたワーカーインスタンスが、SQSキューから投票データを定期的に取得し、制御可能な速度でAmazonRDSデータベースに書き込みます。これにより、データベースが過負荷になることなく、安定したパフォーマンスを維持しながら票を処理することが可能になります。ワーカーインスタンスの数や処理速度は、投票リクエストの量に応じてスケーリングすることができます。必要に応じて、複数のワーカーインスタンスを並列で稼働させることで、処理能力をさらに向上させることが可能です。データの信頼性と安全性:
SQSは、高耐久性と冗長性を持つため、投票データが失われるリスクを最小限に抑えることができます。また、SQSはデータを自動的に複数の可用性ゾーンに分散して保存するため、システム障害時でもデータの安全性が確保されます。他の選択肢との比較選択肢A(AWSLambdaとAPIGatewayの利用):AWSLambdaとAPIGatewayを使用して投票リクエストを処理する方法も考えられますが、リアルタイムでの高負荷処理には向いていません。Lambda関数は短時間の処理には適していますが、持続的な大量のデータ処理には限界があり、またステートレスであるため、キューによるバッファリングには適しません。
選択肢B(マルチAZ配置による水平スケーリング):データベースをマルチAZ配置にして水平方向にスケーリングすることで、可用性や冗長性を高めることは可能です。しかし、データベースの書き込み負荷が軽減されるわけではないため、根本的な解決にはなりません。また、プライマリとセカンダリの両方のインスタンスに書き込む設定は一般的ではなく、データ整合性の問題を引き起こす可能性があります。
選択肢D(EventBridgeと大規模インスタンスの再プロビジョニング):投票期間中に大規模なメモリ最適化インスタンスでデータベースを再プロビジョニングする方法は、一時的にリソースを増強することができるものの、手動での再プロビジョニング作業が必要であり、リアルタイムのスケーリングには適していません。また、インスタンスの変更は一時的な解決策であり、処理能力に関する根本的な問題を解決するわけではありません。
問題8
この問題では、企業が現在使用している2層アーキテクチャにおいて、システムの高可用性を実現するための適切なステップについて問われています。現在のアーキテクチャでは、ウェブアプリケーションとデータベースが単一のアベイラビリティーゾーン(AZ)で実行されています。この構成では、特定のAZが障害を起こした場合に、システム全体が停止するリスクがあります。高可用
性を確保するためには、システムが複数のAZにまたがって冗長化される必要があります。選択肢B(複数のAZにまたがるAutoScalingグループとApplicationLoadBalancerの使用)高
可用性の確保:
AutoScalingグループを使用して、ウェブアプリケーションインスタンスを複数のAZにまた
がって展開することで、特定のAZが障害を起こした場合でも、他のAZで実行中のインスタンスが引き続きリクエストを処理できます。これにより、システムの耐障害性が向上し、ダウンタイムを最小限に抑えることができます。ApplicationLoadBalancer(ALB)の利用:
**ApplicationLoadBalancer(ALB)**を設定することで、複数のAZにまたがるウェブアプリケーションインスタンスへのリクエストを自動的に分散させることができます。ALBは、トラフィックを健全なインスタンスにルーティングするため、特定のインスタンスやAZに障害が発生しても、他のインスタンスがリクエストを処理することでサービスが継続されます。メリット:
この構成により、負荷分散が効率的に行われ、ウェブアプリケーションのパフォーマンスと信頼性が向上します。また、AutoScalingによってインスタンスの数が自動的に増減されるため、トラフィックの急激な増加にも柔軟に対応できます。選択肢E(新しいAZにサブネットを作成し、RDSのマルチAZ構成を設定)複数のAZへのデプロイ:
現在の構成では、データベースインスタンスが単一のAZにのみ配置されているため、AZ全体が障害を起こした場合、データベースが利用不能になります。これを避けるため、新しいAZにパブリックサブネットとプライベートサブネットを作成し、データベースをマルチAZ構成にすることが重要です。AmazonRDSマルチAZ構成のメリット:
AmazonRDSのマルチAZ配置では、プライマリデータベースインスタンスと同期的にレプリケーションされるスタンバイインスタンスが、異なるAZに自動的に配置されます。これにより、プライマリインスタンスに障害が発生した場合でも、自動的にスタンバイインスタンスにフェイルオーバーが行われ、データベースの可用性が維持されます。データの整合性と可用性:
マルチAZ構成を使用することで、データの整合性を保ちながら、データベース層の高可用性を実現できます。これにより、システム全体の信頼性が向上し、災害対策の一環としても効果的です。
問題9
この問題では、毎日正午に大量のトラフィックを受信するWebアプリケーションのパフォーマンス問題について扱っています。ユーザーが新しい写真やコンテンツをアップロードする際に、タイムアウトが発生しているため、これを解決するためのアーキテクチャの再設計が求められています。
現在の問題点起動時の遅延:現在の設定では、AmazonEC2AutoScalingグループが使用されていますが、新しいインスタンスがスケールアウトで起動された後、アプリケーションが完全に立ち上がり、リクエストに応答できるようになるまでに約1分かかります。この時間が原因で、トラフィックが急増した際にユーザーリクエストがタイムアウトする可能性があります。選択肢C:ウォームアップ条件でAutoScalingステップスケーリングポリシーを設定するウォームアップ期間:AutoScalingのステップスケーリングポリシーでは、新しく起動されたEC2インスタンスが、スケーリングメトリクスに影響を与え始める前に必要なウォームアップ時間を指定できます。この時間は、インスタンスがリクエストに対して完全に応答可能な状態になるまでの準備期間を示します。
ウォームアップ期間中の挙動:ウォームアップ期間中、AutoScalingは新たに起動したインスタ
ンスをまだ「有効なキャパシティ」としてカウントしません。つまり、AutoScalingはウォームアップ中のインスタンスを含まずにスケールアウトやスケールインの判断を行います。これにより、すべてのインスタンスが完全に稼働可能な状態になるまで、さらに新しいインスタンスを追加し続けることを防ぎます。
スケーリングの効率化:これにより、システムが必要以上にスケールアウトするのを防ぎ、無駄なリソースの消費や過度なスケーリングによるコストの増加を抑えることができます。ウォームアップ時間を適切に設定することで、新しいインスタンスがリクエストを処理できる状態になるまでのタイミングを制御できるため、ユーザーのタイムアウトを減少させることが期待されます。
他の選択肢との比較選択肢A(NetworkLoadBalancerのスロースタート設定):
スロースタートは、ロードバランサーが新しいターゲットに対してリクエストを徐々に増加させる機能ですが、現在の問題である「新しいインスタンスが準備完了になるまでの遅延」を直接解決するものではありません。選択肢B(ElastiCacheforRedisの設定):
ElastiCacheは、データベースやその他のストレージシステムに対するリクエストのオフロードに役立ちますが、今回の問題はインスタンスの起動時間に関するものであり、ElastiCacheはその遅延を解決するものではありません。選択肢D(AmazonCloudFrontの設定):
CloudFrontは、コンテンツのキャッシングと配信を効率化するサービスですが、インスタンスの起動遅延の問題には直接関係しません。
問題10
この問題では、AmazonAuroraマルチAZデプロイメントを使用しているアプリケーションで、データベースの読み取り要求が増加した結果、I/O負荷が高まり、書き込み要求のレイテンシーが増大しているという課題が示されています。これに対する解決策を見つけることが求められています。
課題の詳細読み取り要求の増加:データベースに対する読み取り要求が増加すると、データベースのI/O負荷が増大します。この負荷が高まると、書き込み要求に対するリソースが圧迫され、結果として書き込みのレイテンシーが増加します。書き込み要求の遅延:書き込み要求のレイテンシーが増加することは、データの整合性やアプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。そのため、読み取りと書き込みの負荷を分けて管理することが重要です。選択肢C:Auroraレプリカを作成し、適切なエンドポイントを使用するようにアプリケーションを変更するAuroraレプリカとは:Auroraレプリカは、AmazonAuroraデータベースクラスター内で追加の読み取り専用インスタンスを提供する機能です。これにより、読み取り要求をメインデータベースインスタンスからオフロードし、書き込み専用にメインインスタンスのリソースを集中させることができます。
読み取りトラフィックのオフロード:Auroraレプリカを作成することで、アプリケーションの
読み取り要求を専用の読み取りインスタンスに振り分けることができます。これにより、メインデータベースは書き込み操作に専念でき、書き込みパフォーマンスの向上が期待されます。
低レイテンシー:Auroraレプリカは、メインデータベースと同じ基本ストレージを共有しており、通常はレプリケーションによる遅延が非常に少ないです。そのため、ユーザーに対してほぼリアルタイムのデータを提供できます。
エンドポイントの設定:Auroraクラスターでは、読み取り専用のエンドポイントを設定できます。このエンドポイントに対して読み取り要求を送ることで、Auroraレプリカに負荷を分散させることが可能です。アプリケーション側でこのエンドポイントを利用するように設定を変更する必要があります。
他の選択肢との比較選択肢A(リードスルーキャッシュを有効にする):
リードスルーキャッシュは、読み取りキャッシュのパフォーマンスを向上させる手段ですが、読み取り負荷をメインデータベースから完全にオフロードするものではありません。高い読み取り要求が続く場合、根本的な解決策とはなりません。選択肢B(マルチAZスタンバイインスタンスから読み取る):
マルチAZスタンバイインスタンスは、通常は障害時のフェイルオーバーを目的として設計されています。読み取り要求をスタンバイインスタンスに送ることは、スタンバイインスタンスがフェイルオーバーの役割を果たせなくなるリスクを伴うため、推奨されません。選択肢D(2つ目のAuroraデータベースを作成し、リードレプリカとしてリンクする):
新たに2つ目のAuroraデータベースを作成することは、コストが高く、運用が複雑になる可能性があります。また、Auroraレプリカを利用する方が、同じ基本ストレージを共有するため、レプリケーションの遅延が少なくなります。