自主学習用のまとめノートです

試験配点：24%（採点対象コンテンツ）

1. はじめに

1.1 Domain3の概要

Domain3「高パフォーマンスなアーキテクチャの設計」 は、AWS SAA試験全体の 24% を占める重要な分野です。

この分野では、ワークロードの要件に応じて最適なAWSサービスを選択し、高いパフォーマンスを維持しながらスケーラブルなアーキテクチャを設計する能力が問われます。

1.2 出題される5つのタスク領域

タスク	内容	重要ポイント
タスク1	ストレージソリューション	EBS、EFS、S3の選択
タスク2	コンピューティングソリューション	EC2、Lambda、Auto Scaling
タスク3	データベースソリューション	RDS、DynamoDB、キャッシュ
タスク4	ネットワークアーキテクチャ	CloudFront、ELB、VPN
タスク5	データ取り込みと変換	Kinesis、Glue、Athena

1.3 高パフォーマンスアーキテクチャの基本原則

高パフォーマンスなアーキテクチャを設計する際に意識すべき3つの原則があります。

┌─────────────────────────────────────────────────────────────┐
│              高パフォーマンスの3原則                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. 適切なサービス選択                                       │
│     └─ ワークロードの特性に合ったサービスを選ぶ              │
│                                                             │
│  2. スケーラビリティ                                         │
│     └─ 需要の増減に応じて自動的にリソースを調整             │
│                                                             │
│  3. レイテンシーの最小化                                     │
│     └─ ユーザーに近い場所でデータを処理・配信               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

試験のポイント: 問題文に含まれるキーワード（IOPS、スループット、レイテンシー、スケーラビリティなど）から、求められるパフォーマンス特性を読み取ることが重要です。

2. ストレージソリューション

2.1 ストレージの種類と特性

AWSには3種類のストレージタイプがあります。それぞれ用途が異なるため、特性を理解して適切に選択することが重要です。

ストレージタイプの比較

種類	代表サービス	データの扱い方	特徴	主なユースケース
ブロックストレージ	EBS	データを固定サイズの「ブロック」に分割	低レイテンシー、高IOPS	データベース、OS起動ディスク
ファイルストレージ	EFS, FSx	階層構造（フォルダ/ファイル）で管理	複数インスタンスで共有可能	共有ファイルサーバー、CMS
オブジェクトストレージ	S3	フラットな構造でオブジェクトとして保存	無制限の容量、高い耐久性	バックアップ、静的コンテンツ

【イメージで理解】

ブロックストレージ（EBS）
┌───┬───┬───┬───┬───┐
│ A │ B │ C │ D │ E │  ← データを小さなブロックに分割
└───┴───┴───┴───┴───┘    EC2に直接アタッチして使用

ファイルストレージ（EFS）
📁 ルート
├── 📁 フォルダA
│   ├── 📄 ファイル1
│   └── 📄 ファイル2      ← 複数のEC2から同時アクセス可能
└── 📁 フォルダB

オブジェクトストレージ（S3）
┌────────────────────────┐
│ Object1 (key: photo.jpg) │
│ Object2 (key: data.csv)  │  ← フラットな構造、メタデータ付き
│ Object3 (key: log.txt)   │
└────────────────────────┘

2.2 Amazon EBS（Elastic Block Store）

EBSは、EC2インスタンスにアタッチして使用するブロックストレージです。データベースやOSのブートボリュームなど、高速なランダムアクセスが必要なワークロードに適しています。

EBSボリュームタイプの詳細比較

ボリュームタイプ	分類	最大IOPS	最大スループット	ユースケース	コスト
gp3（汎用SSD）	SSD	16,000	1,000 MB/s	一般的なワークロード	低〜中
gp2（汎用SSD）	SSD	16,000	250 MB/s	一般的なワークロード	低〜中
io2 Block Express	SSD	256,000	4,000 MB/s	ミッションクリティカルDB	高
io1/io2（プロビジョンドIOPS）	SSD	64,000	1,000 MB/s	高IOPSが必要なDB	高
st1（スループット最適化HDD）	HDD	500	500 MB/s	ビッグデータ、ログ処理	低
sc1（コールドHDD）	HDD	250	250 MB/s	アクセス頻度の低いデータ	最低

IOPSとスループットの違い

初学者にとって混同しやすいのがIOPSとスループットです。

IOPS（Input/Output Operations Per Second）: 1秒間に処理できる読み書き操作の回数
- 例：データベースで多数の小さなクエリを処理する場合に重要
スループット（Throughput）: 1秒間に転送できるデータ量（MB/s）
- 例：大きなファイルの読み書きやログデータの処理に重要

【IOPSが重要なケース】
データベースの例：
┌────────────────────────────────────────┐
│ SELECT * FROM users WHERE id = 1;      │
│ SELECT * FROM users WHERE id = 2;      │  小さなデータを
│ SELECT * FROM users WHERE id = 3;      │  何度もアクセス
│ ...（毎秒数千〜数万回）                  │  → 高IOPSが必要
└────────────────────────────────────────┘

【スループットが重要なケース】
ビッグデータの例：
┌────────────────────────────────────────┐
│ 100GBのログファイルを読み込み            │  大きなデータを
│ → 連続的にデータを流す                   │  一気に処理
│ → 500MB/秒で処理したい                   │  → 高スループットが必要
└────────────────────────────────────────┘

EBSボリューム選択のフローチャート

                    ┌─────────────────┐
                    │ ストレージ要件は？ │
                    └────────┬────────┘
                             │
            ┌────────────────┼────────────────┐
            ▼                ▼                ▼
    ┌───────────┐    ┌───────────┐    ┌───────────┐
    │ 高IOPS    │    │ 高スループット│   │ 低コスト  │
    │ (DB等)    │    │ (ビッグデータ)│   │ (アーカイブ)│
    └─────┬─────┘    └─────┬─────┘    └─────┬─────┘
          │                │                │
    ┌─────┴─────┐          ▼                ▼
    ▼           ▼    ┌───────────┐    ┌───────────┐
┌───────┐  ┌───────┐ │   st1     │    │   sc1     │
│16,000 │  │16,000 │ │ (HDD)     │    │ (HDD)     │
│IOPS   │  │IOPS   │ └───────────┘    └───────────┘
│以下？  │  │超過？  │
└───┬───┘  └───┬───┘
    ▼          ▼
┌───────┐  ┌───────┐
│ gp3   │  │io1/io2│
│ (SSD) │  │ (SSD) │
└───────┘  └───────┘

試験頻出ポイント:

「20,000 IOPSが必要」→ io1/io2（gp3の上限は16,000 IOPS）
「一時的なデータで最もコスト効率が良い」→ インスタンスストア
「大量のログデータを順次処理」→ st1

2.3 EC2インスタンスストア

インスタンスストアは、EC2インスタンスに物理的に接続されたディスクです。

インスタンスストアの特性

特性	説明
エフェメラル（一時的）	インスタンス停止・終了でデータ消失
追加コストなし	インスタンス料金に含まれる
超高パフォーマンス	物理的に近いため低レイテンシー、高IOPS
サイズ固定	インスタンスタイプで決まる

【EBSとインスタンスストアの違い】

┌─────────────────────────────────────────────────────────┐
│                      EC2インスタンス                    │
│  ┌─────────────────┐      ┌─────────────────────────┐ │
│  │ インスタンスストア │      │        EBS             │ │
│  │  (内蔵ディスク)    │      │   (ネットワーク経由)     │ │
│  │                   │      │                        │ │
│  │ ✓ 超高速          │      │ ✓ データ永続化         │ │
│  │ ✓ 追加コストなし   │      │ ✓ スナップショット可能  │ │
│  │ ✗ データ消失リスク │      │ ✓ サイズ変更可能       │ │
│  └─────────────────┘      └─────────────────────────┘ │
└─────────────────────────────────────────────────────────┘

インスタンスストアの適切なユースケース

キャッシュデータ: 消えても再生成できるデータ
一時的なバッファ: 処理中の中間データ
スクラッチスペース: レンダリング時の一時ファイル

