AWS コアサービス完全ガイド 2025：EC2、S3、RDS、Lambda、VPC、IAM 徹底解説

目次（もくじ）

1. AWSグローバルインフラストラクチャ

Amazon Web Services（AWS）は、世界中（せかいじゅう）に広がる膨大（ぼうだい）なインフラストラクチャを運用（うんよう）している。2025年時点（じてん）で33以上のリージョン（Region）、105以上のアベイラビリティゾーン（Availability Zone）、600以上のエッジロケーション（Edge Location）を保有（ほゆう）している。

1.1 リージョン（Region）

リージョンは地理的（ちりてき）に分離（ぶんり）された独立（どくりつ）したデータセンターのクラスターである。各リージョンは最低（さいてい）3つのアベイラビリティゾーンで構成（こうせい）される。

主要（しゅよう）リージョン：

1.2 リージョン選択（せんたく）基準（きじゅん）

リージョンを選択する際（さい）に考慮（こうりょ）すべき4つの核心（かくしん）基準がある。

1. レイテンシー（Latency）: ユーザーに最も近いリージョンを選択
2. コンプライアンス（Compliance）: データ主権法（しゅけんほう）、GDPR等の法的要件（ようけん）
3. サービス可用性（かようせい）: すべてのAWSサービスがすべてのリージョンで提供（ていきょう）されるわけではない
4. コスト: リージョンごとに価格（かかく）が異（こと）なり、us-east-1が一般的（いっぱんてき）に最も安い

1.3 アベイラビリティゾーン（Availability Zone）

アベイラビリティゾーンはリージョン内の独立したデータセンターである。各AZは独立した電源（でんげん）、冷却（れいきゃく）、ネットワーキングを備（そな）えており、AZ間は低遅延（ていちえん）ネットワークで接続（せつぞく）されている。

リージョン: ap-northeast-1 (東京)
├── AZ: ap-northeast-1a
├── AZ: ap-northeast-1b
├── AZ: ap-northeast-1c
└── AZ: ap-northeast-1d

1.4 エッジロケーションとローカルゾーン

• エッジロケーション: CloudFront CDNキャッシュサーバーが配置（はいち）される場所。世界中に600以上
• ローカルゾーン（Local Zone）: 大都市（だいとし）に位置（いち）するAWSインフラの拡張（かくちょう）。超低遅延が必要な場合に使用
• Wavelength Zone: 5Gネットワークのエッジに位置するAWSインフラ

2. EC2 (Elastic Compute Cloud)

EC2はAWSで最も基本的（きほんてき）なコンピューティングサービスである。仮想（かそう）サーバー（インスタンス）を作成（さくせい）して様々（さまざま）なワークロードを実行（じっこう）できる。

2.1 インスタンスタイプ

EC2インスタンスは使用目的（もくてき）に応（おう）じて複数（ふくすう）のファミリーに分類（ぶんるい）される。

インスタンス命名規則（めいめいきそく）：

m6i.xlarge
│││  └─── サイズ (nano, micro, small, medium, large, xlarge, 2xlarge...)
│││
││└───── 追加機能 (i=Intel, g=Graviton, a=AMD, n=ネットワーク強化)
│└────── 世代 (数字が大きいほど新しい)
└─────── ファミリー (t=バースト, m=汎用, c=コンピューティング, r=メモリ...)

2.2 AMI、User Data、Key Pairs

AMI（Amazon Machine Image） はインスタンスを起動（きどう）するために必要な情報（じょうほう）を含むテンプレートである。

# AWS CLIで最新のAmazon Linux 2023 AMIを照会
aws ec2 describe-images \
  --owners amazon \
  --filters "Name=name,Values=al2023-ami-2023.*-x86_64" \
  --query "sort_by(Images, &CreationDate)[-1].ImageId" \
  --output text

User Data はインスタンス起動時に自動的（じどうてき）に実行されるスクリプトである。

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "Hello from EC2" > /var/www/html/index.html

Key Pairs はSSHアクセスに使用される公開鍵（こうかいかぎ）/秘密鍵（ひみつかぎ）のペアである。EC2インスタンスには公開鍵が保存され、ユーザーは秘密鍵で接続する。

2.3 料金（りょうきん）モデル

EC2は4つの主要な料金モデルを提供している。

スポットインスタンスの使用例：

