全78問から、出題範囲の骨格が掴める28問だけを抜き出しました。まずはここだけ流して、必要なら全問へ進んでください。
全78問に進むこの28問の内容
出典: オリジナル想定問題(当サイト作成、実際の過去問ではありません)。公表されている出題範囲に基づく(最終更新 2026-10-03)
ある企業は単一のアベイラビリティーゾーン内にEC2インスタンス(Webサーバー)とRDSインスタンスを配置して運用しているが、AZ障害時にもサービスを継続できるようにしたい。最小限の変更で可用性を高める方法として最も適切なものはどれか。
- AEC2インスタンスのインスタンスタイプをより大きいものに変更する
- ✓EC2インスタンスを複数のAZにまたがるAuto ScalingグループとELBの配下に配置し、RDSをMulti-AZ配置に変更する
- CRDSのストレージタイプをプロビジョンドIOPSに変更する
- DEC2インスタンスのEBSボリュームのスナップショットを毎日取得するよう設定する
解説
AZ障害への耐性を持たせるには、コンピューティング層を複数AZにまたがるAuto ScalingとELBで冗長化し、データベース層をMulti-AZ配置にして自動フェイルオーバーを可能にする必要がある。インスタンスタイプの変更やIOPSの変更、スナップショット取得だけではAZ障害時の可用性は向上しない。
根拠回復力に優れたアーキテクチャ設計:マルチAZ構成によるアベイラビリティーゾーン障害への耐性設計(EC2 Auto Scaling, ELB, RDS Multi-AZ)
あるシステムは2つの独立したアベイラビリティーゾーンにそれぞれ可用性99%のコンポーネントを配置し、少なくとも一方が稼働していればシステム全体が稼働するよう設計されている。このシステム全体の可用性に最も近い値はどれか。
- A99%
- B99.9%
- ✓99.99%
- D99.999%
解説
各コンポーネントの停止率は1%(0.01)であり、両方が同時に停止する確率は0.01×0.01=0.0001(0.01%)となる。したがってシステム全体の可用性は100%-0.01%=99.99%となる。
根拠回復力に優れたアーキテクチャ設計:マルチAZ構成による合成可用性の考え方
災害復旧(DR)戦略であるBackup and Restore、Pilot Light、Warm Standby、Multi-Site Active/Activeの4つを、一般的にRTO(目標復旧時間)が長い方から短い方へ正しく並べたものはどれか。
- ✓Backup and Restore → Pilot Light → Warm Standby → Multi-Site Active/Active
- BMulti-Site Active/Active → Warm Standby → Pilot Light → Backup and Restore
- CPilot Light → Backup and Restore → Multi-Site Active/Active → Warm Standby
- DWarm Standby → Pilot Light → Backup and Restore → Multi-Site Active/Active
解説
Backup and Restoreは復旧に最も時間がかかり、Pilot Lightは最小限のコアシステムを常時稼働させることで復旧時間を短縮し、Warm Standbyは縮小版の環境を常時稼働させることでさらに短縮し、Multi-Site Active/Activeは複数サイトで同時稼働させることでRTOを最小化する。
根拠回復力に優れたアーキテクチャ設計:災害復旧戦略(Backup and Restore, Pilot Light, Warm Standby, Multi-Site Active/Active)
Amazon SQSとAmazon SNSの違いに関する記述として正しいものはどれか。
- ASQSはパブリッシュ/サブスクライブ型で複数の受信者にメッセージを配信し、SNSはキューからメッセージをポーリングして取得する
- BSQSとSNSはどちらもメッセージの永続的な保持を行わず即時配信のみを行う
- CSQSはリアルタイム通知専用のサービスであり、SNSはバッチ処理専用のサービスである
- ✓SQSはメッセージをキューに保持し消費者がポーリングして取得するのに対し、SNSはパブリッシュされたメッセージを複数のサブスクライバーにプッシュ配信する
解説
SQSはポイントツーポイント型のキューイングサービスで、消費者がメッセージをポーリングして取得する。一方SNSはパブリッシュ/サブスクライブ型であり、発行されたメッセージを登録済みの複数サブスクライバーにプッシュ配信する点が異なる。
根拠回復力に優れたアーキテクチャ設計:疎結合アーキテクチャにおけるAmazon SQSとAmazon SNSの違い
ある企業のアプリケーションはS3バケットに重要なオブジェクトを保存しており、リージョン全体の障害に備えて別リージョンにもデータを自動的に複製しておきたいと考えている。最も適切な設計はどれか。
- AS3のライフサイクルポリシーでオブジェクトを定期的にGlacierに移行する
- BS3標準ストレージクラスのまま単一リージョンでバージョニングのみ有効にする
- ✓S3のクロスリージョンレプリケーション(CRR)を設定し、別リージョンのバケットにオブジェクトを自動複製する
- DEC2インスタンス上で手動でオブジェクトを定期的にコピーするスクリプトを実行する
解説
S3のクロスリージョンレプリケーションを設定することで、オブジェクトを別リージョンのバケットへ自動的かつ継続的に複製でき、リージョン全体の障害に備えることができる。ライフサイクルポリシーやバージョニングのみでは別リージョンへの複製は行われない。
根拠回復力に優れたアーキテクチャ設計:Amazon S3のクロスリージョンレプリケーションによる耐障害性向上
あるWebアプリケーションはEC2インスタンスのローカルディスクにユーザーのセッション情報を保存しており、Auto Scalingによるスケールインが発生すると該当インスタンス上のセッションを持つユーザーが強制的にログアウトされてしまう。この問題を解決するために最も適切な設計変更はどれか。
- Aスケールインを無効にし、常に最大容量でインスタンスを稼働させる
- BEC2インスタンスのインスタンスタイプを大きくしてスケールインの発生頻度を減らす
- ✓セッション情報をAmazon ElastiCacheなどの外部データストアに保存し、EC2インスタンスをステートレスにする
- D各EC2インスタンスにEBSボリュームを追加してセッション情報の保存容量を増やす
解説
インスタンス固有の状態を持たせる(ステートフル)設計はスケールイン・障害時にデータ損失やユーザー体験の劣化を招く。外部データストアにセッションを保存しEC2をステートレス化することで、どのインスタンスが終了してもサービスに影響しない回復力の高い設計となる。
根拠回復力に優れたアーキテクチャ設計 - ステートレス化によるスケーラビリティ・回復力の確保(Amazon ElastiCache等の活用)
Auto Scalingグループにおいて、新しいEC2インスタンスが起動してからロードバランサー経由でトラフィックを受信するようになるまでの一般的な処理順序として正しいものはどれか。
- AELBターゲットグループへ登録→インスタンス起動→トラフィック受信→ヘルスチェック
- ✓インスタンス起動→ELBターゲットグループへ登録→ELBヘルスチェック合格→トラフィック受信
- Cトラフィック受信→インスタンス起動→ヘルスチェック→登録
- Dインスタンス起動→トラフィック受信→ヘルスチェック→登録解除
解説
Auto Scalingはまず起動テンプレートに基づきインスタンスを起動し、起動後にELBのターゲットグループへ登録、ELBのヘルスチェックに合格した時点でトラフィックを受信し始める。この順序を誤ると未準備のインスタンスにトラフィックが流れてしまう。
根拠回復力に優れたアーキテクチャ設計 - Auto Scalingとロードバランサー連携の仕組み
ある企業は世界中のユーザーに静的な画像・動画ファイルを低レイテンシーで配信したいと考えており、オリジンはS3バケットである。この要件を満たす最も適切な設計はどれか。
- AS3バケットをパブリックに公開し、Route 53のレイテンシーベースルーティングで最寄りのバケットに誘導する
- ✓Amazon CloudFrontディストリビューションを作成し、オリジンをS3バケットに設定してエッジロケーションでコンテンツをキャッシュする
- C各リージョンにEC2インスタンスを配置し、S3からコンテンツをプルして配信する
- DS3のクロスリージョンレプリケーションで全リージョンにバケットを複製し、Route 53でフェイルオーバーさせる
解説
CloudFrontは世界中のエッジロケーションにコンテンツをキャッシュすることで、ユーザーに最も近い拠点から低レイテンシーで配信できる。S3単体のレプリケーションやルーティングだけでは、エッジキャッシュによる配信の高速化効果は得られない。
根拠高性能アーキテクチャ設計:コンテンツ配信の最適化(Amazon CloudFront)
Amazon EBSのgp3ボリュームはデフォルトで3,000 IOPSが追加料金なしで含まれる。あるアプリケーションがこのボリュームに対して5,000 IOPSを必要とする場合、追加課金の対象となるIOPS数はどれか。
- A5,000 IOPS
- ✓2,000 IOPS
- C3,000 IOPS
- D0 IOPS
解説
gp3は3,000 IOPSまでが基本料金に含まれるため、必要な5,000 IOPSのうち超過分である5,000-3,000=2,000 IOPSが追加課金の対象となる。
根拠高性能アーキテクチャ設計:ストレージの性能設計(Amazon EBS gp3)
100GBの大容量ファイルをAmazon S3にアップロードする際、アップロード速度の向上と耐障害性を高めるためにマルチパートアップロードを利用する場合、最初に行う操作はどれか。
- Aファイルを分割せずそのままPutObjectで一括アップロードする
- B各パートをアップロードしてETagを取得する
- C全パートの完了をCompleteMultipartUploadで通知する
- ✓マルチパートアップロードを開始(CreateMultipartUpload)してアップロードIDを取得する
解説
マルチパートアップロードはCreateMultipartUploadでアップロードを開始しIDを取得した後、各パートをアップロードし、最後にCompleteMultipartUploadで完了を通知するという順序で行う。
根拠高性能アーキテクチャ設計:大容量データ転送の高速化(Amazon S3マルチパートアップロード)
ある企業はキャッシュストアとして、マルチAZでの自動フェイルオーバー、データの永続化、およびソートセット型などの高度なデータ構造をサポートするインメモリデータストアを必要としている。このユースケースに最も適したElastiCacheのエンジンはどれか。
- ✓Redis
- BMemcached
- CDynamoDB Accelerator(DAX)
- DRDSのインメモリオプション
解説
RedisはMulti-AZレプリケーション、スナップショットによるデータ永続化、ソートセットなどの高度なデータ構造をサポートするのに対し、Memcachedはマルチスレッドでシンプルなキャッシュ用途に向くが永続化やレプリケーション、高度なデータ型はサポートしない。
根拠高性能アーキテクチャ設計:キャッシュエンジンの選定(Amazon ElastiCache)
あるDynamoDBテーブルにおいて、1アイテムのサイズが6KBであり、強力な整合性のある読み取り(Strongly Consistent Read)を1秒あたり10回実行する場合、必要な読み取りキャパシティユニット(RCU)はいくつか。
- A10 RCU
- B12 RCU
- ✓20 RCU
- D30 RCU
解説
強整合性読み取りは4KBごとに1RCUを消費し、端数は切り上げて計算する。6KBは4KB単位で切り上げると2ブロック分となり1回あたり2RCUが必要で、10回/秒では20RCUとなる。
根拠Amazon DynamoDBの読み取りキャパシティユニット(RCU)の計算方法
Auto Scalingのステップスケーリングポリシーとターゲットトラッキングスケーリングポリシーの違いに関する記述として正しいものはどれか。
- ✓ステップスケーリングはアラームの超過幅に応じて段階的に調整値を変化させられるのに対し、ターゲットトラッキングは単一の目標値を維持するように自動的に調整する
- Bターゲットトラッキングは段階的な調整値を手動で設定する必要があるが、ステップスケーリングは目標値のみ設定すればよい
- Cステップスケーリングはスケジュールに基づいて事前定義された時刻にのみ実行される
- Dターゲットトラッキングは固定の調整値のみをサポートし、目標値による自動調整はできない
解説
ステップスケーリングはCloudWatchアラームの超過幅に応じて段階的に異なる調整量を適用できるのに対し、ターゲットトラッキングは指定した目標値(例:CPU使用率50%)を維持するようAuto Scalingが自動的にインスタンス数を増減させる。
根拠EC2 Auto Scalingのスケーリングポリシー(ステップスケーリング・ターゲットトラッキング)
あるゲームアプリケーションはTCP/UDPプロトコルを使用し、世界中のユーザーに対して低レイテンシーかつ高可用性の接続を提供したい。AWSのグローバルネットワークを経由してユーザーを最適なエンドポイントにルーティングするサービスとして最も適切なものはどれか。
- ✓AWS Global Accelerator
- BAmazon CloudFront
- CAmazon Route 53
- DAWS Direct Connect
解説
AWS Global AcceleratorはAnycast IPを使用してAWSのグローバルネットワーク経由でTCP/UDPトラフィックを最適なエンドポイントへルーティングし、レイテンシーと可用性を改善する。CloudFrontは主にHTTP(S)コンテンツ配信用であり、TCP/UDP全般の最適化には適さない。
根拠AWS Global Acceleratorによるネットワークパフォーマンスの最適化
EC2インスタンス上で動作するアプリケーションがAmazon S3バケットにアクセスする必要がある。認証情報の管理において最もセキュアな方法はどれか。
- AIAMユーザーを作成しアクセスキーをEC2インスタンス内に保存する
- ✓IAMロールを作成しEC2インスタンスプロファイルとして関連付ける
- Cルートユーザーのアクセスキーを環境変数に設定する
- DS3バケットポリシーで匿名アクセスを許可する
解説
IAMロールをインスタンスプロファイルとして付与すると、一時的な認証情報が自動的にローテーションされ、長期的なアクセスキーをインスタンス内に保存するリスクを回避できる。アクセスキーの保存やルートユーザーの使用、匿名アクセスの許可はいずれもセキュリティリスクが高い。
根拠AWS IAM - IAMロールとEC2インスタンスプロファイルによる一時的認証情報の付与(セキュアなアーキテクチャ設計)
ある企業のS3バケットが誤って全世界に公開され、機密データが漏洩するインシデントが発生した。再発防止のために最も効果的な対策はどれか。
- ✓S3 Block Public Accessをアカウントレベルで有効化する
- Bバケットのバージョニングを有効化する
- Cバケットのライフサイクルポリシーを設定する
- DCloudFrontディストリビューションを作成してバケットの前段に配置する
解説
S3 Block Public Accessをアカウントまたはバケットレベルで有効化すると、パブリックACLやバケットポリシーによる意図しない公開を設定自体で防止できる。バージョニングやライフサイクルポリシー、CloudFrontの配置は公開設定の誤りそのものを防ぐものではない。
根拠Amazon S3 - Block Public Accessによるパブリックアクセス防止(セキュアなアーキテクチャ設計)
AWS KMSのカスタマーマネージドキーとAWSマネージドキーの違いに関する記述として正しいものはどれか。
- AAWSマネージドキーのみCloudTrailで使用履歴を記録できる
- ✓カスタマーマネージドキーはキーポリシーをユーザーが制御でき、ローテーション間隔も設定可能であるが、AWSマネージドキーはAWSが管理し自動年次ローテーションのみでユーザーはキーポリシーを変更できない
- Cカスタマーマネージドキーは無料で、AWSマネージドキーには料金が発生する
- DAWSマネージドキーはリージョンをまたいで共有できるがカスタマーマネージドキーはできない
解説
カスタマーマネージドキーはユーザーがキーポリシーや権限、ローテーション設定を細かく制御できるのに対し、AWSマネージドキーはAWSが完全に管理し、ユーザー側でキーポリシーの変更はできず自動年次ローテーションのみとなる。
根拠AWS KMS - カスタマーマネージドキーとAWSマネージドキーの比較(セキュアなアーキテクチャ設計)
AWS WAFの主な用途に関する記述として正しいものはどれか。
- ✓SQLインジェクションやクロスサイトスクリプティングなどのWebアプリケーションに対する一般的な攻撃パターンからCloudFrontやALBなどを保護する
- BVPC内のネットワークトラフィックを監視し異常な振る舞いを検知する
- CEC2インスタンスのOSレベルの脆弱性をスキャンする
- DS3バケット内のオブジェクトを暗号化する
解説
AWS WAFはWebアクセスコントロールリスト(Web ACL)を使用して、SQLインジェクションやXSSなど一般的なWeb攻撃パターンからCloudFront、ALB、API Gatewayなどを保護するマネージドファイアウォールである。ネットワーク全体の監視やOSの脆弱性スキャン、暗号化は他のサービスの役割である。
根拠AWS WAF - Webアプリケーション層の保護(セキュアなアーキテクチャ設計)
RDSデータベースの認証情報を保存し、定期的な自動ローテーションを行いたい場合に最も適したサービスはどれか。
- AAWS Systems Manager Parameter Store(標準パラメータ)
- BAmazon S3バケットのプレーンテキストファイル
- ✓AWS Secrets Manager
- DEC2インスタンスのユーザーデータ
解説
AWS Secrets ManagerはRDSなどのデータベース認証情報を組み込みの仕組みで定期的に自動ローテーションできる機能を持つ。Parameter Storeの標準パラメータは自動ローテーション機能を持たず、S3へのプレーンテキスト保存やユーザーデータへの記載はセキュリティ上不適切である。
根拠AWS Secrets Manager - シークレットの保管と自動ローテーション(セキュアなアーキテクチャ設計)
ある企業では、開発アカウント(Account A)のEC2インスタンスから本番アカウント(Account B)のS3バケットに安全にアクセスさせたい。長期的なアクセスキーを共有せずに実現する方法として最も適切なものはどれか。
- AAccount BのIAMユーザーを作成し、アクセスキーをAccount AのEC2インスタンスに配置する
- BAccount AとAccount Bを同一のAWS Organizationsに統合し、ルートユーザーの認証情報を共有する
- ✓Account Bにクロスアカウントアクセスを許可するIAMロールを作成し、Account AのEC2インスタンスがそのロールをAssumeRoleする
- DAccount BのS3バケットポリシーでAccount AのVPC CIDRを許可する
解説
クロスアカウントアクセスでは、信頼ポリシーを設定したIAMロールをAssumeRoleし、一時的な認証情報を取得する方式が標準的でセキュアである。長期的なアクセスキーの共有はセキュリティリスクとなるため避けるべきである。
根拠AWS IAM クロスアカウントアクセス、AWS STS AssumeRole
ある企業はプライベートサブネット内のEC2インスタンスに運用担当者がシェルアクセスできるようにしたいが、踏み台サーバーの運用管理やSSH鍵の配布、ポート22の開放を避けたいと考えている。最も適切な方法はどれか。
- ✓AWS Systems Manager Session Managerを使用し、SSH鍵の管理やインバウンドポートの開放なしにインスタンスへ安全に接続する
- BパブリックサブネットにBastionホストを配置し、SSH鍵を運用担当者全員に配布する
- CプライベートサブネットのEC2にElastic IPを割り当て直接SSH接続を許可する
- DセキュリティグループでインバウンドのTCPポート22を0.0.0.0/0に許可する
解説
Session ManagerはSSMエージェントとIAM権限を利用し、インバウンドポートの開放やSSH鍵の管理なしに安全にシェルアクセスを提供できるため、踏み台サーバーの代替として適切である。
根拠AWS Systems Manager Session Manager
ある企業の開発環境のEC2インスタンスは平日の業務時間(9時〜18時)のみ使用され、夜間・週末は利用されていないにもかかわらず常時起動したままになっている。コストを最適化するために最も適切な対応はどれか。
- A開発環境のインスタンスをスポットインスタンスに全面的に切り替える
- B1年間の全前払いリザーブドインスタンスを購入する
- ✓Lambda関数とCloudWatch Eventsを使用して業務時間外にインスタンスを自動的に停止し、業務時間内に自動的に起動するよう設定する
- D3年間のSavings Plansを購入してコミットする
解説
使用時間が決まっている開発環境は、稼働していない時間帯に自動停止することで無駄な課金を削減できる。RIやSavings Plansは稼働時間に関わらず課金が発生するため、断続的な使用パターンには適さない。
根拠コスト最適化アーキテクチャ設計(EC2インスタンスのスケジューリングによるコスト削減)
オンデマンドインスタンスの料金が1時間あたり$0.10、同スペックの1年間リザーブドインスタンスの実効料金が1時間あたり$0.07であるとき、1年間(8760時間)連続稼働させた場合のコスト削減額に最も近い値はどれか。
- A約$150
- B約$350
- C約$438
- ✓約$263
解説
オンデマンド年間コストは0.10×8760=876ドル、リザーブドインスタンス年間コストは0.07×8760=613.2ドルであり、差額は約262.8ドルとなる。
根拠コスト最適化アーキテクチャ設計(リザーブドインスタンスによるコスト削減の試算)
ある画像変換バッチ処理は処理が中断されても後で再試行可能であり、処理完了までの厳密な時間制約もない。このワークロードのコストを最小化するために最も適した購入オプションはどれか。
- Aオンデマンドインスタンス
- B3年全前払いリザーブドインスタンス
- CSavings Plans
- ✓スポットインスタンス
解説
中断に耐えられ厳密な期限がないバッチ処理は、最大90%程度割引されるスポットインスタンスのユースケースに合致し、コストを大幅に削減できる。
根拠コスト最適化アーキテクチャ設計(EC2購入オプション: スポットインスタンスの適用ユースケース)
あるアプリケーションが生成するログデータはアクセス頻度が予測不能で、日によって頻繁にアクセスされたりまったくアクセスされなかったりする。追加の運用負荷なしにストレージコストを自動的に最適化するために最も適したS3ストレージクラスはどれか。
- AS3 Standard-IA
- BS3 One Zone-IA
- ✓S3 Intelligent-Tiering
- DS3 Glacier Deep Archive
解説
S3 Intelligent-Tieringはアクセスパターンを監視し、一定期間アクセスがないオブジェクトを自動的に低コストの階層に移動させるため、アクセス頻度が予測できないデータのコストを運用負荷なく最適化できる。
根拠コスト最適化アーキテクチャ設計(S3ストレージクラスとライフサイクル管理: S3 Intelligent-Tiering)
3年間にわたり安定した負荷で稼働し続けることが事前にわかっているデータベースサーバーがある。コストを最小限に抑えるために最も適した購入オプションはどれか。
- Aオンデマンドインスタンス
- Bスポットインスタンス
- ✓3年間全前払いのリザーブドインスタンス
- D1年間部分前払いのSavings Plans
解説
長期間安定して稼働することが確定しているワークロードには、コミット期間が長く前払い割合が高いほど割引率が高くなる3年全前払いのリザーブドインスタンスが最もコストを削減できる。
根拠コスト最適化アーキテクチャ設計(EC2購入オプション: リザーブドインスタンスの割引率と前払い条件)
ある企業のVPC内の複数のEC2インスタンスはプライベートサブネットに配置されており、インターネット経由でAmazon S3バケットに頻繁にアクセスするためNATゲートウェイを経由している。データ処理料金によりコストが高額になっていることが判明した。このコストを削減するために最も適切な対応はどれか。
- ✓S3用のゲートウェイ型VPCエンドポイントを作成し、NATゲートウェイを経由せずにS3へアクセスできるようにする
- BNATゲートウェイをより大きいインスタンスサイズのNATインスタンスに置き換える
- CEC2インスタンスにパブリックIPアドレスを割り当て、インターネットゲートウェイ経由でアクセスする
- DS3バケットを別のAWSリージョンに移動する
解説
S3用のゲートウェイ型VPCエンドポイントは追加料金なしで利用でき、NATゲートウェイのデータ処理料金を回避してVPC内からS3へ直接アクセスできる。他の選択肢はコスト削減につながらないか、新たなコストやセキュリティリスクを生む。
根拠コスト最適化アーキテクチャ設計(VPCエンドポイントを用いたデータ転送コストの削減)
ある企業はAWS Organizationsで複数のメンバーアカウントを運用しており、各アカウントが個別にリザーブドインスタンスを購入しているため割引の適用効率が低くなっている。全アカウントでリザーブドインスタンスの割引メリットを最大限共有するために最も適切な対応はどれか。
- A各メンバーアカウントのIAMユーザーに管理者権限を付与する
- B各メンバーアカウントを個別のクレジットカードで契約する
- ✓一括請求(Consolidated Billing)の仕組みを利用し、RI共有を有効にして管理アカウント配下の全アカウントで割引を共有する
- DSCPを使用して各メンバーアカウントのRI購入を禁止する
解説
AWS Organizationsの一括請求機能では、RI共有を有効にすることで管理アカウント配下の全メンバーアカウントの使用量に対してRIの割引が自動的に適用され、未使用分の割引を無駄にせず活用できる。
根拠コスト最適化アーキテクチャ設計(AWS Organizations・一括請求によるリザーブドインスタンスの共有)