クラウド時代のネットワーク設計パターンを理解する

クラウドサービスの普及により、従来のオンプレミス環境とは異なるネットワーク設計の考え方が求められるようになりました。VPC（Virtual Private Cloud）を中心としたクラウドネットワーク設計では、論理的に分離された仮想ネットワーク上でサブネット、ロードバランサー、セキュリティグループなどを組み合わせて、スケーラブルかつセキュアな構成を実現します。

本記事では、クラウド時代のネットワーク設計パターンについて以下の内容を解説します。

• VPC（Virtual Private Cloud）の基本概念とアーキテクチャ
• パブリック/プライベートサブネットを活用したネットワーク分離
• ロードバランサーによる負荷分散とトラフィック制御
• CDN（Content Delivery Network）を活用したコンテンツ配信
• マルチリージョン・マルチAZ構成による高可用性設計
• AWS・Azure・GCPの共通概念と用語の対応

この記事を読むことで、クラウド環境でのネットワーク設計の基礎を理解し、適切な構成を選択できるようになります。

前提条件

本記事を理解するために、以下の知識があることを前提としています。

• IPアドレスとサブネットの基本概念を理解している（IPアドレスとサブネットマスクの基礎を理解するを参照）
• ルーティングの基礎知識がある（ルーティングの基礎とデフォルトゲートウェイを理解するを参照）
• NATの仕組みを理解している（NATとプライベートネットワークの仕組みを理解するを参照）
• ファイアウォールの基本概念を理解している（ファイアウォールの仕組みと設定の基礎を理解するを参照）

実行環境

本記事で解説する内容は、以下のクラウドサービスで共通して適用できます。

各クラウドプロバイダの無料枠やハンズオン環境があれば、実際に構築を試すことができます。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

1. VPCの構成要素と役割を説明できる
2. パブリック/プライベートサブネットの使い分けを理解できる
3. ロードバランサーの種類と適切な選択ができる
4. CDNの仕組みと導入メリットを理解できる
5. 高可用性を実現するためのマルチAZ構成を設計できる

VPC（Virtual Private Cloud）の基本概念

VPC（Virtual Private Cloud）は、クラウド上に構築される論理的に分離された仮想ネットワークです。オンプレミス環境での物理ネットワークと同様に、IPアドレス範囲の定義、サブネットの作成、ルーティングテーブルの設定、セキュリティポリシーの適用が可能です。

VPCの主要構成要素

クラウドネットワーク設計において、VPCは以下の構成要素で成り立っています。

graph TB
    subgraph VPC["VPC (10.0.0.0/16)"]
        subgraph AZ1["アベイラビリティゾーン A"]
            PublicSubnet1["パブリックサブネット<br/>10.0.1.0/24"]
            PrivateSubnet1["プライベートサブネット<br/>10.0.10.0/24"]
        end
        subgraph AZ2["アベイラビリティゾーン B"]
            PublicSubnet2["パブリックサブネット<br/>10.0.2.0/24"]
            PrivateSubnet2["プライベートサブネット<br/>10.0.20.0/24"]
        end
        IGW["インターネット<br/>ゲートウェイ"]
        NAT["NAT<br/>ゲートウェイ"]
    end
    
    Internet["インターネット"]
    
    Internet <--> IGW
    IGW <--> PublicSubnet1
    IGW <--> PublicSubnet2
    PublicSubnet1 --> NAT
    NAT --> PrivateSubnet1
    NAT --> PrivateSubnet2
    
    style VPC fill:#e3f2fd
    style PublicSubnet1 fill:#c8e6c9
    style PublicSubnet2 fill:#c8e6c9
    style PrivateSubnet1 fill:#fff3e0
    style PrivateSubnet2 fill:#fff3e0

VPCを構成する主要な要素は以下のとおりです。

VPCのCIDR設計

VPCを作成する際、最初にIPアドレス範囲（CIDRブロック）を決定する必要があります。この設計は後から変更が難しいため、将来の拡張性を考慮して慎重に決定します。

RFC 1918 プライベートIPアドレス範囲:
- 10.0.0.0/8       (10.0.0.0 - 10.255.255.255)    約1677万アドレス
- 172.16.0.0/12    (172.16.0.0 - 172.31.255.255)  約104万アドレス
- 192.168.0.0/16   (192.168.0.0 - 192.168.255.255) 約6.5万アドレス