試験頻出ポイント:
問題文に「一時的なデータ」「レンダリング後に破棄」「コスト効率」というキーワードがあれば、インスタンスストアが正解の可能性が高いです。

2.4 Amazon EFS（Elastic File System）

EFSは、複数のEC2インスタンスから同時にアクセスできる共有ファイルシステムです。

EFSのスループットモード

モード	説明	特徴	ユースケース
バーストスループット	ファイルシステムのサイズに比例	小さいFSは低スループット	小規模で一時的な負荷
プロビジョンドスループット	必要なスループットを指定	サイズに関係なく一定	高スループットが常に必要
エラスティックスループット	使用量に応じて自動調整	予測困難なワークロード向け	変動の大きいワークロード

【スループットモードの比較】

バーストスループット
スループット ↑
            │    ▲ バースト
            │   ╱ ╲
            │  ╱   ╲    ← ファイルシステムサイズに依存
            │ ╱     ╲      小さいFSはベースラインが低い
            │╱───────╲
            └──────────→ 時間

プロビジョンドスループット
スループット ↑
            │──────────── ← 常に一定のスループットを確保
            │                サイズに関係なく指定可能
            │
            │
            └──────────→ 時間

試験頻出ポイント:

「ファイルシステムのサイズは小さいが高スループットが必要」→ プロビジョンドスループット
「複数のAZにまたがるECSタスク間でファイル共有」→ EFS

2.5 Amazon S3のパフォーマンス最適化

S3は無制限の容量を持つオブジェクトストレージですが、パフォーマンスを最大化するためのテクニックがあります。

S3のパフォーマンス特性

リクエストレート: プレフィックスあたり毎秒3,500 PUT/COPY/POST/DELETE、5,500 GETリクエスト
自動スケーリング: 負荷に応じて自動的にスケール

パフォーマンス最適化テクニック

テクニック	説明	効果
マルチパートアップロード	大きなファイルを分割してアップロード	100MB以上のファイルで推奨、5GB以上で必須
S3 Transfer Acceleration	CloudFrontのエッジロケーション経由	遠距離からのアップロード高速化
プレフィックス分散	キー名にランダムなプレフィックスを追加	リクエストを分散（現在は自動最適化）
バイトレンジフェッチ	ファイルの一部だけを取得	大きなファイルの部分取得を高速化

2.6 ハイブリッドストレージ

オンプレミスとAWS間でデータを連携させるためのサービスです。

AWS Storage Gateway

オンプレミスのアプリケーションからAWSストレージにシームレスにアクセスするためのサービスです。既存のアプリケーションを変更せずに、AWSのストレージを活用できます。

タイプ	用途	バックエンド
File Gateway	NFS（Network File System：Linux/Unix向けファイル共有プロトコル）やSMB（Server Message Block：Windows向けファイル共有プロトコル）でS3にアクセス	S3
Volume Gateway（キャッシュ型）	頻繁にアクセスするデータをローカルキャッシュ	S3
Volume Gateway（保管型）	全データをローカルに保持、S3にバックアップ	S3
Tape Gateway	仮想テープライブラリ（物理テープの代替）	S3 Glacier

【Storage Gatewayの使用イメージ】

オンプレミス                         AWS
┌─────────────────┐               ┌─────────────┐
│ アプリケーション  │               │             │
│  （既存システム） │               │     S3      │
│        │        │               │             │
│        ▼        │               └─────────────┘
│ ┌─────────────┐ │                     ↑
│ │  Storage    │─┼─────────────────────┘
│ │  Gateway    │ │  NFS/SMBで接続
│ └─────────────┘ │  （アプリは変更不要）
└─────────────────┘

AWS DataSync

オンプレミスとAWS間、またはAWSサービス間で大量のデータを高速転送するサービスです。

特徴: 帯域幅の最適化、暗号化、データ整合性チェック
転送先: S3、EFS、FSx
ユースケース: データ移行、定期的なデータ同期

3. コンピューティングソリューション

3.1 EC2インスタンスタイプの選択

EC2インスタンスは、用途に応じて最適化された複数のファミリーがあります。

インスタンスファミリーの特性

ファミリー	特徴	ユースケース
M系（汎用）	バランスの取れたリソース	Webサーバー、小〜中規模DB
C系（コンピューティング最適化）	高いCPU性能	バッチ処理、ゲームサーバー
R系（メモリ最適化）	大容量メモリ	インメモリDB、ビッグデータ
I系（ストレージ最適化）	高いI/O性能	データウェアハウス、分散FS
G/P系（GPU最適化）	GPUアクセラレーション	機械学習、グラフィックレンダリング

【インスタンスタイプの命名規則】

    m5.xlarge
    │ │  │
    │ │  └── サイズ: nano, micro, small, medium, large, xlarge, 2xlarge...
    │ └───── 世代: 数字が大きいほど新しい
    └─────── ファミリー: m=汎用, c=コンピューティング, r=メモリ, i=ストレージ

試験頻出ポイント:

「グラフィックレンダリング」「40,000 IOPS」「一時データ」→ ストレージ最適化インスタンス（I系）+ インスタンスストア

3.2 Auto Scaling

Auto Scalingは、需要の変化に応じてEC2インスタンスの数を自動的に調整する機能です。

スケーリングの種類

スケーリング	説明	方法
水平スケーリング（スケールアウト/イン）	インスタンス数を増減	Auto Scaling
垂直スケーリング（スケールアップ/ダウン）	インスタンスサイズを変更	手動または自動化

【水平スケーリングと垂直スケーリング】

水平スケーリング（スケールアウト）
┌────┐  ┌────┐  ┌────┐  ┌────┐
│ EC2│  │ EC2│  │ EC2│  │ EC2│  ← インスタンスを追加
└────┘  └────┘  └────┘  └────┘

垂直スケーリング（スケールアップ）
┌────────────┐
│            │
│   EC2      │  ← より大きなインスタンスに変更
│  (大きく)   │
│            │
└────────────┘

Auto Scalingポリシーの種類

ポリシー	説明	ユースケース
ターゲット追跡	指定したメトリクスを目標値に維持	「CPU使用率を50%に維持」
ステップスケーリング	メトリクスの変化幅に応じて段階的に調整	「CPU 70%で+2台、90%で+4台」
シンプルスケーリング	単一のスケーリング調整	シンプルな条件での調整
スケジュールベース	予測可能な需要パターンに対応	「毎日9時に10台に増やす」
予測スケーリング	機械学習で需要を予測	過去のパターンから予測

3.3 サーバーレスコンピューティング

AWS Lambda

Lambdaは、サーバーを管理せずにコードを実行できるサービスです。

主な特徴:

イベント駆動型（S3へのアップロード、API Gatewayからのリクエストなど）
実行時間の課金（100ミリ秒単位）
最大実行時間: 15分

Lambdaのメモリとパフォーマンスの関係

Lambdaでは、メモリを増やすとCPUパワーも比例して増加します。これは試験で重要なポイントです。

【Lambdaのメモリ・CPU・コストの関係】

メモリ設定   CPU性能   実行時間   料金計算
────────────────────────────────────────
  128MB    →  低い   →  遅い   = メモリ × 時間
  512MB    →  中程度 →  中程度 = メモリ × 時間
 1024MB    →  高い   →  速い   = メモリ × 時間

※メモリを2倍にして実行時間が半分以下になれば、コスト削減になる

試験頻出ポイント:
サンプル問題より、「512MBで2分」の処理を最適化する場合：

メモリを1024MB（2倍）にして実行時間が1分未満になれば → コスト削減
メモリを256MB（半分）にして実行時間が4分未満になれば → コスト削減

AWS Fargate

Fargateは、コンテナ用のサーバーレスコンピューティングエンジンです。

項目	EC2起動タイプ	Fargate起動タイプ
インフラ管理	必要	不要
スケーリング	Auto Scaling設定	自動
課金	インスタンス単位	vCPU/メモリ使用量
ユースケース	大規模で予測可能なワークロード	変動するワークロード

