質問#1 ある企業が、複数の大陸にまたがる都市の気温、湿度、気圧のデータを収集している。各拠点から毎日収集するデータ量は平均 500GB である。各サイトには高速インターネット接続がある。同社は、これらすべてのグローバルサイトからのデータを、単一の Amazon S3 バケットに可能な限り迅速に集約したいと考えている。ソリューションは、運用の複雑さを最小限に抑えなければならない。これらの要件を満たすソリューションはどれか。

A.宛先の S3 バケットで S3 Transfer Acceleration を有効化にする。マルチパートアップロードを使用して、サイトのデータを宛先の S3 バケットに直接アップロードする。

B.各サイトのデータを最も近いリージョンの S3 バケットにアップロードする。S3 Cross-Region Replication を使用して、オブジェクトをデスティネーション S3 バケットにコピーする。その後、オリジンの S3 バケットからデータを削除する。

C.AWS Snowball Edge Storage Optimized デバイスジョブを毎日スケジュールし、各サイトから最も近いリージョンにデータを転送する。S3 クロスリージョンレプリケーションを使用して、オブジェクトをデスティネーション S3 バケットにコピーする。

D.各サイトから最も近いリージョンにある Amazon EC2 インスタンスにデータをアップロードする。Amazon Elastic Block Store（Amazon EBS）ボリュームにデータを保存する。定期的に EBS スナップショットを取り、宛先の S3 バケットを含むリージョンにコピーする。そのリージョンの EBS ボリュームをリストアする。

正解 A

解説：

S3 Transfer Accelerationを有効化すると、各拠点は通常の s3.<region>.amazonaws.com ではなく、アクセラレーション用エンドポイント（グローバル）にアップロードします。
データは AWS のエッジロケーションへ最寄りで入って、そこから AWS バックボーン網でバケットのリージョンへ運ばれるため、大陸跨ぎアップロードの遅延・輻輳の影響を減らしやすいです。

質問#2 ある企業が、独自のアプリケーションのログを分析する機能を必要としている。ログは Amazon S3 のバケットに JSON 形式で保存されている。クエリはシンプルで、オンデマンドで実行される。ソリューションアーキテクトは、既存のアーキテクチャに最小限の変更を加えるだけで分析を実行する必要がある。運用上のオーバーヘッドを最小限に抑えてこれらの要件を満たすために、ソリューションアーキテクトは何をすべきか？

A.Amazon Redshift を使ってすべてのコンテンツを一箇所にロードし、必要に応じて SQL クエリを実行する。
B.Amazon CloudWatch Logs を使ってログを保存する。Amazon CloudWatch コンソールから必要に応じて SQL クエリを実行する。
C.Amazon Athena と Amazon S3 を直接使用して、必要に応じてクエリを実行する。
D.AWS Glue を使用してログをカタログ化する。必要に応じて SQL クエリを実行するために、Amazon EMR 上の一時的な Apache
Spark クラスタを使用する。

正解 C

解説：

要件が「S3 に JSON で置いてあるログ」「クエリはシンプル」「オンデマンド（たまに）」「既存アーキテクチャ変更を最小」「運用オーバーヘッド最小」なので、「データを動かさず、サーバ管理もせず、必要なときだけ SQL で読む」が最短です。まさに Athena の機能です。

1) 既存アーキテクチャ変更が最小

• ログは すでに S3 にある

• Athena は S3 をそのままデータソースにしてクエリできる
  → 「ログ保存先を変える」「DBにロードする」みたいな大改造が不要。

2) オンデマンド・シンプルクエリに強い

• Athena は サーバレスで、クエリ実行時だけ課金（基本はスキャン量ベース）

• たまに実行する、軽い集計や絞り込みなら運用がしやすい

3) JSON も扱える

• JSON は Athena で外部テーブル定義（スキーマ定義）をして SQL で読める

• さらにログが日付などでプレフィックス分けされていれば パーティションでスキャン量も減らせる

最小構成のイメージ

1. Athena で DB を作る