VPCのCIDR設計における推奨事項は以下のとおりです。

1. 十分な拡張性の確保: /16（約65,000アドレス）程度のCIDRを確保
2. VPC間の重複回避: 将来のVPCピアリングやVPN接続を考慮し、重複しないアドレス範囲を使用
3. オンプレミスとの重複回避: ハイブリッドクラウド構成時に既存ネットワークと重複しない範囲を選択

良い設計例:
- 本番VPC:    10.1.0.0/16
- 開発VPC:    10.2.0.0/16
- ステージングVPC: 10.3.0.0/16
- オンプレミス: 192.168.0.0/16

悪い設計例:
- 全環境で 10.0.0.0/16 を使用 → VPC間の接続が不可能に

パブリック/プライベートサブネット設計

クラウドネットワーク設計の基本は、パブリックサブネットとプライベートサブネットを適切に使い分けることです。この分離により、セキュリティを確保しつつ、必要な通信を実現します。

パブリックサブネットとプライベートサブネットの違い

両者の違いは、インターネットへの直接アクセス可否にあります。

3層アーキテクチャのサブネット設計

Webアプリケーションでよく採用される3層アーキテクチャをクラウドで実現する場合、以下のようなサブネット設計が推奨されます。

graph TB
    Internet["インターネット"]
    
    subgraph VPC["VPC (10.0.0.0/16)"]
        subgraph PublicTier["パブリック層"]
            ALB["Application<br/>Load Balancer"]
            Bastion["踏み台サーバー"]
        end
        
        subgraph AppTier["アプリケーション層<br/>（プライベート）"]
            App1["App Server 1"]
            App2["App Server 2"]
        end
        
        subgraph DataTier["データ層<br/>（プライベート）"]
            DB1[("Primary DB")]
            DB2[("Standby DB")]
        end
        
        NAT["NAT Gateway"]
    end
    
    Internet --> ALB
    Internet -.->|SSH| Bastion
    ALB --> App1
    ALB --> App2
    App1 --> DB1
    App2 --> DB1
    DB1 -.->|レプリケーション| DB2
    App1 -.-> NAT
    App2 -.-> NAT
    NAT -.-> Internet
    Bastion --> App1
    Bastion --> App2
    
    style PublicTier fill:#c8e6c9
    style AppTier fill:#fff3e0
    style DataTier fill:#ffcdd2

サブネットのCIDR設計例を以下に示します。

VPC CIDR: 10.0.0.0/16

アベイラビリティゾーン A:
  パブリックサブネット:    10.0.1.0/24   (ロードバランサー、踏み台)
  アプリケーションサブネット: 10.0.10.0/24  (Webサーバー)
  データベースサブネット:   10.0.100.0/24 (RDS、ElastiCache)

アベイラビリティゾーン B:
  パブリックサブネット:    10.0.2.0/24
  アプリケーションサブネット: 10.0.20.0/24
  データベースサブネット:   10.0.200.0/24

NATゲートウェイの役割と配置

プライベートサブネット内のリソースがインターネットにアクセスする必要がある場合（OSアップデート、外部APIとの通信など）、NATゲートウェイを使用します。

NATゲートウェイの特徴は以下のとおりです。

• パブリックサブネットに配置し、Elastic IP（固定のパブリックIP）を付与
• プライベートサブネットからの送信トラフィックのみを許可（外部からの受信は不可）
• 高可用性のため、各アベイラビリティゾーンにNATゲートウェイを配置

ルートテーブル設定例（プライベートサブネット用）:

| 宛先           | ターゲット          |
|---------------|-------------------|
| 10.0.0.0/16   | local             |
| 0.0.0.0/0     | nat-gateway-xxxx  |

セキュリティグループとネットワークACL

クラウドネットワーク設計において、トラフィック制御は多層防御の考え方で実装します。セキュリティグループとネットワークACLを組み合わせることで、きめ細かなアクセス制御を実現します。

セキュリティグループ

セキュリティグループは、インスタンス（仮想マシン）レベルで動作するステートフルファイアウォールです。