3.4 コンテナオーケストレーション

コンテナオーケストレーションとは、複数のコンテナの配置、スケーリング、ネットワーク接続などを自動管理する仕組みです。AWSでは主に2つの選択肢があります。

Amazon ECS（Elastic Container Service）

AWSネイティブのコンテナオーケストレーションサービスです。

特徴: AWS統合が強い、学習コストが低い
起動タイプ: EC2またはFargate

Amazon EKS（Elastic Kubernetes Service）

マネージドKubernetesサービスです。Kubernetesは業界標準のオープンソースコンテナオーケストレーションツールで、Google発祥です。

特徴: オープンソース標準、マルチクラウド対応しやすい
起動タイプ: EC2またはFargate

ECS vs EKS の選択基準

観点	ECS	EKS
学習コスト	低い（AWS独自だがシンプル）	高い（Kubernetesの知識が必要）
AWS統合	深い（IAM、CloudWatch等とシームレス）	標準的
ポータビリティ	AWS専用	他クラウドや自社DCに移行可能
エコシステム	AWS内で完結	Kubernetes周辺ツールが豊富

選択の目安:

AWSに集中し、シンプルに運用したい → ECS
既存のKubernetes資産がある、または将来マルチクラウドを検討 → EKS

3.5 バッチ処理と大規模データ処理

AWS Batch

バッチコンピューティングワークロードを効率的に実行するサービスです。

特徴: ジョブキューの管理、リソースの自動プロビジョニング
ユースケース: 科学計算、金融モデリング、画像処理

Amazon EMR（Elastic MapReduce）

ビッグデータ処理のためのマネージドクラスターサービスです。

対応フレームワーク: Hadoop、Spark、Hive、Presto
ユースケース: ログ分析、ETL処理、機械学習

3.7 分散コンピューティングの概念

分散コンピューティングとは、複数のコンピュータが協調して1つのタスクを処理する手法です。AWSでは様々な分散処理のパターンがあります。

分散処理のパターン

パターン	説明	AWSサービス
水平分散	同じ処理を複数のインスタンスで並列実行	Auto Scaling、ECS、EKS
MapReduce	データを分割（Map）→ 集約（Reduce）	EMR
イベント駆動	イベントに応じて処理を分散実行	Lambda、Step Functions
エッジコンピューティング	データ発生源の近くで処理	Lambda@Edge、CloudFront Functions

エッジコンピューティング

ユーザーに近い場所（エッジロケーション）で処理を実行することで、レイテンシーを削減します。

サービス	実行場所	ユースケース
Lambda@Edge	CloudFrontエッジロケーション	リクエスト/レスポンスのカスタマイズ、A/Bテスト
CloudFront Functions	CloudFrontエッジロケーション	軽量な処理（ヘッダー操作、URLリダイレクト）
AWS Wavelength	5Gネットワークエッジ	超低レイテンシーが必要なモバイルアプリ
AWS Outposts	オンプレミス	ローカルでのAWSサービス実行

【エッジコンピューティングの効果】

従来（中央集中型）:
ユーザー（東京）───────────────→ サーバー（バージニア）
                  往復で大きなレイテンシー

エッジコンピューティング:
ユーザー（東京）──→ エッジ（東京）──→ サーバー（バージニア）
                  │
                  └─ 簡単な処理はここで完結
                     → レイテンシー大幅削減

試験頻出ポイント:

「ユーザーの近くで処理」「レイテンシー削減」→ Lambda@Edge、CloudFront Functions
「リクエストヘッダーの操作」「軽量な処理」→ CloudFront Functions（Lambda@Edgeより高速・低コスト）

3.6 キューイングとメッセージング

アプリケーション間の通信を疎結合にするためのサービスです。SQS（キューイング）とSNS（Pub/Sub）の2つのパターンがあります。

なぜ疎結合が重要か

疎結合とは、システムの各コンポーネントが互いに依存せず、独立して動作できる設計のことです。

観点	密結合	疎結合
障害の影響	1つのコンポーネントがダウンすると全体が停止	他のコンポーネントは動作を継続
スケーリング	全体を一緒にスケールする必要あり	コンポーネントごとに個別スケール可能
デプロイ	全体を同時にデプロイ	個別にデプロイ可能
開発	チーム間の調整が必要	チームが独立して開発可能

Amazon SQS（Simple Queue Service）

フルマネージドのメッセージキューサービスです。1対1のメッセージングに適しています。

キュータイプ	順序保証	スループット	重複排除
標準キュー	ベストエフォート	ほぼ無制限	なし
FIFOキュー	厳密な順序保証	3,000メッセージ/秒（バッチ）	あり

【SQSによるシステムの疎結合化】

密結合（直接接続）
┌────────┐        ┌────────┐
│Producer│───────→│Consumer│  ← Consumerがダウンすると
└────────┘        └────────┘    メッセージが失われる

疎結合（SQS経由）
┌────────┐   ┌─────┐   ┌────────┐
│Producer│──→│ SQS │──→│Consumer│  ← Consumerがダウンしても
└────────┘   └─────┘   └────────┘    メッセージはキューに残る

Amazon SNS（Simple Notification Service）

フルマネージドのPub/Sub（発行/購読）メッセージングサービスです。1対多のメッセージ配信に適しています。

特徴	説明
Pub/Subモデル	1つのメッセージを複数のサブスクライバーに配信
プッシュ型	メッセージを即座にサブスクライバーにプッシュ
配信先	Lambda、SQS、HTTP/S、Email、SMS、モバイルプッシュ
ファンアウト	1つのイベントで複数の処理を並列実行

【SNSのファンアウトパターン】

                    ┌─────────────┐
                    │    SNS      │
                    │   Topic     │
                    └──────┬──────┘
                           │ 1つのメッセージを
          ┌────────────────┼────────────────┐
          │                │                │
          ▼                ▼                ▼
    ┌──────────┐    ┌──────────┐    ┌──────────┐
    │  Lambda  │    │   SQS    │    │  Email   │
    │ (処理A)  │    │ (処理B)  │    │ (通知)   │
    └──────────┘    └──────────┘    └──────────┘

【SNS + SQSのファンアウト（よくあるパターン）】

注文イベント
     │
     ▼
┌─────────┐
│   SNS   │
│  Topic  │
└────┬────┘
     │
     ├───────────────┬───────────────┐
     ▼               ▼               ▼
┌─────────┐    ┌─────────┐    ┌─────────┐
│  SQS    │    │  SQS    │    │  SQS    │
│(在庫管理)│    │(配送処理)│    │(メール送信)│
└─────────┘    └─────────┘    └─────────┘
     │               │               │
     ▼               ▼               ▼
  在庫更新        配送手配       確認メール

※各SQSが独立して処理できるため、一部が遅延しても影響しない

SQS vs SNS vs Kinesis の使い分け

サービス	パターン	特徴	ユースケース
SQS	キュー（1対1）	メッセージはコンシューマーが取得後削除	非同期処理、ワーカー分散
SNS	Pub/Sub（1対多）	メッセージを複数サブスクライバーにプッシュ	イベント通知、ファンアウト
Kinesis	ストリーム（多対多）	大量データを複数コンシューマーがリアルタイム処理	クリックストリーム、ログ分析

試験頻出ポイント:

「順序が重要」「重複不可」→ SQS FIFOキュー
「高スループット」「順序は問わない」→ SQS標準キュー
「1つのイベントで複数の処理を実行」「ファンアウト」→ SNS + SQS
「リアルタイムのクリックストリーム分析」「複数のコンシューマー」→ Kinesis Data Streams（SQSではない）

4. データベースソリューション

4.1 データベースタイプの選択

AWSには様々なデータベースサービスがあり、ワークロードに応じて適切なものを選択することが重要です。

