AWS Local Zones 完全ガイド
大都市のユーザーに超低レイテンシーでAWSサービスを届ける「出前キッチン」
先に結論：押さえるべき4つのポイント
Local Zones = 大都市の近くに置かれたAWSの「出前キッチン」。親リージョンのサブセットを、ユーザーに地理的に近い場所で提供し、レイテンシーを1桁ミリ秒に短縮する。
使えるサービスはリージョンの一部。EC2、EBS、ELB、VPCサブネットなどが利用可能。RDSやS3などは親リージョンを利用する。
VPCは親リージョンで作り、サブネットをLocal Zoneに配置する。既存VPCを拡張するだけなので、ネットワーク設計がシンプル。
リアルタイムゲーム、メディア制作、ML推論など「低レイテンシーが命」のワークロードに最適。一般的なWebアプリはリージョンで十分。
出前キッチンで理解する AWS Local Zones
大きなレストラン（AWSリージョン）は郊外にあって品揃えは抜群ですが、都心のお客さんへの配達には時間がかかります。そこで、都心に出前専用の小さなキッチン（Local Zone）を開設し、人気メニューだけを素早く届ける ── これがAWS Local Zonesの考え方です。
| 出前キッチンの世界 | AWSの世界 | ポイント |
|---|---|---|
| 郊外の大型レストラン（本店） | AWS リージョン（例: 東京） | フルメニュー（全サービス）が揃う拠点 |
| 都心の出前キッチン | Local Zone（例: 大阪） | 人気メニュー（EC2等）だけ出す小規模拠点 |
| 出前キッチンのメニュー | EC2, EBS, ELB, VPCサブネット等 | 限定メニュー＝利用可能サービスのサブセット |
| 本店にしかないメニュー | RDS, S3, Lambda, etc. | 出前キッチンでは扱わない＝リージョン限定サービス |
| 出前キッチンの住所 | Local Zoneの AZ 名（例: ap-northeast-1-tky-1a） | サブネット作成時に指定するゾーン名 |
| 本店と出前キッチンの連絡網 | 親リージョンとの高帯域プライベート接続 | AWSが管理するネットワークで自動接続 |
| 近所のお客さん | エンドユーザー（大都市圏） | 距離が近い＝レイテンシーが小さい |
AWS Local Zones アーキテクチャ概要図
親リージョンのVPCにLocal Zoneサブネットを追加し、低レイテンシーが必要なリソースだけをLocal Zoneに配置します。
Local Zones を有効化する3ステップ
Local Zoneはデフォルトでは無効です。以下の手順で有効にし、リソースを配置します。
Local Zone を有効化（オプトイン）
EC2コンソールの「設定」>「ゾーン」から、使いたいLocal Zoneを有効化します。たとえ話なら「出前キッチンの開業届を出す」段階です。
VPC にサブネットを追加
親リージョンのVPCに、Local Zoneを指定したサブネットを作成します。「出前キッチンの住所を本店の台帳に登録する」イメージです。
リソースを配置
EC2インスタンスやELBをLocal Zoneサブネットに起動します。「出前キッチンにシェフ（EC2）と受付（ELB）を配置する」段階です。
Local Zone で使える主なサービス
Local Zoneはリージョンの全サービスが使えるわけではありません。以下がよく使われるサービスです。
EC2
低レイテンシーが必要なコンピューティングを、エンドユーザーの近くで実行。
EBS
EC2に接続するブロックストレージ。gp3, io1等のボリュームタイプに対応。
ELB（ALB/NLB）
Local Zone内のEC2にトラフィックを分散。ユーザーに近い場所でLBを実行。
VPC サブネット
親リージョンVPCの一部としてLocal Zoneにサブネットを作成。
実装例：Local Zone にサブネットとEC2を作成
# Step 1: Local Zone を有効化（オプトイン）
aws ec2 modify-availability-zone-group \
--group-name "ap-northeast-1-tky-1" \
--opt-in-status "opted-in"
# Step 2: Local Zone にサブネットを作成
aws ec2 create-subnet \
--vpc-id "vpc-0abc123def456" \
--cidr-block "10.0.10.0/24" \
--availability-zone "ap-northeast-1-tky-1a"
# Step 3: EC2 インスタンスを起動
aws ec2 run-instances \
--image-id "ami-0abcdef1234567890" \
--instance-type "t3.medium" \
--subnet-id "subnet-0localzone123" \
--key-name "my-key-pair"AWSTemplateFormatVersion: '2010-09-09'
Description: 'Local Zone Subnet + EC2'
Resources:
LocalZoneSubnet:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref MyVPC
CidrBlock: "10.0.10.0/24"
AvailabilityZone: "ap-northeast-1-tky-1a"
Tags:
- Key: Name
Value: "LocalZone-Subnet"
LocalZoneInstance:
Type: AWS::EC2::Instance
Properties:
InstanceType: "t3.medium"
SubnetId: !Ref LocalZoneSubnet
ImageId: "ami-0abcdef1234567890"# Local Zone サブネット
resource "aws_subnet" "local_zone" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.10.0/24"
availability_zone = "ap-northeast-1-tky-1a"
tags = {
Name = "LocalZone-Subnet"
}
}
# EC2 インスタンス
resource "aws_instance" "lz_app" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.medium"
subnet_id = aws_subnet.local_zone.id
tags = {
Name = "LZ-AppServer"
}
}Local Zones の代表的ユースケース
「1桁ミリ秒のレイテンシーが必要」なワークロードが最適なターゲットです。
リアルタイムゲーム
ゲームサーバーをプレイヤーの近くに配置し、操作のラグを最小化。
メディア制作・配信
映像編集やライブストリーミングのレンダリングを低遅延で処理。
ML/AI リアルタイム推論
推論リクエストを近くのGPUインスタンスで素早く処理し、応答速度を向上。
金融トレーディング
取引所の近くでミリ秒単位のレイテンシー削減が求められるワークロード。
どこに置く？ Region / Local Zone / Outposts / Wavelength 比較
AWSには「エッジ側にコンピューティングを配置する」選択肢が複数あります。ワークロードに応じて使い分けましょう。
| 観点 | Region | Local Zone | Outposts | Wavelength |
|---|---|---|---|---|
| 設置場所 | AWSデータセンター群 | 大都市近郊の小規模DC | 自社データセンター | 5Gキャリア基地局内 |
| たとえ話 | 郊外の大型レストラン | 都心の出前キッチン | 自宅に配送された食材キット | 移動販売車（フードトラック） |
| 運用管理者 | AWS | AWS | AWS（物理設置は顧客施設） | AWS + 通信キャリア |
| レイテンシー | 数十ms（距離依存） | 1桁ms | サブms（オンプレ内） | 超低遅延（5Gエッジ） |
| サービス範囲 | フルサービス | EC2, EBS, ELB等のサブセット | EC2, EBS, ECS, RDS等 | EC2, EBS等のサブセット |
| 主なユースケース | 一般的なワークロード全般 | 都市向け低遅延アプリ | データ主権・ハイブリッド | 5Gモバイルアプリ |
| 追加ハードウェア | 不要 | 不要 | 必要（ラック単位で購入） | 不要 |
ベストプラクティス vs アンチパターン
ベストプラクティス
レイテンシー要件を測定してからLocal Zoneの採用を判断する。「本当に1桁msが必要か？」を確認。
データ永続化（DB、オブジェクトストレージ）は親リージョンに配置し、コンピューティングだけをLocal Zoneに置く。
CloudFrontなどCDNと組み合わせて、静的コンテンツはエッジキャッシュ、動的処理だけLocal Zoneに任せる。
Local Zoneの障害に備え、親リージョンにフォールバック構成を用意しておく。
アンチパターン
レイテンシー要件がないのに「なんとなく」Local Zoneを使う → コストが上がるだけ。
RDSやS3をLocal Zoneに配置しようとする → これらのサービスは非対応。親リージョンで使う。
Local Zoneだけで完結する設計にする → 障害時のフォールバック先がない。
AZ（アベイラビリティーゾーン）とLocal Zoneを混同する → Local ZoneはAZの一種だが、サービス範囲が異なる。
よくある質問（FAQ）
AWS Local Zones チートシート
一言で言うと
「親リージョンのサービスを、大都市の近くに持ってくる仕組み」。低レイテンシーが必要なEC2ワークロードに最適。
キーワード
オプトイン必要 / VPCサブネット拡張 / 親リージョンのサブセット / 1桁msレイテンシー / EC2・EBS・ELB対応
試験で聞かれたら
「特定の大都市のユーザーに低レイテンシーを提供したい」→ Local Zone。「自社DCにAWSを置きたい」→ Outposts。「5Gエッジ」→ Wavelength。
注意点
利用可能サービスが限定的 / リージョンより料金が高い / データ転送料が別途発生 / フォールバック設計が必須