# スポットインスタンスのリクエスト
aws ec2 request-spot-instances \
  --instance-count 1 \
  --type "one-time" \
  --launch-specification '{
    "ImageId": "ami-0abcdef1234567890",
    "InstanceType": "c5.xlarge",
    "KeyName": "my-key-pair"
  }'

2.4 Auto Scaling Group

Auto Scaling Group（ASG）はトラフィックの変化（へんか）に応じてEC2インスタンス数を自動的に調整（ちょうせい）する。

核心構成要素：

1. Launch Template: インスタンス起動時に使用するAMI、インスタンスタイプ、セキュリティグループ等を定義（ていぎ）
2. スケーリングポリシー: いつ拡張（かくちょう）/縮小（しゅくしょう）するかを決定するルール
3. Cooldown Period: スケーリング操作間の待機時間（たいきじかん）

# CloudFormationでのASG定義例
AutoScalingGroup:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    LaunchTemplate:
      LaunchTemplateId: !Ref LaunchTemplate
      Version: !GetAtt LaunchTemplate.LatestVersionNumber
    MinSize: 2
    MaxSize: 10
    DesiredCapacity: 4
    TargetGroupARNs:
      - !Ref ALBTargetGroup
    VPCZoneIdentifier:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2

スケーリングポリシーの種類（しゅるい）：

• Target Tracking: CPU使用率70%維持（いじ）など目標指標（しひょう）を設定
• Step Scaling: 指標値に応じて段階的（だんかいてき）に拡張/縮小
• Scheduled Scaling: 予定された時間にインスタンス数を調整（例：毎朝9時に拡張）
• Predictive Scaling: MLベースでトラフィックパターンを予測し事前に拡張

2.5 プレイスメントグループ（Placement Groups）

2.6 EBS (Elastic Block Store)

EBSはEC2インスタンスに接続するブロックストレージボリュームである。

# EBSスナップショット作成
aws ec2 create-snapshot \
  --volume-id vol-0123456789abcdef0 \
  --description "Daily backup"

# スナップショットからボリューム復元
aws ec2 create-volume \
  --snapshot-id snap-0123456789abcdef0 \
  --availability-zone ap-northeast-1a \
  --volume-type gp3

3. S3 (Simple Storage Service)

S3はAWSのオブジェクトストレージサービスで、ほぼ無制限（むせいげん）の容量（ようりょう）と99.999999999%（イレブンナイン）の耐久性（たいきゅうせい）を提供する。

3.1 ストレージクラス

3.2 ライフサイクルポリシー

ライフサイクルポリシーでデータを自動的に低コストのストレージクラスに移行（いこう）または削除（さくじょ）できる。

