#1 Compute / Container / Storage / Network 編
#2 Data / Analytics / AI・ML / Integration 編
本記事
#3 Security / Governance / Migration / Operations 編
鋭意制作中
本記事のねらい
データ基盤・分析・生成AI・システム間連携の主要サービスを、ユースケースから逆引きできるように整理する。
「なぜそれを選ぶのか」「どの構成が最小で実用なのか」を明確にする。
対象読者
- データ分析/可視化/機械学習/生成AIまでを一気に俯瞰したい設計者・実装者
- オンプレ・他クラウド経験者で、AWS のデータ/AI 領域の地図を短時間で掴みたい読者
到達点（この記事で分かること）
- OLTP/OLAP/ストリーム/検索/生成AI/RAG の各用途から選ぶ判断軸
- 主要サービスの使い分けと落とし穴、最小構成テンプレート
- 30 日で回せる学習ロードマップ
断り書き・更新方針
- 本記事は 2025 年 7 月時点の情報に基づく。今後のアップデートは適宜追記する。
- 詳細仕様は公式ドキュメントを一次情報として確認のうえ設計判断を行うこと。
目次
- まずはこれ：用途別の推奨サービス早見表
- データ設計の出発点：選定フレーム
- Database（OLTP/キャッシュ）の選び方
- Analytics（データレイク/ウェアハウス/可視化）の選び方
- Streaming / Integration（リアルタイムと連携）の選び方
- Search / Vector / RAG 構成の選び方
- AI・ML（学習・推論・生成AI）の選び方
- 最小構成テンプレート
- 設計チェックリスト（落とし穴対策）
- 学習ロードマップ（30 日）
- 次回予告
- 付録：用語ミニ辞典
まずはこれ：用途別の推奨サービス早見表
| 用途 | 第一想起（推奨） | 代替候補 | 判断の目安 |
|---|---|---|---|
| トランザクション（OLTP） | Aurora MySQL/PostgreSQL | RDS 各種 / DynamoDB | RDB 必須なら Aurora、高可用・自動修復・スケール。ワークロードが単純でアクセスパターン固定なら DynamoDB |
| キー・バリュー/セッション | DynamoDB | ElastiCache / Aurora Serverless | ミリ秒以下・スケール・運用最小化を優先 |
| インメモリ高速化 | ElastiCache for Redis | Memcached / DynamoDB DAX | レイテンシ最優先、Pub/Sub・ストリームも可 |
| データレイク | S3 + Glue + Lake Formation + Athena | EMR / Redshift Spectrum | ロックイン少・コスパ・スキーマオンリード |
| DWH（集計・BI 基盤） | Redshift（RA3） | Athena / BigQuery 連携（外部） | 高並列・高速集計・ETL 定着前提なら Redshift |
| 可視化/BI | QuickSight | 外部 BI（Tableau/Looker 等） | サーバーレス運用・SPICE・コスト効率 |
| ログ/全文検索 | OpenSearch Service | CloudWatch Logs Insights / Athena | 検索/集約/可視化の一体運用 |
| ストリーム（イベント） | Kinesis Data Streams + Firehose | MSK（Kafka） / EventBridge | マネージド優先は Kinesis、Kafka 互換要件なら MSK |
| バッチ ETL/ELT | Glue（Spark） | EMR / ECS Batch / Lambda | 管理最小化は Glue、自由度優先は EMR |
| システム連携（SaaS/DB移行） | AppFlow / DMS | Data Pipeline（旧） | SaaS データは AppFlow、DB/移行は DMS |
| メッセージング | SQS / SNS / EventBridge | MQ（ActiveMQ/RabbitMQ） | 疎結合・再試行・DLQ を前提に設計 |
| 生成 AI API | Bedrock | SageMaker JumpStart / 独自ホスティング | マネージド・複数モデルの一元利用 |
| ML 学習/運用 | SageMaker | 自前 K8s + Kubeflow | 実験〜本番までの MLOps を一気通貫 |
データ設計の出発点：選定フレーム
- 処理性質：OLTP（行志向）か OLAP（列志向/集計）か、バッチかストリームか
- スキーマ：スキーマオンライト（RDB/DWH）か、スキーマオンリード（データレイク）か
- SLA/SLI/SLO：スループット、レイテンシ、同時実行、RTO/RPO、可用性
- 運用責務：スケール/パッチ/ノード運用をどこまで持つか
- コスト構造：ストレージ・スキャン量・圧縮/フォーマット（Parquet/ORC）を最適化できるか
- ガバナンス：カラムレベル・行レベル制御、監査、ラインジング（データ来歴）
Database（OLTP/キャッシュ）の選び方
| サービス | 使うとき | 強み | 注意・落とし穴 | 代表組合せ |
|---|---|---|---|---|
| Aurora | RDB 必須・高可用/高スループット | 分散ストレージ・フェイルオーバ高速 | 物理設計/接続管理は必要 | ALB/ECS → Aurora |
| RDS（MySQL/PG/Oracle/SQL Server） | 既存互換/ライセンス要件 | 運用簡易 | スケール柔軟性は Aurora未満 | Lift & Shift |
| DynamoDB | アクセスパターン固定・超スケール | サーバーレス・従量・GSI | パーティション/ホットキー | API GW/Lambda → DDB |
| ElastiCache for Redis | キャッシュ/ランキング/PubSub | ミリ秒未満・データ構造 | 永続要件は別途 | ECS/EC2 → Redis |
DynamoDB 設計要点
- アクセスパターン起点で 単一テーブル設計 を検討する
- On-Demand と Provisioned + Auto Scaling のコスト/制御を比較する
- ホットパーティション回避、TTL、DLQ（Streams + Lambda）を前提化する
Analytics（データレイク/ウェアハウス/可視化）の選び方
| カテゴリ | サービス | 使うとき | 強み | 注意 |
|---|---|---|---|---|
| データレイク | S3 + Lake Formation + Glue + Athena | マルチソースの集約/分析 | ロックイン少/コスパ/ガバナンス | 小ファイル地獄、権限レイヤの複雑さ |
| DWH | Redshift（RA3） | 高速集計/BI | MVs/自動最適化/並列 | WLM 設計/ロード設計 |
| ETL/ELT | Glue（Spark） | バッチ変換/スキーマ管理 | サーバーレス | ジョブチューニング |
| ビジュアライズ | QuickSight | 軽量BI/サーバーレス | SPICE/コスト効率 | データモデリングの設計力 |
| 検索/ログ | OpenSearch Service | 検索/可視化/Kibana系 | 近似ベクタ/ログ集約 | ノード/ストレージ設計 |
データレイク最小パターン
-
着信：S3
raw/に到着（CloudTrail/アプリ/外部SaaS） -
整形：Glue（Spark）で Parquet 化、partition（
dt=YYYY-MM-DD等） - 権限：Lake Formation でテーブル/列レベルのアクセス制御
- クエリ：Athena（Presto）でアドホック分析
- 可視化：QuickSight から Athena/Redshift に接続
Streaming / Integration（リアルタイムと連携）の選び方
| 用途 | 推奨 | 代替 | 目安 |
|---|---|---|---|
| ストリーム取り込み | Kinesis Data Streams | MSK | Kafka 互換要件なしなら Kinesis が速い |
| ストリーム→蓄積 | Firehose → S3/Redshift/OpenSearch | Lambda 自作 | 変換/圧縮/バッファをマネージド化 |
| イベント連携 | EventBridge | SNS/SQS | SaaS/サービス間の疎結合連携 |
| キューイング | SQS | MQ | 既定で高スケール・DLQ・可用 |
| DB/システム移行 | DMS | AppFlow（SaaS） | CDC/移行/近リアルタイム複製 |
| SaaS 連携 | AppFlow | 各種 SDK | Salesforce/Slack 等の管理型 ETL |
Kinesis の設計ポイント
- スループットは シャード数 × 1 MB/s（書込） を基準に見積もる
- バックプレッシャ対策に バッファ/再試行/失敗出力（S3 DLQ） を設計に入れる
- 取り込み後のフォーマットは Parquet + 圧縮 でスキャンコスト削減
Search / Vector / RAG 構成の選び方
- キーワード検索/ログ分析：OpenSearch（インデクシング＋可視化）
- ベクタ検索（類似検索）：OpenSearch のベクタ機能、Aurora PostgreSQL + pgvector、ユースケースによっては DynamoDB + 外部ベクタ
- RAG（生成 AI × 検索拡張）：S3（データ） → 切片化/埋め込み → ベクタストア → Bedrock 推論
| 構成 | 使うとき | メリット | 注意 |
|---|---|---|---|
| OpenSearch（ベクタ） | 文書/ログも一体管理 | 一元化・可視化 | ノード設計/コスト |
| Aurora PG + pgvector | 既存 RDB と統合 | トランザクション連携 | ストレージ/索引設計 |
| S3 + 外部埋め込み + Bedrock | 低ロックイン | 柔軟 | 前処理/権限設計 |
AI・ML（学習・推論・生成AI）の選び方
| カテゴリ | サービス | 使うとき | 強み | 注意 |
|---|---|---|---|---|
| 生成AI API | Bedrock | モデル利用/RAG/ツール実行 | 複数モデル/ガバナンス | 入出力とコスト管理 |
| ML ライフサイクル | SageMaker | 実験〜本番/MLOps | Studio/Pipelines/Feature Store | 学習コスト/実験管理 |
| 機能特化 AI | Comprehend/Translate/Transcribe/Rekognition/Textract/Kendra 等 | 文書・翻訳・音声・画像・検索 | 学習不要/導入が速い | 使途に合わせ精度検証 |
RAG on AWS の型
- 文書格納：S3（原本）
- 前処理：Glue or Lambda で分割・前処理
- 埋め込み：SageMaker or Bedrock の埋め込みモデル
- ベクタ格納：OpenSearch（ベクタ） or Aurora pgvector
- 推論：API Gateway + Lambda + Bedrock（LLM）
- 監査：CloudWatch Logs/X-Ray、データアクセスは Lake Formation と IAM で制御
最小構成テンプレート
A. データレイク（S3 + Glue + Lake Formation + Athena）
# CloudFormation（概念抜粋）
Resources:
RawBucket:
Type: AWS::S3::Bucket
GlueDatabase:
Type: AWS::Glue::Database
Properties: { CatalogId: !Ref AWS::AccountId, DatabaseInput: { Name: "lake_raw" } }
GlueCrawler:
Type: AWS::Glue::Crawler
Properties:
Role: arn:aws:iam::123456789012:role/glue-role
DatabaseName: lake_raw
Targets: { S3Targets: [ { Path: !Sub "s3://${RawBucket}/raw/" } ] }
# Athena/Lake Formation 設定は別リソースで付与
B. ストリーム → 蓄積（Kinesis + Firehose → S3 / OpenSearch）
# Terraform（概念抜粋）
resource "aws_kinesis_stream" "ingest" { shard_count = 2 }
resource "aws_kinesis_firehose_delivery_stream" "to_s3" {
destination = "extended_s3"
extended_s3_configuration {
bucket_arn = aws_s3_bucket.data.arn
buffering_interval = 60
compression_format = "GZIP"
}
}
C. RAG API（API GW + Lambda + Bedrock + OpenSearch）
# 疑似フロー
[API Gateway] -> [Lambda Router]
├─ /embed : S3 取込 → 分割 → 埋め込み → OpenSearch へ upsert
└─ /chat : クエリ → ベクタ検索 → コンテキスト付で Bedrock 推論
設計チェックリスト（落とし穴対策）
- S3 小ファイル問題：Parquet/ORC + まとまったサイズで出力。ライフサイクルで階層化。
- 権限レイヤの衝突：IAM + S3 ポリシー + Lake Formation 権限の整合を確認。
- Athena スキャンコスト：圧縮・列指向・パーティション・プルーニング。
- Redshift ロード：COPY の圧縮・列順・ソートキー、WLM/キュー設計。
- Kinesis シャード不足：スループット見積とアラーム、再送/バッファ戦略。
- DynamoDB ホットキー：キー設計・書込分散・GSI/LSI の意味づけ。
- RAG のセキュリティ：機密データの取り扱い、監査ログ、プロンプト注入対策。
- コスト可視化：Cost Explorer/Tags/リソース命名規約、Compute Optimizer。
学習ロードマップ（30 日）
Week 1：基礎の骨格
- データモデリング（3 正規形 / Star Schema）、OLTP vs OLAP、S3/Glue/Athena の一連操作
Week 2：ETL/ELT と DWH
- Glue（Spark）で Parquet 化、パーティション設計。Redshift ロード＆クエリ最適化
Week 3：ストリーム & 検索
- Kinesis（Streams/Firehose）でリアルタイム取り込み、OpenSearch でログ検索/ダッシュボード
Week 4：AI・ML / RAG
- SageMaker で実験管理、Bedrock で API 組み込み。S3 → 埋め込み → ベクタ検索 → 推論まで通す
次回予告
#3：Security / Governance / Migration / Operations 編
- IAM/Organizations/Control Tower/KMS/Secrets/CloudTrail/Config/GuardDuty/Security Hub/Backup/Systems Manager/DMS ほか
- マルチアカウントの着地設計、監査・暗号・運用自動化の「最初の正解」を提示する
付録：用語ミニ辞典
- OLTP/OLAP：行志向の取引処理／列志向の分析処理
- スキーマオンリード：格納時は生で、読取時にスキーマを当てる方式
- Parquet/ORC：列指向かつ圧縮前提のファイルフォーマット
- WLM：Redshift のワークロード管理。
- RAG：Retrieval Augmented Generation。検索で補強した文脈を LLM に与える推論方式
#1 Compute / Container / Storage / Network 編
#2 Data / Analytics / AI・ML / Integration 編
本記事
#3 Security / Governance / Migration / Operations 編
鋭意制作中