2. S3 上の JSON に対してテーブルを定義（または Glue Data Catalog を使う）

3. その場で SELECT / WHERE / GROUP BY

質問#3 ある企業が、AWS Organizations を使用して、異なる部門の複数の AWS アカウントを管理している。管理アカウントには、プロジェクトレポートを含む Amazon S3 バケットがある。会社は、この S3 バケットへのアクセスを、AWS Organizations の組織内のアカウントのユーザーのみに制限したい。運用上のオーバーヘッドを最小限に抑えながら、これらの要件を満たすソリューションはどれか。
A.組織 ID を参照する aws PrincipalOrgID グローバル条件キーを S3 バケットポリシーに追加する。
B.部門ごとに組織単位（OU）を作成する。S3 バケットポリシーにaws:PrincipalOrgPaths グローバル条件キーを追加する。
C.AWS CloudTrail を 使 用 し て 、 CreateAccount 、InviteAccountToOrganization 、 LeaveOrganization 、RemoveAccountFromOrganization イベントを監視する。それに応じて S3 バケットポリシーを更新する。
D.S3 バケットへのアクセスが必要な各ユーザーをタグ付けする。S3 バケットポリシーに aws:PrincipalTag グローバル条件キーを追加する。
正解 A

解説：

問題の要点整理

• AWS Organizations で複数アカウントを管理している

• 管理アカウントの S3 バケットにあるレポート

• 組織内のアカウントのユーザーだけがアクセス可能にしたい

• 運用オーバーヘッドは最小限

この条件を見ると、「Organizations に属しているかどうか」だけを判定条件にできる仕組みがベストです。

正解：A の理由

A. aws:PrincipalOrgID を S3 バケットポリシーに追加

これは AWS Organizations 専用のグローバル条件キーで、

「このリクエスト元の IAM プリンシパルが、指定した Organization ID に属しているか」

を 1 行の条件で判定できます。

なぜ運用が楽か

• 新しいアカウントを Organizations に追加するだけで自動的にアクセス可能

• アカウント削除・脱退時も 自動的にアクセス不可

• バケットポリシーを 更新し続ける必要がない

• ユーザーやロールを個別管理しない

バケットポリシーのイメージ

👉 「組織に属しているかどうか」だけで制御でき、最小オーバーヘッド。

質問#4 VPC 内の Amazon EC2 インスタンス上でアプリケーションが動作している。このアプリケーションは、Amazon S3 バケットに保存されたログを処理する。EC2 インスタンスは、インターネットに接続せずに S3 バケットにアクセスする必要がある。Amazon S3 へのプライベートネットワーク接続を提供するソリューションはどれか。
A.S3 バケットへのゲートウェイ VPC エンドポイントを作成する。
B.Amazon CloudWatch Logs にログをストリーミングする。ログを S3 バケットにエクスポートする。
C.S3 アクセスを許可するために、Amazon EC2 にインスタンスプロルを作成する。
D.S3 エンドポイントにアクセスするためのプライベートリンクを持つ Amazon API Gateway API を作成する。
正解 A

問題の要点整理

• VPC 内の EC2 上でアプリが稼働

• S3 バケットのログにアクセス

• インターネット接続なし（NAT / IGW を使わない）

• S3 へのプライベートネットワーク接続が必要

ここまで条件が揃うと、AWS 的にはほぼ 即答レベルで Gateway VPC Endpoint for S3 です。

正解：A の理由

S3 ゲートウェイ VPC エンドポイントとは

• Amazon VPC 内から
  Amazon S3 へ

• AWS 内部ネットワークのみを使って通信できる仕組み

• インターネット / NAT / IGW 不要

• ルートテーブルにエントリを追加するだけ

この問題との一致点

実装イメージ

• VPC に S3 用 Gateway Endpoint を作成

• 対象サブネットの ルートテーブルに関連付け

• 必要なら エンドポイントポリシーでアクセス制御

