トップ > クラウド > AWSネットワーク設計におけるCIDR設計を改めて考える

AWSネットワーク設計におけるCIDR設計を改めて考える

クラウド ネットワーク

はじめに

NTT西日本の近藤です。

AWSでシステムを構築する際、意外と悩まされるのがネットワークのCIDR設計ではないでしょうか。
私自身も、後からアカウントやVPCが増えたタイミングで
「最初のCIDR設計、もう少し考えておけばよかった…」と感じた経験があります。

CIDRは一度決めると簡単には見直せない要素であり、
その判断が後工程に影響しやすい、設計上の“前提条件”の一つです。

AWSはネットワーク設計の自由度が高く、VPCやサブネットを柔軟に構成できる一方で、
CIDRの割り当てを起点として構成全体が決まっていくため、
構築初期の設計が数年後の拡張性や運用性に影響するケースも少なくありません。

本記事では、AWS上でシステムを構築・運用する際に重要となる
ネットワークCIDR設計の考え方と、将来的な拡張を見据えたアドレス管理のポイント について整理します。

特に、以下のような環境ではCIDR設計の重要性が高まります。

  • システムやアカウントの増加が見込まれる
  • 複数リージョンやDR構成を前提としている
  • オンプレミス環境や外部ネットワークとの接続を想定している

本記事では、AWS公式ドキュメントで示されている一般的な設計指針を踏まえつつ、
AWS環境全体からサブネットまでを段階的に整理するCIDR設計アプローチ を一例として紹介します。

なお、本記事で紹介する構成やCIDRは あくまで一例 です。
システム要件や将来計画に応じて、適切に設計を見直す前提でお読みください。

本記事は 2026年3月時点の情報 に基づいています。

対象読者

本記事が想定する対象読者は以下の通りです。

  • AWSでネットワーク設計・レビューを担当するエンジニア
  • VPCやサブネットのCIDR設計を一通り経験した方
  • 将来のシステム拡張やアカウント増加を見据えた設計を行いたい方
  • AWS Solutions Architect – Associate 相当の基礎知識をお持ちの方

目次

1. AWSネットワーク設計においてCIDRが重要となる理由

AWSのネットワーク設計において、CIDR設計は全体構成の土台となる要素です。

VPCやサブネットは後から追加できる場合もありますが、
一度割り当てたCIDRそのものを柔軟に変更することは難しい という制約があります。

そのため、CIDR設計では次のような点を意識した検討が重要になります。

  • 将来的なリソース増加やシステム追加
  • リージョン追加や災害対策構成への対応
  • ネットワーク統合や再構成のしやすさ

本記事では、CIDR設計を以下の粒度で段階的に整理していきます。

設計レイヤー 主な目的
AWS環境全体 外部接続・全体設計の整理
リージョン 障害ドメイン単位での分離
VPC 環境・用途ごとの分離
Availability Zone(AZ)・サブネット 可用性と役割設計

2. AWS環境全体で利用するCIDR設計

最初に検討するのは、AWS環境全体で利用するIPアドレス帯です。

オンプレミス環境や他クラウドと接続する可能性がある場合、
最も重要となるのが CIDRの重複を避けること です。
重複が発生すると、Site-to-Site VPNやDirect Connect、VPCピアリングなどで制約が生じます。

AWS全体CIDR設計の一例

用途 CIDR例
オンプレミス環境 10.0.0.0/8
AWS環境全体 172.16.0.0/12

AWSでは、ロードバランサーやNAT Gateway、Amazon EKSなど、
間接的にIPアドレスを消費するサービスが多く存在します。
そのため、必要最小限ではなく 将来を見据えて余裕を持ったCIDRを確保する 設計が選択されることがあります。

3. リージョン単位でのCIDR割り当て

AWSリージョンは、物理的・論理的に独立した障害ドメインとして設計されています。
CIDRもリージョン単位で整理しておくことで、設計・運用の見通しが良くなります。

リージョン分割のメリット

  • 障害影響範囲を論理的に把握しやすい
  • DR（Disaster Recovery）構成やリージョン間接続の検討が容易
  • IPアドレス管理が属人化しにくい

割り当て例

リージョン CIDR例
東京リージョン 172.16.0.0/14
大阪リージョン 172.20.0.0/14

このようにリージョン単位でCIDRを整理することで、
将来的なリージョン追加時にも全体設計を崩しにくくなります。

4. VPC単位でのCIDR設計

リージョン内では、用途や役割ごとに複数のVPCを作成するケースが一般的です。

  • 本番（PRD）環境用VPC
  • 災害対策（DR）環境用VPC
  • 検証・Sandbox用VPC

