Uncategorized

#54

 

はい！問題1 を整理しました。

■問題文

ある企業は、60 のオンプレミスのレガシーアプリケーションを AWS に移行する必要があります。これらのアプリケーションは .NET Framework に基づいており、Windows で実行されます。

同社は、移行時間を最小限に抑え、アプリケーションコードの変更を必要としないソリューションを必要としています。また、インフラストラクチャの管理も望んでいません。

これらの要件を満たすソリューションを選択してください。

■選択肢

A. AWS Toolkit for .NET Refactoring を使用して、アプリケーションをリファクタリングし、コンテナ化します。Fargate 起動タイプで Amazon Elastic Container Service (Amazon ECS) を使用して、コンテナ化されたアプリケーションをホストします。

B. Windows Web Application Migration Assistant を使用して、アプリケーションを AWS Elastic Beanstalk に移行します。Elastic Beanstalk を使用して、アプリケーションをデプロイし、管理します。

C. Windows Web Application Migration Assistant を使用して、アプリケーションを Amazon EC2 インスタンスに移行します。EC2 インスタンスを使用して、アプリケーションをデプロイし、管理します。

D. AWS Toolkit for .NET Refactoring を使用して、アプリケーションをリファクタリングし、コンテナ化します。Fargate 起動タイプで Amazon Elastic Kubernetes Service (Amazon EKS) を使用して、コンテナ化されたアプリケーションをホストします。

■問題文の要件の概要

  • アプリ特性：.NET Framework ベース、Windows 上で稼働。
  • 要件：
    • コード修正なしで移行したい。
    • 移行時間を短縮したい。
    • インフラ管理を最小化したい。
  • 理想解：既存 Windows 環境をそのまま受け入れ可能な PaaS 型のマネージドサービス。

■正解の選択肢と解説

✅ B. Windows Web Application Migration Assistant + Elastic Beanstalk

  • Windows Web Application Migration Assistant は IIS 上の .NET Framework アプリを自動検出し、移行用パッケージを作成。
  • Elastic Beanstalk の Windows/.NET プラットフォームにデプロイ可能。
  • Elastic Beanstalk は EC2・Auto Scaling・ELB・監視・パッチ管理 をフルマネージド提供 → 運用負担を軽減。
  • コード修正不要で短期間に大量アプリを移行可能。

👉 「コード変更なし」「インフラ管理不要」「迅速な移行」という要件をすべて満たす。

■不正解の選択肢の理由

❌ A. ECS + .NET Refactoring

  • .NET Framework アプリを .NET 6 以降に変換し、Docker 化が必要。
  • コード修正・テストが発生 → 移行時間が長くなる。

❌ C. EC2 に移行

  • EC2 はインフラ管理が必要（OS パッチ、IIS 設定、スケーリング対応）。
  • 「インフラ管理不要」の要件を満たさない。

❌ D. EKS + .NET Refactoring

  • .NET Refactoring に加え Kubernetes 運用も必要。
  • 複雑性が高く、迅速・低運用コストという要件に反する。

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

  • 移行戦略の判断基準
    • Rehost（リフト＆シフト）：EC2 → 運用負荷大。
    • Replatform（そのまま移行）：Elastic Beanstalk → コード修正なし・運用軽減。
    • Refactor（リファクタリング）：ECS/EKS → コード修正必要、時間とコスト増。
  • Elastic Beanstalk の強み
    • Windows/.NET アプリをサポート。
    • オートスケーリング、監視、パッチ適用、ロールバックを自動化。
    • レガシーアプリの短期移行に最適。

👉 この問題の本質は、
「.NET Framework アプリをコード修正なし・短期間・インフラ管理不要で移行するなら Elastic Beanstalk」
という理解です。

次は 問題2 をまとめていきますか？

はい！問題2 を整理しました。

■問題文

ソリューションアーキテクトは、企業が間もなくリリースする新しいアプリケーションのために、データストレージと検索のアーキテクチャを設計しています。このアプリケーションは、世界中のデバイスから毎分数百万の小さなレコードを取り込むように設計されています。各レコードのサイズは 4 KB 以下で、低レイテンシーで検索できる耐久性のある場所に保存する必要があります。データは一時的なものであり、会社は 120 日間のみデータを保存し、その後はデータを削除することが求められています。ソリューションアーキテクトは、1 年の間にストレージ要件は約 10～15 TB になると計算しています。最も費用対効果が高く、設計要件を満たすストレージ戦略を選択してください。

