deploying-on-aws

AWS パターン

目的

このスキルでは、Amazon Web Services の意思決定フレームワークと実装パターンを提供します。実績のある選定基準、アーキテクチャパターン、Well-Architected Framework の原則を活用して、AWS の 200 以上のサービスを使いこなせます。実用的なサービス選定、コストを考慮した設計、Lambda SnapStart、EventBridge Pipes、S3 Express One Zone を含む 2025 年の最新パターンに重点を置いています。

AWS ソリューションの設計、特定のワークロードに適したサービスの選定、サーバーレスまたはコンテナアーキテクチャの実装、コスト、パフォーマンス、信頼性の観点から既存の AWS インフラストラクチャを最適化する際に、このスキルを使用してください。

このスキルを使用する場面

次のような場合に、このスキルを呼び出してください。

• コンピューティングワークロードで Lambda、Fargate、ECS、EKS、EC2 のいずれを選ぶか検討する
• アクセスパターンに基づいてデータベースサービス（RDS、Aurora、DynamoDB）を選定する
• 多層アプリケーション向けの VPC アーキテクチャを設計する
• API Gateway と Lambda を使用してサーバーレスパターンを実装する
• ECS または EKS 上にコンテナベースのマイクロサービスを構築する
• 設計に AWS Well-Architected Framework を適用する
• パフォーマンスを維持しながら AWS コストを最適化する
• セキュリティのベストプラクティス（IAM、KMS、暗号化）を実装する

中核となるサービス選定フレームワーク

コンピューティングサービスの選定

意思決定フロー：

Execution Duration:
  <15 minutes → Evaluate Lambda
  >15 minutes → Evaluate containers or VMs

Event-Driven/Scheduled:
  YES → Lambda (serverless)
  NO → Consider traffic patterns

Containerized:
  YES → Need Kubernetes?
    YES → EKS
    NO → ECS (Fargate or EC2)
  NO → Evaluate EC2 or containerize first

Special Requirements:
  GPU/Windows/BYOL licensing → EC2
  Predictable high traffic → EC2 or ECS on EC2 (cost optimization)
  Variable traffic → Lambda or Fargate

クイックリファレンス：

ワークロード	主な選択肢	料金モデル	主なメリット
API バックエンド	Lambda + API Gateway	リクエストごとの従量課金	自動スケーリング、サーバー不要
マイクロサービス	Fargate 上の ECS	実行時間に応じた課金	運用が簡単
Kubernetes アプリ	EKS	月額 $73 + コンピューティング料金	移植性、エコシステム
バッチジョブ	Lambda または Fargate Spot	リクエスト／Spot 料金	コスト効率
長時間実行	EC2 リザーブドインスタンス	30～60% の節約	予測可能なコスト

コストの例、パフォーマンス特性、ユースケースのガイダンスを含む詳細なサービス比較については、references/compute-services.md を参照してください。

データベースサービスの選定

アクセスパターン別の判断マトリックス：

アクセスパターン	データモデル	主な選択肢	主な判断基準
トランザクション処理（OLTP）	リレーショナル	Aurora	パフォーマンス + 高可用性
シンプルな CRUD	リレーショナル	RDS PostgreSQL	コストと機能のバランス
キー値検索	NoSQL	DynamoDB	サーバーレスでのスケーリング
ドキュメントストレージ	JSON/BSON	DynamoDB	柔軟性と MongoDB 互換性
キャッシュ	インメモリ	ElastiCache Redis	速度 + 耐久性
分析（OLAP）	列指向	Redshift/Athena	専用型とサーバーレス型
時系列	タイムスタンプ付き	Timestream	専用設計

クエリの複雑さに関するガイド：

• シンプルなキー値検索： DynamoDB（1 桁ミリ秒のレイテンシ）
• 中程度の結合（2～3 テーブル）： Aurora または RDS（コストとパフォーマンスのバランス）
• 複雑な分析： Redshift（専用型）または Athena（サーバーレス、S3 をクエリ）
• リアルタイムストリーム： DynamoDB Streams + Lambda

