以下に、問題1の内容を指定フォーマットで整理・解説します。
■ 問題文（編集せずそのまま）
アプリケーションは、Auto Scaling グループで実行される Amazon EC2 インスタンスにデプロイされます。Auto Scaling グループの構成では、1 種類のインスタンスのみを使用します。
CPU とメモリの使用率メトリクスは、インスタンスが十分に活用されていないことを示しています。ソリューションアーキテクトは、EC2 コストを永続的に削減し、使用率を高めるソリューションを実装する必要があります。
将来的に最も少ない構成変更でこれらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずそのまま）
A.
現在のインスタンスが持つプロパティと同様のプロパティを持つインスタンスタイプをリストします。リストから複数のインスタンスタイプを使用するように、Auto Scaling グループの起動テンプレート構成を変更します。
B.
アプリケーションの CPU とメモリの使用率に関する情報を使用して、要件に一致するインスタンスタイプを選択します。新しいインスタンスタイプを追加して、Auto Scaling グループの構成を変更します。現在のインスタンスタイプを構成から削除します。
C.
アプリケーションの CPU とメモリの使用率に関する情報を使用して、Auto Scaling グループの起動テンプレートの新しいリビジョンで CPU とメモリの要件を指定します。現在のインスタンスタイプを構成から削除します。
D.
AWS Price List Bulk API から適切なインスタンスタイプを選択するスクリプトを作成します。選択したインスタンスタイプを使用して、Auto Scaling グループの起動テンプレートの新しいリビジョンを作成します。
■ 問題文の要件の概要
- Auto Scaling グループで 1種類の EC2 インスタンスを使用中
- CPU・メモリ使用率が低すぎる（オーバースペック）
- コスト削減かつ使用率を上げたい
- 将来的な構成変更が少ない方法が望ましい
■ 正解の選択肢と解説
✅ B. インスタンスのライトサイジングと構成変更
理由：
- 使用率が低いということは、現在のインスタンスがスペック過剰（＝コスト無駄）。
- 実データ（CPU/メモリ使用率）に基づき、より小さいインスタンスタイプに変更することで、コスト削減とリソース最適化が可能。
- 現在のインスタンスタイプを削除し、1つの新しいインスタンスタイプに絞ることで、構成の複雑性も抑えられる。
- 今後スペック見直しが必要な場合も、同様にテンプレートを1つ更新するだけで済む。
■ 不正解の選択肢の理由
❌ A. 複数のインスタンスタイプに分散
- 同等性能のインスタンスを複数用意することで、選択肢は広がるが…
- 将来的な構成変更が複雑化しやすく、管理コストが上がる
- この問題では「シンプルかつ継続的に最適化可能な構成」が求められているため不適
❌ C. 起動テンプレートに CPU・メモリ要件を記述
- 起動テンプレートに CPU やメモリの**「使用率」を直接設定する機能はない**
- インスタンスタイプを指定する必要があり、要件値を指定しても実際の選定にはならない
❌ D. Price List API で選定
- コスト最小のインスタンスを探す手段としてスクリプトは有効だが…
- 価格だけを基準にしても、パフォーマンス要件を満たすとは限らない
- 実使用メトリクスに基づいたライトサイジングが本質的解決
■ SAP試験で押さえておくべきポイント
- **インスタンス最適化（ライトサイジング）**は、コスト削減と効率化の基本戦略
- Auto Scaling の起動テンプレート変更により1インスタンス型構成で最適化できる
- 構成変更の複雑化（マルチインスタンスタイプ化）＝将来の保守コスト増加
- 使用率が低い→インスタンスを小さくするという発想が基本（上下両対応）
この問題の意図は「柔軟さではなく、適切な選定とシンプルな最適化」にあります。迷った場合は「Auto Scaling構成をシンプルに保ちつつ費用最適化」を優先する思考が重要です。
以下に、問題2を整理して解説します。
■問題文
ある企業は、多数の IoT デバイスから大量のデータを収集しています。データは永続的な Amazon EMR クラスターの HDFS に ORC 形式で保存されています。
データ分析チームは同じ EMR クラスター上の Apache Presto で SQL クエリを実行しており、クエリは17〜22時に限定され、常に15分以内で完了します。企業は 現在のソリューションのコスト を懸念しており、SQLクエリを可能にする最もコスト効率の高いソリューション を提案する必要があります。
■選択肢（文字列編集なし）
A.
Amazon S3 にデータを保存します。Amazon Redshift Spectrum を使用してデータをクエリします。
B.
Amazon S3 にデータを保存します。AWS Glue Data Catalog と Amazon Athena を使用してデータをクエリします。
C.
EMR ファイルシステム (EMRFS) にデータを保存します。Amazon EMR の Presto を使用してデータをクエリします。
D.
Amazon Redshift にデータを保存します。Amazon Redshift を使用してデータをクエリします。
■問題文の要件の概要
- クエリ時間は限られている（17〜22時）
- 現在は常時起動の EMR クラスター（コスト高）
- ORC 形式で保存されたデータを SQL でクエリしたい
- 目的：コスト最適化（継続的な）
■正解の選択肢と解説
正解：B. Amazon S3 + Glue Data Catalog + Athena
理由：
- S3：低コストの永続ストレージ。HDFSよりもコスト効率が高い。
- ORC：Athena との相性がよく、スキャンコストが抑えられる。
- Glue Data Catalog：S3上のデータのメタデータ管理を提供。
- Athena：完全サーバーレスのクエリエンジン。クエリ実行時のみ課金され、EMRのように常時課金されない。
👉 午後5時〜10時の短時間使用パターンでは、Athena が最も費用対効果が高い。
■不正解の選択肢の理由
A. Redshift Spectrum
- Redshift クラスターの常時稼働が必要 → 固定費が発生。
- Spectrum のスキャン課金 + クラスタ料金の 二重コスト。
C. EMR + Presto
- EMR クラスターは 常時インスタンス維持 が必要 → 17時〜22時以外でもコストが発生。
- 運用管理も必要 → Athena より複雑・高コスト。
D. Redshift
- Redshift はデータをロード（ETL/COPY）する必要がある。
- 分析時間が限定されているのに 24時間稼働するクラスターコスト が高い。
■SAP試験で押さえておくべきポイント
| ポイント | 内容 |
|---|---|
| Athenaの特性 | サーバーレス・従量課金・S3と連携・SQLクエリ対応 |
| Glue Data Catalog | S3上のデータのメタデータ定義を管理し、AthenaやRedshift Spectrumなどで共有可能 |
| S3 + ORC | 高圧縮・列指向フォーマットでスキャン効率が高い |
| Redshift Spectrumとの違い | Redshiftはクラスタ常時起動が必要、Athenaは不要 |
| EMRのコスト特性 | 自動停止しない限り、マスター/コアノード維持費が継続的に発生 |
ご不明点や他の選択肢に関する追加の質問があれば、いつでもどうぞ！
以下に、問題3の解説を整理して提示します。
■ 問題文
ある企業は AWS クラウドで処理エンジンを実行しています。このエンジンは物流センターからの環境データを処理し、持続可能性指標を算出します。
同社は、ヨーロッパ全土に広がる物流センターに数百万台のデバイスを設置しています。デバイスは、RESTful API を通じて処理エンジンに情報を送信します。
API で 予測できないトラフィックのバースト が発生しました。
同社は、デバイスが処理エンジンに送信するすべてのデータを処理するソリューションを実装する必要があります。データの損失は容認できません。
■ 選択肢（文字列そのまま）
A.
RESTful API 用の Application Load Balancer (ALB) を作成します。Amazon Simple Queue Service (Amazon SQS) キューを作成します。ALB のリスナーとターゲットグループを作成します。SQS キューをターゲットとして追加します。Amazon Elastic Container Service (Amazon ECS) で Fargate 起動タイプで動作するコンテナを使用して、キュー内のメッセージを処理します。
B.
RESTful API を実装する Amazon API Gateway HTTP API を作成します。Amazon Simple Queue Service (Amazon SQS) キューを作成します。SQS キューとの API Gateway サービス統合を作成します。SQS キュー内のメッセージを処理する AWS Lambda 関数を作成します。
C.
RESTful API を実装する Amazon API Gateway REST API を作成します。Auto Scaling グループに Amazon EC2 インスタンスのフリートを作成します。API Gateway Auto Scaling グループのプロキシ統合を作成します。EC2 インスタンスを使用して、受信データを処理します。
D.
RESTful API 用の Amazon CloudFront ディストリビューションを作成します。Amazon Kinesis Data Streams でデータストリームを作成します。データストリームを配布元として設定します。データストリームのデータを消費して処理する AWS Lambda 関数を作成します。
■ 問題文の要件の概要
- 数百万の IoT デバイス → 大量のリクエストが到来
- RESTful API を使用してデータ送信
- バースト（突発的）トラフィックあり
- データ損失は許されない
- 高い耐久性・スケーラビリティが必要
■ 正解の選択肢と解説
正解：B
「API Gateway + SQS + Lambda」構成
- API Gateway HTTP API：RESTful エンドポイントを提供、スケーラブルでバースト耐性あり
- Amazon SQS：耐久性のあるメッセージキュー。バーストトラフィックでも受信データを一時保存・バッファリング可能
- AWS Lambda：キューのデータを非同期に自動処理、スケールも柔軟
この構成により、API の急増にも対応可能で、データ損失なく確実に処理できます。
また、すべてのコンポーネントがサーバーレスなので、コスト効率も高いです。
■ 不正解の選択肢の理由
A. ALB + SQS + Fargate
→ ALB は SQS をターゲットにできないため構成不可能。Fargate は起動に時間がかかるためバースト時に取りこぼしの可能性がある。
C. API Gateway + EC2 Auto Scaling
→ EC2 のスケールイン・アウトには数分かかるため、急なバーストには非対応。キューもなく、データ損失のリスクがある。
D. CloudFront + Kinesis
→ CloudFront は API 処理用途ではなく静的コンテンツ配信用。CloudFront から Kinesis に直接送信する構成も技術的に不可能。
■ SAP試験で押さえておくべきポイント
- バーストトラフィック対応には「API Gateway + SQS + Lambda」が最適な構成
- ALB ≠ メッセージ受信装置 → レイヤーの役割に注意
- EC2 はスケーリング遅延あり → バーストに不向き
- CloudFront は API 処理には不適
- SQSはデータ損失防止・バッファリングに有効な中継手段
必要であればこの構成のアーキテクチャ図も作成できます。お気軽にどうぞ。
以下に、問題4の要点を整理してお届けします。
■ 問題文（編集せず）
ある企業は、会社の AWS ワークロードの健全性を監視するために、単一の Amazon EC2 インスタンス上で実行される Grafana データ視覚化ソリューションを使用しています。同社は、保存したいダッシュボードを作成するために時間と労力を費やしてきました。ダッシュボードは可用性が高い必要があり、10 分を超えて停止することはできません。継続的なメンテナンスを最小限に抑える必要があります。
運用上のオーバーヘッドを最小限に抑えてこれらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せず）
A.
Amazon CloudWatch ダッシュボードに移行します。既存の Grafana ダッシュボードと一致するようにダッシュボードを再作成します。可能な限り自動ダッシュボードを使用します。
B.
Amazon Managed Grafana ワークスペースを作成します。新しい Amazon CloudWatch データソースを構成します。既存の Grafana インスタンスからダッシュボードをエクスポートします。ダッシュボードを新しいワークスペースにインポートします。
C.
Grafana がプリインストールされた AMI を作成します。既存のダッシュボードを Amazon Elastic File System (Amazon EFS) に保存します。新しい AMI を使用する Auto Scaling グループを作成します。Auto Scaling グループのインスタンスの最小数、希望する数、および最大数を 1 に設定します。少なくとも 2 つのアベイラビリティーゾーンにサービスを提供する Application Load Balancer を作成します。
D.
Grafana を実行する EC2 インスタンスを 1 時間ごとにバックアップするように AWS Backup を設定します。必要に応じて、代替アベイラビリティーゾーンの最新のスナップショットから EC2 インスタンスを復元します。
■ 問題文の要件の概要
- 作成済みの Grafana ダッシュボードを活用したい（再作成は避けたい）
- 可用性は高く、10分以上の停止不可
- 継続的なメンテナンス負荷を最小限に
■ 正解の選択肢と解説
正解：B. Amazon Managed Grafana を使う構成
- Amazon Managed Grafana は、Grafana の運用を AWS が管理するマネージドサービスで、高可用性 と 自動スケーリング を提供。
- 既存の EC2 上の Grafana ダッシュボードはエクスポート・インポートが可能なため、構築済みの資産を活かせる。
- CloudWatch や他の AWS データソースと簡単に統合可能で、追加のインフラ管理不要。
■ 不正解の選択肢の理由
A. CloudWatch ダッシュボードに移行：
- Grafana 特有の高度な視覚化機能が失われる
- ダッシュボードを再構築する必要があり、時間とコストがかかる
C. AMI + EFS + Auto Scaling 構成：
- 可用性は確保できるが、EC2/EFSのメンテナンスが必要
- マネージドサービスと比較して運用負荷が高い
D. AWS Backup + スナップショット復元：
- スナップショット復元に時間がかかり、10分以内の復旧は困難
- 可用性担保よりもバックアップ戦略に近く、要件に合致しない
■ SAP試験で押さえておくべきポイント
- Amazon Managed Grafana は、運用負荷最小化・可用性重視の要件に対して有効な選択肢
- マネージドサービスを選ぶべきか、EC2/Auto Scalingで構築すべきかは、**「RTO（復旧時間）」や「メンテナンス負荷」**の観点で判断
- バックアップと高可用性の違いを理解しておく（復旧 vs 継続的提供）
必要であれば、図解によるイメージ化や再出題形式での確認もお手伝いできます！
以下に、問題5の内容をSAP試験対策として整理・要約します。
■ 問題文（編集せず）
ある金融サービス会社が、数百万件の過去の株式取引を Amazon DynamoDB のテーブルにロードしました。このテーブルではオンデマンドキャパシティモードを使用しています。毎日午前 0 時に、数百万の新しいレコードがテーブルにロードされます。このテーブルに対するアプリケーションの読み取りアクティビティは、1 日を通じてバースト的に発生し、限られたキーのセットが繰り返し検索されます。同社は、DynamoDB に関連するコストを削減する必要があります。
この要件を満たすための最適な方法を選択してください。
■ 選択肢（編集せず）
A.
DynamoDB テーブルの前に Amazon ElastiCache クラスターをデプロイします。
B.
DynamoDB Accelerator (DAX) をデプロイします。DynamoDB Auto Scaling を設定します。Cost Explorer で Savings Plans を購入します。
C.
プロビジョニングされたキャパシティモードを使用します。Cost Explorer で Savings Plans を購入します。
D.
DynamoDB Accelerator (DAX) をデプロイします。プロビジョニングされたキャパシティモードを使用します。DynamoDB Auto Scaling を設定します。
■ 問題文の要件の概要
- オンデマンド課金からのコスト削減が目的
- 毎日定時（0時）に大量書き込みあり
- 日中は読み取りバーストがあり、しかも特定のキーに偏り
- 頻出読み込みパターン → キャッシュ最適
- 使用サービス：Amazon DynamoDB
■ 正解の選択肢と解説
正解：D
✅ 解説：
- DAX（DynamoDB Accelerator）
- DynamoDB 専用のインメモリキャッシュ
- 同じキーの読み取りが頻繁にある → キャッシュヒットが高く、RCUの削減でコスト最適
- プロビジョニングモード + Auto Scaling
- 書き込み量とトラフィックパターンがある程度予測可能
- オンデマンドよりもコストが大幅に抑えられる
- Auto Scaling により無駄な過剰プロビジョンを避けられる
■ 不正解の選択肢の理由
A. ElastiCache クラスター導入
- ElastiCache は DynamoDB と統合されていない
- アプリケーション側で TTL・キャッシュ整合性管理が必要 → 実装が複雑
- DAX という専用キャッシュがあるので不要
B. DAX + Auto Scaling + Savings Plans 購入
- Savings Plans は EC2・Lambda・Fargate用
- DynamoDB には適用不可 → コスト削減に繋がらない
- オンデマンドモードのままではピーク対応に高コスト
C. プロビジョニングモード + Savings Plans
- Savings Plans は DynamoDB に関係なし
- キャッシュもスケーリングもなし → ピークに合わせた過剰プロビジョニングが必要
- コスト効率が悪くなる可能性大
■ SAP試験で押さえておくべきポイント
| ポイント | 内容 |
|---|---|
| 🔹 DAXの活用場面 | 頻繁に読み取られるキーがある場合（特にRPSが高いとき）に、RCU削減と高速応答の両立ができる |
| 🔹 プロビジョニング + Auto Scaling | トラフィックパターンが予測可能な場合にコスト効率が最も高い。オンデマンドより安い |
| 🔹 Savings Plansの適用範囲に注意 | DynamoDBには適用されない。EC2・Lambda・Fargateなどのみ対象 |
| 🔹 ElastiCacheとDAXの違い | DAXはDynamoDB専用でシームレス連携。ElastiCacheは汎用キャッシュで自前実装が必要 |
必要であれば、「DAXとElastiCacheの比較表」や「プロビジョニング vs オンデマンドのコスト例」も提供できます！
以下に、問題6の要点を整理して出力します。
■ 問題文（編集せず）
ある企業が、Amazon RDS for Oracle データベースを、別の AWS アカウントにある RDS for PostgreSQL DB インスタンスに移行することを計画しています。ソリューションアーキテクトは、ダウンタイムが必要なく、移行を完了するのに必要な時間を最小限に抑える移行戦略を設計する必要があります。移行戦略は、すべての既存データと移行中に作成されるすべての新規データを複製する必要があります。移行先 (ターゲット) データベースは、移行プロセス完了時に移行元データベースと同一である必要があります。
すべてのアプリケーションは現在、RDS for Oracle DB インスタンスとの通信のエンドポイントとして Amazon Route 53 CNAME レコードを使用しています。RDS for Oracle DB インスタンスはプライベートサブネットにあります。
これらの要件を満たす最適な手順の組み合わせを選択してください。(3 つ選択)
■ 選択肢（編集せず）
A.
ターゲットアカウントに新しい RDS for PostgreSQL DB インスタンスを作成します。AWS Schema Conversion Tool (AWS SCT) を使用して、データベーススキーマをソースデータベースからターゲットデータベースに移行します。
B.
AWS Schema Conversion Tool (AWS SCT) を使用して、ソースデータベースのスキーマと初期データを使用して、ターゲットアカウントに新しい RDS for PostgreSQL DB インスタンスを作成します。
C.
ターゲットアカウントから両方の DB インスタンスへの接続を提供するために、2 つの AWS アカウントの VPC 間で VPC ピアリングを構成します。各 DB インスタンスにアタッチされているセキュリティグループを設定し、ターゲットアカウントの VPC からデータベースポートのトラフィックを許可します。
D.
ターゲットアカウントの VPC からの接続を提供するために、ソース DB インスタンスがパブリックにアクセスできるように一時的に許可します。各 DB インスタンスにアタッチされているセキュリティグループを設定し、ターゲットアカウントの VPC からのデータベースポートのトラフィックを許可します。
E.
ターゲットアカウントで AWS Database Migration Service (AWS DMS) を使用して、ソースデータベースからターゲットデータベースへの全ロードと変更データキャプチャ (CDC) 移行を実行します。移行が完了したら、ターゲット DB インスタンスのエンドポイントを指すように CNAME レコードを変更します。
F.
ターゲットアカウントで AWS Database Migration Service (AWS DMS) を使用して、ソースデータベースからターゲットデータベースへの変更データキャプチャ (CDC) 移行を実行します。移行が完了したら、ターゲット DB インスタンスのエンドポイントを指すように CNAME レコードを変更します。
■ 問題文の要件の概要
- RDS for Oracle → RDS for PostgreSQL への移行（異種DB間移行）
- AWSアカウント間の移行
- ダウンタイムなし／最小限
- 全データ＋移行中の変更データの複製が必要
- プライベート接続が前提（RDSはプライベートサブネット）
- 最終的にCNAMEでエンドポイント切り替え
■ 正解の選択肢と解説
✅ A. SCT を使用してスキーマ変換
- Oracle と PostgreSQL は異なるエンジンのため、スキーマ互換性の変換が必須
- AWS Schema Conversion Tool (SCT) を用いて、スキーマやストアドプロシージャ等を PostgreSQL 対応に変換可能
✅ C. VPC ピアリングとセキュリティグループ設定
- ソースDBはプライベートサブネット
- AWSアカウント間で安全にDB通信するには、VPCピアリングを使ってプライベートな接続経路を確保する必要あり
✅ E. DMS による全ロード＋CDC、CNAME切り替え
- DMS を使うことで、
- 全ロード（初期データ）
- CDC（更新データのリアルタイム同期）
- 最後に Route 53 の CNAME 切り替えにより、ダウンタイムなしで移行が完了
■ 不正解の選択肢の理由
B.
- SCT はスキーマ変換用だが、全データ移行までを担えない
- 特に移行中の 変更データ は DMS が必要
D.
- RDS を 一時的にパブリックアクセス可能にするのはセキュリティ的にNG
- 構成変更リスクが大きく、推奨されない
F.
- DMS の CDC（変更データキャプチャ）だけでは初期データが移行されない
- 必ず「全ロード＋CDC」の組み合わせが必要
■ SAP試験で押さえておくべきポイント
| 分類 | 内容 |
|---|---|
| 🔁 データベース移行戦略 | スキーマ変換は SCT、データ移行は DMS（全ロード＋CDC） |
| 🔒 安全な接続手段 | 複数アカウント間の通信は VPC ピアリング／セキュリティグループ設定で対応 |
| ⛔ よくある誤答 | DMS で CDC のみを使うパターンは、初期データが抜けるため不完全 |
| ⚠ RDSパブリックアクセス | セキュリティリスク大。出題者のひっかけに注意 |
この問題は「異種DB間移行 × クロスアカウント × 無停止」がキーワードです。手順の順序を図にするとさらに理解しやすくなります。必要があれば図解も作成します。
以下に、問題7の内容をSAP試験対策として整理します。
■ 問題文（編集せず）
企業のインタラクティブなウェブアプリケーションは、Amazon CloudFront ディストリビューションを使用して、Amazon S3 バケットから画像を提供します。時折、サードパーティーのツールが破損した画像を S3 バケットに取り込むことがあります。この画像の破損により、アプリケーションのユーザーエクスペリエンスが低下します。同社は、破損した画像を検出する Python ロジックの実装とテストに成功しました。
ソリューションアーキテクトは、取り込みと配信の間の待ち時間を最小限に抑えながら、検出ロジックを統合するソリューションを推奨する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せず）
A. ビューワー応答イベントによって呼び出される Lambda@Edge 関数を使用します。
B. オリジン応答イベントによって呼び出される Lambda@Edge 関数を使用します。
C. AWS Lambda 関数を呼び出す S3 イベント通知を使用します。
D. AWS Step Functions ステートマシンを呼び出す S3 イベント通知を使用します。
■ 問題文の要件の概要
- S3バケットにアップロードされた画像が破損している可能性あり
- Pythonで破損チェックのロジックは実装済
- 配信前（ユーザーへの表示前）に破損を検出したい
- 待ち時間最小化が重要
■ 正解の選択肢と解説
✅ 正解：C. AWS Lambda 関数を呼び出す S3 イベント通知を使用します。
解説：
- S3イベント通知により、画像がアップロードされた瞬間に Lambda を起動可能。
- Lambda関数で破損チェックを即座に実行できるため、CloudFront による配信前に排除可能。
- Lambda@EdgeやStep Functionsよりもリアルタイム処理に向いており、待ち時間を最小限に抑えられる。
■ 不正解の選択肢の理由
A. ビューワー応答イベント × Lambda@Edge
- CloudFront がキャッシュからビューワーへレスポンスを返す直前に発火。
- この段階では既に画像がユーザーに届く直前で、破損チェックとしては遅い。
B. オリジン応答イベント × Lambda@Edge
- CloudFront が S3 からレスポンスを受け取った後のタイミング。
- キャッシュヒット時には発火しない → 全てのリクエストをカバーできない。
- チェック漏れの可能性があり、信頼性に欠ける。
D. Step Functions 呼び出し via S3 イベント通知
- ワークフロー処理が可能だが、起動〜処理完了まで時間がかかる。
- 今回の要件（即時チェック）にはオーバースペックで、待ち時間を最小化できない。
■ SAP試験で押さえておくべきポイント
| 観点 | 内容 |
|---|---|
| ✅ 破損画像の即時検出 | S3イベントで Lambda を直接呼び出すのが最速・最小構成 |
| ✅ Lambda@Edge のタイミングに注意 | ビューワー応答・オリジン応答は配信直前で、事前フィルタリングには不向き |
| ✅ Step Functions の用途 | マルチステップワークフロー向け。リアルタイム用途では基本的に不適 |
| ✅ CloudFront + S3 の組み合わせ | S3のアップロード検知はCloudFrontより前に処理を挟むなら Lambda + S3 イベント通知が最適 |
図解付きのフローや、Lambda@Edge と Lambda@S3 イベント通知の比較表なども必要あれば提供可能です！
