AWS SAA試験は、AWSを使ったシステム設計の知識を証明するもので、クラウド環境でスケーラブルで耐障害性が高く、コスト効率の高いソリューションを設計する能力が求められます。この資格を取得することで、企業がAWSクラウド上で適切なアーキテクチャを構築できるスキルがあることを示すことができます。SAAレベルの練習問題を繰り返し解いて試験に備えましょう。無料の練習問題は10問です。
第1問: RedshiftクラスタのAPIコール監査とコンプライアンス対策の最適解
ある小売企業は、Amazon Redshiftを用いたデータウェアハウス上で販売データの分析を行っています。内部監査と外部規制への対応のため、RedshiftクラスターへのAPI呼び出し（クラスターの作成、変更、削除、スナップショット操作など）をすべて追跡し、ログとして保存する必要があります。ログはコンプライアンス監査時に提出可能な形で保持することが求められます。これらの要件を満たすにはどのAWSサービスを利用するのが最適でしょうか？
正解: 4. AWS CloudTrailを使用してRedshiftクラスターのAPI呼び出しを記録する
AWS CloudTrailは、AWSアカウント内で行われるAPIコールを記録・保存するサービスであり、Redshiftクラスターに対する管理系操作（作成、変更、削除など）を含むAPI呼び出しをログとして残すことができます。これにより、コンプライアンス監査に必要な情報を容易に取得できます。また、CloudTrailログは安全なストレージであるS3に保存可能で、必要に応じて外部監査に対応できます。
他の選択肢
- Redshift SpectrumはS3上のデータをRedshift SQLでクエリするための機能であり、APIコールの監査目的には適していません。
- CloudWatchはパフォーマンスメトリクスやイベントのアラート用途であり、APIコール自体の詳細な監査ログには不向きです。
- X-Rayは分散トレーシングツールで、主にアプリケーション全体のリクエストフローやレイテンシー解析に用いられます。Redshiftの管理APIコール監査には適しません。
第2問: オンプレミスアプリケーションへのクラウド拡張ストレージソリューション選択
ある医療研究所は、患者の医療画像データをオンプレミスデータセンターに保管しています。新たな研究プロジェクトにより、これらの画像データは大幅に増加する見込みです。多くのデータは履歴的なもので、普段はほとんど参照されませんが、新しい検査データや最近の画像は頻繁に分析され、低レイテンシでアクセスできる必要があります。研究所はオンプレミスのストレージ容量を無制限に拡張することを避けつつ、iSCSIインターフェイスを通じてクラウド上にバックアップされたストレージボリュームをマウントし、必要に応じて最新データをすぐに利用できるようにしたいと考えています。この要件を満たすにはどのAWS Storage Gatewayタイプを選ぶべきでしょうか？
正解: 3. キャッシュモードのボリュームゲートウェイを使用する
キャッシュモードのボリュームゲートウェイは、オンプレミスでよくアクセスされる最新データをローカルキャッシュとして保持しながら、実質的にはクラウド（Amazon S3）上にメインのデータセットを置くことが可能です。これにより、オンプレミスのストレージ拡張を抑えつつ、必要なデータに対しては低レイテンシアクセスを確保できます。
他の選択肢
- ストアドモードのボリュームゲートウェイは、オンプレミスに全データを保持し、バックアップ的にクラウドを使用するため、ストレージコスト削減とクラウド活用の点で最適ではありません。
- テープゲートウェイはアーカイブやバックアップ用の仮想テープライブラリを提供しますが、頻繁なアクセスが必要なデータへの低レイテンシ要求には適していません。
- ファイルゲートウェイはNFSやSMBプロトコル経由でアクセスする仕組みであり、問題の要件であるiSCSIデバイスやブロックストレージへの低レイテンシアクセス要件には直接合致しません。
第3問: Route 53を用いたDR環境への自動DNSフェイルオーバー設計
あるゲノム解析企業は、Amazon ECS上で稼働するHPCワークロードを本番リージョンとDRリージョンで構成しています。両リージョンは同様のアプリケーションスタックを持ち、本番リージョンが利用不可能になった場合にはDRリージョンへ自動的にトラフィックを切り替える必要があります。エンドユーザーが利用するアプリケーションはDNS名を介してアクセスしますが、プライマリがダウンした際にDR環境へフェイルオーバーするためには、最小限の運用手間でどのようなアプローチをとるべきでしょうか？
正解: 2. プライマリ環境のエンドポイントにRoute 53のフェイルオーバールーティングポリシーとヘルスチェックを設定し、プライマリが異常な場合に自動的にDRリージョンへDNSクエリを転送する
Route 53のフェイルオーバールーティングポリシーは、プライマリ環境にヘルスチェックを設定することで、その環境がダウンした際に自動的にDR環境へDNSクエリを振り分けることが可能です。これにより、外部からのアクセスは同一のDNS名を用いてDR環境に誘導され、オペレーションコストを最小限に抑えつつ自動的なフェイルオーバーを実現できます。
他の選択肢
- CloudFrontは主にコンテンツ配信向けであり、フェイルオーバー制御は限定的です。
- CloudWatch EventsとLambdaによる手動レコード書き換えは自動化可能ですが、運用・管理が複雑になり、Route 53のフェイルオーバールーティングほど簡潔ではありません。
- AWS Global Acceleratorはグローバルエッジネットワークによるパフォーマンス向上やエンドポイントヘルスチェックを行えますが、DNSレベルでのフェイルオーバー構成を求める今回の要件にはRoute 53フェイルオーバーのほうがシンプルかつ適切です。
第4問: 5Gエッジでの低レイテンシEKSデプロイとロールベースアクセス制御の実現方法
あるゲーム開発企業は、新たなクラウドゲーミングプラットフォームを5Gネットワークのエッジで実行することで、超低レイテンシ（1桁ミリ秒）を実現しようとしています。ゲームサーバーはコンテナ化されており、Amazon EKS上でKubernetesクラスターとしてホストする計画です。開発チームはIAMユーザーに対するロールベースアクセス制御（RBAC）を有効にし、クラスターへの認証には適切なロールマッピングを行いたいと考えています。高いパフォーマンスと認証設定を同時に満たすには、どのような構成が最適でしょうか？
正解: 2. アプリケーションをAmazon EKSクラスター上にデプロイし、AWS Wavelengthゾーン内でEKSノードグループを作成する。aws-auth ConfigMapをクラスターに適用してIAMロールとKubernetes RBACを紐づける。
Wavelengthゾーンは5Gエッジでの超低レイテンシを実現するための仕組みであり、EKSクラスターをWavelengthゾーン内にデプロイすることで、ユーザーがエッジに近い場所でコンテナ化されたゲームサーバーにアクセスできます。また、aws-auth ConfigMapを使用してIAMロールとKubernetes RBACを連携することで、IAMユーザーに対するアクセスコントロールを容易に管理できます。この組み合わせは、低レイテンシと認証要件の両方を満たす最適なソリューションとなります
他の選択肢
- CloudFrontは主にコンテンツ配信を最適化しますが、Wavelengthゾーンでの超低レイテンシなコンテナ実行やEKSでのRBAC管理には直接関係がありません。
- Wavelengthゾーンと無関係なAZにノードグループを置くと、エッジでの低レイテンシ効果が得られず、RBAC管理は外部ツールでは非効率です。
- EC2上で手動構築したKubernetesでは、EKSのマネージド特性やaws-auth ConfigMapによる簡易RBAC連携が得られず、運用コストが増加します
第5問: コンテナ環境での暗号化証明書管理と高可用ストレージの最適化
あるメディア配信会社は、動画ストリーミング用の暗号化キーと関連証明書をAmazon ECS上で稼働するコンテナ化アプリケーションからほぼリアルタイムで取得し、他のサービスと安全に通信する必要があります。この暗号化・復号操作は高度に安全であることが求められ、暗号化済みのキーや証明書は可用性の高いストレージに保管されなければなりません。同時に、インフラ管理や手動プロセスの最小化も重要視しています。これらの要件を満たすには、どの方法が最適でしょうか？
正解: 4. AWS KMSでカスタマーマネージドキーを作成し、EC2ロールを介してECSタスクがKMSキーを使用可能にする。暗号化済みデータをAmazon S3に保存する
AWS KMSを用いて暗号化キーをセキュアに管理し、EC2ロール（タスクロール）を用いることでECSタスクからKMSキーを使用した暗号化・復号操作が可能になります。また、暗号化済みデータをAmazon S3に保管することで高可用性と耐久性が確保され、運用上の手間を最小限に抑えながらセキュリティとスケーラビリティを維持できます。
他の選択肢
- EBSスナップショットへの手動保存は自動化が難しく、運用上の負担が増えます。
- Secrets Managerでの手動更新シークレットは、頻繁な更新が必要な場合に運用コストが増加し、KMSとの直接連携で得られるリアルタイム性が損なわれます。
- Lambda関数とDynamoDBの組み合わせは可能ですが、KMSキーによる自動的かつシームレスな暗号化フローと比べて、設計と管理が複雑化します。
第6問: Kinesisストリームからのデータ欠落とデフォルト保持期間に関する問題
ある観光分析会社は、公園内に設置したセンサーから訪問者数データを取得し、Amazon Kinesisを用いてリアルタイムにストリームへ送信しています。データは1日おきにバッチ処理する予定で、Amazon S3に蓄積する設計です。しかし、S3側でデータが一部欠落していることが判明しました。センサーは確実に1日分のデータをKinesisストリームに送信していることを確認したにもかかわらず、なぜデータがすべてS3に取り込まれないのでしょうか？
正解: 3. デフォルトのKinesisデータストリーム保持期間が24時間であり、1日おきの処理時には一部のデータが期限切れとなっている
Amazon Kinesisデータストリームはデフォルトで24時間のデータ保持期間を持ちます。1日おきにデータ処理を行う場合、24時間以上経過したデータはストリームから読み出せず、結果としてS3に取り込めないデータが発生します。対策としては、データ保持期間を延長したり、処理スケジュールを短くするなどが考えられます。
他の選択肢
- センサーの動作は確認済みであり、データは正しく送信されています。
- S3はライフサイクルルールを設定しない限り自動移動しませんし、24時間以内のデータで欠落は説明できません。
- この状況でハッキングを疑うよりも、Kinesisの保持期間が合理的な原因です。
第7問: SNSからの通知が不安定な場合でも確実なデータ取り込みを実現する方法
ある流通企業は、新商品情報が登録されるたびにAmazon SNSトピックを通じて通知を受け取り、AWS Lambda関数でメタデータを処理し、データウェアハウスに取り込みを行っています。しかし、ネットワーク接続の不安定さが原因で、時々Lambda関数が通知を受け取り損ね、データが取り込まれないケースが発生しています。手動でジョブを再実行しない限り、その失われた通知分のデータは処理されません。このような状況を防ぎ、全ての通知データを確実に取り込むには、どのような対策を取るべきでしょうか？（2つ選択してください）
正解: 1. Amazon SQSキューを作成し、SNSトピックにサブスクライブする, 5. Lambda関数をSQSキューからメッセージを読み取るように変更する
SNSから直接Lambdaをトリガーしている場合、ネットワーク障害などによって一度イベントを取り逃がすと再取得が困難になります。SQSをSNSにサブスクライブさせることで、通知はSQSキューに堆積され、Lambdaはキューから確実にメッセージを読み取れるため、信頼性が向上します。これにより、障害発生時にもデータのロストを防ぎ、後から確実に処理することが可能になります。
他の選択肢
- Lambda実行メモリやプロビジョンド同時実行数の増加は、パフォーマンス向上には役立ちますが、通知ロストを防ぐ仕組みにはなりません。
- 複数AZでLambdaを設定しても、単一リージョン内ではLambdaはすでに高可用性であり、SNSイベントロストの問題を解決できません。
第8問: Oracleデータベースの高可用性維持とAWSへの迅速な移行方法
あるオンライン決済サービス提供企業は、オンプレミスで稼働中のOracleデータベースを使用する金融取引分析アプリケーションをAWSへ緊急移行する必要があります。アプリケーションはグローバルに分散したユーザーから毎分頻繁にデータを受け取り、処理と保存を行っています。移行後は、データベースインスタンスに万一の障害が発生しても可用性を維持し、アプリケーションを中断なく継続運用できることが求められます。これらの要件を最も効果的に満たすソリューションはどれでしょうか？
正解: 1. RDSでマルチAZ構成のOracleデータベースを作成する
RDSでマルチAZ構成を使用したOracleデータベースは、AWS上で高可用性を簡易かつ自動的に実現する標準的な方法です。マルチAZ構成ではプライマリインスタンスの障害時にスタンバイインスタンスに自動フェイルオーバーが行われ、アプリケーションを中断することなく稼働を続けることができます。これにより、移行後も金融取引分析アプリケーションへの影響を最小限に抑え、パフォーマンスと可用性を確保できます。
他の選択肢
- AWS Schema Conversion ToolとDMSでAuroraに変換する場合、Oracle固有の機能が非互換となる可能性があり、またAuroraはOracle互換ではないため即時移行には向きません。
- RACはRDS上でサポートされていません。
- RMANはバックアップ・リカバリツールであり、高可用性構成を自動的に実現するものではありません。単一インスタンスではフェイルオーバーによる可用性向上ができません。
第9問: Auto Scalingで使用中のAMIを新しいイメージへ切り替える方法
あるオンライン学習企業は、需要に応じてEC2インスタンスを増減させるため、Auto Scalingグループを活用しています。アプリケーションの更新に伴い、新しいAmazon Machine Image（AMI）を使って今後起動するEC2インスタンスを刷新したいと考えています。現在のAuto Scalingグループを継続的に利用しつつ、新たなAMIを用いるには、どのような手順を踏めばよいでしょうか？
正解: 3. 新しい起動構成（Launch Configuration）または起動テンプレートを作成し、その中で新しいAMIを指定する
Auto Scalingグループは起動構成（または起動テンプレート）を参照してインスタンスを起動します。起動構成は不変であり、一度作成するとAMIなどの設定を変更できません。そのため、新たなAMIを使用するには新しい起動構成（または起動テンプレート）を作成し、Auto Scalingグループを更新してその新しい起動構成を参照させる必要があります。
他の選択肢
- 既存の起動構成を変更することはできません。新たな起動構成の作成が必要です。
- ターゲットグループはトラフィックの振り分け先を定義するもので、AMI変更とは無関係です。
- Auto Scalingグループ自身に直接AMIを割り当てることはできず、必ず起動構成や起動テンプレートを介して指定します。
第10問: SQSメッセージの再処理メカニズムについて
あるニュース配信サービスでは、新しい記事が公開されるたびにAmazon SNSトピックへメッセージを送信し、このメッセージを複数のAmazon SQSキューへファンアウトさせています。これらのキューからは、スポットEC2インスタンスがメッセージを取得して記事メタデータを処理しています。ある日、EC2インスタンスがメッセージを処理中に突然終了し、処理が最後まで完了しませんでした。この場合、該当するSQSメッセージはどのような挙動を取りますか？
正解: 4. メッセージの可視性タイムアウトが切れると、メッセージは再びキューに戻り、他の利用可能なEC2インスタンスが再処理できるようになる
Amazon SQSでは、メッセージが消費者（この場合はEC2インスタンス）によって受信された後、処理中である間は「可視性タイムアウト」がカウントダウンします。処理中にインスタンスが終了すると、そのメッセージは削除されないまま可視性タイムアウトが切れます。タイムアウト後、そのメッセージは再びキュー内で可視化され、他のコンシューマが取得して再処理可能になります。これにより、処理途中で失敗したメッセージも再度処理されるため、データロストを防ぐことができます。
他の選択肢
- 同じインスタンスへの再配信や自動削除は行われません。SQSは可視性タイムアウト後にメッセージを再度利用可能にするだけです。
- 自動的なデッドレターキュー行きにはデッドレターキュー設定が必要です。また、未処理のうちにデッドレターキューには行きません。
- S3への自動保存はSQSの機能ではありません。