{
  "Rules": [
    {
      "ID": "ArchiveAndDelete",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

3.3 バージョニングとレプリケーション

バージョニング（Versioning） はオブジェクトのすべての変更履歴（へんこうりれき）を保存する。誤（あやま）って削除や上書（うわが）きしても以前のバージョンに復元（ふくげん）できる。

# バージョニングの有効化
aws s3api put-bucket-versioning \
  --bucket my-bucket \
  --versioning-configuration Status=Enabled

# 特定バージョンのオブジェクト照会
aws s3api list-object-versions \
  --bucket my-bucket \
  --prefix config.json

クロスリージョンレプリケーション（CRR） と 同一リージョンレプリケーション（SRR）：

• CRR: 災害復旧（さいがいふっきゅう）、コンプライアンスのため別リージョンに自動複製（ふくせい）
• SRR: ログ集約（しゅうやく）、開発/本番環境間のデータ同期（どうき）

3.4 Presigned URLとイベント通知（つうち）

Presigned URL は認証（にんしょう）なしで一時的にS3オブジェクトにアクセスできるURLを生成する。

import boto3

s3_client = boto3.client('s3')

# ダウンロード用Presigned URL（1時間有効）
url = s3_client.generate_presigned_url(
    'get_object',
    Params={
        'Bucket': 'my-bucket',
        'Key': 'reports/annual-2025.pdf'
    },
    ExpiresIn=3600
)
print(f"Download URL: {url}")

S3イベント通知: オブジェクト作成、削除などのイベントをLambda、SQS、SNSに転送（てんそう）する。

# イベント通知設定例（CloudFormation）
S3Bucket:
  Type: AWS::S3::Bucket
  Properties:
    NotificationConfiguration:
      LambdaConfigurations:
        - Event: 's3:ObjectCreated:*'
          Filter:
            S3Key:
              Rules:
                - Name: prefix
                  Value: uploads/
          Function: !GetAtt ProcessingFunction.Arn

3.5 S3 Selectと Transfer Acceleration

• S3 Select: SQLクエリでオブジェクト内の特定データのみ抽出（ちゅうしゅつ）。CSV、JSON、Parquet対応
• S3 Transfer Acceleration: CloudFrontエッジロケーションを活用して長距離（ちょうきょり）アップロードを高速化

3.6 静的（せいてき）ウェブサイトホスティング

S3を使用して静的ウェブサイトをホスティングできる。

# バケットを静的ウェブサイトとして設定
aws s3 website s3://my-website-bucket/ \
  --index-document index.html \
  --error-document error.html

# ウェブサイトファイルの同期
aws s3 sync ./build/ s3://my-website-bucket/ \
  --delete \
  --cache-control "max-age=31536000"

4. VPC (Virtual Private Cloud)

VPCはAWSクラウド内で論理的（ろんりてき）に分離された仮想ネットワークを構成できるサービスである。

4.1 CIDR表記とサブネット

CIDR（Classless Inter-Domain Routing）でIPアドレス範囲（はんい）を定義する。

10.0.0.0/16  → 65,536個のIP (10.0.0.0 ~ 10.0.255.255)
10.0.1.0/24  → 256個のIP   (10.0.1.0 ~ 10.0.1.255)
10.0.1.0/28  → 16個のIP    (10.0.1.0 ~ 10.0.1.15)

パブリックサブネット vs プライベートサブネット：

• パブリックサブネット: Internet Gatewayへのルーティングがあるサブネット。Webサーバー、ロードバランサーを配置
• プライベートサブネット: インターネットへの直接（ちょくせつ）アクセスが不可能なサブネット。DB、アプリケーションサーバーを配置

4.2 3層（そう）アーキテクチャ設計（せっけい）

┌─────────────────────────────────────────────────────────┐
│                     VPC: 10.0.0.0/16                     │
│                                                          │
│  ┌────────────────────┐  ┌────────────────────┐         │
│  │   Public Subnet     │  │   Public Subnet     │         │
│  │   10.0.1.0/24       │  │   10.0.2.0/24       │         │
│  │   (AZ-a)            │  │   (AZ-b)            │         │
│  │                     │  │                     │         │
│  │  ┌──────────────┐  │  │  ┌──────────────┐  │         │
│  │  │  ALB / NAT GW │  │  │  │  ALB / NAT GW │  │         │
│  │  └──────────────┘  │  │  └──────────────┘  │         │
│  └────────────────────┘  └────────────────────┘         │
│            │                        │                    │
│  ┌────────────────────┐  ┌────────────────────┐         │
│  │  Private Subnet     │  │  Private Subnet     │         │
│  │  (App) 10.0.3.0/24  │  │  (App) 10.0.4.0/24  │         │
│  │                     │  │                     │         │
│  │  ┌──────────────┐  │  │  ┌──────────────┐  │         │
│  │  │  EC2 / ECS    │  │  │  │  EC2 / ECS    │  │         │
│  │  └──────────────┘  │  │  └──────────────┘  │         │
│  └────────────────────┘  └────────────────────┘         │
│            │                        │                    │
│  ┌────────────────────┐  ┌────────────────────┐         │
│  │  Private Subnet     │  │  Private Subnet     │         │
│  │  (DB) 10.0.5.0/24   │  │  (DB) 10.0.6.0/24   │         │
│  │                     │  │                     │         │
│  │  ┌──────────────┐  │  │  ┌──────────────┐  │         │
│  │  │  RDS Primary  │  │  │  │  RDS Standby  │  │         │
│  │  └──────────────┘  │  │  └──────────────┘  │         │
│  └────────────────────┘  └────────────────────┘         │
│                                                          │
│  ┌──────────┐                                            │
│  │  IGW      │  ← Internet Gateway                       │
│  └──────────┘                                            │
└─────────────────────────────────────────────────────────┘

4.3 Internet GatewayとNAT Gateway

• Internet Gateway（IGW）: VPCとインターネット間の通信（つうしん）を可能にするゲートウェイ
• NAT Gateway: プライベートサブネットのインスタンスがインターネットにアクセスできるようにしつつ、外部からのインバウンドアクセスは遮断（しゃだん）

# NAT Gatewayの作成
aws ec2 create-nat-gateway \
  --subnet-id subnet-0123456789abcdef0 \
  --allocation-id eipalloc-0123456789abcdef0

4.4 セキュリティグループ vs NACL

# セキュリティグループの作成とルール追加
aws ec2 create-security-group \
  --group-name web-sg \
  --description "Web server security group" \
  --vpc-id vpc-0123456789abcdef0

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

4.5 VPCピアリングとTransit Gateway

• VPC Peering: 2つのVPC間のプライベートネットワーク接続。推移的（すいいてき）ルーティングは不可（A-B、B-C接続時にA-Cの直接通信は不可）
• Transit Gateway: 中央ハブを通じて複数のVPCとオンプレミスネットワークを接続。推移的ルーティングをサポート

4.6 VPCエンドポイント

VPCエンドポイントを使用すると、インターネットを経由（けいゆ）せずにAWSサービスにアクセスできる。

4.7 VPC Flow Logs

VPC Flow Logsはネットワークインターフェースの送受信（そうじゅしん）IPトラフィック情報をキャプチャする。

# Flow Logレコード例
# version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-abc123 10.0.1.5 52.94.76.1 49761 443 6 12 1024 1625000000 1625000060 ACCEPT OK

5. IAM (Identity and Access Management)

IAMはAWSリソースへのアクセスを安全（あんぜん）に制御（せいぎょ）するサービスである。

5.1 IAM構成要素（こうせいようそ）

• ユーザー（User）: 個々（ここ）の人やサービスを表すエンティティ
• グループ（Group）: 同じ権限（けんげん）が必要なユーザーの集合
• ロール（Role）: AWSサービスや外部ユーザーが一時的（いちじてき）に引き受（う）けることができる権限セット
• ポリシー（Policy）: JSON形式で権限を定義した文書（ぶんしょ）

5.2 ポリシーJSON構造

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

ポリシー構成要素：

• Effect: Allow または Deny
• Action: 許可/拒否するAPI操作（例：s3:GetObject）
• Resource: 対象リソースのARN
• Condition: 条件付き適用（IP、時間、タグなど）

5.3 EC2用IAMロール（インスタンスプロファイル）

EC2インスタンスにIAMロールを付与（ふよ）すると、アクセスキーなしでAWSサービスにアクセスできる。

# インスタンスプロファイルの作成とロール関連付け
aws iam create-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly

aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly \
  --role-name S3ReadOnlyRole

# EC2インスタンスにプロファイルを関連付け
aws ec2 associate-iam-instance-profile \
  --instance-id i-0123456789abcdef0 \
  --iam-instance-profile Name=EC2-S3-ReadOnly

5.4 クロスアカウントアクセス

別のAWSアカウントのリソースにアクセスする際は、IAMロールの信頼（しんらい）関係（Trust Policy）を活用する。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

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

1. ルートアカウント使用禁止: ルートアカウントにはMFAのみ設定し、日常業務（にちじょうぎょうむ）では使用しない
2. MFA有効化: すべてのユーザーに多要素認証（たようそにんしょう）を要求
3. 最小権限の原則: 必要最小限（ひつようさいしょうげん）の権限のみ付与
4. アクセスキーのローテーション: 90日ごとにアクセスキーを交換（こうかん）
5. IAM Access Analyzer: 外部アクセス可能なリソースを分析（ぶんせき）・監視（かんし）
6. 一時的資格情報の使用: 長期資格情報の代（か）わりにSTSによる一時的資格情報を使用

6. RDS (Relational Database Service)

RDSはマネージド型リレーショナルデータベースサービスで、パッチ適用、バックアップ、フェイルオーバーを自動的に処理（しょり）する。

6.1 サポートエンジン

6.2 Multi-AZとRead Replica

Multi-AZ（高可用性）：

┌──────────────────┐     同期レプリケーション  ┌──────────────────┐
│  Primary (AZ-a)   │ ──────────────────── │  Standby (AZ-b)   │
│                   │                       │                   │
│  読み書き         │    自動フェイルオーバー   │  待機（アクセス不可）│
└──────────────────┘                       └──────────────────┘

Read Replica（読み取りスケーリング）：

                    ┌──────────────────┐
                    │  Read Replica 1   │  ← 読み取り専用
               ┌──▶│  (同一リージョン)  │
               │    └──────────────────┘
┌──────────────┤    ┌──────────────────┐
│  Primary      │──▶│  Read Replica 2   │  ← 読み取り専用
│  (読み書き)   │    │  (同一リージョン)  │
└──────────────┤    └──────────────────┘
               │    ┌──────────────────┐
               └──▶│  Read Replica 3   │  ← クロスリージョン
                    │  (別リージョン)    │
                    └──────────────────┘

6.3 Aurora Serverless v2

Aurora Serverless v2はワークロードに応じて自動的に容量を調整する。

• ACU（Aurora Capacity Unit）: 0.5-128 ACUの範囲で自動スケーリング
• 秒単位（びょうたんい）課金: 実際に使用したACU分のみコスト発生
• 混合構成（こんごうこうせい）: プロビジョニングされたインスタンスとサーバーレスインスタンスを同一クラスターで混在可能

# Aurora Serverless v2クラスター作成
aws rds create-db-cluster \
  --db-cluster-identifier my-aurora-cluster \
  --engine aurora-postgresql \
  --engine-version 16.1 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 \
  --master-username admin \
  --master-user-password MySecurePassword123

6.4 自動バックアップとパラメータグループ

• 自動バックアップ: 毎日自動スナップショット作成（最大35日保管）
• ポイントインタイムリカバリ（PITR）: 5分単位で特定時点のデータを復元
• パラメータグループ: DBエンジン設定をカスタマイズ

6.5 RDS Proxy

RDS Proxyはデータベース接続をプーリングして管理する。Lambdaのように短命（たんめい）な接続が多いサーバーレス環境で特に有用（ゆうよう）である。

Lambda関数群 ──▶ RDS Proxy ──▶ RDSインスタンス
(数千の接続)    (コネクションプーリング)  (少数の接続)

7. Lambda（サーバーレスコンピューティング）

Lambdaはサーバーをプロビジョニングや管理する必要なくコードを実行できるサーバーレスコンピューティングサービスである。

7.1 イベント駆動（くどう）アーキテクチャ

Lambdaは様々なAWSサービスのイベントによってトリガーされる。

┌─────────────┐     ┌──────────┐     ┌─────────────┐
│ API Gateway  │────▶│          │────▶│ DynamoDB    │
└─────────────┘     │          │     └─────────────┘
                    │          │
┌─────────────┐     │  Lambda  │     ┌─────────────┐
│ S3 Event     │────▶│ Function │────▶│ S3          │
└─────────────┘     │          │     └─────────────┘
                    │          │
┌─────────────┐     │          │     ┌─────────────┐
│ SQS / SNS    │────▶│          │────▶│ SQS / SNS   │
└─────────────┘     │          │     └─────────────┘
                    │          │
┌─────────────┐     │          │     ┌─────────────┐
│ EventBridge  │────▶│          │────▶│ Step Func.  │
└─────────────┘     └──────────┘     └─────────────┘

7.2 Lambda関数の例

import json
import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Users')

def lambda_handler(event, context):
    """API Gatewayから呼び出されるLambda関数"""

    http_method = event['httpMethod']
    path = event['path']

    if http_method == 'GET':
        response = table.scan()
        return {
            'statusCode': 200,
            'headers': {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Origin': '*'
            },
            'body': json.dumps(response['Items'], default=str)
        }

    elif http_method == 'POST':
        body = json.loads(event['body'])
        table.put_item(Item=body)
        return {
            'statusCode': 201,
            'body': json.dumps({'message': 'Created successfully'})
        }

    return {
        'statusCode': 400,
        'body': json.dumps({'message': 'Unsupported method'})
    }

7.3 コールドスタート最適化

Lambda関数が初めて呼び出されるか、長時間後に呼び出される時にコールドスタートが発生する。

最適化方法（さいてきかほうほう）：

1. Provisioned Concurrency: インスタンスを事前にウォームアップしてコールドスタートを排除（はいじょ）
2. メモリサイズ最適化: メモリを増やすとCPUも比例して増加
3. パッケージサイズ縮小: 不要（ふよう）な依存関係（いぞんかんけい）を除去
4. Lambda SnapStart: Java関数のスナップショットベース初期化（最大10倍速い起動）
5. Lambda Layers: 共通（きょうつう）ライブラリをLayerに分離して再利用

# Provisioned Concurrencyの設定
aws lambda put-provisioned-concurrency-config \
  --function-name my-function \
  --qualifier prod \
  --provisioned-concurrent-executions 10

7.4 Lambda@Edge

Lambda@EdgeはCloudFrontエッジロケーションでLambda関数を実行する。A/Bテスティング、ヘッダー操作、URLリダイレクトなどに活用される。

7.5 料金モデル

• リクエスト数: 月100万件無料、以降100万件あたり約0.20 USD
• 実行時間: GB秒単位の課金（メモリ x 実行時間）
• Provisioned Concurrency: プロビジョニング容量に応じた追加コスト

8. DynamoDB

DynamoDBは完全マネージド型NoSQLデータベースで、ミリ秒単位の一貫した応答時間を提供する。

8.1 データモデル

┌─────────────────────────────────────────────┐
│  Table: Orders                               │
│                                              │
│  Partition Key: userId (String)              │
│  Sort Key: orderDate (String)                │
│                                              │
│  ┌──────────┬────────────┬────────┬────────┐│
│  │ userId   │ orderDate   │ total  │ status ││
│  ├──────────┼────────────┼────────┼────────┤│
│  │ user-001 │ 2025-01-15 │ 29900  │ shipped││
│  │ user-001 │ 2025-03-20 │ 15000  │ pending││
│  │ user-002 │ 2025-02-10 │ 89000  │ delivered│
│  └──────────┴────────────┴────────┴────────┘│
│                                              │
│  GSI: StatusIndex                            │
│  Partition Key: status                       │
│  Sort Key: orderDate                         │
└─────────────────────────────────────────────┘

インデックス：

• GSI（Global Secondary Index）: 異なるパーティションキーとソートキーでクエリ可能
• LSI（Local Secondary Index）: 同一パーティションキー、異なるソートキー（テーブル作成時にのみ追加可能）

8.2 容量モード

8.3 DynamoDB StreamsとTTL

• DynamoDB Streams: テーブルの変更をリアルタイムでキャプチャ。Lambdaトリガーでイベント処理
• TTL（Time to Live）: 有効期限（ゆうこうきげん）を設定して古いアイテムを自動削除

8.4 シングルテーブル設計パターン

DynamoDBでは単一テーブルに複数のエンティティを格納（かくのう）するパターンが推奨（すいしょう）される。

PK          | SK              | データ
------------|-----------------|------------------
USER#001    | PROFILE         | name, email, ...
USER#001    | ORDER#2025-001  | total, status, ...
USER#001    | ORDER#2025-002  | total, status, ...
ORG#ABC     | METADATA        | orgName, plan, ...
ORG#ABC     | MEMBER#001      | role, joinedAt, ...

9. CloudFront（CDN）

CloudFrontはAWSのCDN（Content Delivery Network）サービスで、世界中のエッジロケーションでコンテンツをキャッシュして高速（こうそく）に配信（はいしん）する。

9.1 ディストリビューション構成

ユーザー ──▶ CloudFront Edge ──▶ オリジン
                │                  │
          キャッシュヒット時      キャッシュミス時
          即座に応答返却          オリジンから取得

オリジンの種類：

• S3バケット（静的コンテンツ）
• ALB / EC2（動的コンテンツ）
• API Gateway（API）
• カスタムオリジン（オンプレミスサーバー）

9.2 キャッシュポリシーとOrigin Shield

キャッシュポリシー（Cache Policy）: どの要素（ヘッダー、クエリストリング、Cookie）をキャッシュキーに含めるかを定義する。

Origin Shield: オリジンの前に追加キャッシングレイヤーを配置してオリジンの負荷（ふか）を軽減（けいげん）する。

9.3 Lambda@Edge vs CloudFront Functions

10. コンテナサービス

10.1 ECS (Elastic Container Service)

ECSはDockerコンテナを実行・管理するオーケストレーションサービスである。

Fargate vs EC2起動タイプ：

10.2 EKS (Elastic Kubernetes Service)

EKSはマネージド型Kubernetesサービスである。コントロールプレーンをAWSが管理し、ワーカーノードはEC2またはFargateで実行できる。

10.3 ECR (Elastic Container Registry)

ECRはDockerイメージを格納するプライベートコンテナレジストリである。

# ECRにイメージをプッシュ
aws ecr get-login-password --region ap-northeast-1 | \
  docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com

docker tag my-app:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest
docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest

11. その他の主要サービス

11.1 メッセージングサービス

SQS（Simple Queue Service）：

• 標準キュー: 無制限スループット、最低1回配信（順序保証なし）
• FIFOキュー: 正確に1回配信、順序保証（毎秒3,000メッセージ）

SNS（Simple Notification Service）：

• Pub/Subメッセージングモデル
• 複数のサブスクライバーへの同時通知（ファンアウトパターン）

EventBridge：

• イベント駆動アーキテクチャのためのサーバーレスイベントバス
• イベントパターンマッチング、スケジュールベーストリガー
• 100以上のAWSサービスおよびSaaS統合

11.2 Step Functions

Step Functionsは複数のAWSサービスをビジュアルワークフローに組み合わせるオーケストレーションサービスである。

{
  "Comment": "注文処理ワークフロー",
  "StartAt": "ValidateOrder",
  "States": {
    "ValidateOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:validate",
      "Next": "ProcessPayment"
    },
    "ProcessPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:payment",
      "Next": "ShipOrder",
      "Catch": [
        {
          "ErrorEquals": ["PaymentFailed"],
          "Next": "NotifyFailure"
        }
      ]
    },
    "ShipOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:ship",
      "End": true
    },
    "NotifyFailure": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:notify",
      "End": true
    }
  }
}