graph LR
    subgraph SG["セキュリティグループの特徴"]
        A["ステートフル"]
        B["インスタンスレベル"]
        C["許可ルールのみ"]
        D["他のSGを参照可能"]
    end
    
    style SG fill:#e8f5e9

セキュリティグループの主な特徴は以下のとおりです。

Webサーバー用セキュリティグループの設定例を以下に示します。

インバウンドルール:
| タイプ  | プロトコル | ポート | ソース                  |
|--------|----------|-------|------------------------|
| HTTP   | TCP      | 80    | ALBのセキュリティグループ |
| HTTPS  | TCP      | 443   | ALBのセキュリティグループ |
| SSH    | TCP      | 22    | 踏み台のセキュリティグループ |

アウトバウンドルール:
| タイプ     | プロトコル | ポート | 宛先       |
|-----------|----------|-------|-----------|
| すべて    | すべて    | すべて | 0.0.0.0/0 |

ネットワークACL

ネットワークACL（Access Control List）は、サブネットレベルで動作するステートレスファイアウォールです。

ネットワークACL設定例:

インバウンドルール:
| ルール番号 | タイプ  | プロトコル | ポート      | ソース        | 許可/拒否 |
|-----------|--------|----------|------------|--------------|----------|
| 100       | HTTP   | TCP      | 80         | 0.0.0.0/0    | 許可     |
| 110       | HTTPS  | TCP      | 443        | 0.0.0.0/0    | 許可     |
| 120       | カスタム | TCP      | 1024-65535 | 0.0.0.0/0    | 許可     |
| *         | すべて  | すべて    | すべて      | 0.0.0.0/0    | 拒否     |

アウトバウンドルール:
| ルール番号 | タイプ   | プロトコル | ポート      | 宛先         | 許可/拒否 |
|-----------|---------|----------|------------|-------------|----------|
| 100       | HTTP    | TCP      | 80         | 0.0.0.0/0   | 許可     |
| 110       | HTTPS   | TCP      | 443        | 0.0.0.0/0   | 許可     |
| 120       | カスタム | TCP      | 1024-65535 | 0.0.0.0/0   | 許可     |
| *         | すべて   | すべて    | すべて      | 0.0.0.0/0   | 拒否     |

セキュリティグループとネットワークACLの使い分け

両者を組み合わせた多層防御が推奨されます。

ロードバランサーによる負荷分散

クラウドネットワーク設計において、ロードバランサーはトラフィックを複数のサーバーに分散し、スケーラビリティと可用性を向上させる重要なコンポーネントです。

ロードバランサーの種類

クラウドプロバイダが提供するロードバランサーは、OSI参照モデルの動作レイヤーに応じて分類されます。

graph TB
    subgraph L7["L7ロードバランサー（アプリケーション層）"]
        ALB["Application Load Balancer<br/>AWS: ALB / Azure: App Gateway / GCP: HTTP(S) LB"]
        L7Feature["特徴: URL、ヘッダー、Cookie等で振り分け"]
    end
    
    subgraph L4["L4ロードバランサー（トランスポート層）"]
        NLB["Network Load Balancer<br/>AWS: NLB / Azure: Load Balancer / GCP: TCP/UDP LB"]
        L4Feature["特徴: IPアドレス、ポート番号で振り分け"]
    end
    
    style L7 fill:#e3f2fd
    style L4 fill:#fff3e0

L7ロードバランサーの構成例

L7ロードバランサー（Application Load Balancer）を使用したWebアプリケーションの構成を以下に示します。

graph TB
    Client["クライアント"]
    
    subgraph VPC
        ALB["Application Load Balancer"]
        
        subgraph TG1["ターゲットグループ: API"]
            API1["API Server 1"]
            API2["API Server 2"]
        end
        
        subgraph TG2["ターゲットグループ: Web"]
            Web1["Web Server 1"]
            Web2["Web Server 2"]
        end
    end
    
    Client -->|"example.com/api/*"| ALB
    Client -->|"example.com/*"| ALB
    ALB -->|"/api/* → API"| TG1
    ALB -->|"/* → Web"| TG2
    
    style ALB fill:#4fc3f7

L7ロードバランサーで実現できる主な機能は以下のとおりです。

ヘルスチェックの設計