データベース選択フローチャート

                        ┌────────────────────────┐
                        │ どんなデータモデル？     │
                        └───────────┬────────────┘
                                    │
            ┌───────────────────────┼───────────────────────┐
            ▼                       ▼                       ▼
    ┌───────────────┐      ┌───────────────┐      ┌───────────────┐
    │ リレーショナル  │      │ キーバリュー    │      │ グラフ        │
    │ (テーブル形式)  │      │ /ドキュメント   │      │ (関係性)      │
    └───────┬───────┘      └───────┬───────┘      └───────┬───────┘
            │                      │                      │
            ▼                      ▼                      ▼
    ┌───────────────┐      ┌───────────────┐      ┌───────────────┐
    │ RDS / Aurora  │      │  DynamoDB     │      │   Neptune     │
    └───────────────┘      └───────────────┘      └───────────────┘

4.2 Amazon RDS

RDSは、リレーショナルデータベースのマネージドサービスです。

対応エンジン

MySQL、PostgreSQL、MariaDB
Oracle、SQL Server
Amazon Aurora

Multi-AZとリードレプリカの違い

項目	Multi-AZ	リードレプリカ
目的	高可用性（障害対策）	読み取りパフォーマンス向上
同期方式	同期レプリケーション	非同期レプリケーション
フェイルオーバー	自動	手動で昇格
読み取りトラフィック	スタンバイは使用不可	読み取り可能
配置	同一リージョン内の別AZ	同一/異なるリージョン

【Multi-AZの動作】

通常時:
┌──────────────┐         ┌──────────────┐
│  プライマリ    │ ──同期──→ │  スタンバイ   │
│  (アクティブ)  │         │  (待機中)     │
│   AZ-1        │         │   AZ-2       │
└──────────────┘         └──────────────┘

障害時:
┌──────────────┐         ┌──────────────┐
│  プライマリ    │    ×    │  スタンバイ   │
│  (停止)       │         │  → プライマリ  │
│   AZ-1        │         │  (自動昇格)   │
└──────────────┘         └──────────────┘

【リードレプリカの動作】

┌──────────────┐         ┌──────────────┐
│  プライマリ    │ ──非同期→ │ リードレプリカ │
│  (読み書き)   │         │  (読み取り専用) │
└──────────────┘         └──────────────┘
       ↑                        ↑
    書き込み                  読み取り
   リクエスト                リクエスト

プロビジョンドIOPS

RDSで高いI/Oパフォーマンスが必要な場合、プロビジョンドIOPS（io1）ストレージを選択します。

最大IOPS: 80,000（db.r5.24xlargeインスタンス時）
ユースケース: I/O集約型のワークロード、OLTP（Online Transaction Processing：ECサイトの注文処理など、多数の短いトランザクションを処理するシステム）

4.3 Amazon Aurora

AuroraはAWSがクラウド向けに設計した高性能リレーショナルデータベースです。

Auroraの特徴

特徴	説明
パフォーマンス	MySQLの5倍、PostgreSQLの3倍高速
ストレージ	最大128TB、自動拡張
レプリケーション	3つのAZに6つのコピー
可用性	99.99%の可用性
リードレプリカ	最大15個、フェイルオーバー可能

Aurora Serverless

トラフィックパターンが予測困難なワークロード向けのオンデマンドオプションです。

特徴: 使用量に応じて自動スケール、アイドル時は一時停止可能
ユースケース: 開発/テスト環境、断続的なワークロード

4.4 Amazon DynamoDB

DynamoDBは、フルマネージドのNoSQLデータベースです。

キャパシティーユニットの理解

ユニット	説明	計算方法
RCU（Read Capacity Unit）	読み取りキャパシティー	1 RCU = 4KBまでの強い整合性読み取り/秒
WCU（Write Capacity Unit）	書き込みキャパシティー	1 WCU = 1KBまでの書き込み/秒

【RCUの計算例】

項目サイズ: 6KB
読み取りタイプ: 強い整合性
必要なリクエスト数: 10リクエスト/秒

計算:
1. 項目サイズを4KBで切り上げ: 6KB → 8KB (2単位)
2. 1リクエストに必要なRCU: 2 RCU
3. 10リクエスト分: 2 × 10 = 20 RCU

※結果整合性読み取りなら半分の10 RCU

オンデマンドモード vs プロビジョンドモード

モード	課金方式	ユースケース
オンデマンド	リクエスト単位	予測困難なトラフィック、新規ワークロード
プロビジョンド	キャパシティー単位	予測可能なトラフィック、コスト最適化

試験頻出ポイント:
「タイムセール中にトランザクションが処理されない」→ オンデマンドモードに切り替え

DynamoDB Accelerator（DAX）

DAXは、DynamoDBのインメモリキャッシュサービスです。

特性	DAX	ElastiCache
レイテンシー	マイクロ秒	ミリ秒
統合	DynamoDB専用	汎用
設定	最小限の変更	アプリ改修必要

【DAXの仕組み】

アプリケーション
      │
      ▼
  ┌───────┐       ┌──────────┐
  │  DAX  │ ←───→ │ DynamoDB │
  │(キャッシュ)│       │          │
  └───────┘       └──────────┘

1. アプリがDAXにリクエスト
2. DAXにキャッシュがあれば即座に返す（マイクロ秒）
3. キャッシュミスの場合、DynamoDBに問い合わせ
4. 結果をキャッシュして返す

試験頻出ポイント:

「キーバリュー」「マイクロ秒のレイテンシー」「繰り返し読み込み」→ DynamoDB + DAX
「人気商品への繰り返しアクセス」「スロットリング」→ DAX

4.5 キャッシュ戦略

キャッシュとは、頻繁にアクセスされるデータを高速なメモリ上に一時保存し、データベースへのアクセスを減らすことでパフォーマンスを向上させる仕組みです。

Amazon ElastiCache

ElastiCacheは、インメモリキャッシュのマネージドサービスです。データをメモリ上に保持するため、ディスクベースのデータベースより桁違いに高速（ミリ秒単位）にデータを取得できます。

エンジン	特徴	ユースケース
Redis	データ永続化、レプリケーション、Pub/Sub対応	セッション管理、リーダーボード、リアルタイムランキング
Memcached	シンプル、マルチスレッド対応	単純なキー・バリューのキャッシュ

Redis vs Memcached の選択基準:

高度な機能（永続化、レプリケーション、ソート済みセット等）が必要 → Redis
単純なキャッシュで十分、マルチスレッドでスケールしたい → Memcached

キャッシュ戦略の比較

戦略	動作	メリット	デメリット
遅延読み込み（Lazy Loading）	キャッシュミス時にDBから読み込み、キャッシュに保存	必要なデータのみキャッシュ	初回アクセスが遅い、データが古くなる可能性
書き込みスルー（Write-Through）	DB書き込み時に同時にキャッシュも更新	キャッシュが常に最新	書き込みが遅い、使われないデータもキャッシュ
TTL（Time To Live）	一定時間経過後にキャッシュを無効化	古いデータを自動削除	適切なTTL設定が必要

【遅延読み込み】

1. アプリがキャッシュを確認
2. キャッシュミス → DBから読み込み
3. キャッシュに保存して返す

   アプリ
     │
     ▼ ①キャッシュ確認
  ┌──────┐
  │Cache │ ← ②ミス
  └──────┘
     │
     ▼ ③DBから読み込み
  ┌──────┐
  │  DB  │
  └──────┘
     │
     ▼ ④キャッシュに保存＆返却

【書き込みスルー】

1. アプリがデータを書き込み
2. DBとキャッシュに同時に書き込み

   アプリ
     │
     ▼ ①書き込み
  ┌──────┐ ←──┐
  │Cache │    │
  └──────┘    │ ②両方に書き込み
              │
  ┌──────┐ ←──┘
  │  DB  │
  └──────┘

試験頻出ポイント:
「データベースに書き込むたびにキャッシュを更新」「キャッシュが古くならない」→ 書き込みスルー

4.6 Amazon RDS Proxy

RDS Proxyは、データベース接続を効率的に管理するサービスです。

特徴: 接続プーリング、フェイルオーバー時間の短縮
ユースケース: Lambda関数からの接続、多数のクライアント接続

【RDS Proxyの効果】