■選択肢

A. 各受信レコードを単一の .csv ファイルとして Amazon S3 バケットに保存し、インデックス付き検索を可能にするようにアプリケーションを設計します。120 日より古いデータを削除するようにライフサイクルポリシーを設定します。

B. 各受信レコードを、スケール用に設定された Amazon DynamoDB テーブルプロパティに保存するようにアプリケーションを設計します。120 日より古いレコードを削除するように DynamoDB 有効期限 (TTL) を設定します。

C. 各受信レコードを Amazon RDS MySQL データベースの 1 つのテーブルに保存するようにアプリケーションを設計します。120 日より古いレコードを削除するクエリを実行する cron ジョブを毎晩実行します。

D. Amazon S3 バケットに書き込む前に、受信レコードをバッチ処理するようにアプリケーションを設計します。オブジェクトのメタデータを更新して、バッチ内のレコードのリストを含め、Amazon S3 メタデータ検索機能を使用してデータを取得します。120 日後にデータを削除するようにライフサイクルポリシーを設定します。

■問題文の要件の概要

  • 規模：毎分数百万件の取り込み。
  • データ特性：1 レコードあたり 4 KB 以下。
  • 要件：
    • 耐久性と低レイテンシー検索。
    • データ保持は 120 日のみ（TTL で自動削除が望ましい）。
    • 年間 10～15 TB 規模 → ストレージコストも最適化が必要。

■正解の選択肢と解説

✅ B. DynamoDB + TTL

  • DynamoDB は 単桁ミリ秒の読み書き を保証するフルマネージド NoSQL データベース。
  • 各レコードサイズは 400 KB 未満 → 4 KB レコードに最適。
  • スケーリング：オンデマンドキャパシティや Auto Scaling により、数百万 TPS に自動対応可能。
  • TTL：アイテムにタイムスタンプを持たせ、120 日後に自動削除。削除処理でスループットを消費しない。
  • マルチ AZ レプリケーションで高い耐久性と可用性を確保。

👉 「超高スループット」「低レイテンシー検索」「期限切れデータの自動削除」をすべて満たす唯一の選択肢。

■不正解の選択肢の理由

❌ A. S3 に .csv 保存 + ライフサイクル

  • 毎分数百万 PUT は S3 のスループット制限に抵触。
  • 小オブジェクトを大量に保存すると PUT コスト増大。
  • S3 は低レイテンシー検索用途には不向き（一覧・検索が遅い）。

❌ C. RDS MySQL

  • 数百万 TPS の書き込みを処理できない。
  • DELETE クエリで大規模データ削除するとテーブルロックや性能劣化が発生。
  • 水平方向のスケーリングが難しく、コストが急増。

❌ D. S3 バッチ処理 + メタデータ検索

  • S3 のメタデータ検索はオブジェクト単位のみ。
  • バッチに含めたレコードの検索は GET してパースが必要 → 遅延増大。
  • バッチオブジェクトに新旧データが混在 → TTL を正確に適用できない。

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

  • DynamoDB の強み
    • 小サイズレコードの大量書き込みに最適。
    • 単桁ミリ秒のレイテンシーを保証。
    • DynamoDB TTL で期限切れデータを自動削除可能。
  • S3 の限界
    • 大量小オブジェクトの保存はコスト＆性能効率が悪い。
    • 検索要件には不向き（Data Lake やアーカイブには有効）。
  • RDS の限界
    • 水平スケールが難しく、超高スループットには対応不可。
    • 定期削除処理が大きな負荷を招く。

👉 この問題の本質は、
「小さなレコードを大量に処理し、短期保持しつつ低レイテンシー検索する要件には DynamoDB + TTL が最適」
という理解です。

次は 問題3 を整理していきますか？

はい！問題3 を整理しました。

■問題文

ある会社はオンプレミスでイントラネットアプリケーションを実行しています。同社はアプリケーションのクラウドバックアップを構成したいと考えています。同社は、このソリューションに AWS Elastic Disaster Recovery を選択しました。

同社は、レプリケーショントラフィックがパブリックインターネットを経由しないことを要求しています。また、アプリケーションにはインターネットからアクセスできないようにする必要があります。同社は、他のアプリケーションが帯域幅を必要とするため、このソリューションが利用可能なネットワーク帯域幅をすべて消費することを望んでいません。

これらの要件を満たす手順の組み合わせを選択してください。(3 つ選択)

■選択肢

