AWS 入門 — アカウント · リージョン · AZ

本書の最初の章です。2章からはコンソールと CLI で実際に手を動かしますが、本章ではその前に頭の中に持っておくべき地図を先に描きます — AWS アカウントとは何か、リージョンとアベイラビリティゾーン(AZ)とは何か、「グローバルサービス」と「リージョンサービス」の違いがどこから来るのかです。

本書はコンソールから始めて、4部で Terraform コードへ移り、ECS Fargate の上にフルスタックアプリを載せて運用するところで終わります(6部 フルスタックアプリを AWS にデプロイする)。その長い流れの出発点が本章の地図です。登録直後に必ず通るべき最初のセットアップ — 第2章 IAM · 第3章 コスト管理 · 第6章 セキュリティ基本 — も本章の最後で案内します。

クラウドと AWS の登場 #

以前はサービスを運用するために、会社が自らサーバーを購入またはレンタルしてデータセンターに設置する必要がありました。その上にオペレーティングシステムを構成しアプリケーションをデプロイする方式が一般的でした。サーバーを1台追加することも簡単ではありませんでした。見積もりを取り、発注し、機材を配送してもらった後で設置とネットワーク構成、モニタリング設定まで終える必要があったため、どんなに速くても数日、普通は数週間かかりました。

クラウドはこの過程を変えました。今では必要なサーバーとデータベース、ネットワークを数回のクリックだけで作成できます。物理機材を自ら管理しなくてよく、使った分だけ費用を払います。過去には「インフラを準備すること」自体が大きなプロジェクトだったとすれば、クラウド時代には必要な瞬間に即座にインフラを使えます。

AWS (Amazon Web Services)はこの流れの先駆者であり事実上の標準です。2006年に S3 と EC2 で始まり、今では200を超えるサービスが一つのコンソールの中にあります。Azure (Microsoft)と GCP (Google)も同じ領域を扱いますが、市場シェアと資料の量で AWS が先行しています。一度身につけておけば、他のクラウドへ移ることも容易です。

本書は AWS の上で実際のバックエンドを運用するのに必要な道具箱だけを選びます。200個のサービスをすべて扱うわけではありません。代わりに、用途に合った道具をどう選ぶかの方がより重要です。

AWS アカウント構造 #

AWS を始めるには AWS アカウント (Account) が一つ必要です。メールアドレスと決済手段(通常はクレジットカード)、電話番号で登録します。

ルートユーザー #

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

ルートユーザーはすべての権限を持ちます — 決済、アカウントの解約、他のユーザーの作成、すべてのリソースへのアクセス。強力なだけ危険です。AWS の最初の推奨は ルートユーザーで日常作業をしないということです。

• ルートでは登録直後のセットアップ、決済情報の確認、アカウントの解約くらいだけを行います。
• 実際の作業は 第2章 IAM で作った IAM ユーザーで行います。
• ルートには必ず MFA をかけます(第6章 セキュリティ基本 で扱います)。
• アクセスキーは作らず、すでにある場合は即座に削除します。

アカウント ID と ARN #

アカウントごとに12桁の数字 ID (例: 123456789012)が付きます。この ID は IAM ポリシーや 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 など)はリージョン部分が空いています。ARN は4部以降の Terraform コードと IAM ポリシーで絶えず登場するので、形だけ目に馴染ませておけば十分です。

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

規模が少し大きくなると、アカウントを一つだけ使うことはなくなります。一般的な分離は次のとおりです。

これらのアカウントを束ねて請求を統合し、ポリシーを一括適用する道具が AWS Organizations です。最初は単一アカウントで始めても十分です。Organizations は二つ目のアカウントが必要になったときに自然に出会うことになり、第29章 セキュリティガバナンス で SCP · Control Tower とともに本格的に扱います。

本書の1 ~ 4部は単一アカウントを前提に進めます。マルチアカウントは5部で運用規模が大きくなった後の話として扱います。

リージョン (Region) #

リージョンは AWS の物理的な配置の単位です。世界中の各地にデータセンターのクラスターがあり、各クラスターが一つのリージョンです。リージョンごとに短いコードが付きます。