11.3 モニタリングと監査（かんさ）

CloudWatch：

• メトリクス収集とダッシュボード
• ロググループとLog Insights
• アラーム設定と自動対応

CloudTrail：

• すべてのAPI呼び出しを記録
• セキュリティ監査とコンプライアンス
• イベント履歴（りれき）90日間デフォルト保存

11.4 Route 53

Route 53はAWSのマネージドDNSサービスである。

ルーティングポリシー：

12. コスト最適化戦略

12.1 インスタンス最適化

1. Right-sizing: AWS Compute Optimizerを活用してインスタンスサイズを最適化
2. Reserved Instances: 安定的ワークロードに1年/3年予約で最大72%削減
3. Spot Instances: 中断可能なワークロードに最大90%削減
4. Savings Plans: コンピューティング使用量コミットメントで柔軟に割引

12.2 ストレージ最適化

• S3ライフサイクルポリシーで自動アーカイブ
• EBSボリュームタイプの最適化（gp2からgp3への切り替えで最大20%削減）
• 未使用のEBSスナップショットとボリュームの整理

12.3 コスト管理ツール

12.4 タグ付け戦略

すべてのリソースに一貫（いっかん）したタグを適用して、チーム/プロジェクト/環境別にコストを追跡（ついせき）する。

# 必須タグの例
aws ec2 create-tags \
  --resources i-0123456789abcdef0 \
  --tags \
    Key=Environment,Value=Production \
    Key=Team,Value=Backend \
    Key=Project,Value=UserService \
    Key=CostCenter,Value=CC-1234