A. 少なくとも 2 つのプライベートサブネット、2 つの NAT ゲートウェイ、および仮想プライベートゲートウェイを持つ VPC を作成します。

B. 少なくとも 2 つのパブリックサブネット、仮想プライベートゲートウェイ、およびインターネットゲートウェイを持つ VPC を作成します。

C. オンプレミスネットワークとターゲット AWS ネットワークの間に AWS Site-to-Site VPN 接続を作成します。

D. オンプレミスネットワークとターゲット AWS ネットワークの間に AWS Direct Connect 接続と Direct Connect ゲートウェイを作成します。

E. レプリケーションサーバーの設定で、データレプリケーションにプライベート IP アドレスを使用するオプションを選択します。

F. ターゲットサーバーの起動設定の構成中に、回復インスタンスのプライベート IP アドレスがソースサーバーのプライベート IP アドレスと一致することを確認するオプションを選択します。

■問題文の要件の概要

  • 通信要件：レプリケーションはパブリックインターネットを経由しないこと。
  • セキュリティ要件：アプリケーションはインターネット非公開。
  • 帯域制御要件：他アプリに影響を与えないよう、専用経路や帯域制御が必要。
  • サービス：AWS Elastic Disaster Recovery（DRS）を利用。

■正解の選択肢と解説

✅ A. プライベートサブネット + NAT GW + VGW

  • レプリケーションサーバーやリカバリインスタンスを プライベートサブネットに配置することで、外部からアクセスできない。
  • 仮想プライベートゲートウェイ (VGW) を使い Direct Connect と連携。
  • NAT GW は必要なアウトバウンド通信（アップデートや S3 連携など）に利用。

✅ D. AWS Direct Connect + Direct Connect Gateway

  • 専用線を利用するため、パブリックインターネットを経由せず安定した通信。
  • 帯域（1Gbps/10Gbps）を専用で確保できるため、他アプリのインターネット帯域を消費しない。
  • Direct Connect Gateway により複数 VPC・リージョン対応が可能。

✅ E. レプリケーションでプライベート IP を使用

  • Elastic Disaster Recovery で「Use private IP for replication」を選択することで、必ずプライベート経路で通信。
  • インターネットに誤って出ることを防止。
  • DRS の スロットリング機能により帯域制御も可能。

■不正解の選択肢の理由

❌ B. パブリックサブネット + IGW

  • インターネットゲートウェイ経由で外部公開される → 「インターネット非公開」要件に違反。

❌ C. Site-to-Site VPN

  • 通信自体は暗号化されるが、物理的経路はパブリックインターネット → 要件違反。
  • 帯域もベストエフォートのため安定性に欠ける。

❌ F. 復旧インスタンスの IP をソースと一致させる

  • 単に IP アドレスの整合性を取るだけで、閉域接続や帯域制御には無関係。
  • CIDR 重複リスクを高めるだけで要件を満たさない。

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

  • Elastic Disaster Recovery (DRS)
    • オンプレから AWS への ディザスタリカバリ用レプリケーションサービス。
    • プライベート接続（Direct Connect）や プライベート IP レプリケーションを組み合わせるのがベストプラクティス。
    • 帯域制御（スロットリング）機能あり。
  • Direct Connect vs Site-to-Site VPN
    • Direct Connect → 閉域専用線・安定帯域確保。
    • VPN → パブリック経由（暗号化あり）だが、帯域・安定性はベストエフォート。
  • VPC 設計の基本
    • イントラネット用途はプライベートサブネット必須。
    • IGW を付けるとインターネット経由となるため要件違反になるケースが多い。

👉 本質は 「インターネットを経由させず、専用線＋プライベート経路で DRS を構成」 すること。

次は 問題4 に進めますか？

はい！問題4 を整理しました ✅

■問題文

ある企業は、自社の AWS 環境からのアウトバウンドのトラフィックを監視および保護するために、AWS Marketplace からサードパーティーのファイアウォールアプライアンスソリューションをデプロイしています。同社は、このアプライアンスを共有サービス VPC にデプロイし、すべてのアウトバウンドのインターネット行きのトラフィックをアプライアンス経由でルーティングしたいと考えています。

ソリューションアーキテクトは、信頼性を優先し、単一の AWS リージョン内のファイアウォールアプライアンス間のフェイルオーバー時間を最小限に抑える導入方法を推奨する必要があります。同社は、共有サービス VPC から他の VPC へのルーティングを設定しています。