質問#5 ある企業が、Amazon EBS ボリュームにユーザーがアップロードしたドキュメントを格納する単一の Amazon EC2 インスタンスを使用して、AWS 上で Web アプリケーションをホスティングしている。スケーラビリティと可用性を向上させるために、同社はアーキテクチャを複製し、別のアベイラビリティゾーンに 2 つ目の EC2 インスタンスと EBS ボリュームを作成し、両方をアプリケーションロードバランサーの背後に配置した。この変更を完了した後、ユーザーから、ウェブサイトを更新するたびに、ドキュメントのサブセットまたは他のサブセットが表示されるが、すべてのドキュメントが同時に表示されることはないとの報
告があった。ユーザーがすべてのドキュメントを一度に見ることができるようにするために、ソリューションアーキテクトは何を提案すべきか？
A.両方の EBS ボリュームにすべての文書が含まれるように、データをコピーする。
B.アプリケーションロードバランサーを構成して、ユーザーをドキュメントのあるサーバーに誘導する。
C.両方の EBS ボリュームから Amazon EFS にデータをコピーする。新しいドキュメントを Amazon EFS に保存するようにアプリケーションを変更する。
D.両方のサーバーにリクエストを送るようにアプリケーションロードバランサーを設定する。正しいサーバーから各ドキュメントを返す
正解 C

何が起きているか（現象の正体）

今の構成はこうです：

• AZ-A：EC2 + EBS(1)

• AZ-B：EC2 + EBS(2)

• その前に ALB（ロードバランシング）

EBS は “特定の1台のEC2にアタッチされるブロックストレージ”で、基本的に 別インスタンスと共有しません（しかも AZ を跨いで共有できない）。
その結果、ユーザーがアクセスするたびに ALB が振り分けた先の EC2 が変わり、見えるドキュメントの集合が EBS(1) 側だったり EBS(2) 側だったりする状態になっています。

つまり問題は：

アップロード済みドキュメントが各インスタンスのローカル（EBS）に分散していて、共有ストレージがない

正解：C の理由（EFS に集約する）

Amazon EFS は “複数EC2から同時に使える共有ファイルシステム”

• 複数AZにまたがってマウントできる

• 2台（将来もっと増えても）の EC2 が 同じディレクトリ／同じファイルを参照できる

• ALB の振り分け先がどちらでも、同じドキュメント一覧が見える

だから、

1. 既存の EBS(1), EBS(2) のデータを EFS にコピー

2. 今後のアップロード先を EFS に変更
   で、ユーザーは常に全ドキュメントを見られます。

実務的にも定番：

• ステートレス部分（Web/アプリ）はEC2を水平スケール

• ステート（ユーザーファイル）は EFS or S3 などの共有ストレージへ

質問#6 ある企業が NFS を使用して、オンプレミスのネットワーク接続ストレージに大容量のビデ オレルを保存している。各ビデオレのサイズは 1MB から 500GB である。ストレージの合計は 70TB で、もはや増えていない。同社は、ビデオレルを Amazon S3に移行することを決定した。可能な限り少ないネットワーク帯域幅で、できるだけ早くビデオレルを移行しなければならない。
これらの要件を満たすソリューションはどれか。
A.S3 バケットを作成する。S3 バケットへの書き込み権限を持つ IAM ロールを作成する。AWS CLI を使用して、すべてのファイルを S3 バケットにローカルにコピーする。
B.AWS Snowball Edge ジョブを作成する。オンプレミスで Snowball Edge デバイスを受け取る。Snowball Edge クライアントを使用してデバイスにデータを転送する。AWS がデータを Amazon S3 にインポートできるように、デバイスを返却する。
C.構内に S3 File Gateway をデプロイする。S3 File Gateway に接続するためのパブリックサービスのエンドポイントを作成する。S3 File Gateway 上に新しい NFS Le 共有を作成する。新しいル共有を S3 バケットに向ける。既存の NFS 共有から S3 File Gateway にデータを転送する。
D.オンプレミスネットワークと AWS の間に AWS Direct Connect 接続をセットアップする。構内に S3 File Gateway をデプロイする。S3 File Gateway に接続するためのパブリック仮想インターフェース（VIF）を作成する。S3 バケットを作成する。S3 File Gateway 上に新しい NFS Le 共有を作成する。新しいル共有を S3 バケットに向ける。既存の NFS ル共有から S3 File Gateway にデータを転送する。
正解 B

