以下に、いただいたHTML問題を基に「AWS Certified Solutions Architect – Professional」形式で整理・解説いたします。
■問題文
データサイエンティストのチームは、Amazon SageMaker インスタンスと SageMaker API を使用して、機械学習 (ML) モデルをトレーニングしています。SageMaker インスタンスは、インターネットにアクセスできない、またはインターネットからアクセスできない VPC にデプロイされています。ML モデルのトレーニング用のデータセットは、Amazon S3 バケットに保存されます。インターフェース VPC エンドポイントは、Amazon S3 と SageMaker API へのアクセスを提供します。
時折、データサイエンティストは、ワークフローの一部として使用する Python パッケージを更新するために、Python Package Index (PyPI) リポジトリへのアクセスを必要とします。ソリューションアーキテクトは、SageMaker インスタンスがインターネットから分離されたままであることを保証しながら、PyPI リポジトリへのアクセスを提供する必要があります。
これらの要件を満たすソリューションを選択してください。
■選択肢
A. データサイエンティストがアクセスする必要があるパッケージごとに AWS CodeCommit リポジトリを作成します。PyPI リポジトリと CodeCommit リポジトリ間のコード同期を構成します。CodeCommit 用の VPC エンドポイントを作成します。
B. VPC に NAT ゲートウェイを作成します。PyPI リポジトリエンドポイントのみへのアクセスを許可するネットワーク ACL を使用して、インターネットへのアクセスを許可するように VPC ルートを構成します。
C. VPC に NAT インスタンスを作成し、インターネットへのアクセスを許可するように VPC ルートを設定します。PyPI リポジトリエンドポイントのみへのアクセスを許可する SageMaker ノートブックインスタンスのファイアウォールルールを設定します。
D. AWS CodeArtifact ドメインとリポジトリを作成します。public:pypi の外部接続を CodeArtifact リポジトリに追加します。CodeArtifact リポジトリを使用するように Python クライアントを設定します。CodeArtifact 用の VPC エンドポイントを作成します。
■問題文の要件の概要
- SageMaker インスタンスはインターネットから完全に分離された VPC に存在
- S3 および SageMaker API には VPC エンドポイント経由でアクセス
- PyPI パッケージを使う必要がある
- インターネットに接続させずに PyPI にアクセスする方法を探す
■正解の選択肢と解説
正解：D
AWS CodeArtifact ドメインとリポジトリを作成し、public:pypi の外部接続を追加し、VPCエンドポイント経由でアクセス
- AWS CodeArtifact は、インターネットからの直接通信を不要にしつつ、PyPI や npm などのパッケージを内部で管理・共有できるマネージドサービス。
- public:pypi を「外部接続（external connection）」として設定し、CodeArtifact にパッケージをキャッシュ・代理取得できる。
- VPCエンドポイント（Interface）を作成すれば、VPC 内から CodeArtifact にアクセスでき、インターネットからは遮断されたままになる。
■不正解の選択肢の理由
A：CodeCommitを利用する案
- CodeCommit は Git リポジトリであり、PyPI パッケージ管理の用途には不適。
- PyPI と CodeCommit の同期処理も非現実的かつ運用が困難。
- PyPI へのアクセスはインターネットが前提のため、結局分離要件に反する。
B：NAT ゲートウェイ案
- NAT ゲートウェイを介すると、インスタンスが間接的にインターネットにアクセスできてしまう。
- ネットワークACLで制限しても、「インターネットから分離された状態」 という要件に反する。
C：NAT インスタンス案
- Bと同様、インターネット経由でPyPIにアクセスする仕組みのためNG。
- ファイアウォールやルーティングで制限しても、分離要件の緩和とは見なされない。
■SAP試験で押さえておくべきポイント
| ポイント | 内容 |
|---|---|
| インターネット分離要件 | NAT ゲートウェイ／インスタンス使用は原則NG。VPCエンドポイント経由や専用サービス活用が推奨。 |
| CodeArtifact | PyPI や npm などのパッケージを内部から安全に取得する手段として登場頻度高。public repositoryとの外部接続、VPCエンドポイント利用がキモ。 |
| VPCエンドポイント | Interfaceエンドポイントはサービスへの安全なプライベートアクセスを提供。S3などGateway型も併用可。 |
| SageMaker in isolated VPC | よくあるシナリオ。モデルトレーニングや推論に必要なデータ・コードへの安全なアクセス経路設計が問われる。 |
追加の問題があれば、引き続き解析いたします。
以下に、問題2の内容をAWS SAP試験向けに整理・解説いたします。
■問題文
ある企業はインフラストラクチャを AWS クラウドに移行しています。様々なプロジェクトで様々な規制基準に準拠する必要があります。同社はマルチアカウント環境を必要としています。
ソリューションアーキテクトは、ベースラインインフラストラクチャを準備する必要があります。このソリューションは、管理とセキュリティの一貫したベースラインを提供する必要がありますが、様々な AWS アカウント内で異なるコンプライアンス要件に柔軟に対応できる必要があります。ソリューションはまた、既存のオンプレミスの Active Directory フェデレーションサービス (AD FS) サーバーと統合する必要もあります。
運用上のオーバーヘッドを最小限に抑えながら、これらの要件を満たすソリューションを選択してください。
■選択肢
A.
AWS Organizations で組織を作成します。すべてのアカウントにわたって最小権限アクセスのための単一の SCP を作成します。すべてのアカウントに対して単一の OU を作成します。オンプレミスの AD FS サーバーとのフェデレーション用に IAM ID プロバイダーを構成します。ログ生成サービスがログイベントを中央アカウントに送信するように、定義されたプロセスで中央ログアカウントを構成します。すべてのアカウントのコンフォーマンスパックを使用して、中央アカウントで AWS Config を有効にします。
B.
AWS Organizations で組織を作成します。その組織で AWS Control Tower を有効にします。SCP に含まれるコントロール (ガードレール) を確認します。AWS Config で追加が必要な領域を確認します。必要に応じて OU を追加します。AWS IAM Identity Center (AWS Single Sign-On) をオンプレミスの AD FS サーバーに接続します。
C.
AWS Organizations で組織を作成します。最小権限アクセス用の SCP を作成します。OU 構造を作成し、それを使用して AWS アカウントをグループ化します。AWS IAM Identity Center (AWS Single Sign-On) をオンプレミスの AD FS サーバーに接続します。ログ生成サービスがログイベントを中央アカウントに送信するように、定義されたプロセスで中央ログアカウントを構成します。アグリゲータとコンフォーマンスパックを使用して、中央アカウントで AWS Config を有効にします。
D.
AWS Organizations で組織を作成します。その組織で AWS Control Tower を有効にします。SCP に含まれるコントロール (ガードレール) を確認します。AWS Config で追加が必要な領域を確認します。オンプレミスの AD FS サーバーとのフェデレーション用に IAM ID プロバイダーを構成します。
■問題文の要件の概要
- マルチアカウント管理
- セキュリティと管理の一貫性を維持
- アカウントごとの異なるコンプライアンス要件に柔軟対応
- オンプレミスの AD FS との連携
- 運用負荷を最小限に
■正解の選択肢と解説
正解：B
AWS Control Tower + IAM Identity Center (旧 SSO) を用いた構成が最も適切
- AWS Control Tower は、マルチアカウント構成を前提に、ベストプラクティスに基づいたランディングゾーン（OU、ガードレール、ログ記録など）を提供するサービス。
- 各アカウントに対して OUごとの管理とガードレール（SCP） の適用が可能。
- IAM Identity Center は、オンプレAD（AD FS）との連携ができ、SAMLベースのSSOを実現。
- これにより、統一的なユーザー管理・セキュリティポリシー適用・運用簡素化 を同時に実現可能。
■不正解の選択肢の理由
A：単一OU・SCP構成＋IAMプロバイダー
- OUやSCPが固定的すぎて柔軟性に欠ける。
- IAM IDプロバイダーではフェデレーションは可能だが、IAM Identity Centerと比べてSSOや管理機能が限定的。
- 運用負荷も高く、管理対象が分散しがち。
C：OU構造＋IAM Identity CenterだがControl Towerなし
- 手動構築に近く、OU作成やConfig設定、ログ連携を都度対応する必要があり非効率。
- Control Towerを使えば自動的にこのあたりの基盤を整備できるため、あえて選ぶメリットが少ない。
D：Control Towerあり、しかしIAM Identity Centerを使わずIAM IDプロバイダーを使う
- AD FS連携が非効率で、シングルサインオンやロール管理が手動かつ煩雑。
- IAM Identity Centerを使わない点で連携性と保守性に欠ける。
■SAP試験で押さえておくべきポイント
| ポイント | 説明 |
|---|---|
| AWS Control Tower | マルチアカウント管理・セキュリティベースラインの自動構築。Landing ZoneとOU管理が重要。 |
| IAM Identity Center (旧 AWS SSO) | 統一されたユーザー・ロール管理とフェデレーション。オンプレAD連携にも対応。 |
| SCP（Service Control Policy） | OUやアカウント単位でアクセス制限。Guardrail（統制）として活用される。 |
| 運用負荷の最小化 | 自動化、共通ポリシー、ログの集約などがキーワード。手動構築よりControl Towerなどの利用が望ましい。 |
| Config + Conformance Pack | 各アカウントの準拠状況を監視・自動評価するために重要。 |
引き続き問題を投稿いただければ、同様に整理・解説いたします。
以下に、問題3の内容をSAP試験対策用に整理・解説いたします。
■問題文
企業は、ウェブアプリケーションのディザスタリカバリ (DR) 計画を実装する必要があります。アプリケーションは単一の AWS リージョンで実行されます。
アプリケーションは、コンテナで実行されるマイクロサービスを使用しています。コンテナは、Amazon Elastic Container Service (Amazon ECS) の AWS Fargate 上でホストされています。このアプリケーションは、データレイヤーとして Amazon RDS for MySQL DB インスタンスがあり、DNS 解決に Amazon Route 53 を使用します。アプリケーションに障害が発生した場合、Amazon CloudWatch アラームは Amazon EventBridge ルールを呼び出します。
ソリューションアーキテクトは、アプリケーションのリカバリを別のリージョンに提供する DR ソリューションを設計する必要があります。ソリューションは、障害からの復旧に必要な時間を最小限にする必要があります。
■選択肢
A.
別のリージョンの Fargate に 2 番目の ECS クラスターと ECS サービスを設定します。次のアクションを実行する AWS Lambda 関数を作成します。RDS DB インスタンスのスナップショットを取得し、スナップショットを別のリージョンにコピーし、スナップショットから新しい RDS DB インスタンスを作成し、トラフィックを 2 番目の ECS クラスターにルーティングするように Route 53 を更新します。EventBridge ルールを更新して、Lambda 関数を呼び出すターゲットを追加します。
B.
別のリージョンに 2 番目の ECS クラスターと ECS サービスを作成する AWS Lambda 関数を作成します。次のアクションを実行するように Lambda 関数を構成します。RDS DB インスタンスのスナップショットを取得し、スナップショットを別のリージョンにコピーし、スナップショットから新しい RDS DB インスタンスを作成し、トラフィックを 2 番目の ECS クラスターにルーティングするように Route 53 を更新します。EventBridge ルールを更新して、Lambda 関数を呼び出すターゲットを追加します。
C.
別のリージョンの Fargate に 2 番目の ECS クラスターと ECS サービスを設定します。別のリージョンに RDS DB インスタンスのクロスリージョンリードレプリカを作成します。リードレプリカをプライマリデータベースに昇格する AWS Lambda 関数を作成します。Route 53 を更新してトラフィックを 2 番目の ECS クラスターにルーティングするように Lambda 関数を設定します。EventBridge ルールを更新して、Lambda 関数を呼び出すターゲットを追加します。
D.
別のリージョンの Fargate に 2 番目の ECS クラスターと ECS サービスを設定します。RDS DB インスタンスのスナップショットを取得します。スナップショットを Amazon DynamoDB グローバルテーブルに変換します。Route 53 を更新してトラフィックを 2 番目の ECS クラスターにルーティングするように AWS Lambda 関数を設定します。EventBridge ルールを更新して、Lambda 関数を呼び出すターゲットを追加します。
■問題文の要件の概要
- DR（ディザスタリカバリ）対応
- RTO（復旧時間目標）最小化が必須
- Fargate/ECS + RDS for MySQL + Route 53 を使用中
- 障害発生時に迅速に別リージョンで復旧したい
■正解の選択肢と解説
正解：C
クロスリージョンリードレプリカ + ECS構成済み + Route 53 + Lambda による切り替え は、最も迅速な復旧（低RTO）を実現可能。
- クロスリージョンリードレプリカは、ほぼリアルタイムのデータ同期が可能で、障害発生時に即座にプライマリに昇格できる。
- ECSサービスを事前に準備しておくことで、障害発生時のプロビジョニング待機時間を排除。
- Lambda + EventBridge を組み合わせることで自動フェイルオーバーが実現。
- Route 53を更新してDNSベースでトラフィックを新リージョンへ。
■不正解の選択肢の理由
A / B：スナップショットベースの復旧
- スナップショットのコピー＆復元は数十分〜数時間かかる。
- RTOを「最小化」したいという要件に不適。
- 特に、障害発生「後」にインスタンス作成を開始する点で遅延が大きい。
D：DynamoDBへの変換
- RDS（リレーショナル）→ DynamoDB（NoSQL）へ変換は非現実的。
- 構造・クエリモデル・用途が異なるため、そもそも技術的に無理がある。
■SAP試験で押さえておくべきポイント
| ポイント | 説明 |
|---|---|
| RDSクロスリージョンリードレプリカ | 高速フェイルオーバーを可能にするRDSの災害対策構成。昇格は手動 or 自動可。 |
| スナップショット復旧 | コストは抑えられるが、RTOが長くDRには不向き。Coldスタンバイ用途。 |
| Route 53 | マルチリージョン構成でのトラフィック切替に重要（フェイルオーバールーティング可） |
| EventBridge + Lambda | イベントドリブンで自動切替・復旧処理が可能。DR設計では定番パターン。 |
| Fargate / ECS | リージョン間での事前構築・並行実行に対応。DR対応の柔軟性が高い。 |
引き続き、問題の提供があれば同様に整理いたします。必要であれば、この問題のRTO/RPO観点での比較表などもご提供可能です。
以下に、問題4の内容を AWS Certified Solutions Architect – Professional（SAP）試験形式で整理・解説します。
■問題文
ライブイベント会社は、AWS 上のチケットアプリケーションのスケーリングソリューションを設計しています。このアプリケーションは、セールイベント中に使用率が最も高くなります。各セールイベントは、スケジュールされた 1 回限りのイベントです。アプリケーションは、Auto Scaling グループに属する Amazon EC2 インスタンス上で実行されます。アプリケーションはデータベース層に PostgreSQL を使用しています。
同社は、セールイベント時の可用性を最大化するスケーリングソリューションを必要としています。
■選択肢
A.
EC2 インスタンスに予測スケーリングポリシーを使用します。リードレプリカを自動的にスケーリングする Amazon Aurora PostgreSQL Serverless v2 マルチ AZ DB インスタンスでデータベースをホストします。AWS Step Functions ステートマシンを作成して、AWS Lambda 関数を並列実行し、セールイベントの前にデータベースを事前にウォームアップします。Amazon EventBridge ルールを作成して、ステートマシンを呼び出します。
B.
EC2 インスタンスにスケジュールされたスケーリングポリシーを使用します。リードレプリカを自動的にスケーリングする Amazon RDS for PostgreSQL マルチ AZ DB インスタンスでデータベースをホストします。販売イベントの前に、AWS Lambda 関数を呼び出してより大きなリードレプリカを作成する Amazon EventBridge ルールを作成します。より大きなリードレプリカにフェイルオーバーします。別の EventBridge ルールを作成し、別の Lambda 関数を呼び出して、セールイベント後にリードレプリカをスケールダウンします。
C.
EC2 インスタンスに予測スケーリングポリシーを使用します。リードレプリカを自動的にスケーリングする Amazon RDS for PostgreSQL マルチ AZ DB インスタンスでデータベースをホストします。AWS Step Functions ステートマシンを作成して AWS Lambda 関数を並列実行し、セールイベントの前にデータベースを事前にウォームアップします。Amazon EventBridge ルールを作成して、ステートマシンを呼び出します。
D.
EC2 インスタンスにスケジュールされたスケーリングポリシーを使用します。Amazon Aurora PostgreSQL マルチ AZ DB クラスターでデータベースをホストします。セールイベントの前に、AWS Lambda 関数を呼び出してより大きな Aurora レプリカを作成する Amazon EventBridge ルールを作成します。より大きな Aurora レプリカにフェイルオーバーします。別の Lambda 関数を呼び出す別の EventBridge ルールを作成し、セールイベント後に Aurora レプリカをスケールダウンします。
■問題文の要件の概要
- イベントは一度限りのセールイベント
- EC2ベースのアプリケーション（Auto Scaling）
- データベースはPostgreSQL
- イベント時の可用性を最大化する必要あり
- 高トラフィックに対応する事前スケーリングが求められる
■正解の選択肢と解説
正解：D
スケジュールスケーリング + Aurora PostgreSQL + レプリカ昇格 + EventBridgeによる制御
- スケジュールされたスケーリングは「一度限り」のイベントに適しており、予測スケーリングより合理的。
- Amazon Aurora PostgreSQL は、RDS for PostgreSQL より高スループット・高パフォーマンス・高速フェイルオーバーに優れている。
- セール前により大きなレプリカを用意してフェイルオーバー、イベント後にスケールダウンする戦略は、高可用性 + コスト効率の両立に適している。
- Aurora のマルチAZ構成も可用性を補強。
■不正解の選択肢の理由
A：予測スケーリング + Aurora Serverless
- 予測スケーリングは継続的パターンのトラフィックに適しており、「1回限りのイベント」には不適。
- Aurora Serverless v2 は柔軟性はあるが、高可用性と事前スケーリング・フェイルオーバー制御の観点で D より劣る。
B：スケジュールスケーリング + RDS for PostgreSQL
- RDS for PostgreSQLはAuroraと比べてスケーラビリティや性能が劣る。
- フェイルオーバーや大規模アクセス処理にはAuroraが適している。
C：予測スケーリング + RDS for PostgreSQL
- 予測スケーリングはイベントに適さず、DBもAurora未使用で要件にマッチしない。
■SAP試験で押さえておくべきポイント
| ポイント | 解説 |
|---|---|
| スケジュールされたスケーリング | 一回限りや特定時間帯の負荷に対応するには「スケジュール型」が有効。予測スケーリングは継続的パターン向け。 |
| Aurora PostgreSQL vs RDS | パフォーマンスやスケーラビリティ、可用性の観点でAuroraが優位。高負荷イベントではAuroraが選ばれやすい。 |
| レプリカのフェイルオーバー戦略 | イベント時にレプリカを昇格させて主DBとすることで、スループット向上が狙える。 |
| EventBridge + Lambda | イベント駆動で事前スケーリングや事後スケールダウンが自動化可能。 |
| Aurora Serverless v2 | 柔軟なスケーリングを提供するが、タイミング制御やイベントドリブンには制限があるため、RTOやRPO重視のシナリオでは注意。 |
次の問題も同様の形式でお待ちしています。必要があれば、予測スケーリングとスケジュールスケーリングの比較表などもご提供可能です。
以下に、問題5をAWS Certified Solutions Architect – Professional（SAP）試験の出題形式に沿って整理・解説します。
■問題文
ある会社には、会社の部門ごとに個別の AWS アカウントが含まれる AWS Organizations の組織があります。異なる部門のアプリケーションチームは、独立してソリューションを開発し、デプロイします。
同社は、コンピューティングコストを削減し、部門全体でコストを適切に管理したいと考えています。同社はまた、各部門の請求に関する可視性を向上させたいと考えています。同社は、コンピューティングリソースを選択する際に、運用上の柔軟性を失いたくありません。
これらの要件を満たすソリューションを選択してください。
■選択肢
A.
部門ごとに AWS Budgets を使用します。タグエディタを使用して、適切なリソースにタグを適用します。EC2 Instance Savings Plans を購入します。
B.
一括請求を使用するように AWS Organizations を設定します。部門を識別するタグ付け戦略を実装します。SCP を使用して、適切なリソースにタグを適用します。EC2 Instance Savings Plans を購入します。
C. ✅（正解）
一括請求を使用するように AWS Organizations を設定します。部門を識別するタグ付け戦略を実装します。タグエディタを使用して、適切なリソースにタグを適用します。Compute Savings Plans を購入します。
D.
部門ごとに AWS Budgets を使用します。SCP を使用して、適切なリソースにタグを適用します。Compute Savings Plans を購入します。
■問題文の要件の概要
- AWS Organizations のマルチアカウント構成
- 部門ごとのコストの可視性
- 運用の柔軟性を維持しながらコスト削減
- コンピューティングリソースに焦点を当てたコスト管理
■正解の選択肢と解説
正解：C
一括請求 + タグ戦略 + Compute Savings Plans の活用が最も合理的
- 一括請求（Consolidated Billing） を利用することで、すべてのアカウントのコストを集約管理し、割引を最大限に活用できる。
- タグ付け戦略により、リソースレベルでの部門ごとのコスト可視化が可能（Cost Allocation Tagsを有効にすることで有効活用）。
- Compute Savings Plans は、インスタンスのタイプやリージョン、サービス（Fargate、Lambda）にとらわれず、最も運用の柔軟性を保ったままコストを削減できる。
■不正解の選択肢の理由
| 選択肢 | 誤っている理由 |
|---|---|
| A | EC2 Instance Savings Plans は特定インスタンスタイプやリージョンに制限され、柔軟性に欠ける。また、AWS Budgets はコストの追跡や警告が目的で、可視性の改善には不十分。 |
| B | SCP（Service Control Policy）ではタグの適用は制御できない。また、EC2 Instance Savings Plans は柔軟性に欠け、Compute Savings Plansの方が本問の要件に合致。 |
| D | Budgets + SCPの組み合わせでは、タグによるコスト分析が不十分。タグ適用方法が明確でない点と、SCPの誤用途も誤り。 |
■SAP試験で押さえておくべきポイント
| 観点 | ポイント |
|---|---|
| 請求管理 | AWS Organizations の 一括請求（Consolidated Billing） は、全アカウントの請求統合によりコスト最適化が可能。 |
| タグ戦略 | タグ（特にコスト配分タグ）を活用して、部門別やプロジェクト別のコスト管理・可視化ができる。 |
| Savings Plans | Compute Savings Plans は、EC2、Lambda、Fargate 全てに柔軟に適用可能。EC2 Instance Savings Plans より柔軟性が高い。 |
| Budgets | AWS Budgets はコストのアラートや予算超過の検知に有効だが、コストの可視化・管理構造の設計には向かない。 |
| SCP | SCP はアカウントレベルでの サービス利用制御に使用するもので、タグ適用制御などには使えない。 |
次の問題も準備できましたら、同様の形式で解説いたします。コスト管理系の分野は試験でも出題されやすいため、関連分野の深掘りも可能です。
以下に、問題6をAWS Certified Solutions Architect – Professional（SAP）試験の形式に沿って整理・解説します。
■問題文
あるデータ分析会社は、複数のリザーブドノードで構成される Amazon Redshift クラスターを持っています。従業員のチームが詳細な監査分析レポートを作成しているため、クラスターで予期しない使用量の急増が発生しています。レポートを作成するためのクエリは複雑な読み取りクエリで、CPU に負荷がかかります。
ビジネス要件では、クラスターは常に読み取りと書き込みのクエリに対応できる必要があります。ソリューションアーキテクトは、使用量の急増に対応するソリューションを考案する必要があります。
これらの要件を最もコスト効率よく満たすソリューションを選択してください。
■選択肢
A.
Amazon EMR クラスターをプロビジョニングする 複雑なデータ処理タスクをオフロードします。
B.
AWS Lambda 関数をデプロイして、Amazon CloudWatch のクラスターの CPU メトリクスが 80% に達したときに、従来のサイズ変更オペレーションを使用して Amazon Redshift クラスターに容量を追加します。
C.
AWS Lambda 関数をデプロイし、Amazon CloudWatch のクラスターの CPU メトリクスが 80% に達したときに、伸縮自在なサイズ変更オペレーションを使用して Amazon Redshift クラスターに容量を追加します。
D. ✅（正解）
Amazon Redshift クラスターの同時実行スケーリングを有効にします。
■問題文の要件の概要
- Redshift クラスターで CPU 負荷の高い読み取りクエリ が発生している。
- 書き込みクエリも継続的に発生しており、常に両方に対応できる性能が必要。
- 突発的なクエリ負荷の急増にスケーラブルに対応したい。
- ソリューションは コスト効率が高いこと。
■正解の選択肢と解説
正解：D. Amazon Redshift クラスターの同時実行スケーリングを有効にします。
- 同時実行スケーリング（Concurrency Scaling） は、Redshift クラスターの 読み取りクエリの急増に自動的に対応する仕組みで、必要なときに自動的に追加キャパシティを起動。
- 書き込みクエリはメインクラスターで処理され、読み取りクエリをスケーリングクラスターにオフロードすることで全体の処理能力を最適化。
- **従量課金制（使用した時間だけ課金）**で、追加コストを最小限に抑えながらスケーラブルに対応可能。
■不正解の選択肢の理由
| 選択肢 | 誤っている理由 |
|---|---|
| A. EMR クラスターを使用 | EMR は一般的な分散処理向けであり、Redshift クエリのパフォーマンス向上には不適切。インフラの増加と運用コストがかかる。 |
| B. Lambda + 従来のサイズ変更 | クラスターの再構成が必要であり、即時反応できない。ダウンタイムやコスト面でも非効率。 |
| C. Lambda + 伸縮自在なサイズ変更（RA3 の elastic resize） | ある程度迅速なサイズ変更は可能だが、それでもスケーリングに数分かかり遅延が発生。突発的なスパイクへの即応性が低い。 |
■SAP試験で押さえておくべきポイント
| 観点 | ポイント |
|---|---|
| Amazon Redshift | Redshift には Concurrency Scaling（同時実行スケーリング） があり、突発的な読み取りクエリ急増へのスケーラブルかつコスト効率のよい対応策。 |
| スケーリング戦略 | 同時実行スケーリングはオンデマンドで処理容量を追加。使用時間に応じた課金のため、常時スケールアウトするより安価。 |
| Elastic Resize / Classic Resize | サイズ変更（Elastic や Classic）は時間がかかり、リアルタイム性が要求されるワークロードには不向き。 |
| EMR vs Redshift | Redshift ワークロードの最適化には Redshift の機能を使用すべき。EMR との連携は別用途（ETL やバッチ処理）に適する。 |
| Lambda + 自動化 | CloudWatch + Lambda による自動対応は柔軟だが、Redshift に対する即時性や実用性は限定的。 |
次の問題があれば、引き続き同様の形式で解析いたします。Redshiftのスケーリング戦略はSAP試験でよく問われるため、他のパターン（Spectrum, RA3 ノードなど）も合わせて覚えておくと効果的です。
以下は、提供いただいたSAP問題7に基づく出力です：
■問題文（編集せずに出力）
ある企業が新しいウェブアプリケーションをデプロイしました。セットアップの一環として、同社は Amazon Kinesis Data Firehose を通じて Amazon S3 にログを記録するように AWS WAF を設定しました。同社は、過去 24 時間の AWS WAF ログデータを返すために毎日 1 回実行される Amazon Athena クエリを開発しました。毎日のログの量は一定です。しかし、時間が経つにつれて、同じクエリの実行にかかる時間が長くなっています。
ソリューションアーキテクトは、クエリ時間が増加し続けるのを防ぐソリューションを設計する必要があります。ソリューションでは、運用上のオーバーヘッドを最小限に抑える必要があります。
これらの要件を満たすソリューションを選択してください。
■選択肢（文字列を編集せずに出力）
A. 毎日の AWS WAF ログを 1 つのログファイルに統合する AWS Lambda 関数を作成します。
B. 毎日異なる S3 バケットにログを送信するように AWS WAF を構成することによって、スキャンされるデータ量を減らします。
C. Kinesis Data Firehose の設定を更新して、Amazon S3 のデータを日付と時刻で分割します。Amazon Redshift の外部テーブルを作成します。データソースをクエリするように Amazon Redshift Spectrum を設定します。
D. Kinesis Data Firehose 設定と Athena テーブル定義を変更して、日付と時刻でデータを分割します。関連するパーティションを表示するように Athena クエリを変更します。
■問題文の要件の概要
- 毎日のログ量は一定だが、Athena クエリ時間が長くなっている。
- クエリ対象は「過去24時間」のログ。
- 運用上のオーバーヘッドは最小限にしたい。
- 解決策は、パフォーマンス劣化の原因（スキャン量の増大）に対応するものである必要がある。
■正解の選択肢と解説
正解：D. Kinesis Data Firehose 設定と Athena テーブル定義を変更して、日付と時刻でデータを分割します。関連するパーティションを表示するように Athena クエリを変更します。
解説：
Amazon Athena はスキャンするデータ量に比例してクエリ時間とコストが増加するため、クエリ対象のデータを「日付ベースでパーティショニング」することで、スキャン対象を限定できます。Firehose 側で S3に日付プレフィックス（例：year=2025/month=06/day=29）を付与して保存し、Athena テーブル定義にパーティションを持たせることで、クエリで過去1日のみのデータを対象にできます。
これによりスキャン量とクエリ時間を抑えつつ、運用オーバーヘッドも最小限にできます。
■不正解の選択肢の理由
A.
「ログを1つのファイルに統合」するLambda処理は、むしろオーバーヘッドを増やす手段です。Athenaは大規模ファイルを扱うのが得意で、1ファイル化してもクエリ効率の根本解決にはならず、かつLambda管理コストも増加します。
B.
「毎日異なるS3バケットに保存」は非効率で、S3バケットの運用管理が煩雑になり、バケット数の増加による可視性の低下・管理コスト増が発生します。スキャン量の制御もパーティショニングのように効率的ではありません。
C.
「Redshift Spectrum を使う」こと自体は間違いではないですが、本設問の要件（Athenaベースで運用中で運用オーバーヘッドを増やしたくない）から外れており、不要なRedshift導入はコスト・運用負担が大きく誤答です。
■SAP試験で押さえておくべきポイント
- Athena + S3 分析では「パーティショニング」がクエリ最適化の鍵。
- Kinesis Data Firehose は動的パーティショニングが可能。
S3保存時にprefix/year=yyyy/month=MM/day=ddのように分けることでAthena側もパーティション指定で高速クエリが可能に。 - Athenaクエリコスト・速度はスキャン量に比例する。→データ量を減らす設計が最重要。
- Athena テーブル定義に合わせて適切な形式（例：Parquet）・プレフィックス管理・パーティション管理を実施するのがベストプラクティス。
次の問題もあれば、同じ形式で分析いたしますので、お気軽にお送りください。