ストレージクラスの選定、コスト比較、移行パターンについては、references/database-services.md を参照してください。

ストレージサービスの選定

主な判断ツリー：

Data Type:
  Objects (files, media) → S3 + lifecycle policies
  Blocks (databases, boot volumes) → EBS
  Shared Files (cross-instance) → Evaluate protocol

File Protocol Required:
  NFS (Linux) → EFS
  SMB (Windows) → FSx for Windows
  High-Performance HPC → FSx for Lustre
  Multi-Protocol + Enterprise → FSx for NetApp ONTAP

コスト比較（月あたり 1TB）：

サービス	月額コスト	アクセスパターン
S3 Standard	$23	頻繁なアクセス
S3 Standard-IA	$12.50	低頻度（30 日超）
S3 Glacier Instant	$4	アーカイブ、即時取り出し
EBS gp3	$80	ブロックストレージ
EFS Standard	$300	共有ファイル、頻繁なアクセス
EFS IA	$25	共有ファイル、低頻度のアクセス

推奨： ストレージニーズの 80% 以上には S3 を使用してください。共有ファイルへのアクセスが必要な場合に限り、EFS/FSx を使用してください。

S3 ストレージクラス、EBS ボリュームタイプ、ライフサイクルポリシーの例については、references/storage-services.md を参照してください。

サーバーレスアーキテクチャパターン

パターン 1：REST API（Lambda + API Gateway + DynamoDB）

アーキテクチャ：

Client → API Gateway (HTTP API) → Lambda → DynamoDB
                                        ↓
                                       S3 (file uploads)

次の場合に使用します：

• CRUD 操作を伴う RESTful API を構築する
• トラフィックが変動する、または予測できない
• 運用負荷を最小限に抑えたい
• リクエストごとの課金モデルを許容できる

コストの見積もり（月間 100 万リクエスト）：

• API Gateway：$3.50
• Lambda：$3.53
• DynamoDB：約 $7.50
• 合計：約 $15/月（Fargate は約 $35 以上、EC2 は約 $50 以上）

主なコンポーネント：

• API Gateway HTTP API（REST API より低コスト）
• 適切なメモリ割り当ての Lambda（通常は 1024MB が最適）
• DynamoDB のオンデマンド課金（トラフィックが変動する場合）
• デバッグ用の CloudWatch Logs

完全な実装については、examples/cdk/serverless-api/ と examples/terraform/serverless-api/ を参照してください。

パターン 2：イベント駆動型の処理（EventBridge + Lambda + SQS）

アーキテクチャ：

S3 Upload → EventBridge Rule → Lambda (process) → DynamoDB (metadata)
                                              ↓
                                            SQS (downstream tasks)

次の場合に使用します：

• ファイルを非同期で処理する
• 疎結合なマイクロサービス間通信を行う
• ファンアウトパターンを使用する（1 つのイベントに複数のコンシューマー）
• 再試行ロジックとデッドレターキューが必要である

主な機能（2025 年）：

• EventBridge Pipes： ソース → フィルター → エンリッチメント → ターゲットを簡素化
• Lambda Response Streaming： 最大 20MB のレスポンスをストリーミング
• Step Functions Distributed Map： 数百万の項目を並列処理

Step Functions のオーケストレーション、API Gateway WebSockets、Lambda SnapStart の設定など、その他のパターンについては references/serverless-patterns.md を参照してください。

コンテナアーキテクチャのパターン

パターン 1：Fargate 上の ECS（サーバーレスコンテナ）

アーキテクチャ：

ALB → ECS Service (Fargate tasks) → RDS Aurora
                                 ↓
                           ElastiCache Redis

次の場合に使用します：

• クラスター管理なしでコンテナ化されたアプリケーションを実行する
• 自動スケーリングを伴う、変動するトラフィックに対応する
• EC2 インスタンスの管理を避ける
• Docker ベースでデプロイする

主なコンポーネント：