解説：

要件のポイント

• オンプレの NFS NAS にビデオ（合計 70TB）

• データは もう増えない（＝一回きりの移行）

• 可能な限り少ないネットワーク帯域幅で

• できるだけ早く移行したい

この条件は典型的に「ネットワーク転送を避けて物理搬送で一気に移す」が正解になります。Snowball（オフライン移行）が正解です。

正解：B の理由

1) ネットワーク帯域をほぼ消費しない

Snowball はデータを オンプレでデバイスに書き込み、それを AWS に返送して S3 に取り込む方式です。
インターネット回線を太くする必要がなく、要件の「帯域幅を最小化」に直撃します。

2) 70TB は Snowball の得意領域

70TB は、オンライン転送だと回線が太くても時間がかかりがちで、帯域圧迫も大きい。
Snowball なら「データ量が大きい」「一回きり」ほど強いです。

3) 運用もシンプル

• ジョブ作成

• 受領 → ローカルコピー

• 返送
  の流れで終わり。S3 File Gateway や Direct Connect のような継続運用前提の仕組みが不要。

質問#7 ある企業が、受信メッセージを取り込むアプリケーションを持っている。その後、何十もの他のアプリケーションやマイクロサービスがこれらのメッセージを素早く消費する。メッセージの数は大幅に変化し、時には毎秒 10 万件まで突然増加することもある。同社はソリューションの切り離しとスケーラビリティの向上を望んでいる。これらの要件を満たすソリューションはどれか？
A.メッセージを Amazon Kinesis Data Analytics に永続化する。コンシューマー・アプリケーションでメッセージを読み取り、
処理する。
B.インジェスト・アプリケーションを Auto Scaling グループの Amazon EC2 インスタンスにデプロイし、CPU メトリクスに基づいて EC2 インスタンス数をスケーリングする。
C.単一のシャードで Amazon Kinesis Data Streams にメッセージを書き込む。AWS Lambda 関数を使用してメッセージを前処理し、Amazon DynamoDB に格納する。コンシューマーアプリケーションが DynamoDB からメッセージを読み込むように設定する。
D.複数の Amazon Simple Queue Service（Amazon SOS）サブスクリプションを持つ Amazon Simple Notication Service（AmazonSNS）トピックにメッセージをパブリッシュする。コンシューマ・アプリケーションがキューからメッセージを処理するように構成する。
正解 D

解説

要点

• 受信（Producer）と多数の消費側（Consumers）を疎結合にしたい

• 消費側が「何十個も」ある（＝同じメッセージを複数サービスがそれぞれ処理したい可能性が高い）

• トラフィックが激しく変動し、瞬間的に毎秒 10 万件まで増える

• スケーラビリティを上げたい

この条件だと、典型解は Pub/Sub + キューです。
「配る（Publish）」は SNS、「溜める/吸収する（Buffer）」は SQS。

正解：D の理由（SNS + SQS）

1) 疎結合になる

Producer は SNS に publish するだけ。
Consumer は 自分専用の SQS を読むだけ。
お互いの実装や増減に引きずられません（新サービス追加も SQS をぶら下げるだけ）。

2) バーストに強い

SQS が バッファになるので、

• 一時的に受信が爆増しても、いったんキューに溜めて

• 消費側は自分の処理能力に合わせて並列に取り出す
  という形で“波”をならせます。

3) “何十ものサービスが同じメッセージを消費” を自然に満たす

SNS は 1 回 publishで、複数の購読先に同時配信できます。
SQS を各サービス専用にすることで、サービス間で処理が干渉しません（あるサービスが遅くても他に影響しにくい）。

