Uncategorized

#62

 

了解しました！こちらの問題も指定フォーマットで整理しました。

■問題文

ある会社には、写真共有ソーシャルネットワーキングアプリケーションがあります。ユーザーに一貫したエクスペリエンスを提供するために、アプリケーションに公開する前にユーザーがアップロードした写真に対して画像処理を行っています。画像処理は、Pythonライブラリのセットを使用して実装されています。

現在のアーキテクチャは以下の通りです。

  • 画像処理の Python コードは単一の Amazon EC2 インスタンスで実行され、処理された画像は ImageBucket という名前の Amazon S3 バケットに保存されます。
  • 別のバケットでホストされているフロントエンドアプリケーションは、ImageBucket から画像を読み込んでユーザーに表示します。

同社は、グローバル展開を計画しており、既存のアーキテクチャに変更を加えて、アプリケーションに対する需要の増加に合わせて拡張し、アプリケーションの拡張に伴う管理の複雑さを軽減できるようにしたいと考えています。

ソリューションアーキテクトはどの変更の組み合わせを行う必要がありますか？ (2 つ選択）

■選択肢

A. AWS Lambda を使用して画像処理タスクを実行します。
B. ImageBucket の前で Amazon CloudFront を使用します。
C. アプリケーションを Amazon ECS クラスターにデプロイし、Service Auto Scaling を適用します。
D. 画像処理に EC2 インスタンスを Auto Scaling グループに配置します。
E. 画像処理に Amazon Rekognition を使用します。

■問題文の要件の概要

  • 現状は 単一 EC2 で処理 → S3 に保存 → フロントエンドから参照
  • グローバル展開に向けて：
    • スケーラブルなアーキテクチャ に変更したい
    • 管理の複雑さを軽減したい
    • ユーザーに高速に画像配信したい

■正解の選択肢と解説

A. AWS Lambda を使用して画像処理タスクを実行します。

  • EC2 単体ではスケールが困難。Lambda を使えば S3 イベント通知を契機に自動実行され、サーバレスで水平スケール可能。管理コスト削減に直結。

B. ImageBucket の前で Amazon CloudFront を使用します。

  • グローバル配信に必要な CDN。世界中のエッジロケーションからキャッシュを配信し、ユーザー体験を向上。S3 直アクセスよりも高速かつセキュアに配信可能。

■不正解の選択肢の理由

  • C. ECS + Service Auto Scaling
    • スケール可能だが、Lambda と比べて管理（コンテナオーケストレーション、クラスター運用）が複雑。要件の「管理の複雑さ軽減」に合致しない。
  • D. EC2 Auto Scaling
    • サーバ運用が必要で Lambda よりも管理負荷が高い。スケールはできるが「サーバレスで簡素化」の要件を満たさない。
  • E. Amazon Rekognition
    • Rekognition は画像認識/解析（顔検出、オブジェクト検出等）のサービスであり、既存の Python ベースの「画像処理（リサイズ・フォーマット変換等）」とは用途が異なるため不適切。

■SAP試験で押さえておくべきポイント

  • S3 + Lambda (イベント駆動処理) → サーバレス画像処理の定石。スケーラブルで高可用性。
  • CloudFront + S3 → グローバル展開時に必須の設計パターン。ユーザー体験向上とセキュリティ強化。
  • ECS / EC2 Auto Scaling はスケーリング可能だが「管理の複雑さ軽減」という要件では不適切。
  • Rekognition は ML サービスであり、画像加工ではなく画像解析が目的。

👉 この問題は「グローバル展開 × サーバレス × CDN」という 試験頻出の組み合わせ です。

次の問題も同じフォーマットで解説していきますか？

了解しました。ご依頼の形式で整理しました。

■問題文

ある企業が、us-east-1 リージョンで、オンプレミスの MySQL データベースを Amazon Aurora MySQL に 1 回限りの移行を計画しています。同社の現在のインターネット接続は帯域幅が限られています。オンプレミスの MySQL データベースのサイズは 60 TB です。同社は、現在のインターネット接続を介してデータを AWS に転送するには 1 ヶ月かかると見積もっています。同社は、データベースをより迅速に移行する移行ソリューションを必要としています。

最も短時間でデータベースを移行できるソリューションを選択してください。

■選択肢

A. AWS Snowball Edge デバイスを注文します。S3 インターフェイスを使用して Amazon S3 バケットにデータをロードします。AWS Database Migration Service (AWS DMS) を使用して、Amazon S3 から Aurora MySQL にデータを移行します。

B. 現在のインターネット接続で AWS DataSync を使用して、オンプレミスのデータセンターと AWS 間のデータ転送を高速化します。AWS Application Migration Service を使用して、オンプレミスの MySQL データベースを Aurora MySQL に移行します。

C. オンプレミスのデータセンターと AWS の間の 1 Gbps AWS Direct Connect 接続を要求します。AWS Database Migration Service (AWS DMS) を使用して、オンプレミスの MySQL データベースを Aurora MySQL に移行します。

D. AWS Snowball デバイスを注文します。Snowball 用 S3 Adapter を使用して、Amazon S3 バケットにデータをロードします。AWS Application Migration Service を使用して、Amazon S3 から Aurora MySQL にデータを移行します。

■問題文の要件の概要

  • 移行対象: オンプレミス MySQL → Aurora MySQL
  • データ量: 60 TB
  • 制約: インターネット帯域幅が狭く、直接転送すると 1か月かかる
  • 要件: 最も短時間で一回限りの移行を完了する

■正解の選択肢と解説

正解: A

  • AWS Snowball Edge は大規模データを物理デバイス経由で AWS に転送するサービス。
  • 60TB のような大容量データでは、ネットワーク経由よりも Snowball Edge を使う方が高速で現実的。
  • データを Snowball Edge 経由で Amazon S3 にロードした後、AWS DMS を使って Aurora MySQL へロードできる。
  • DMS はデータベース移行に最適化されており、Snowball Edge と組み合わせて「迅速かつ一回限りの移行」を実現できる。

■不正解の選択肢の理由

  • B. DataSync + Application Migration Service
    • DataSync はファイルベース転送に最適で、60TB の DB データ移行には不向き。
    • Application Migration Service はサーバリフト移行向けで、RDB 直接移行には適していない。
  • C. Direct Connect (1Gbps) + DMS
    • 1Gbps では 60TB の転送に数日〜数週間かかり、短時間移行要件に不適合。
    • Direct Connect の調達にもリードタイムがかかる。
  • D. Snowball (通常版) + Application Migration Service
    • Snowball（通常）は容量面で Edge より非効率。
    • さらに Application Migration Service は Aurora への DB 移行に対応していないため不適切。

■SAP試験で押さえておくべきポイント

  1. 大容量データ移行のベストプラクティス
    • 数十 TB クラス以上では、Snowball Edge + S3 + DMS の組み合わせが定石。
    • 帯域制限があるときはネットワーク経由の転送は避ける。
  2. DataSync と DMS の違い
    • DataSync → ファイルシステム転送（EFS, FSx, S3）。
    • DMS → データベース移行専用（スキーマ・レプリケーション含む）。
  3. Direct Connect の制約
    • 帯域に応じてデータ転送時間を計算できる必要がある。
    • 短時間移行が要件なら Direct Connect は不適切。
  4. 試験視点
    • 「最短時間で大容量 DB 移行」＝ Snowball Edge + DMS がキーワード解答。

この整理で進めていけば、同様の 「大容量データ移行 vs 帯域制約 vs 一回限り」 の設問に対応できます。

👉 続けて、他の問題文も同じフォーマットで整理していきますか？

了解しました。問題3についても整理しました。

■問題文

ある会社が、オンプレミス環境で 3 層のウェブアプリケーションをホストしています。最近のトラフィックの急増によりダウンタイムが発生し、経済的にも大きな影響が出たため、会社の経営陣はアプリケーションを AWS に移行するように命じました。アプリケーションは .NET で記述されており、MySQL データベースに依存しています。ソリューションアーキテクトは、毎日 20 万人のユーザーの需要を満たすために、スケーラブルで可用性の高いソリューションを設計する必要があります。ソリューションアーキテクトが適切なソリューションを設計するために実行する必要がある手順はどれですか。

■選択肢

A. AWS CloudFormation を使用して、3 つのアベイラビリティーゾーンにまたがるスポットインスタンスの Amazon ECS クラスターの前に Application Load Balancer (ALB) を含むスタックを起動します。スタックは、 Snapshot 削除ポリシーを持つ Amazon RDS MySQL DB インスタンスを起動する必要があります。Amazon Route 53 エイリアスレコードを使用して、会社のドメインから ALB にトラフィックをルーティングします。

B. AWS Elastic Beanstalk を使用して、ウェブサーバー環境と Amazon RDS for MySQL DB インスタンスのマルチ AZ 配置を備えた新しいアプリケーションを作成します。環境は、複数のアベイラビリティーゾーンの Amazon EC2 Auto Scaling グループの前で Network Load Balancer (NLB) を起動する必要があります。Amazon Route 53 エイリアスレコードを使用して、会社のドメインから NLB にトラフィックをルーティングします。

C. AWS Elastic Beanstalk を使用して、各リージョンに Application Load Balancer (ALB) を備えた 2 つの別々のリージョンにまたがる Auto Scaling を使用したウェブサーバー環境を作成します。クロスリージョンリードレプリカを使用して、Amazon Aurora MySQL DB クラスターのマルチ AZ 配置を作成します。Amazon Route 53 を地理的近接性ルーティングポリシーとともに使用して、2 つのリージョン間でトラフィックをルーティングします。

D. AWS CloudFormation を使用して、3 つのアベイラビリティーゾーンにまたがる Amazon EC2 Auto Scaling グループの前に Application Load Balancer (ALB) を含むスタックを起動します。スタックは、Retain 削除ポリシーを持つ Amazon Aurora MySQL DB クラスターのマルチ AZ 配置で起動する必要があります。Amazon Route 53 エイリアスレコードを使用して、会社のドメインから ALB にトラフィックをルーティングします。

■問題文の要件の概要

  • 現状の課題: オンプレミスで 3 層アプリ、トラフィック急増でダウンタイム発生
  • 要件:
    • 高スケーラビリティ
    • 高可用性
    • 20万ユーザー/日規模を安定稼働できる設計
  • 技術条件: .NET アプリケーション + MySQL

■正解の選択肢と解説

正解: D

  • EC2 Auto Scaling + ALB (3AZ) → ウェブ層をスケールアウトさせ、可用性を担保できる。
  • Aurora MySQL マルチAZ配置 → MySQL 互換かつ可用性・スケーラビリティに優れたマネージドDB。
  • CloudFormation → IaC で再現性・運用効率を高める。
  • Route 53 エイリアスレコード → ドメインから ALB へのスムーズなトラフィックルーティングを実現。
  • Retain 削除ポリシー → 誤ってスタック削除しても DB を保持する設計。

この構成により、アプリケーションはスケーラブルかつ高可用な設計を満たせる。

■不正解の選択肢の理由

  • A. ECS クラスター + スポットインスタンス + RDS MySQL
    • スポットインスタンスはコスト効率は良いが、突発的な中断があり高可用性要件には不向き。
    • DB がシングル AZ の RDS MySQL で、マルチAZ高可用性を満たしていない。
  • B. Elastic Beanstalk + RDS MySQL + NLB
    • NLB は TCP/TLS レイヤーで最適化されており、HTTP/HTTPS ワークロードには ALB の方が適切。
    • アプリ層の負荷分散に NLB を使うのは不適切。
  • C. Elastic Beanstalk + クロスリージョン構成 + Aurora
    • Beanstalk は1リージョン内が前提であり、マルチリージョン設計は複雑で非推奨。
    • 試験問題の要件では過剰設計で、必要以上の複雑性を追加してしまう。

■SAP試験で押さえておくべきポイント

  1. スケーラブルWebアプリの基本構成
    • EC2 Auto Scaling + ALB + RDS/Aurora マルチAZ が定石パターン。
    • Route 53 を組み合わせてドメインルーティング。
  2. ロードバランサーの選択
    • ALB: HTTP/HTTPS レイヤー7 に最適。
    • NLB: TCP/UDP/TLS レイヤー4 に最適。
    • 問題で Web アプリケーションなら基本は ALB。
  3. Aurora vs RDS
    • 高可用性とスケーラビリティを重視するなら Aurora。
    • Snapshot 削除ポリシーではなく、Retain 削除ポリシーが試験的に問われやすい。
  4. 試験戦略
    • 「高可用性」「スケーラビリティ」が強調されている場合は、Multi-AZ + Auto Scaling + ALB 構成を選ぶ。
    • 過剰に複雑な構成は誤答候補になりやすい。

👉 この問題は 「三層アプリの AWS 標準設計」 を問う定番パターンです。

次の問題も整理していきますか？

了解しました。いただいた問題を整理して、指定の形式で出力します。

■問題文

企業には、企業ネットワークに接続されていない VPC 内のパブリックサブネットとプライベートサブネットの両方に複数の Amazon EC2 インスタンスがあります。EC2 インスタンスに関連付けられたセキュリティグループにより、企業はインターネット経由で Windows リモートデスクトッププロトコル (RDP) を使用してインスタンスにアクセスできます。セキュリティチームは、未知のソースからの接続試行に気づきました。同社は、EC2 インスタンスにアクセスするために、より安全なソリューションを実装したいと考えています。ソリューションアーキテクトはどの戦略を実装する必要がありますか？

■選択肢

A. 企業ネットワークと VPC を接続する Site-to-Site VPN を確立します。セキュリティグループを更新して、企業ネットワークからのアクセスのみを許可します。

B. EC2 インスタンスに AWS Systems Manager エージェントをデプロイします。Session Manager を使用して EC2 インスタンスにアクセスし、権限を持つユーザーへのアクセスを制限します。

C. VPC 内のすべてのインスタンスにアクセスできる企業ネットワークに Linux の踏み台ホストをデプロイします。

D. パブリックサブネットに Elastic IP アドレスを使用して Linux の踏み台ホストをデプロイします。 0.0.0.0/0 から踏み台ホストへのアクセスを許可します。

■問題文の要件の概要

  • VPC は企業ネットワークに未接続
  • インターネット経由で RDP（3389/TCP）が開放されている
  • 未知のソースからのアクセス試行が検出された → セキュリティリスク
  • より安全なアクセス方法が必要

■正解の選択肢と解説

正解：B. AWS Systems Manager Session Manager を利用する

  • Session Manager はインバウンドポートを開放する必要がなく、ブラウザまたは CLI を介して安全に EC2 に接続可能。
  • Windows インスタンスにも対応しており、ポートフォワーディングを使えば RDP も利用できる。
  • IAM によるアクセス制御や CloudTrail へのログ記録も可能で、セキュリティチームの要件を満たす。

■不正解の選択肢の理由

  • A. Site-to-Site VPN
    → VPN 接続によりセキュアにはなるが、依然として RDP ポートを開放する必要がある。Session Manager のように完全にポート閉鎖して運用する方法に比べるとセキュリティが劣る。
  • C. 企業ネットワークに踏み台ホスト
    → 企業ネットワークに踏み台を置いても VPC とつながっていないためアクセス不可。VPN がなければ機能しない。
  • D. パブリックサブネットに踏み台ホスト (0.0.0.0/0 許可)
    → 踏み台ホストを全世界に公開してしまいリスクが増大。セキュリティベストプラクティスに反する。

■SAP試験で押さえておくべきポイント

  • Session Manager
    • インバウンドポートを閉じたまま安全に管理可能
    • IAM による権限管理、CloudTrail による監査ログが可能
    • RDP もポートフォワーディングで利用可能
  • 踏み台ホストや VPN は「古典的な手法」としては使えるが、セキュリティ・運用の観点では Session Manager が推奨される。

次の問題も同じ形式で整理していきますか？

ありがとうございます！いただいた問題を整理して指定フォーマットで出力しました。

問題文

ソリューションアーキテクトは、3 層アプリケーションの災害復旧戦略を設計しています。アプリケーションのデータ層の RTO は 30 分、RPO は 5 分です。アプリケーション層とウェブ層はステートレスであり、Amazon EC2 インスタンスのフリートを利用しています。データ層は、50 TB の Amazon Aurora データベースで構成されています。コストを最適化しながら、RTO と RPO の要件を満たすステップの組み合わせはどれですか？ (2 つ選択）

選択肢

A. AWS バックアップジョブを作成してデータを別のリージョンにレプリケートします。
B. Aurora データベースのスナップショットを 5 分ごとに作成します。
C. アプリケーションのホットスタンバイを別のリージョンにデプロイします。
D. データベースのクロスリージョン Aurora レプリカを作成します。
E. EC2 インスタンスの毎日のスナップショットを作成し、スナップショットを別のリージョンにレプリケートします。

問題文の要件の概要

  • 災害復旧戦略設計の問題。
  • 要件:
    • データ層の RTO（30分以内）
    • データ層の RPO（5分以内）
  • 構成:
    • アプリ/Web層はステートレス（EC2フリートで対応可能）
    • データ層は 50TB の Amazon Aurora

👉 ポイントは「Aurora データの短い RPO（5分）」をどう満たすか、かつ「コストを抑えつつ 30分以内に復旧」できる手段を選ぶこと。

正解の選択肢と解説

  • D. データベースのクロスリージョン Aurora レプリカを作成します。
    • Aurora のクロスリージョンレプリカは数秒～数分以内にデータを同期できるため、RPO 5分を満たせる。
    • 災害発生時はフェイルオーバー先を昇格させて短時間で稼働可能。
  • E. EC2 インスタンスの毎日のスナップショットを作成し、スナップショットを別のリージョンにレプリケートします。
    • アプリ/Web層はステートレスなので、AMIやスナップショットを使って30分以内にリカバリ可能。
    • 毎日バックアップで十分。Aurora に比べて要求は緩いためコスト最適化も実現。

不正解の選択肢の理由

  • A. AWS バックアップジョブを作成してデータを別のリージョンにレプリケートします。
    • Aurora 専用のクロスリージョンレプリカの方が RPO を短くできる。AWS Backup はRPOが緩く、RPO=5分に不十分。
  • B. Aurora データベースのスナップショットを 5 分ごとに作成します。
    • 頻繁なスナップショットは高コストで非効率。さらに復旧にはインスタンス再作成が必要で、RTO 30分を満たしにくい。
  • C. アプリケーションのホットスタンバイを別のリージョンにデプロイします。
    • 可用性は確保できるが、常にリソースを稼働させるためコストが高い。コスト最適化の要件に反する。

SAP試験で押さえておくべきポイント

  • Aurora クロスリージョンレプリカは短い RPO を実現できる主要手段。
  • スナップショットのみでは RTO が延びる（再構築が必要）。
  • ホットスタンバイは可用性を高めるが、費用面で不利 → コスト最適化が求められる設問では不正解になりやすい。
  • ステートレスなアプリ層は AMI や Auto Scaling で簡単に復旧可能。
  • DR 戦略問題は「RPO/RTO」「コスト」のバランスを意識すること。

この問題は Aurora レプリカで RPO を満たし、EC2 スナップショットでコスト最適な RTO を実現する組み合わせが正解でした。

👉 次の問題も整理していきましょうか？

了解しました！いただいた問題を整理して指定フォーマットでまとめました。

問題文

ある会社には、グローバルなスケーラビリティとパフォーマンスのために Amazon CloudFront を活用した複雑なウェブアプリケーションを使用しています。時間の経過とともに、ユーザーはウェブアプリケーションの速度が低下していると報告しています。同社の運用チームは、CloudFront のキャッシュヒット率が着実に低下していると報告しています。キャッシュメトリクスのレポートによると、一部の URL のクエリ文字列の順序が一貫しておらず、大文字と小文字が混在した文字で指定されていることがあります。

キャッシュヒット率をできるだけ早く向上させるために、ソリューションアーキテクトが取るべきアクションを選択してください。

選択肢

A. Lambda@Edge 関数をデプロイして、パラメーターを名前で並べ替え、強制的に小文字にします。CloudFront ビューワーのリクエストトリガーを選択して、関数を呼び出します。
B. CloudFront ディストリビューションを更新して、クエリ文字列パラメーターに基づくキャッシュを無効にします。
C. CloudFront ディストリビューションを更新して、大文字と小文字を区別しないクエリ文字列処理を指定します。
D. ロードバランサーの後にリバースプロキシをデプロイし、アプリケーションで発行された URL を後処理し、URL 文字列を強制的に小文字にします。

問題文の要件の概要

  • 課題: CloudFront のキャッシュヒット率が低下し、アプリのパフォーマンスが悪化。
  • 原因:
    • クエリ文字列の順序が一定でない
    • 大文字・小文字の混在によるキャッシュ不一致
  • 要件: キャッシュキーを正規化して、ヒット率を改善する。

正解の選択肢と解説

  • A. Lambda@Edge 関数をデプロイして、パラメーターを名前で並べ替え、強制的に小文字にする。
    • Lambda@Edge を CloudFront ビューワーリクエスト時に実行させることで、**クエリ文字列を正規化（順序を固定・小文字化）**できる。
    • これによりキャッシュキーが統一され、キャッシュヒット率が大幅に向上。
    • 即効性があり、最小限の変更で対応可能。

不正解の選択肢の理由

  • B. クエリ文字列パラメーターに基づくキャッシュを無効にする
    • クエリを無視すると正しいレスポンスが返せなくなる可能性が高く、キャッシュヒット率の改善にはつながらない。
  • C. 大文字と小文字を区別しないクエリ文字列処理を指定
    • CloudFront にはそのようなオプションは存在せず、デフォルトでは区別されるため効果がない。
  • D. リバースプロキシで URL を小文字化
    • 後段にプロキシを追加すると遅延・運用コスト・障害ポイントが増える。根本解決にならず非効率。

SAP試験で押さえておくべきポイント

  • CloudFront キャッシュの効率化では「クエリ文字列」「ヘッダー」「Cookie」の扱いが重要。
  • Lambda@Edge はキャッシュキーの正規化やリクエスト書き換えに最適。
  • 「キャッシュヒット率低下 → クエリの順序/大文字小文字不一致 → Lambda@Edge で正規化」というパターンは試験で頻出。
  • クエリを無効化するのは安易すぎて要件を満たさない。必ず「正規化」を意識する。

👉 この問題は、CloudFront のキャッシュキー正規化を Lambda@Edge で行うのがベストプラクティスという理解がポイントでした。

次の問題（問題7）も整理しますか？

承知しました！いただいた 問題7 を指定フォーマットで整理しました。

問題文

ある会社が、Amazon API Gateway、Amazon DynamoDB、AWS Lambda を使用して、AWS 上でブログ投稿のアプリケーションをホストしています。このアプリケーションは現在、リクエストの認証に API キーを使用していません。

API モデルは次のとおりです。

GET/posts/[postid] : 投稿の詳細を取得します。
GET/users[userid] : でユーザーの詳細を取得します。
GET/comments/[commentid] : コメントの詳細を取得します。

同社は、ユーザーがコメント欄で活発に話題を議論していることに気づいており、コメントがリアルタイムで表示されるようにマークを付けることで、ユーザーのエンゲージメントを高めたいと考えています。

コメントの待ち時間を短縮し、ユーザーエクスペリエンスを向上させるには、どの設計を使用する必要がありますか？

選択肢

A. Amazon CloudFront でエッジ最適化 API を使用して、API レスポンスをキャッシュします。
B. AWS AppSyncを使用し、コメントの配信に WebSocket を活用します。
C. Lambda 関数の同時実行制限を変更して、APIのレスポンス時間を短縮します。
D. ブログアプリケーションのコードを変更して、10 秒ごとに GET/comments/[commentid] をリクエストします。

問題文の要件の概要

  • コメント機能をリアルタイムでユーザーに配信したい。
  • 単なるレスポンス改善ではなく 双方向・リアルタイム通信 が必要。
  • リアルタイム更新による待ち時間短縮とエンゲージメント向上 が目的。

正解の選択肢と解説

  • B. AWS AppSyncを使用し、コメントの配信に WebSocket を活用する
    • AppSync はフルマネージドな GraphQL API サービスで、リアルタイム更新（サブスクリプション）機能を持つ。
    • WebSocket を利用することで、サーバーからクライアントに新しいコメントを即座にプッシュ可能。
    • リアルタイム性が求められる「チャット」や「コメント」系ユースケースの代表的な解決策。

不正解の選択肢の理由

  • A. CloudFront で API レスポンスをキャッシュ
    • キャッシュにより応答は早くなるが、コメントは最新である必要があるため不適切。リアルタイム性を損なう。
  • C. Lambda の同時実行制限を変更
    • API レスポンスは多少早くなるかもしれないが、リアルタイム配信を実現する仕組みではない。
  • D. 10 秒ごとにポーリング
    • 疑似リアルタイムではあるが効率が悪く、リクエスト数の増加でシステムに負荷を与える。リアルタイム要件を満たさない。

SAP試験で押さえておくべきポイント

  • リアルタイム更新が要件なら AppSync（GraphQL サブスクリプション + WebSocket）が最適解。
  • CloudFront キャッシュは 静的コンテンツ配信の高速化には有効だが、動的データのリアルタイム配信には不向き。
  • ポーリングは暫定策だがコスト・効率・スケーラビリティの面で不適切。
  • Lambda のスケーリング調整は性能改善であり、リアルタイム通信の解決策ではない。

👉 この問題は、「リアルタイム通信 ＝ AppSync + WebSocket」 を確実に押さえることが重要です。

次は 問題8 も整理していきますか？

RELATED POST