VPCのプライマリCIDRは後から変更できないため、
サブネット追加やサービス拡張を見据えたサイズ設計が重要になります。

なお、AWSではVPCにセカンダリCIDRブロックを追加することも可能です。
しかし、後付けでCIDRを追加すると、アドレス設計の一貫性が崩れたり、
運用やセキュリティポリシーが複雑化するケースもあります。

このため、実務では「後から追加できる」ことを前提にするのではなく、
初期設計の段階で将来を見据えたCIDR設計を行うことが重要 と考えられます。

観点 目的
環境分離 障害・影響範囲の限定
セキュリティ ポリシー適用を容易に
運用性 構成把握・管理のしやすさ

5. AZ・サブネット設計の考え方

AWSでは高可用性を確保するため、
複数AZを前提とした設計 が基本となります。

サブネット設計では、以下のような方針が取られることが多くなります。

  • 同一用途のサブネットを各AZに配置
  • AZごとに同じCIDRサイズを割り当てる
  • 将来的なスケールアウトを考慮する

AZごとにCIDRサイズがばらついていると、
障害対応や構成把握が難しくなるため、
多少のアドレス余裕を許容し、構成を揃える ことが実務上有効な場合もあります。

本構成例では、リージョン内ネットワークの集約点として
Transit Gateway（TGW）を利用する想定とし、
TGW専用のサブネットを各AZに配置しています。

6. AWSにおける予約IPアドレスの仕様

AWSのIPv4サブネットでは、
CIDR内のすべてのIPアドレスを利用できるわけではありません。

各サブネットごとに、以下のIPアドレスがAWSによって予約されています。

利用できないIPアドレス（例：10.0.0.0/24）

IPアドレス 用途
10.0.0.0 ネットワークアドレス
10.0.0.1 VPCルーター
10.0.0.2 AWS提供DNS
10.0.0.3 AWS予約（将来用途）
10.0.0.255 ブロードキャスト

そのため、/24 サブネットで利用可能なIPは 251個 となります。

CIDR 総IP数 利用可能IP数
/28 16 11
/24 256 251
/22 1024 1019

特に小さなCIDRでは、この予約分が相対的に大きな制約となるため、
ENIを多用する構成やコンテナ基盤では設計時の考慮が必要です。

7. （発展）IPAMを前提としたCIDR管理

環境規模が大きくなるにつれ、
CIDR管理そのものが運用課題となるケース があります。

AWSでは、この課題に対応する仕組みとして
Amazon VPC IP Address Manager（IPAM） が提供されています。

IPAMを利用することで、以下のような管理が可能になります。

  • CIDR割り当て状況の一元管理
  • リージョン・VPC単位での可視化
  • 意図しないCIDR重複の防止

IPAMでは、
全体プール → リージョンプール → VPC割り当て
といった階層構造でCIDRを管理できるため、
本記事で紹介した設計レイヤーとの親和性も高いと言えます。

なお、IPAMはあくまで設計・管理を支援する仕組みであり、
すべての環境で必須となるものではありません。
組織規模や運用体制に応じて採用可否を検討することが重要です。

8. 本記事の位置付けと注意事項

本記事で紹介したCIDR設計は、
AWSネットワーク設計における一つの参考例 です。

  • 利用するAWSサービス
  • システム規模やトラフィック特性
  • 運用体制や将来計画

によって、最適な設計は異なります。

本記事の内容をそのまま適用するのではなく、
設計検討時の参考情報としてご活用ください。
なお、本記事の記載内容に基づく構成や動作について、
筆者および所属組織が保証するものではありません。

9. まとめ

AWSのCIDR設計は、後から見直しが難しい重要な設計要素です。

AWS環境全体からリージョン、VPC、サブネットへと
段階的に整理して設計することで、
将来の拡張や運用フェーズを見据えた構成を検討しやすくなります。

本記事が、AWSネットワーク設計を検討されている方の一助となれば幸いです。

執筆者

近藤 隆太 （NTT西日本 エンタープライズビジネス営業部 N＆S部門 N＆S推進担当（福岡））
九州・沖縄エリアのクラウド・セキュリティ案件推進に携わっています。

  • AWS Community Builder (AI Engineering)
  • 2025 Japan AWS Top Engineers (Services)
  • 2024 Japan AWS Jr. Champions

参考資料・出典

商標

  • 「AWS」「Amazon VPC」「Amazon VPC IP Address Manager」は、Amazon Web Services, Inc.またはその関連会社の商標または登録商標です。

免責事項

本記事は情報提供を目的としたものであり、
記載内容の正確性、完全性、将来的な動作を保証するものではありません。
本記事の内容を利用したことにより生じたいかなる損害についても、
筆者および所属組織は責任を負いません。 ``

© NTT WEST, Inc.