• Application Load Balancer（パスベースのルーティング）
• Fargate 起動タイプの ECS クラスター
• タスク定義（CPU、メモリ、コンテナイメージ）
• CPU／メモリまたはカスタムメトリクスに基づく自動スケーリング
• 組み込みサービスメッシュの Service Connect（2025 年の機能）

コストモデル（2 vCPU、4GB RAM、24 時間 365 日）：

• Fargate：約 $70/月
• ALB：約 $20/月
• RDS Aurora db.t3.medium：約 $50/月
• 合計：約 $140/月

パターン 2：EKS（AWS 上の Kubernetes）

次の場合に使用します：

• チームに Kubernetes の知識がある
• マルチクラウドまたはハイブリッドクラウド戦略を採用する
• Kubernetes エコシステム（Helm、Operators、Istio）が必要である
• 複雑なワークロードのオーケストレーション要件がある

主な機能（2025 年）：

• EKS Auto Mode： ノードのライフサイクルを完全に管理
• EKS Pod Identities： IAM を簡素化（IRSA に代わるもの）
• EKS Hybrid Nodes： オンプレミスのノードを実行

コストに関する考慮事項：

• EKS コントロールプレーン：クラスターごとに $73/月
• ワーカーノード：Fargate または EC2 の料金
• シンプルさを優先する場合は Fargate 上の EKS、コスト最適化を優先する場合は EC2 を使用

ECS タスク定義、CDK／Terraform による EKS クラスターのセットアップ、サービスメッシュのパターンについては、references/container-patterns.md を参照してください。

ネットワーキングの基本

VPC アーキテクチャ

標準的な 3 層パターン：

VPC: 10.0.0.0/16

Per Availability Zone (deploy across 3 AZs):
  Public Subnet:    10.0.X.0/24   (ALB, NAT Gateway)
  Private Subnet:   10.0.1X.0/24  (ECS, Lambda, app tier)
  Database Subnet:  10.0.2X.0/24  (RDS, Aurora, isolated)

ベストプラクティス：

• VPC CIDR には /16 を使用します（拡張用に 65,536 個の IP）
• サブネット CIDR には /24 を使用します（256 個の IP、使用可能なのは 251 個）
• 高可用性のため、最低 2 つの AZ にデプロイします（3 つを推奨）
• インスタンスレベルのファイアウォールには、ステートフルな Security Groups を使用します
• トラブルシューティングのため、VPC Flow Logs を有効にします

ロードバランシング

サービスの選択：

ロードバランサー	プロトコル	ユースケース	主な機能
ALB	HTTP/HTTPS	Web アプリ、API	パス／ホストベースのルーティング、Lambda ターゲット
NLB	TCP/UDP	高パフォーマンス	静的 IP、超低レイテンシー
GWLB	Layer 3	セキュリティアプライアンス	インライン検査

ALB の機能：

• パスベースのルーティング：/api → バックエンド、/web → フロントエンド
• ホストベースのルーティング：api.example.com、web.example.com
• WebSocket と gRPC のサポート
• Lambda との統合（サーバーレスバックエンド）

CloudFront CDN のパターン、Route 53 のルーティングポリシー、VPC ピアリングの設定については、references/networking.md を参照してください。

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

IAM の原則

