【無料】AWS SAA-C03練習問題10問｜図解解説付き｜Udemy講師作成

正解：A

A. 目的地となるS3バケットでS3 Transfer Accelerationを有効化します。マルチパートアップロードを利用して拠点データを目的地S3バケットに直接アップロードします。

正解 S3 Transfer Accelerationは、Amazon CloudFrontの世界中に分散したエッジロケーションを活用して、長距離でのデータ転送を最適化します。マルチパートアップロードは750GBという大容量データの並列アップロードを可能にし、転送速度と信頼性を大幅に向上させます。この組み合わせは、中間的な保存場所や追加のインフラストラクチャを必要とせず、直接目的地バケットへの最適化されたパスを提供するため、運用の複雑さを最小化します。高速インターネット接続が利用可能な環境では、最も効率的で実用的なソリューションです。

B. 各工場から最も近いリージョンのS3バケットにデータをアップロードします。S3クロスリージョンレプリケーションを使用してオブジェクトを目的地S3バケットにコピーし、その後、元のS3バケットからデータを削除します。

不正解 このアプローチは技術的には実現可能ですが、複数のステップが必要で運用が複雑になります。最寄りリージョンへのアップロード、クロスリージョンレプリケーションの設定と監視、元のバケットからのデータ削除など、手動の介入が必要な作業が含まれます。また、クロスリージョンレプリケーションには追加のコストがかかり、データの重複保存期間中のストレージコストも発生します。高速インターネット接続があるにもかかわらず、Transfer Accelerationと比較して最適化されていないアプローチとなります。

C. 各工場から最も近いリージョンのAmazon EC2インスタンスにデータをアップロードし、Amazon Elastic Block Store（Amazon EBS）ボリュームに保存します。定期的にEBSスナップショットを取得して目的地S3バケットのあるリージョンにコピーし、そのリージョンでEBSボリュームを復元します。

不正解 最も複雑で非効率的なソリューションです。EC2インスタンス、EBSボリューム、スナップショットという複数のコンポーネントが必要で、運用オーバーヘッドが大幅に増加します。定期的なスナップショットの作成、リージョン間でのスナップショットコピー、EBSボリュームの復元など、多くの手動作業が必要です。データがS3に直接アップロードできるにもかかわらず、不要な中間ステップとコストが発生し、データの可用性も低下します。

D. 各工場の拠点から最寄りのAWS Direct Connectロケーションへ、専用接続を新たに敷設します。その専用接続を経由してデータを目的地S3バケットにアップロードします。

不正解 AWS Direct Connectは拠点とAWSの間に専用の物理接続を提供し、帯域と遅延が安定します。しかし専用接続は拠点ごとに申し込みが必要で、Direct Connectロケーションでのクロスコネクト手配や回線事業者との調整を伴い、開通までに数週間から数か月かかります。料金面の利点はAWSからの下り転送に効くもので、S3へのアップロードはインターネット経由でも無料のためこの要件では効きません。複数の大陸にある工場それぞれに敷設する費用と調整の負担は大きく、要件の「運用上の複雑性を最小限に抑える」から大きく外れます。

全体的な説明

問われている要件

• グローバルに分散した環境からの高速データ転送：複数の大陸にある工場からのデータを効率的に集約する必要があります
• 大容量データの効率的な転送：各工場から日次750GBという大容量のデータを処理する必要があります
• 運用の複雑さの最小化：シンプルで管理しやすいソリューションが求められています
• 高速インターネット接続の活用：各工場に既存のインフラストラクチャを有効活用する必要があります

前提知識

S3 Transfer Accelerationの適用場面について理解しておく必要があります：

• 地理的に分散したユーザーからのアップロード
• 大容量ファイルの長距離転送
• 高速インターネット接続が利用可能な環境
• 転送速度の予測可能性が重要な場合

マルチパートアップロードの基準も重要です：

• 100MB以上のオブジェクトに推奨される
• 単一のPUT操作には5GBという上限があるため、それを超える大容量オブジェクトでは必須となる
• 並列処理による速度向上が期待できる
• 部分的な失敗時の再送効率が向上する

AWS Direct Connectの適用場面についても理解が必要です：

• 帯域と遅延の安定性が長期にわたって求められる環境
• AWSからの下り転送量が多く、その転送料金を継続的に削減したい場合（S3へのアップロードはインターネット経由でも無料のため、上り主体の用途では料金面の利点は出ない）
• 拠点ごとに専用接続の申し込みとクロスコネクトの手配が必要で、開通までに数週間から数か月かかる
• すでに高速インターネット回線がある拠点や、短期間で立ち上げたい構成には過剰

クロスリージョンレプリケーションの特徴も重要です：

• 災害復旧やコンプライアンス要件に適している
• 追加のコストが発生する
• レプリケーション遅延が発生する可能性がある
• 手動でのデータ削除が必要な場合がある

解くための考え方

S3 Transfer Accelerationは、Amazon CloudFrontの世界中に分散したエッジロケーションを活用して、S3バケットへの転送を高速化する機能です。通常のインターネット経由の転送と比較して、長距離かつ大容量のオブジェクトでは最大50〜500%の性能向上が見込めるとAWSは説明しています。有効化にあたっては、対象バケットの名前がDNS準拠でピリオド（.）を含まないことが条件で、有効化後に効果が現れるまで最大20分程度かかる点にも注意が必要です。

マルチパートアップロードの利点も考慮する必要があります。750GBという大容量データに対しては、マルチパートアップロードが不可欠です。これにより、データを複数のパートに分割して並列アップロードが可能になり、転送速度の向上とネットワーク障害時の復旧性が向上します。

単一ステップの構成は、複数ステップの構成より運用が簡単で、障害点も少なくなります。

アーキテクチャ図の解説

アーキテクチャ図

S3 Transfer Accelerationの要点は、転送経路を「最寄りのCloudFrontエッジまで」と「エッジから目的地まで」の2段構えに分ける点です。各工場の稼働ログとセンサーデータはマルチパートアップロードで並列に最寄りのエッジロケーションへ届き、その先はAWSの最適化されたバックボーンネットワークを通って目的地のS3バケットへ高速に転送されます。中間に別のS3バケットやEC2インスタンスを挟まず、取り込み側から目的地へ一直線に流れるため、同期や削除といった後始末が残りません。最寄りリージョンのS3へ一度保存してクロスリージョンレプリケーションで複製する構成を選ぶと、レプリケーションの設定・監視と元データの削除が運用負荷として残り、要件の「複雑性の最小化」を満たせません。専用接続を拠点ごとに敷設する構成も、この図のように既存のインターネット回線とエッジロケーションだけで完結する経路と比べると、開通までの調整と敷設費用が上乗せされるだけになります。

コストと性能の考慮事項

S3 Transfer Accelerationを使用する場合、加速された転送に対してのみ追加料金が発生します。AWSが通常の転送より速くならないと判断した転送には加速料金は課金されず、標準の転送料金のみが適用されます。性能面では、AWSは長距離での大容量オブジェクト転送において最大50〜500%の高速化が見込めるとしており、実際の効果は拠点ごとに異なるため、S3 Accelerate速度比較ツールで事前に確認できます。マルチパートアップロードと組み合わせることで、ネットワーク障害時の復旧性も向上し、障害時は失敗したパートだけ送り直せます。

参考資料

• Amazon S3 Transfer Acceleration を使用した高速かつ安全なファイル転送の設定
• S3 Transfer Acceleration の有効化と使用
• Amazon S3 Transfer Acceleration の開始方法
• Amazon S3 でのマルチパートアップロードを使用したオブジェクトのアップロードとコピー
• マルチパートアップロードを使用したオブジェクトのアップロード
• チュートリアル: マルチパートアップロードでオブジェクトをアップロードして、データ整合性を検証する
• Amazon CloudFront とは何ですか?
• CloudFront の開始方法
• AWS Direct Connect とは

正解：D

A. 各事業部に組織単位（OU）を作成します。aws:PrincipalOrgPathsグローバル条件キーをS3バケットポリシーに追加します。