ロードバランサーのヘルスチェックは、バックエンドインスタンスの正常性を監視し、障害発生時に自動的にトラフィックを迂回させます。

ヘルスチェック設定例:

| 項目                    | 設定値              |
|------------------------|-------------------|
| プロトコル              | HTTP               |
| ポート                  | 80                 |
| パス                    | /health            |
| 正常判定しきい値         | 2回連続成功         |
| 異常判定しきい値         | 3回連続失敗         |
| チェック間隔            | 30秒               |
| タイムアウト            | 5秒                |

ヘルスチェックエンドポイントの実装例（Node.js）を以下に示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// /health エンドポイントの実装例
app.get('/health', async (req, res) => {
  try {
    // データベース接続の確認
    await db.query('SELECT 1');
    
    // 外部依存サービスの確認（必要に応じて）
    // await checkExternalService();
    
    res.status(200).json({ status: 'healthy' });
  } catch (error) {
    res.status(503).json({ status: 'unhealthy', error: error.message });
  }
});

CDN（Content Delivery Network）の活用

CDN（Content Delivery Network）は、世界中に分散配置されたエッジサーバーを利用して、コンテンツを高速に配信するネットワークサービスです。クラウドネットワーク設計において、静的コンテンツの配信やAPIレスポンスのキャッシュに活用されます。

CDNの仕組み

graph TB
    subgraph Users["ユーザー"]
        User1["東京のユーザー"]
        User2["ロンドンのユーザー"]
        User3["ニューヨークのユーザー"]
    end
    
    subgraph CDN["CDNエッジロケーション"]
        Edge1["東京エッジ"]
        Edge2["ロンドンエッジ"]
        Edge3["ニューヨークエッジ"]
    end
    
    Origin["オリジンサーバー<br/>（東京リージョン）"]
    
    User1 -->|近い| Edge1
    User2 -->|近い| Edge2
    User3 -->|近い| Edge3
    
    Edge1 -->|キャッシュミス時| Origin
    Edge2 -->|キャッシュミス時| Origin
    Edge3 -->|キャッシュミス時| Origin
    
    style CDN fill:#e8f5e9
    style Origin fill:#fff3e0

CDNの主なメリットは以下のとおりです。

CDNのキャッシュ戦略

CDNでは、Cache-Controlヘッダーを使用してキャッシュの動作を制御します。

Cache-Control ヘッダーの主なディレクティブ:

| ディレクティブ      | 説明                                    |
|-------------------|----------------------------------------|
| max-age=秒数       | キャッシュの有効期間を秒単位で指定          |
| s-maxage=秒数      | CDN（共有キャッシュ）専用の有効期間        |
| no-cache          | キャッシュ前に必ずオリジンに再検証          |
| no-store          | キャッシュを一切禁止                       |
| private           | CDNでのキャッシュを禁止（ブラウザのみ）      |
| public            | CDNでのキャッシュを許可                    |

コンテンツタイプ別のキャッシュ設定例を以下に示します。

静的アセット（CSS/JS/画像）:
  Cache-Control: public, max-age=31536000
  → 1年間キャッシュ（ファイル名にハッシュを含める前提）

HTMLページ:
  Cache-Control: public, max-age=0, must-revalidate
  → 常に再検証（ETagで差分チェック）

APIレスポンス（ユーザー固有データ）:
  Cache-Control: private, no-store
  → キャッシュ禁止

APIレスポンス（共有データ）:
  Cache-Control: public, s-maxage=60
  → CDNで60秒キャッシュ

各クラウドプロバイダのCDNサービス

マルチAZ・マルチリージョン構成

クラウドネットワーク設計において、高可用性と災害対策を実現するためには、複数のアベイラビリティゾーン（AZ）やリージョンにリソースを分散配置することが重要です。

アベイラビリティゾーン（AZ）とリージョン

クラウドプロバイダのインフラストラクチャは、階層的に構成されています。

graph TB
    subgraph Region["リージョン（例: 東京）"]
        subgraph AZ1["AZ-a<br/>（データセンター群A）"]
            DC1["サーバー群"]
        end
        subgraph AZ2["AZ-b<br/>（データセンター群B）"]
            DC2["サーバー群"]
        end
        subgraph AZ3["AZ-c<br/>（データセンター群C）"]
            DC3["サーバー群"]
        end
    end
    
    AZ1 <-->|低レイテンシ接続| AZ2
    AZ2 <-->|低レイテンシ接続| AZ3
    AZ1 <-->|低レイテンシ接続| AZ3
    
    style Region fill:#e3f2fd

