AWS基礎 #1 AWS入門 — アカウント / リージョン / AZ

インフラ AWS クラウド
読了 11分

Linux、Docker のような インフラの道具箱 を身につけたら、次はその道具たちをどこで動かすかが問題になります。その答えが クラウド です。このシリーズはこの分野の標準になった AWS を最初から運用まで一気に整理します。

全 4 シリーズ 27 編にまとめました。

  • AWS 基礎 7 編 ← いま読んでいるシリーズ
  • AWS 中級 7 編 — EC2 / VPC / S3 / RDS / Route 53 / ALB / CloudFront
  • AWS 上級 7 編 — ECS / ECR / Lambda / API Gateway / EventBridge / Secrets Manager / Step Functions
  • AWS 実践 6 編 — 本物のバックエンドを ECS Fargate に乗せて運用

この記事はシリーズの出発点です。コンソールに入る前 に頭の中にあってほしい絵 — アカウントとは何で、リージョンと AZ とは何で、「グローバルサービス」と「リージョンサービス」の違いがどこから来るのか — を整理します。

クラウドと AWS の立ち位置 #

昔は会社がサーバーを 買うか借りて データセンターに設置し、そこに OS を入れアプリケーションを乗せていました。1 台増やすには見積もり → 発注 → 配送 → 設置 → ネットワーク → モニタリングのセットアップ — 早くても数日、普通は数週間かかっていました。

クラウド はその流れを分単位に圧縮します。

項目昔クラウド
サーバー 1 台見積もり → 発注 → 配送 → 設置 (数週間)コンソールクリック (数分)
ストレージ 1TBRAID カード + ディスク + バックアップ設計S3 バケット 1 行
グローバル展開海外 IDC レンタルリージョン切替 1 行
失敗した実験サンクコストterminate

AWS (Amazon Web Services) はこの流れの 第一走者であり標準。2006 年に S3 と EC2 から始まり、いまでは 200 を超えるサービス が 1 つのコンソールに収まっています。Azure (Microsoft) / GCP (Google) も同じ市場で競合していますが、市場シェアと資料の量で AWS が先行しています。一度身につけておけば他のクラウドへの移行も楽になります。

このシリーズは AWS の上に小さなバックエンドを運用するのに必要な道具箱 だけを取り上げます。AWS の 200 個を全部扱うわけではありません。代わりに 場面に合った道具をどう選ぶか の方が大事になります。

AWS アカウントの形 #

AWS を始めるには AWS アカウント (Account) が 1 つ必要です。メールアドレス + 支払い手段 (普通はクレジットカード) + 電話番号で登録します。

ルートユーザー #

登録直後に得るアカウントには ルートユーザー (Root User) が 1 人います。登録したメールアドレスがそのままそのユーザーです。

ルートユーザーは すべての権限 を持ちます — 請求、アカウント解約、他のユーザー作成、すべてのリソースアクセス。強力な分だけ危険でもあります。AWS の最初のアドバイスは ルートユーザーで日常作業をするな です。覚えておきましょう:

  • ルートでは登録直後のセットアップ、請求情報の確認、アカウント解約くらいだけ
  • 実際の作業は #2 IAM で作る IAM ユーザーで
  • ルートには 必ず MFA (#6 で扱います)
  • アクセスキーは作らない、すでにあるなら即削除

アカウント ID #

アカウントごとに 12 桁の数字 ID (例: 123456789012) が付きます。この ID は IAM ポリシーや ARN (リソース識別子) などの場面で頻繁に登場します。コンソール右上のユーザーメニューから確認できます。

ARN の形 
arn:aws:s3:::my-bucket/path/to/object
arn:aws:iam::123456789012:role/MyRole
arn:aws:lambda:ap-northeast-2:123456789012:function:my-fn

arn:aws:<サービス>:<リージョン>:<アカウントID>:<リソース> の形です。グローバルサービス (S3、IAM など) はリージョンの欄が空になっています。

マルチアカウントと AWS Organizations #

規模が少し大きくなると アカウントを 1 つだけでは使いません。一般的な分け方:

アカウント用途
root (管理)請求の統合、Organizations、セキュリティ監査
prod本番環境 — もっとも保護される環境
staging本番直前の検証
dev開発者の自由度が高い環境
sandbox実験 / 学習 — 自動クリーンアップ

これらのアカウントを束ねて請求を統合し、ポリシーを一括適用するためのツールが AWS Organizations です。最初は単一アカウントで始めても十分。Organizations は 2 つ目のアカウントが必要になったとき に自然に出会います。

なお、このシリーズは単一アカウントを前提に進めます。Organizations は運用規模が大きくなった後の話。

リージョン (Region) #

リージョン は AWS の 物理的な場所 の単位。世界中のあちこちにデータセンタークラスタがあり、それぞれのクラスタが 1 つのリージョンになります。

リージョンごとに短いコードが付きます。よく見るもの:

リージョンコード日本からの距離
東京ap-northeast-1もっとも近い (5~20ms)
大阪ap-northeast-310~30ms
ソウルap-northeast-240~60ms
シンガポールap-southeast-170~100ms
米国東部 (バージニア)us-east-1150~200ms
米国西部 (オレゴン)us-west-2100~140ms
欧州 (フランクフルト)eu-central-1230~280ms

2026 年現在 33 以上 のリージョンが運用中です。コンソール右上のリージョンセレクタで切り替えできます。

リージョンをどう選ぶか #

ユーザーの大部分が日本にいるなら 東京 (ap-northeast-1) が第一候補。ただし次の場面では別の答えになり得ます。

1) ユーザー位置とレイテンシ. ユーザーが韓国 / 東南アジア / 米国に分布しているなら近いリージョン。グローバルサービスなら CloudFront (Edge 分散) で分散することもあります。