不正解 aws:PrincipalOrgPathsグローバル条件キーは特定のOUパスのメンバーのみにアクセスを制限しますが、各事業部にOUを作成し、それぞれのOUパスを管理する必要があります。組織全体でのアクセスを許可する要件に対しては過剰に複雑で、運用オーバーヘッドが増加します。事業部間でユーザーが移動する場合やOUの構造が変更される場合に、追加の管理作業が必要になります。要件では組織全体のアクセスを求めているため、事業部別のアクセス制御は不要です。

B. S3バケットにアクセスする必要がある各ユーザーにタグを付けます。aws:PrincipalTagグローバル条件キーをS3バケットポリシーに追加します。

不正解 各ユーザーにタグを付けてaws:PrincipalTagグローバル条件キーを使用するアプローチは、大規模な組織では非現実的です。すべてのユーザーに手動でタグを付ける必要があり、ユーザーが多い場合にはタグ管理が非常に困難になります。新しいユーザーの追加や既存ユーザーの事業部変更時にも、継続的なタグ管理が必要となり、運用オーバーヘッドが最大になります。また、タグの一貫性を保つことも困難です。

C. AWS CloudTrailを使用してCreateAccount、InviteAccountToOrganization、LeaveOrganization、RemoveAccountFromOrganizationイベントを監視します。それに応じてS3バケットポリシーを更新します。

不正解 AWS CloudTrailを使用したイベント監視とポリシーの手動更新は、非常に複雑で運用オーバーヘッドが大きいアプローチです。CloudTrailはログ記録サービスであり、アクセス制御を直接提供しません。アカウントの追加や削除のたびに手動でS3バケットポリシーを更新する必要があり、自動化されていないため運用負荷が高くなります。また、リアルタイムでのアクセス制御ができず、セキュリティ上の問題も生じます。

D. aws:PrincipalOrgIDグローバル条件キーを組織IDへの参照とともにS3バケットポリシーに追加します。

正解 aws:PrincipalOrgIDグローバル条件キーは、組織内のすべてのアカウントのプリンシパル（ユーザー、ロール）からのアクセスを許可する最もシンプルで効率的な方法です。組織IDを一度指定するだけで、組織内のすべてのアカウントのユーザーにアクセスを許可できます（別アカウントからのアクセスでは、そのアカウント側のIAMポリシーでも同じ操作が許可されている必要があります）。新しいアカウントが組織に追加されても、ポリシーの更新が不要で、運用オーバーヘッドが最小限です。リソースベースポリシーで組織内のすべてのアカウントIDを個別に列挙する必要がなく、管理が簡素化されます。

全体的な説明

問われている要件

• AWS Organizations内の組織のアカウントのユーザーのみがS3バケットにアクセスできるようにする
• 複数の事業部にまたがるアカウントが対象で、組織全体でのアクセス制御が必要
• 最小限の運用オーバーヘッドでソリューションを実装する
• S3バケットポリシーを使用したリソースベースのアクセス制御を活用する

前提知識

AWS OrganizationsのIAM条件キーについて理解しておく必要があります：

• aws:PrincipalOrgIDは組織内のすべてのアカウントのプリンシパルを対象とする条件キーです
• 組織IDを指定するだけで、組織内のすべてのアカウントからのアクセスを許可できます
• 新しいアカウントが組織に追加されても、自動的にアクセス権限が付与されます
• 管理アカウントも含めて、組織内のすべてのアカウントが対象となります

aws:PrincipalOrgPathsの特徴：

• 特定のOUパスのメンバーのみにアクセスを制限する条件キーです
• OUの階層構造に基づいてアクセス制御を行います
• 事業部別のアクセス制御には適していますが、組織全体のアクセスには複雑すぎます
• OUの構造変更時には、ポリシーの更新が必要になる場合があります

リソースベースポリシーの概念：

• S3バケットポリシーはリソースベースポリシーの一種です
• リソース側でアクセス制御を定義し、どのプリンシパルがアクセス可能かを制御します
• 複数のアカウントからのアクセスを制御する場合に効果的です
• 条件キーを使用してより詳細なアクセス制御を実現できます

解くための考え方

「組織内のアカウントのユーザーのみ」は、事業部別ではなく組織全体でのアクセス制御を求めています。

一度設定すればアカウントの増減のたびにポリシーを直さなくて済む構成を選びます。手動更新や継続監視が必要な案は、運用負荷が残ります。

AWS Organizationsの機能を活用することで、組織の構造変更（アカウントの追加や削除）に対して自動的に対応できるソリューションを選択する必要があります。

各選択肢の運用オーバーヘッドを比較すると、aws:PrincipalOrgIDは設定が最も簡単で、継続的なメンテナンスが不要です。他の選択肢は、OUの管理、CloudTrailの監視、ユーザータグの管理など、継続的な運用作業が必要です。

アーキテクチャ図の解説

アーキテクチャ図

バケットポリシーに組織IDを条件として持たせるだけで、組織内の全アカウントのユーザーとロールにアクセスが許可され、組織外のユーザーは条件を満たさないため拒否されます。管理アカウントにある監査ログ用のS3バケットには、aws:PrincipalOrgID条件を指定したバケットポリシーが付いており、営業部・開発部・経理部の各アカウントに属するユーザーやロールは、その組織IDとの一致によってアクセスを許可されます。一方、外部ユーザーは組織IDを持たないため、同じポリシーの条件を満たせず拒否されます。事業部ごとのOUパスやユーザータグで絞り込む構成にすると、組織構造の変更やユーザーの増減のたびに管理が発生し、要件の「最小限の運用オーバーヘッド」を満たせません。

セキュリティと運用の利点

このソリューションの主な利点は、組織の構造変更に対する自動対応です。新しいアカウントが組織に追加されても、そのアカウントのユーザーは自動的にS3バケットにアクセス可能になります。逆に、アカウントが組織から削除されると、そのアカウントのユーザーは自動的にアクセス権限を失います。この自動対応により、手動でのポリシー更新が不要になり、運用ミスやセキュリティ上の問題を防げます。

なお、aws:PrincipalOrgIDは組織のメンバーであるプリンシパルからのリクエストにのみ含まれる条件キーです。AWSのサービスプリンシパルがバケットへ直接書き込むケース（AWS CloudTrailによるログ配信など）ではこの条件を満たさないため、そうしたアクセスを許可する場合は、サービスプリンシパル向けのステートメントを別に用意するか、サービス間リクエスト用のaws:SourceOrgID条件キーを併用します。

他のソリューションとの比較

OUベースのアクセス制御は、事業部別のアクセス制御が必要な場合には適していますが、組織全体でのアクセス許可には複雑すぎます。

CloudTrailを使用した監視と手動更新は、リアルタイムでのアクセス制御ができず、運用負荷も高くなります。

ユーザータグベースのアクセス制御は、大規模な組織では管理が困難で、タグの一貫性を保つことも難しくなります。

実装例

バケットポリシーの Condition に aws:PrincipalOrgID を置き、組織 ID を指定します。アカウントの増減のたびにプリンシパル ARN を書き足す必要はありません。

参考資料

• AWS Organizations のIAM条件キー
• aws:PrincipalOrgID条件キーの使用方法
• Amazon S3 バケットポリシーの例
• AWS Organizations とは
• リソースベースポリシーとアイデンティティベースポリシー
• AWS Organizations を使用した組織のアクセス許可の管理
• Amazon S3 でのアクセスコントロール
• AWS Organizations のベストプラクティス

正解：A

A. S3接続のため、ゲートウェイVPCエンドポイントをVPC内に作成し、ルートテーブルへ経路を追加してインターネットを経由せずS3バケットへアクセスできるようにします。

正解 ゲートウェイVPCエンドポイントは、VPC内のリソースがインターネットゲートウェイ、NATゲートウェイ、またはNATインスタンスを経由することなく、Amazon S3やDynamoDBなどのサポートされたAWSサービスにプライベートに接続できるようにします。このソリューションは、EC2インスタンスとS3バケット間の通信がAWSのプライベートネットワーク内に留まることを保証し、インターネット接続を必要とせずにセキュアで直接的な接続を提供します。追加コストもかからず、設定も簡単です。

B. S3接続に必要なアクセス権限を付与するため、Amazon EC2にインスタンスプロファイルを作成してS3バケットへの読み取りを許可し、各インスタンスへ割り当てます。

