「取引先の AWS アカウントのサーバーと同じ ap-northeast-1a に置きました。同じデータセンターなので、遅延は小さいですよね」
「検証のために AWS のアカウントを作って少し触っただけなのに、翌月に請求が来ました」
第1回では、クラウドの定義と責任共有モデルを見ました。AWS を実際に使い始めると、最初に出会うのが リージョン・AZ・アカウント・料金 です。どれも画面の上では1行の選択肢ですが、どこに置くかで可用性が、どのアカウントで作るかで権限と請求の境界が、何を動かしたままにするかで料金が決まります。ここを知らないと、冒頭のような勘違いや「無料のはず」の請求が起きます。
第2回では、AWS のグローバルなインフラ（リージョン・AZ・エッジロケーション・Local Zones・Wavelength）、AZ 名と AZ ID、AWS アカウントとルートユーザー、操作の手段、ARN とサービスエンドポイント、料金の構成要素、無料利用枠、Azure との対応を扱います。数値と料金は2026年9月時点で、料金は東京リージョンの例です。
グローバルインフラストラクチャの規模
AWS の基盤は、大きい順に リージョン ⊃ AZ ⊃ データセンター（DC） の階層になっています。エッジロケーションや Local Zones は、リージョンの外側に置かれた延長です。
- リージョン：39の地理的なエリア（2026年9月時点。サウジアラビア・チリの2つも発表済み。最新の数は公式の「グローバルインフラストラクチャ」のページ aws.amazon.com/about-aws/global-infrastructure/ で確かめる）。日本は 東京（ap-northeast-1、2011年）と大阪（ap-northeast-3、2021年）
- アベイラビリティーゾーン（AZ）：全体で120を超える。1つの AZ は1つ以上の DC でできていて、AZ どうしは数 km〜100 km 程度離れ、独立した電源・空調・ネットワーク を持つ。AZ 間は専用の低遅延の回線で結ばれ、遅延は1桁ミリ秒（同期レプリケーションができる程度）。1つのリージョンに3つ以上
- エッジロケーション：CloudFront・Route 53 などが使う数百の拠点（後の「エッジロケーション・Local Zones・Wavelength」の節）
- Local Zones：特定の都市に置かれた AZ の小型版。低遅延が必要な用途向け
- Outposts：AWS のラックを利用者の DC に置き、同じ API で使う（プライベートクラウド的な使い方。第1回の「配置モデル」）
- 東京リージョンで使える AZ は3つ（AZ ID：apne1-az1・az2・az4。次の次の節「AZ 名と AZ ID」）
リージョンと AZ
リージョンは地理的に独立したエリアで、リージョン間はデータもコントロールプレーンも原則として分離 されています。東京リージョンに作った EC2 は大阪リージョンの画面には出てきませんし、リージョン間の通信は、インターネット経由か AWS のバックボーン経由で明示的に設計する必要があります。
AZ はリージョンの中の独立した DC 群で、1つの AZ 全体が停止しても、ほかの AZ は動き続けるように設計されています。AWS の上での可用性の設計の基本は 「複数の AZ にまたがって配置する」 ことで、ELB・Auto Scaling（第4回）、RDS のマルチ AZ（第10回）は、いずれもこの前提で動きます。逆に、単一の AZ だけに置いたシステムは、AZ の障害（東京でも2019年8月に冷却の障害で発生）でそのまま止まります。
リージョンは、利用者との距離（遅延）、データの所在の規制、必要なサービスの提供の有無（新しいサービスは米国から順に展開）、料金（東京は米国東部より1〜2割高い） の4点で選びます。
- リージョン＝独立したエリア。リージョン間は 明示的に設計しないとつながらない
- AZ＝リージョンの中の独立した DC 群。マルチ AZ が可用性の設計の基本の単位
- 選ぶ基準：遅延・規制・サービスの提供の有無・料金
AZ の中・複数の AZ・リージョンをまたぐという冗長の範囲の考え方は、このブログの連載「ストレージ入門」第11回の「冗長の範囲：AZの中・複数のAZ・リージョン」でも扱います。
AZ 名と AZ ID
コンソールに出る ap-northeast-1a のような名前と、実際の物理的な AZ の関係には注意が要ります。
- 東京のように2012年11月より前に開設されたリージョンでは、コンソールに出る
ap-northeast-1aのような AZ 名と物理的な AZ の対応が、アカウントごとに異なる（2025年10月までに作ったアカウントの場合。負荷を分散するため）。A 社の 1a と B 社の 1a は、別の DC の可能性がある。大阪など新しいリージョンと、2025年11月以降に作ったアカウントでは対応は共通 - 物理的な AZ を一意に指す識別子が AZ ID（
apne1-az1など）。複数のアカウントの間で「同じ AZ に置いて遅延を下げたい」「AZ の障害の影響範囲を突き合わせたい」ときは、AZ ID で比べる - 確かめ方：
aws ec2 describe-availability-zones --region ap-northeast-1のZoneIdの列 - 東京の
apne1-az3は新しいアカウントには開放されておらず、使えるのは az1・az2・az4 の3つ - ネットワークの「同じセグメント」の感覚に近いのは AZ の中。AZ をまたぐ通信には、データ転送料（1 GB あたり 0.01 USD を双方向で。第12回）と遅延（AWS の説明では1桁ミリ秒）が乗る
冒頭の1つ目の相談がこれです。自分の ap-northeast-1a と取引先の ap-northeast-1a が同じとは限りません。AZ ID を突き合わせて 確かめます。「同じセグメントなら直接届き、違えばゲートウェイを経由する」という判定は、このブログの連載「TCP/IP入門」第7回の「デフォルトゲートウェイと宛先の判定」で扱います。
AZ 名と AZ ID の対応は、次のように表にして見ると分かりやすくなります（出力はアカウント A の場合の例）。
$ aws ec2 describe-availability-zones --region ap-northeast-1 \
--query "AvailabilityZones[].[ZoneName,ZoneId]" --output table
-------------------------------------
| DescribeAvailabilityZones |
+------------------+----------------+
| ap-northeast-1a | apne1-az4 |
| ap-northeast-1c | apne1-az1 |
| ap-northeast-1d | apne1-az2 |
+------------------+----------------+エッジロケーション・Local Zones・Wavelength
リージョンの外にも、利用者の近くで動く拠点があります。
- エッジロケーション：CloudFront（CDN）・Route 53（DNS）・AWS WAF・Global Accelerator が動く拠点。リージョンより多く、利用者の近くに置かれている。東京・大阪にも複数ある
- リージョナルエッジキャッシュ：エッジロケーションとオリジンの間にある中間のキャッシュの層
- Local Zones：都市部に置く EC2・EBS・VPC のサブセット。親リージョンの VPC を延長して使う。東京リージョン（ap-northeast-1）を親とする Local Zone は、台北（ap-northeast-1-tpe-1）に提供されている（2026年9月時点）
- Wavelength：通信事業者の 5G 網の中に置く拠点（日本では KDDI）。モバイル端末からの超低遅延の用途に使う
- 用途の違い：エッジは 「配信・名前解決を近くで」 行い、Local Zones は 「計算資源を近くに」 置く
Route 53 と CloudFront は第7回で扱います。Route 53 の DNS の機能は、このブログの連載「DNS入門」第10回「クラウド・社内環境のDNS」でも詳しく扱っています。
AWS アカウントとルートユーザー
AWS を使う単位は 「AWS アカウント」 で、契約・請求・リソースの境界 になります。アカウントを作ったときのメールアドレスとパスワードでログインするのが 「ルートユーザー」 で、請求の情報の変更、アカウントの閉鎖、サポートプランの変更、一部の S3 の設定など、IAM ユーザーではできない操作を含む 全権限 を持ちます。
そのため、ルートユーザーは日常の作業に使わず、MFA を設定し、アクセスキーは作らず、パスワードは金庫のように管理する のが原則です。AWS も、2024年5月に Organizations の管理アカウント、2024年6月に単独のアカウント、2025年6月にはメンバーアカウントを含むすべてのアカウントで、ルートユーザーの MFA を必須にしました。
実際の作業は IAM ユーザーか IAM ロール（第8回）で行い、複数のアカウントを部門・環境ごとに分けて Organizations（第8回）で束ねる構成が標準的になっています。1つのアカウントで全部を賄うと、権限の分離も請求の切り分けもできなくなります。
- アカウント＝契約・請求・リソースの境界
- ルートユーザー＝全権限。MFA 必須・アクセスキー禁止・日常には使わない
- 作業は IAM、複数のアカウントは Organizations で管理
アクセスの手段：コンソール・CLI・SDK・IaC
AWS を操作する手段はいくつかありますが、どの手段も最終的には同じ REST API を呼びます。
- マネジメントコンソール：ブラウザの GUI。学習・確認・単発の作業向け。裏では API を呼んでいる
- AWS CLI（v2）：
aws <サービス> <操作>の形式（例は下のコマンド） - SDK：Python（boto3）・Java・JavaScript など。アプリケーションから AWS を操作する
- IaC：CloudFormation・CDK・Terraform で構成をコードにする（第12回）。本番は手作業ではなく IaC が原則
- CloudShell：コンソールの中で使えるブラウザ上のシェル。CLI が設定済みで、手元に環境が無くても試せる
- どの手段も最終的には同じ REST API を呼ぶ。API の呼び出しは CloudTrail（第11回）にすべて記録される
$ aws sts get-caller-identity # 今どの認証情報で操作しているか
$ aws ec2 describe-instances --query "Reservations[].Instances[].[InstanceId,State.Name]" --output table
$ aws s3 cp ./log.txt s3://my-bucket/logs/最初の aws sts get-caller-identity は、作業の前に「どのアカウントの、どのユーザー・ロールで操作しているか」を確かめるコマンドです。次のような JSON が返ります（値は例）。
{
"UserId": "AIDAEXAMPLEUSERID1234",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/tanaka"
}リソースの識別：ARN とサービスエンドポイント
AWS のリソースは、ARN（Amazon Resource Name） で一意に識別します。
- すべてのリソースは ARN で一意に識別される。書式は
arn:partition:service:region:account-id:resource - 例：
arn:aws:s3:::my-bucket/logs/*（S3 のバケットはバケット名だけで全体で一意に決まるので、リージョンとアカウントが空）、arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abc123def456、arn:aws:iam::123456789012:role/AppRole（IAM はグローバルなのでリージョンが空）、arn:aws:lambda:ap-northeast-1:123456789012:function:hello - IAM ポリシー（第8回）の
Resourceで対象を指定するのに使う。ワイルドカード*が使える - サービスエンドポイント：API の接続先は
https://ec2.ap-northeast-1.amazonaws.comのように、サービスとリージョンで決まる。DNS の名前解決のとおり、名前は AWS 側の IP アドレスに解決される。VPC エンドポイント（第7回）を使うと、この名前が VPC の中のプライベート IP に解決されるようになる - グローバルサービス（IAM・Route 53・CloudFront・Organizations）と リージョナルサービス（EC2・VPC・RDS・Lambda など。S3 のバケットもリージョンに作られる）の区別を意識する
名前解決の流れ（スタブリゾルバーからキャッシュ DNS サーバーへの問い合わせ）は、このブログの連載「DNS入門」第3回「名前解決の流れ」で詳しく扱っています。
料金の構成要素
AWS の料金は、おおむね 「コンピューティング（時間）＋ストレージ（GB・月）＋リクエスト数＋データ転送（GB）」の合計 です。サービスごとに単価表があり、リージョンで異なります。
- 時間課金：EC2・RDS・NAT ゲートウェイなど。EC2 は秒単位（最低60秒、Linux の場合）。停止中は EC2 本体の課金は止まるが、EBS は続く（第4回）
- 容量課金：S3・EBS・EFS。GB・月で数える。EBS は確保した容量、S3 は実際に置いた容量。スナップショットも容量で課金される
- リクエスト数：Lambda・API Gateway・S3 の PUT・GET・DynamoDB など
- データ転送：インバウンドは無料、インターネットへのアウトバウンドが有料（東京：最初の 100 GB/月は無料（全リージョン合計）、以降は約 0.114 USD/GB）。AZ 間・リージョン間も有料（第12回）。「入れるのはタダ、出すと高い」
- パブリック IPv4：2024年2月から、1アドレスあたり 0.005 USD/時（約 3.6 USD/月）。EIP も、使用中でも課金される
- 見積は AWS Pricing Calculator（公式）で行う。東京は米国東部より1〜2割高い
見落としがちな費用は次のとおりです（東京リージョンの例、2026年9月時点）。
| 見落としがちな費用 | 単価の例 | どこで扱うか |
|---|---|---|
| NAT ゲートウェイの処理量 | 0.062 USD/GB | 第6回 |
| パブリック IPv4 | 0.005 USD/時 | 第6回 |
| データ転送（インターネットへ・AZ 間・リージョン間） | インターネットへ約 0.114 USD/GB、AZ 間 0.01 USD/GB（双方向） | 第12回 |
| スナップショット | 容量に応じて | 第5回 |
| CloudWatch Logs の取り込み量 | 0.76 USD/GB | 第11回 |
| 詳細モニタリング | メトリクスの数に応じて | 第11回 |
冒頭の2つ目の相談は、多くがこれです。検証で作った NAT ゲートウェイや EIP、パブリック IPv4 を持つ EC2 を 止めたり消したりせずに置いたまま にすると、触っていなくても時間で課金されます。
無料利用枠（2025年7月の改定）
AWS の無料利用枠は、2025年7月に仕組みが大きく変わりました（2026年9月時点の内容）。
- 2025年7月15日以降に作ったアカウントは、「無料プラン」か「有料プラン」を選ぶ 方式に変わった
- 無料プラン：最大6か月、最大 200 USD のクレジット（登録時に 100 USD＋所定の作業を終えると最大 100 USD）の範囲で使える。クレジットか期間が尽きるとアカウントが閉じられ（90日以内に有料プランへ切り替えないと削除）、課金は発生しない。Savings Plans・リザーブドインスタンス・一部の Marketplace の製品など、クレジットを一度に使い切るおそれのあるものは使えない
- 有料プラン：従来どおりの従量課金。クレジットは同じように付与される。本番・長期の利用向け
- 常時無料枠 は続く：Lambda 月100万リクエスト、DynamoDB 25 GB、CloudWatch の基本メトリクス、CloudFront 月 1 TB の転送、SNS 100万パブリッシュなど
- 改定前（2025年7月15日より前）のアカウントには、従来の 「12か月無料枠」（EC2 の t2・t3.micro 750時間/月など）が適用される
- 検証で無料枠を使う場合でも、Budgets（第12回）で上限のアラートを必ず設定する。「無料のはず」の請求は、初めての人の定番の事故
冒頭の2つ目の相談の続きです。有料プランを選んだアカウントや、改定前のアカウントでは、無料の範囲を超えた分はそのまま請求されます。アカウントを作ったら最初に Budgets を設定する、と覚えてください。
Azure との対応表①：全体像
ここまでの AWS の用語を、Azure の用語と対応させます。
| AWS | Azure | 補足 |
|---|---|---|
| AWS アカウント | サブスクリプション | Azure ではさらに上位に テナント（Entra ID ディレクトリ）、下位に リソースグループ がある |
| （タグ・リソースグループは任意） | リソースグループ | Azure ではすべてのリソースが必ずいずれかのリソースグループに属する。AWS の「リソースグループ」は任意のタグ集約 |
| AWS Organizations | 管理グループ | サブスクリプションを階層化 |
| リージョン／AZ | リージョン／可用性ゾーン | Azure には「リージョンペア」（東日本⇄西日本）があり、一部サービスの DR に使う |
| マネジメントコンソール | Azure Portal | ― |
AWS CLI（aws） | Azure CLI（az）／Azure PowerShell | ― |
| ARN | リソース ID | 階層パス形式（/subscriptions/…/resourceGroups/…/providers/…） |
| CloudFormation | ARM テンプレート／Bicep | Terraform は両方で使える |
| ルートユーザー | （相当なし。Entra ID のグローバル管理者＋サブスクリプション所有者） | Azure は ID 基盤が Entra ID に統合されている |
いちばん違うのは、Azure ではすべてのリソースが必ずリソースグループに属する ことと、ID の基盤が Entra ID に統合されている ことです。AWS のアカウントに当たるのはサブスクリプションですが、ユーザーの管理はその上のテナント（Entra ID）で行います。
考えてみよう
- 自分のアカウントで
aws ec2 describe-availability-zones --region ap-northeast-1を実行し、ap-northeast-1a がどの AZ ID に当たるかを確かめてみましょう。同僚のアカウントと比べるとどうなるでしょうか - 検証用のアカウントで、ルートユーザーに MFA が設定されているか、ルートユーザーのアクセスキーが残っていないかを確かめてみましょう
- EC2（パブリック IPv4 付き）と NAT ゲートウェイを1か月動かしたままにすると、何に料金がかかるでしょうか。AWS Pricing Calculator で見積もってみてください
ヒント：1は「AZ 名と AZ ID」、2は「AWS アカウントとルートユーザー」、3は「料金の構成要素」と「無料利用枠（2025年7月の改定）」の節を見直してください。
まとめ
- AWS の基盤は リージョン ⊃ AZ ⊃ DC。日本は東京（ap-northeast-1）と大阪（ap-northeast-3）
- 可用性の設計の基本は マルチ AZ。リージョン間は明示的に設計しないとつながらない
- 東京など古いリージョンでは AZ 名と物理的な AZ の対応がアカウントごとに異なることがある。物理的な AZ を比べるときは AZ ID
- エッジは「配信・名前解決を近くで」、Local Zones は「計算資源を近くに」
- アカウントは契約・請求・リソースの境界。ルートユーザーは MFA・アクセスキー禁止・日常に使わない
- 操作はどの手段も同じ API。本番は IaC、記録は CloudTrail。リソースは ARN で識別
- 料金は時間・容量・リクエスト・転送の合計。「入れるのはタダ、出すと高い」、検証でも Budgets を最初に
次回は、コンピューティングの前編として、EC2 と Nitro System・Graviton、インスタンスタイプ、AMI と起動テンプレート、EBS とインスタンスストア、ログインの手段、IMDS を扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）
- AWSの全体像（この記事）
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
- ストレージ
- ネットワーキング 前編（VPC・サブネット・SG・NACL）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
- Well-Architectedフレームワーク
- これまでのテーマとAWSの対応・まとめ
コメント