AWS SAA試験は、AWSを使ったシステム設計の知識を証明するもので、クラウド環境でスケーラブルで耐障害性が高く、コスト効率の高いソリューションを設計する能力が求められます。この資格を取得することで、企業がAWSクラウド上で適切なアーキテクチャを構築できるスキルがあることを示すことができます。SAAレベルの練習問題を繰り返し解いて試験に備えましょう。2つ目の無料の練習問題は10問です。
第1問: グローバルメディア企業におけるVPC間トラフィック検査の実現
あるグローバルメディア企業は、AWS上にホストされた動画配信アプリケーションを運用しています。フロントエンドのウェブサーバーはパブリックサブネット、メディア変換用のアプリケーションサーバーとデータベースはプライベートサブネットに配置された3層アーキテクチャです。同社は、AWS Marketplaceで購入したサードパーティの仮想ファイアウォールアプライアンスを別のVPC（検査VPC）にデプロイしました。すべてのインバウンドトラフィックがウェブサーバーに到達する前に、このアプライアンスを通してパケット検査を行い、セキュリティを強化したいと考えています。同時に、運用上のオーバーヘッドは最小限に抑えたい場合、どのソリューションが適していますか？
正解: 1. 検査VPCにゲートウェイロードバランサーをデプロイし、アプリケーションVPC側でゲートウェイロードバランサーエンドポイントを作成してインバウンドトラフィックをファイアウォールアプライアンス経由で検査する。
ゲートウェイロードバランサー（GWLB）とゲートウェイロードバランサーエンドポイント（GWLBE）は、仮想ファイアウォールアプライアンスなどのサードパーティ製ネットワーク機能を透過的かつスケーラブルに導入するためのサービスです。GWLBを検査VPCにデプロイし、アプリケーションVPC側でGWLBEを作成することで、インバウンドトラフィックを自動的にファイアウォールアプライアンスへ転送できます。これにより、追加のルーティングやカスタムスクリプトをほとんど必要とせず、運用オーバーヘッドを最小化できます。
他の選択肢
- Network Load Balancerを使用してカスタムルーティングを行う場合、追加のルート設定や管理が複雑になります。
- Application Load BalancerとLambda@Edgeの組み合わせは、HTTP層での処理には適していても、パケットレベルの検査には不向きです。
- Transit Gatewayを使用して全トラフィックを集約する方法は可能ですが、設定が複雑になり、追加の運用コストが増加します。
第2問: 急増するクエリリクエストからAPIバックエンドを保護する方法
あるデータ分析サービス提供企業は、AWS LambdaとAmazon API Gatewayを使用して、ユーザーがオンデマンドで分析クエリを実行できるAPIを構築しています。最近、大型イベントに関連するデータ分析需要が急増し、数日間で多くの新規ユーザーとクエリリクエストが押し寄せると予想されています。これにより、APIバックエンドに高負荷がかかる可能性があります。このシナリオでは、バックエンドシステムを過剰な負荷からどのように保護すべきでしょうか？
正解: 4. Amazon API Gatewayでスロットリングを有効にし、結果キャッシュを使用して過剰なリクエストを緩和する。
API Gatewayでスロットリングを有効にすることで、特定の時間あたりのリクエスト数を制限し、バックエンドへの過剰な負荷を防止できます。また、結果キャッシュを使用すると、同じクエリに対してキャッシュ済みのレスポンスを返すため、Lambda関数への呼び出し回数を減らし、コストと負荷を抑えることが可能です。
他の選択肢
- CloudFrontは静的コンテンツや一部の動的コンテンツをキャッシュできますが、リアルタイム性が求められる分析クエリには適していません。また、全ての動的クエリを効率的にキャッシュすることは困難です。
- EC2インスタンスへの移行は、インフラ管理のオーバーヘッドが増加し、サーバーレスの利点を失います。また、Auto Scalingを適用しても、スパイク時の短期的な負荷には対応が難しくなります。
- AWS WAFはセキュリティ要件に対しては有用ですが、リクエストスロットリングや結果のキャッシュには直接関与しません。
第3問: 複数リージョンでホストされたバックエンドへのグローバルなトラフィック分散方法
ある動画ストリーミング企業は、AWS上で複数のリージョンにわたってサービスを提供しています。ユーザーはアジア圏とヨーロッパ圏に集中しており、同社はap-northeast-1リージョンとeu-central-1リージョンにそれぞれ3台ずつのEC2インスタンスを起動し、各リージョンでNetwork Load Balancer（NLB）を構成しています。これら2つのNLBを効率的に利用して、ユーザーが最も近いリージョンのバックエンドリソースにアクセスできるようにし、パフォーマンスと可用性を向上させたいと考えています。運用上のオーバーヘッドを最小化しつつ、どのようなソリューションを使用すればよいでしょうか？
正解: 2. AWS Global Acceleratorを使用して標準アクセラレーターを作成し、ap-northeast-1とeu-central-1にエンドポイントグループを設定し、各エンドポイントグループのエンドポイントとして2つのNLBを追加する。
AWS Global Acceleratorは、グローバルなエンドポイントへのアクセスを最適化し、ユーザーに最も近いリージョンへトラフィックを誘導するためのサービスです。標準アクセラレーターを作成し、複数のエンドポイントグループを設定することで、ユーザーは低遅延で最適なバックエンドにアクセスできます。NLBをエンドポイントとして追加することで、バックエンドインフラに対する運用上のオーバーヘッドを最小限に抑えつつ、パフォーマンスと可用性を向上できます。
他の選択肢
- Route 53のジオロケーションルーティングは地理的な分配は可能ですが、AWS Global Acceleratorほど動的な最適ルーティングやパフォーマンス向上機能はありません。
- ALBやWAFを使用しても、グローバルな最適ルーティングや低遅延の実現には不十分であり、設定が複雑になります。
- CloudFrontは主に静的コンテンツ配信や一部のキャッシュ可能な動的コンテンツに有用ですが、NLBへの直接ルーティングやグローバルな動的最適化にはAWS Global Acceleratorが適しています。
第4問: 短期間の計算負荷増大に対するEC2キャパシティー保証の実現方法
ある医薬品開発企業は、新薬候補の大規模な分子シミュレーションを実行するために、一時的に大きな計算リソースを必要としています。計算ジョブは約1週間続く予定で、特定のAWSリージョン内の特定の3つのアベイラビリティゾーンにおいて、一定のEC2インスタンスキャパシティーを確保したいと考えています。オンデマンドで必要な期間だけ確実にリソースを利用できるようにするには、どのアプローチが最適でしょうか？
正解: 4. 必要なリージョンと3つのアベイラビリティゾーンを指定してオンデマンドキャパシティー予約を作成する
オンデマンドキャパシティー予約は、特定のリージョンとアベイラビリティゾーンで必要な期間、必要な数のインスタンスキャパシティーを確保することができます。これにより、短期的なジョブやイベント期間中に確実なリソース利用が可能となり、リザーブドインスタンスのように長期間のコミットやスポットインスタンスのような価格と可用性の変動を気にする必要がありません。
他の選択肢
- リザーブドインスタンスは特定の期間（1年または3年）にコミットし、コスト削減できますが、短期的な需要には不向きです。
- 必要なリージョンのみを指定するオンデマンドキャパシティー予約では、特定のAZに対する確実なキャパシティ保証ができません。
- スポットインスタンスはコストは低いものの、いつでも中断される可能性があり、確実なキャパシティーが必要な場合には適していません。
第5問: 医療記録のAWS上での暗号化と鍵管理方法の選択
ある医療サービス提供企業は、患者記録をAmazon S3に保存する計画を立てています。これらのデータはコンプライアンス上、保存時に暗号化する必要があり、使用された暗号化キーの使用状況をログに記録することが求められています。また、セキュリティ上の理由から暗号化キーは自動的に定期的なローテーションが行われる必要があります。運用の負担を最小限に抑えつつ、これらの要件を満たすためにはどのソリューションが適していますか？
正解: 1. 顧客管理のAWS KMSキー（CMK）を使用し、SSE-KMSで自動キーのローテーションを有効にする
AWS KMSを使用したSSE-KMSによる暗号化を選択することで、データを保管中に強固に暗号化し、KMSキーの使用状況をCloudTrailログで監査できます。また、KMSキー（CMK）の自動ローテーション機能を有効にすることで、キーの定期的な更新が自動で行われ、運用上の手間を減らしながらコンプライアンス要件を満たします。
他の選択肢
- 顧客が独自に管理するキー（SSE-C）は、キー管理およびローテーションが顧客側で必要となり、運用負荷が増大します。
- SSE-S3はキー管理が自動化されますが、KMSキーほど詳細なログやキーの自動ローテーション機能はありません。
- 手動キー管理では、年に一度の手動ローテーションと運用コスト増大が発生し、自動化による効率化が得られません。
第6問: 自動データ処理と機械学習パイプライン起動のための最適なアーキテクチャ
ある金融分析企業は、毎日取引データを格納するために「ingest」S3バケットを使用しています。これらのファイルは、正規化や検証などの前処理を行った後、「analysis」S3バケットに移動して、さらなる分析に供する必要があります。また、パターンマッチング処理をLambdaで実行したいと考えています。さらに、前処理済みデータをAmazon SageMaker Pipelinesに投入し、機械学習モデルによる予測を自動的に実行したいという要件があります。これらすべてを最小限の運用オーバーヘッドで実現するには、どのような構成が最適でしょうか？
正解: 4. ingestバケットにS3イベント通知を作成し、ファイル到着時にLambda関数を起動してデータを処理し、analysisバケットにコピーする。analysisバケットにもS3イベント通知を設定し、ファイル配置時にLambda関数を起動してSageMaker Pipelinesを開始する。
最小限の運用オーバーヘッドで複数ステップの処理パイプラインを構築するには、S3イベント通知を活用し、Lambda関数をチェーンするアプローチが適しています。まず、ingestバケットにファイルが到着すると、S3イベント通知をトリガーにLambdaが起動し、データを処理（パターンマッチングや正規化など）した上でanalysisバケットに配置します。次に、analysisバケットへのファイル配置をトリガーに別のS3イベント通知を設定し、このイベントで起動されるLambda関数がSageMaker Pipelinesを実行します。これにより、フルマネージドなサーバーレス構成が実現し、人的コストや複雑なオペレーションを最小限に抑えつつ、要件を満たすことが可能です。
他の選択肢
- SNSやEventBridgeによる間接的な通知は可能ですが、本シナリオでは直接S3イベント通知とLambdaを組み合わせる方がシンプルかつオーバーヘッドが少ないです。
- S3レプリケーションはバケット間でのデータ同期には有効ですが、ファイル処理やSageMakerパイプライン起動といった追加ステップには別途処理が必要になります。
- CloudFrontやAWS Configを組み合わせても、本来の要件であるシンプルなサーバーレス処理チェーンには不必要で、構成が複雑になるためオーバーヘッドが増えます。
第7問: フルマネージドなコンテナ運用基盤の選択
あるゲーム開発会社は、新しいオンラインゲームのマッチングサーバーをコンテナ化してAWS上で実行したいと考えています。このゲームは世界中のユーザーを対象としており、同時接続数が大きく増減します。開発チームは、ゲームロジックやマッチングアルゴリズムの改善に集中したいと思っており、コンテナを実行するためのサーバー管理やインフラストラクチャのプロビジョニング、パッチ適用などの手間を避けたいと考えています。この要件を満たし、最小限の運用上のオーバーヘッドでコンテナを実行するには、どのオプションが最適でしょうか？
正解: 3. AWS Fargateを使用してAmazon Elastic Container Service（ECS）上でコンテナを実行する
AWS Fargateは、サーバーレスなコンテナ実行環境であり、EC2インスタンスの管理やプロビジョニングを行う必要がありません。これにより、開発チームはサーバー管理のオーバーヘッドから解放され、アプリケーションやゲームロジックに集中できます。ECSとFargateを組み合わせることで、コンテナのスケーリングや可用性も自動的に処理され、変動するトラフィックに対応できます。
他の選択肢
- EC2インスタンスにDockerをインストールする場合、インスタンスのライフサイクル管理やスケーリング、パッチ適用といった運用負荷が発生します。
- 自社データセンターでKubernetesクラスターを構築し、AWSとの接続を行うと、インフラ管理やKubernetesの運用が複雑になり、目標である運用負荷軽減を実現できません。
- EKS上でEC2ワーカーノードを使用する場合、EC2インスタンスの管理は必要になり、完全なサーバーレス運用にはなりません。
第8問: 最小コストかつ安全性を確保したリモート管理用EC2インスタンスの構築方法
あるスタートアップ企業は、AWS上でテスト用の小規模な開発環境を運用しています。この環境に対して、運用担当者がメンテナンスやトラブルシューティングの際にSSHで接続する必要があります。しかし、コストは極力抑えつつ、安全なアクセス手段を確保したいと考えています。運用担当者は1名のみで、特定の固定IPアドレスからのアクセスだけを許可したい場合、どのような構成が最も適していますか？
正解: 1. 小規模なEC2インスタンスを起動し、セキュリティグループで22番ポートへのインバウンドアクセスを固定IPアドレスからのみに制限する
コストを抑えるためには小規模（低スペック）のEC2インスタンスを選択します。また、セキュリティ上、特定の管理者のみがアクセスする場合には固定IPアドレスからのアクセスだけを許可します。セキュリティグループでインバウンドトラフィックを22番ポート（SSH）に限定し、ソースを特定のIPアドレスに絞ることで、不要なアクセスを防ぎながら必要な管理アクセスを確保できます。
他の選択肢
- 大規模なEC2インスタンスはコスト増につながり、また全てのIPからのアクセス許可はセキュリティリスクとなります。
- 小規模なインスタンスを用いても、全てのIPから22番ポートを許可すると、攻撃リスクが高まります。
- 中規模なインスタンスでCIDRブロック単位の制限をしても、特定の固定IPアドレスに限定しない場合は想定より広い範囲からアクセスが可能となり、最小コストかつ最大限のセキュリティとは言えません。
第9問: MySQLデータベース移行時の最適なEBSボリュームタイプ選択
あるソフトウェア企業は、オンプレミスで稼働中のMySQLデータベースをAWSに移行する計画を立てています。このデータベースは日中は通常の読み書きが行われ、夜間には集計やレポート生成などのバッチ処理で負荷が高まります。データ量は最大で450GBほどで、使用するEBSボリュームはシステムのブートボリュームとしても使用できる必要があります。性能とコストを両立しつつ、このシナリオで最適なEBSストレージタイプはどれでしょうか？
正解: 2. Amazon EBS汎用SSD（gp2）
Amazon EBS汎用SSD（gp2）は、ブートボリュームとして使用でき、汎用的なパフォーマンスとコスト効率を兼ね備えています。MySQLデータベースの定常的なワークロードや夜間のピーク処理に対しても、十分なI/O性能を提供します。一方で、HDDベースのst1やsc1はブートボリュームに使用できず、io1は高性能ですがコストが高くなります。
他の選択肢
- プロビジョンドIOPS SSD（io1）は高いIOPS性能を提供しますが、コストが高く、今回の要件ではオーバースペックとなります。
- スループット最適化HDD（st1）は大規模なシーケンシャルアクセスに適していますが、ブートボリュームとして利用できず、SSDほど低レイテンシではありません。
- コールドHDD（sc1）は最も低コストですが、ブートボリュームとして利用できず、性能面でデータベース用としては不十分です。
第10問: オンプレミスからの安全なSSHアクセスを実現するEC2インスタンスセキュリティグループ構成
ある研究機関は、AWS上でデータ分析用のデータベースサーバー（Linuxベース）をプライベートサブネットに配置し、管理用の踏み台ホストをパブリックサブネットに配置しました。オンプレミスのネットワーク管理者は、SSHを使用して踏み台ホスト経由でデータベースサーバーにアクセスしたいと考えています。セキュリティポリシー上、インターネット経由で踏み台ホストにアクセス可能なのは、この管理者が利用する特定の外部IPアドレスのみであり、データベースサーバーには踏み台ホスト経由でのみSSHアクセスが許可されなければなりません。これらの要件を満たすには、セキュリティグループをどのように構成するべきでしょうか。（2つ選択してください）
正解: 1. 踏み台ホストのセキュリティグループで、管理者の外部固定IPアドレスのみから22番ポートへのインバウンドアクセスを許可する, 4. データベースサーバーのセキュリティグループで、踏み台ホストのセキュリティグループからのみ22番ポートへのインバウンドアクセスを許可する
踏み台ホストへのインバウンドアクセスを特定の外部固定IPアドレスに限定することで、不正なアクセスを防止できます。また、データベースサーバー側では、踏み台ホストのセキュリティグループを信頼元として指定することで、踏み台ホスト経由でのみSSH接続が可能になります。これにより、オンプレミスの管理者は安全に踏み台ホスト経由でデータベースサーバーにアクセスできます。
他の選択肢
- すべてのIPから踏み台ホストにアクセスを許可すると不正アクセスのリスクが増加します。
- データベースサーバーで外部IPからの直接アクセスを許可すると、踏み台ホストを経由しない経路が生まれ、要件を満たしません。
- AWS内の任意のIPからのアクセスを許可しても、制御が曖昧になり、セキュリティ要件を満たせません。