AWS — SAA 以上の設計・運用知識

前提知識: VPC・EC2・S3・IAMの基礎。本教材では設計判断・コスト・運用を扱います。

1. SAA を超えた設計判断

ECS vs EKS — 選び方

Lambda vs Fargate vs EC2

Lambda:
  ✅ イベント駆動・短時間処理（15分以内）
  ✅ リクエスト数が読めない（ゼロスケール）
  ❌ コールドスタート、ステートレス
  例: S3イベント処理、API Gateway バックエンド

Fargate:
  ✅ 常時稼働のコンテナ、サーバー管理不要
  ✅ 秒単位課金（EC2より柔軟）
  ❌ EC2 より高コスト（同スペックで約2倍）
  例: Web API、バッチ処理

EC2:
  ✅ 最大コントロール、コスト最適化
  ✅ Reserved Instance で大幅割引（最大72%）
  ❌ サーバー管理が必要
  例: 長時間・安定したワークロード、特殊なインスタンスタイプ

2. コスト最適化（SAP でも重要）

Reserved Instance vs Savings Plans

コスト可視化・削減の実践

# Cost Explorer API で月次コストを取得
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# 未使用リソースの検出
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=stopped" \
  --query 'Reservations[].Instances[].[InstanceId,Tags[?Key==`Name`].Value|[0],LaunchTime]' \
  --output table

# Trusted Advisor で推奨確認（Businessサポート以上で全チェック）
aws support describe-trusted-advisor-checks --language ja

3. マルチアカウント設計（Organizations）

Root
├── Management Account（請求・ポリシー管理のみ）
├── Security OU
│   ├── Log Archive Account（CloudTrail, Config logs）
│   └── Security Tooling Account（SecurityHub, GuardDuty）
├── Infrastructure OU
│   └── Shared Services Account（DNS, Directory Service）
└── Workloads OU
    ├── Production Account
    └── Development Account

Service Control Policy (SCP)

// 東京リージョン以外での操作を禁止（Root OUに適用）
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["ap-northeast-1"]
      },
      "ArnNotLike": {
        "aws:PrincipalARN": [
          "arn:aws:iam::*:role/OrganizationAccountAccessRole"
        ]
      }
    }
  }]
}

4. 可用性設計パターン

Multi-AZ vs Multi-Region

Multi-AZ（高可用性）:
  - 同一リージョン内の別データセンター
  - RDS Multi-AZ: スタンバイへの自動フェイルオーバー（60-120秒）
  - 99.99% SLA が目安
  - ほぼ全てのサービスで推奨

Multi-Region（DR対応）:
  - 地域災害・リージョン障害への対応
  - RTO/RPO 要件が厳しい場合
  - コストが大幅増
  - Route53 + CloudFront でトラフィック切り替え

RDS のフェイルオーバーを理解する

Primary (AZ-a)          Standby (AZ-c)
    ↓ 書き込み              ↓ 同期レプリケーション
   DB データ  ─────────>  DB データ（ミラーリング）

フェイルオーバー時:
1. Primary が障害
2. DNS が Standby に切り替わる（同じエンドポイントURL）
3. アプリは再接続するだけ

5. オブザーバビリティ（Observability）三本柱

Metrics（メトリクス）
  └── CloudWatch Metrics, Container Insights
  └── 例: CPU使用率, リクエスト数, エラー率

Logs（ログ）
  └── CloudWatch Logs, OpenSearch
  └── 例: アプリログ, アクセスログ, 監査ログ

Traces（トレース）
  └── X-Ray, OpenTelemetry
  └── 例: マイクロサービス間のレイテンシ追跡

# Lambda での X-Ray トレーシング
from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # boto3, requests 等を自動計装

@xray_recorder.capture('process_order')
def process_order(order_id: str):
    # このセグメントがX-Rayのトレースに記録される
    ...

6. よく出る SAP 試験の設計問題

大量データの転送

• オンプレ → AWS: AWS DataSync（ネットワーク転送）/ Snowball Edge（物理デバイス）
• 閾値: 10Gbps 以下なら Direct Connect / 100TB 超なら Snowball 検討

Blue/Green デプロイ

Blue（現行）:  ALB → Target Group Blue  → EC2/ECS Blue
Green（新版）:                           → EC2/ECS Green

切り替え: ALB のリスナールールを Green に変更
ロールバック: Blue に戻すだけ（即時）

イベント駆動アーキテクチャ

S3 Upload
  → S3 Event Notification
  → SQS（バッファリング・デカップリング）
  → Lambda（処理）
  → SNS（通知）
  → DynamoDB（結果保存）

ポイント: SQS でバッファリングすると Lambda の同時実行数を制御できる

🔗 次のステップ

• 02_コンテナサービス.md — ECS・EKS 実践
• 03_サーバーレス.md — Lambda・API Gateway 深掘り
• ../../06_DevOps/IaC/01_Terraform.md — AWS リソースを Terraform で管理