質問#8 ある企業が分散アプリケーションを AWS に移行しようとしている。このアプリケーションはさまざまなワークロードに対応している。レガシープラットフォームは、複数のコンピュートノードにまたがるジョブを調整するプライマリサーバーで構成されている。この企業は、回復力と拡張性を最大化するソリューションでアプリケーションを最新化したいと考えている。これらの要件を満たすために、ソリューションアーキテクトはどのようにアーキテクチャを設計すべきか？
A.Amazon Simple Queue Service（Amazon SQS）のキューをジョブのデスティネーションとして構成する。コンピュートノードを、Auto Scaling グループで管理される Amazon EC2 インスタンスで実装する。スケジュールされたスケーリングを使用するように EC2 Auto Scaling を設定する。
B.ジョブのデスティネーションとして、Amazon Simple Queue Service（Amazon SQS）キューを設定する。Auto Scaling グループで管理される Amazon EC2 インスタンスでコンピュートノードを実装する。キューのサイズに基づいて EC2 Auto Scaling を設定する。
C.プライマリサーバーとコンピュートノードを、Auto Scaling グループで管理されている Amazon EC2 インスタンスで実装する。AWS CloudTrail をジョブのデスティネーションとして設定する。プライマリサーバーの負荷に基づいて EC2 Auto Scalingを設定する。
D.プライマリサーバーとコンピュートノードを、Auto Scaling グループで管理される Amazon EC2 インスタンスで実装する。
Amazon EventBridge（Amazon CloudWatch Events）をジョブの送信先として設定する。コンピュートノードの負荷に基づいてEC2 Auto Scaling を設定する。
正解 B

解説：

何を最新化したいか

レガシーは「プライマリ（調整役）サーバーがいて、複数ノードにジョブを配る」構造。
この **プライマリが単一障害点（SPOF）**になりがちで、スケールもしにくい。

AWS で回復力・拡張性を最大化するなら、基本は

• 調整役（プライマリ）を消す/最小化する

• ジョブはキューに積む（疎結合 + バッファ）

• ワーカー（コンピュートノード）はキュー量で水平スケール

という “キュー駆動ワーカー” の形が王道です。

B が正解な理由

1) SQS をジョブの宛先にして疎結合 & バッファ化

Producer（ジョブ投入側）と Worker（処理側）を切り離せます。
急な増加も SQS が吸収でき、落ちにくい。

2) ワーカーは Auto Scaling で水平スケール

EC2 Auto Scaling グループで処理ノードを増減できるので拡張性が出ます。

3) “キューのサイズ” に基づくスケーリングが一番筋がいい

ジョブ量に対してワーカー数を合わせるのが自然です。
CPU負荷だけ見ても「ジョブが溜まってるのにCPU低い」などズレが起きます。

試験のセオリー：
ジョブキュー + ワーカーASG + キュー深さでスケール＝回復力/拡張性の定番

質問#9 ある企業が、データセンターで SMB ファイルサーバーを運用している。ファイルサーバーは、ファイル が作成されてから数日間は頻繁にアクセスされる大きな ファイルを保存している。7 日後には、ほとんどアクセスされなくなる。データ総容量は増加の一途をたどり、会社のストレージ総容量に迫る勢いである。ソリューションアーキテクトは、最近アクセスされたファイルへの低レイテンシーアクセスを失うことなく、利用可能なストレージ容量を増やさなければならない。ソリューションアーキテクトはまた、将来のストレージの問題を回避するために、ファイルのライフサイクル管理を提供しなければならない。これらの要件を満たすソリューションはどれか。
A.AWS DataSync を使用して、7 日以上前のデータを SMB le サーバーから AWS にコピーする。
B.Amazon S3 File Gateway を作成し、会社のストレージスペースを拡張する。S3 ライフサイクルポリシーを作成し、7 日後にデータを S3 Glacier Deep Archive に移行する。
C.会社のストレージスペースを拡張するために、Amazon FSx for Windows File Server LE システムを作成する。
D.Amazon S3 にアクセスするためのユーティリティを各ユーザーのコンピュータにインストールする。7 日後にデータを S3 Glacier Flexible Retrieval に移行する S3 ライフサイクルポリシーを作成する。
正解 B

