2026.09.22 インフラ

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

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

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

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

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

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

ap-northeast-1は、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名を独立してマッピングするリージョンに含まれており、2025年11月より前に作ったアカウントでは、同じ1aが別の物理ゾーンを指します。アカウント間でサブネットを共有する構成やマルチアカウント運用では、AZ IDで突き合わせる必要が出てきます。

第2に、リージョンをコードのどこで決めているかを1か所に揃えること。環境変数・プロファイル・SDKの引数・Terraformのproviderブロックが混在すると、検証環境と本番で違うリージョンに作られる事故が起きます。第3に、リージョンをまたぐ通信が料金表のどの行に当たるかを設計段階で確認することです。

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

AWSのリージョンは、地理的に離れた複数のデータセンター群をまとめた単位です。公式のグローバルインフラストラクチャのページには、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に分かれ、間に韓国が挟まる形になっているので、「東京の隣の番号が大阪」という思い込みで設定を書くと隣国にリソースを作ってしまいます。公式のリージョン一覧で、コードと表示名の対応を必ず引いてください。

リージョンコード	表示名	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

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

東京リージョンの物理的な構成は、公式のAZ一覧に載っています。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名を各アカウントへ独立してマッピングしていました。公式ドキュメントには、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本で出ます。公式に載っている例を東京リージョン向けに書き換えたのが次のコマンドです。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のドキュメントも、共有されたリソースがどのAZにあるかを受け手側が知るにはAZ IDが必要だ、という説明です。共有VPC構成やTransit Gateway越しの接続でAZをまたぐと通信が遠回りする設計になっていないか、ここで点検しておきます。ネットワークの初期設計をまとめて見直すならAWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説を先に読んでおくと、サブネット分割の判断が早く済みます。

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

リージョンは、API呼び出しのたびにエンドポイントとして解決されます。EC2のユーザーガイドも、コマンドラインやAPIでインスタンスを操作するときはリージョンエンドポイントの指定が必要だ、という記述です。どこで指定するかが散らばると、意図しないリージョンにリソースが生まれる事故につながります。

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

AWS CLIのリージョンは、コマンドの--regionオプション、環境変数、プロファイルの設定ファイルの順に解決されます。環境変数のドキュメントによると、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サポート終了への移行手順にまとめてあります。

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

PythonのSDKでは、リージョン未指定のままclient()を呼ぶとNoRegionErrorで落ちます。boto3の設定ドキュメントによると、解決順はクライアント生成時の引数、環境変数、設定ファイル、そして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と対で扱う形にしておけば、アカウントを増やしたときの手直しが要りません。

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

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

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

EC2のオンデマンド料金ページはリージョンを選ぶと表が切り替わる作りで、同じインスタンスタイプでも単価はリージョンごとに違います。記事や社内資料に単価を転記すると、改定のたびに古くなるので、必要になった時点で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とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説にまとめました。

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

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

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

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

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

確認の手順は単純で、使う予定のサービスが大阪で提供されているかをサービスエンドポイントの一覧で引くだけです。ここにap-northeast-3の行が無ければ、そのサービスは大阪では使えないと判断できる。DR設計では、待機系で落ちる機能を洗い出してから構成を決める順番になります。

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

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

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

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

検証だけ海外リージョンで進め、本番は東京で組む、という二段構えが現実的な進め方です。このとき検証用のコードにリージョンを直書きしないでおけば、提供開始のタイミングで向き先を変えるだけで済む。東京リージョンの延伸として大都市圏に配置されるLocal Zonesという選択肢もあり、位置づけはAWS Local Zonesのページで確認できます。

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

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

正しい表記はサービスエンドポイントの一覧が基準です。S3の場合はバケット名を含む仮想ホスト形式もあり、どちらを使うかでCORSやSDKの設定が変わります。S3側の仕様はAmazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説で扱いました。リポジトリ全体をgrepして表記を1つに揃えるところまでを、移行作業の1タスクとして積んでおきます。

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

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

回避策は3つあります。Auto Scalingグループに複数のAZと複数のインスタンスタイプを並べること、起動テンプレートで代替タイプを許可すること、確実に確保したい枠だけキャパシティ予約で押さえておくことです。世代や系列の読み替えはEC2インスタンスタイプの選び方：命名規則の読み方とCLI絞り込み・変更手順を実装者目線で解説を見ながら、代替候補を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戦略と移行ツール・費用と見送り判断を発注者視点で解説で移行パターンを確認してから構成に入る順番になります。

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

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

いずれの場合も、リージョンを分けた瞬間に運用の手数が増えます。監視の設定、IAMの管理、デプロイの経路がリージョンごとに必要になるためで、その負荷を見積もらずに「安いから」と分けると保守で回収されます。構成の判断に迷う段階から相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）で対応範囲を確認してください。

よくある質問

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

アジアパシフィック（東京）リージョンです。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では新規作成が制限され、新規アカウントの一覧から外れる場合があるとも説明しています。実際に使えるAZはaws ec2 describe-availability-zonesで自分のアカウントを確認してください。