不正解 インスタンスプロファイルの作成は、EC2インスタンスにIAMロールを割り当てて、S3リソースへのアクセス権限を付与するためのものです。これはアクセス制御（認証・認可）の問題を解決しますが、ネットワーク接続の問題は解決しません。インスタンスプロファイルがあっても、EC2インスタンスは依然としてインターネット経由でS3にアクセスする必要があり、プライベートネットワーク接続は提供されません。

C. S3接続の代替として、監査ログをAmazon CloudWatch Logsへストリーミングし、そのログをS3バケットへエクスポートして参照できるようにします。

不正解 CloudWatch LogsにログをストリーミングしてからS3にエクスポートするアプローチは、要件を満たしません。この方法では、EC2インスタンスが直接S3バケットにアクセスするのではなく、CloudWatch Logsを中間的な保存場所として使用します。また、CloudWatch LogsからS3へのログエクスポートには数時間かかる場合があり、リアルタイムでのログ処理には適していません。さらに、この方法でもプライベートネットワーク接続は提供されません。

D. S3接続を提供するため、AWS PrivateLinkを利用したAmazon API Gateway APIを作成し、そのAPIを経由してS3バケットへアクセスできるように構成します。

不正解 API GatewayはAWSサービス統合によってAmazon S3をバックエンドにしたプロキシAPIを構成できますが、これはAPIの呼び出し元にHTTPインターフェースを提供する仕組みであり、EC2インスタンスからS3への通信経路をプライベート化するものではありません。プライベートAPIエンドポイントを使った場合でもプライベートになるのはAPI Gatewayまでの区間だけで、単純なオブジェクト取得のためにAPI層を挟むことになり、レイテンシーと運用の複雑さ、リクエストごとの課金が増えます。EC2インスタンスがS3へ直接プライベートアクセスするという要件には見合いません。

全体的な説明

問われている要件

• VPC内で動作するEC2インスタンスがS3バケットにアクセスする必要がある
• インターネット接続なしでS3バケットにアクセスする必要がある
• プライベートネットワーク接続を提供するソリューションが必要
• EC2インスタンスからS3バケットへの直接アクセスが必要

前提知識

VPCエンドポイントの概念について理解しておく必要があります：

• VPCエンドポイントは、VPCとサポートされているAWSサービス間のプライベート接続を提供するサービスです
• インターネットゲートウェイ、NATゲートウェイ、VPN接続、またはDirect Connect接続を経由せずにAWSサービスにアクセスできます
• トラフィックはAWSのプライベートネットワーク内に留まり、インターネットを経由しません

ゲートウェイVPCエンドポイントとインターフェースVPCエンドポイントの違い：

• ゲートウェイVPCエンドポイントは、S3とDynamoDBのみをサポートします
• ルートテーブルの特定のIPルートをターゲットとして、プレフィックスリストの形式で動作します
• 追加コストがかからず、設定が簡単です
• インターフェースVPCエンドポイントは、AWS PrivateLinkを使用してその他の多くのAWSサービスにアクセスします（S3はゲートウェイ型とインターフェース型の両方に対応しています）

S3へのアクセス方法の種類：

• パブリックインターネット経由のアクセス：インターネットゲートウェイまたはNATゲートウェイを使用
• VPCエンドポイント経由のプライベートアクセス：ゲートウェイエンドポイントまたはインターフェースエンドポイントを使用
• 各方法には異なるセキュリティ、コスト、パフォーマンスの特性があります

解くための考え方

インターネットを使わず、プライベート経路でS3へ届けることが条件です。VPCエンドポイントがその経路になります。

S3へのプライベート到達にはゲートウェイ型VPCエンドポイントを使います。S3とDynamoDBだけがこの方式で、他サービスとは接続の仕方が違います。

ネットワーク到達とIAM認可は別問題です。インスタンスプロファイルは認可だけを解決し、経路は変えません。

ゲートウェイ型VPCエンドポイントに時間課金はなく、作成とルート追加だけで済み、継続的な管理も不要です。

アーキテクチャ図の解説

アーキテクチャ図

ゲートウェイVPCエンドポイントを使うと、VPC内のEC2インスタンスからS3への通信がインターネットを一切通らず、AWSのプライベートネットワーク内に留まります。EC2インスタンスからのアクセス要求は、ルートテーブルに追加されたエンドポイント向けの経路によってゲートウェイVPCエンドポイントへ向かい、そこからAWSバックボーンネットワークを経てS3バケットへ届きます。インターネットゲートウェイやNATゲートウェイを経由しないため、出口が不要で追加コストもかかりません。インスタンスプロファイルでIAM権限を付けるだけの構成を選ぶと、認可は解決しても通信経路がインターネット経由のまま残り、要件の「インターネット接続なし」を満たせません。

セキュリティとアクセス制御

ゲートウェイVPCエンドポイントは、ネットワークレベルでのプライベート接続を提供しますが、アクセス制御も重要です。EC2インスタンスがS3バケットにアクセスするためには、適切なIAMロールとポリシーが必要です。これは通常、インスタンスプロファイルを通じてEC2インスタンスに割り当てられます。ただし、インスタンスプロファイル単体では、問題で要求されているプライベートネットワーク接続は提供されません。

コストと性能の利点

ゲートウェイVPCエンドポイントを使用することで、複数の利点が得られます。まず、エンドポイント自体に追加コストがかからないため、コスト効率的です。また、インターネットゲートウェイやNATゲートウェイを経由しないため、これらのサービスに関連するデータ転送コストも削減されます。さらに、AWSのプライベートネットワークを使用することで、レイテンシーが低減され、帯域幅も向上します。

他のソリューションとの比較

CloudWatch Logsを経由するアプローチは、リアルタイムでのログ処理には適していません。また、複数のサービスを経由することで、追加のコストと複雑性が発生します。

API Gatewayを使用するアプローチは、S3をバックエンドにしたプロキシAPIを構成できるものの、EC2インスタンスからS3への通信経路をプライベート化するものではなく、API層を挟む分だけ構成の複雑さとコストが増えます。

インスタンスプロファイルは必要な権限を提供しますが、ネットワーク接続の問題は解決しません。

実装の考慮事項

ゲートウェイ型エンドポイントを作ると、指定したルートテーブルへS3向けプレフィックスリストのルートが入ります。エンドポイントポリシーでバケットとアクションを絞れます。

参考資料

• AWS PrivateLink の概念
• ゲートウェイ VPC エンドポイント
• Amazon S3 のゲートウェイエンドポイント
• VPC エンドポイントポリシー
• Amazon VPC とは
• Amazon EC2 でのIAM ロールの使用
• Amazon S3 でのアクセスコントロール
• AWS PrivateLink とは

正解：B

A. リクエストを両方のサーバーに送信するようにApplication Load Balancerを設定します。正しいサーバーから各画像を返します。

不正解 Application Load Balancerは負荷分散のために単一のサーバーにリクエストを送信するよう設計されており、同じリクエストを両方のサーバーに送信することはありません。このアプローチでは、アプリケーションレベルで複数のレスポンスをマージする複雑な仕組みが必要になります。また、ネットワークトラフィックが倍増し、リソースの無駄遣いになるため、スケーラビリティと効率性に欠けます。

B. 両方のEBSボリュームからAmazon EFSへデータをコピーします。新しい画像はEFSに保存するようアプリケーションを変更します。

正解 Amazon EFSは複数のアベイラビリティゾーンの複数のEC2インスタンスから同時にアクセスできる共有ファイルストレージサービスです。両方のEBSボリュームからEFSにデータをコピーし、アプリケーションを変更して新しい画像をEFSに保存することで、すべてのインスタンスが同じデータにアクセスできるようになります。これにより、ユーザーがどのインスタンスに送信されても、すべての画像を見ることができます。EFSは自動的にスケールし、高可用性を提供します。

C. 画像を持つサーバーにユーザーを誘導するようにApplication Load Balancerを設定します。

不正解 スティッキーセッションの概念を使用してユーザーを特定のサーバーに誘導することは、ユーザーの画像が両方のサーバーに分散されている現在の状況では機能しません。Load Balancerがどのサーバーにどの画像があるかを知る必要がありますが、これは現実的ではありません。また、この方法では負荷分散の利点が失われ、単一障害点も生じます。