マルチAZ構成のパターン

単一リージョン内でマルチAZ構成を実現するパターンを以下に示します。

graph TB
    Internet["インターネット"]
    
    subgraph Region["東京リージョン"]
        ALB["Application Load Balancer<br/>（マルチAZ）"]
        
        subgraph AZ1["AZ-a"]
            Web1["Web Server"]
            DB1[("Primary DB")]
        end
        
        subgraph AZ2["AZ-b"]
            Web2["Web Server"]
            DB2[("Standby DB")]
        end
    end
    
    Internet --> ALB
    ALB --> Web1
    ALB --> Web2
    Web1 --> DB1
    Web2 --> DB1
    DB1 -.->|同期レプリケーション| DB2
    
    style ALB fill:#4fc3f7

マルチAZ構成の設計ポイントは以下のとおりです。

マルチリージョン構成（DR対策）

災害対策（Disaster Recovery）を考慮したマルチリージョン構成を以下に示します。

graph TB
    DNS["Route 53 / Azure Traffic Manager<br/>/ Cloud DNS"]
    
    subgraph Primary["プライマリリージョン（東京）"]
        ALB1["Load Balancer"]
        App1["App Servers"]
        DB1[("Primary DB")]
    end
    
    subgraph Secondary["セカンダリリージョン（大阪）"]
        ALB2["Load Balancer"]
        App2["App Servers"]
        DB2[("Replica DB")]
    end
    
    DNS -->|"通常時: 100%"| ALB1
    DNS -.->|"フェイルオーバー時"| ALB2
    ALB1 --> App1
    ALB2 --> App2
    App1 --> DB1
    App2 --> DB2
    DB1 -.->|非同期レプリケーション| DB2
    
    style Primary fill:#c8e6c9
    style Secondary fill:#fff3e0

DR戦略は、目標復旧時間（RTO）と目標復旧時点（RPO）に応じて選択します。

VPC間接続とハイブリッドクラウド

複数のVPCやオンプレミス環境を接続する場合、適切な接続方式を選択する必要があります。

VPCピアリング

VPCピアリングは、2つのVPC間でプライベートIPアドレスを使用して通信する機能です。

graph LR
    subgraph VPC1["VPC A (10.1.0.0/16)"]
        EC2A["EC2 Instance<br/>10.1.1.10"]
    end
    
    subgraph VPC2["VPC B (10.2.0.0/16)"]
        EC2B["EC2 Instance<br/>10.2.1.20"]
    end
    
    VPC1 <-->|"VPCピアリング接続"| VPC2
    
    style VPC1 fill:#e3f2fd
    style VPC2 fill:#fff3e0

VPCピアリングの特徴は以下のとおりです。

Transit Gateway（ハブ＆スポーク構成）

多数のVPCやオンプレミス環境を接続する場合、Transit Gateway（ハブ型アーキテクチャ）が推奨されます。

graph TB
    subgraph Cloud["クラウド環境"]
        TGW["Transit Gateway<br/>（ハブ）"]
        
        VPC1["VPC 1<br/>本番環境"]
        VPC2["VPC 2<br/>開発環境"]
        VPC3["VPC 3<br/>共有サービス"]
    end
    
    OnPrem["オンプレミス<br/>データセンター"]
    
    TGW <--> VPC1
    TGW <--> VPC2
    TGW <--> VPC3
    TGW <-->|VPN / Direct Connect| OnPrem
    
    style TGW fill:#4fc3f7

オンプレミスとの接続方式

オンプレミス環境とクラウドを接続する方式は、要件に応じて選択します。

AWS・Azure・GCPの用語対応表

3大クラウドプロバイダで使用される用語は異なりますが、概念としては共通しています。以下に主要な用語の対応表を示します。

ベストプラクティスとチェックリスト

クラウドネットワーク設計を行う際のベストプラクティスをチェックリスト形式でまとめます。

VPC設計のチェックリスト