これらの要件を満たす最適な手順を選択してください。(3 つ選択)

■選択肢

A. 2 つのファイアウォールアプライアンスを共有サービス VPC にデプロイし、それぞれを別のアベイラビリティーゾーンに配置します。

B. 共有サービス VPC に新しい Network Load Balancer を作成します。新しいターゲットグループを作成し、それを新しい Network Load Balancer にアタッチします。各ファイアウォールアプライアンスインスタンスをターゲットグループに追加します。

C. 共有サービス VPC に新しい Gateway Load Balancer を作成します。新しいターゲットグループを作成し、新しい Gateway Load Balancer にアタッチします。各ファイアウォールアプライアンスインスタンスをターゲットグループに追加します。

D. VPC インターフェイスのエンドポイントを作成します。共有サービス VPC のルートテーブルにルートを追加します。他の VPC から共有サービス VPC に入るトラフィックのネクストホップとして新しいエンドポイントを指定します。

E. 共有サービス VPC に 2 つのファイアウォールアプライアンスを、それぞれ同じアベイラビリティーゾーンに配備します。

F. VPC Gateway Load Balancer エンドポイントを作成します。共有サービス VPC のルートテーブルにルートを追加します。新しいエンドポイントを、他の VPC から共有サービス VPC に入るトラフィックのネクストホップとして指定します。

■問題文の要件の概要

  • 目的：全てのアウトバウンドインターネット通信をサードパーティーファイアウォール経由にする
  • 要件：
    • 高可用性（マルチAZ）
    • フェイルオーバー時間を最小化
    • 複数VPCからのアウトバウンドトラフィックを集約

■正解の選択肢と解説

✅ A. ファイアウォールを異なるAZに配置

  • AZ 冗長構成により、単一AZ障害でもサービス継続可能。
  • フェイルオーバー時のダウンタイムを最小化。

✅ C. Gateway Load Balancer (GWLB) を作成

  • L3/L4トラフィックを透過的にルーティング。
  • ヘルスチェックで異常なアプライアンスを自動的に除外し、健全なアプライアンスへ瞬時に切替。
  • AWSが推奨するファイアウォールアプライアンスの標準設計。

✅ F. GWLBエンドポイントを作成し、ルートテーブルに追加

  • 各VPCから共有サービスVPCへ安全にトラフィックを転送可能。
  • GWLBe は各AZに配置され、障害発生時に自動フェイルオーバー。
  • VPC追加時もエンドポイント作成だけでスケーラブルに拡張。

■不正解の選択肢の理由

❌ B. Network Load Balancer を使用

  • TCP/UDPレベルの分散は可能だが、**透過的ルーティング機能（GENEVEカプセル化）**がないため、全トラフィックを強制的にファイアウォールへ通せない。

❌ D. VPC インターフェイスエンドポイント

  • PrivateLink用であり、任意のインターネット宛トラフィックを中継する機能はない。

❌ E. 同じAZに2台配置

  • AZ障害時に両方が同時に停止するため冗長性がない。

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

  • Gateway Load Balancer (GWLB)
    • サードパーティ製ファイアウォールを高可用・透過的にスケーリングするAWSサービス。
    • GENEVEカプセル化により、全てのトラフィックを強制的に転送可能。
  • マルチAZ設計
    • 高可用性要件では必須。
    • AZ冗長構成＋GWLBでフェイルオーバーをミリ秒レベルに短縮可能。
  • 誤答のポイント
    • NLBは単純な負荷分散のみ。
    • VPCインターフェイスエンドポイントはPrivateLink専用。
    • 同一AZ配置は可用性不足。

👉 本質は「GWLB + GWLBe + マルチAZ配置 によるセキュアで冗長なファイアウォール設計」。

次の 問題5 に進みますか？

はい！問題5 を整理しました ✅

■問題文

金融サービス会社が EC2 + Lambda を用いた多層アプリを運用。
一時データを S3 に保存するが、

  • オブジェクトは 45分間のみ有効
  • 24時間後に削除

CloudFormation スタックでアプリをデプロイ → 古いスタック削除時に S3バケット削除失敗。
原因：バケット内にオブジェクトが残っていたため。

👉 大きなアーキテクチャ変更をせずに解決したい。

■正解

✅ A. Lambda 関数でバケットを空にする → カスタムリソースとして統合

  • Lambda を使い、スタック削除フェーズで対象バケット内の全オブジェクトを削除。
  • DependsOn 属性で依存関係を制御し、確実に削除順序を守る。
  • これにより バケットが空になり、CloudFormation が削除に成功。
  • 最小限の追加（Lambda + カスタムリソース）のみで、既存アプリ設計は大きく変更不要。