2026年現在、36を超えるリージョンが運用中です。コンソール右上のリージョンセレクターで切り替えます。

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

ほとんどのユーザーが韓国にいるならソウル(ap-northeast-2)が第一候補です。ただし次の基準では別の答えが出ることがあります。

1. ユーザーの位置と遅延 (Latency) — ユーザーが韓国 / 東南アジア / 米国に分布しているなら近いリージョンを選びます。グローバルサービスなら 第14章 CloudFront の Edge 分散で解消することもあります。
2. 法規 / データ主権 — 韓国の一部の業界(金融、医療)はデータを韓国国内に置くよう求める規制があり、ソウルリージョンが事実上強制されます。ヨーロッパの GDPR も同様に影響を与えます。
3. サービスの可用性 — すべてのサービスがすべてのリージョンにあるわけではありません。新しいサービス / 機能は通常 us-east-1 で先にリリースされ、他のリージョンへ広がります。
4. 価格 — 同じサービスでもリージョンごとに価格が異なります。us-east-1 が一般的に最も安いです。遅延が問題にならないバッチ処理は安価なリージョンを検討します。
5. 新サービスのベータ / 新機能 — 3番の逆で、常に最新機能を試したいなら us-east-1 です。

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

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

• 一つのリージョンが障害になっても他のリージョンは無事です(災害復旧設計の基本であり、第30章 災害復旧・バックアップ で扱います)。
• リソース ID と ARN の中にリージョンが含まれます。
• コンソールで「なぜ私の EC2 が見えないのか」という場合、十中八九リージョンを間違って選んでいます。

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

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

ap-northeast-2a
ap-northeast-2b
ap-northeast-2c
ap-northeast-2d

AZ コードの a/b/c/d はアカウントごとに異なってマッピングされます。自分のアカウントの ap-northeast-2a と他の人の ap-northeast-2a が同じ物理 AZ ではないことがあります。AWS が負荷分散のためにシャッフルするからです。そのため、共同作業するときは apne2-az1 のような AZ ID という別の識別子を使います。

Multi-AZ の意味 #

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

                  Route 53
                     │
                     ▼
              Application Load Balancer
                  ╱        ╲
                 ╱          ╲
        ┌───────▼──┐    ┌──▼──────┐
        │   AZ a   │    │   AZ b  │
        │  EC2 #1  │    │ EC2 #2  │
        │  EC2 #2  │    │ EC2 #3  │
        └─────┬────┘    └────┬────┘
              ╲              ╱
               ╲            ╱
                ▼          ▼
            RDS Primary  RDS Standby
              (AZ a)       (AZ b)

• ALB は自動的に複数の AZ に分散します(第13章 ALB / NLB と ACM)。
• EC2 は ASG (Auto Scaling Group)で複数の AZ にデプロイします。
• RDS の Multi-AZ オプションをオンにすると standby が別の AZ に自動生成され、障害時にフェイルオーバーします。

Multi-AZ は費用がかかります。学習やサイドプロジェクトは単一 AZ でも十分です。本番トラフィックが実際に流れるサービスでのみオンにします。

Edge Location と周辺インフラ #

リージョンと AZ 以外にも、AWS のグローバルインフラ拠点がさらにあります。

本書では Edge Location だけを 第14章 CloudFront で再び扱います。残りは一般的なバックエンド運用ではほとんど使われません。

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

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

グローバルサービス #

リージョンを選ばず、コンソールのどのリージョンで見ても同じデータを表示するサービスです。

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

リージョンサービス #

リージョンごとに別々に存在するサービスです。ほとんどがここに属します。

• EC2 / RDS / VPC / Lambda / ECS / DynamoDB — 作ったリージョンの中だけで見え、動作します。
• CloudWatch — メトリクスとログがリージョンごとに別々です(第7章 CloudWatch 入門)。

S3 は少し紛らわしい部分です。バケット自体は一つのリージョンに存在しますが、名前は世界中で一意でなければなりません。そのため S3 コンソールがグローバルのように見えながらも、データはリージョン単位です(第10章 S3)。