12.5 Well-Architected Framework

AWS Well-Architected Frameworkの6つの柱（はしら）：

1. 運用の卓越性（たくえつせい）（Operational Excellence）: 自動化、IaC、可観測性
2. セキュリティ（Security）: IAM、暗号化（あんごうか）、ネットワークセキュリティ
3. 信頼性（しんらいせい）（Reliability）: Multi-AZ、自動復旧、災害復旧
4. パフォーマンス効率（こうりつ）（Performance Efficiency）: 適切なリソース選択、モニタリング
5. コスト最適化（Cost Optimization）: 使用した分だけ課金、予約
6. 持続可能性（じぞくかのうせい）（Sustainability）: エネルギー効率、リソース最適化

13. 実践（じっせん）クイズ

以下のクイズで学習内容を確認（かくにん）しよう。

参考資料（さんこうしりょう）

1. AWS公式ドキュメント
2. AWS Well-Architected Framework
3. AWSコスト最適化ガイド
4. AWS Solutions Library
5. AWS re:Invent 2024/2025セッション
6. AWS Skill Builder
7. AWS Architecture Blog
8. Amazon Auroraユーザーガイド
9. AWS Lambda開発者ガイド
10. VPCネットワーキングベストプラクティス
11. DynamoDB開発者ガイド
12. AWS Pricing Calculator
13. AWS Serverless Application Model (SAM)