---
title: "AWS東京リージョン（ap-northeast-1）とは｜AZ構成と指定方法・大阪との使い分け"
url: "https://www.issoh.co.jp/tech/details/17728/"
published: 2026-09-22
updated: 2026-10-01
categories: ["AWS"]
publisher: "株式会社一創"
---

# AWS東京リージョン（ap-northeast-1）とは｜AZ構成と指定方法・大阪との使い分け

ap-northeast-1は、AWSのアジアパシフィック（東京）リージョン、いわゆるAWS東京リージョンを指すリージョンコードです。日本国内向けのシステムをAWSに載せると、エンドポイント・ARN・Terraformの設定ファイル・CI/CDの環境変数と、あらゆる場所にこの文字列が現れます。ところが実装で引っかかるのはコードの意味ではなく、その先にあるアベイラビリティゾーン（AZ）の扱いです。`ap-northeast-1a`が自分のアカウントと他社のアカウントで同じ場所とは限らず、しかもその前提が2025年11月を境に変わりました。この記事では、東京リージョンのAZ構成、AZ名とAZ IDの対応をCLIで確定する手順、東京で使えるサービスの調べ方、CLI・SDK・Terraformでのリージョン解決順、過去の障害から読む設計の線引き、大阪リージョンとの使い分けと費用の見方を、公式ドキュメントの記述に沿って整理します。

## まとめ：ap-northeast-1で先に決める3点とAZ IDの扱い

結論を先に置きます。ap-northeast-1は東京リージョンのコードで、AZ IDは`apne1-az1`から`apne1-az4`までの4つ。アカウントを作った時点で有効になっている既定のリージョンなので、申請や有効化の操作は要りません。国内の利用者だけを相手にする業務システムなら、ここを既定に置いて問題ありません。判断が要るのは残りの3点です。