要件を整理すると「典型的な階層化ストレージ問題」

• オンプレで SMB ファイルサーバ

• 作成直後（数日）は頻繁アクセス＝低レイテンシーが必要

• 7日後はほぼアクセスされない

• 総容量が増え続けてオンプレ逼迫

• 容量を増やしつつ、将来のために ライフサイクル管理も欲しい

つまり、

1. “最近使う分” はオンプレにキャッシュして低遅延

2. “古い分” はクラウドへ逃がして容量無限化

3. さらに “古い分” は自動で低コスト階層へ
   が必要。

これを 最小の変更で SMB を維持しながらやれるのが S3 File Gateway です。

正解：B の理由

1) SMB のままストレージを拡張できる（ユーザー体験を崩さない）

Amazon S3 File Gateway はオンプレ側にゲートウェイを置き、
ユーザー/サーバーは SMB 共有としてアクセスし続けられます。

2) “最近アクセスされたファイル” の低レイテンシーを守れる

File Gateway はローカルに キャッシュを持つので、ホットデータはオンプレ相当のレスポンスを維持できます（設問の「最近アクセスされたファイルへの低レイテンシー」を満たす）。

3) S3 側でライフサイクル管理ができる

データは S3 に保存されるので、

• 7日後に Glacier 系へ移行

• さらに長期で Deep Archive へ
  など S3 Lifecycle で自動化できます。

※選択肢Bは「7日後に Glacier Deep Archive」だけど、
“7日後はほぼアクセスされない” なら コスト最優先で Deep Archive を選ぶのは筋が通ります。
ただし、7日以降でも“たまに取り出す”可能性があるなら、実務では Glacier Instant / Flexible を挟む設計も多いです（設問は「ほぼアクセスされない」なのでBの方向でOK）。

質問#10 ある企業が AWS 上に e コマースの Web アプリケーションを構築している。このアプリケーションは、新しい注文に関する情報を処理するためにAmazon API Gateway REST API に送信する。同社は、注文が受信した順番に処理されることを保証したいと考えている。これらの要件を満たすソリューションはどれか？
A.API Gateway 統合を使用して、アプリケーションが注文を受信したときに、Amazon Simple Notication Service (Amazon SNS)トピックにメッセージを発行する。AWS Lambda 関数をトピックにサブスクライブして処理を実行する。
B.API Gateway インテグレーションを使用して、アプリケーションが注文を受信したときに、Amazon Simple Queue Service (Amazon SQS) FIFO キューにメッセージを送信する。SQS FIFO キューを構成して、処理のために AWS Lambda 関数を呼び出す。
C.API Gateway オーソライザーを使用して、アプリケーションが注文を処理している間、すべてのリクエストをブロックする。
D.API Gateway インテグレーションを使用して、アプリケーションが注文を受信したときに、Amazon Simple Queue Service(Amazon SQS)標準キューにメッセージを送信する。SQS 標準キューを構成して、処理のために AWS Lambda 関数を呼び出す。
正解 B

解説：

なぜ B なのか（順序保証の要件に直撃）

1) FIFO キューは “順序” を保証できる

• SQS 標準キューは基本 順不同（at-least-once + ベストエフォート順序）

• SQS FIFO キューは メッセージグループ単位で順序を保持し、重複排除もできます

注文処理は「順番」が重要になりやすいので、FIFO が適切。

2) API Gateway → SQS は疎結合＆バッファになる

• 注文が一気に増えても、まず FIFO に積んでおける

• バックエンドの処理能力に合わせて Lambda を動かせる

3) Lambda 連携も自然

SQS FIFO をイベントソースとして Lambda を起動し、キューから順番に処理できます。
（並列性は MessageGroupId で制御。全注文を完全に1本の順序で処理したいなら MessageGroupId を固定する、注文単位で順序なら注文ID等で分ける、という設計になります。）

※FIFOは「First In, First Out」の略で、「先入れ先出し」を意味し、先に入ったものから先に出す・処理するという原則や方式を指します。