D. 両方のEBSボリュームにすべての画像が含まれるようにデータをコピーします。

不正解 両方のEBSボリュームにすべての画像をコピーすることは技術的には可能ですが、継続的な同期の問題があります。新しい画像がアップロードされるたびに、両方のEBSボリュームを手動で同期する必要があり、これは自動化されていません。また、EBSボリュームは単一のAZに制限されているため、真の高可用性ソリューションではありません。データの整合性を保つことも困難で、スケーラビリティに欠けます。

全体的な説明

問われている要件

• 複数のアベイラビリティゾーンに分散された複数のEC2インスタンスから同一のデータにアクセスする
• ユーザーがどのインスタンスに誘導されても、すべての画像を同時に見ることができる
• スケーラビリティと可用性を維持しながら、データの一貫性を保つ
• 新しい画像のアップロードにも対応し、すべてのインスタンスから即座にアクセス可能にする

前提知識

EBSボリュームの特性について理解しておく必要があります：

• EBSボリュームは単一のアベイラビリティゾーンに制限されており、同じAZ内のEC2インスタンスにのみアタッチできます
• 異なるAZのインスタンス間でEBSボリュームを共有することはできません
• EBSボリュームは高性能ですが、単一インスタンスでの使用に最適化されています
• EBSスナップショットを使用してデータを他のAZにコピーできますが、リアルタイムの同期は提供されません

Amazon EFSの特性も重要です：

• EFSは複数のアベイラビリティゾーンにまたがる共有ファイルストレージサービスです
• 複数のEC2インスタンスから同時にアクセスでき、POSIX準拠のファイルシステムを提供します
• 自動的にスケールし、ペタバイト規模まで拡張できます
• 高可用性と耐久性を提供し、データは複数のAZに自動的に複製されます

Application Load Balancerの動作：

• ALBは受信リクエストを利用可能なターゲット（EC2インスタンス）に分散します
• ターゲットグループのルーティングアルゴリズムとして、ラウンドロビン、未処理リクエスト数が最も少ないターゲット、加重ランダムのいずれかを選択できます
• スティッキーセッションを設定することで、特定のユーザーを同じインスタンスに誘導できますが、データが分散されている場合は効果的ではありません

解くための考え方

いま起きているのは、各EC2インスタンスが独自のEBSボリュームを持っており、ユーザーの画像が2つのボリュームに分散されていることです。ALBがリクエストを異なるインスタンスにルーティングするため、ユーザーは異なるデータセットにアクセスすることになります。

解決策は、すべてのインスタンスが同じデータにアクセスできるようにすることです。この要件を満たすには、共有ストレージソリューションが必要です。AWSでは、EFSが複数のインスタンスから同時にアクセスできる共有ファイルストレージを提供します。

各選択肢を評価する際は、自動化、スケーラビリティ、運用の簡素化、および高可用性の観点から考慮する必要があります。手動でのデータ同期や複雑なアプリケーションロジックは避けるべきです。

アーキテクチャ図の解説

アーキテクチャ図

複数のアベイラビリティゾーンに置かれたEC2インスタンスが、単一のAmazon EFSを共有して同じデータにアクセスします。変更前は各インスタンスが個別のEBSボリュームを持ち、ユーザーのアップロードした画像がボリュームごとに分散していたため、ALBが別のインスタンスへ振り分けると一部の画像しか見えませんでした。EFSへ移行すると、各インスタンスはマウントターゲット経由で同じEFSに接続し、すべての画像にアクセスできます。両方のEBSへ手動でコピーを同期する構成を選ぶと、アップロードのたびの同期作業が残り、EBSは単一AZに制限されるためAZをまたいだ共有にはなりません。

パフォーマンスとスケーラビリティの考慮事項

EFSはパフォーマンスモード（汎用と最大I/O）とスループットモード（Elastic、プロビジョンド、バースト）の組み合わせで構成します。汎用パフォーマンスモードはオペレーションごとのレイテンシーが最も低く、ほとんどのワークロードで推奨されます。汎用モードの性能上限は継続的に引き上げられており、Elasticスループットとの組み合わせでは1ファイルシステムあたり読み取り250万IOPS規模まで対応するため、写真共有サービスのような同時アクセスでも余裕があります。スループットモードは、ワークロードの増減に応じて自動で調整されるElasticが現在の推奨です。安定した帯域をあらかじめ確保したい場合は、プロビジョンドスループットモードでファイルシステムのサイズに関係なく一貫したスループットを指定できます。

セキュリティの考慮事項

EFSは、転送中および保存時の暗号化をサポートしています。また、POSIXアクセス許可、IAMポリシー、VPCセキュリティグループ、およびネットワークACLを使用してアクセスを制御できます。EFSアクセスポイントを使用することで、アプリケーションレベルでのアクセス制御をさらに細かく設定できます。

コストの最適化

EFSは使用した分だけ課金される従量課金制で、事前のプロビジョニングが不要です。また、EFS ライフサイクル管理を使用することで、アクセス頻度に基づいてファイルを自動的に低コストのストレージクラスへ移動し、コストを最適化できます。頻繁にアクセスされないファイルは、最大92%のコスト削減が可能です。

移行戦略

既存のEBSボリュームからEFSへの移行は、段階的に実行できます。まず、EFSファイルシステムを作成し、既存の画像をEFSにコピーします。次に、アプリケーションを変更して新しい画像をEFSに保存するようにします。最後に、すべてのデータがEFSに移行されたことを確認してから、古いEBSボリュームを削除します。

参考資料

• Amazon Elastic File System とは
• Amazon EFS の使用方法
• Amazon EFS のパフォーマンス
• Amazon Elastic Block Store とは？
• Application Load Balancer とは
• Amazon EFS のセキュリティ
• Amazon EFS の料金

正解：A

A. AWS Data Transfer Terminal の拠点の利用枠を予約します。オンプレミスの NFS から取り出したデータをストレージデバイスに格納して拠点へ持ち込み、拠点の高速接続を使って Amazon S3 へアップロードします。

正解 AWS Data Transfer Terminal は、AWS が運営する物理拠点にストレージデバイスを持ち込み、拠点の高速接続から Amazon S3 へアップロードできるサービスです。転送は拠点側の回線で行われるため、自社のインターネット回線の帯域幅を消費しません。一回限りの大容量移行に向きます。

B. オンプレミスネットワークと AWS の間に AWS Direct Connect 接続を設定します。S3 File Gateway をオンプレミスに導入し、新しい NFS ファイル共有を S3 バケットへ向けて、既存の NFS から S3 File Gateway へデータを転送します。

不正解 AWS Direct Connect の新規設定には数週間から数か月かかり、「できるだけ早く」という要件に反します。回線を用意しても 160 TB の転送には帯域幅を消費します。Direct Connect は継続的な高速接続に向くため、一回限りの移行には過剰です。

C. S3 バケットを作成します。S3 バケットへの書き込み権限を持つ IAM ロールを作成します。AWS CLI を使ってすべてのファイルをローカルから S3 バケットへコピーします。

不正解 AWS CLI で直接コピーする方法は、160 TB ものデータをインターネット経由で送るため、自社のネットワーク回線の帯域幅を大量に消費します。1 Gbps の接続でも転送に約 15 日かかり、帯域幅を最小限に抑えるという要件に反します。転送中の障害による再送のリスクもあります。

D. AWS DataSync のエージェントをオンプレミスに導入します。NFS の保存場所から Amazon S3 バケットへの転送タスクをスケジュールします。

不正解 AWS DataSync はオンラインのデータ転送サービスで、エージェントを経由してデータをネットワーク上で送るため、160 TB の転送には自社回線の帯域幅を大量に消費します。転送の自動化や増分同期に向く利点はありますが、帯域幅を抑えるという要件には合いません。

全体的な説明

問われている要件

• 160 TB の映像素材を一回限りで移行すること
• データは今後増えないこと
• 自社のネットワーク回線の帯域幅を最小限に抑えること
• できるだけ早く移行すること

前提知識

AWS Data Transfer Terminal の特徴は次のとおりです。