最小権限パターン：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/uploads/*"
  }]
}

主な実践項目：

• アプリケーションには IAM ユーザーではなく IAM ロールを使用する
• 最小権限を実装する（必要最低限の権限を付与する）
• 特権ユーザーには MFA を有効にする
• IAM Access Analyzer を使用してポリシーを検証する
• ガードレールとして AWS Organizations SCP を活用する

データ保護

暗号化要件：

サービス	保存時の暗号化	転送中の暗号化
S3	SSE-S3 または SSE-KMS	HTTPS（TLS 1.2+）
EBS	KMS 暗号化	該当なし（インスタンス内）
RDS/Aurora	KMS 暗号化	TLS 接続
DynamoDB	KMS 暗号化	HTTPS API

シークレット管理：

• Secrets Manager： 自動ローテーション付きのデータベース認証情報
• Parameter Store： アプリケーション設定（無料利用枠あり）
• KMS： 暗号化キー管理（カスタマー管理キー）

WAF ルール、GuardDuty の設定、ネットワークセキュリティのパターンについては、references/security.md を参照してください。

AWS Well-Architected フレームワーク

6 つの柱の概要

1. オペレーショナルエクセレンス

• Infrastructure as Code（CDK、Terraform、CloudFormation）
• デプロイの自動化（CI/CD パイプライン）
• オブザーバビリティ（CloudWatch Logs、Metrics、X-Ray）
• 一般的な運用のためのランブックとプレイブック

2. セキュリティ

• 強固な ID 基盤（IAM ロールとポリシー）
• 多層防御（Security Groups、NACLs、WAF）
• データ保護（保存時および転送中の暗号化）
• 検知コントロール（CloudTrail、GuardDuty、Security Hub）

3. 信頼性

• マルチ AZ デプロイ（RDS Multi-AZ、Aurora レプリカ）
• オートスケーリング（EC2 ASG、ECS Service Auto Scaling）
• バックアップと復旧（自動スナップショット、クロスリージョン）
• カオスエンジニアリング（Fault Injection Simulator）

4. パフォーマンス効率

• リソースの適正サイズ化（Compute Optimizer を使用）
• マネージドサービスの利用（運用負荷を軽減）
• キャッシュ戦略（CloudFront、ElastiCache、DAX）
• 継続的な監視と最適化

5. コスト最適化

• コンピューティングの適正サイズ化（容量を需要に合わせる）
• 料金モデル（Reserved Instances、Savings Plans、Spot）
• ストレージの最適化（S3 Intelligent-Tiering、ライフサイクルポリシー）
• コストの監視（Cost Explorer、Budgets、Trusted Advisor）

6. サステナビリティ（2024 年追加）

• Graviton プロセッサを使用する（エネルギー消費を 60％削減し、パフォーマンスを 25％向上）
• ワークロードの配置を最適化する（再生可能エネルギーを利用できるリージョン）
• ストレージ効率を高める（未使用データの削除、圧縮）
• ソフトウェアを最適化する（効率的なコード、非同期処理）

各柱の詳細な実装ガイド、アーキテクチャレビューのチェックリスト、Well-Architected Tool との連携については、references/well-architected.md を参照してください。

Infrastructure as Code

ツールの選択

AWS CDK（Cloud Development Kit）：

• 言語： TypeScript、Python、Java、C#、Go
• 最適な用途： AWS ネイティブなワークロード、型安全なインフラストラクチャ
• 主な利点： 高レベルのコンストラクト、CloudFormation への合成
• 例： examples/cdk/serverless-api/

Terraform：

• 言語： HCL（HashiCorp Configuration Language）
• 最適な用途： マルチクラウド環境
• 主な利点： 最大規模のエコシステム、成熟した状態管理
• 例： examples/terraform/serverless-api/

CloudFormation：

• 言語： YAML または JSON
• 最適な用途： AWS とのネイティブな連携、追加ツールが不要
• 主な利点： 初日からの AWS サービスサポート
• 例： examples/cloudformation/lambda-api.yaml

CDK クイックスタート

# Install CDK CLI
npm install -g aws-cdk

# Initialize new project
cdk init app --language=typescript
npm install

# Deploy infrastructure
cdk bootstrap  # One-time setup
cdk deploy

Terraform クイックスタート

# Install Terraform
brew install terraform  # macOS

# Initialize project
terraform init

# Preview changes
terraform plan

# Apply changes
terraform apply

VPC ネットワーキング、多層アプリケーション、イベント駆動型アーキテクチャを含む、すぐに動作する完全なサンプルについては、examples/ ディレクトリを参照してください。

コスト最適化戦略

コンピューティングコストの最適化

適切なサイズの選定：

• EC2／Lambda の推奨事項には AWS Compute Optimizer を使用します
• CloudWatch のメトリクス（CPU、メモリ使用率）を監視します
• 控えめに開始し、実際の使用状況に基づいてスケールします

料金モデル：

モデル	コミットメント	割引率	最適な用途
オンデマンド	なし	0%	変動するワークロード
Savings Plans	1-3 年	30-40%	柔軟なコンピューティング
リザーブドインスタンス	1-3 年	30-60%	予測可能なワークロード
スポットインスタンス	なし	60-90%	耐障害性が求められるタスク

Graviton の利点：

• Graviton3 インスタンス：Graviton2 と比べてパフォーマンスが 25% 向上します
• エネルギー消費量を 60% 削減します
• 利用可能なサービス：EC2、Lambda、Fargate、RDS、ElastiCache

ストレージコストの最適化

S3 ライフサイクルポリシー：

Day 0-30:    S3 Standard         ($0.023/GB)
Day 30-90:   S3 Standard-IA      ($0.0125/GB)
Day 90-365:  S3 Glacier Instant  ($0.004/GB)
Day 365+:    S3 Deep Archive     ($0.00099/GB)

EBS の最適化：

• gp3 ボリュームを使用します（gp2 より 20% 安価で、IOPS を設定可能です）
• 使用していないスナップショットを削除します
• 古いスナップショットをアーカイブします（75% 安価です）

モニタリング：

• AWS Cost Explorer を有効にします（無料）
• アラート付きの AWS Budgets を設定します
• コスト配分タグを使用して配賦します
• Trusted Advisor のコストチェックを確認します

一般的なパターンと例

サーバーレスの 3 層アプリケーション

CloudFront (CDN)
  → S3 (React frontend)
  → API Gateway (REST API)
    → Lambda (business logic)
      → DynamoDB (data)
      → S3 (file storage)

CDK の完全な実装： examples/cdk/three-tier-app/ Terraform の完全な実装： examples/terraform/three-tier-app/

コンテナ化されたマイクロサービス

Route 53 (DNS)
  → CloudFront (CDN)
    → ALB (load balancer)
      → ECS Fargate (services)
        → RDS Aurora (database)
        → ElastiCache Redis (cache)

完全な実装： examples/cdk/ecs-fargate/

イベント駆動型データパイプライン

S3 Upload
  → EventBridge Rule
    → Lambda (transform)
      → Kinesis Firehose
        → S3 Data Lake
          → Athena (query)

完全な実装： examples/cdk/event-driven/

他のスキルとの連携

関連スキル

• infrastructure-as-code - マルチクラウドの IaC 概念、CDK と Terraform のパターン
• kubernetes-operations - EKS クラスターの運用、kubectl、Helm チャート
• building-ci-pipelines - CodePipeline、CodeBuild、GitHub Actions → AWS
• secret-management - Secrets Manager のローテーション、Parameter Store の階層構造
• observability - CloudWatch の高度なクエリ、X-Ray による分散トレーシング
• security-hardening - IAM ポリシーのベストプラクティス、セキュリティ自動化
• disaster-recovery - マルチリージョン戦略、バックアップの自動化

スキル間のパターン

EKS + kubernetes-operations：

• EKS クラスターのプロビジョニング（CDK／Terraform）にはこのスキルを使用します
• kubectl、Helm、アプリケーションのデプロイには kubernetes-operations を使用します

シークレット管理：

• Secrets Manager／Parameter Store のセットアップにはこのスキルを使用します
• ローテーションポリシーやアクセスパターンには secret-management スキルを使用します

CI/CD との連携：

• CodePipeline インフラストラクチャにはこのスキルを使用します
• パイプラインの設定には building-ci-pipelines スキルを使用します

リファレンスドキュメント

詳細ガイド

• コンピューティングサービス： references/compute-services.md - Lambda、Fargate、ECS、EKS、EC2 の詳細
• データベースサービス： references/database-services.md - RDS、Aurora、DynamoDB、ElastiCache の比較
• ストレージサービス： references/storage-services.md - S3 ストレージクラス、EBS タイプ、EFS／FSx の選定
• ネットワーキング： references/networking.md - VPC 設計、ロードバランシング、CloudFront、Route 53
• セキュリティ： references/security.md - IAM パターン、KMS、Secrets Manager、WAF
• サーバーレスパターン： references/serverless-patterns.md - Lambda、Step Functions、EventBridge の高度なパターン
• コンテナパターン： references/container-patterns.md - ECS Service Connect、EKS Pod Identities
• Well-Architected： references/well-architected.md - 6 つの柱の実装ガイド

実用例

• CDK の例： examples/cdk/ - TypeScript による実装
• Terraform の例： examples/terraform/ - HCL による実装
• CloudFormation の例： examples/cloudformation/ - YAML テンプレート

ユーティリティスクリプト

• コスト見積もり： scripts/cost-estimate.sh - インフラストラクチャのコストを見積もります
• リソース監査： scripts/resource-audit.sh - AWS リソースを監査します
• セキュリティチェック： scripts/security-check.sh - 基本的なセキュリティ検証を行います

AWS Service Updates (2025)

検討したい最近のイノベーション：

• Lambda SnapStart： Java 関数のコールドスタートをほぼ瞬時にします
• Lambda Response Streaming： 最大 20MB のレスポンスをストリーミングします
• EventBridge Pipes： イベント処理を簡素化します（ソース → フィルター → エンリッチメント → ターゲット）
• S3 Express One Zone： S3 の 10 倍の速度、1 桁ミリ秒のレイテンシー
• ECS Service Connect： ECS 向けの組み込みサービスメッシュ
• EKS Auto Mode： Kubernetes ノードのライフサイクルを完全マネージドで管理します
• EKS Pod Identities： Pod 向けの IAM を簡素化します（IRSA を置き換えます）
• Aurora Limitless Database： 単一ライターの上限を超える水平書き込みスケーリング
• DynamoDB Standard-IA： アクセス頻度の低いテーブルでコストを 60% 削減します
• RDS Blue/Green Deployments： ダウンタイムなしでバージョンをアップグレードします

---

迅速な選定チェックリスト

サービスを選ぶ前に、次の質問に答えてください：

1. トラフィックパターン： 予測可能ですか、それとも変動しますか？（コンピューティングの選択に影響します）
2. データモデル： リレーショナル、キーと値、ドキュメント、グラフのどれですか？（データベースの選択に影響します）
3. アクセスパターン： 頻繁、低頻度、アーカイブのどれですか？（ストレージクラスの選択に影響します）
4. レイテンシー要件： ミリ秒、秒、分のうち、どれまで許容できますか？
5. スケーリングのニーズ： 垂直（より大きなインスタンス）と水平（より多くのインスタンス）のどちらですか？
6. 運用上のオーバーヘッド： マネージドサービスを優先しますか、それとも制御が必要ですか？
7. コストの重視度： コスト、パフォーマンス、バランスのどれを最適化しますか？
8. コンプライアンス要件： データレジデンシー、暗号化、監査ログが必要ですか？

そのうえで、このスキルまたは詳細なリファレンスにある該当の意思決定フレームワークを参照してください。

はじめに

新しい AWS プロジェクトの場合：

1. Well-Architected Framework の柱に沿ってアーキテクチャを定義します
2. 意思決定ツリーを使ってコンピューティングサービスを選択します（Lambda/Fargate/ECS/EKS/EC2）
3. アクセスパターンとデータモデルに基づいてデータベースを選択します
4. 3 層サブネットアーキテクチャで VPC を設計します
5. CDK または Terraform を使って IaC を実装します（examples/ を参照）
6. セキュリティのベストプラクティスを適用します（IAM、暗号化、ログ記録）
7. モニタリングとコスト追跡を設定します

既存の AWS プロジェクトの場合：

1. AWS Trusted Advisor を実行して推奨事項を確認します
2. Well-Architected Framework の柱を見直します
3. コストを最適化します（適正サイズへの調整、Reserved Instances、ストレージのライフサイクル）
4. 最新のサービスに移行します（EC2 → Fargate、RDS → Aurora）
5. セキュリティ体制を強化します（GuardDuty を有効にし、最小権限を実装）
6. IaC で自動化します（Terraform または CDK にリバースエンジニアリングします）