Proxyなし:
┌───────┐   ┌───────┐   ┌───────┐
│Lambda1│──→│       │──→│       │
└───────┘   │       │   │       │
┌───────┐   │  DB   │   │ 接続  │ ← 接続が枯渇
│Lambda2│──→│       │   │ 多数  │
└───────┘   │       │   │       │
┌───────┐   │       │   │       │
│Lambda3│──→│       │──→│       │
└───────┘   └───────┘   └───────┘

Proxyあり:
┌───────┐   ┌───────┐   ┌───────┐
│Lambda1│──→│       │   │       │
└───────┘   │ Proxy │──→│  DB   │ ← 接続を効率的に再利用
┌───────┐   │       │   │       │
│Lambda2│──→│       │   │       │
└───────┘   │       │   │       │
┌───────┐   │       │   │       │
│Lambda3│──→│       │   │       │
└───────┘   └───────┘   └───────┘

4.7 データベース移行

AWS Database Migration Service（DMS）

DMSは、データベースを最小限のダウンタイムでAWSに移行するためのサービスです。

特徴	説明
継続的レプリケーション	移行中もソースDBを稼働させながらデータを同期
異種間移行	Oracle → PostgreSQL など異なるエンジン間の移行が可能
同種間移行	MySQL → MySQL など同じエンジン間の移行

移行タイプ

移行タイプ	説明	ユースケース
同種間移行（Homogeneous）	同じDBエンジン間	MySQL → Aurora MySQL
異種間移行（Heterogeneous）	異なるDBエンジン間	Oracle → PostgreSQL

【異種間移行の流れ】

┌──────────┐    ┌──────────┐    ┌──────────┐
│  Oracle  │    │   SCT    │    │PostgreSQL│
│ (ソース)  │───→│ (変換)   │───→│ (ターゲット)│
└──────────┘    └──────────┘    └──────────┘

SCT = Schema Conversion Tool
    スキーマとコードを自動変換

AWS Schema Conversion Tool（SCT）

異種間移行時に、スキーマ（テーブル定義）やストアドプロシージャ（データベース内に保存された再利用可能な処理手順）をターゲットDBに合わせて変換するツールです。

変換対象	説明
スキーマ	テーブル、インデックス、制約
コード	ストアドプロシージャ、トリガー、ビュー
アプリケーションSQL	埋め込みSQL文

試験頻出ポイント:

「Oracle → Aurora PostgreSQL」「最小限のダウンタイム」→ DMS + SCT
「MySQL → Aurora MySQL」（同種間）→ DMSのみ（SCT不要）

5. ネットワークアーキテクチャ

5.1 エッジネットワークサービス

Amazon CloudFront

CloudFrontは、グローバルなCDN（Content Delivery Network：コンテンツ配信ネットワーク）です。世界中に配置されたサーバー（エッジロケーション）にコンテンツをキャッシュし、ユーザーに最も近いサーバーからコンテンツを配信することで、高速な配信を実現します。

仕組み: 世界中のエッジロケーションにコンテンツをキャッシュ
対応コンテンツ: 静的コンテンツ、動的コンテンツ、ストリーミング
プロトコル: HTTP、HTTPS、WebSocket

【CloudFrontの仕組み】

ユーザー（日本）
      │
      ▼
┌──────────────────┐
│ エッジロケーション  │ ← キャッシュがあれば即座に返す
│  （東京）         │
└────────┬─────────┘
         │キャッシュミス時のみ
         ▼
┌──────────────────┐
│   オリジン        │
│ （S3、EC2など）   │
│  （バージニア）    │
└──────────────────┘

AWS Global Accelerator

Global Acceleratorは、AWSのグローバルネットワークを使用してアプリケーションの可用性とパフォーマンスを向上させるサービスです。

仕組み: 固定IPアドレス（Anycast IP：複数のサーバーが同じIPアドレスを持ち、最も近いサーバーに自動ルーティングされる技術）を提供し、最寄りのエッジロケーションからAWSバックボーンネットワーク経由でリクエストを転送
プロトコル: TCP、UDP

【Global Acceleratorの仕組み】

ユーザー
   │
   ▼
┌────────────────┐
│ エッジロケーション │
└───────┬────────┘
        │ AWSバックボーン
        │ ネットワーク経由
        ▼
┌────────────────┐
│  アプリケーション  │
│  （eu-central-1） │
└────────────────┘

※インターネットを通る時間を最小化

CloudFront vs Global Accelerator

項目	CloudFront	Global Accelerator
主な用途	コンテンツキャッシュ	パフォーマンス向上
キャッシュ	あり	なし
プロトコル	HTTP/HTTPS	TCP/UDP
IPアドレス	動的	固定（Anycast）
ユースケース	Webサイト、動画配信	ゲーム、VoIP、IoT

試験頻出ポイント:

「UDPを使用するオーディオストリーミング」「北米ユーザーのパフォーマンス改善」→ Global Accelerator
「静的コンテンツの配信」「HTTPS」→ CloudFront

5.2 ロードバランシング

Elastic Load Balancing（ELB）の種類

ロードバランサー	レイヤー	特徴	ユースケース
ALB（Application）	L7（HTTP/HTTPS）	パスベースルーティング、ホストベースルーティング	Webアプリケーション
NLB（Network）	L4（TCP/UDP）	超低レイテンシー、高スループット	ゲーム、IoT
GLB（Gateway）	L3（IP）	サードパーティアプライアンス統合	ファイアウォール、IDS/IPS
CLB（Classic）	L4/L7	レガシー	既存システムの維持

