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

- Name
- Youngju Kim
- @fjvbn20031
目次(もくじ)
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つの核心(かくしん)基準がある。
- レイテンシー(Latency): ユーザーに最も近いリージョンを選択
- コンプライアンス(Compliance): データ主権法(しゅけんほう)、GDPR等の法的要件(ようけん)
- サービス可用性(かようせい): すべてのAWSサービスがすべてのリージョンで提供(ていきょう)されるわけではない
- コスト: リージョンごとに価格(かかく)が異(こと)なり、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, m7g | Webサーバー、開発環境 | 1:4 |
| コンピューティング最適化 | c7g, c6i | バッチ処理、HPC | 1:2 |
| メモリ最適化 | r6g, r6i, x2idn | インメモリDB、キャッシュ | 1:8以上 |
| ストレージ最適化 | i3, i3en, d3 | データウェアハウス | 高IOPS |
| GPUインスタンス | p4d, p5, g5 | ML学習、グラフィックス | 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インスタンス数を自動的に調整(ちょうせい)する。
核心構成要素:
- Launch Template: インスタンス起動時に使用するAMI、インスタンスタイプ、セキュリティグループ等を定義(ていぎ)
- スケーリングポリシー: いつ拡張(かくちょう)/縮小(しゅくしょう)するかを決定するルール
- 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,000 | 1,000 MB/s |
| io2 Block Express | 高性能SSD | 256,000 | 4,000 MB/s |
| st1 | スループット最適化HDD | 500 | 500 MB/s |
| sc1 | コールドHDD | 250 | 250 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 ストレージクラス
| ストレージクラス | 可用性 | 最小保管期間(きかん) | 検索(けんさく)コスト | ユースケース |
|---|---|---|---|---|
| Standard | 99.99% | なし | なし | 頻繁にアクセスするデータ |
| Intelligent-Tiering | 99.9% | なし | モニタリング費用 | アクセスパターンが変化するデータ |
| Standard-IA | 99.9% | 30日 | GB単位課金 | 月1回未満のアクセス |
| One Zone-IA | 99.5% | 30日 | GB単位課金 | 再生成可能なデータ |
| Glacier Instant | 99.9% | 90日 | GB単位課金 | 四半期1回、即時検索 |
| Glacier Flexible | 99.99% | 90日 | GB単位+検索時間 | 年1-2回、分-時間で検索 |
| Glacier Deep Archive | 99.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/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
| 項目(こうもく) | セキュリティグループ | ネットワーク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 Endpoint | S3、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セキュリティベストプラクティス
- ルートアカウント使用禁止: ルートアカウントにはMFAのみ設定し、日常業務(にちじょうぎょうむ)では使用しない
- MFA有効化: すべてのユーザーに多要素認証(たようそにんしょう)を要求
- 最小権限の原則: 必要最小限(ひつようさいしょうげん)の権限のみ付与
- アクセスキーのローテーション: 90日ごとにアクセスキーを交換(こうかん)
- IAM Access Analyzer: 外部アクセス可能なリソースを分析(ぶんせき)・監視(かんし)
- 一時的資格情報の使用: 長期資格情報の代(か)わりにSTSによる一時的資格情報を使用
6. RDS (Relational Database Service)
RDSはマネージド型リレーショナルデータベースサービスで、パッチ適用、バックアップ、フェイルオーバーを自動的に処理(しょり)する。
6.1 サポートエンジン
| エンジン | 最新バージョン | 特徴 |
|---|---|---|
| Amazon Aurora | MySQL 8.0/PostgreSQL 16互換 | 商用DB性能、オープンソース価格 |
| MySQL | 8.0 | 最も普及したオープンソースDB |
| PostgreSQL | 16 | 高度な機能、拡張性 |
| MariaDB | 10.11 | MySQL互換、コミュニティ主導 |
| Oracle | 19c/21c | エンタープライズワークロード |
| SQL Server | 2022 | Windowsベースアプリケーション |
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関数が初めて呼び出されるか、長時間後に呼び出される時にコールドスタートが発生する。
最適化方法(さいてきかほうほう):
- Provisioned Concurrency: インスタンスを事前にウォームアップしてコールドスタートを排除(はいじょ)
- メモリサイズ最適化: メモリを増やすとCPUも比例して増加
- パッケージサイズ縮小: 不要(ふよう)な依存関係(いぞんかんけい)を除去
- Lambda SnapStart: Java関数のスナップショットベース初期化(最大10倍速い起動)
- 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 容量モード
| モード | 特徴 | 適したユースケース |
|---|---|---|
| オンデマンド | 自動スケーリング、使用量ベース課金 | 予測不可能なトラフィック |
| プロビジョニング | 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@Edge | CloudFront Functions |
|---|---|---|
| 実行場所 | リージョンエッジキャッシュ | エッジロケーション |
| 最大実行時間 | 5-30秒 | 1ms |
| メモリ | 128-10,240 MB | 2 MB |
| ネットワークアクセス | 可能 | 不可 |
| コスト | 比較的高い | 非常に安い |
| ユースケース | A/Bテスティング、認証 | URLリライト、ヘッダー操作 |
10. コンテナサービス
10.1 ECS (Elastic Container Service)
ECSはDockerコンテナを実行・管理するオーケストレーションサービスである。
Fargate vs EC2起動タイプ:
| 項目 | Fargate | EC2 |
|---|---|---|
| インフラ管理 | 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 インスタンス最適化
- Right-sizing: AWS Compute Optimizerを活用してインスタンスサイズを最適化
- Reserved Instances: 安定的ワークロードに1年/3年予約で最大72%削減
- Spot Instances: 中断可能なワークロードに最大90%削減
- 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つの柱(はしら):
- 運用の卓越性(たくえつせい)(Operational Excellence): 自動化、IaC、可観測性
- セキュリティ(Security): IAM、暗号化(あんごうか)、ネットワークセキュリティ
- 信頼性(しんらいせい)(Reliability): Multi-AZ、自動復旧、災害復旧
- パフォーマンス効率(こうりつ)(Performance Efficiency): 適切なリソース選択、モニタリング
- コスト最適化(Cost Optimization): 使用した分だけ課金、予約
- 持続可能性(じぞくかのうせい)(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は読み取りトラフィックを分散してパフォーマンスを向上させる。