• AWS が運営する物理拠点へストレージデバイスを持ち込み、拠点の高速接続で Amazon S3 などの AWS パブリックエンドポイントへアップロードできるサービスです
• 転送は拠点側の光接続（1 本あたり最大 100 Gbps）で行われるため、自社回線の帯域幅を消費しません
• コンソールからの事前予約制で、料金は予約中に使用したポートの時間単位です。転送したデータ量に応じた課金はありません
• 現時点では AWS エンタープライズサポートを契約しているお客様が対象で（未契約の場合は AWS Support への問い合わせが必要）、拠点も世界の主要都市に限られます
• 一回限りの大容量移行に向きます

AWS DataSync の特徴は次のとおりです。

• オンプレミスと AWS の間でデータを転送するオンラインサービスです
• エージェントを設置してネットワーク経由で送るため、帯域幅を消費します
• 定期実行や増分同期に向きます

S3 File Gateway の特徴は次のとおりです。

• オンプレミスと S3 の間のハイブリッド接続を提供します
• 継続的なファイルアクセスとローカルキャッシュに向きます
• 一回限りの移行より継続的な同期用途に適します

AWS Direct Connect の特徴は次のとおりです。

• オンプレミスと AWS の間の専用接続を提供します
• 新規設定には数週間から数か月かかります
• 継続的な高速接続に向きます

解くための考え方

最も重要な要件は「自社のネットワーク回線の帯域幅を最小限に抑える」です。転送を拠点側の回線で行う AWS Data Transfer Terminal がこの要件を満たします。

「データは今後増えない」という記述は一回限りの移行を示しており、継続的な同期に向く DataSync や File Gateway より、物理的な持ち込みによる移行が適しています。

時間の観点では、Direct Connect のセットアップが最も長くかかり、「できるだけ早く」という要件に合いません。Data Transfer Terminal は拠点までの移動時間がかかりますが、拠点での転送は高速です。

移行プロセスとタイムライン

AWS Data Transfer Terminal の移行は次の流れで進みます。まずマネジメントコンソールで拠点の利用枠を予約し、NFS から取り出したデータをストレージデバイスへ格納します。当日は、そのデバイスに加えて転送作業用のノート PC や 100G QSFP28 LR4 対応の光トランシーバーなど、接続に必要な機材を自社で用意して拠点へ持ち込みます。拠点の光接続には自分でつないで Amazon S3 へアップロードし、作業終了後は持ち込んだ機材をすべて撤去します。

データ転送の時間比較

オンライン転送の場合の所要時間は次のとおりです。160 TB は約 1,280 Tbit（160 TB × 8 bit）に相当します。

• 1 Gbps 接続: 約 1,280,000 秒 ≈ 約 15 日
• 10 Gbps 接続: 約 128,000 秒 ≈ 約 1.5 日

このため、インターネット経由の転送では数日から十数日の間、自社回線を占有することになります。これに対し、Data Transfer Terminal は拠点側の光接続（1 本あたり最大 100 Gbps）で転送するため、転送効率のオーバーヘッドを見込んでも 160 TB を数時間程度で取り込め、自社回線を一切占有しません。

セキュリティとコスト

AWS Data Transfer Terminal は拠点でセキュアな転送を提供します。料金は予約中に使用したポートごとの時間課金（最低 1 ポート時間）で、転送したデータ量に応じた課金はありません。専用線のように継続的な接続料が発生することもないため、一回限りの移行では費用を見積もりやすくなります。

他のソリューションとの比較

AWS CLI による直接コピーは小規模データに向きますが、160 TB には不向きです。DataSync と S3 File Gateway は継続的なハイブリッドアクセスに向き、Direct Connect は継続的な高速接続に向くため、いずれも一回限りの大容量移行には適しません。

実装の考慮事項

Data Transfer Terminal は現時点でエンタープライズサポート契約が前提です。サポートプランと最寄りの拠点を確認してから枠を取り、持ち込み前にデータが取り出せることを確かめます。アップロードが完了するまで、元データはオンプレミス側に残しておきます。

参考資料

• AWS Data Transfer Terminal
• AWS Data Transfer Terminal とは（ユーザーガイド）
• AWS Data Transfer Terminal の料金
• AWS DataSync とは
• AWS Storage Gateway とは
• AWS Direct Connect とは

正解：D

A. 受注イベントを単一シャードのAmazon Kinesis Data Streamsへ書き込み、複数のLambda関数で前処理してDynamoDBへ保存し、コンシューマーが読み取るよう設定します。

不正解 単一シャードのKinesis Data Streamsでは毎秒1,000レコードまでしか処理できず、毎秒120,000メッセージという要件を満たすには大幅にシャード数を増やす必要があります。さらに、DynamoDBからメッセージを読み取る方式では、コンシューマーアプリケーションが継続的にポーリングする必要があり、効率的ではありません。この構成は複雑でコストも高く、真のデカップリングが実現されていません。

B. 受注イベントをAmazon Managed Service for Apache Flinkへストリーミングし、複数のコンシューマーアプリケーションが分析結果を読み取って処理するよう設定します。

不正解 Amazon Managed Service for Apache Flinkはリアルタイムのストリーム処理・分析サービスであり、メッセージのデカップリングや配信には適していません。このサービスはApache Flinkを使用してストリーミングデータを変換・分析することが主目的です。複数のコンシューマーアプリケーションへメッセージを配信する仕組みは持たないため、要件である「数十のアプリケーションとマイクロサービスがメッセージを消費する」という部分を満たすことができません。

C. 受注イベントを取り込むアプリケーションを、複数のAmazon EC2インスタンスから成るAuto Scalingグループへデプロイし、CPU使用率に応じて台数を自動調整します。

不正解 EC2 Auto ScalingはCPUメトリクスに基づいてスケールしますが、突然のメッセージ量増加に対する反応速度が不十分です。インスタンスの起動には時間がかかり、毎秒120,000メッセージという急激な負荷変動に対応できません。また、このアプローチではアプリケーション間のデカップリングが実現されず、取り込みアプリケーションとコンシューマーアプリケーションが直接結合したままになります。運用コストも高くなる傾向があります。

D. 受注イベントをAmazon SNSトピックへパブリッシュし、複数のAmazon SQSキューをサブスクライブして、コンシューマーアプリケーションがそれぞれのキューから処理するよう設定します。

正解 SNSとSQSを組み合わせたファンアウトパターンは、メッセージの分離と拡張性の両方を実現する構成です。SNSトピックに一度パブリッシュされたメッセージは、複数のSQSキューに自動的に配信され、各コンシューマーアプリケーションが独立してメッセージを処理できます。標準SQSキューは実質的に無制限のスループットを提供し、複数キューの並列処理により毎秒120,000メッセージの要件も満たせます。

全体的な説明

問われている要件

• メッセージを取り込むアプリケーションと数十のコンシューマーアプリケーション間のデカップリング実現
• 毎秒120,000メッセージまで対応可能な高いスケーラビリティの確保
• 急激なメッセージ量変動への対応能力
• 複数のマイクロサービスが同一メッセージを並列処理できる仕組みの構築
• コスト効率性と運用の簡素化

前提知識

メッセージングサービスの特徴

• Amazon SNS：フルマネージドなパブリッシュ・サブスクライブメッセージングサービスで、一つのメッセージを複数の宛先に同時配信可能。標準トピックでは実質的に無制限のスループットを提供し、メッセージフィルタリング機能も備えています。FIFOトピックは既定で毎秒3,000メッセージまで対応し、高スループットモードを有効にすればさらに高いスループットを扱えます。
• Amazon SQS：フルマネージドなメッセージキューサービスで、標準キューは実質無制限のスループット、FIFOキューは既定で毎秒300メッセージ（バッチ利用時は毎秒3,000メッセージ）で、高スループットモードを使うとパーティションごとにこの値を確保してリージョンのクォータの範囲までスケールできます。デッドレターキューや可視性タイムアウトなど、信頼性の高いメッセージ処理機能を提供します。

ストリーミングサービスについて