■不正解の選択肢

❌ B. EFS を利用

  • 大幅な構成変更が必要。
  • EFS はオブジェクト有効期限の制御ができず、要件を満たさない。

❌ C. S3 ライフサイクルルールで 45分後に削除

  • S3 ライフサイクルはバッチ処理であり即時性なし。
  • 遅延で削除前にスタック削除が走ると失敗する。

❌ D. DeletionPolicy=Delete を付与

  • DeletionPolicy は「削除時の動作（保持・スナップショットなど）」を制御するが、
    中身のオブジェクト削除はしない。
  • バケットが空でなければ削除失敗は変わらない。

■試験でのポイント

  • CloudFormation は中身が残っている S3 バケットを削除できない。
  • **バケットを空にする仕組み（Lambdaカスタムリソース）**が必要。
  • S3 ライフサイクルや DeletionPolicy では「即時空にする」要件を満たせない。

👉 本質は「CloudFormation スタック削除を成功させるには、削除前に確実にバケットを空にする処理が必要」。

次の 問題6 も整理しますか？

了解しました。それではご依頼いただいたフォーマットで整理します。

■問題文

ある会社は、モノリシックアプリケーションを AWS 上にデプロイされた最新のアプリケーションデザインにリファクタリングすることを計画しています。CI/CD パイプラインは、以下の要件を満たすアプリケーションの最新の設計をサポートするためにアップグレードする必要があります。

・ 1 時間に数回の変更をリリースできるようにしなければなりません。
・ 変更をできるだけ早くロールバックできる必要があります。

これらの要件を満たす設計はどれですか？

■選択肢

A：アプリケーションとその構成を格納するために AMI を組み込んだ CI/CD パイプラインをデプロイします。Amazon EC2 インスタンスを置き換えてアプリケーションをデプロイします。

B：アプリケーションの CI/CD パイプラインのデプロイ先として、セカンダリ環境でステージングする AWS Elastic Beanstalk を指定します。デプロイするには、ステージング環境と本番環境の URL を入れ替えます。

C：AWS Systems Manager を使用して、各デプロイのインフラストラクチャを再プロビジョニングします。Amazon EC2 ユーザーデータを更新して、Amazon S3 から最新のコードアーティファクトを引き出し、Amazon Route 53 加重ルーティングを使用して新しい環境を指すようにします。

D：ビルド済みの AMI を使用して、Auto Scaling イベントの一部としてアプリケーションの更新をロールアウトします。新しいバージョンの AMI を使用してインスタンスを追加し、デプロイイベントの間に設定された終了ポリシーで以前の AMI バージョンを使用するすべてのインスタンスを段階的に廃止します。

■問題文の要件の概要

  • モノリシックアプリケーションをリファクタリングしてモダンなアプリ設計へ移行する。
  • 高頻度デプロイ（1時間に数回リリース可能）。
  • 即時ロールバックできる仕組みが必須。

■正解の選択肢と解説

B：AWS Elastic Beanstalk を使用し、セカンダリ環境にステージング → 本番環境と URL をスワップする方式

Elastic Beanstalk は、Blue/Green デプロイをサポートしており、CNAME スワップ機能によって本番環境とステージング環境の URL を即座に入れ替えることができます。

  • これにより 数分以内でのデプロイ が可能。
  • 問題があれば CNAME を元に戻すだけで即時ロールバック ができる。
  • インフラ管理も自動化されており、CI/CD パイプラインとの連携も容易。

このため、頻繁リリースと即時ロールバックの要件を満たす最適解です。

■不正解の選択肢の理由

  • A（EC2 + AMI 置換）
    • AMI ビルド・インスタンス置換に時間がかかる。
    • 数分〜数十分のデプロイとなり高頻度リリース・即時ロールバックに不向き。
  • C（Systems Manager + Route 53 加重ルーティング）
    • 環境の再プロビジョニングや DNS 切替に手間と時間がかかる。
    • 短時間でのデプロイ／即時ロールバックには不向き。
  • D（Auto Scaling + AMI ローリング更新）
    • 新 AMI のインスタンスを順次展開 → 検証 → 旧インスタンス停止と段階を踏むため時間がかかる。
    • ロールバックも即時にはできない。

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

  • Blue/Green デプロイは高頻度リリースと即時ロールバックに最適な手法。
  • Elastic Beanstalkはインフラ管理不要で、CNAME スワップによる ダウンタイム最小化／迅速な切り戻しが可能。
  • AMI ベースの更新は堅牢だが、時間がかかるため短時間デリバリーには不向き。
  • Route 53 加重ルーティングはトラフィック移行に有効だが、プロビジョニングを伴う場合は迅速性に欠ける。
  • Auto Scaling のローリング更新は安全性はあるが、速度と即時ロールバック要件には不適。

