フラット ネットワークは、最も単純なAzure ネットワーク トポロジです。1 つの仮想ネットワークと、1 つのワークロードをホストする複数のサブネットを持つ 1 つの仮想ネットワークです。 この記事では、このパターンを使用するタイミングとその実装方法について説明します。
この記事の内容
この記事では、最も単純なAzure ネットワーク トポロジについて説明します。1 つのワークロードをホストする複数のサブネットを持つ単一の仮想ネットワークです。 このパターンは、1 つのチームによって管理される単一のアプリケーションがあり、中央のファイアウォールや VPN ゲートウェイなどの共有サービスが必要ない場合に使用します。
この記事が必要なユーザー
次の場合は、この記事をお読みください。
- Azureで最初のワークロードをデプロイします。
- 1 つのチームがすべてのリソースを所有し、運用します。
- 複数のワークロードにわたって共有ネットワーク サービス (ファイアウォール、Bastion、ゲートウェイ) は必要ありません。
- サブネット レベルの分離とセキュリティを提供する最も単純なネットワークが必要です。
リフトアンドシフトフォーカス: コンポーネントごとにサブネットを持つ単一のフラット VNet は、多くの場合、1 つのリージョン内の 1 つのワークロードを再ホストするための適切な最初の手順です。
フォーカスを最新化する: 初期の PaaS パイロットまたは 1 つの最新化されたワークロードにはフラット ネットワークを使用し、共有サービスまたは 2 つ目のリージョンを追加するときにハブアンドスポークに対して適切に卒業できるようにサブネットを設計します。
クラウド間のフォーカス:クラウド間の移行中に単一のAzureの足掛かりとしてフラット VNet を使用します。まずワークロードを配置し、そのアドレス空間とセグメント化を計画して、設計が成熟するにつれてハブまたはVirtual WANに参加できるようにします。
Azureサービスと機能
フラット ネットワーク トポロジでは、次のコア Azure サービスが使用されます。
| サービス | このトポロジでの役割 |
|---|---|
| Azure 仮想ネットワーク | ワークロード用のプライベートで分離されたアドレス空間を提供します。 仮想ネットワークのスコープは、1 つのAzure リージョンです。 |
| サブネット + ネットワーク セキュリティ グループ (NSG) | サブネットはアプリケーション層を分離します。 NSG は、各サブネット境界で受信トラフィックと送信トラフィックをフィルター処理します。 NSG はステートフルです。許可された接続のリターン トラフィックは自動的に許可されます。 |
| Azure プライベート DNS ゾーン | 仮想ネットワーク内のリソースの内部名前解決を提供します。 VM が DNS レコードを自動的に取得できるように、自動登録が有効になっているゾーンをリンクします。 |
| ゲートウェイ サブネット(省略可能) | オンプレミス ネットワークへの 1 つの接続が必要な場合は、VPN または ExpressRoute ゲートウェイをホストします。 |
どう選ぶ？ フラット型を維持するか、ハブ＆スポーク型に移行するか
次の決定表を使用して、フラット トポロジが環境に適しているかどうか、または代わりにハブ アンド スポーク トポロジを採用する必要があるかどうかを判断します。
| 状態 | レコメンデーション |
|---|---|
| 単一ワークロード、単一チーム、共有サービスなし | 平らに保つ: この記事は適用されます |
| 2 つ目の独立したワークロードには、独自のネットワーク分離が必要です | ハブ アンド スポーク トポロジに移行する |
| ワークロード間で共有ファイアウォール、VPN ゲートウェイ、またはAzure Bastionが必要です | ハブ アンド スポーク トポロジに移行する |
| セキュリティ ポリシーは、複数のワークロードにわたって一元的に管理する必要があります | ハブ アンド スポーク型トポロジに移行する |
Tip
6 ~ 12 か月以内に 2 つ目のワークロードを追加する予定がある場合は、1 日目からハブアンドスポークから開始することを検討してください。 追加の仮想ネットワークとピアリング接続を 1 つだけ追加するため、オーバーヘッドは最小限です。 この方法では、後で中断を伴う移行を回避できます。
設計上の考慮事項
リフトアンドシフトフラットネットワーク設計フォーカス
- アプリケーション コンポーネント (Web、アプリ、データ) ごとにサブネットを持つ 1 つの VNet を使用して、最小限の再設計で一般的なオンプレミスの 3 層レイアウトをミラー化します。
- サブネット間に NSG を適用して既存のセグメント化を再作成し、アドレス空間をオンプレミスの範囲に合わせて維持して重複を回避します。
- 単一のチームがワークロードを担当しており、共有ファイアウォール、ゲートウェイ、または Bastion サービスを必要としない場合は、フラットなままにできます。
- 2 つ目のワークロードを追加する前にハブアンドスポークへの移行を計画し、共有サービスが後付けされるのではなくハブに移動するようにします。
フラット ネットワーク設計の焦点を最新化する
- 初期の PaaS パイロットまたは単一の最新化されたワークロードにはフラット ネットワークを使用します。アプリ層をサブネットに配置し、専用サブネット内のプライベート エンドポイントを介して PaaS Azureに到達します。
- Application Gateway やプライベート エンドポイントなど、追加するプラットフォーム サービス用の専用サブネットを事前に予約して、アドレス指定なしでネットワークを拡大します。
- 階層ごとに NSG とアプリケーション セキュリティ グループを適用し、後でワークロードがハブ アンド スポーク設計でスポークになった場合にセグメント化が既に行われるようにします。
- アドレス空間が他のリージョンや VNet と重複しないようにしてください。そうすることで、後でアドレスを振り直すことなく、ピアリングしたりハブ構成に移行したりできます。
クラウド間フラット ネットワーク設計に重点を置く
- クラウド間の移行中に単一のAzureの足掛かりとしてフラット VNet を使用します。最初にワークロードを設定してから、設計が成熟するにつれてハブから接続をアタッチします。
- フラット VNet のアドレス空間を計画して、後で翻訳なしで IPsec または相互接続ルーティングに参加できるように、AWS VPC や Google Cloud ネットワークとの重複を回避します。
- セキュリティで保護されたVirtual WAN ハブの背後にあるスポークになったときにワークロードのセキュリティ体制が引き継がれることができるように、NSG を使用して階層のセグメント化を維持します。
- 他のクラウドと一致するようにサブネットの名前付けとタグ付けを標準化して、移行中と移行後にワークロードを簡単に関連付けられるようにします。
前提条件
このトポロジを実装する前に、次の操作を行います。
- 仮想ネットワークと NSG を作成するアクセス許可を持つAzure サブスクリプション。
- 計画された IP アドレス空間。 /16 アドレス空間には 65,536 個のアドレスが用意されています。これは、1 つのワークロードの共通の開始点です。 Azureは、内部使用のためにサブネットごとに 5 つのアドレスを予約します。 詳細なガイダンスについては、 IP アドレス指定の計画に関する記事を参照してください。
- アプリケーション層 (Web、アプリケーション、データなど) を理解し、サブネットにマップできるようにします。 サブネットの設計ガイダンスについては、 仮想ネットワークとサブネットの設計に関するページを参照してください。
ネットワークレイアウト
フラット ネットワーク トポロジは、次の構造に従います。
- 1 つの アドレス空間を持つ 1 つの仮想ネットワーク (たとえば、10.0.0.0/16)。
-
複数のサブネット: アプリケーション層またはコンポーネントごとに 1 つ:
- Web 層サブネット (10.0.1.0/24 など)。
- アプリケーション層サブネット (10.0.2.0/24 など)。
- データ層サブネット (10.0.3.0/24 など)。
- ゲートウェイ サブネット (10.0.255.0/27 など、省略可能)。
- 各サブネットに関連付けられた NSG。各層に必要なトラフィックのみを許可するルールを持つ
- 自動登録が有効になっている仮想ネットワークにリンクされている 1 つのプライベート DNS ゾーン。
Note
IP アドレスの範囲を慎重に計画します。 後でハブ アンド スポーク トポロジに移行する場合、スポーク仮想ネットワークには、ハブと重複しない CIDR 範囲が必要です。 適切に構造化されたアドレススキームを選択すると、移行中の競合が防止されるようになりました。
セキュリティに関する考慮事項
フラット ネットワークに次のセキュリティ プラクティスを適用します。
- 各サブネットの NSG。 すべての受信拒否ベースラインから開始し、層間の正当なトラフィックに対する特定の許可規則を追加します。 たとえば、Web 層からアプリケーション層への HTTPS を許可し、アプリケーション層からデータ層への SQL を許可します。
- VM 上にパブリック IP が直接存在しない。 ロード バランサーまたは Application Gateway を介してサービスを公開します。 管理アクセスにはAzure Bastionを使用します。
- 内部解決のためのプライベート DNS。 プライベート DNS ゾーンでは、パブリック DNS クエリによって内部ホスト名が公開されないようにします。
- ゲートウェイ サブネットの分離。 VPN または ExpressRoute ゲートウェイを追加する場合は、専用サブネット (
GatewaySubnetという名前) に配置します。 ゲートウェイ サブネット上の NSG はサポートされていません。 NSG をこのサブネットに関連付けることで、仮想ネットワーク ゲートウェイが期待どおりに機能しなくなる可能性があります。
Important
接続を許可する NSG ルールを削除すると、既存のアクティブな接続は中断されずに続行されます。 削除されたルールに一致する新しい接続のみがブロックされます。
関連資料
次の記事では、関連トピックに関するより詳細なガイダンスを提供します。
- 仮想ネットワークとサブネットの設計: ワークロード層のサブネットのサイズ設定と配置
- IP アドレス指定の計画: アドレス空間の計画と CIDR の選択
- ネットワーク セキュリティ グループの設計: NSG ルールの設計とアプリケーション セキュリティ グループ
- ハブアンドスポーク トポロジ: ネットワークの拡大時に採用する次のトポロジ
- DDoS 保護: ワークロードがパブリック エンドポイントを公開している場合
詳細情報
このトポロジで使用されるAzure サービスの詳細については、次を参照してください。
次のステップ
Tip
あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。
リフトアンドシフト体験の次の手順:
ハブアンドスポーク トポロジを設計する: リフト アンド シフト移行のほとんどがフラット ネットワークを迅速に上回ります。 最初から一元化された共有サービスを計画します。
次に、最新化の取り組みを行います。
ハブアンドスポーク トポロジを設計する: 複数のサービス、セキュリティ制御、チームを備えた最新化されたワークロードには、1 日目からハブアンドスポークが必要です。
マルチクラウドへの移行における次のステップ:
クラウド間接続アーキテクチャを計画する: クラウド間の資産には、フラット ネットワークではなくトランジット アーキテクチャが必要です。 マルチクラウド接続モデルを設計します。