今日のゴール

• AWSの 主要サービス9つ の役割がわかる
• 「自分のアプリをAWSで動かすには？」のイメージが持てる
• 明日からAWSの会話についていける

全部覚えなくて大丈夫。「こういうのがあるんだな」でOK

今日のストーリー

あなたが作ったWebアプリを AWSで公開するまでの旅

1. まずは動かす（EC2 / VPC）
2. 公開する（Route 53）
3. データベースを分ける（RDS / DocumentDB）
4. ファイルを置く（S3）
5. 見守る（CloudWatch）
6. 守る（IAM）
7. さらに進化させる（Lambda）

クラウドを一言で

自炊 → レストラン への変化

AWS = 世界最大のクラウドレストラン。200以上のメニュー（サービス）がある

リージョンとAZ — AWSの「場所」の話

AWSのサーバーは世界中に分散配置されている

• リージョン（Region） = データセンターがある地域
  • 東京、大阪、バージニア、シンガポール... 世界30以上
  • 日本で使うなら 東京リージョン（ap-northeast-1） が基本
• AZ（Availability Zone） = リージョン内の独立したデータセンター群
  • 東京リージョンには 3つのAZ がある（ap-northeast-1a, 1c, 1d）

なぜAZが複数あるのか？

1つのデータセンターが災害や停電で止まっても、別のAZが生きていればサービスは継続できる

• 単一AZ = 1つの建物にすべて → 火事になったら全滅
• 複数AZ = 別々の建物に分散 → 片方が倒れてもOK

AWSのサービス（RDS、S3など）は複数AZに自動でデータを複製してくれるものが多い

EC2 — クラウド上の自分専用PC

EC2（Elastic Compute Cloud） = 仮想サーバー

• ローカルPCで動いているアプリを、そのままクラウドで動かせる
• OSもスペックも自由に選べる（Linux, Windows / メモリ1GB〜数TB）
• 不要になったら数クリックで削除 → 課金ストップ

開発者にとっては「SSHで入れるリモートPC」のイメージ

VPC — アプリの住所と間取り

VPC（Virtual Private Cloud） = AWS上のプライベートネットワーク

マンションに例えると...

• VPC = マンション全体（自分だけの敷地）
• パブリックサブネット = 玄関・ロビー（外から来れる場所）
• プライベートサブネット = 寝室（外から直接入れない場所）

EC2は パブリック に置けば外部アクセス可能、プライベート に置けば内部専用

Route 53 — インターネットの電話帳

Route 53 = DNS（ドメイン名 → IPアドレスの変換）

ユーザーが example.com にアクセス
        ↓
Route 53:「example.com の住所は 54.xx.xx.xx です」
        ↓
EC2 に到着 → アプリが表示される

• ドメインの取得・管理もできる
• ヘルスチェック機能で障害時に自動切り替えも可能

名前の由来: DNSのポート番号が 53 + アメリカの有名な道路 Route 66 のもじり

なぜDBを分離するのか？

EC2の中にDBも同居させると...

• EC2が壊れたら アプリもデータも全滅
• アプリのデプロイでDBまで巻き込むリスク
• スケールしたいとき、片方だけ増強できない

1LDKに家族5人で暮らすようなもの。部屋を分けよう

RDS — いつものSQLがそのまま使える

RDS（Relational Database Service） = マネージドRDB

• MySQL, PostgreSQL, Oracle などに対応
• バックアップ、パッチ適用、レプリカ作成をAWSが自動でやってくれる
• SQLを書ける人なら すぐ使える

開発者が嬉しいポイント

• 接続先のエンドポイント（URL）が発行される → コードの接続先を変えるだけ
• 自動バックアップで「やらかした」ときも復元できる

DocumentDB — JSONをそのまま保存

DocumentDB = マネージドNoSQLデータベース（MongoDB互換）

• スキーマが柔軟 → データの形が決まりきらない場面に強い
• MongoDB用のドライバーやツールがそのまま使える

RDSとの使い分け

S3 — 無限に広がる倉庫

S3（Simple Storage Service） = オブジェクトストレージ

• 画像、PDF、ログ、バックアップ... なんでも保存
• 容量制限が実質なし（自動で拡張）
• 耐久性 99.999999999%（イレブンナイン） → まず消えない

開発者の使いどころ

• ユーザーがアップロードした画像の保存先
• フロントエンド（HTML/CSS/JS）の静的ホスティング
• ログファイルの長期保管

EC2に画像を置くのは「冷蔵庫にタイヤを保管する」ようなもの。適材適所！

S3の基本概念

S3
├── バケット（bucket）= フォルダの親玉
│   ├── images/
│   │   ├── logo.png
│   │   └── photo.jpg
│   ├── logs/
│   │   └── 2026-03-27.log
│   └── index.html

• バケット名はグローバルで一意（世界中で重複不可）
• アクセス権限を細かく設定できる（公開/非公開）
• バージョニングで上書きミスも復元可能

CloudWatch — アプリの健康診断

CloudWatch = AWSリソースの監視サービス

3つの柱:

• メトリクス — CPU使用率、メモリ、リクエスト数などの数値データ
• ログ — アプリやサーバーのログを集約・検索
• アラーム — 閾値を超えたらSlackやメールに通知

体温計のようなもの。「38度を超えたら通知」を設定しておく

CloudWatch でよくやること

例: EC2の監視設定

• 「気づいたら本番が止まっていた」を防ぐ仕組み
• ダッシュボードでリアルタイムに可視化もできる

IAM — 社員証＋入館カード

IAM（Identity and Access Management） = 認証・認可の仕組み

• 誰が（ユーザー / ロール）
• 何を（S3, EC2, RDS...）
• どこまで（読み取りだけ / フルアクセス）

会社のセキュリティと同じ。「経理の人に全部屋の鍵を渡さない」

IAMで大事な3つのこと

1. ルートユーザーは金庫の鍵

• AWSアカウント作成時のユーザー = 何でもできる最強権限
• 普段は使わない。IAMユーザーを作って作業する

2. 最小権限の原則

• 必要最低限の権限だけを付与する
• 「とりあえず全権限」は事故のもと

3. ロールを活用する

• EC2やLambdaに「この権限で動いてね」と渡す仕組み
• パスワードやキーを埋め込まなくて済む → セキュリティ向上

Lambda — 必要なときだけ現れるアルバイト

Lambda = サーバーレスコンピューティング

• コードをアップロードするだけ。サーバーの管理は不要
• イベント（APIリクエスト、S3へのアップロード等）に反応して実行
• 実行した時間だけ課金 → 待機中は0円

EC2 =「正社員（常にいる）」、Lambda =「アルバイト（呼んだ時だけ来る）」

EC2 と Lambda の使い分け

Lambdaが活躍する場面

• 画像がS3にアップロードされたら リサイズ処理
• 定期的な データ集計バッチ
• APIの バックエンド処理

今日覚えてほしい3つのこと

1. AWSは「必要なものを必要なだけ借りる」サービス
   自炊からレストランへ。初期投資なしで始められる

2. サービスには役割分担がある
   EC2=サーバー、RDS=DB、S3=ファイル... 適材適所で組み合わせる

3. 全部を一度に覚えなくていい
   まずは今日の9つ。触りながら少しずつ広げていこう

迷ったらチームに聞いてください。みんな最初は初心者でした