✅ この問題の本質は 「高頻度リリース」＋「即時ロールバック」＝ Blue/Green デプロイの採用 です。

次も同じ形式でまとめますか？

了解しました！それでは 問題7 を整理します。

■問題文

ある企業が複数の AWS アカウントにワークロードをデプロイしています。各アカウントには VPC があり、VPC フローログはテキストログ形式で一元管理された Amazon S3 バケットに公開されています。各ログファイルは gzip 圧縮されています。同社は、ログファイルを無期限に保持する必要があります。

セキュリティエンジニアは、Amazon Athena を使用して VPC フローログをクエリし、ログを定期的に分析します。取り込まれたログの数が増えるにつれて、クエリのパフォーマンスは時間とともに低下しています。ソリューションアーキテクトは、ログ分析のパフォーマンスを改善し、VPC フローログが使用するストレージ容量を削減する必要があります。

これらの要件を満たし、パフォーマンスが最も向上するソリューションを選択してください。

■選択肢

A：gzip ファイルを解凍し、bzip2 圧縮でファイルを圧縮する AWS Lambda 関数を作成します。S3 バケットの s3:ObjectCreated:Put S3 イベント通知に Lambda 関数をサブスクライブします。

B：S3 バケットの S3 Transfer Acceleration を有効にします。ファイルがアップロードされるとすぐに S3 Intelligent-Tiering ストレージクラスにファイルを移動する S3 ライフサイクル設定を作成します。

C：VPC フローログ設定を更新して、ファイルを Apache Parquet 形式で保存します。ログファイル用に 1 時間ごとのパーティションを指定します。

D：データ使用量制御制限のない新しい Athena のワークグループを作成します。Athena エンジンバージョン 2 を使用します。

■問題文の要件の概要

  • Athena クエリのパフォーマンス低下が問題
  • ログは無期限保存が必須
  • ストレージ容量削減も求められる
  • 解決策は「Athena が効率的にスキャンできるデータ形式＋構造」にする必要がある

■正解の選択肢と解説

✅ C：VPC フローログを Apache Parquet 形式で保存し、1時間ごとにパーティション分割する

  • Apache Parquet は列指向フォーマットで、Athena は不要な列を読み飛ばせる（列プルーニング）。
  • gzip テキストよりも 圧縮率が高く、ストレージ容量を削減できる。
  • 時間ベースのパーティションにより、Athena は必要な範囲だけをスキャンし、クエリ速度が大幅に向上。
  • スキャンデータ量が減ることで コスト削減にもつながる。

■不正解の選択肢の理由

  • A（gzip → bzip2 再圧縮）
    • 圧縮方式を変えても行指向テキストのままであり、Athena は全行をスキャンする必要がある。
    • クエリ性能は改善しない。
  • B（S3 Transfer Acceleration + Intelligent-Tiering）
    • Transfer Acceleration はアップロード速度改善用。Athena クエリ性能には無関係。
    • Intelligent-Tiering はストレージコスト最適化であり、スキャン効率は改善しない。
  • D（Athena ワークグループ新規作成 + Engine v2）
    • ワークグループやエンジン変更だけでは、基盤となるファイル形式がテキストのままなのでスキャン量は減らない。
    • 根本的な性能改善につながらない。

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

  • Athena のパフォーマンス改善の王道は「列指向フォーマット（Parquet / ORC）」＋「パーティション」。
  • gzipやbzip2などの圧縮方式変更ではなく、データ形式を最適化するのが重要。
  • S3 Intelligent-Tiering や Transfer Acceleration はストレージ／ネットワーク効率向上用であり、Athena クエリには直接関係しない。
  • ワークグループやエンジン設定よりも、データ形式・構造設計が最優先。

👉 この問題の核心は、「Athena のボトルネックは スキャンデータ量」であり、それを解決するのが Parquet + パーティション だという点です。

次の問題（問題8）も同じ形式で整理しますか？

RELATED POST