2) 法規制 / データ主権. 日本の一部の業界 (金融、医療) はデータを国内に置くことを求める規制があり、東京リージョンが必須になります。欧州の GDPR も同じような場面で影響します。

3) サービスの可用性. すべてのサービスがすべてのリージョンにあるわけではありません。 新しいサービス / 機能は普通 us-east-1 で先にリリースされ、他のリージョンに広がっていきます。リージョン選択前に AWS Regional Services List を確認。

4) 価格. 同じサービスでもリージョンごとに価格が違います。us-east-1 が一般的にもっとも安いです。レイテンシが問題にならないバッチ処理は安いリージョンを検討。

5) 新サービスのベータ / 新機能. 上の 3) の反対側 — 常に最新機能を使いたいなら us-east-1。

リージョンは隔離されている #

リージョン同士は 物理的 / 論理的に隔離 されています。東京リージョンで作った EC2 / S3 / RDS はソウルリージョンのコンソールには表示されません。リージョン間の通信は 明示的に設定 する必要があります (VPC peering、S3 cross-region replication など)。

これが大事な理由:

  • 1 つのリージョンで障害が起きても他のリージョンは無事 (ディザスタリカバリ設計の基本)
  • リソース ID / ARN にリージョンが埋め込まれている
  • IAM コンソールで「なぜ私の EC2 が見えないんだ?」 → ほぼ間違いなく リージョン選択ミス

アベイラビリティゾーン (Availability Zone, AZ) #

リージョンの中をもう 1 段掘り下げると アベイラビリティゾーン (AZ) があります。1 つのリージョンの中に 3~6 個 の AZ があります。各 AZ は 物理的に離れたデータセンター — 通常は数十 km 離れていて電源 / ネットワークが独立しています。

東京リージョン (ap-northeast-1) の AZ:

ap-northeast-1 の AZ 
ap-northeast-1a
ap-northeast-1c
ap-northeast-1d

AZ コードの a/c/d は アカウントごとに違うマッピング になります。私のアカウントの ap-northeast-1a と他の人の ap-northeast-1a が同じ物理 AZ とは限りません。AWS が負荷分散のためにシャッフルしているのです。なので協業する際は AZ ID (apne1-az1 のような) という別の識別子を使います。コンソールの EC2 → アベイラビリティゾーンページで確認できます。

Multi-AZ の意味 #

1 つの AZ がダウンするとその AZ のすべての EC2 / RDS が一緒にダウンします。本番システムは Multi-AZ で設計して 1 AZ の障害に耐える必要があります。

典型的なパターン:

