Skip to content
Published on

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

Authors

目次(もくじ)

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

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

1.1 リージョン(Region)

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

主要(しゅよう)リージョン:

リージョンコード場所(ばしょ)特徴(とくちょう)
us-east-1米国バージニア最も古く、サービスが最も多い
ap-northeast-1日本 東京アジア太平洋の主要拠点
ap-northeast-2韓国 ソウル韓国ユーザー向け最適
eu-west-1アイルランドヨーロッパの主要拠点
ap-southeast-1シンガポール東南アジアカバレッジ

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インスタンスは使用目的(もくてき)に応(おう)じて複数(ふくすう)のファミリーに分類(ぶんるい)される。

ファミリー代表的タイプ用途(ようと)vCPU:メモリ比率
汎用(はんよう)t3, m6i, m7gWebサーバー、開発環境1:4
コンピューティング最適化c7g, c6iバッチ処理、HPC1:2
メモリ最適化r6g, r6i, x2idnインメモリDB、キャッシュ1:8以上
ストレージ最適化i3, i3en, d3データウェアハウス高IOPS
GPUインスタンスp4d, p5, g5ML学習、グラフィックスGPU含む

インスタンス命名規則(めいめいきそく):

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つの主要な料金モデルを提供している。

料金モデル割引率(わりびきりつ)契約期間(けいやくきかん)適(てき)したワークロード
オンデマンド基準価格なし短期、予測不可
リザーブドインスタンス最大72%1年または3年安定的、予測可能
スポットインスタンス最大90%なし(中断可能)バッチ処理、CI/CD
Savings Plans最大72%1年または3年柔軟な使用パターン

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

# スポットインスタンスのリクエスト
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)

戦略(せんりゃく)説明ユースケース
Cluster単一AZ内にインスタンスを密集配置HPC、低遅延ネットワーク
Spreadインスタンスを異なるハードウェアに分散高可用性が重要なアプリ
Partitionインスタンスを論理的パーティションに分割Hadoop、Cassandra

2.6 EBS (Elastic Block Store)

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

ボリュームタイプ用途最大IOPS最大スループット
gp3汎用SSD(デフォルト)16,0001,000 MB/s
io2 Block Express高性能SSD256,0004,000 MB/s
st1スループット最適化HDD500500 MB/s
sc1コールドHDD250250 MB/s
# 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 ストレージクラス

ストレージクラス可用性最小保管期間(きかん)検索(けんさく)コストユースケース
Standard99.99%なしなし頻繁にアクセスするデータ
Intelligent-Tiering99.9%なしモニタリング費用アクセスパターンが変化するデータ
Standard-IA99.9%30日GB単位課金月1回未満のアクセス
One Zone-IA99.5%30日GB単位課金再生成可能なデータ
Glacier Instant99.9%90日GB単位課金四半期1回、即時検索
Glacier Flexible99.99%90日GB単位+検索時間年1-2回、分-時間で検索
Glacier Deep Archive99.99%180日GB単位+検索時間規制準拠用、12時間検索

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/1665,536個のIP (10.0.0.0 ~ 10.0.255.255)
10.0.1.0/24256個のIP   (10.0.1.0 ~ 10.0.1.255)
10.0.1.0/2816個の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

項目(こうもく)セキュリティグループネットワークACL(NACL)
適用範囲インスタンス(ENI)レベルサブネットレベル
状態ステートフル(応答自動許可)ステートレス(明示的許可が必要)
ルールタイプ許可ルールのみ許可+拒否ルール
ルール評価すべてのルールを評価番号順に評価
デフォルト動作すべてのアウトバウンド許可、インバウンド拒否すべてのトラフィック許可
# セキュリティグループの作成とルール追加
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サービスにアクセスできる。

タイプサポートサービスコスト
Gateway EndpointS3、DynamoDB無料
Interface Endpointほとんどの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 サポートエンジン