• Amazon Kinesis Data Streams：リアルタイムデータストリーミングサービスで、シャードあたり毎秒1,000レコードまで処理可能。複数のコンシューマーが同一データを並列処理でき、データは最大365日間保持されます。オンデマンドモードではスループットに応じて自動でスケールしますが、プロビジョンドモードでシャード数を固定した構成では、その上限を超えるバーストを吸収できません。
• Amazon Managed Service for Apache Flink（旧 Amazon Kinesis Data Analytics）：Apache Flinkを使用したリアルタイムのストリーム処理・分析サービスで、Java、Scala、Python、SQLでストリーミングデータを処理できます。分析が主目的で、メッセージの配信には適していません。

コンピューティングサービスの特徴

• Amazon EC2 Auto Scaling：需要に応じてEC2インスタンス数を自動調整するサービスで、CPUやメモリなどのメトリクスに基づいてスケールします。インスタンス起動には通常30秒から数分かかり、急激な負荷変動への対応には限界があります。

解くための考え方

送信側と受信側を直接つながないことと、急増する負荷に追従できることが条件です。まず、デカップリングの要件を満たすには、メッセージの送信者と受信者が直接接続されない仕組みが必要です。次に、毎秒120,000メッセージという高いスループット要件と急激な負荷変動への対応を考慮する必要があります。選択肢を検討すると、Managed Service for Apache Flinkは分析サービスであり配信には不適切、EC2 Auto Scalingは起動時間の問題でリアルタイム性に欠ける、単一シャードのKinesis Data Streamsは容量不足という問題があります。一方、SNS + SQSの組み合わせは、SNSによる1対多のメッセージ配信とSQSによる非同期処理により、完全なデカップリングを実現します。さらに、複数のSQSキューを並列運用することで必要なスループットを確保でき、各コンシューマーアプリケーションが独立してスケールできます。

アーキテクチャ図の解説

アーキテクチャ図

SNSに一度パブリッシュしたメッセージが複数のSQSキューへ自動配信されるファンアウト構造によって、取り込み側と数十のコンシューマー側を分離します。取り込みアプリケーションはSNSトピックへ受注イベントをパブリッシュし、SNSが各SQSキューへ配信するため、コンシューマーは自分のキューをポーリングするだけで独立に処理できます。標準キューは実質無制限のスループットを持ち、複数キューを並列運用することで毎秒120,000メッセージのバーストにも対応します。単一シャードのKinesis Data Streamsへ書き込む構成では毎秒1,000レコードしか処理できず、DynamoDBからのポーリングも過剰な結合を残すため、急な増加時にメッセージが滞留します。

他のソリューションとの比較

Kinesis Data Streamsを使用したストリーミング処理と比較すると、SNS + SQSソリューションは運用が簡素でコスト効率に優れています。Kinesisはリアルタイム分析には適していますが、単純なメッセージ配信においては過剰な機能となり、シャード管理の複雑さとコストが増大します。EC2ベースのソリューションと比べて、完全マネージドサービスであるため運用負荷が大幅に軽減され、自動スケーリングにより予期しない負荷変動にも柔軟に対応できます。

実装の考慮事項

SQSの可視性タイムアウトは、コンシューマーの処理時間より長く設定します。毎秒120,000メッセージという規模では、順序保証のあるFIFOキューではスループットの制約が厳しいため、実質無制限のスループットを持つ標準キューを並列に使う構成が前提になります。

参考資料

• Amazon SNS とは – Amazon Simple Notification Service
• Amazon SQS とは – Amazon Simple Queue Service
• SNS から SQS へのファンアウト – Amazon Simple Notification Service
• Amazon Managed Service for Apache Flink とは – Amazon Managed Service for Apache Flink
• Amazon Kinesis Data Streams とは – Amazon Kinesis Data Streams
• Amazon EC2 Auto Scaling とは – Amazon EC2 Auto Scaling

正解：C

A. プライマリサーバーとコンピュートノードを Auto Scaling グループで管理される Amazon EC2 インスタンスで実装し、Amazon EventBridge をジョブの宛先として設定し、コンピュートノードのメモリ使用率に基づいて EC2 Auto Scaling を設定します。

不正解 Amazon EventBridge はイベントルーティングのサービスで、リアルタイムのイベント配信には優れていますが、バッチジョブのキューイングやワークロード管理には向いていません。また、コンピュートノードのメモリ使用率に基づくスケーリングでは、プライマリサーバーがボトルネックとして残ります。ジョブの宛先としても需要の指標としても、この要件には適合しません。

B. プライマリサーバーとコンピュートノードを Auto Scaling グループで管理される Amazon EC2 インスタンスで実装し、AWS CloudTrail をジョブの宛先として設定し、プライマリサーバーの CPU 使用率に基づいて EC2 Auto Scaling を設定します。

不正解 AWS CloudTrail は API コールのログ記録と監査を目的としたサービスで、ジョブの宛先としては技術的に不適切です。CloudTrail は AWS リソースへのアクション履歴を追跡するもので、分散処理のジョブキューイングやメッセージング機能は提供しません。また、プライマリサーバーの CPU 使用率に基づくスケーリングでは単一障害点が解消されず、回復力の向上につながりません。

C. Amazon Simple Queue Service（Amazon SQS）キューをジョブの宛先として設定し、Auto Scaling グループで管理される Amazon EC2 インスタンスでコンピュートノードを実装し、キューのサイズに基づいて EC2 Auto Scaling を設定します。

正解 SQS キューがプライマリサーバーとコンピュートノードを完全に分離し、真のデカップリングを実現します。キューのサイズ（メッセージ数）に基づく Auto Scaling は、実際の需要に応じてコンピュートリソースを動的に増減できます。キューにジョブが溜まればインスタンスが追加され、減れば削減されるため、応答性とコスト効率を両立できます。この方式は高い回復力とスケーラビリティを提供します。

D. Amazon Simple Queue Service（Amazon SQS）キューをジョブの宛先として設定し、Auto Scaling グループで管理される Amazon EC2 インスタンスでコンピュートノードを実装し、スケジュール済みスケーリングを使用するように EC2 Auto Scaling を設定します。

不正解 SQS キューをジョブの宛先として使う点は適切です。しかし、スケジュール済みスケーリングは可変ワークロードには適していません。スケジュールベースのスケーリングは予測可能な負荷パターン向けで、ピークが通常時の 12 倍に達するような突発的な変動には追従できません。事前に決めた時刻にだけ依存するため、リソースの過剰プロビジョニングや不足が生じやすくなります。

全体的な説明

問われている要件

• 動画トランスコード基盤を AWS へ移行してモダナイズすること
• プライマリサーバーとコンピュートノード間の回復力を高めること
• ピーク時に通常時の 12 倍へ増える可変ワークロードへ追従すること
• 単一障害点を排除して耐障害性を強化すること
• コスト効率を保ちながらリソースを動的に管理すること

前提知識

Amazon SQS の特徴は次のとおりです。

• フルマネージドなメッセージキューサービスで、メッセージを最長 14 日間保持します
• 標準キューは実質無制限のスループットを提供し、FIFO キューは順序保証とちょうど 1 回の配信を実現します
• デッドレターキューと可視性タイムアウトにより信頼性の高い処理を支援します
• プロデューサーとコンシューマーを分離し、各コンポーネントを独立してスケールできるようにします

Amazon EC2 Auto Scaling の特徴は次のとおりです。

• 需要の変化に応じて EC2 インスタンスの数を自動調整します
• 動的スケーリング（ターゲット追跡、ステップ、シンプル）に加え、スケジュールされたスケーリングと予測スケーリングを利用できます
• SQS キューの深さをスケーリング指標にできます。実装では、キュー内のメッセージ数（ApproximateNumberOfMessages）を稼働中のインスタンス数で割った「インスタンスあたりのバックログ」をターゲット追跡の指標にする方法が推奨で、CloudWatch のメトリクスマスで算出できます

AWS CloudTrail の特徴は次のとおりです。

• AWS API コールのログ記録と監査のためのサービスです
• ジョブのキューイングやメッセージング機能は提供しません

Amazon EventBridge の特徴は次のとおりです。

• サーバーレスのイベントルーティングサービスです
• リアルタイムのイベント配信には適しますが、継続的なバッチジョブ処理には向きません

解くための考え方

