Lecture 1クラウドコンピューティングとは — なぜAWSを学ぶのか
8:00
クラウドコンピューティングとは — なぜAWSを学ぶのか
はじめに
「サーバーを買う時代」は終わりました。2024年現在、世界のIT支出の約65%以上がクラウド関連に移行しています。本レクチャーではクラウドコンピューティングの根本的な概念を理解し、なぜAWS(Amazon Web Services)が業界のデファクトスタンダードとなっているのかを学びます。
オンプレミス vs クラウド
従来のオンプレミス環境とクラウド環境を比較してみましょう。
┌─────────────────────────────────────────────────────┐
│ オンプレミス環境 │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Server│ │Server│ │Server│ ← 物理サーバーを購入 │
│ └──┬───┘ └──┬───┘ └──┬───┘ │
│ └─────────┼─────────┘ │
│ ┌───┴───┐ │
│ │ Switch │ ← ネットワーク機器も自前 │
│ └───┬───┘ │
│ ┌───┴───┐ │
│ │ FW │ ← ファイアウォールも自前 │
│ └───────┘ │
│ 設備投資: 数百万〜数千万円 / 調達期間: 数週間〜数ヶ月 │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ クラウド環境 │
│ ┌──────────────┐ │
│ │ AWS Console │ ← ブラウザからアクセス │
│ └──────┬───────┘ │
│ ┌───────────┼───────────┐ │
│ ┌───┴──┐ ┌────┴───┐ ┌───┴──┐ │
│ │ EC2 │ │ RDS │ │ S3 │ ← 必要な分だけ利用 │
│ └──────┘ └────────┘ └──────┘ │
│ 初期費用: 0円 / 調達期間: 数分 │
└─────────────────────────────────────────────────────┘
| 比較項目 | オンプレミス | クラウド |
|---|---|---|
| 初期費用 | 数百万〜数千万円 | 0円(従量課金) |
| 調達期間 | 数週間〜数ヶ月 | 数分 |
| スケーリング | ハードウェア追加購入 | ボタン1つで増減 |
| 運用コスト | 人件費・電気代・場所代 | 利用分のみ |
| 障害対応 | 自社で24/365対応 | クラウドベンダーが対応 |
| セキュリティ | 自社責任 | 責任共有モデル |
クラウドのサービスモデル:IaaS / PaaS / SaaS
クラウドサービスは提供範囲によって3つのモデルに分類されます。
自分で管理する範囲が多い ←─────────→ 少ない
┌────────┐ ┌────────┐ ┌────────┐
│ IaaS │ │ PaaS │ │ SaaS │
├────────┤ ├────────┤ ├────────┤
│アプリ │ │アプリ │ │████████│
│ミドル │ │████████│ │████████│
│ OS │ │████████│ │████████│
│仮想化 │ │████████│ │████████│
│ HW │ │████████│ │████████│
└────────┘ └────────┘ └────────┘
██ = ベンダー管理
| モデル | 説明 | AWS例 | 他社例 |
|---|---|---|---|
| IaaS | インフラだけ提供。OS以上は自分で管理 | EC2, VPC | Azure VM, GCE |
| PaaS | アプリ実行基盤まで提供 | Elastic Beanstalk, Lambda | Azure App Service, GAE |
| SaaS | 完成したソフトウェアを提供 | Amazon WorkSpaces | Microsoft 365, Gmail |
主要クラウドベンダー比較
2024年のクラウド市場シェアを見てみましょう。
| ベンダー | シェア(概算) | 強み | 認定資格 |
|---|---|---|---|
| AWS | 約31% | サービス数最多(200以上)、エコシステム充実 | CLF, SAA, SAP 等 |
| Azure | 約25% | Microsoft製品との連携、エンタープライズ強い | AZ-900, AZ-104 等 |
| GCP | 約11% | データ分析・ML、Kubernetes(GKE)の元祖 | ACE, PCA 等 |
AWSは2006年のサービス開始以来、最も長い歴史を持ち、日本国内でもクラウド採用企業の約50%以上が利用しています。「クラウドを学ぶなら、まずAWSから」と言われる理由がここにあります。
AWSのグローバルインフラストラクチャ
AWSは世界中に物理的なインフラを展開しています。
世界のAWSリージョン(主要なもの)
北米: us-east-1 (バージニア), us-west-2 (オレゴン)
欧州: eu-west-1 (アイルランド), eu-central-1 (フランクフルト)
アジア: ap-northeast-1 (東京), ap-southeast-1 (シンガポール)
┌─ リージョン (Region) ──────────────────────────┐
│ 地理的に独立した場所(例:東京) │
│ │
│ ┌─ AZ-a ─┐ ┌─ AZ-c ─┐ ┌─ AZ-d ─┐ │
│ │ DC群 │ │ DC群 │ │ DC群 │ │
│ │ │ │ │ │ │ │
│ └────────┘ └────────┘ └────────┘ │
│ ↕ 低遅延・高帯域の専用線で接続 │
└──────────────────────────────────────────────────┘
- リージョン(Region): 地理的に離れた独立したエリア。東京リージョン(
ap-northeast-1)は日本で最もよく使われます - アベイラビリティゾーン(AZ): リージョン内の独立したデータセンター群。東京リージョンには3つのAZがあります
- エッジロケーション: CloudFront(CDN)のキャッシュ拠点。世界に400以上
AWS無料枠(Free Tier)
AWSを学習する上で最も重要な情報が「無料枠」です。
| サービス | 無料枠の内容 | 期間 |
|---|---|---|
| EC2 | t2.micro / t3.micro 750時間/月 | 12ヶ月 |
| S3 | 5GB ストレージ、20,000 GET | 12ヶ月 |
| RDS | db.t2.micro / db.t3.micro 750時間/月 | 12ヶ月 |
| Lambda | 100万リクエスト/月、40万GB秒 | 無期限 |
| DynamoDB | 25GBストレージ、25 WCU/RCU | 無期限 |
| CloudWatch | 基本モニタリング | 無期限 |
重要: 無料枠には「12ヶ月限定」と「無期限」の2種類があります。アカウント作成日から12ヶ月を超えると、EC2やRDSの無料枠は失効します。必ず期限を確認しましょう。
実践ワーク
- AWS公式の「クラウドコンピューティングとは」ページを読む
- https://aws.amazon.com/jp/what-is-cloud-computing/
- AWS無料枠の対象サービス一覧を確認する
- https://aws.amazon.com/jp/free/
- 以下の質問に答えてみましょう:
- あなたの会社(または学習環境)でクラウドに移行するメリットは何ですか?
- 東京リージョンのAZ数を確認し、なぜ複数AZが必要なのか説明してください
- IaaS/PaaS/SaaSの違いを、自分の言葉で説明してみましょう
まとめと次回の準備
- クラウドコンピューティングは「必要なときに必要なだけ」ITリソースを利用できるモデル
- IaaS / PaaS / SaaS の3層で理解すると、サービス選定がしやすくなる
- AWSは市場シェア1位、サービス数200以上、日本国内採用率トップ
- リージョンとAZの仕組みにより、高可用性と低遅延を実現
- 無料枠を活用すれば、コストを抑えて実践学習が可能
次回は実際にAWSアカウントを作成し、管理コンソールの使い方を学びます。クレジットカードを用意しておいてください(無料枠内で利用すれば課金は発生しません)。
参考文献
Lecture 2AWSアカウントと管理コンソール — 最初の設定
10:00
AWSアカウントと管理コンソール — 最初の設定
はじめに
AWSを使い始めるには、まずアカウントの作成とセキュリティの初期設定が必要です。このレクチャーでは、アカウント作成の手順からMFA(多要素認証)の設定、請求アラートの設定、そしてAWS CLIのインストールまでを一気に進めます。
AWSアカウント作成手順
ステップ1:サインアップ
- https://aws.amazon.com/jp/ にアクセス
- 「無料アカウントを作成」をクリック
- 以下の情報を入力:
- メールアドレス(ルートユーザーのメールになります)
- AWSアカウント名(後から変更可能)
- パスワード(大文字・小文字・数字・記号を含む強力なもの)
ステップ2:連絡先情報
- アカウントの種類:「個人」または「ビジネス」を選択
- 氏名、住所、電話番号を入力
ステップ3:支払い情報
- クレジットカードまたはデビットカードを登録
- 無料枠内で利用すれば課金は発生しません
- 本人確認として$1(約150円)の一時的な課金が行われ、数日で返金されます
ステップ4:本人確認
- 電話番号を入力し、SMSまたは音声通話で確認コードを受け取ります
ステップ5:サポートプラン
- 学習目的なら「ベーシックサポート(無料)」を選択
注意: ルートユーザーのメールアドレスとパスワードは非常に重要です。パスワードマネージャーに保存し、日常の作業にはルートユーザーを使わないでください。
ルートユーザー vs IAMユーザー
┌─────────────────────────────────────────────┐
│ AWSアカウント │
│ │
│ ┌──────────────┐ │
│ │ ルートユーザー │ ← 全権限。日常使用NG │
│ │ root@xxx.com │ │
│ └──────┬───────┘ │
│ │ 作成 │
│ ┌──────┴───────┐ ┌──────────────┐ │
│ │ IAMユーザー │ │ IAMユーザー │ │
│ │ admin │ │ developer │ │
│ │ (管理者権限) │ │ (開発者権限) │ │
│ └──────────────┘ └──────────────┘ │
└─────────────────────────────────────────────┘
| 項目 | ルートユーザー | IAMユーザー |
|---|---|---|
| 権限 | 全権限(制限不可) | ポリシーで制御 |
| 用途 | アカウント作成時・緊急時のみ | 日常の作業 |
| MFA | 必須で設定すべき | 推奨 |
| アクセスキー | 作成しない | 必要に応じて作成 |
| 削除 | 不可 | 可能 |
MFA(多要素認証)の設定
ルートユーザーへのMFA設定は最優先のセキュリティ対策です。
設定手順
- ルートユーザーでAWSコンソールにログイン
- 右上のアカウント名 → 「セキュリティ認証情報」
- 「MFAデバイスの割り当て」をクリック
- 「仮想MFAデバイス」を選択(Google Authenticator / Authyを推奨)
- QRコードをスマートフォンのアプリでスキャン
- 連続する2つのMFAコードを入力して完了
認証フロー(MFA設定後):
パスワード入力 → MFAコード入力 → ログイン成功
↓ ↓
「何を知っているか」 「何を持っているか」
(知識要素) (所有要素)
請求アラートの設定
予期せぬ課金を防ぐために、請求アラートを設定しましょう。
方法1:Billing コンソールから設定
- コンソール上部の検索バーで「Billing」と入力
- 左メニュー →「Billing preferences(請求設定)」
- 「Alert preferences(アラート設定)」で以下を有効化:
- 「AWS 無料利用枠の使用アラートを受信する」
- 「CloudWatch 請求アラートを受信する」
方法2:AWS Budgets でゼロ円予算を設定
AWS Budgets → 予算を作成 → コスト予算
├─ 月次予算額: $1(または $5)
├─ 閾値: 実績が80%に達したらアラート
└─ 通知先: メールアドレスを入力
ベストプラクティス: まず $1 の予算アラートを設定しましょう。無料枠内なら通知が来ないはずですが、もし来たら何かが無料枠を超えているサインです。
AWS管理コンソールのナビゲーション
コンソールの主要な操作方法を覚えましょう。
┌──────────────────────────────────────────────────────────┐
│ [AWS Logo] サービス検索バー リージョン ▼ アカウント ▼ │
├──────────────────────────────────────────────────────────┤
│ │
│ 最近アクセスしたサービス: │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ EC2 │ │ S3 │ │ RDS │ │ IAM │ │
│ └─────┘ └─────┘ └─────┘ └─────┘ │
│ │
│ ウィジェット: │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ コスト & 使用状況 │ │ 最近のイベント │ │
│ └──────────────────┘ └──────────────────┘ │
└──────────────────────────────────────────────────────────┘
- サービス検索バー(Alt + S): 最も速いナビゲーション方法。サービス名を入力するだけ
- リージョン選択: 右上から東京(
ap-northeast-1)を選択。サービスごとにリージョンが異なるので注意 - CloudShell: コンソール下部のターミナルアイコン。ブラウザ内でAWS CLIが使える
AWS CLIのインストール
ローカル環境にAWS CLIをインストールしましょう。
Windows
# MSIインストーラーをダウンロードして実行
# https://awscli.amazonaws.com/AWSCLIV2.msi
# インストール確認
aws --version
# aws-cli/2.x.x Python/3.x.x Windows/10 exe/AMD64
macOS
# パッケージをダウンロード
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /
# インストール確認
aws --version
Linux (Ubuntu/Debian)
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
# インストール確認
aws --version
CLI初期設定
aws configure
# AWS Access Key ID: (IAMユーザーのアクセスキー)
# AWS Secret Access Key: (シークレットキー)
# Default region name: ap-northeast-1
# Default output format: json
注意: この設定は次のレクチャーでIAMユーザーを作成してから行います。ルートユーザーのアクセスキーは絶対に作成しないでください。
実践ワーク
- AWSアカウントを作成する(まだの場合)
- ルートユーザーにMFAを設定する
- 請求アラートを $1 で設定する
- AWS CLIをインストールし、
aws --versionで確認する - コンソールのリージョンが「東京(ap-northeast-1)」になっていることを確認する
- サービス検索バーで「EC2」「S3」「IAM」を検索し、それぞれのダッシュボードを確認する
まとめと次回の準備
- AWSアカウント作成時は、ルートユーザーのパスワードを厳重に管理する
- ルートユーザーは日常使用せず、IAMユーザーで作業する
- MFAはルートユーザーに必ず設定し、IAMユーザーにも推奨
- 請求アラートを設定して、予期せぬ課金を防ぐ
- AWS CLIはローカル開発とインフラ自動化の基本ツール
次回はIAM(Identity and Access Management)を詳しく学び、安全なユーザー管理とアクセス制御を設定します。
参考文献
Lecture 3IAM — セキュリティの基本
12:00
IAM — セキュリティの基本
はじめに
IAM(Identity and Access Management)は、AWSの全サービスにおけるセキュリティの基盤です。「誰が」「何に」「どのような操作を」許可するかを細かく制御できます。IAMは無料で利用でき、正しく設定することでセキュリティインシデントの大部分を防ぐことができます。
IAMの4つの要素
┌──────────────────────────────────────────────────────┐
│ IAMの構成要素 │
│ │
│ ┌──────────┐ │
│ │ ユーザー │ ← 個人を識別するアカウント │
│ │ (User) │ │
│ └────┬─────┘ │
│ │ 所属 │
│ ┌────┴─────┐ │
│ │ グループ │ ← ユーザーをまとめて管理 │
│ │ (Group) │ │
│ └────┬─────┘ │
│ │ アタッチ │
│ ┌────┴─────┐ │
│ │ ポリシー │ ← JSON形式の権限定義 │
│ │ (Policy) │ │
│ └──────────┘ │
│ │
│ ┌──────────┐ │
│ │ ロール │ ← サービスや外部アカウントに権限を委任 │
│ │ (Role) │ │
│ └──────────┘ │
└──────────────────────────────────────────────────────┘
| 要素 | 説明 | 例 |
|---|---|---|
| ユーザー (User) | 個人または自動化ツール用のID | admin-tanaka, ci-deploy |
| グループ (Group) | ユーザーの集合。ポリシーをまとめて適用 | Developers, Administrators |
| ポリシー (Policy) | 権限をJSON形式で定義 | AmazonS3ReadOnlyAccess |
| ロール (Role) | 一時的に権限を委任する仕組み | EC2がS3にアクセスするロール |
最小権限の原則(Least Privilege)
IAM設計の鉄則は「必要最小限の権限のみを付与する」ことです。
❌ 悪い例: 全員に AdministratorAccess を付与
→ 誰でもアカウントの全リソースを削除できてしまう
✅ 良い例: 役割に応じた権限を付与
├─ 管理者: AdministratorAccess(限定的な人数)
├─ 開発者: PowerUserAccess(IAM以外の操作)
├─ 閲覧者: ReadOnlyAccess(参照のみ)
└─ CI/CD: 特定サービスのみのカスタムポリシー
IAMポリシーのJSON構造
IAMポリシーは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/*"
]
},
{
"Sid": "DenyDeleteBucket",
"Effect": "Deny",
"Action": "s3:DeleteBucket",
"Resource": "*"
}
]
}
ポリシーの主要要素
| 要素 | 説明 | 値の例 |
|---|---|---|
Version |
ポリシー言語のバージョン | "2012-10-17"(常にこの値) |
Statement |
権限ルールの配列 | 複数のルールを記述可能 |
Sid |
ステートメントの識別子(任意) | "AllowS3ReadAccess" |
Effect |
許可 or 拒否 | "Allow" or "Deny" |
Action |
対象のAPI操作 | "s3:GetObject", "ec2:*" |
Resource |
対象のリソースARN | "arn:aws:s3:::my-bucket/*" |
Condition |
条件(オプション) | IPアドレス制限、MFA必須 等 |
ポイント:
DenyはAllowより優先されます。明示的なDenyがあれば、他のどのポリシーでAllowされていてもアクセスは拒否されます。
実践:管理者用IAMユーザーの作成
コンソールから作成
- IAMダッシュボード → 「ユーザー」→「ユーザーを作成」
- ユーザー名:
admin(任意の名前) - 「AWSマネジメントコンソールへのアクセスを提供する」にチェック
- 「IAM ユーザーを作成します」を選択
- パスワード: カスタムパスワードを設定
- 「ユーザーをグループに追加」→ 新しいグループ
Administratorsを作成 AdministratorsグループにAdministratorAccessポリシーをアタッチ- 確認画面で「ユーザーの作成」をクリック
AWS CLIから作成
# IAMユーザーの作成
aws iam create-user --user-name admin
# グループの作成
aws iam create-group --group-name Administrators
# AdministratorAccessポリシーをグループにアタッチ
aws iam attach-group-policy \
--group-name Administrators \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
# ユーザーをグループに追加
aws iam add-user-to-group --user-name admin --group-name Administrators
# ログインプロフィールの作成(コンソールアクセス用)
aws iam create-login-profile \
--user-name admin \
--password 'YourStr0ng!Pass' \
--password-reset-required
# アクセスキーの作成(CLI用)
aws iam create-access-key --user-name admin
IAMユーザーへのMFA強制
組織全体でMFAを強制するポリシーを作成できます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnMFA",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ResyncMFADevice",
"iam:ListMFADevices"
],
"Resource": [
"arn:aws:iam::*:mfa/${aws:username}",
"arn:aws:iam::*:user/${aws:username}"
]
},
{
"Sid": "DenyAllExceptMFASetup",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
このポリシーをグループにアタッチすると、MFAを設定していないユーザーは自分のMFA設定以外の操作ができなくなります。
IAMロール — サービス間の権限委任
IAMロールは、AWSサービスや外部アカウントに一時的な権限を付与する仕組みです。
EC2インスタンスがS3にアクセスする場合:
❌ アクセスキーをEC2に埋め込む → 漏洩リスク
✅ IAMロールをEC2にアタッチ → 安全
┌─────────┐ ロール ┌─────────┐
│ EC2 │ ←──────────→ │ S3 │
│ Instance│ S3ReadOnly │ Bucket │
└─────────┘ ロール └─────────┘
↓
一時的な認証情報が
自動で発行・更新される
ロールの作成例(EC2 → S3アクセス)
# 信頼ポリシーを作成
cat > trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOF
# ロールを作成
aws iam create-role \
--role-name EC2-S3-ReadOnly \
--assume-role-policy-document file://trust-policy.json
# S3読み取りポリシーをアタッチ
aws iam attach-role-policy \
--role-name EC2-S3-ReadOnly \
--policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
# インスタンスプロファイルを作成してロールを追加
aws iam create-instance-profile --instance-profile-name EC2-S3-Profile
aws iam add-role-to-instance-profile \
--instance-profile-name EC2-S3-Profile \
--role-name EC2-S3-ReadOnly
クロスアカウントアクセスの基本
複数のAWSアカウントを使う場合、ロールを使ってアカウント間でアクセスを委任できます。
アカウントA (開発) アカウントB (本番)
┌──────────────┐ ┌──────────────┐
│ IAMユーザー │ ──STS──→ │ IAMロール │
│ (developer) │ AssumeRole│ (prod-deploy)│
└──────────────┘ └──────┬───────┘
│
┌────┴────┐
│ S3/EC2 │
│ etc. │
└─────────┘
この仕組みにより、本番アカウントのIAMユーザーを作らずに、開発アカウントから安全にアクセスできます。
実践ワーク
- 管理者用IAMユーザーを作成し、
AdministratorAccessポリシーを付与する - 作成したIAMユーザーでコンソールにログインする(ルートユーザーとは別のログインURL)
- IAMユーザーにMFAを設定する
- 以下のカスタムポリシーを作成する(S3の特定バケットへの読み取り専用アクセス)
- AWS CLIに
aws configureでIAMユーザーのアクセスキーを設定する aws iam list-usersでユーザー一覧を確認する
まとめと次回の準備
- IAMはAWSセキュリティの根幹。ユーザー・グループ・ポリシー・ロールの4要素で構成
- 最小権限の原則を常に意識し、必要最小限の権限のみを付与する
- ポリシーはJSONで記述。
Effect、Action、Resourceが3つの柱 - MFAの強制はポリシーで実現可能。組織のセキュリティレベルを大幅に向上させる
- IAMロールはサービス間の権限委任に使う。アクセスキーの埋め込みより安全
- クロスアカウントアクセスはロールの
AssumeRoleで実現
次回はEC2(仮想サーバー)を学びます。IAMユーザーでのログインと、AWS CLIの設定が完了していることを確認しておいてください。
参考文献
Lecture 4EC2 — 仮想サーバーを立てる
12:00
EC2 — 仮想サーバーを立てる
はじめに
EC2(Elastic Compute Cloud)は、AWSの最も基本的なコンピューティングサービスです。仮想サーバー(インスタンス)を数分で起動し、必要に応じてスケーリングできます。このレクチャーでは、EC2の基本概念から実際にインスタンスを起動し、SSHで接続するまでを実践します。
EC2の主要コンポーネント
┌─────────────────────────────────────────────────┐
│ EC2インスタンス │
│ │
│ ┌───────────────┐ ┌───────────────┐ │
│ │ AMI │ │ インスタンス │ │
│ │ (OS イメージ) │ → │ タイプ │ │
│ │ Amazon Linux │ │ (t3.micro) │ │
│ └───────────────┘ └───────────────┘ │
│ │
│ ┌───────────────┐ ┌───────────────┐ │
│ │ キーペア │ │ セキュリティ │ │
│ │ (SSH認証) │ │ グループ │ │
│ │ my-key.pem │ │ (ファイア │ │
│ └───────────────┘ │ ウォール) │ │
│ └───────────────┘ │
│ ┌───────────────┐ ┌───────────────┐ │
│ │ EBS │ │ Elastic IP │ │
│ │ (ストレージ) │ │ (固定IP) │ │
│ └───────────────┘ └───────────────┘ │
└─────────────────────────────────────────────────┘
インスタンスタイプ
インスタンスタイプは、仮想サーバーのスペック(CPU、メモリ、ネットワーク)を決めます。
命名規則
t3.micro
│ │ │
│ │ └─ サイズ (nano, micro, small, medium, large, xlarge, 2xlarge...)
│ └──── 世代 (数字が大きいほど新しい)
└────── ファミリー (用途別カテゴリ)
主なインスタンスファミリー
| ファミリー | 用途 | 代表的なタイプ | ユースケース |
|---|---|---|---|
| t3/t4g | 汎用(バースト) | t3.micro, t3.small | Webサーバー、開発環境 |
| m6i/m7g | 汎用(定常) | m6i.large | アプリサーバー |
| c6i/c7g | コンピュート最適化 | c6i.xlarge | バッチ処理、ML推論 |
| r6i/r7g | メモリ最適化 | r6i.large | DB、キャッシュ |
| g5 | GPU | g5.xlarge | 機械学習、動画処理 |
無料枠:
t2.microまたはt3.microが月750時間まで12ヶ月間無料です。学習にはこれで十分です。
AMI(Amazon Machine Image)
AMIは、インスタンスのOSとソフトウェア構成のテンプレートです。
| AMI | 説明 | 用途 |
|---|---|---|
| Amazon Linux 2023 | AWS公式のLinux。最新のパッケージ管理 | 汎用、AWS連携が容易 |
| Ubuntu Server 24.04 LTS | 人気の高いLinuxディストリビューション | Web開発、コンテナ |
| Windows Server 2022 | Microsoft公式のWindows | .NET、Active Directory |
| Red Hat Enterprise Linux 9 | エンタープライズ向け | 企業システム |
EC2インスタンスの起動手順
コンソールから起動
- EC2ダッシュボード →「インスタンスを起動」
- 設定項目:
- 名前:
my-first-instance - AMI: Amazon Linux 2023(無料枠対象)
- インスタンスタイプ:
t3.micro(無料枠対象) - キーペア: 新しいキーペアを作成(
.pem形式) - ネットワーク設定: デフォルトVPC、パブリックIPを自動割り当て
- セキュリティグループ: SSH(ポート22)を自分のIPから許可
- ストレージ: 8 GiB gp3(デフォルト)
- 「インスタンスを起動」をクリック
AWS CLIから起動
# キーペアの作成
aws ec2 create-key-pair \
--key-name my-key \
--query 'KeyMaterial' \
--output text > my-key.pem
# 権限を設定(Linux/macOS)
chmod 400 my-key.pem
# セキュリティグループの作成
aws ec2 create-security-group \
--group-name my-sg \
--description "Allow SSH"
# SSH許可ルールを追加(自分のIPのみ)
MY_IP=$(curl -s https://checkip.amazonaws.com)
aws ec2 authorize-security-group-ingress \
--group-name my-sg \
--protocol tcp \
--port 22 \
--cidr "${MY_IP}/32"
# インスタンスの起動
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type t3.micro \
--key-name my-key \
--security-groups my-sg \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=my-first-instance}]'
注意:
image-idはリージョンによって異なります。東京リージョンのAmazon Linux 2023 AMI IDはコンソールまたは以下のコマンドで確認できます:bash aws ec2 describe-images --owners amazon \ --filters "Name=name,Values=al2023-ami-2023*-x86_64" \ --query 'Images | sort_by(@, &CreationDate) | [-1].ImageId' \ --output text
SSH接続
インスタンスが起動したら、SSHで接続します。
# パブリックIPを確認
aws ec2 describe-instances \
--filters "Name=tag:Name,Values=my-first-instance" \
--query 'Reservations[0].Instances[0].PublicIpAddress' \
--output text
# SSH接続
ssh -i my-key.pem ec2-user@<パブリックIP>
# 接続後の確認コマンド
uname -a # カーネル情報
cat /etc/os-release # OS情報
free -h # メモリ使用量
df -h # ディスク使用量
Windows(PowerShell)の場合:
# OpenSSHを使用
ssh -i my-key.pem ec2-user@<パブリックIP>
# または PuTTY を使用(.pem を .ppk に変換が必要)
ユーザーデータ(User Data)
インスタンス起動時に自動実行されるスクリプトを設定できます。
#!/bin/bash
# Webサーバーの自動セットアップ
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from EC2!</h1>" > /var/www/html/index.html
このスクリプトをユーザーデータに設定すると、インスタンス起動時にApache HTTPサーバーが自動的にインストール・起動されます。
EBSボリューム(ストレージ)
EC2のストレージはEBS(Elastic Block Store)で管理します。
| ボリュームタイプ | IOPS | スループット | 用途 | 料金(東京、1GB/月) |
|---|---|---|---|---|
| gp3 | 3,000(ベース) | 125 MB/s | 汎用(推奨) | 約$0.096 |
| gp2 | サイズ依存 | サイズ依存 | 汎用(旧世代) | 約$0.12 |
| io2 | 最大64,000 | 最大1,000 MB/s | 高性能DB | 約$0.142 |
| st1 | - | 最大500 MB/s | ログ、データ分析 | 約$0.054 |
| sc1 | - | 最大250 MB/s | アーカイブ | 約$0.018 |
無料枠: 30 GBのEBS汎用(SSD)ストレージが12ヶ月間無料です。
EC2の料金モデル
| 料金モデル | 割引率 | 特徴 | ユースケース |
|---|---|---|---|
| オンデマンド | 0%(基準) | 使った分だけ。コミットメントなし | 開発・テスト、変動ワークロード |
| リザーブド (1年) | 約40% | 1年間のコミットメント | 常時稼働のサーバー |
| リザーブド (3年) | 約60% | 3年間のコミットメント | 安定した本番ワークロード |
| スポット | 最大90% | 中断される可能性あり | バッチ処理、テスト、CI/CD |
| Savings Plans | 最大72% | 一定の使用量をコミット | 柔軟な割引プラン |
料金例(東京リージョン、t3.micro)
オンデマンド: $0.0136/時 × 730時間/月 ≒ $9.93/月(約1,500円)
リザーブド (1年全前払い): ≒ $5.84/月(約880円)
スポット: ≒ $0.004/時(約70%割引、ただし中断あり)
セキュリティグループの詳細
セキュリティグループはインスタンスレベルの仮想ファイアウォールです。
インバウンドルール(外部 → EC2):
┌────────┬──────────┬──────────────────┐
│ タイプ │ ポート │ ソース │
├────────┼──────────┼──────────────────┤
│ SSH │ 22 │ 自分のIP/32 │
│ HTTP │ 80 │ 0.0.0.0/0 │
│ HTTPS │ 443 │ 0.0.0.0/0 │
│ Custom │ 3000 │ 10.0.0.0/16 │
└────────┴──────────┴──────────────────┘
アウトバウンドルール(EC2 → 外部):
┌────────┬──────────┬──────────────────┐
│ タイプ │ ポート │ 送信先 │
├────────┼──────────┼──────────────────┤
│ All │ All │ 0.0.0.0/0 │
└────────┴──────────┴──────────────────┘
重要: SSHポート(22)を
0.0.0.0/0(全世界)に公開するのは非常に危険です。必ず自分のIPアドレスに制限しましょう。
実践ワーク
t3.microインスタンスを Amazon Linux 2023 で起動する- キーペアを作成し、SSHで接続する
- ユーザーデータを使ってApache HTTPサーバーを起動し、ブラウザからアクセスする
- セキュリティグループにHTTP(ポート80)のインバウンドルールを追加する
- 重要: 実践が終わったら必ずインスタンスを停止(または終了)して、無料枠の時間を節約する
# インスタンスの停止(課金停止、データ保持)
aws ec2 stop-instances --instance-ids i-xxxxxxxxxxxx
# インスタンスの終了(完全削除、EBSも削除される場合あり)
aws ec2 terminate-instances --instance-ids i-xxxxxxxxxxxx
まとめと次回の準備
- EC2はAWSの基本的な仮想サーバーサービス。数分でサーバーを起動可能
- インスタンスタイプはファミリー・世代・サイズの3要素で構成。学習にはt3.microを使用
- AMIはOSイメージ。Amazon Linux 2023が推奨
- キーペアはSSH接続に必須。秘密鍵(.pem)は厳重に管理
- セキュリティグループでファイアウォールルールを制御。SSHは自分のIPに制限
- 料金モデルを理解し、用途に応じた最適な選択をする
- 使い終わったインスタンスは必ず停止・終了する
次回はS3(ストレージサービス)を学びます。EC2インスタンスからS3にデータをアップロードする練習もしますので、IAMロールの復習をしておいてください。
参考文献
Lecture 5S3 — ストレージとCDN
12:00
S3 — ストレージとCDN
はじめに
S3(Simple Storage Service)は、AWSで最も多く使われるストレージサービスです。99.999999999%(イレブンナイン)の耐久性を誇り、画像・動画・ログ・バックアップなど、あらゆるデータを保存できます。このレクチャーでは、S3の基本操作からストレージクラスの使い分け、静的Webサイトホスティング、そしてCloudFront(CDN)との連携までを学びます。
S3の基本概念
┌─ S3 ──────────────────────────────────────────┐
│ │
│ ┌─ バケット (Bucket) ────────────────────┐ │
│ │ 名前: my-app-bucket-2024 │ │
│ │ リージョン: ap-northeast-1 │ │
│ │ │ │
│ │ ┌─ オブジェクト (Object) ────────┐ │ │
│ │ │ キー: images/logo.png │ │ │
│ │ │ 値: (バイナリデータ) │ │ │
│ │ │ メタデータ: Content-Type 等 │ │ │
│ │ │ サイズ: 最大5TB │ │ │
│ │ └──────────────────────────────┘ │ │
│ │ │ │
│ │ ┌─ プレフィックス(擬似フォルダ)─┐ │ │
│ │ │ images/ │ │ │
│ │ │ ├── logo.png │ │ │
│ │ │ ├── banner.jpg │ │ │
│ │ │ css/ │ │ │
│ │ │ ├── style.css │ │ │
│ │ └──────────────────────────────┘ │ │
│ └────────────────────────────────────────┘ │
└────────────────────────────────────────────────┘
| 概念 | 説明 | 制約 |
|---|---|---|
| バケット | オブジェクトのコンテナ | 名前はグローバルで一意、3-63文字 |
| オブジェクト | ファイル本体 + メタデータ | 最大5TB/個 |
| キー | オブジェクトの識別子(パス) | UTF-8、最大1,024バイト |
| プレフィックス | キーの先頭部分(擬似フォルダ) | フォルダという概念は存在しない |
S3の基本操作(CLI)
# バケットの作成
aws s3 mb s3://my-learning-bucket-2024 --region ap-northeast-1
# ファイルのアップロード
aws s3 cp index.html s3://my-learning-bucket-2024/
# フォルダごとアップロード(再帰的)
aws s3 sync ./website/ s3://my-learning-bucket-2024/website/
# ファイル一覧の表示
aws s3 ls s3://my-learning-bucket-2024/
aws s3 ls s3://my-learning-bucket-2024/ --recursive
# ファイルのダウンロード
aws s3 cp s3://my-learning-bucket-2024/index.html ./downloaded.html
# ファイルの削除
aws s3 rm s3://my-learning-bucket-2024/index.html
# バケット内の全ファイルを削除
aws s3 rm s3://my-learning-bucket-2024/ --recursive
# バケットの削除(空のバケットのみ)
aws s3 rb s3://my-learning-bucket-2024
ストレージクラス
S3はアクセス頻度とコストのバランスに応じて複数のストレージクラスを提供しています。
| ストレージクラス | 耐久性 | 取り出し | 料金(東京/GB/月) | ユースケース |
|---|---|---|---|---|
| S3 Standard | 99.999999999% | 即時 | $0.025 | アクティブなデータ |
| S3 Standard-IA | 99.999999999% | 即時 | $0.019 | 低頻度アクセス(30日以上保存) |
| S3 One Zone-IA | 99.999999999% | 即時 | $0.0152 | 再作成可能なデータ |
| S3 Glacier IR | 99.999999999% | ミリ秒 | $0.005 | アーカイブ(即時取得) |
| S3 Glacier Flexible | 99.999999999% | 分〜時間 | $0.0045 | 長期アーカイブ |
| S3 Glacier Deep Archive | 99.999999999% | 12〜48時間 | $0.002 | 10年以上の保管 |
| S3 Intelligent-Tiering | 99.999999999% | 即時 | 自動最適化 | アクセスパターン不明 |
コスト低い ←────────────────────────→ コスト高い
アクセス遅い アクセス速い
Deep Archive Glacier Glacier IR One Zone-IA Standard-IA Standard
$0.002 $0.0045 $0.005 $0.0152 $0.019 $0.025
バージョニング
バケットのバージョニングを有効にすると、オブジェクトの全バージョンを保持できます。
# バージョニングの有効化
aws s3api put-bucket-versioning \
--bucket my-learning-bucket-2024 \
--versioning-configuration Status=Enabled
# バージョン一覧の表示
aws s3api list-object-versions --bucket my-learning-bucket-2024
# 特定バージョンのダウンロード
aws s3api get-object \
--bucket my-learning-bucket-2024 \
--key index.html \
--version-id "xxxxxxxxxxxx" \
downloaded-old.html
注意: バージョニングを有効にすると、削除したファイルも「削除マーカー」として残ります。ストレージコストが増加するため、ライフサイクルポリシーと組み合わせて使いましょう。
ライフサイクルポリシー
データのライフサイクルを自動管理するルールを設定できます。
{
"Rules": [
{
"ID": "MoveToIAAfter30Days",
"Status": "Enabled",
"Filter": {
"Prefix": "logs/"
},
"Transitions": [
{
"Days": 30,
"StorageClass": "STANDARD_IA"
},
{
"Days": 90,
"StorageClass": "GLACIER"
},
{
"Days": 365,
"StorageClass": "DEEP_ARCHIVE"
}
],
"Expiration": {
"Days": 730
}
}
]
}
ライフサイクルの例:
作成 → 30日 → 90日 → 365日 → 730日
│ │ │ │ │
│ │ │ │ └─ 削除
│ │ │ └─ Deep Archive
│ │ └─ Glacier
│ └─ Standard-IA
└─ Standard
静的Webサイトホスティング
S3はHTML/CSS/JSなどの静的ファイルをWebサイトとして公開できます。
設定手順
# 1. バケットの作成
aws s3 mb s3://my-static-site-2024
# 2. 静的ウェブサイトホスティングの有効化
aws s3 website s3://my-static-site-2024 \
--index-document index.html \
--error-document error.html
# 3. パブリックアクセスブロックの解除(公開サイトの場合)
aws s3api put-public-access-block \
--bucket my-static-site-2024 \
--public-access-block-configuration \
"BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false"
# 4. バケットポリシーの設定(公開読み取り)
aws s3api put-bucket-policy --bucket my-static-site-2024 --policy '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-static-site-2024/*"
}
]
}'
# 5. ファイルのアップロード
aws s3 sync ./website/ s3://my-static-site-2024/
アクセスURL: http://my-static-site-2024.s3-website-ap-northeast-1.amazonaws.com
CloudFront CDN の基本
CloudFrontは、S3のコンテンツを世界中のエッジロケーション(400以上)にキャッシュして高速配信するCDNサービスです。
ユーザー (東京) ユーザー (NY)
│ │
↓ ↓
┌──────────┐ ┌──────────┐
│ エッジ │ │ エッジ │
│ (東京) │ │ (NY) │
└────┬─────┘ └────┬─────┘
│ キャッシュミス時のみ │
└──────────┬───────────────────┘
↓
┌───────────┐
│ S3 バケット │ ← オリジン(東京リージョン)
│ (東京) │
└───────────┘
CloudFront + S3 の利点
| 項目 | S3単体 | CloudFront + S3 |
|---|---|---|
| HTTPS | 独自ドメイン不可 | ACM証明書で無料SSL |
| レイテンシ | リージョン依存 | エッジロケーションで低遅延 |
| 料金 | データ転送料 | 転送料が安い場合あり |
| セキュリティ | バケットポリシー | OAC(Origin Access Control) |
署名付きURL(Pre-signed URL)
プライベートなS3オブジェクトへの一時的なアクセスを許可するURLを発行できます。
# 署名付きURLの生成(有効期限: 3600秒 = 1時間)
aws s3 presign s3://my-bucket/secret-file.pdf --expires-in 3600
# 出力例:
# https://my-bucket.s3.ap-northeast-1.amazonaws.com/secret-file.pdf
# ?X-Amz-Algorithm=AWS4-HMAC-SHA256
# &X-Amz-Credential=...
# &X-Amz-Date=20240101T000000Z
# &X-Amz-Expires=3600
# &X-Amz-Signature=...
ユースケース: ユーザーが購入したデジタルコンテンツのダウンロードリンク、一時的なファイル共有など。
実践ワーク
- S3バケットを作成し、ファイルをアップロード・ダウンロードする
- バージョニングを有効にし、同じファイルを2回アップロードしてバージョン一覧を確認する
- 簡単なHTML/CSSを作成し、S3静的ウェブサイトホスティングで公開する
- 署名付きURLを生成し、プライベートなファイルにアクセスする
- 重要: 実践後、不要なバケットとオブジェクトを削除してコストを抑える
# 後片付け
aws s3 rm s3://my-learning-bucket-2024/ --recursive
aws s3 rb s3://my-learning-bucket-2024
まとめと次回の準備
- S3はイレブンナインの耐久性を持つオブジェクトストレージ。バケットとオブジェクトで構成
- ストレージクラスを使い分けてコストを最適化。ライフサイクルポリシーで自動化
- バージョニングで誤削除を防止。ライフサイクルと組み合わせて管理
- 静的WebサイトホスティングでHTML/CSS/JSサイトを低コストで公開
- CloudFront(CDN)でグローバル配信を高速化し、HTTPSを実現
- 署名付きURLでプライベートコンテンツへの一時アクセスを提供
次回はVPC(Virtual Private Cloud)を学びます。ネットワークの基礎知識(IPアドレス、サブネット、CIDR表記)を予習しておくと理解が深まります。
参考文献
Lecture 6VPC — ネットワークの基礎
12:00
VPC — ネットワークの基礎
はじめに
VPC(Virtual Private Cloud)は、AWS上に論理的に分離されたプライベートネットワークを構築するサービスです。EC2やRDSなどのリソースはすべてVPC内に配置されます。ネットワークの設計はセキュリティと可用性の基盤であり、クラウドエンジニアにとって最も重要なスキルの一つです。
VPCアーキテクチャの全体像
┌─ VPC (10.0.0.0/16) ─────────────────────────────────────────┐
│ │
│ ┌─ AZ-a ──────────────────┐ ┌─ AZ-c ──────────────────┐ │
│ │ │ │ │ │
│ │ ┌─ パブリックサブネット ─┐│ │ ┌─ パブリックサブネット ─┐│ │
│ │ │ 10.0.1.0/24 ││ │ │ 10.0.2.0/24 ││ │
│ │ │ ┌─────┐ ┌─────┐ ││ │ │ ┌─────┐ ┌─────┐ ││ │
│ │ │ │ ALB │ │ NAT │ ││ │ │ │ ALB │ │Bastn│ ││ │
│ │ │ └─────┘ └─────┘ ││ │ │ └─────┘ └─────┘ ││ │
│ │ └──────────────────────┘│ │ └──────────────────────┘│ │
│ │ │ │ │ │
│ │ ┌─ プライベートサブネット┐│ │ ┌─ プライベートサブネット┐│ │
│ │ │ 10.0.11.0/24 ││ │ │ 10.0.12.0/24 ││ │
│ │ │ ┌─────┐ ┌─────┐ ││ │ │ ┌─────┐ ┌─────┐ ││ │
│ │ │ │ EC2 │ │ EC2 │ ││ │ │ │ EC2 │ │ EC2 │ ││ │
│ │ │ └─────┘ └─────┘ ││ │ │ └─────┘ └─────┘ ││ │
│ │ └──────────────────────┘│ │ └──────────────────────┘│ │
│ │ │ │ │ │
│ │ ┌─ DBサブネット ────────┐│ │ ┌─ DBサブネット ────────┐│ │
│ │ │ 10.0.21.0/24 ││ │ │ 10.0.22.0/24 ││ │
│ │ │ ┌─────┐ ││ │ │ ┌─────┐ ││ │
│ │ │ │ RDS │ (Primary) ││ │ │ │ RDS │ (Standby) ││ │
│ │ │ └─────┘ ││ │ │ └─────┘ ││ │
│ │ └──────────────────────┘│ │ └──────────────────────┘│ │
│ └──────────────────────────┘ └──────────────────────────┘ │
│ │
│ ┌──────────────┐ │
│ │ Internet GW │ ← インターネットへの出入口 │
│ └──────────────┘ │
└───────────────────────────────────────────────────────────────┘
CIDR表記の基礎
VPCとサブネットのIPアドレス範囲はCIDR(Classless Inter-Domain Routing)表記で指定します。
10.0.0.0/16 → IPアドレスの範囲を指定
│ │
│ └─ プレフィックス長(ネットワーク部のビット数)
└─ ネットワークアドレス
/16 → 65,536個のIPアドレス (2^16 = 65,536)
/24 → 256個のIPアドレス (2^8 = 256)
/28 → 16個のIPアドレス (2^4 = 16)
| CIDR | IPアドレス数 | 用途例 |
|---|---|---|
/16 |
65,536 | VPC全体 |
/20 |
4,096 | 大規模サブネット |
/24 |
256 | 標準的なサブネット |
/28 |
16 | 小規模サブネット(最小) |
AWSの制約: VPCのCIDRは
/16(最大)から/28(最小)まで。各サブネットで5つのIPアドレスはAWSが予約するため、実際に使えるのは割り当て数 - 5 です。
パブリックサブネット vs プライベートサブネット
| 項目 | パブリックサブネット | プライベートサブネット |
|---|---|---|
| インターネットアクセス | 直接アクセス可能 | NATゲートウェイ経由 |
| パブリックIP | 自動割り当て可能 | なし |
| 用途 | ALB、踏み台サーバー、NAT GW | アプリサーバー、DBサーバー |
| ルートテーブル | 0.0.0.0/0 → IGW | 0.0.0.0/0 → NAT GW |
インターネット
│
┌────┴─────┐
│ Internet │
│ Gateway │
└────┬─────┘
│
─────┼──────────────── パブリックサブネット
│ │
┌────┴───┐ ┌──┴──┐
│ ALB │ │ NAT │
└────┬───┘ │ GW │
│ └──┬──┘
─────┼─────────┼──── プライベートサブネット
│ │
┌────┴───┐ │ (アウトバウンドのみ)
│ EC2 │ ────┘
└────────┘
VPCの構築手順(CLI)
ステップ1:VPCの作成
# VPCの作成
VPC_ID=$(aws ec2 create-vpc \
--cidr-block 10.0.0.0/16 \
--tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=my-vpc}]' \
--query 'Vpc.VpcId' --output text)
echo "VPC ID: $VPC_ID"
# DNSホスト名を有効化
aws ec2 modify-vpc-attribute --vpc-id $VPC_ID --enable-dns-hostnames
ステップ2:サブネットの作成
# パブリックサブネット(AZ-a)
PUB_SUB_A=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.1.0/24 \
--availability-zone ap-northeast-1a \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=public-subnet-a}]' \
--query 'Subnet.SubnetId' --output text)
# パブリックサブネット(AZ-c)
PUB_SUB_C=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.2.0/24 \
--availability-zone ap-northeast-1c \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=public-subnet-c}]' \
--query 'Subnet.SubnetId' --output text)
# プライベートサブネット(AZ-a)
PRIV_SUB_A=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.11.0/24 \
--availability-zone ap-northeast-1a \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=private-subnet-a}]' \
--query 'Subnet.SubnetId' --output text)
# プライベートサブネット(AZ-c)
PRIV_SUB_C=$(aws ec2 create-subnet \
--vpc-id $VPC_ID \
--cidr-block 10.0.12.0/24 \
--availability-zone ap-northeast-1c \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=private-subnet-c}]' \
--query 'Subnet.SubnetId' --output text)
ステップ3:インターネットゲートウェイ
# IGWの作成とアタッチ
IGW_ID=$(aws ec2 create-internet-gateway \
--tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=my-igw}]' \
--query 'InternetGateway.InternetGatewayId' --output text)
aws ec2 attach-internet-gateway --internet-gateway-id $IGW_ID --vpc-id $VPC_ID
ステップ4:ルートテーブル
# パブリック用ルートテーブル
PUB_RT=$(aws ec2 create-route-table \
--vpc-id $VPC_ID \
--tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=public-rt}]' \
--query 'RouteTable.RouteTableId' --output text)
# インターネットへのルートを追加
aws ec2 create-route \
--route-table-id $PUB_RT \
--destination-cidr-block 0.0.0.0/0 \
--gateway-id $IGW_ID
# パブリックサブネットにルートテーブルを関連付け
aws ec2 associate-route-table --route-table-id $PUB_RT --subnet-id $PUB_SUB_A
aws ec2 associate-route-table --route-table-id $PUB_RT --subnet-id $PUB_SUB_C
ステップ5:NATゲートウェイ(プライベートサブネットのアウトバウンド用)
# Elastic IPの割り当て
EIP_ID=$(aws ec2 allocate-address --domain vpc --query 'AllocationId' --output text)
# NATゲートウェイの作成(パブリックサブネットに配置)
NAT_ID=$(aws ec2 create-nat-gateway \
--subnet-id $PUB_SUB_A \
--allocation-id $EIP_ID \
--tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=my-nat}]' \
--query 'NatGateway.NatGatewayId' --output text)
# プライベート用ルートテーブル
PRIV_RT=$(aws ec2 create-route-table \
--vpc-id $VPC_ID \
--tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=private-rt}]' \
--query 'RouteTable.RouteTableId' --output text)
# NATゲートウェイへのルートを追加
aws ec2 create-route \
--route-table-id $PRIV_RT \
--destination-cidr-block 0.0.0.0/0 \
--nat-gateway-id $NAT_ID
# プライベートサブネットにルートテーブルを関連付け
aws ec2 associate-route-table --route-table-id $PRIV_RT --subnet-id $PRIV_SUB_A
aws ec2 associate-route-table --route-table-id $PRIV_RT --subnet-id $PRIV_SUB_C
コスト注意: NATゲートウェイは時間課金(約$0.062/時、月約$45)+ データ転送料($0.062/GB)がかかります。学習時は使い終わったら削除しましょう。
セキュリティグループ vs ネットワークACL
| 項目 | セキュリティグループ (SG) | ネットワークACL (NACL) |
|---|---|---|
| レベル | インスタンス(ENI) | サブネット |
| ステートフル | はい(戻りの通信は自動許可) | いいえ(両方向のルールが必要) |
| ルール | 許可のみ | 許可 + 拒否 |
| 評価順 | 全ルールを評価 | ルール番号の小さい順 |
| デフォルト | 全インバウンド拒否 | 全トラフィック許可 |
| 推奨用途 | 通常のアクセス制御 | サブネットレベルの追加防御 |
外部トラフィック
│
┌────┴────────┐
│ NACL │ ← サブネットレベル(1次フィルタ)
│ ルール100: │ ステートレス
│ Allow 443 │
└────┬────────┘
│
┌────┴────────┐
│ セキュリティ │ ← インスタンスレベル(2次フィルタ)
│ グループ │ ステートフル
│ Allow 443 │
└────┬────────┘
│
┌────┴────┐
│ EC2 │
└─────────┘
VPC設計のベストプラクティス
- マルチAZ構成: 最低2つのAZにサブネットを配置し、可用性を確保
- 3層サブネット: パブリック / プライベート(アプリ) / プライベート(DB)の3層構成
- CIDRの余裕: 将来の拡張を見据えて
/16で確保し、サブネットは/24で分割 - NATゲートウェイ: 各AZに1つずつ配置してAZ障害に対応(コスト優先なら1つでも可)
- VPCフローログ: 通信ログを有効にしてセキュリティ監査に活用
実践ワーク
- 上記の手順に従ってVPCを構築する(パブリックサブネット2つ + プライベートサブネット2つ)
- パブリックサブネットにEC2インスタンスを起動し、インターネットからSSH接続できることを確認
- プライベートサブネットにEC2インスタンスを起動し、パブリックサブネットの踏み台経由で接続
- VPCフローログを有効にし、CloudWatch Logsで通信ログを確認
- 重要: NATゲートウェイとElastic IPは使い終わったら削除する(月約$45のコスト)
# 後片付け
aws ec2 delete-nat-gateway --nat-gateway-id $NAT_ID
# NATゲートウェイ削除完了後に実行
aws ec2 release-address --allocation-id $EIP_ID
aws ec2 terminate-instances --instance-ids <instance-id>
まとめと次回の準備
- VPCはAWSにおけるネットワークの基盤。すべてのリソースはVPC内に存在する
- CIDR表記でIPアドレス範囲を指定。VPCは
/16、サブネットは/24が一般的 - パブリックサブネットはインターネットゲートウェイ経由で外部と通信
- プライベートサブネットはNATゲートウェイ経由でアウトバウンドのみ
- セキュリティグループ(ステートフル)とNACL(ステートレス)の2層防御
- マルチAZ構成で可用性を確保するのがベストプラクティス
次回はRDS(マネージドデータベース)を学びます。VPCのプライベートサブネットにRDSを配置する構成を実践しますので、今回構築したVPCを残しておいてください。
参考文献
Lecture 7RDS — マネージドデータベース
12:00
RDS — マネージドデータベース
はじめに
RDS(Relational Database Service)は、AWSが提供するフルマネージドのリレーショナルデータベースサービスです。OS のパッチ適用、バックアップ、スケーリング、フェイルオーバーなど、データベースの運用タスクをAWSが自動的に処理してくれます。このレクチャーでは、RDSの基本概念から高可用性構成、そしてDynamoDB との使い分けまでを学びます。
なぜRDSを使うのか?
EC2にMySQL等を自分でインストールすることも可能ですが、運用負荷が大きく異なります。
| 運用タスク | EC2上にDB構築 | RDS |
|---|---|---|
| OSパッチ適用 | 自分で実施 | AWS自動 |
| DBエンジン更新 | 自分で実施 | ワンクリック |
| バックアップ | 自分でスクリプト | 自動(35日保持) |
| フェイルオーバー | 自分で構築 | Multi-AZ で自動 |
| スケーリング | 手動でインスタンス変更 | コンソールから変更 |
| モニタリング | 自分で設定 | CloudWatch統合済み |
| 暗号化 | 自分で設定 | ワンクリック |
対応データベースエンジン
| エンジン | バージョン例 | 特徴 | ユースケース |
|---|---|---|---|
| MySQL | 8.0 | 最もポピュラー | Webアプリ全般 |
| PostgreSQL | 16 | 高機能、拡張性 | 地理データ、JSON |
| MariaDB | 10.11 | MySQL互換、オープンソース | MySQL代替 |
| Oracle | 19c, 21c | エンタープライズ | 基幹業務システム |
| SQL Server | 2019, 2022 | Microsoft製 | .NETアプリ |
| Aurora (MySQL) | MySQL 8.0互換 | AWS独自、高性能 | 大規模Webアプリ |
| Aurora (PostgreSQL) | PostgreSQL 16互換 | AWS独自、高性能 | 高スループット |
Aurora の特長
通常のRDS Aurora
┌──────────┐ ┌──────────┐
│ DB │ │ DB │
│ Instance │ │ Instance │
└────┬─────┘ └────┬─────┘
│ │
┌────┴─────┐ ┌─────────┴──────────┐
│ EBS │ │ Aurora Storage │
│ (単一AZ) │ │ (3 AZ × 2コピー │
└──────────┘ │ = 6コピー自動) │
└────────────────────┘
Aurora は通常のRDSと比べて最大5倍(MySQL)/ 3倍(PostgreSQL)の性能を発揮し、ストレージは自動的に10GBから128TBまでスケールします。
RDSインスタンスの作成
コンソールから作成
- RDSダッシュボード →「データベースの作成」
- 設定項目:
- エンジン: MySQL 8.0
- テンプレート: 無料利用枠
- DBインスタンス識別子:
my-first-db - マスターユーザー名:
admin - パスワード: 強力なパスワードを設定
- インスタンスクラス:
db.t3.micro(無料枠対象) - ストレージ: 20 GiB gp2
- VPC: 前回作成したVPC
- サブネットグループ: プライベートサブネットを選択
- パブリックアクセス: いいえ
AWS CLIから作成
# DBサブネットグループの作成(プライベートサブネットを指定)
aws rds create-db-subnet-group \
--db-subnet-group-name my-db-subnet-group \
--db-subnet-group-description "Private subnets for RDS" \
--subnet-ids $PRIV_SUB_A $PRIV_SUB_C
# DB用セキュリティグループの作成
DB_SG=$(aws ec2 create-security-group \
--group-name rds-sg \
--description "Security group for RDS" \
--vpc-id $VPC_ID \
--query 'GroupId' --output text)
# アプリサーバーのSGからMySQL(3306)を許可
aws ec2 authorize-security-group-ingress \
--group-id $DB_SG \
--protocol tcp \
--port 3306 \
--source-group $APP_SG_ID
# RDSインスタンスの作成
aws rds create-db-instance \
--db-instance-identifier my-first-db \
--db-instance-class db.t3.micro \
--engine mysql \
--engine-version 8.0 \
--master-username admin \
--master-user-password 'YourStr0ng!Pass' \
--allocated-storage 20 \
--storage-type gp2 \
--db-subnet-group-name my-db-subnet-group \
--vpc-security-group-ids $DB_SG \
--no-publicly-accessible \
--backup-retention-period 7 \
--storage-encrypted
無料枠:
db.t3.microが月750時間まで12ヶ月間無料。ストレージ20GBまで無料。
Multi-AZ構成(高可用性)
Multi-AZを有効にすると、別のAZにスタンバイレプリカが自動的に作成され、プライマリに障害が発生した場合に自動フェイルオーバーします。
┌─ AZ-a ──────────┐ ┌─ AZ-c ──────────┐
│ │ │ │
│ ┌────────────┐ │ │ ┌────────────┐ │
│ │ Primary │ │ 同期 │ │ Standby │ │
│ │ DB │──┼──→──┼──│ DB │ │
│ │ (R/W) │ │ レプリ│ │ (待機) │ │
│ └────────────┘ │ ケーション│ └────────────┘ │
│ │ │ │
└──────────────────┘ └──────────────────┘
障害発生時: DNS切り替えで自動フェイルオーバー(60〜120秒)
アプリ側の接続先(エンドポイント)は変わらない
# 既存のインスタンスをMulti-AZに変更
aws rds modify-db-instance \
--db-instance-identifier my-first-db \
--multi-az \
--apply-immediately
コスト: Multi-AZはインスタンス料金が約2倍になります。本番環境では必須ですが、学習時はシングルAZで十分です。
リードレプリカ
読み取り負荷を分散するために、リードレプリカ(読み取り専用のコピー)を作成できます。
アプリケーション
├─ 書き込み → Primary DB
│ │
│ 非同期レプリケーション
│ │
└─ 読み取り → Read Replica (1)
Read Replica (2)
Read Replica (3) ← 最大15個(Aurora)
# リードレプリカの作成
aws rds create-db-instance-read-replica \
--db-instance-identifier my-first-db-replica \
--source-db-instance-identifier my-first-db \
--db-instance-class db.t3.micro
# リードレプリカのエンドポイントを確認
aws rds describe-db-instances \
--db-instance-identifier my-first-db-replica \
--query 'DBInstances[0].Endpoint'
バックアップと復元
RDSは自動バックアップとスナップショットの2種類のバックアップを提供します。
| バックアップ種類 | 説明 | 保持期間 | コスト |
|---|---|---|---|
| 自動バックアップ | 毎日のバックアップ + トランザクションログ | 1〜35日(設定可) | インスタンスストレージと同量まで無料 |
| 手動スナップショット | 任意のタイミングで取得 | 無期限(手動削除まで) | ストレージ料金がかかる |
# 手動スナップショットの作成
aws rds create-db-snapshot \
--db-snapshot-identifier my-db-snapshot-20240101 \
--db-instance-identifier my-first-db
# スナップショットからの復元(新しいインスタンスとして復元される)
aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier my-restored-db \
--db-snapshot-identifier my-db-snapshot-20240101
# ポイントインタイムリカバリ(特定の日時に復元)
aws rds restore-db-instance-to-point-in-time \
--source-db-instance-identifier my-first-db \
--target-db-instance-identifier my-pitr-db \
--restore-time "2024-01-15T10:30:00Z"
パラメータグループ
データベースエンジンの設定(my.cnf や postgresql.conf に相当)をパラメータグループで管理します。
# カスタムパラメータグループの作成
aws rds create-db-parameter-group \
--db-parameter-group-name my-mysql-params \
--db-parameter-group-family mysql8.0 \
--description "Custom MySQL 8.0 parameters"
# パラメータの変更
aws rds modify-db-parameter-group \
--db-parameter-group-name my-mysql-params \
--parameters "ParameterName=character_set_server,ParameterValue=utf8mb4,ApplyMethod=pending-reboot" \
"ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate"
# パラメータグループをインスタンスに適用
aws rds modify-db-instance \
--db-instance-identifier my-first-db \
--db-parameter-group-name my-mysql-params \
--apply-immediately
RDS vs DynamoDB の使い分け
| 項目 | RDS | DynamoDB |
|---|---|---|
| データモデル | リレーショナル(テーブル・結合) | キーバリュー / ドキュメント |
| スキーマ | 固定スキーマ | スキーマレス |
| スケーリング | 垂直スケーリング(インスタンスクラス変更) | 水平スケーリング(自動) |
| クエリ | SQL | API(GetItem, Query, Scan) |
| トランザクション | ACID完全サポート | 制限付きサポート |
| レイテンシ | ミリ秒 | 1桁ミリ秒 |
| 料金モデル | インスタンス時間課金 | リクエスト数 + ストレージ |
| ユースケース | 複雑なクエリ、既存RDBの移行 | 高スループット、IoT、ゲーム |
選択指針: 「既存のRDBアプリの移行」や「複雑なJOINが必要」→ RDS、「大量の読み書きが必要」や「スキーマが頻繁に変わる」→ DynamoDB
RDS料金の目安(東京リージョン)
| インスタンスクラス | vCPU | メモリ | オンデマンド(月額概算) |
|---|---|---|---|
| db.t3.micro | 2 | 1 GiB | 約$18.40(無料枠対象) |
| db.t3.small | 2 | 2 GiB | 約$36.79 |
| db.t3.medium | 2 | 4 GiB | 約$73.58 |
| db.r6g.large | 2 | 16 GiB | 約$235 |
| db.r6g.xlarge | 4 | 32 GiB | 約$470 |
実践ワーク
- VPCのプライベートサブネットにRDS(MySQL 8.0, db.t3.micro)を作成する
- パブリックサブネットのEC2からRDSに接続する
# EC2からRDSに接続(mysqlクライアント)
sudo yum install -y mysql
mysql -h my-first-db.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com \
-u admin -p
# テスト用データベース・テーブルの作成
CREATE DATABASE testdb;
USE testdb;
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(255),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO users (name, email) VALUES ('田中太郎', 'tanaka@example.com');
SELECT * FROM users;
- 手動スナップショットを取得し、復元できることを確認する
- 重要: 実践後、RDSインスタンスを削除して課金を止める
# RDSインスタンスの削除(最終スナップショット不要の場合)
aws rds delete-db-instance \
--db-instance-identifier my-first-db \
--skip-final-snapshot
まとめと次回の準備
- RDSはフルマネージドのRDB。パッチ適用、バックアップ、フェイルオーバーが自動化
- 6つのエンジン + Auroraに対応。MySQLとPostgreSQLが最も人気
- Multi-AZで高可用性、リードレプリカで読み取り負荷の分散
- 自動バックアップとポイントインタイムリカバリで最大35日前まで復元可能
- パラメータグループでDB設定をコード管理
- DynamoDBはNoSQLの選択肢。ユースケースに応じて使い分ける
次回はLambdaとAPI Gatewayを学び、サーバーレスアーキテクチャの世界に踏み込みます。モジュール2のスタートです。
参考文献
Lecture 8Lambda・API Gateway — サーバーレス入門
12:00
Lambda・API Gateway — サーバーレス入門
はじめに
サーバーレスコンピューティングは、サーバーの管理を一切必要とせず、コードの実行だけに集中できるアーキテクチャです。AWS Lambda はイベント駆動でコードを実行し、API Gateway と組み合わせることでREST API を迅速に構築できます。このレクチャーでは、Lambda の基本概念から API Gateway との連携、そして SAM(Serverless Application Model)によるデプロイまでを実践します。
サーバーレスとは
従来型(EC2ベース) サーバーレス(Lambda)
┌──────────────────┐ ┌──────────────────┐
│ OS管理 │ │ ──────────────── │
│ ランタイム管理 │ │ ──────────────── │
│ スケーリング設定 │ │ ──────────────── │
│ セキュリティパッチ │ │ ──────────────── │
│ │ │ │
│ ┌──────────────┐ │ │ ┌──────────────┐ │
│ │ アプリコード │ │ │ │ アプリコード │ │
│ └──────────────┘ │ │ └──────────────┘ │
└──────────────────┘ └──────────────────┘
全部自分で管理 コードだけ書けばOK
──── = AWSが管理
| 項目 | EC2 | Lambda |
|---|---|---|
| サーバー管理 | 自分で管理 | 不要 |
| スケーリング | Auto Scaling設定が必要 | 自動(同時実行1,000まで) |
| 課金 | 稼働時間で課金 | 実行回数 + 実行時間で課金 |
| 最大実行時間 | 無制限 | 15分 |
| 起動時間 | 秒〜分 | ミリ秒〜秒(コールドスタート) |
| OS/ランタイム | 自由 | 対応ランタイムのみ |
Lambda の基本概念
対応ランタイム
| ランタイム | バージョン | ユースケース |
|---|---|---|
| Python | 3.12, 3.13 | データ処理、API、自動化 |
| Node.js | 18.x, 20.x | API、Webバックエンド |
| Java | 11, 17, 21 | エンタープライズ |
| Go | provided.al2023 | 高性能処理 |
| Ruby | 3.3 | WebAPI |
| .NET | 8 | Microsoftエコシステム |
| カスタム | provided.al2023 | Rust、C++等 |
Lambda関数の構造(Python)
import json
def lambda_handler(event, context):
"""
event: トリガーからの入力データ(辞書型)
context: 実行環境の情報(関数名、残り実行時間等)
"""
# リクエストボディの取得
body = json.loads(event.get('body', '{}'))
name = body.get('name', 'World')
# レスポンスの作成
response = {
'statusCode': 200,
'headers': {
'Content-Type': 'application/json',
'Access-Control-Allow-Origin': '*'
},
'body': json.dumps({
'message': f'Hello, {name}!',
'function_name': context.function_name,
'remaining_time_ms': context.get_remaining_time_in_millis()
})
}
return response
Lambda関数の構造(Node.js)
export const handler = async (event, context) => {
const body = JSON.parse(event.body || '{}');
const name = body.name || 'World';
return {
statusCode: 200,
headers: {
'Content-Type': 'application/json',
'Access-Control-Allow-Origin': '*'
},
body: JSON.stringify({
message: `Hello, ${name}!`,
functionName: context.functionName,
remainingTimeMs: context.getRemainingTimeInMillis()
})
};
};
Lambda関数の作成と実行
AWS CLIで作成
# 1. Lambda用のIAMロールを作成
aws iam create-role \
--role-name lambda-basic-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Service": "lambda.amazonaws.com"},
"Action": "sts:AssumeRole"
}]
}'
# CloudWatch Logsへの書き込み権限を付与
aws iam attach-role-policy \
--role-name lambda-basic-role \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
# 2. コードをZIPに圧縮
zip function.zip lambda_function.py
# 3. Lambda関数を作成
aws lambda create-function \
--function-name hello-function \
--runtime python3.12 \
--role arn:aws:iam::<ACCOUNT_ID>:role/lambda-basic-role \
--handler lambda_function.lambda_handler \
--zip-file fileb://function.zip \
--timeout 30 \
--memory-size 128
# 4. テスト実行
aws lambda invoke \
--function-name hello-function \
--payload '{"body": "{\"name\": \"AWS\"}"}' \
response.json
cat response.json
Lambdaのトリガー
Lambda関数はさまざまなAWSサービスからトリガーできます。
┌─────────────┐
│ API Gateway │──→┐
└─────────────┘ │
┌─────────────┐ │ ┌──────────────┐
│ S3 Event │──→┼──→│ Lambda │──→ DynamoDB / S3 / SNS
└─────────────┘ │ │ Function │
┌─────────────┐ │ └──────────────┘
│ CloudWatch │──→┤
│ Events/Cron │ │
└─────────────┘ │
┌─────────────┐ │
│ SQS Queue │──→┤
└─────────────┘ │
┌─────────────┐ │
│ DynamoDB │──→┘
│ Streams │
└─────────────┘
| トリガー | ユースケース |
|---|---|
| API Gateway | REST/HTTP APIのバックエンド |
| S3 | ファイルアップロード時の画像処理、変換 |
| CloudWatch Events | 定期実行(cron)、スケジュールタスク |
| SQS | 非同期処理、メッセージキュー |
| DynamoDB Streams | データ変更時のリアクティブ処理 |
| SNS | 通知、ファンアウト |
Lambda Layers
共通ライブラリをLayerとして管理し、複数の関数で共有できます。
┌──────────────┐ ┌──────────────┐
│ Function A │ │ Function B │
└──────┬───────┘ └──────┬───────┘
│ │
└────────┬─────────┘
│
┌────────┴────────┐
│ Layer │
│ (共通ライブラリ) │
│ requests │
│ pandas │
│ numpy │
└─────────────────┘
# Layerの作成
mkdir -p python/lib/python3.12/site-packages
pip install requests -t python/lib/python3.12/site-packages/
zip -r layer.zip python/
aws lambda publish-layer-version \
--layer-name common-libs \
--zip-file fileb://layer.zip \
--compatible-runtimes python3.12
# 関数にLayerをアタッチ
aws lambda update-function-configuration \
--function-name hello-function \
--layers arn:aws:lambda:ap-northeast-1:<ACCOUNT_ID>:layer:common-libs:1
API Gateway
API Gateway は、Lambda 関数をHTTPエンドポイントとして公開するサービスです。
REST API vs HTTP API
| 項目 | REST API | HTTP API |
|---|---|---|
| 料金 | $3.50/100万リクエスト | $1.00/100万リクエスト |
| 機能 | フル機能(APIキー、使用量プラン等) | 軽量、高速 |
| WebSocket | 非対応 | 非対応(別途WebSocket API) |
| 認証 | IAM, Cognito, Lambda Authorizer | IAM, JWT Authorizer |
| 推奨 | 高度な機能が必要な場合 | 一般的なAPI(推奨) |
HTTP APIの作成
# HTTP APIの作成
API_ID=$(aws apigatewayv2 create-api \
--name hello-api \
--protocol-type HTTP \
--target "arn:aws:lambda:ap-northeast-1:<ACCOUNT_ID>:function:hello-function" \
--query 'ApiId' --output text)
# Lambda関数にAPI Gatewayからの呼び出し権限を付与
aws lambda add-permission \
--function-name hello-function \
--statement-id apigateway-invoke \
--action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-arn "arn:aws:execute-api:ap-northeast-1:<ACCOUNT_ID>:${API_ID}/*"
# エンドポイントURLを確認
aws apigatewayv2 get-api --api-id $API_ID --query 'ApiEndpoint' --output text
# → https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com
# テスト
curl -X POST https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/ \
-H "Content-Type: application/json" \
-d '{"name": "AWS"}'
サーバーレスアーキテクチャの実例
クライアント
│
┌────┴─────────┐
│ CloudFront │ ← 静的ファイル配信(S3)
└────┬─────────┘
│
┌────┴─────────┐
│ API Gateway │ ← REST/HTTP API
└────┬─────────┘
│
┌────┴─────────┐ ┌────────────┐
│ Lambda │───→│ DynamoDB │ ← データストア
└────┬─────────┘ └────────────┘
│
┌────┴─────────┐ ┌────────────┐
│ Lambda │───→│ SES │ ← メール送信
│ (非同期) │ └────────────┘
└──────────────┘
AWS SAM(Serverless Application Model)
SAMはサーバーレスアプリケーションをIaC(Infrastructure as Code)で定義・デプロイするフレームワークです。
SAM CLIのインストール
# macOS
brew install aws-sam-cli
# Windows (pip)
pip install aws-sam-cli
# 確認
sam --version
SAMテンプレート(template.yaml)
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Hello API
Globals:
Function:
Timeout: 30
Runtime: python3.12
MemorySize: 128
Resources:
HelloFunction:
Type: AWS::Serverless::Function
Properties:
Handler: app.lambda_handler
CodeUri: hello_function/
Events:
HelloApi:
Type: HttpApi
Properties:
Path: /hello
Method: post
Outputs:
HelloApiUrl:
Value: !Sub "https://${ServerlessHttpApi}.execute-api.${AWS::Region}.amazonaws.com/hello"
SAMデプロイ
# プロジェクトの初期化
sam init --runtime python3.12 --app-template hello-world --name my-sam-app
# ビルド
sam build
# ローカルテスト(Docker必要)
sam local invoke HelloFunction --event events/event.json
sam local start-api # localhost:3000 でAPIサーバー起動
# デプロイ
sam deploy --guided
コスト比較:EC2 vs Lambda
月間100万リクエスト、平均200ms実行、128MBメモリの場合:
| 項目 | EC2 (t3.micro) | Lambda |
|---|---|---|
| コンピュート | $9.93/月 | $0.21/月 |
| 課金対象 | 730時間(常時稼働) | 実行時間のみ(合計55.6時間) |
| スケーリング | Auto Scaling設定必要 | 自動 |
| アイドル時コスト | 発生する | 発生しない |
| 合計 | 約$10/月 | 約$0.21/月 |
注意: Lambda は大量の常時トラフィックがある場合、EC2の方が安くなることがあります。月間1000万リクエスト以上の場合はコスト試算が必要です。無料枠(月100万リクエスト + 40万GB秒)は無期限で利用可能です。
実践ワーク
- Python(またはNode.js)でLambda関数を作成する
- API Gateway(HTTP API)を作成し、Lambda関数と統合する
curlでAPIエンドポイントにPOSTリクエストを送り、レスポンスを確認する- CloudWatch Logs でLambda関数の実行ログを確認する
- SAM CLIをインストールし、
sam initでサンプルプロジェクトを作成してローカルテストする - 重要: 不要なAPI GatewayとLambda関数は削除する
# 後片付け
aws lambda delete-function --function-name hello-function
aws apigatewayv2 delete-api --api-id $API_ID
まとめと次回の準備
- サーバーレスはサーバー管理不要で、コード実行に集中できるアーキテクチャ
- Lambdaはイベント駆動で最大15分の関数を実行。無料枠は月100万リクエスト
- Lambda関数はhandler、event、contextの3要素で構成。Python/Node.jsが人気
- API GatewayはLambdaをHTTPエンドポイントとして公開。HTTP APIが低コストで推奨
- Lambda Layersで共通ライブラリを効率的に管理
- SAMでサーバーレスアプリケーションをIaCで管理・デプロイ
- 小〜中規模のAPIではLambdaの方がEC2より大幅に安い
次回はCloudWatchとコスト管理を学び、AWSリソースの監視と費用最適化の方法を身につけます。
参考文献
Lecture 9CloudWatch・コスト管理 — 運用と監視
10:00
CloudWatch・コスト管理 — 運用と監視
はじめに
AWSリソースを本番運用するには、「監視」と「コスト管理」が不可欠です。CloudWatch はメトリクス・ログ・アラームを統合した監視サービスで、AWS Budgets と Cost Explorer はコストの可視化と管理を担います。このレクチャーでは、運用に必要な監視とコスト最適化の手法を実践的に学びます。
CloudWatch の全体像
┌─ CloudWatch ───────────────────────────────────────────┐
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ メトリクス │ │ ログ │ │ アラーム │ │
│ │ (Metrics) │ │ (Logs) │ │ (Alarms) │ │
│ │ │ │ │ │ │ │
│ │ CPU使用率 │ │ アプリログ │ │ 閾値超え通知 │ │
│ │ ネットワーク │ │ エラーログ │ │ Auto Scaling │ │
│ │ ディスクI/O │ │ アクセスログ │ │ SNS連携 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ ダッシュボード │ │ Events / │ │
│ │ (Dashboard) │ │ EventBridge │ │
│ │ │ │ │ │
│ │ 統合監視画面 │ │ 定期実行 │ │
│ │ カスタムグラフ│ │ イベント連携 │ │
│ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────┘
CloudWatch メトリクス
メトリクスはAWSリソースの数値データ(CPU使用率、リクエスト数など)を時系列で収集します。
主要な標準メトリクス
| サービス | メトリクス | 説明 | 間隔 |
|---|---|---|---|
| EC2 | CPUUtilization | CPU使用率(%) | 5分(基本)/1分(詳細) |
| EC2 | NetworkIn/Out | ネットワーク通信量 | 5分 |
| EC2 | StatusCheckFailed | ステータスチェック失敗 | 1分 |
| RDS | DatabaseConnections | DB接続数 | 1分 |
| RDS | FreeStorageSpace | 空きストレージ | 1分 |
| Lambda | Invocations | 呼び出し回数 | 1分 |
| Lambda | Duration | 実行時間 | 1分 |
| Lambda | Errors | エラー数 | 1分 |
| ALB | RequestCount | リクエスト数 | 1分 |
| ALB | TargetResponseTime | 応答時間 | 1分 |
カスタムメトリクスの送信
# CLIでカスタムメトリクスを送信
aws cloudwatch put-metric-data \
--namespace "MyApp" \
--metric-name "ActiveUsers" \
--value 42 \
--unit Count \
--dimensions Environment=Production
# Pythonで送信
# pip install boto3
import boto3
cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-1')
cloudwatch.put_metric_data(
Namespace='MyApp',
MetricData=[
{
'MetricName': 'OrderCount',
'Value': 15,
'Unit': 'Count',
'Dimensions': [
{'Name': 'Environment', 'Value': 'Production'},
{'Name': 'Region', 'Value': 'Tokyo'}
]
}
]
)
無料枠: 基本モニタリング(5分間隔)は無料。詳細モニタリング(1分間隔)はインスタンスあたり$3.00/月。カスタムメトリクスは最初の10個まで無料。
CloudWatch アラーム
メトリクスが指定した閾値を超えたときに通知やアクションを実行します。
メトリクス値の推移:
100% ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
┌───┐
80% ─ ─ ─ ─ ── 閾値 ──────┤ ├─── ALARM!
┌─┐ │ │ ↓
60% ┌─┐ │ │ │ │ SNS通知
┌──┤ ├─┤ ├──┤ │ Auto Scaling
40% ┌──┤ │ │ │ │ │ │
┌──┤ │ │ │ │ │ │ │
20% ───┤ │ │ │ │ │ │ │ │
───┴──┴──┴──┴─┴─┴─┴──┴───┴────→ 時間
アラームの作成
# SNSトピックの作成(通知先)
TOPIC_ARN=$(aws sns create-topic --name alarm-notifications --query 'TopicArn' --output text)
# メール通知の登録
aws sns subscribe \
--topic-arn $TOPIC_ARN \
--protocol email \
--notification-endpoint your-email@example.com
# EC2 CPU使用率のアラーム
aws cloudwatch put-metric-alarm \
--alarm-name "High-CPU-Alarm" \
--alarm-description "CPU使用率が80%を超えたら通知" \
--metric-name CPUUtilization \
--namespace AWS/EC2 \
--statistic Average \
--period 300 \
--threshold 80 \
--comparison-operator GreaterThanThreshold \
--evaluation-periods 2 \
--dimensions Name=InstanceId,Value=i-xxxxxxxxxxxx \
--alarm-actions $TOPIC_ARN \
--ok-actions $TOPIC_ARN
# Lambda エラー率のアラーム
aws cloudwatch put-metric-alarm \
--alarm-name "Lambda-Error-Alarm" \
--alarm-description "Lambda関数のエラーが発生したら通知" \
--metric-name Errors \
--namespace AWS/Lambda \
--statistic Sum \
--period 60 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--dimensions Name=FunctionName,Value=hello-function \
--alarm-actions $TOPIC_ARN
# RDS ストレージ残容量のアラーム
aws cloudwatch put-metric-alarm \
--alarm-name "RDS-Low-Storage" \
--alarm-description "RDSの空きストレージが2GBを下回ったら通知" \
--metric-name FreeStorageSpace \
--namespace AWS/RDS \
--statistic Average \
--period 300 \
--threshold 2000000000 \
--comparison-operator LessThanThreshold \
--evaluation-periods 1 \
--dimensions Name=DBInstanceIdentifier,Value=my-first-db \
--alarm-actions $TOPIC_ARN
CloudWatch Logs
アプリケーションログ、Lambda実行ログ、VPCフローログなどを一元管理します。
ロググループ (Log Group)
└─ /aws/lambda/hello-function
├─ ログストリーム (Log Stream)
│ └─ 2024/01/15/[$LATEST]xxxxx
│ ├─ START RequestId: ...
│ ├─ {"level": "info", "message": "処理開始"}
│ ├─ {"level": "error", "message": "DB接続失敗"}
│ └─ END RequestId: ...
└─ ログストリーム
└─ 2024/01/15/[$LATEST]yyyyy
ログの検索(Logs Insights)
-- 過去1時間のエラーログを検索
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20
-- Lambda関数の実行時間の統計
filter @type = "REPORT"
| stats avg(@duration), max(@duration), min(@duration) by bin(1h)
-- 特定のリクエストIDでトレース
fields @timestamp, @message
| filter @message like /abc123-request-id/
| sort @timestamp asc
ログの保持期間設定
# ログの保持期間を30日に設定(コスト削減)
aws logs put-retention-policy \
--log-group-name /aws/lambda/hello-function \
--retention-in-days 30
コスト注意: CloudWatch Logs は取り込み ($0.76/GB) + 保存 ($0.033/GB/月) で課金。ログの保持期間を適切に設定してコストを管理しましょう。
AWS Budgets — 予算管理
予算の作成
# 月次コスト予算の作成($10超えたら通知)
aws budgets create-budget \
--account-id <ACCOUNT_ID> \
--budget '{
"BudgetName": "Monthly-Cost-Budget",
"BudgetLimit": {"Amount": "10", "Unit": "USD"},
"TimeUnit": "MONTHLY",
"BudgetType": "COST"
}' \
--notifications-with-subscribers '[
{
"Notification": {
"NotificationType": "ACTUAL",
"ComparisonOperator": "GREATER_THAN",
"Threshold": 80
},
"Subscribers": [
{"SubscriptionType": "EMAIL", "Address": "your-email@example.com"}
]
},
{
"Notification": {
"NotificationType": "FORECASTED",
"ComparisonOperator": "GREATER_THAN",
"Threshold": 100
},
"Subscribers": [
{"SubscriptionType": "EMAIL", "Address": "your-email@example.com"}
]
}
]'
推奨する予算アラート設定
| 予算タイプ | 閾値 | 通知タイミング |
|---|---|---|
| 月次コスト | $1 | 実績80%で通知 |
| 月次コスト | $10 | 実績80%で通知 + 予測100%で通知 |
| サービス別 | サービスごと | 実績80%で通知 |
Cost Explorer — コスト分析
Cost Explorer はAWSの利用コストを可視化・分析するツールです。
Cost Explorer のビュー:
┌──────────────────────────────────────────┐
│ 月次コスト推移 (過去6ヶ月) │
│ │
│ $50 │ ┌──┐ │
│ │ ┌──┐ │ │ │
│ $30 │ ┌──┐ │ │ │ │ │
│ │ ┌──┐ │ │ │ │ │ │ │
│ $10 │ ┌──┐ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │
│ $0 └─┴──┴─┴──┴───┴──┴──┴──┴───┴──┴── │
│ Sep Oct Nov Dec Jan Feb │
│ │
│ サービス別内訳: │
│ ██████████ EC2: 45% │
│ ██████ RDS: 30% │
│ ████ S3: 15% │
│ ██ その他: 10% │
└──────────────────────────────────────────┘
CLIでコストデータを取得
# 過去30日のサービス別コスト
aws ce get-cost-and-usage \
--time-period Start=2024-01-01,End=2024-01-31 \
--granularity MONTHLY \
--metrics "BlendedCost" \
--group-by Type=DIMENSION,Key=SERVICE
# 今月の予測コスト
aws ce get-cost-forecast \
--time-period Start=2024-02-01,End=2024-02-28 \
--metric BLENDED_COST \
--granularity MONTHLY
タグ戦略 — コスト配分とリソース管理
タグはAWSリソースにキーバリューのメタデータを付与する仕組みです。コスト配分やリソース管理に必須です。
推奨タグ一覧
| タグキー | 説明 | 値の例 |
|---|---|---|
Name |
リソース名 | web-server-01 |
Environment |
環境 | production, staging, development |
Project |
プロジェクト名 | my-web-app |
Owner |
管理者 | team-backend |
CostCenter |
コストセンター | engineering-001 |
# EC2インスタンスにタグを付与
aws ec2 create-tags \
--resources i-xxxxxxxxxxxx \
--tags Key=Environment,Value=production Key=Project,Value=my-web-app Key=Owner,Value=team-backend
# タグベースのコスト配分を有効化
# コンソール: Billing → コスト配分タグ → タグをアクティブ化
コスト最適化のチェックリスト
コスト最適化の優先順位:
1. 不要リソースの削除 ← 最も効果的
│ └─ 使っていないEC2、EBS、EIP、NAT GW
│
2. 適切なサイジング
│ └─ 過大なインスタンスをダウンサイズ
│
3. 料金モデルの最適化
│ └─ リザーブドインスタンス、Savings Plans
│
4. ストレージの最適化
│ └─ S3ライフサイクル、EBSタイプ見直し
│
5. アーキテクチャの最適化 ← 長期的に最も効果的
└─ サーバーレス化、スポットインスタンス活用
よくあるコスト漏れ
| リソース | 見落としやすい課金 | 対策 |
|---|---|---|
| Elastic IP | 未使用のEIPは$0.005/時(月$3.6) | 使わないEIPは解放 |
| NAT Gateway | 月$45 + データ転送料 | 学習後は削除 |
| EBSボリューム | 未アタッチでも保存料発生 | 定期的に確認・削除 |
| RDSスナップショット | 手動スナップショットは無期限保存 | 古いものを削除 |
| CloudWatch Logs | ログ保存量が増え続ける | 保持期間を設定 |
リザーブドインスタンスと Savings Plans
常時稼働するリソースは、コミットメント型の割引プランで大幅にコスト削減できます。
| プラン | 対象 | 割引率 | 柔軟性 |
|---|---|---|---|
| Reserved Instances (RI) | EC2, RDS, ElastiCache | 最大72% | インスタンスタイプ固定 |
| EC2 Savings Plans | EC2のみ | 最大72% | ファミリー内で柔軟 |
| Compute Savings Plans | EC2 + Fargate + Lambda | 最大66% | 最も柔軟 |
推奨: まず Cost Explorer の「リザーブドインスタンスのレコメンデーション」を確認し、適切なプランを選択しましょう。
実践ワーク
- CloudWatch でEC2のCPUUtilizationメトリクスを確認する
- CPU使用率80%超えのアラームを作成し、SNSでメール通知を設定する
- CloudWatch Logs Insights で Lambda のログを検索する
- AWS Budgets で $1 の月次予算を作成する
- Cost Explorer で過去1ヶ月のサービス別コストを確認する
- すべてのリソースに
EnvironmentとProjectタグを付与する
まとめと次回の準備
- CloudWatch メトリクスでリソースの状態を数値で監視。標準メトリクスは無料
- CloudWatch アラームで閾値超えを検知し、SNS通知やAuto Scalingを自動実行
- CloudWatch Logsでアプリケーションログを一元管理。Logs Insightsで高速検索
- AWS Budgetsで予算アラートを設定し、予期せぬ課金を防止
- Cost Explorerでコストの可視化と分析。リザーブドインスタンスの推奨も確認可能
- タグ戦略でコスト配分とリソース管理を効率化
- コスト最適化は不要リソースの削除から始めるのが最も効果的
次回は総合演習として、これまで学んだサービスを組み合わせてWebアプリのインフラ全体を設計します。各サービスの基本操作を復習しておいてください。
参考文献
Lecture 10総合演習 — Webアプリのインフラを設計する
15:00
総合演習 — Webアプリのインフラを設計する
はじめに
このレクチャーでは、コース全体で学んだAWSサービスを統合し、本番環境レベルのWebアプリケーションインフラを設計します。VPC、EC2/ECS、RDS、S3、CloudFront、Lambda を組み合わせた構成を理解し、AWS Well-Architected Framework の5つの柱に基づいてアーキテクチャを評価します。最後に、AWSの認定資格についても紹介します。
設計するWebアプリの要件
以下のようなECサイト(電子商取引サイト)を想定します。
| 要件 | 詳細 |
|---|---|
| ユーザー数 | 月間アクティブユーザー 10,000人 |
| 同時接続 | ピーク時 500人 |
| データベース | 商品、ユーザー、注文データ(リレーショナル) |
| 静的ファイル | 商品画像、CSS/JS(数GB) |
| API | REST API(商品検索、注文処理) |
| 可用性 | 99.9%(月間ダウンタイム43分以内) |
| セキュリティ | HTTPS必須、PCI DSS準拠を考慮 |
全体アーキテクチャ図
ユーザー (ブラウザ / モバイル)
│
┌──────────┴──────────┐
│ │
┌─────┴──────┐ ┌──────┴──────┐
│ CloudFront │ │ Route 53 │
│ (CDN) │ │ (DNS) │
│ 静的配信 │ │ example.com │
└─────┬──────┘ └──────┬──────┘
│ │
┌─────┴──────┐ │
│ S3 Bucket │ │
│ (静的資産) │ │
│ 画像/CSS/JS │ │
└────────────┘ │
│
┌─ VPC (10.0.0.0/16) ─────────────────────┼──────────────────────────┐
│ │ │
│ ┌─ パブリックサブネット ──────────────────┼────────────────────────┐ │
│ │ │ │ │
│ │ ┌─ AZ-a ─────────┐ ┌─ AZ-c ────────┴──┐ │ │
│ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ │
│ │ │ │ NAT GW │ │ │ │ NAT GW │ │ │ │
│ │ │ └───────────┘ │ │ └───────────┘ │ │ │
│ │ └─────────────────┘ └──────────────────┘ │ │
│ │ │ │
│ │ ┌──────────────┐ │ │
│ │ │ ALB │ ← Application LB │ │
│ │ │ (HTTPS:443) │ ACM証明書でSSL終端 │ │
│ │ └──────┬───────┘ │ │
│ └───────────────────────────┼────────────────────────────────────┘ │
│ │ │
│ ┌─ プライベートサブネット(アプリ層)─┼────────────────────────────┐ │
│ │ │ │ │
│ │ ┌─ AZ-a ──────────┐ ┌─ AZ-c ──────────┐ │ │
│ │ │ ┌────────────┐ │ │ ┌────────────┐ │ │ │
│ │ │ │ ECS/EC2 │ │ │ │ ECS/EC2 │ │ │ │
│ │ │ │ (App) │ │ │ │ (App) │ │ │ │
│ │ │ │ Target Grp │ │ │ │ Target Grp │ │ │ │
│ │ │ └────────────┘ │ │ └────────────┘ │ │ │
│ │ └──────────────────┘ └──────────────────┘ │ │
│ └─────────────────────────────┼──────────────────────────────┘ │
│ │ │
│ ┌─ プライベートサブネット(DB層)──┼────────────────────────────┐ │
│ │ │ │ │
│ │ ┌─ AZ-a ──────────┐ ┌─ AZ-c ──────────┐ │ │
│ │ │ ┌────────────┐ │ │ ┌────────────┐ │ │ │
│ │ │ │ RDS │ │ │ │ RDS │ │ │ │
│ │ │ │ (Primary) │ │ │ │ (Standby) │ │ │ │
│ │ │ │ MySQL/PG │ │ │ │ Multi-AZ │ │ │ │
│ │ │ └────────────┘ │ │ └────────────┘ │ │ │
│ │ └──────────────────┘ └──────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─ サーバーレス層 ─────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ API GW │───→│ Lambda │───→│ DynamoDB │ │ │
│ │ │ (REST) │ │ (注文) │ │ (セッション)│ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ │ │ │
│ │ ┌────┴─────┐ │ │
│ │ │ SQS │ ← 非同期処理キュー │ │
│ │ └────┬─────┘ │ │
│ │ ┌────┴─────┐ │ │
│ │ │ Lambda │ ← メール送信、在庫更新 │ │
│ │ └──────────┘ │ │
│ └──────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘
┌─ 監視・運用 ──────────────────────────────────────────────┐
│ CloudWatch (メトリクス・ログ・アラーム) │
│ AWS Budgets (コスト管理) │
│ CloudTrail (API操作ログ) │
│ AWS Config (構成変更の追跡) │
└────────────────────────────────────────────────────────────┘
各レイヤーの設計詳細
1. DNS + CDN層
| コンポーネント | サービス | 設定 |
|---|---|---|
| DNS | Route 53 | ドメイン管理、ヘルスチェック、フェイルオーバー |
| CDN | CloudFront | S3オリジン(静的)+ ALBオリジン(動的)、ACM証明書 |
| 静的アセット | S3 | 画像・CSS・JS、バージョニング有効、ライフサイクル設定 |
2. ネットワーク層(VPC)
| コンポーネント | CIDR | AZ | 用途 |
|---|---|---|---|
| VPC | 10.0.0.0/16 | - | 全体ネットワーク |
| パブリックサブネット A | 10.0.1.0/24 | AZ-a | ALB、NAT GW |
| パブリックサブネット C | 10.0.2.0/24 | AZ-c | ALB、NAT GW |
| プライベートサブネット(App)A | 10.0.11.0/24 | AZ-a | EC2/ECS |
| プライベートサブネット(App)C | 10.0.12.0/24 | AZ-c | EC2/ECS |
| プライベートサブネット(DB)A | 10.0.21.0/24 | AZ-a | RDS Primary |
| プライベートサブネット(DB)C | 10.0.22.0/24 | AZ-c | RDS Standby |
3. コンピュート層
Option A: EC2 + Auto Scaling
# Auto Scalingグループの設定例
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-app-asg \
--launch-template LaunchTemplateName=my-app-template,Version='$Latest' \
--min-size 2 \
--max-size 10 \
--desired-capacity 2 \
--vpc-zone-identifier "$PRIV_SUB_A,$PRIV_SUB_C" \
--target-group-arns $TARGET_GROUP_ARN \
--health-check-type ELB \
--health-check-grace-period 300
Option B: ECS (Fargate) — 推奨
# ECSクラスターの作成
aws ecs create-cluster --cluster-name my-app-cluster
# タスク定義(Docker コンテナ)
aws ecs register-task-definition \
--family my-app \
--network-mode awsvpc \
--requires-compatibilities FARGATE \
--cpu 256 \
--memory 512 \
--container-definitions '[{
"name": "app",
"image": "<ACCOUNT_ID>.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest",
"portMappings": [{"containerPort": 8080}],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/my-app",
"awslogs-region": "ap-northeast-1",
"awslogs-stream-prefix": "ecs"
}
}
}]'
4. データベース層
# Aurora MySQL クラスターの作成(本番向け)
aws rds create-db-cluster \
--db-cluster-identifier my-app-cluster \
--engine aurora-mysql \
--engine-version 8.0 \
--master-username admin \
--master-user-password 'YourStr0ng!Pass' \
--db-subnet-group-name my-db-subnet-group \
--vpc-security-group-ids $DB_SG \
--storage-encrypted \
--backup-retention-period 14
# Writerインスタンス
aws rds create-db-instance \
--db-instance-identifier my-app-writer \
--db-cluster-identifier my-app-cluster \
--db-instance-class db.r6g.large \
--engine aurora-mysql
# Readerインスタンス(読み取り負荷分散)
aws rds create-db-instance \
--db-instance-identifier my-app-reader \
--db-cluster-identifier my-app-cluster \
--db-instance-class db.r6g.large \
--engine aurora-mysql
5. サーバーレス層
注文処理や通知など、イベント駆動の処理はLambdaで実装します。
注文フロー:
ユーザー → API GW → Lambda (注文登録)
│
┌────┴────┐
│ SQS │ ← 注文イベントをキューイング
└────┬────┘
│
┌────┴──────────┐
│ │
┌─────┴────┐ ┌─────┴────┐
│ Lambda │ │ Lambda │
│ (在庫更新)│ │ (メール) │
└──────────┘ └──────────┘
コスト試算
この構成の月額コスト概算(東京リージョン):
| コンポーネント | スペック | 月額概算 |
|---|---|---|
| ALB | 1台 | $22 |
| EC2 (t3.medium × 2) | Auto Scaling | $73 × 2 = $146 |
| RDS (db.r6g.large, Multi-AZ) | Aurora MySQL | $470 |
| NAT Gateway (× 2) | 各AZに1台 | $90 |
| S3 (50GB) | Standard | $1.25 |
| CloudFront | 100GB転送 | $12.50 |
| Lambda | 100万リクエスト | $0.21 |
| Route 53 | 1ホストゾーン | $0.50 |
| CloudWatch | 基本監視 | 無料 |
| 合計 | 約 $742/月(約11万円) |
コスト削減の選択肢
| 戦略 | 効果 | 削減後の概算 |
|---|---|---|
| EC2 → Fargate | サーバー管理不要、使った分だけ | -$50 |
| Reserved Instances (1年) | EC2+RDS 40%OFF | -$250 |
| 開発環境は停止スケジュール | 夜間・休日は停止 | -$100 |
| NAT GWを1台に | 可用性と引き換え | -$45 |
| 最適化後合計 | 約 $300〜400/月 |
AWS Well-Architected Framework — 5つの柱
アーキテクチャを評価する際のフレームワークです。
┌──────────────────────────────────────────────────────┐
│ AWS Well-Architected Framework │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 運用 │ │ セキュリ │ │ 信頼性 │ │
│ │ の卓越性 │ │ ティ │ │ │ │
│ │ │ │ │ │ │ │
│ │ CloudWatch│ │ IAM │ │ Multi-AZ │ │
│ │ IaC │ │ 暗号化 │ │ Auto │ │
│ │ CI/CD │ │ VPC │ │ Scaling │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ パフォー │ │ コスト │ │ サステナ │ │
│ │ マンス │ │ 最適化 │ │ ビリティ │ │
│ │ 効率 │ │ │ │ │ │
│ │ CloudFront│ │ RI/SP │ │ 効率的な │ │
│ │ 適切な │ │ 右サイ │ │ リソース │ │
│ │ サイジング │ │ ジング │ │ 利用 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└──────────────────────────────────────────────────────┘
5つの柱で今回の構成を評価
| 柱 | 今回の構成での対応 | 改善点 |
|---|---|---|
| 運用の卓越性 | CloudWatch監視、タグ戦略 | IaC化(CloudFormation/Terraform)、CI/CDパイプライン |
| セキュリティ | IAM最小権限、プライベートサブネット、暗号化 | WAF追加、GuardDuty有効化、Secrets Manager |
| 信頼性 | Multi-AZ、Auto Scaling、自動バックアップ | マルチリージョン対応、カオスエンジニアリング |
| パフォーマンス効率 | CloudFront CDN、適切なインスタンスタイプ | ElastiCache追加、Aurora Serverless v2 |
| コスト最適化 | Budgets、Cost Explorer、タグベースコスト配分 | RI/Savings Plans適用、スポットインスタンス活用 |
インフラのコード化(IaC)
実際の運用では、インフラを手動で構築するのではなくコードとして管理します。
| ツール | 提供元 | 特徴 | 学習優先度 |
|---|---|---|---|
| CloudFormation | AWS純正 | AWSに最適化、追加費用なし | 高 |
| Terraform | HashiCorp | マルチクラウド対応、HCL記法 | 高 |
| AWS CDK | AWS | プログラミング言語でインフラ定義 | 中 |
| Pulumi | Pulumi | TypeScript/Python等で定義 | 中 |
CloudFormation テンプレート例(VPC)
AWSTemplateFormatVersion: '2010-09-09'
Description: VPC with public and private subnets
Resources:
VPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsHostnames: true
Tags:
- Key: Name
Value: my-app-vpc
PublicSubnetA:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.1.0/24
AvailabilityZone: !Select [0, !GetAZs '']
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: public-subnet-a
PrivateSubnetA:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.11.0/24
AvailabilityZone: !Select [0, !GetAZs '']
Tags:
- Key: Name
Value: private-subnet-a
Outputs:
VPCId:
Value: !Ref VPC
Export:
Name: my-app-vpc-id
AWS認定資格 — 次のステップ
このコースの内容をベースに、AWS認定資格に挑戦しましょう。
AWS認定資格のロードマップ:
┌─ 基礎レベル ──────────────────────────────────────┐
│ CLF-C02: Cloud Practitioner │
│ 対象: 非エンジニアも含む全員 │
│ 範囲: クラウドの概念、セキュリティ、料金 │
│ 難易度: ★★☆☆☆ │
│ このコースの内容で約70%カバー │
└────────────────────────────────────────────────────┘
│
┌─ アソシエイトレベル ──────────────────────────────────┐
│ SAA-C03: Solutions Architect Associate │
│ 対象: クラウドエンジニア │
│ 範囲: アーキテクチャ設計、サービス選定 │
│ 難易度: ★★★☆☆ │
│ このコースの内容 + 追加学習で合格可能 │
├──────────────────────────────────────────────────────┤
│ DVA-C02: Developer Associate │
│ SOA-C02: SysOps Administrator Associate │
└────────────────────────────────────────────────────────┘
│
┌─ プロフェッショナルレベル ──────────────────────────────┐
│ SAP-C02: Solutions Architect Professional │
│ DOP-C02: DevOps Engineer Professional │
│ 難易度: ★★★★★ │
└────────────────────────────────────────────────────────┘
各資格の概要
| 資格 | コード | 試験時間 | 問題数 | 合格ライン | 受験料 |
|---|---|---|---|---|---|
| Cloud Practitioner | CLF-C02 | 90分 | 65問 | 700/1000 | $100 |
| Solutions Architect Associate | SAA-C03 | 130分 | 65問 | 720/1000 | $150 |
| Developer Associate | DVA-C02 | 130分 | 65問 | 720/1000 | $150 |
| SysOps Administrator | SOA-C02 | 180分 | 65問+ラボ | 720/1000 | $150 |
学習リソース
| リソース | 説明 | 料金 |
|---|---|---|
| AWS Skill Builder | AWS公式の学習プラットフォーム | 無料/有料プラン |
| AWS 公式模擬試験 | 本番に近い問題形式 | 無料(Skill Builder) |
| Udemy | 動画コース + 模擬試験 | セール時 $12〜15 |
| AWS ハンズオンチュートリアル | 公式の実践ガイド | 無料 |
実践ワーク
この総合演習では、以下の設計作業を行います。
課題1:アーキテクチャ設計書の作成
以下の項目を含む設計書をMarkdownで作成してください:
- システム概要: 要件の整理
- ネットワーク設計: VPC、サブネット、CIDR
- コンピュート設計: EC2/ECS/Lambda の選定理由
- データベース設計: RDS/DynamoDB の選定理由
- セキュリティ設計: IAM、SG、暗号化
- 監視・運用設計: CloudWatch アラーム一覧
- コスト試算: 月額概算と最適化戦略
- 障害対応計画: 障害シナリオと対応手順
課題2:最小構成の構築(オプション)
無料枠内で以下の最小構成を実際に構築してみてください:
# 1. VPC + サブネット構築
# 2. EC2 (t3.micro) + Nginx
# 3. RDS (db.t3.micro) + MySQL
# 4. S3 + 静的ファイル
# 5. CloudWatch アラーム
# 6. 全リソースにタグ付与
課題3:後片付け
# すべてのリソースを削除して課金を止める
# チェックリスト:
# □ EC2 インスタンス → 終了
# □ RDS インスタンス → 削除(スナップショット不要)
# □ NAT Gateway → 削除
# □ Elastic IP → 解放
# □ EBS ボリューム → 削除
# □ S3 バケット → オブジェクト削除 → バケット削除
# □ Lambda 関数 → 削除
# □ API Gateway → 削除
# □ CloudWatch ログ → 必要に応じて削除
# □ VPC → サブネット・IGW・RT削除後にVPC削除
まとめと次回の準備
- WebアプリのインフラはVPC + ALB + EC2/ECS + RDS + S3 + CloudFront の構成が基本
- マルチAZとAuto Scalingで可用性とスケーラビリティを確保
- サーバーレス層(Lambda + API Gateway + SQS)でイベント駆動の処理を効率化
- Well-Architected Frameworkの5つの柱でアーキテクチャを評価・改善
- IaC(CloudFormation/Terraform)でインフラをコード管理するのが本番の基本
- コスト試算は設計段階で行い、RI/Savings Plansで最適化
- AWS認定資格はキャリアの証明。CLF-C02 → SAA-C03 の順で挑戦
コース全体の振り返り
Module 1: AWS基礎
├── Lecture 0: クラウドコンピューティングの概念
├── Lecture 1: AWSアカウントと管理コンソール
├── Lecture 2: IAM — セキュリティの基本
├── Lecture 3: EC2 — 仮想サーバー
├── Lecture 4: S3 — ストレージとCDN
├── Lecture 5: VPC — ネットワーク
└── Lecture 6: RDS — データベース
Module 2: AWS実践
├── Lecture 7: Lambda・API Gateway — サーバーレス
├── Lecture 8: CloudWatch・コスト管理 — 運用
└── Lecture 9: 総合演習 — アーキテクチャ設計 ← 今ここ
このコースで学んだ内容は、AWSの広大なサービス群のほんの入口です。しかし、EC2、S3、VPC、RDS、Lambda、IAM、CloudWatch という主要サービスを理解したことで、AWS上でのシステム構築の基盤が身についています。ここから先は、実際のプロジェクトで手を動かしながら、コンテナ(ECS/EKS)、CI/CD(CodePipeline)、IaC(CloudFormation/Terraform)など、より高度なトピックに進んでいきましょう。