エンジン最新バージョン特徴
Amazon AuroraMySQL 8.0/PostgreSQL 16互換商用DB性能、オープンソース価格
MySQL8.0最も普及したオープンソースDB
PostgreSQL16高度な機能、拡張性
MariaDB10.11MySQL互換、コミュニティ主導
Oracle19c/21cエンタープライズワークロード
SQL Server2022Windowsベースアプリケーション

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-0012025-01-1529900  │ shipped││
│  │ user-0012025-03-2015000  │ pending││
│  │ user-0022025-02-1089000  │ delivered│
│  └──────────┴────────────┴────────┴────────┘│
│                                              │
GSI: StatusIndexPartition Key: status                       │
Sort Key: orderDate                         │
└─────────────────────────────────────────────┘

インデックス:

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

8.2 容量モード

モード特徴適したユースケース
オンデマンド自動スケーリング、使用量ベース課金予測不可能なトラフィック
プロビジョニングRCU/WCUを事前設定、Auto Scaling可能予測可能なトラフィック、コスト削減

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

項目Lambda@EdgeCloudFront Functions
実行場所リージョンエッジキャッシュエッジロケーション
最大実行時間5-30秒1ms
メモリ128-10,240 MB2 MB
ネットワークアクセス可能不可
コスト比較的高い非常に安い
ユースケースA/Bテスティング、認証URLリライト、ヘッダー操作

10. コンテナサービス

10.1 ECS (Elastic Container Service)

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

Fargate vs EC2起動タイプ:

項目FargateEC2
インフラ管理AWSが管理ユーザーが管理
価格vCPU+メモリベースEC2インスタンスコスト
スケーリングタスク単位インスタンス+タスク
GPUサポート不可可能
適した場面簡単な運用GPU、大規模コスト最適化

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サービスである。

ルーティングポリシー:

ポリシー説明
Simple単一リソースへルーティング
Weighted重み付けベースのトラフィック分配
Latency最も低いレイテンシーのリージョンへルーティング
Failover障害時に代替リソースへ切り替え
Geolocationユーザーの位置に基づくルーティング
Multi-Value複数の健全なリソースを返却

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 コスト管理ツール

ツール機能
Cost Explorerコスト分析と予測
Budgets予算設定とアラート
Cost Anomaly Detection異常コストの自動検出
Trusted Advisorコスト削減の推奨事項提供

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. 実践(じっせん)クイズ

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

Q1. S3バケットに保存されたオブジェクトを30日後にStandard-IAへ、90日後にGlacierへ移行し、365日後に削除するにはどの機能を使用すべきか?

正解(せいかい): S3ライフサイクルポリシー(Lifecycle Policy)

ライフサイクルポリシーを使用すると、Transitionルールでストレージクラスを自動移行し、Expirationルールでオブジェクトを自動削除できる。これによりコストを大幅(おおはば)に削減できる。

Q2. Lambda関数のコールドスタートを完全に排除するにはどの機能を使用すべきか?

正解: Provisioned Concurrency

Provisioned ConcurrencyはLambda実行環境を事前に初期化された状態で維持し、コールドスタートを完全に排除する。ただし、プロビジョニングされた容量に対する追加コストが発生する。

Q3. VPCでプライベートサブネットのインスタンスがインターネットにアクセスでき、外部からのインバウンドアクセスは遮断したい場合、どのサービスを使用すべきか?

正解: NAT Gateway

NAT Gatewayはプライベートサブネットのインスタンスがアウトバウンドインターネットトラフィックを送信できるようにしつつ、インターネットからのインバウンド接続を遮断する。NAT Gatewayはパブリックサブネットに配置する必要がある。

Q4. DynamoDBで特定の属性値で効率的にクエリするにはどのインデックスを使用すべきか?

正解: GSI(Global Secondary Index)

GSIを使用すると、テーブルのパーティションキーとソートキー以外の属性でも効率的なクエリを実行できる。GSIはテーブル作成後にも追加できる。

Q5. Multi-AZ RDSとRead Replicaの違いは何か?

正解:

  • Multi-AZ: 高可用性(HA)目的。同期レプリケーション、自動フェイルオーバー。Standbyには読み取りアクセス不可。
  • Read Replica: 読み取りスケーリング目的。非同期レプリケーション。読み取り専用でアクセス可能。クロスリージョンレプリケーションもサポート。

Multi-AZは障害時に自動的にStandbyに切り替わりダウンタイムを最小化し、Read Replicaは読み取りトラフィックを分散してパフォーマンスを向上させる。


参考資料(さんこうしりょう)

  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)