単一のプライマリサーバーに依存した分散処理を、コンポーネントが独立して動く構成へ置き換えることが条件です。既存システムでは単一のプライマリサーバーがボトルネックとなり、障害時には全体が停止するリスクがあります。モダナイゼーションの目標は、この単一障害点を排除し、各コンポーネントが独立して動くデカップリング構成を実現することです。

ピーク時に通常時の 12 倍へ増える可変ワークロードには、事前に決めたスケジュールではなく、実際の需要に基づく動的スケーリングが欠かせません。選択肢を検討すると、CloudTrail と EventBridge はジョブ処理の文脈では技術的に不適切で、SQS がメッセージキューイングの標準的な解決策となります。スケーリング指標としては、キューの深さが実際の需要を最も正確に反映するため、キューサイズベースのスケーリングが最適です。この方式により、高可用性、費用対効果、運用の簡素化を同時に実現できます。

アーキテクチャ図の解説

アーキテクチャ図

プライマリサーバーとコンピュートノードの間に SQS キューを挟み、スケーリングの判断をキューの深さに委ねています。プライマリサーバーはエンコードジョブを SQS キューへ送るだけで、ノードの状態を意識せずに次の処理へ進めます。CloudWatch はキューに溜まったメッセージ数を ApproximateNumberOfMessages メトリクスとして監視し、Auto Scaling グループがその値に応じて EC2 インスタンスを増減します。各コンピュートノードはキューからジョブを取り出して処理し、完了後にメッセージを削除するため、ノードは複数のアベイラビリティゾーンへ分散できます。もしスケジュール済みスケーリングを選ぶと、ピークが通常時の 12 倍に達する突発的な変動に追従できず、需要が増えた時間帯に処理が滞ったり、需要の少ない時間帯にインスタンスが余ったりします。

他のソリューションとの比較

従来のマスター・ワーカー構成と比べると、SQS ベースの構成は単一障害点を排除し、高い可用性を実現します。Kinesis Data Streams を使うストリーミング処理と比べると、シャード管理の複雑さがなくバッチジョブ処理に向きます。Lambda を使うサーバーレス構成と比べると、長時間のトランスコードや複雑な処理に柔軟に対応できます。

実装の考慮事項

可視性タイムアウトはジョブの処理時間より長くし、失敗したジョブはデッドレターキューへ分けます。

参考資料

• Amazon SQS とは – Amazon Simple Queue Service
• Amazon EC2 Auto Scaling とは – Amazon EC2 Auto Scaling
• Amazon SQS に基づく Amazon EC2 Auto Scaling – Amazon EC2 Auto Scaling
• ターゲット追跡スケーリングポリシー – Amazon EC2 Auto Scaling
• AWS CloudTrail とは – AWS CloudTrail
• Amazon EventBridge とは – Amazon EventBridge

正解：C

A. AWS DataSync を使用して、SMB ファイルサーバーから 7 日より古いデータを AWS へコピーします。

不正解 DataSync は一方向のデータ転送サービスで、継続的なストレージ容量拡張には適していません。この方式は古いデータを AWS へ移すだけで、オンプレミスの容量は実質的に増えません。また、移行したデータへの日常的なアクセス方法や統合的なファイル管理が提供されず、ライフサイクル管理も自動化できません。DataSync は主に一度きりの移行や定期同期に使うサービスです。

B. Amazon FSx for Windows File Server のファイルシステムを作成して企業のストレージ容量を拡張します。

不正解 FSx for Windows File Server は高性能なマネージドファイルシステムを提供しますが、経過日数に応じて低コストなアーカイブ階層へ自動移行するライフサイクル管理を備えていません。データ重複排除やシャドウコピーは利用できるものの、古いファイルを退避する仕組みがないため、時間の経過とともに同じ容量問題が再発します。また、オンプレミスの SMB サーバーとの統合や移行の複雑さを踏まえると、要件を十分に満たすソリューションではありません。

C. Amazon S3 File Gateway を導入して SMB プロトコルのまま S3 へ接続し、7 日を過ぎたデータを自動で S3 Glacier Deep Archive へ移す設定を行います。

正解 S3 File Gateway は SMB プロトコルをネイティブにサポートし、既存のファイルサーバーと透過的に統合できます。ローカルキャッシュにより頻繁にアクセスされるファイルは高速に読めるため、低レイテンシ要件を満たします。S3 の実質無制限の容量で根本的な容量問題を解決し、ライフサイクルポリシーによる自動アーカイブでコストも最適化します。7 日後に Glacier Deep Archive へ移行することで、長期保存コストを大幅に下げられます。

D. 各ユーザーのコンピューターに Amazon S3 へアクセスするユーティリティをインストールし、7 日後にデータを S3 Glacier Flexible Retrieval へ移行する S3 ライフサイクルポリシーを作成します。

不正解 各ユーザーのコンピューターへ個別にユーティリティを入れる方式は、スケーラビリティと管理性の面で現実的ではありません。利用者が増えるたびに設定が必要になり、セキュリティポリシーの管理も複雑になります。また、参照がほぼなくなる 7 日後のデータには Flexible Retrieval より Deep Archive の方が適しており、長期保存のコスト効率でも劣ります。手動の工程を伴うため運用負荷が高く、エンタープライズ環境には向きません。

全体的な説明

問われている要件

• SMB ファイルサーバーの容量不足を解消してストレージを拡張すること
• 最近アクセスされたファイルへの低レイテンシアクセスを維持すること
• 7 日経過後のアクセス低下に合わせてコストを最適化すること
• 自動化されたファイルライフサイクル管理で将来の容量問題を回避すること
• 既存システムと透過的に統合して運用を継続すること

前提知識

Amazon S3 File Gateway の特徴は次のとおりです。

• オンプレミス環境と S3 を接続するハイブリッドクラウドストレージサービスです
• NFS・SMB プロトコルを通じて S3 バケットへのファイルアクセスを提供します
• ローカルキャッシュにより頻繁にアクセスされるデータを高速に読み出せます
• ローカルキャッシュと帯域幅制限、暗号化を備えます

AWS DataSync の特徴は次のとおりです。

• オンプレミス、AWS、他クラウド間のデータ転送を自動化するサービスです
• 初回移行や定期同期に適しますが、リアルタイムアクセスには対応しません

Amazon FSx for Windows File Server の特徴は次のとおりです。

• Windows 環境向けのフルマネージドファイルシステムです
• SMB・NTFS・Active Directory 統合をサポートしますが、アーカイブ階層への自動移行によるライフサイクル管理は提供しません

Amazon S3 ライフサイクルポリシーとストレージクラスの特徴は次のとおりです。

• 作成日や最終アクセス日を基準に、ストレージクラス間を自動で移行します
• S3 Glacier Deep Archive は長期アーカイブ向けの最も低コストなクラスで、標準取得に約 12 時間かかります
• Standard から Deep Archive への移行で最大 95% のコスト削減が可能です

解くための考え方

オンプレミスの容量不足を、既存のSMBアクセスを保ったままクラウド側へ伸ばすことが条件です。要件のうち「低レイテンシアクセスの維持」と「ライフサイクル管理」が重要なキーワードです。既存の SMB ファイルサーバー環境を維持しながら容量を拡張するため、プロトコル互換性が必須です。また、7 日間というアクセスパターンの変化を活用したコスト最適化が求められます。

選択肢を検討すると、DataSync は移行ツールであり継続的な拡張には不適切です。FSx はライフサイクル管理がありません。ユーティリティ方式は運用性に問題があります。S3 File Gateway は、SMB プロトコルサポート、ローカルキャッシュによる低レイテンシ、S3 の無制限容量、自動ライフサイクル管理をすべて統合的に提供する最適解です。これにより、運用負荷を増やさずにスケーラブルで費用対効果の高いストレージを実現できます。

アーキテクチャ図の解説

アーキテクチャ図

既存の SMB サーバーの手前に S3 File Gateway を置き、データを S3 へ移しつつ手元のアクセス性能を維持しています。利用者は従来どおり SMB・CIFS プロトコルでファイルへアクセスし、頻繁に使うファイルはゲートウェイのローカルキャッシュから高速に読み出せます。新しいファイルはゲートウェイ経由で S3 バケットへ書き込まれ、キャッシュミス時のみクラウドから取得します。作成から 7 日を過ぎたオブジェクトはライフサイクルポリシーが自動的に S3 Glacier Deep Archive へ移し、長期保存コストを最大 95% 削減します。もし DataSync で古いデータを単純にコピーするだけの構成にすると、容量は増えず、7 日を過ぎたデータへの透過的なアクセスもライフサイクル管理も実現できません。