【ALBのパスベースルーティング】

                   ┌──────────────┐
                   │     ALB      │
                   └──────┬───────┘
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
        ▼                 ▼                 ▼
   /api/*            /images/*          /static/*
   ┌─────┐           ┌─────┐           ┌─────┐
   │API  │           │画像 │           │静的 │
   │サーバー│         │サーバー│         │コンテンツ│
   └─────┘           └─────┘           └─────┘

5.3 ネットワーク接続オプション

AWS Site-to-Site VPN

オンプレミスネットワークとAWS VPCをインターネット経由で暗号化接続します。

特徴	説明
スループット	最大1.25 Gbps（1トンネルあたり）
設定	素早くセットアップ可能
冗長性	2つのトンネルを提供

AWS Direct Connect

オンプレミスとAWSを専用回線で接続します。

特徴	説明
帯域幅	1 Gbps / 10 Gbps / 100 Gbps
レイテンシー	低く安定
セットアップ	数週間〜数ヶ月

VPNスループットの向上策

Site-to-Site VPNのスループット制限（1.25 Gbps）を超えたい場合：

【Transit Gateway + ECMP】

                    ┌──────────────┐
                    │Transit Gateway│
                    │   (ECMP有効)  │
                    └───────┬──────┘
                            │
         ┌──────────────────┼──────────────────┐
         │                  │                  │
    ┌────┴────┐        ┌────┴────┐        ┌────┴────┐
    │VPN接続1 │        │VPN接続2 │        │VPN接続3 │
    │1.25Gbps │        │1.25Gbps │        │1.25Gbps │
    └─────────┘        └─────────┘        └─────────┘
                            │
                       合計3.75 Gbps

※ECMP: Equal Cost Multi-Path（等コストマルチパス）
  複数のパスにトラフィックを分散

試験頻出ポイント:

「VPNスループットが不足」「帯域幅に余裕あり」→ Transit Gateway + ECMP + 追加VPN
「仮想プライベートゲートウェイでECMP」→ 不可（Transit Gatewayのみ対応）

VPCエンドポイント

VPCからAWSサービスへプライベート接続を提供します。

エンドポイントタイプ	対象サービス	特徴
ゲートウェイエンドポイント	S3、DynamoDB	無料、ルートテーブルに追加
インターフェースエンドポイント	その他多数のサービス	時間課金、ENI（Elastic Network Interface：仮想ネットワークカード）を作成

【VPCエンドポイントの効果】

エンドポイントなし:
┌──────────────┐
│    VPC       │
│  ┌────────┐  │     インターネット      ┌──────────┐
│  │  EC2   │──┼────────────────────────→│   S3     │
│  └────────┘  │   (パブリック経由)       └──────────┘
└──────────────┘

ゲートウェイエンドポイントあり:
┌──────────────┐
│    VPC       │     AWSネットワーク内    ┌──────────┐
│  ┌────────┐  │    ┌──────────────┐     │          │
│  │  EC2   │──┼───→│ エンドポイント │────→│   S3     │
│  └────────┘  │    └──────────────┘     │          │
└──────────────┘    (プライベート経由)    └──────────┘

試験頻出ポイント:
「インスタンスとAWSサービス間のトラフィックをプライベートに」→ VPCエンドポイント

5.4 ネットワーク設計の基礎

高パフォーマンスなネットワークを設計するために、VPC（Virtual Private Cloud：AWS上に作成する仮想ネットワーク）の基本構造を理解することが重要です。

VPCのサブネット設計

サブネットとは、VPCをさらに分割した小さなネットワーク領域です。セキュリティと可用性のために、用途別にサブネットを分けて設計します。

サブネットタイプ	特徴	配置するリソース
パブリックサブネット	インターネットへの直接アクセス可能（パブリックIPを持つ）	ALB、NAT Gateway、踏み台サーバー
プライベートサブネット	インターネットへの直接アクセス不可（外部から直接到達できない）	EC2（アプリ）、RDS、ElastiCache

なぜサブネットを分けるのか？

セキュリティ: データベースなど重要なリソースをプライベートサブネットに配置し、外部からの攻撃を防ぐ
可用性: 複数のAZ（Availability Zone）にサブネットを配置し、障害時も継続稼働
管理のしやすさ: 用途別に分けることで、セキュリティグループやルートテーブルの設定がシンプルに

【3層アーキテクチャのサブネット構成】

┌─────────────────────────────────────────────────────────┐
│                        VPC                             │
│  ┌─────────────────────┐  ┌─────────────────────┐     │
│  │  パブリックサブネット   │  │  パブリックサブネット   │     │
│  │      (AZ-1)         │  │      (AZ-2)         │     │
│  │  ┌───────────────┐  │  │  ┌───────────────┐  │     │
│  │  │     ALB       │  │  │  │     ALB       │  │     │
│  │  │  NAT Gateway  │  │  │  │  NAT Gateway  │  │     │
│  │  └───────────────┘  │  │  └───────────────┘  │     │
│  └─────────────────────┘  └─────────────────────┘     │
│                                                        │
│  ┌─────────────────────┐  ┌─────────────────────┐     │
│  │ プライベートサブネット  │  │ プライベートサブネット  │     │
│  │   (アプリ層 AZ-1)    │  │   (アプリ層 AZ-2)    │     │
│  │  ┌───────────────┐  │  │  ┌───────────────┐  │     │
│  │  │     EC2       │  │  │  │     EC2       │  │     │
│  │  └───────────────┘  │  │  └───────────────┘  │     │
│  └─────────────────────┘  └─────────────────────┘     │
│                                                        │
│  ┌─────────────────────┐  ┌─────────────────────┐     │
│  │ プライベートサブネット  │  │ プライベートサブネット  │     │
│  │    (DB層 AZ-1)      │  │    (DB層 AZ-2)      │     │
│  │  ┌───────────────┐  │  │  ┌───────────────┐  │     │
│  │  │     RDS       │  │  │  │  RDS (待機)   │  │     │
│  │  └───────────────┘  │  │  └───────────────┘  │     │
│  └─────────────────────┘  └─────────────────────┘     │
└─────────────────────────────────────────────────────────┘

ルートテーブルとルーティング

ルートテーブルとは、ネットワークトラフィックの経路を決定する「道案内表」のようなものです。サブネットごとに関連付けられ、「この宛先に行きたい場合はこの経路を通れ」というルールを定義します。

宛先	ターゲット	用途
VPC CIDR	local	VPC内通信（VPC内のリソース間通信は自動でルーティング）
0.0.0.0/0	Internet Gateway	インターネットへ（パブリックサブネット用）
0.0.0.0/0	NAT Gateway	インターネットへ（プライベートサブネット用、外向き通信のみ）
S3プレフィックス	VPC Endpoint	S3へのプライベートアクセス（インターネットを経由しない）

【ルートテーブルの動作イメージ】

パブリックサブネットのルートテーブル:
┌─────────────────┬───────────────────┐
│     宛先        │    ターゲット      │
├─────────────────┼───────────────────┤
│ 10.0.0.0/16     │ local             │ ← VPC内通信
│ 0.0.0.0/0       │ Internet Gateway  │ ← それ以外はインターネットへ
└─────────────────┴───────────────────┘

プライベートサブネットのルートテーブル:
┌─────────────────┬───────────────────┐
│     宛先        │    ターゲット      │
├─────────────────┼───────────────────┤
│ 10.0.0.0/16     │ local             │ ← VPC内通信
│ 0.0.0.0/0       │ NAT Gateway       │ ← 外部へはNAT経由（戻りのみ許可）
└─────────────────┴───────────────────┘

パブリックとプライベートの違いのポイント:

パブリックサブネット: Internet Gatewayへのルートがある → 外部から直接アクセス可能
プライベートサブネット: NAT Gateway経由 → 外部からの直接アクセス不可（セキュリティ向上）

拡張ネットワーキング

EC2インスタンスのネットワークパフォーマンスを向上させる機能です。

機能	説明	効果
ENA（Elastic Network Adapter）	高性能ネットワークインターフェース	最大100 Gbps
EFA（Elastic Fabric Adapter）	HPC（High Performance Computing：科学技術計算や大規模シミュレーションなどの高性能計算）向けネットワークインターフェース	低レイテンシー、高スループット

5.5 配置グループ（Placement Groups）

EC2インスタンスの物理的な配置を制御し、パフォーマンスを最適化します。

なぜ配置グループが必要か

AWSのデータセンターでは、EC2インスタンスは通常ランダムに配置されます。しかし、ワークロードによっては「インスタンス同士を近くに置きたい」または「障害に備えて離して置きたい」というニーズがあります。配置グループは、この物理的な配置をユーザーが制御するための機能です。

タイプ	特徴	ユースケース
クラスター	単一AZ内で低レイテンシー	HPC、機械学習
スプレッド	異なるハードウェアに分散	重要なアプリケーション
パーティション	論理的なグループに分散	HDFS、Cassandra

各タイプの考え方:

クラスター: 「通信速度が最優先。同じラックに詰め込む」→ 1つのラックが故障すると全滅するリスクあり
スプレッド: 「可用性が最優先。1台ずつ別のラックに分散」→ 通信速度は犠牲になるが障害に強い
パーティション: 「グループ単位で分散。同じグループ内は近くに配置」→ 分散DBなどで、レプリカセットごとに分ける

【配置グループの違い】

クラスター配置グループ:
┌─────────────────────────────┐
│        同一ラック           │
│  ┌────┐ ┌────┐ ┌────┐      │
│  │EC2 │ │EC2 │ │EC2 │      │  ← 低レイテンシー
│  └────┘ └────┘ └────┘      │    高スループット
└─────────────────────────────┘

スプレッド配置グループ:
┌────────┐  ┌────────┐  ┌────────┐
│ラック1  │  │ラック2  │  │ラック3  │
│ ┌────┐ │  │ ┌────┐ │  │ ┌────┐ │  ← 障害の分離
│ │EC2 │ │  │ │EC2 │ │  │ │EC2 │ │    AZ内7インスタンスまで
│ └────┘ │  │ └────┘ │  │ └────┘ │
└────────┘  └────────┘  └────────┘

試験頻出ポイント:

「HPC」「ノード間通信が重要」→ クラスター配置グループ
「単一障害点の排除」「可用性重視」→ スプレッド配置グループ

6. データ取り込みと変換

6.1 ストリーミングデータ処理

Amazon Kinesisファミリー

【Kinesisサービスの使い分け】

                   ストリーミングデータ
                         │
                         ▼
              ┌──────────────────────┐
              │ Kinesis Data Streams │ ← データの収集・保持
              └──────────┬───────────┘
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
    ┌──────────┐   ┌──────────┐   ┌──────────┐
    │Data      │   │Data      │   │Lambda    │
    │Firehose  │   │Analytics │   │          │
    │          │   │          │   │          │
    │・S3へ配信 │   │・SQLで分析│   │・カスタム │
    │・Redshift│   │・リアル   │   │  処理    │
    │・変換    │   │  タイム   │   │          │
    └──────────┘   └──────────┘   └──────────┘

Kinesisサービス比較

サービス	目的	特徴
Kinesis Data Streams	データ収集・ストリーミング	カスタム処理、複数コンシューマー、デフォルト24時間保持
Kinesis Data Firehose	データ配信	S3、Redshift、OpenSearchへ自動配信、変換可能
Kinesis Data Analytics	リアルタイム分析	SQLでストリームデータを分析

試験頻出ポイント:

「毎秒50,000リクエスト」「クリックストリーム」「複数アプリで分析」→ Kinesis Data Streams
「ほぼリアルタイムでデータクエリ」「SQLで分析」→ Kinesis Data Analytics
「S3に自動配信」「変換」→ Kinesis Data Firehose

【サンプル問題の正解パターン】

ほぼリアルタイムのレコメンデーション:
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│Kinesis Data │────→│Kinesis Data │────→│Kinesis Data │
│Streams      │     │Analytics    │     │Firehose     │
│(データ収集)  │     │(SQLで分析)   │     │(S3に保存)    │
└─────────────┘     └─────────────┘     └─────────────┘

6.2 ETL（Extract・Transform・Load：抽出・変換・ロード）

ETLとは、データを**抽出（Extract）→変換（Transform）→ロード（Load）**する一連のデータ処理パイプラインのことです。例えば、複数のデータベースからデータを抽出し、分析しやすい形式に変換して、データウェアハウスにロードするといった処理を行います。

AWS Glue

Glueは、フルマネージドのETLサービスです。

コンポーネント	説明
Data Catalog	データソースのメタデータ（テーブル名、カラム名、データ型など）を一元管理する「データの目録」
Crawler	S3やRDSなどを自動スキャンし、スキーマ（データの構造）を検出してData Catalogに登録
ETLジョブ	データの変換処理（例：CSV→Parquet変換）を実行するプログラム

【Glueの処理フロー】

1. Crawlerがデータソースをスキャン
   S3バケット ──→ Crawler ──→ Data Catalog
   (CSVファイル)    (自動検出)   (スキーマ登録)

2. ETLジョブで変換
   S3(CSV) ──→ ETLジョブ ──→ S3(Parquet)
                (変換処理)

3. Athenaで分析
   Athena ──→ Data Catalog ──→ S3(Parquet)
          (メタデータ参照)    (クエリ実行)

データ形式変換の重要性

Athenaなどでクエリパフォーマンスを向上させるには、データ形式の変換が重要です。

形式	特徴	ユースケース
CSV	行指向、テキスト	汎用的なデータ交換
JSON	半構造化	API、ログ
Parquet	列指向、圧縮	分析クエリに最適
ORC	列指向、圧縮	Hiveワークロードに最適

【列指向フォーマットの利点】

行指向（CSV）:
┌─────┬─────┬─────┬─────┐
│ id  │name │age  │city │ → 1行目
├─────┼─────┼─────┼─────┤
│ id  │name │age  │city │ → 2行目  全列を読む必要あり
├─────┼─────┼─────┼─────┤
│ id  │name │age  │city │ → 3行目
└─────┴─────┴─────┴─────┘

列指向（Parquet）:
┌─────────────────┐
│ id: 1, 2, 3     │ ← 必要な列だけ読める
├─────────────────┤
│ name: A, B, C   │   SELECT city FROM ... では
├─────────────────┤   city列だけ読む
│ age: 20, 30, 40 │
├─────────────────┤
│ city: X, Y, Z   │ ← この列だけ読む
└─────────────────┘

試験頻出ポイント:
「Athenaのクエリパフォーマンス向上」「大規模データ分析」→ Glueで CSV → Parquet 変換

6.3 データ分析サービス

Amazon Athena

S3上のデータに対してSQLクエリを実行できるサーバーレスサービスです。

特徴	説明
課金	スキャンしたデータ量に応じた課金
パフォーマンス最適化	パーティショニング、列指向フォーマット

パーティショニングによる最適化

パーティショニングとは、データをある基準（日付、地域など）で分割して保存することです。本棚で例えると、すべての本を1つの棚に入れるのではなく、「2024年の本」「2025年の本」のように分けて整理するイメージです。これにより、特定のデータを探すときに全体を調べる必要がなくなります。

【パーティショニングの効果】

パーティションなし:
s3://bucket/data/
├── file1.parquet
├── file2.parquet
├── file3.parquet  → すべてスキャン
└── ...

パーティションあり（日付・リージョン別）:
s3://bucket/data/
├── year=2024/month=01/region=us/
├── year=2024/month=01/region=jp/
├── year=2024/month=02/region=us/
└── ...

WHERE year='2024' AND month='01' AND region='jp'
→ 該当パーティションのみスキャン（コスト・時間削減）

試験頻出ポイント:
「Athenaのクエリが遅い」「失敗する」→ パーティショニング + Parquet形式

Amazon Redshift

Redshiftは、ペタバイト規模のデータウェアハウスサービスです。

特徴	説明
列指向ストレージ	分析クエリに最適化
大規模並列処理（MPP）	複数ノードで並列クエリ実行
スケーラビリティ	ペタバイト規模のデータを処理
Redshift Spectrum	S3上のデータに直接クエリ（データロード不要）

【Athena vs Redshiftの使い分け】

┌──────────────────────────────────────────────────────────┐
│                    データ分析の選択                       │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  Athena                    Redshift                      │
│  ・アドホック（単発）クエリ    ・定期的な分析                │
│  ・サーバーレス              ・クラスター管理              │
│  ・S3にデータを配置          ・データをロード              │
│  ・スキャン量課金            ・インスタンス時間課金         │
│  ・小〜中規模                ・大規模（PB級）              │
│                                                          │
└──────────────────────────────────────────────────────────┘

AWS Lake Formation

データレイクとは

データレイクは、構造化データ（RDBのテーブルなど）と非構造化データ（ログ、画像、動画など）をそのままの形で大量に蓄積できる「データの湖」です。従来のデータウェアハウス（整理された「倉庫」）とは異なり、データを加工せずにまず貯めておき、後から必要に応じて分析できます。

Lake Formationは、このデータレイクの構築・管理を簡素化するサービスです。

機能	説明
データカタログ	データソースのメタデータを一元管理
アクセス制御	細粒度のセキュリティポリシー
データ取り込み	様々なソースからデータを収集
変換	データのクレンジングと変換

【データレイクアーキテクチャ】

データソース                    データレイク              分析
┌─────────┐                    ┌─────────┐          ┌─────────┐
│   RDS   │───┐                │         │          │ Athena  │
└─────────┘   │                │         │    ┌────→│         │
┌─────────┐   │  ┌──────────┐  │   S3    │    │     └─────────┘
│ DynamoDB│───┼─→│   Lake   │─→│         │────┤     ┌─────────┐
└─────────┘   │  │Formation │  │(Raw/    │    ├────→│Redshift │
┌─────────┐   │  └──────────┘  │Curated) │    │     │Spectrum │
│ On-prem │───┘                │         │    │     └─────────┘
└─────────┘                    └─────────┘    │     ┌─────────┐
                                              └────→│QuickSight│
                                                    └─────────┘

Amazon QuickSight

QuickSightは、サーバーレスのビジネスインテリジェンス（BI：データを可視化して意思決定を支援するシステム）サービスです。グラフやダッシュボードを簡単に作成できます。

特徴	説明
サーバーレス	インフラ管理不要
SPICE	Super-fast Parallel In-memory Calculation Engineの略。データをメモリ上にキャッシュして高速にクエリを実行するエンジン
データソース	S3、RDS、Redshift、Athenaなど多数対応
機械学習	異常検知、予測などのML機能内蔵

SPICEのメリット: データソースに毎回クエリを投げる代わりに、SPICEにデータをインポートしておくことで、ダッシュボードの表示が高速になり、データソースへの負荷も軽減できます。

試験頻出ポイント:

「ペタバイト規模のデータ分析」「定期的なレポート」→ Redshift
「S3のデータにアドホッククエリ」「サーバーレス」→ Athena
「データレイクの構築」「アクセス制御」→ Lake Formation
「ダッシュボード作成」「BI」→ QuickSight

6.4 データ取り込みパターン

データの取り込み方法は、データの特性と要件によって選択します。

取り込み頻度による分類

パターン	頻度	サービス	ユースケース
バッチ	時間〜日単位	Glue、EMR、DataSync	日次レポート、定期的なETL
マイクロバッチ	分〜時間単位	Kinesis Firehose	ニアリアルタイム分析
ストリーミング	リアルタイム	Kinesis Streams、MSK	リアルタイムダッシュボード

【データ取り込みパターンの選択】

                 ┌─────────────────────────────────────┐
                 │        データの新鮮さの要件          │
                 └─────────────────────────────────────┘
                           │
         ┌─────────────────┼─────────────────┐
         ▼                 ▼                 ▼
    ┌─────────┐      ┌─────────┐      ┌─────────┐
    │ 日〜週   │      │ 分〜時間 │      │リアルタイム│
    │ (バッチ) │      │(マイクロ)│      │(ストリーム)│
    └────┬────┘      └────┬────┘      └────┬────┘
         │                │                │
         ▼                ▼                ▼
    ┌─────────┐      ┌─────────┐      ┌─────────┐
    │  Glue   │      │Firehose │      │Kinesis  │
    │  EMR    │      │         │      │Streams  │
    └─────────┘      └─────────┘      └─────────┘

6.5 データ転送サービス

AWS DataSync

特徴	説明
用途	オンプレミスとAWS間、AWS内の大量データ転送
転送先	S3、EFS、FSx
機能	暗号化、帯域幅制限、データ検証

AWS Transfer Family

プロトコル	ユースケース
SFTP	セキュアなファイル転送
FTPS	既存FTPシステムとの互換
FTP	レガシーシステム

6.6 取り込みアクセスポイントへのセキュアなアクセス

データ取り込みサービス（Kinesis、S3など）へのアクセスをセキュアに行うためには、VPCエンドポイントの活用が重要です。

VPCエンドポイントによるプライベートアクセス

VPC内のリソースからデータ取り込みサービスにアクセスする際、インターネットを経由せずにAWSのプライベートネットワーク内で通信できます。

サービス	エンドポイントタイプ	特徴
S3	ゲートウェイエンドポイント	無料、ルートテーブルに追加
Kinesis Data Streams	インターフェースエンドポイント	ENIを作成、時間課金
Kinesis Data Firehose	インターフェースエンドポイント	ENIを作成、時間課金

【VPCエンドポイント経由のデータ取り込み】

インターネット経由（非推奨）:
┌──────────────┐
│    VPC       │
│  ┌────────┐  │     インターネット      ┌──────────┐
│  │Producer│──┼──────────────────────→│ Kinesis  │
│  └────────┘  │   (パブリック経由)     └──────────┘
└──────────────┘
     ↑ セキュリティリスク、レイテンシー増加

VPCエンドポイント経由（推奨）:
┌──────────────────────────────────────────────────┐
│                      VPC                         │
│  ┌────────┐    ┌─────────────────┐              │
│  │Producer│───→│ インターフェース │              │
│  └────────┘    │ エンドポイント   │              │
│                └────────┬────────┘              │
└─────────────────────────┼────────────────────────┘
                          │ AWSプライベート
                          │ ネットワーク
                          ▼
                   ┌──────────┐
                   │ Kinesis  │
                   └──────────┘
     ↑ セキュア、低レイテンシー

セキュアなアクセスのベストプラクティス

観点	推奨事項
ネットワーク	VPCエンドポイントを使用してプライベート接続
暗号化	転送中のデータはTLS暗号化を使用
アクセス制御	IAMポリシーとリソースポリシーで最小権限を付与
監査	CloudTrailでAPIコールを記録

エンドポイントポリシー

VPCエンドポイントにはポリシーを設定でき、アクセスできるリソースを制限できます。

【エンドポイントポリシーの例】

VPCエンドポイント経由でアクセスできるバケットを限定：
{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-data-bucket/*"
    }
  ]
}

→ 指定したバケットのみアクセス可能
   他のバケットへのアクセスはブロック

試験頻出ポイント:

「プライベートサブネットからKinesisへセキュアにアクセス」→ インターフェースVPCエンドポイント
「S3へのアクセスをVPC内に限定」→ ゲートウェイエンドポイント + S3バケットポリシー
「インターネットを経由せずにデータ取り込み」→ VPCエンドポイント

6.7 Amazon MSK（Managed Streaming for Apache Kafka）

Amazon MSKは、Apache Kafkaをフルマネージドで提供するサービスです。Kinesisと並ぶストリーミングデータ処理の選択肢として、試験でも問われることがあります。

Apache Kafkaとは

Apache Kafkaは、オープンソースの分散ストリーミングプラットフォームです。大量のリアルタイムデータを高スループットで処理できます。

特徴	説明
分散システム	複数のブローカーでクラスターを構成
高スループット	毎秒数百万メッセージを処理可能
永続化	メッセージをディスクに保存
コンシューマーグループ	複数のコンシューマーが並列処理

MSK vs Kinesis Data Streams

項目	Amazon MSK	Kinesis Data Streams
基盤	Apache Kafka（オープンソース）	AWS独自
移行性	既存Kafkaアプリを移行しやすい	AWS専用
管理	クラスター管理が必要	フルマネージド
スケーリング	ブローカー追加で手動	シャード追加で柔軟
保持期間	無制限（ストレージ容量まで）	デフォルト24時間、最大365日
統合	Kafkaエコシステム	AWSサービスとの統合が容易

【MSKアーキテクチャ】

┌──────────────────────────────────────────────────────────┐
│                     Amazon MSK クラスター                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐      │
│  │  ブローカー1  │  │  ブローカー2  │  │  ブローカー3  │      │
│  │    (AZ-1)   │  │    (AZ-2)   │  │    (AZ-3)   │      │
│  └─────────────┘  └─────────────┘  └─────────────┘      │
│                                                          │
│  ┌─────────────────────────────────────────────────┐    │
│  │              Apache ZooKeeper                    │    │
│  │        （クラスター管理、メタデータ）              │    │
│  └─────────────────────────────────────────────────┘    │
└──────────────────────────────────────────────────────────┘
         │                    │
         ▼                    ▼
   ┌──────────┐         ┌──────────┐
   │ Producer │         │ Consumer │
   │(データ送信)│         │(データ受信)│
   └──────────┘         └──────────┘

MSKを選択するケース

シナリオ	推奨サービス	理由
既存のKafkaアプリケーションをAWSに移行	MSK	コード変更最小限
Kafkaエコシステム（Kafka Connect等）を活用	MSK	互換性が高い
AWSサービスとの統合を優先	Kinesis	統合が容易
サーバーレスで運用したい	Kinesis	管理負担が少ない
メッセージを長期間保持したい	MSK	無制限保持が可能

MSK Serverless

MSK Serverlessは、クラスター管理なしでKafkaを利用できるオプションです。

特徴	説明
自動スケーリング	トラフィックに応じて自動調整
課金	使用したリソースのみ
管理	ブローカー管理不要

試験頻出ポイント:

「既存のKafkaアプリケーションをAWSに移行」→ Amazon MSK
「Kafka Connectを使用したいKafkaエコシステム活用」→ Amazon MSK
「AWSネイティブでサーバーレス」「運用負担軽減」→ Kinesis Data Streams
「メッセージの長期保持」→ MSK（保持期間無制限）