Multi-AZ 設計の形 
                  Route 53
                     │
                     ▼
              Application Load Balancer
                  ╱        ╲
                 ╱          ╲
        ┌───────▼──┐    ┌──▼──────┐
        │   AZ a   │    │   AZ c  │
        │  EC2 #1  │    │ EC2 #2  │
        │  EC2 #2  │    │ EC2 #3  │
        └─────┬────┘    └────┬────┘
              ╲              ╱
               ╲            ╱
                ▼          ▼
            RDS Primary  RDS Standby
              (AZ a)       (AZ c)
  • ALB は自動で複数 AZ に分散 (中級 #6)
  • EC2 は ASG (Auto Scaling Group) で複数 AZ に配置
  • RDS Multi-AZ オプションを ON にすると standby が別の AZ に自動生成、障害時にフェイルオーバー

Multi-AZ にはコストがかかります。 学習 / サイドプロジェクトは単一 AZ でも十分です。本番トラフィックが本当に流れる場面でだけ ON にしましょう。

Edge Location とその仲間たち #

リージョン / AZ 以外にも AWS の物理的な場所はまだあります。

拠点何か用途
Edge Location世界 600+ ヶ所の小さな拠点CloudFront / Route 53 がユーザーに近いところで応答
Local Zone大都市内に置いた小さなリージョン拡張1 桁 ms のレイテンシが必要なワークロード (ゲーム、メディア)
Wavelength Zone5G キャリアの中に置いた拠点モバイル 5G ユーザーのレイテンシ最小化
Outpostsユーザーのデータセンター内に置く AWS ハードウェアオンプレ + AWS の一貫性

このシリーズでは Edge Location だけ 中級 #7 CloudFront でまた出会います。残りは一般的なバックエンド運用ではほぼ使いません。

グローバルサービス vs リージョンサービス #

AWS の 200 個のサービスは 2 種類 に分かれます。

グローバルサービス #

リージョンを選ばない — コンソールのどのリージョンから見ても同じデータを見せるサービス。

サービス特性
IAMユーザー / ロール / ポリシー — アカウント単位
S3バケット名はグローバル一意 (リージョンはバケット単位)
Route 53DNS — インターネット自体がグローバル
CloudFrontEdge 分散 — 本質的に世界中
WAF (CloudFront 用)CloudFront と同じくグローバル
Organizationsアカウントの束

コンソールでグローバルサービスを開くと右上のリージョンセレクタが 「Global」 に自動で切り替わります。

リージョンサービス #

リージョンごとに別々に住むサービス。ほとんどがここに属します。

  • EC2 / RDS / VPC / Lambda / ECS / DynamoDB — 作ったリージョンの中だけで見えて動く
  • CloudWatch — メトリクス / ログがリージョンごとに別 (グローバルダッシュボードは別途)

S3 はちょっとややこしいです。バケット自体は 1 つのリージョンに住みますが 名前は世界中で一意 である必要があります。だから S3 コンソールがグローバルに見えつつも、データはリージョン単位なのです。

はじめる — コンソールを見渡す #

登録後の最初のログイン画面 (コンソールホーム) でよく見る項目:

  • 上部検索バー — サービス名から直接ジャンプ (例: EC2、S3)
  • 上部リージョンセレクタ — 常に意識します。間違ったリージョンで作業するのが一番ありがちなミス
  • 右上ユーザーメニュー — アカウント ID、請求情報、セキュリティ認証情報
  • お気に入り (★アイコン) — よく使うサービスをピン留め
  • CloudShell アイコン — ブラウザ内ターミナル (#5)

初期セットアップのチェックリスト #

登録直後に次の記事を順に進めます。

  1. #2 IAM — 日常作業用の IAM ユーザーを作る。ルートで作業しません。
  2. #3 コスト管理 — 請求アラーム / 無料利用枠の上限設定。最初の請求書ショックを防ぐ。
  3. #6 セキュリティの基本 — ルート + IAM ユーザー両方に MFA。

この 3 つは 実際の作業を始める前に必ず 終えるべきステップです。

よく出会う落とし穴 #

1) 「なぜ私のリソースが見えないんだ?」 #

コンソールで間違いなく作った EC2 が見えません。99% は リージョン選択ミス です。右上を確認します。

2) ルートキーの漏洩 #

登録直後に「API を試そう」とルートユーザーのアクセスキーを作って GitHub にコードと一緒にプッシュ — 数分以内にボットが見つけて仮想通貨マイニングが回り始めます。翌日の請求書は数万ドル。

絶対やらないこと:

  • ルートのアクセスキーを作る
  • アクセスキーをコード / git に入れる
  • アクセスキーを README、Slack、メールに貼る

#6 で詳しく扱います。

3) 別リージョンでの過去の作業の痕跡 #

東京で作ったと思っていた EC2 が実はバージニアにあった。請求書で気付くまで — すでに 1 ヶ月分のコストが流れていました。すべてのリージョンに対して リソースを定期的に点検します (または #3 の請求アラームで早期検知します)。

4) リージョン間データ転送コスト #

同じリージョン内のトラフィックは普通無料ですが リージョン間 / インターネットへ出るトラフィック (Egress) は GB 単位で課金されます。Multi-region 設計時はこのコストが意外と大きく出ます。

5) 単一 AZ 運用 #

小さなシステムでも本番に入れば Multi-AZ を検討します。EC2 1 台 + RDS 単一 AZ では 1 AZ 障害で全面ダウンします。コスト ↔ 可用性のトレードオフを明確にしましょう。

まとめ #

今回つかんだもの:

  • クラウドと AWS の立ち位置 — 買ったり借りたりしていたインフラが分単位に変わります。AWS はその流れの標準
  • アカウント — ルートユーザーはセットアップと請求だけ、日常作業は IAM (#2)
  • アカウント ID は ARN に埋め込まれています。マルチアカウントは Organizations
  • リージョン — 世界 33+ ヶ所。ユーザー位置 / 法規制 / サービス可用性 / 価格 / 新機能で選びます
  • AZ — リージョン内のデータセンター単位。Multi-AZ が運用の基本パターン
  • Edge Location は CloudFront が使う拠点 (中級 #7)
  • グローバル vs リージョンサービス — IAM / S3 (名前) / Route 53 / CloudFront だけがグローバル
  • 落とし穴 — リージョン選択ミス、ルートキー漏洩、眠っている別リージョンのリソース、Egress コスト、単一 AZ

次回 — IAM #

コンソールの見渡しは終わりました。次は ルートユーザーから抜け出して 日常作業用の IAM ユーザーを作る番。

#2 IAM — ユーザー、グループ、ロール、ポリシー では IAM の 4 つの要素 (ユーザー / グループ / ロール / ポリシー) を 1 本の糸で通し、運用で通じる権限設計のパターンまで整理します。

X