他のソリューションとの比較

従来の SAN・NAS の増設と比べると、S3 File Gateway は設備投資が不要で容量制限がありません。DataSync ベースのアーカイブと比べると、ファイルアクセスの透明性と継続性で優れています。FSx for Windows File Server と比べると、自動ライフサイクル管理とコスト最適化で差別化されます。完全クラウド移行と比べると、既存インフラとの互換性を保ちながら段階的に移行できるため、リスクを抑えられます。

実装の考慮事項

ローカルキャッシュはよく使うデータ量に合わせます。Glacier Deep Archiveからの取り出しには約12時間かかるため、業務の待ち時間に含めます。

参考資料

• Amazon S3 File Gateway とは – AWS Storage Gateway
• Amazon S3 ライフサイクル設定 – Amazon Simple Storage Service
• S3 Glacier storage classes – Amazon Simple Storage Service
• AWS DataSync とは – AWS DataSync
• Amazon FSx for Windows File Server とは – Amazon FSx

正解：C

A. アプリケーションが予約を受信したときに Amazon Simple Notification Service（Amazon SNS）トピックへメッセージをパブリッシュする API Gateway 統合を使用し、処理を実行する AWS Lambda 関数をトピックへサブスクライブします。

不正解 Amazon SNS の標準トピックはメッセージの順序を保証しません。複数のサブスクライバーへの並列配信により、受信した順序と異なる順序で処理されることがあります。SNS FIFO トピックなら順序は保証できますが、この選択肢では FIFO が明記されていません。また、SNS FIFO トピックは Lambda 関数を直接サブスクライブできず、SQS キュー（FIFO または標準）を経由してから Lambda を呼び出す必要があります。

B. アプリケーションが予約を受信したときに Amazon Simple Queue Service（Amazon SQS）標準キューへメッセージを送信する API Gateway 統合を使用し、処理のために SQS 標準キューが AWS Lambda 関数を呼び出すよう設定します。

不正解 Amazon SQS の標準キューは高いスループットと可用性を提供しますが、厳密な順序保証は行いません。分散アーキテクチャの性質上、メッセージが順不同で配信されることがあります。標準キューはベストエフォートの順序を提供するため、在庫確保と決済を正しい順序で行う必要がある用途には適していません。メッセージの重複配信も起こり得ます。

C. アプリケーションが予約を受信したときに、順序保証と重複排除を提供する Amazon Simple Queue Service（Amazon SQS）キューへメッセージを送信する API Gateway 統合を使用し、そのキューが AWS Lambda 関数を呼び出すよう設定します。

正解 Amazon SQS FIFO キューは、順序保証と重複排除を提供する専用サービスです。First-In-First-Out の配信により、予約は受け付けた順番どおりに厳密に処理されます。API Gateway から SQS FIFO キューへの統合は標準的なパターンで、Lambda 関数をイベントソースマッピングで接続すれば自動的に予約を処理できます。この構成は、在庫確保と決済を正しい順序で行う要件を完全に満たします。

D. アプリケーションが予約を受け付ける API Gateway にカスタムオーソライザーを設定し、直前の予約の処理が完了するまで後続のリクエストを待機させてから、在庫確保と決済を実行する AWS Lambda 関数へ順番に引き渡します。

不正解 API Gateway オーソライザーは認証・認可を目的とした機能で、メッセージの順序保証には適用できません。予約の処理中に他のリクエストをブロックする方式は、システム全体のスケーラビリティと可用性を大きく損ないます。単一の処理スレッドに依存するため、販売開始時の高負荷で性能が低下し、障害のリスクも高まります。この方式はクラウドネイティブなアーキテクチャの原則に反します。

全体的な説明

問われている要件

• 予約プラットフォームで予約情報を処理すること
• API Gateway REST API を通じて予約データを受信すること
• 受信順と処理順を厳密に一致させること
• スケーラブルで信頼性の高い非同期処理を構築すること
• Lambda 関数で在庫確保と決済を効率的に自動化すること

前提知識

Amazon SQS FIFO キューの特徴は次のとおりです。

• 厳密な順序保証と重複排除を提供するメッセージキューサービスです
• メッセージグループ ID による並列処理とコンテンツベースの重複排除をサポートします
• 既定では 1 パーティションあたりバッチ使用時に毎秒 3,000 メッセージまで対応し、高スループットモードを有効にするとリージョンによって毎秒数万メッセージ規模まで拡張できます
• メッセージの保持期間は最長 14 日間です
• 順序が重要な予約・金融取引・在庫管理などに適します

Amazon SQS 標準キューの特徴は次のとおりです。

• 実質無制限のスループットと少なくとも 1 回の配信を保証します
• 順不同や重複の配信が起こり得るため、順序が重要でない用途に向きます

Amazon SNS の特徴は次のとおりです。

• 標準トピックは 1 対多の高速配信を提供しますが、順序は保証しません
• FIFO トピックは順序と重複排除を提供しますが、サブスクライブできるのは SQS キュー（FIFO または標準）だけで、Lambda やメール、HTTP(S) は直接指定できません

API Gateway 統合の特徴は次のとおりです。

• AWS Service 統合により、SQS や DynamoDB へ Lambda を介さずにデータを渡せます
• 非同期処理パターンに適し、システムの分離性と拡張性を高めます

解くための考え方

予約の処理順を崩さないことが条件です。まず、各選択肢を順序保証の観点から評価します。SNS 標準トピックと SQS 標準キューは高いスループットを提供しますが、順序は保証しません。API Gateway オーソライザーによるブロッキングは順序を保てますが、スケーラビリティを犠牲にします。SQS FIFO キューは順序保証のサービスで、メッセージグループ ID による論理的な順序付けとコンテンツベースの重複排除により、厳密な順序処理を実現します。さらに Lambda とのイベントソースマッピングにより、ポーリングベースの効率的な非同期処理が可能です。この選択により、可用性と拡張性を保ちながら要件の順序保証を確実に満たせます。

アーキテクチャ図の解説

アーキテクチャ図

API Gateway と Lambda の間に SQS FIFO キューを置き、順序保証をキューへ委ねています。Web やモバイルから送られた予約は、API Gateway の AWS Service 統合を通じて直接 SQS FIFO キューへ配信されます。各メッセージにはメッセージグループ ID が付与され、同一グループ内は受信順を維持して処理されます。コンテンツベースの重複排除がネットワーク障害や再試行による二重予約を防ぎます。Lambda 関数はイベントソースマッピングでキューから予約を順番に取り出し、在庫確保と決済を実行して DynamoDB と S3 へ保存します。もし標準キューや SNS 標準トピックを選ぶと順序が保証されず、販売開始時の高負荷で予約の成立順が崩れ、在庫の二重確保や決済の不整合が起きる恐れがあります。

他のソリューションとの比較

同期処理と比べると、SQS FIFO ベースの構成は可用性と拡張性に優れます。Apache Kafka や RabbitMQ などのオープンソースブローカーと比べると、完全マネージドによる運用負荷の軽減と AWS エコシステムとの統合が利点です。データベース直接書き込みと比べると、負荷分散と障害時の復旧性で優れています。SNS と SQS 標準キューの組み合わせと比べると、順序保証の確実性で要件に適合します。

実装の考慮事項

FIFOのメッセージグループIDで、並列数と順序保証の単位を決めます。グループが1つだと処理は直列になります。

参考資料

• Amazon SQS FIFO キューの使用 – Amazon Simple Queue Service
• API Gateway で HTTP API の AWS のサービス統合を作成する
• AWS Lambda での Amazon SQS の使用 – AWS Lambda
• FIFO キューの順序付けと重複排除 – Amazon Simple Queue Service
• Amazon SNS とは – Amazon Simple Notification Service
• Lambda 関数のイベントソースマッピング – AWS Lambda
• SQS キューの監視とログ記録 – Amazon Simple Queue Service