第1に、AZを`ap-northeast-1a`のような名前で固定しないこと。東京リージョンは[AZ名を独立してマッピングするリージョン](https://docs.aws.amazon.com/global-infrastructure/latest/regions/az-ids.html)に含まれており、2025年11月より前に作ったアカウントでは、同じ`1a`が別の物理ゾーンを指します。アカウント間でサブネットを共有する構成やマルチアカウント運用では、AZ IDで突き合わせる必要が出てきます。

第2に、リージョンをコードのどこで決めているかを1か所に揃えること。環境変数・プロファイル・SDKの引数・Terraformのproviderブロックが混在すると、検証環境と本番で違うリージョンに作られる事故が起きます。第3に、リージョンをまたぐ通信が料金表のどの行に当たるかを設計段階で確認することです。加えて、東京リージョンでも単一AZの障害は実際に起きているので、AZを2つ以上使う構成を最低ラインとして扱います。

## ap-northeast-1が指すのは東京リージョンという場所である

AWSのリージョンは、地理的に離れた複数のデータセンター群をまとめた単位です。[公式のグローバルインフラストラクチャのページ](https://aws.amazon.com/jp/about-aws/global-infrastructure/regions%5Faz/)には、2026年9月22日時点で39のリージョンと124のアベイラビリティゾーンが稼働し、各リージョンは隔離され物理的に分離された最低3つのAZで構成されると記載されています。

### リージョンコードの読み方とap-northeast-2や3との関係

リージョンコードは「大陸や地域の略称」「方角」「連番」の3つをハイフンでつないだ形です。`ap`はAsia Pacific、`northeast`はその中の北東部、末尾の数字はそのグループで開設された順番を示します。したがって`ap-northeast-1`は「アジアパシフィック北東部で最初のリージョン」であり、それが東京でした。

連番は国ごとに振られるわけではないので、そこが混乱のもとになります。`ap-northeast-2`はソウル（韓国）、`ap-northeast-3`が大阪（日本）です。日本のリージョンが1と3に分かれ、間に韓国が挟まる形になっているので、「東京の隣の番号が大阪」という思い込みで設定を書くと隣国にリソースを作ってしまいます。[公式のリージョン一覧](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html)で、コードと表示名の対応を必ず引いてください。

| リージョンコード       | 表示名            | AZ ID         |
| -------------- | -------------- | ------------- |
| ap-northeast-1 | アジアパシフィック（東京）  | apne1-az1〜az4 |
| ap-northeast-2 | アジアパシフィック（ソウル） | apne2-az1〜az4 |
| ap-northeast-3 | アジアパシフィック（大阪）  | apne3-az1〜az3 |
| us-east-1      | 米国東部（バージニア北部）  | use1-az1〜az6  |

### AWS東京リージョンはオプトイン不要で最初から使える既定リージョン

AWSのリージョンには、アカウント作成直後から使える「既定のリージョン」と、利用者が有効化しないと使えない「オプトインリージョン」の2種類があります。[アカウント管理のドキュメント](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)によると、2019年3月20日より前に開設されたリージョンは既定で有効になり、無効化もできません。それ以降に開設されたリージョンはオプトイン扱いで、有効化するまでコンソールのナビゲーションバーにも表示されない仕様です。

同じページのDefault Regionsの表には、Asia Pacific（Tokyo）の`ap-northeast-1`とAsia Pacific（Osaka）の`ap-northeast-3`が並んでいます。したがって東京と大阪を組み合わせる構成なら、リージョンの有効化という手順自体が発生しません。一方でオプトイン側の表にはAsia Pacific（Taipei）の`ap-east-2`などが載っており、台湾や東南アジアへ広げる構成では、有効化の申請とIAM情報の伝播を待つ時間を作業計画に入れる必要があります。

```
# 自分のアカウントで東京リージョンの有効化状態を確認する（2026年10月時点のAWS CLI v2）
$ aws account get-region-opt-status --region-name ap-northeast-1
{
    "RegionName": "ap-northeast-1",
    "RegionOptStatus": "ENABLED_BY_DEFAULT"
}
```

既定リージョンは無効化できないため、「使っていないリージョンを閉じて攻撃面を減らす」という発想は、東京やバージニア北部では成り立ちません。使わないリージョンを締め出したい場合は、後述するIAMポリシーの条件キーで制御する形になります。

### 東京リージョンのAZ IDはapne1-az1からaz4までの4つ

東京リージョンの物理的な構成は、[公式のAZ一覧](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-availability-zones.html)に載っています。ap-northeast-1の行は`apne1-az1`・`apne1-az2`・`apne1-az3`・`apne1-az4`の4行で、地理はいずれもJapanと記載されました。大阪のap-northeast-3は`apne3-az1`から`apne3-az3`までの3つなので、東京のほうが1ゾーン多い構成になります。

注意したいのは、この4という数がすべてのアカウントで見えるとは限らない点です。同じ公式ページに「Constrained Availability Zones」という節があり、AZの拡張余地がなくなった場合、そのAZに既存リソースを持たないアカウントからは新規作成が制限され、最終的には新規アカウントのAZ一覧から外れることがあると説明されています。結果として、自分のアカウントで見えるAZ数と他アカウントのAZ数は一致しないことがある、というのが公式の立場です。ドキュメントの数を信じて4AZ前提の構成図を書く前に、次の節のコマンドで実際のアカウントに何が見えるかを確認してください。

## AZ名とAZ IDの対応はアカウントの作成時期によって変わる

ここが東京リージョンで一番踏みやすい落とし穴です。`ap-northeast-1a`のようなAZ名は、アカウントごとに物理ゾーンへ割り当てられる「表示名」であって、物理位置そのものを指すわけではありません。

### 2025年11月を境に東京リージョンのAZマッピングは統一された

もともとAWSは、利用者が先頭のAZにリソースを寄せてしまうのを避けるため、AZ名を各アカウントへ独立してマッピングしていました。[公式ドキュメント](https://docs.aws.amazon.com/global-infrastructure/latest/regions/az-ids.html)には、2012年11月より後に追加されたリージョンは統一マッピングを使うと明記されています。東京リージョンは2011年の開設なので、この「独立マッピング」側に残った古参リージョンの1つでした。

同じページの「Regions with independently mapped Availability Zones」には、対象リージョンとしてバージニア北部・北カリフォルニア・オレゴン・シンガポール・シドニー・東京・アイルランド・サンパウロ・GovCloud（US-West）の9つが挙がっています。そして目を引く追記が入りました。この独立マッピングが効くのは2025年11月より前に作成されたアカウントで、2025年11月以降に作成したアカウントは統一マッピングになる、というものです。

つまり現在は、同じ東京リージョンでもアカウントの作成時期で挙動が2通りに分かれています。2020年に作った本番アカウントと、2026年に作った検証アカウントを並べると、`ap-northeast-1a`が別の物理ゾーンを指す可能性が残るわけです。新しいアカウント同士なら一致するので、「昔から言われている話だから自分には関係ない」と切り捨てる判断と、「常にずれる」と身構える判断の両方とも外れます。

### CLIでAZ名とAZ IDの対応表を出して構成に固定する手順

対応表はコマンド1本で出ます。[公式に載っている例](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-availability-zones.html)を東京リージョン向けに書き換えたのが次のコマンドです。VPCとサブネットの設計に入る前に、対象アカウントすべてで流しておきます。

```
$ aws ec2 describe-availability-zones \
  --filters Name=zone-type,Values=availability-zone \
  --region ap-northeast-1 \
  --query "AvailabilityZones[].{Name:ZoneName,ID:ZoneId}" \
  --output table

----------------------------------
|   DescribeAvailabilityZones    |
+------------+-------------------+
|     ID     |       Name        |
+------------+-------------------+
|  apne1-az4 |  ap-northeast-1a  |
|  apne1-az1 |  ap-northeast-1c  |
|  apne1-az2 |  ap-northeast-1d  |
+------------+-------------------+
```

出力例に置いた並びは、AZ名の末尾の文字とAZ IDの番号が一致しない様子を示すためのものです。実際に返る組み合わせはアカウントごとに違うため、この表をそのまま設計へ持ち込まないでください。自分のアカウントで引いた結果を構成図とパラメータストアに書き残すのが正しい進め方になります。

EC2インスタンスの中から確認したい場合は、インスタンスメタデータにAZ ID専用のパスが用意されています。IMDSv2でトークンを取ってから叩く形です。

```
$ TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

$ curl -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/placement/availability-zone-id
apne1-az2
```

アカウントをまたいでサブネットを共有する構成では、AZ IDが事実上の共通言語になります。[AWS RAMのドキュメント](https://docs.aws.amazon.com/ja%5Fjp/ram/latest/userguide/working-with-az-ids.html)も、共有されたリソースがどのAZにあるかを受け手側が知るにはAZ IDが必要だ、という説明です。共有VPC構成やTransit Gateway越しの接続でAZをまたぐと通信が遠回りする設計になっていないか、ここで点検しておきます。ネットワークの初期設計をまとめて見直すなら[AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説](https://www.issoh.co.jp/tech/details/15359/)を先に読んでおくと、サブネット分割の判断が早く済みます。

## AWS東京リージョンで使えるサービスをコマンドと公式一覧で調べる

「東京リージョンでそのサービスは使えるのか」は、設計の初日に必ず出る問いです。記事や社内資料の一覧表は提供開始のたびに古くなるので、AWSが公開しているデータを直接引く手順を持っておくと判断がぶれません。

### 東京リージョンで使えるサービスの公開パラメータによる一覧取得手順

AWS Systems Managerのパラメータストアには、リージョン・サービス・AZの情報をAWS自身が載せた公開パラメータがあります。[公開パラメータのドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-store-public-parameters-global-infrastructure.html)によると、パス`/aws/service/global-infrastructure`の問い合わせに対応するリージョンの中にAsia Pacific（Tokyo）が含まれています。東京で提供されているサービスの一覧を取得するコマンドは、次のとおりです。

```
# 東京リージョンで提供されているサービスのコード一覧（アルファベット順）
$ aws ssm get-parameters-by-path \
    --path /aws/service/global-infrastructure/regions/ap-northeast-1/services \
    --region ap-northeast-1 \
    --query 'Parameters[].Value | sort(@)' --output text

# 特定のサービスが提供されているリージョンを逆引きする（例: Systems Manager）
$ aws ssm get-parameters-by-path \
    --path /aws/service/global-infrastructure/services/ssm/regions \
    --region ap-northeast-1 \
    --query 'Parameters[].Value | sort(@)' --output text

# 東京リージョンのAZ IDを公開パラメータから引く
$ aws ssm get-parameters-by-path \
    --path /aws/service/global-infrastructure/regions/ap-northeast-1/availability-zones \
    --region ap-northeast-1 \
    --query 'Parameters[].Value | sort(@)' --output text
```

1本目の出力をファイルに保存し、大阪の`ap-northeast-3`で同じコマンドを流した結果と`diff`で突き合わせれば、「東京にあって大阪に無いサービス」が一覧になります。DR設計の前提確認として、この差分を設計書に貼っておく運用が扱いやすいでしょう。

ただし、サービスが東京にあることと、そのサービスの全機能・全モデルが東京で使えることは別の話です。生成AIのように機能単位・モデル単位でリージョン対応が分かれるサービスでは、サービス単位の一覧だけでは足りません。Amazon Bedrockの場合の具体的な制約は[Amazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年版】](https://www.issoh.co.jp/tech/details/4204/)で扱っています。

### リージョン別サービス一覧のページで機能単位の提供状況を確かめる

ブラウザで確認したい場合は、[AWS Services by Region](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)のページでリージョンを選ぶと、そのリージョンで提供中のサービスが表示されます。発注者や上長への説明資料に貼るときはこちらが扱いやすく、CLIを使えない関係者とも同じ情報源を共有できます。

エンドポイントの単位まで確かめたいときは、既存の節でも触れた[サービスエンドポイントの一覧](https://docs.aws.amazon.com/ja%5Fjp/general/latest/gr/rande.html)が基準になります。公開パラメータ・サービス一覧ページ・エンドポイント一覧の3つで食い違いが出た場合は、サービスごとのユーザーガイドにある対応リージョンの記述を正とし、確認日を設計書に残しておきます。

## AWS CLIとSDK・Terraformでリージョンを指定する優先順位

リージョンは、API呼び出しのたびにエンドポイントとして解決されます。[EC2のユーザーガイド](https://docs.aws.amazon.com/ja%5Fjp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)も、コマンドラインやAPIでインスタンスを操作するときはリージョンエンドポイントの指定が必要だ、という記述です。どこで指定するかが散らばると、意図しないリージョンにリソースが生まれる事故につながります。

### 環境変数AWS\_REGIONとプロファイル設定の解決順を押さえる

AWS CLIのリージョンは、コマンドの`--region`オプション、環境変数、プロファイルの設定ファイルの順に解決されます。[環境変数のドキュメント](https://docs.aws.amazon.com/ja%5Fjp/cli/latest/userguide/cli-configure-envvars.html)によると、`AWS_REGION`と`AWS_DEFAULT_REGION`の両方が使え、AWS CLI v2で優先されるのは`AWS_REGION`の設定です。CIのコンテナで`AWS_DEFAULT_REGION`だけを設定した状態にSDKが混在すると、挙動が読みにくくなるので片方へ寄せます。

```
# 設定ファイルに東京を既定として書く
$ aws configure set region ap-northeast-1 --profile prod-tokyo

# 一時的に別リージョンへ向ける（環境変数が設定ファイルより優先される）
$ AWS_REGION=ap-northeast-3 aws ec2 describe-availability-zones \
    --query "AvailabilityZones[].ZoneName" --output text

# いま実際にどのリージョンで動いているかを確認する
$ aws configure list
      Name              Value          Type      Location
      ----              -----          ----      --------
   profile         prod-tokyo   manual   --profile
    region     ap-northeast-1   config-file    ~/.aws/config
```

`aws configure list`のType列とLocation列は、その値がどこから来たかを示します。想定と違うリージョンで動いているときの切り分けは、この2列を読むのが一番早い。CLIそのものの導入やSSO認証の設定は[AWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順](https://www.issoh.co.jp/tech/details/17403/)にまとめてあります。

### リージョンを指定し忘れてboto3やCLIが落ちるときの対処

PythonのSDKでは、リージョン未指定のまま`client()`を呼ぶと`NoRegionError`で落ちます。[boto3の設定ドキュメント](https://docs.aws.amazon.com/boto3/latest/guide/configuration.html)によると、解決順はクライアント生成時の引数、環境変数、設定ファイル、そしてEC2やコンテナのインスタンスメタデータの順です。Lambdaでは実行環境が`AWS_REGION`を自動で渡すため落ちませんが、ローカル実行やCIコンテナでは渡らない場合があります。

```
import boto3
from botocore.exceptions import NoRegionError

# 引数で明示する（最優先・テストで固定したいときはこれ）
ec2 = boto3.client("ec2", region_name="ap-northeast-1")

# いま解決されているリージョンを確認する
session = boto3.session.Session()
print(session.region_name)  # ap-northeast-1

try:
    s3 = boto3.client("s3")
except NoRegionError:
    # 環境変数も設定ファイルもメタデータも無い状態
    s3 = boto3.client("s3", region_name="ap-northeast-1")
```

Terraformでは、providerブロックの`region`引数、`AWS_REGION`環境変数、共有設定ファイルの順で解決されます。複数リージョンにリソースを置く構成では、providerに`alias`を付けて呼び分けるのが定石です。

```
provider "aws" {
  region = "ap-northeast-1"   # 既定は東京
}

provider "aws" {
  alias  = "osaka"
  region = "ap-northeast-3"   # DR先として大阪を併用する
}

# AZ名を直書きせず、データソースから引いてAZ IDで固定する
data "aws_availability_zones" "tokyo" {
  state = "available"
  filter {
    name   = "zone-type"
    values = ["availability-zone"]
  }
}

output "tokyo_az_map" {
  value = zipmap(
    data.aws_availability_zones.tokyo.names,
    data.aws_availability_zones.tokyo.zone_ids,
  )
}
```

AZ名をハードコードしたコードは、別アカウントへ複製した瞬間に意味が変わります。データソース経由で引いて`zone_ids`と対で扱う形にしておけば、アカウントを増やしたときの手直しが要りません。

### 組織で使うリージョンを東京と大阪に絞るIAMポリシーの書き方

解決順を揃えても、手作業の操作やコピーしたスクリプトで海外リージョンにリソースが作られる事故は残ります。これを権限で止めるのが条件キー`aws:RequestedRegion`です。[IAMユーザーガイドのポリシー例](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference%5Fpolicies%5Fexamples%5Faws%5Fdeny-requested-region.html)を、東京と大阪だけを許す形に書き換えると次のようになります。

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideTokyoAndOsaka",
      "Effect": "Deny",
      "NotAction": [
        "cloudfront:*",
        "iam:*",
        "organizations:*",
        "route53:*",
        "support:*",
        "pricing:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-1", "ap-northeast-3"]
        }
      }
    }
  ]
}
```

公式の例がCloudFront・IAM・Route 53・Supportを`NotAction`で除外しているのは、これらが`us-east-1`に単一のエンドポイントを持つグローバルサービスで、除外しないとすべての要求が拒否されるためです。本記事で紹介したPrice List APIも`us-east-1`へ投げるので、単価比較を社内で回すなら`pricing:*`を除外リストに足しておく必要があります。このポリシーは許可を与えるものではなく、拒否だけを足す形なので、既存の許可ポリシーと組み合わせて使います。

## ap-northeast-1と大阪・海外リージョンを費用と遅延で比べる

リージョン選定は「近いほうが速い」だけでは決まりません。単価・データ転送・サービスの提供状況の3つが絡みます。応答時間の考え方そのものを整理したい場合は[レイテンシーとは？レスポンスタイムとの違い・原因・目安と改善方法](https://www.issoh.co.jp/column/details/7053/)を参照してください。

### 東京と大阪・バージニア北部の単価差をPrice List APIで測る

[EC2のオンデマンド料金ページ](https://aws.amazon.com/jp/ec2/pricing/on-demand/)はリージョンを選ぶと表が切り替わる作りで、同じインスタンスタイプでも単価はリージョンごとに違います。記事や社内資料に単価を転記すると、改定のたびに古くなるので、必要になった時点でPrice List APIから引くのが確実です。次のコマンドは料金APIのエンドポイントがある`us-east-1`へ投げる点に注意します。

```
$ aws pricing get-products --region us-east-1 \
  --service-code AmazonEC2 \
  --filters \
    "Type=TERM_MATCH,Field=instanceType,Value=m7i.large" \
    "Type=TERM_MATCH,Field=regionCode,Value=ap-northeast-1" \
    "Type=TERM_MATCH,Field=operatingSystem,Value=Linux" \
    "Type=TERM_MATCH,Field=tenancy,Value=Shared" \
    "Type=TERM_MATCH,Field=preInstalledSw,Value=NA" \
    "Type=TERM_MATCH,Field=capacitystatus,Value=Used" \
  --query 'PriceList[0]' --output text | \
  python -c "import sys,json;d=json.load(sys.stdin);t=d['terms']['OnDemand'];print([list(v['priceDimensions'].values())[0]['pricePerUnit']['USD'] for v in t.values()])"
```

`regionCode`を`ap-northeast-3`や`us-east-1`へ差し替えれば、同じ条件で単価を並べられます。インスタンスタイプそのものの選び方は[Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15424/)にまとめました。

### 東京と他リージョンをまたぐデータ転送料金で費用が伸びる構成例

単価差より効いてくるのがデータ転送です。同一AZ内の通信、AZをまたぐ通信、リージョンをまたぐ通信、インターネットへの送出で、それぞれ料金の扱いが変わります。典型的なのは、アプリケーションを東京、データベースを大阪に置くような分離。あるいは分析基盤だけを海外リージョンに寄せて、ログを常時転送する構成です。どちらもリージョン間転送が定常的に発生するので、転送量の見積もりを先に出しておきます。オンプレミスとの接続を絡める場合は、専用線の費用構造も一緒に見る必要があり、[AWS Direct Connectとは？専用線接続の仕組み・VPNとの違い・料金と導入判断【2026年版】](https://www.issoh.co.jp/tech/details/15476/)で整理した観点が使えます。

| 通信の経路      | 設計上の扱い       |
| ---------- | ------------ |
| 同一AZ内      | 遅延も費用も最小     |
| AZ間（東京内）   | 冗長化の標準構成     |
| 東京と大阪の間    | 転送量の見積もり必須   |
| 東京と海外リージョン | 遅延と費用の両方が増える |

### 大阪ap-northeast-3をDR先に選ぶときに確認する制約

国内で災害対策（DR）の待機系を持つなら、大阪リージョンが第一候補になります。距離があるため同時被災の確率が下がり、国内にデータを留める要件も満たせるからです。ただし大阪は東京より後発で、AZは3つ、提供サービスの顔ぶれも東京と完全に同じではありません。

確認の手順は単純で、使う予定のサービスが大阪で提供されているかを[サービスエンドポイントの一覧](https://docs.aws.amazon.com/ja%5Fjp/general/latest/gr/rande.html)で引くだけです。ここに`ap-northeast-3`の行が無ければ、そのサービスは大阪では使えないと判断できる。DR設計では、待機系で落ちる機能を洗い出してから構成を決める順番になります。前の章で紹介した公開パラメータの差分を使えば、この洗い出しを機械的に済ませられます。

## AWS東京リージョンの過去の障害事例から設計の線引きを読み解く

東京リージョンを既定に置くと決めたら、次に決めるのは「どこまでの障害に耐えるか」です。AWSは大きな障害のあとに事後報告（Post-Event Summary）を公開しており、東京リージョンについても原因と影響範囲が文章で残っています。ここでは設計判断に効く2件を取り上げます。

### 2019年8月の東京リージョン障害は単一AZの空調停止から始まった

[2019年8月23日の事後報告](https://aws.amazon.com/message/56489/)によると、東京リージョンの単一のAZの一部で、空調を制御するシステムの不具合から冷却が止まり、EC2インスタンスの停止とEBSボリュームの性能劣化が起きました。日本時間の12時36分ごろに始まり、大部分は18時30分ごろまでに復旧したと記載されています。当該AZで動いていたRDSやElastiCacheなどにも影響が及びました。

報告の中で読み取るべき一文は、複数のAZでアプリケーションを稼働させていた利用者は事象の発生中も可用性を保てていた、という記述です。単一AZの障害はリージョンを分けなくても、AZを分けるだけで吸収できる。東京リージョンの設計でマルチAZを最低ラインに置く根拠は、この事後報告にあります。前の章で扱ったAZ IDの固定は、複数アカウントにまたがる構成で「本当に別のAZに分かれているか」を確かめるための手順でもあるわけです。

### 2021年9月のDirect Connect障害が示した接続経路の冗長化

[2021年9月2日の事後報告](https://aws.amazon.com/message/17908/)は、東京リージョンへのDirect Connect接続が日本時間7時30分ごろから13時42分ごろまで影響を受けた事象を扱っています。原因はDirect Connectロケーションから東京リージョンのデータセンターネットワークへ向かう経路上のネットワーク機器で、報告ではVPN接続や他リージョンへのDirect Connect、AZ間の通信は影響を受けなかったと説明されています。

ここから読み取れるのは、AZをいくら分けても、オンプレミスとAWSをつなぐ経路が1本なら業務は止まるという事実です。拠点や基幹システムと東京リージョンを専用線で結ぶ構成では、Direct Connectを複数ロケーションで冗長化するか、インターネットVPNを予備経路として持つかを、構成の初期段階で決めておきます。

### 障害の事後報告から逆算する東京リージョン設計の線引きと判断軸

2件の事後報告を並べると、設計の線引きは3段階に整理できます。第1段階は「単一AZの障害に耐える」で、東京リージョン内の複数AZにアプリケーションとデータベースを分けるだけで達成できます。第2段階は「接続経路の障害に耐える」で、Direct ConnectやVPNを複数経路で持つ構成です。第3段階が「リージョン全体の停止に耐える」で、大阪リージョンに待機系を置くDR構成になります。

第3段階まで進むと、データの複製・切り替え手順・定期的な訓練まで含めて費用が一段上がります。業務の停止許容時間（RTO）とデータの損失許容量（RPO）から、どの段階まで必要かを決めるのが順序です。RPOとRTOの目安と構成パターンは[DR対策とは？構成4パターンのRPO・RTO目安とDR計画の作り方](https://www.issoh.co.jp/column/details/9439/)で整理しています。運用中は[AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/aws-health-dashboard-status.html)で東京リージョンのサービス状態と、自分のアカウントに影響するイベントを確認できるので、監視の通知先に組み込んでおくとよいでしょう。どの段階を採るかの見積もりから相談したい場合は、[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)で対応範囲を確認できます。

## ap-northeast-1で実装が止まる場面と回避手順を押さえる

東京リージョンを選んだあとで詰まる場面は、だいたい3つに集約されます。新サービスの提供時期、文字列の不一致、そしてAZの偏りです。

### 新しいサービスが東京リージョンに来るまでの期間をどう埋めるか

AWSの新サービスや新機能は、バージニア北部（us-east-1）やオレゴン（us-west-2）で先に提供され、東京へ来るまでに時間が空くことがあります。生成AI関連のモデルや新しいインスタンスタイプでは、この差が数か月に及ぶ場合も出てきました。

検証だけ海外リージョンで進め、本番は東京で組む、という二段構えが現実的な進め方です。このとき検証用のコードにリージョンを直書きしないでおけば、提供開始のタイミングで向き先を変えるだけで済む。東京リージョンの延伸として大都市圏に配置されるLocal Zonesという選択肢もあり、位置づけは[AWS Local Zonesのページ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)で確認できます。前述の公開パラメータの例にも、東京リージョンのAZ ID接頭辞`apne1`を冠したLocal Zone`apne1-tpe1-az1`（台北）が載っています。

### エンドポイントとARNに現れるap-northeast-1の表記を揃える

リージョンコードはエンドポイントのホスト名にもARNにも埋め込まれます。S3なら`s3.ap-northeast-1.amazonaws.com`、ARNなら`arn:aws:s3:ap-northeast-1:123456789012:...`という形です。ここで起きがちなのが、設定ファイルやドキュメントに`ap-northeast1`や`apne1`といった表記揺れが混ざり、一致検索や置換が空振りする問題になります。

正しい表記は[サービスエンドポイントの一覧](https://docs.aws.amazon.com/ja%5Fjp/general/latest/gr/rande.html)が基準です。S3の場合はバケット名を含む仮想ホスト形式もあり、どちらを使うかでCORSやSDKの設定が変わります。S3側の仕様は[Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15433/)で扱いました。リポジトリ全体をgrepして表記を1つに揃えるところまでを、移行作業の1タスクとして積んでおきます。

### 特定のAZに寄った設計がキャパシティ不足で詰まるのを避ける対策

1つのAZにインスタンスを寄せると、そのAZで該当インスタンスタイプの在庫が尽きたときに起動できなくなります。`InsufficientInstanceCapacity`が返るのはこの状況で、新しい世代のインスタンスやGPUインスタンスで起きやすい。特に東京リージョンは利用が多く、需要の集中しやすいリージョンです。

回避策は3つあります。Auto Scalingグループに複数のAZと複数のインスタンスタイプを並べること、起動テンプレートで代替タイプを許可すること、確実に確保したい枠だけキャパシティ予約で押さえておくことです。世代や系列の読み替えは[EC2インスタンスタイプの選び方：命名規則の読み方とCLI絞り込み・変更手順を実装者目線で解説](https://www.issoh.co.jp/tech/details/17679/)を見ながら、代替候補を2つ3つ用意しておきます。

```
# 指定したインスタンスタイプが東京のどのAZで提供されているか確認する
$ aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters Name=instance-type,Values=m7i.large \
  --region ap-northeast-1 \
  --query "InstanceTypeOfferings[].Location" --output text
ap-northeast-1a ap-northeast-1c ap-northeast-1d
```

新しい世代のタイプほど提供AZが限られるため、Auto Scalingグループのサブネットを決める前に流しておく作業です。

## 受託開発でap-northeast-1を選ぶ条件と見送る場面を示す

ここまでの内容を、案件の判断に落とします。私たちが国内の業務システムを受託する場合、既定は東京リージョンです。そのうえで、例外をどこに置くかを決めます。

### 国内利用者向けの業務システムで東京リージョンを既定に置く条件

利用者が国内に閉じ、データを国内に置く要件があり、運用担当も国内にいる。この3つが揃うなら東京リージョンで迷う必要はありません。AZを3つ使う構成にしておけば可用性の設計も標準的な形に収まり、ドキュメントや事例も国内向けのものが揃っています。

設計時に決めておくのは、AZをいくつ使うかと、AZ IDをどこに記録するかの2点だけです。既存システムからの移し替えを含む場合は、[AWS移行とは？7R戦略と移行ツール・費用と見送り判断を発注者視点で解説](https://www.issoh.co.jp/column/details/16408/)で移行パターンを確認してから構成に入る順番になります。

### ap-northeast-1を選ばない判断になる条件と代替の置き方

東京を外す判断になるのは、次の3つの場合です。第1に、利用者の大半が海外にいるとき。アジア域内ならシンガポールやソウル、欧米向けならアイルランドやバージニア北部のほうが応答時間の面で有利になります。第2に、使いたいサービスが東京で提供されていないとき。この場合は該当機能だけを別リージョンに置き、本体は東京に残す部分的な分離が現実解です。第3に、費用の差が構成全体に効くほど大きいとき。ただしリージョン間の転送料金を含めて比べないと、単価だけ見た比較は外れます。

いずれの場合も、リージョンを分けた瞬間に運用の手数が増えます。監視の設定、IAMの管理、デプロイの経路がリージョンごとに必要になるためで、その負荷を見積もらずに「安いから」と分けると、保守の負担で費用削減分が相殺されるためです。リージョンを分けたときは、前述の`aws:RequestedRegion`の許可リストにも追加先を足しておかないと、権限で弾かれて作業が止まります。構成の判断に迷う段階から相談したい場合は、[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)で対応範囲を確認してください。

## よくある質問

### ap-northeast-1はどこのリージョンですか？

AWS東京リージョン、正式な表示名はアジアパシフィック（東京）です。`ap`がAsia Pacific、`northeast`がその北東部、`1`がそのグループで最初に開設されたリージョンであることを示します。韓国のソウルが`ap-northeast-2`、大阪が`ap-northeast-3`なので、番号だけで日本のリージョンを判断しないでください。

### ap-northeast-1aは他のアカウントでも同じ場所ですか？

アカウントの作成時期によります。東京リージョンはAZ名を独立してマッピングするリージョンに含まれ、2025年11月より前に作られたアカウントでは、同じ`1a`が別の物理ゾーンを指す場合があります。2025年11月以降に作成したアカウントは統一マッピングです。アカウントをまたいで位置を揃えるなら、`apne1-az1`のようなAZ IDで突き合わせます。

### 東京リージョンのアベイラビリティゾーンはいくつありますか？

公式のAZ一覧には`apne1-az1`から`apne1-az4`までの4つが載っています。ただし公式は、拡張余地がなくなったAZでは新規作成が制限され、新規アカウントの一覧から外れる場合があるとも説明しています。AWS東京リージョンで実際に使えるAZは`aws ec2 describe-availability-zones`で自分のアカウントを確認してください。

### ap-northeast-1とap-northeast-3はどう使い分けますか？

通常のワークロードは東京、災害対策の待機系に大阪、という組み合わせが基本です。どちらも既定で有効なリージョンなので、有効化の手続きは要りません。大阪はAZが3つで、提供サービスも東京と完全には一致しません。待機系で使う予定のサービスがサービスエンドポイントの一覧や公開パラメータに`ap-northeast-3`を持つかを先に確認し、落ちる機能を洗い出してから構成を決めます。

### リージョンは後から変更できますか？

リソースそのものを移すことはできません。AMIやスナップショットのコピー、S3のレプリケーション、データベースのダンプ移送といった手段で、別リージョンに作り直す形になります。ダウンタイムと転送料金が伴うため、東京リージョンを選ぶかどうかの最初の判断は、作り直しの手間を織り込んで行います。

## 関連記事

- [AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説](https://www.issoh.co.jp/tech/details/15359/)：AZを決めたあとのサブネット分割とセキュリティグループの初期設計
- [AWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順](https://www.issoh.co.jp/tech/details/17403/)：本記事のコマンドを流す前提になるCLI v2の導入と認証設定
- [EC2インスタンスタイプの選び方：命名規則の読み方とCLI絞り込み・変更手順を実装者目線で解説](https://www.issoh.co.jp/tech/details/17679/)：AZごとの提供状況を踏まえた代替インスタンスタイプの選び方

---

出典: [AWS東京リージョン（ap-northeast-1）とは｜AZ構成と指定方法・大阪との使い分け](<https://www.issoh.co.jp/tech/details/17728/>)（株式会社一創）