[ ] 将来の拡張を考慮した十分なCIDRブロックを確保している
[ ] 他のVPCやオンプレミスとCIDRが重複していない
[ ] パブリック/プライベートサブネットを適切に分離している
[ ] 各アベイラビリティゾーンにサブネットを作成している
[ ] サブネットのCIDRは将来の拡張を考慮して設計している

セキュリティ設計のチェックリスト

[ ] 最小権限の原則に基づいてセキュリティグループを設計している
[ ] プライベートサブネット内のリソースにパブリックIPを付与していない
[ ] 踏み台サーバーまたはSystems Manager Session Managerを使用している
[ ] 不要なポートを開放していない
[ ] セキュリティグループでIPアドレスではなくセキュリティグループを参照している

可用性設計のチェックリスト

[ ] 重要なワークロードをマルチAZ構成にしている
[ ] ロードバランサーのヘルスチェックを適切に設定している
[ ] データベースのマルチAZ配置を有効化している
[ ] 災害対策の要件（RTO/RPO）を定義している
[ ] 自動スケーリングを設定している

コスト最適化のチェックリスト

[ ] 不要なNATゲートウェイを削除している
[ ] リージョン間データ転送を最小化している
[ ] CDNを活用してオリジンへのトラフィックを削減している
[ ] 不要なElastic IPを解放している
[ ] VPCエンドポイントを使用してAWSサービスへの通信を最適化している

まとめ

本記事では、クラウド時代のネットワーク設計パターンについて解説しました。

学習した主なポイントは以下のとおりです。

1. VPCの基本概念: 論理的に分離された仮想ネットワークで、サブネット、ルートテーブル、セキュリティグループなどを組み合わせて構成する
2. サブネット設計: パブリック/プライベートサブネットを適切に分離し、NATゲートウェイでプライベートリソースのインターネットアクセスを実現する
3. セキュリティ: セキュリティグループとネットワークACLによる多層防御を実装する
4. ロードバランサー: L7/L4ロードバランサーを用途に応じて使い分け、ヘルスチェックで自動復旧を実現する
5. CDN: エッジサーバーからのコンテンツ配信により、レイテンシ低減とオリジン負荷軽減を実現する
6. 高可用性: マルチAZ・マルチリージョン構成により、障害に強いアーキテクチャを実現する
7. ハイブリッドクラウド: VPCピアリング、Transit Gateway、専用線接続などを用途に応じて選択する

クラウドネットワーク設計の知識は、現代のインフラエンジニアやアプリケーション開発者にとって必須のスキルです。本記事の内容を理解したうえで、実際のクラウド環境でハンズオンを行い、理解を深めることをお勧めします。

シリーズの振り返り

本記事は「ネットワーク基礎」シリーズの最終回です。シリーズ全体を通じて、以下の内容を学習しました。

1. OSI参照モデルとTCP/IPモデルを図解で理解する - ネットワークの階層構造
2. IPアドレスとサブネットマスクの基礎を理解する - アドレッシングの基礎
3. ルーティングの基礎とデフォルトゲートウェイを理解する - パケットの経路制御
4. DNSの仕組みを基礎から理解する - 名前解決の仕組み
5. DNSキャッシュとTTLの仕組みを理解する - DNSの高度な動作
6. TCPとUDPの違いを理解する - トランスポート層プロトコル
7. ポート番号とソケット通信を理解する - アプリケーション識別
8. ファイアウォールの仕組みと設定の基礎を理解する - ネットワークセキュリティ
9. NATとプライベートネットワークの仕組みを理解する - アドレス変換
10. ネットワークトラブルシューティングに役立つコマンド集 - 実践的なスキル
11. クラウド時代のネットワーク設計パターンを理解する（本記事）- クラウドアーキテクチャ

これらの知識を土台として、実際のシステム設計や運用に活かしていただければ幸いです。

参考リンク

• AWS - Amazon VPC とは?
• AWS - VPC のサブネット
• AWS - Elastic Load Balancing の仕組み
• Azure - 仮想ネットワークとは
• Azure - Azure Load Balancer の概要
• Google Cloud - Virtual Private Cloud（VPC）の概要
• Google Cloud - Cloud Load Balancing の概要
• AWS Well-Architected Framework - 信頼性の柱