Azure Spring Apps ランディング ゾーン アクセラレータのネットワーク トポロジと接続性に関する考慮事項
この記事では、Spring Boot ワークロードを配置するネットワークの設計上の考慮事項と推奨事項について説明します。 ターゲットの設計は、ワークロードの要件と組織のセキュリティとコンプライアンスの要件によって異なります。
一元化されたプラットフォーム チームとアプリケーション チームが、ネットワーク設計領域の責任を共有します。 プラットフォーム チームは、ネットワーク トポロジを選択します。これは、従来のハブスポーク モデルにすることも、Virtual WAN ネットワーク トポロジ (Microsoft マネージド) にすることもできます。 アプリケーション チームは、スポーク ネットワークの設計の選択を担当します。 ワークロードには、プラットフォームによって管理される共有サービスへの依存関係があることが想定されます。 アプリケーション チームは、これらの依存関係の影響を理解し、ワークロードの全体的な目標が満たされるように要件を伝える必要があります。
プラットフォーム設計の詳細については、「ネットワーク トポロジと接続」を参照してください。
サブネット化、イングレス、エグレス制御のベスト プラクティスとして、次の設計上の考慮事項と推奨事項に従ってください。
設計上の考慮事項
分離。 中央チームは、アプリケーション チームがワークロードを実行するための仮想ネットワークを提供できます。 Spring Boot のワークロードの懸念事項が他のワークロードから分離されている場合は、Spring App Service ランタイムとアプリケーション用に独自の仮想ネットワークをプロビジョニングすることを検討してください。
サブネット化。 サブネットのサイズとアプリケーションの数を選択るときは、アプリケーションのスケーラビリティを考慮してください。
既存のサブネットを使用する場合、または独自のルート テーブルを持ち込む場合は、Azure Spring Apps によって追加されたルールが更新または削除されないようにポリシーを設定します。
もう 1 つの側面はセキュリティです。 サブネットへのトラフィックを許可または拒否するルールを検討してください。
エグレス (送信) トラフィック。 仮想ネットワークから送信されるトラフィックは、Azure Firewall またはネットワーク仮想アプライアンス (NVA) を介してルーティングする必要があります。
Azure Spring Apps によって提供される組み込みロード バランサーの制限事項を考慮してください。 要件に基づいて、たとえば NVA を介してすべてのトラフィックをルーティングするために、ユーザー定義ルーティング (UDR) を使用してエグレス パスをカスタマイズすることが必要になる場合があります。
イングレス (受信) トラフィック。 Azure Spring Apps へのトラフィックにリバース プロキシを使用することを検討してください。 要件に基づいて、Azure Application Gateway、Front Door などのネイティブ オプション、または API Management (APIM) などのリージョン サービスを選択します。 これらのオプションがワークロードのニーズを満たさない場合は、Azure 以外のサービスを検討できます。
設計の推奨事項
これらの推奨事項は、上記の一連の考慮事項に対する規範的なガイダンスとなります。
仮想ネットワークとサブネット
Azure Spring Apps には、仮想ネットワークに対する所有者アクセス許可が必要です。 このロールは、デプロイとメンテナンスのために専用の動的サービス プリンシパルを付与するために必要です。 詳しくは、「仮想ネットワークに Azure Spring Apps をデプロイする」をご覧ください。
プライベート ネットワークにデプロイされた Azure Spring Apps には、プライベート ネットワーク内でのみアクセスできる完全修飾ドメイン名 (FQDN) が用意されています。 Spring アプリの IP アドレス用の Azure プライベート DNS ゾーンを作成します。 Azure Spring Apps 内でプライベート FQDN を割り当てることによって、プライベート DNS を仮想ネットワークにリンクします。 詳細な手順については、「プライベート ネットワークのアプリケーションにアクセスする」を参照してください。
Azure Spring Apps には、2 つの専用サブネットが必要です。 1 つのサブネットにはサービス ランタイムがあり、もう 1 つのサブネットは Spring Boot アプリケーション用です。
これらの各サブネットの最小 CIDR ブロック サイズは /28 です。 ランタイム サブネットとアプリケーション サブネットには、/28 の最小アドレス空間が必要です。 ただし、デプロイできる Spring アプリの数が、そのサブネットのサイズに影響します。 サブネット範囲ごとのアプリ インスタンスの最大数については、「使用するサブネット範囲を小さくする」を参照してください。
Azure Spring Apps の前でリバース プロキシとして Azure Application Gateway を使用する場合、そのインスタンス用に別のサブネットが必要になります。 詳細については、「リバース プロキシとして Application Gateway を使う」を参照してください。
サブネットでネットワーク セキュリティ グループ (NSG) を使用して、東西トラフィックをフィルター処理し、サービス ランタイム サブネットへのトラフィックを制限します。
Azure Spring Apps のデプロイで管理されるリソース グループとサブネットは変更できません。
エグレス トラフィック
既定では、Azure Spring Apps の送信インターネット アクセスは無制限です。 南北トラフィックをフィルター処理するには、Azure Firewall などの NVA を使用します。 一元化されたハブ ネットワークの Azure Firewall を利用して、管理オーバーヘッドを削減します。
注意
サービス インスタンスをサポートするために、Azure Spring コンポーネントへのエグレス トラフィックが必要です。 具体的なエンドポイントとポートの詳細については、「Azure Spring Apps のネットワーク要件」を参照してください。
Azure Spring Apps では、エグレス トラフィック パスを完全に制御するためのユーザー定義ルート (UDR) 送信の種類が提供されます。 新しい Azure Spring Apps サービス インスタンスが作成されるときに、
OutboundTypeを定義する必要があります。 これは後で更新することはできません。OutboundTypeは仮想ネットワークでのみ構成できます。 詳細については、「ユーザー定義ルートを使用して Azure Spring Apps のエグレスをカスタマイズする」を参照してください。アプリケーションは、ソリューション内の他の Azure サービスと通信する必要があります。 アプリケーションでプライベート接続が必要な場合は、サポートされているサービスに Azure Private Link を使用します。
イグレス トラフィック
リバース プロキシを使用して、悪意のあるユーザーが Web アプリケーション ファイアウォール (WAF) をバイパスしたり、調整制限を回避したりできないようにします。 統合 WAF を使用した Azure Application Gateway をお勧めします。
Enterprise レベルを使用している場合は、Spring Cloud Gateway アプリの割り当てられたエンドポイントを Application Gateway のバックエンド プールとして使用します。 このエンドポイントは、Azure Spring Apps サービス ランタイム サブネット内のプライベート IP アドレスに解決されます。
サービス ランタイム サブネットに、Application Gateway サブネット、Azure Spring Apps サブネット、Azure Load Balancer からのトラフィックのみを許可する NSG を追加します。
注意
リバース プロキシの代替手段として、Azure Front Door や Azure 以外のサービスなどを選択できます。 構成オプションの詳細については、「リバース プロキシ経由で Azure Spring Apps を公開する」を参照してください。
Azure Spring Apps は、VNet インジェクションを介して仮想ネットワーク内に、またはネットワークの外部にデプロイできます。 詳細については、「構成の概要」を参照してください。