コンソールを一回りと最初のセットアップ #

登録後の初回ログイン画面(コンソールホーム)でよく見る項目は次のとおりです。

• 上部の検索欄 — サービス名で直接移動します(例: EC2, S3)。
• 上部のリージョンセレクター — 常に意識します。間違ったリージョンで作業することが最もよくあるミスです。
• 上部右側のユーザーメニュー — アカウント ID、決済情報、セキュリティ認証情報。
• CloudShell アイコン — ブラウザの中のターミナルです(第5章 CloudShell と IAM Identity Center)。

登録直後には次の3つの章を順に進めます。実際の作業を始める前に必ず終えるべき段階です。

1. 第2章 IAM — 日常作業用の IAM ユーザーを作り、ルートで働かないようにします。
2. 第3章 コスト管理 — 決済アラートと無料利用枠の限度を設定して、最初の請求書ショックを防ぎます。
3. 第6章 セキュリティ基本 — ルートと IAM ユーザーの両方に MFA をかけます。

よく出会う落とし穴 #

• 「なぜ私のリソースが見えないのか」 — コンソールで確かに作った EC2 が見えないなら、99% はリージョン選択のミスです。右上を確認します。
• ルートキーの漏洩 — 登録直後にルートユーザーのアクセスキーを作って GitHub にコードと一緒にプッシュすると、数分以内にボットが発見して仮想通貨のマイニングが走ります。ルートのアクセスキーは作らず、どんなキーもコード / git / README / メッセンジャーに入れません(第6章 セキュリティ基本)。
• 間違ったリージョンの眠っているリソース — 東京で作ったと思っていた EC2 が実はバージニアにあって、1ヶ月分の費用が請求された後で発見されることがよくあります。すべてのリージョンを定期点検するか、第3章 コスト管理 の決済アラートで早期に検知します。
• リージョン間のデータ転送費用 — 同じリージョン内のトラフィックは通常無料ですが、リージョン間やインターネットへ出ていくトラフィック(Egress)は GB あたり課金されます。
• 単一 AZ 運用 — 小さなシステムでも本番に入るなら Multi-AZ を検討します。費用と可用性のトレードオフを明確にします。

練習問題 #

1. 自分が作ろうとしているサービスの主なユーザーがどこにいるかを一行で書き、§「リージョンをどう選ぶか」の5つの基準のうちどれがリージョン選択に最も大きく作用するかをメモしておきましょう。第25章 Terraform 入門 で provider "aws" { region = ... } を書くとき、このメモが最初の判断になります。
2. 登録直後に必ず終えるべき最初のセットアップの3つ(IAM ユーザー · 決済アラート · MFA)を見ずに書いてみましょう。各項目が本章の「よく出会う落とし穴」のどれを防いでくれるかを一行ずつ結びつけておきましょう。
3. arn:aws:s3:::my-bucket と arn:aws:ec2:ap-northeast-2:123456789012:instance/i-0abc の二つの ARN で、リージョン部分が一方は空いていて一方は埋まっている理由を §「グローバルサービス vs リージョンサービス」を根拠に一段落で説明してみましょう。

一行まとめ: AWS は買うか借りていたインフラを分単位で使えるように変えた、クラウドの事実上の標準です。アカウントのルートユーザーはセットアップと決済にだけ使い、日常作業は IAM ユーザーで行い、アカウント ID は ARN の中に入ります。リージョンは世界36ヶ所を超える隔離された物理単位で、ユーザーの位置 · 法規 · サービス可用性 · 価格で選び、その中の AZ を複数使う Multi-AZ が運用の基本です。サービスはグローバル(IAM · S3 名 · Route 53 · CloudFront)とリージョンに分かれ、最もよくあるミスはリージョンの選択間違いとルートキーの漏洩です。

次の章 #

次の 第2章 IAM では、ルートユーザーから抜け出して日常作業用の IAM ユーザーを作ります。IAM の4要素(ユーザー · グループ · ロール · ポリシー)を一度に整理し、運用で通用する最小権限の設計パターンまで扱います。