Azure ランディング ゾーンでの Azure Virtual Machines ベースライン アーキテクチャ

この記事のアーキテクチャでは、仮想マシン (VM) のベースライン アーキテクチャを拡張して、Azure ランディング ゾーンにデプロイするときの変更と想定事項に対応します。

この記事の例では、組織は、プラットフォーム チームが一元的に管理するフェデレーション リソースを VM ベースのワークロードで使用することが前提です。 これらのリソースには、クロスプレミス接続、ID アクセス管理、ポリシー用のネットワーク リソースが含まれます。 この例では、組織が Azure ランディング ゾーンを採用して、複数のワークロード間で一貫したガバナンスとコスト効率を適用することを前提としています。

ワークロード所有者は、共有リソースの管理を中央チームに任せられるため、ワークロード開発作業に集中できます。 この記事では、ワークロード チームの視点について説明します。 プラットフォーム チーム用のおすすめが指定されます。

記事のレイアウト

Architecture	設計上の決定	Azure Well-Architected Framework のアプローチ
▪ アーキテクチャの図 ▪ ワークロード リソース ▪ フェデレーション リソース	▪ サブスクリプションの設定 ▪ ネットワーク要件 ▪ ベースラインからのネットワーク設計の変更 ▪ 監視 ▪ パッチ コンプライアンス ▪ 組織のガバナンス ▪ 変更管理	▪ 信頼性 ▪ セキュリティ ▪ コストの最適化

Architecture

このアーキテクチャの Visio ファイルをダウンロードします。

コンポーネント

すべての Azure ランディング ゾーン アーキテクチャでは、プラットフォーム チームとワークロード チームの間で所有権が分かれています。 アプリケーション アーキテクトと DevOps チームは、直接的な影響や制御の配下にあるものとそうでないものを理解するために、この責任分担について深く理解する必要があります。

ワークロード チーム所有のリソース

次のリソースは、ベースライン アーキテクチャとほとんど変わりません。

• Azure Virtual Machines はアプリケーション プラットフォームです。 コンピューティング リソースは、可用性ゾーン間で分散されます。

• Azure Load Balancer は、フロントエンド VM からバックエンド VM へのトラフィックをプライベートに負荷分散するために使用されます。 Load Balancer はトラフィックをゾーン全体に分散します。

• Azure Application Gateway は、ユーザー リクエストをフロントエンド VM にルーティングするためのリバース プロキシとして使用されます。 選択した SKU は、悪意のある可能性のあるトラフィックからフロントエンド VM を保護するために、Azure Web Application Firewall をホストするためにも使用されます。

• Azure Key Vault は、アプリケーション シークレットと認定資格証を保管するために使用します。

• Azure Monitor、Log Analytics、およびアプリケーション インサイトは、監視データの収集、格納、視覚化に使用します。

• Azure Policy は、ワークロードに固有のポリシーを適用するために使用します。

ワークロード チームは以下のリソースを維持し、責任を果たします。

• セグメントと制御トラフック フローを維持するためにサブネットに配置されるスポーク仮想ネットワーク サブネットとネットワーク セキュリティ グループ (NSG)。

• Platform as a Service (PaaS) ソリューションへの接続をセキュリティで保護するためにプライベート エンドポイントおよびこれらエンドポイントに必要なプライベート DNS ゾーン。

• Azure Managed Disks はバックエンド サーバーにログ ファイルを格納し、VM が再起動してもデータは保持されます。 フロントエンド サーバーには、ステートレス アプリケーションのデプロイに使用できるディスクが接続されています。

プラットフォーム チーム所有のリソース

プラットフォーム チームは、これらの一元化されたリソースを所有し、維持します。 このアーキテクチャでは、これらのリソースが事前にプロビジョニングされていることを前提とし、依存関係を考慮します。

• ハブ ネットワーク内の Azure Firewall は、エグレス トラフィックの検査と制限に使用されます。 このコンポーネントは、インターネットへの送信トラフィックに制限を提供しないベースライン アーキテクチャの標準ロード バランサーを置き換えます。

• ハブ ネットワーク 内の Azure Bastion は、ワークロード VM への安全な運用アクセスを提供します。 ベースライン アーキテクチャでは、ワークロード チームがこのコンポーネントを所有しています。

• スポーク仮想ネットワークは、ワークロードがデプロイされる場所です。

• ユーザー定義ルート (UDR) は、ハブ ネットワークへのトンネリングを強制するために使用されます。

• Azure Policy ベースのガバナンス制約 と DeployIfNotExists (DINE) ポリシーは、ワークロード サブスクリプションの一部です。

サブスクリプションの設定

ランディング ゾーンのコンテキストでは、ワークロード チームはプラットフォーム チームに固有の要件を通知する必要があります。

ワークロード チームは、プラットフォーム チームが必要なリソースを割り当てることができるように、ワークロードに必要なネットワーク領域に関する詳細情報を含める必要があります。 チームは要件を決定し、プラットフォーム チームは、仮想ネットワーク内で割り当てる IP アドレスと、サブスクリプションが割り当てられている管理グループを決定します。

プラットフォーム チームは、ワークロードがインターネットに公開されている場合など、ワークロードのビジネスの重要度と技術的要件に基づいて適切な管理グループを割り当てます。 組織はこれらの管理グループの構成を決定し、プラットフォーム チームがそれらを実装します。

たとえば、ベースライン アーキテクチャのアプリケーション シナリオの管理グループは、次と見なされます。

• 社内の基幹業務アプリケーションや商用の既製 (COTS) ソリューションなどのプライベート アプリケーション。多くの場合、Azure ランディング ゾーンの Corp 管理グループ配下にあります。

• インターネットに接続するアプリケーションとしてのパブリック アプリケーション。多くの場合、Corp または Online 管理グループ配下にあります。

プラットフォーム チームは、ワークロードのデプロイ用にサブスクリプションまたはサブスクリプションのグループを設定する役割も担います。

次のセクションでは、サブスクリプションの初期設定に関して説明します。 ただし、プラットフォーム チームは通常、一元化されたサービスに変更を加えて、見落とされた要件や変更された要件に対処します。 プラットフォームの変更は、すべてのワークロード チームに広範な影響を与えます。

そのため、プラットフォーム チームは、すべての VM ワークロードが変更に対して準備されていることを確認し、VM ベースのソリューションのライフ サイクルとテスト サイクルを認識する必要があります。 詳細については、「時間の経過に伴う変更管理」を参照してください。

ワークロードの要件とフルフィルメント

ワークロード チームとプラットフォーム チームは、管理グループの割り当てとネットワークのセットアップという 2 つの主な責任を共有します。 このアーキテクチャでは、プラットフォーム チームとやりとりをする必要がある次のネットワーク要件を検討してください。 これらのポイントを例として使用して、同様のアーキテクチャを実装するときに 2 つのチーム間の詳解とネゴシエーションを理解します。

• スポーク仮想ネットワーク数: このアーキテクチャでは、専用のスポークが 1 つだけ必要です。 デプロイされたリソースは複数のネットワークにまたがる必要がなく、単一の仮想ネットワーク内に併置されます。

• スポーク ネットワークのサイズ: 運用要件とワークロードの予想される増加を考慮します。 たとえば、青/緑またはカナリアの更新プログラムを実装する予定の場合は、side-by-side デプロイで必要な領域を最大サイズで考慮する必要があります。

  今後の変更では、より多くの IP 領域が必要になる可能性があり、現在の割り当てとずれる可能性があります。 これらのスペースを統合すると、複雑さが増す可能性があります。 割り当てられたスペースが今後の拡張に対応できるよう、事前に十分なネットワーク リソースを積極的に要求します。

• デプロイ リージョン: ワークロードをデプロイするリージョンを指定することが重要です。 プラットフォーム チームがこの情報を使用すると、スポーク仮想ネットワークとハブ仮想ネットワークを同じリージョンでプロビジョニングできます。 異なるリージョン間のネットワークでは、リージョン境界を越えるトラフィックが原因で待機時間の問題が発生する可能性があり、帯域幅の追加コストが発生する可能性もあります。

• ワークロードの特性と設計の選択: 設計の選択、コンポーネント、特性をプラットフォーム チームに伝えます。 たとえば、ワークロードがインターネットへの多数のコンカレント接続 (チャット) を生成することが予想される場合、プラットフォーム チームは、枯渇を防ぐために十分なポートがあることを確認する必要があります。 トラフィックをサポートするために一元化されたファイアウォールに IP アドレスを追加したり、代替パスを介してトラフィックをルーティングするネットワーク アドレス変換 (NAT) ゲートウェイを設定したりできます。

  逆に、ワークロードで最小限のネットワーク トラフィック (バックグラウンド ノイズ) が生成される場合、プラットフォーム チームは組織全体でリソースを効率的に使用する必要があります。

  プラットフォーム チームは、依存関係を明確に理解する必要があります。 たとえば、ワークロードが別のチームが所有するデータベースへのアクセスが必要な場合や、ワークロードにクロスプレミス トラフィックがある場合があります。 ワークロードには Azure の外部に依存関係がありますか? このような情報は、プラットフォーム チームにとって重要です。

• ファイアウォール構成: プラットフォーム チームは、スポーク ネットワークを離れ、ハブ ネットワークにトンネリングされるトラフィックを認識している必要があります。 ハブ内のファイアウォールでは、そのトラフィックをブロックできません。

  たとえば、ワークロードが Windows 更新プログラムにアクセスしてパッチをあてる必要がある場合、ファイアウォールはこれらの更新プログラムをブロックしないようにする必要があります。 同様に、特定のエンドポイントにアクセスするモニター エージェントがある場合は、ワークロードの監視データが中断される可能性があるため、ファイアウォールでそのトラフィックをブロックしないでください。 アプリケーションでは、サード パーティのエンドポイントへのアクセスが必要になる場合があります。 いずれの場合も、一元化されたファイアウォールを使用して、予想されるトラフィックと警告されていないトラフィックを区別します。

• オペレーター アクセス: オペレーターが Azure Bastion 経由で VM にアクセスするために使用する Microsoft Entra ID セキュリティ グループがある場合は、プラットフォーム チームに通知します。 通常、Azure Bastion は中央リソースです。 セキュリティ グループと VM がセキュリティで保護されたプロトコルをサポートしていることを確認することが重要です。

  さらに、VM を含む IP 範囲についてプラットフォーム チームに通知します。 この情報は、ハブ ネットワークで Azure Bastion 周辺の NSG を構成するために必要です。

• パブリック IP: 予想されるパブリック IP アドレスを含め、イングレス トラフィック プロファイルについてプラットフォーム チームに通知します。 このアーキテクチャでは、インターネットソースのトラフィックのみが Application Gateway のパブリック IP を対象としています。 プラットフォーム チームは、これらの IP が Azure DDoS 保護プランの配下にある場合、またはそれがワークロード チームの責任である場合は、ワークロード チームに通知する必要があります。

  このアーキテクチャでは、Azure Bastion 経由で運用アクセスするための別のパブリック IP があります。 プラットフォーム チームはこのパブリック IP を所有し、プラットフォーム チームも管理する DDoS Protection などのサービスに登録されます。

VM 設計の選択肢

VM SKU とディスクの選択は、「ベースライン アーキテクチャ」と同じです。

組織は、特定の VM イメージの使用を義務付けるコンプライアンス要件をワークロード チームに課す場合があります。 このような要件を考えると、プラットフォーム チームは、組織全体で使用するために作成される、ゴールデン イメージと呼ばれる標準化されたイメージ一式を管理する場合があります。

プラットフォーム チームは、Azure Compute Gallery やプライベート リポジトリなどのマネージド オファリングを使用して、承認された OS イメージまたはワークロード アーティファクトを格納する場合があります。 VM の OS イメージを選択する場合は、イメージ ソース、更新頻度、および使用状況の想定値に関して、プラットフォーム チームに問い合わせます。 また、イメージがワークロードで満たす必要なビジネス要件を満たすことができることを確認します。

ネットワーク

ベースライン アーキテクチャでは、ワークロードは 1 つの仮想ネットワークでプロビジョニングされます。 ワークロード チームが仮想ネットワークを管理します。

このアーキテクチャでは、プラットフォーム チームがネットワーク トポロジを決定します。 このアーキテクチャでは、ハブスポーク トポロジが想定されています。

このアーキテクチャの Visio ファイルをダウンロードします。

• ハブ仮想ネットワーク: リージョン ハブには、同じリージョン内のワークロード リソースと通信する一元化されたサービスが含まれています。 詳しくは、「プラットフォーム チーム所有のリソース」を参照してください。 接続サブスクリプションにハブを配置することをお勧めします。

• スポーク仮想ネットワーク: このアーキテクチャでは、ベースライン アーキテクチャの単一の仮想ネットワークがスポーク ネットワークです。 一元化されたサービスを含むハブ ネットワークにピアリングされます。 プラットフォーム チームは、このスポーク ネットワークを所有し、管理します。 このネットワークには、ワークロード リソースが含まれています。 ワークロード チームは、サブネットを含め、このネットワーク内のリソースを所有しています。

ワークロードの要件をプラットフォーム チームに伝え、定期的に確認します。

仮想ネットワーク サブネット

スポーク仮想ネットワークでは、ワークロード チームがサブネットを作成して割り当てます。 サブネットとの間でトラフィックを制限するコントロールを配置すると、セグメント化を実現するのに役立ちます。 このアーキテクチャでは、ベースライン アーキテクチャと同じサブネット トポロジが 使用されます。このアーキテクチャには、Application Gateway、フロントエンド VM、ロード バランサー、バックエンド VM、プライベート エンドポイント用の専用サブネットがあります。

Azure ランディング ゾーンにワークロードをデプロイする場合でも、ネットワーク制御を実装する必要があります。 組織は、データ流出から保護し、中央セキュリティ オペレーション センター (SOC) と IT ネットワーク チームの可視性を確保するために制限を課す場合があります。

このアプローチにより、プラットフォーム チームは、組織全体のワークロードごとに冗長なセキュリティ制御をデプロイするのではなく、一元化されたサービスを使用して組織全体の支出を最適化できます。 このアーキテクチャでは、Azure Firewall が中央サービスの例です。 各ワークロード チームが独自のファイアウォール インスタンスを管理することは、コスト効率が高く、実用的ではありません。 ファイアウォール管理の一元化されたアプローチをお勧めします。

イグレス トラフィック

イングレス トラフィック フローは、ベースライン アーキテクチャと同じです。

ワークロード所有者は、ワークロードへのパブリック インターネット イングレスに関連するすべてのリソースを担当します。 たとえば、このアーキテクチャでは、Application Gateway とそのパブリック IP はハブ ネットワークではなくスポーク ネットワークに配置されます。 一部の組織では、一元化された非武装地帯 (DMZ) の実装を使用して、イングレス トラフィックを含むリソースを接続サブスクリプションに配置する場合があります。 この記事では、その特定のトポロジとの統合は範囲外です。

エグレス トラフィック

ベースライン アーキテクチャでは、ワークロード Virtual Machine Scale Sets は、Azure Load Balancer を介してパブリック インターネットにアクセスしますが、そのトラフィックは制限されません。

このアーキテクチャでは、その設計が異なります。 スポーク仮想ネットワークを離れるすべてのトラフィックは、エグレス ファイアウォール経由でピアリングされたハブ ネットワーク経由でルーティングされます。 ルートは、ローカル仮想ネットワーク (0.0.0.0/0) に見つからない IP のすべてのトラフィックをハブの Azure Firewall に転送する、スポーク ネットワーク内のすべての可能なサブネットに接続されます。

このアーキテクチャの Visio ファイルをダウンロードします。

Key Vault アクセスのプライベート エンドポイントへのワークロード通信はメインベースライン アーキテクチャと同じです。 このパスは、簡潔にするために前の図から省略されています。

ワークロード チームは、インフラストラクチャとワークロードの運用に必要なすべての送信トラフィック フローを特定し、文書化し、通信する必要があります。 プラットフォーム チームは必要なトラフィックを許可し、すべての通信されないエグレス トラフィックが拒否される可能性があります。

エグレス トラフィックの制御は、予想されるトラフィックが許可されることを確認するだけではありません。 また、予想されるトラフィックのみを許可することも確認します。 通信されないエグレス トラフィックは既定で拒否される可能性がありますが、トラフィックが適切にルーティングされるようにするのは、ワークロードのセキュリティ上の利益です。

プラットフォーム チームに固有のエグレス トラフィック要件を伝えます。 たとえば、ワークロードで外部ネットワーク エンドポイントへの多数のコンカレント接続が確立されている場合は、プラットフォーム チームに通知します。 その後、プラットフォーム チームは、適切な Azure NAT Gateway 実装をプロビジョニングするか、軽減策のためにリージョン ファイアウォールにパブリック IP をさらに追加できます。

組織には、ワークロード所有のパブリック IP をエグレスに使用するアーキテクチャ パターンの使用を推奨しない要件がある場合があります。 その場合は、Azure Policy を使用して、VM ネットワーク インターフェイス カード (NIC) とその他のパブリック IP (既知のイングレス ポイント以外) のパブリック IP を拒否できます。

プライベート DNS ゾーン

プライベート エンドポイントを使用するアーキテクチャでは、DNS プロバイダーと連携するためにプライベート DNS ゾーンが必要です。 ワークロード チームは、プラットフォーム チームが提供するサブスクリプションのプライベート DNS ゾーンの要件と管理を明確に理解している必要があります。 プライベート DNS ゾーンは、通常、DINE ポリシーを使用して大規模に管理されます。これにより、Azure Firewall は信頼性の高い DNS プロキシとして機能し、完全修飾ドメイン名 (FQDN) ネットワーク規則をサポートできます。

このアーキテクチャでは、プラットフォーム チームは、プライベート リンク エンドポイントの信頼性の高いプライベート DNS 解決を保証します。 プラットフォーム チームと共同作業して、期待を理解します。

接続テスト

VM ベースのアーキテクチャの場合、ネットワークの見通し、ルーティング、DNS の問題を特定するのに役立つテスト ツールがいくつかあります。 netstat、nslookup、tcping などの従来のトラブルシューティング ツールを使用できます。 さらに、ネットワーク アダプターの動的ホスト構成プロトコル (DHCP) と DNS の設定を分析できます。 NIC がある場合は、Azure Network Watcher を使用して接続チェックを実行できる、より多くのトラブルシューティング機能があります。

オペレーター アクセス

ベースライン アーキテクチャと同様に、このアーキテクチャでは Azure Bastion を介したオペレーター アクセスがサポートされています。

ただし、ベースライン アーキテクチャでは、ワークロードの一部として Azure Bastion がデプロイされます。 Azure ランディング ゾーンを採用する一般的な組織では、各リージョンの中央リソースとして Azure Bastion をデプロイします。 プラットフォーム チームは Azure Bastion を所有、維持し、組織内のすべてのワークロードで共有します。 このアーキテクチャのユース ケースを示すために、Azure Bastion は接続サブスクリプションのハブ ネットワークにあります。

オペレーター アイデンティティ

このアーキテクチャでは、ベースライン アーキテクチャと同じ認証拡張機能が使用されます。

長期的なアクセスではなく、常に、最小限の権限と詳細なアクセスの原則から始めます。 ランディング ゾーン コンテキストでは、プラットフォーム チームが管理する Just-In-Time (JIT) サポートを利用します。

パッチのコンプライアンスと OS のアップグレード

ベースライン アーキテクチャでは、パッチとアップグレードに対する自律的なアプローチについて説明します。 ワークロードがランディング ゾーンと統合されると、そのアプローチが変わる可能性があります。 プラットフォーム チームは、すべてのワークロードが組織の要件に準拠するようにパッチの適用操作を指示する場合があります。

パッチ適用プロセスに、アーキテクチャに追加するすべてのコンポーネントが含まれていることを確認します。 たとえば、アプリケーションのデプロイ、スケーリング、管理を自動化するためにビルド エージェント VM を追加する場合、それらの VM はプラットフォームの要件に準拠している必要があります。

監視

Azureランディング ゾーン プラットフォームでは、管理サブスクリプションの一部として共有監視リソースが提供されます。 ただし、ワークロードの所有権の責任を容易にするために、独自の監視リソースをプロビジョニングすることをお勧めします。 このアプローチは、ベースライン アーキテクチャと 一致します。

ワークロード チームは、次のような監視リソースをプロビジョニングします。

• ワークロード チームに対するアップロード パフォーマンス監視 (APM) としての Application Insights。

• ワークロード所有の Azure リソースとアプリケーション コードから収集されるすべてのログとメトリックの統合シンクとしての Log Analytics ワークスペース。

このアーキテクチャの Visio ファイルをダウンロードします。

ベースラインと同様に、すべてのリソースは、ワークロード チームがリソースの Infrastructure as Code (IaC) デプロイの一部としてプロビジョニングする Log Analytics ワークスペースに Azure 診断ログを送信するように構成されます。 また、中央の Log Analytics ワークスペースにログを送信する必要がある場合もあります。 Azure ランディング ゾーンでは、そのワークスペースは管理サブスクリプションにあります。

プラットフォーム チームには、集中管理サブスクリプションにログを送信するように診断を構成するために使用できる DINE ポリシーもあります。 実装で追加のログ フローが制限されないようにすることが重要です。

複数のシンクからのデータを関連付ける

ワークロードのログとメトリック、およびそのインフラストラクチャ コンポーネントは、ワークロードの Log Analytics ワークスペースに格納されます。 ただし、Azure Firewall、Microsoft Entra ID、Azure Bastion などの一元化されたサービスが生成するログとメトリックは、中央の Log Analytics ワークスペースに格納されます。 複数のシンクからのデータの関連付けは、複雑なタスクになる可能性があります。

相関データは、インシデント対応時によく使用されます。 複数のシンクからのデータの関連付けに問題がある場合は、このアーキテクチャの Triage Runbook がそれに対処し、問題がワークロード リソースを超える場合は、組織の連絡先が含まれていることを確認してください。 ワークロード管理者は、エンタープライズ ネットワーク、セキュリティ、またはその他のプラットフォーム サービスからのログ・エントリーを関連付けるために、プラットフォーム管理者の支援を必要とする場合があります。

Azure Policy

プラットフォーム チームは、ワークロードのデプロイに影響を与えるポリシーを適用する可能性があります。 多くの場合、DINE ポリシーを適用して、アプリケーション ランディング ゾーン サブスクリプションへの自動デプロイを処理します。 DINE ポリシーを使用すると、ワークロード リソースを変更したり、デプロイにリソースを追加したりできます。これにより、ワークロード テンプレートを通じて宣言的にデプロイされるリソースと、処理要求が実際に使用するリソースとの間に不一致が生じる可能性があります。 一般的な解決策は、命令型アプローチを使用してこれらの変更を修正することです。これは理想的ではありません。

この不一致を回避するには、プラットフォームによって開始された変更を前もって IaC に組み込んでテストします。 プラットフォーム チームがアプリケーションの要件と競合する Azure ポリシーを使用している場合は、プラットフォーム チームと解決策をネゴシエートできます。

時間と共に変更を管理する

プラットフォームが提供するサービスと操作は、このアーキテクチャでは外部の依存関係と見なされます。 プラットフォーム チームは引き続き変更の適用、ユーザーのオンボード、コスト管理の適用を行います。 組織にサービスを提供するプラットフォーム チームは、個々のワークロードに優先順位を付けられない可能性があります。 これらの依存関係に対する変更は、ゴールデン イメージの変更、ファイアウォールの変更、自動修正、ルールの変更のいずれであっても、複数のワークロードに影響を与える可能性があります。

そのため、ワークロードチームとプラットフォームチームは、すべての外部依存関係を管理するために効率的かつタイムリーにやりとりをする必要があります。 ワークロードに悪影響を及ぼさないように、変更をテストすることが重要です。

ワークロードに影響するプラットフォームの変更

このアーキテクチャでは、プラットフォーム チームが次のリソースを管理します。 これらのリソースに対する変更は、ワークロードの信頼性、セキュリティ、運用、およびパフォーマンスのターゲットに影響する可能性があります。 これらの変更は、プラットフォーム チームがそれらを有効にしてワークロードに与える影響を判断する前に評価することが重要です。

• Azure ポリシー: Azure ポリシーの変更は、ワークロード リソースとその依存関係に影響する可能性があります。 たとえば、ポリシーの直接的変更やランディング ゾーンの新しい管理グループ階層への移動が挙げられます。 これらの変更は、新しいデプロイが行われるまで気付かない可能性があるため、十分にテストすることが重要です。

• ファイアウォール規則: ファイアウォール規則の変更は、ワークロードの仮想ネットワークまたはすべてのトラフィックに広く適用される規則に影響を与える可能性があります。 これらの変更により、トラフィックがブロックされ、OS パッチの適用が失敗したなどのサイレント プロセス エラーが発生する可能性があります。 これらの潜在的な問題は、エグレス Azure Firewall と Azure Virtual Network Manager が適用する NSG 規則の両方に適用されます。

• 共有リソース: SKU または共有リソースの機能に対する変更は、ワークロードに影響を与える可能性があります。

• ハブ ネットワークでのルーティング: ハブでのルーティングの推移的本質の変化は、ワークロードが他の仮想ネットワークへのルーティングに依存している場合、ワークロードの機能に影響する可能性があります。

• Azure Bastion ホスト: Azure Bastion ホストの可用性または構成の変更は、ワークロード操作に影響を与える可能性があります。 ジャンプ ボックス アクセス パターンの変更に、効果的なルーチン、アドホック、緊急アクセスがあることを確認します。

• 所有権の変更: ワークロードの管理とサポートの要求に影響を与える可能性があるため、所有権と連絡先の変更をワークロード チームに伝えます。

プラットフォームに影響するワークロードの変更

次の例は、プラットフォーム チームに伝える必要がある、このアーキテクチャでのワークロードの変更です。 プラットフォーム チームが、新しいワークロード チームの変更に対してプラットフォーム サービスの信頼性、セキュリティ、運用、およびパフォーマンスのターゲットを検証してから有効にすることが重要です。

• ネットワーク エグレス: ネットワーク エグレスの大幅な増加を監視して、ネットワーク デバイスでワークロードがノイズの多いネイバーにならないようにします。 この問題は、他のワークロードのパフォーマンスまたは信頼性のターゲットに影響する可能性があります。

• パブリック アクセス: ワークロード コンポーネントへのパブリック アクセスを変更するには、さらにテストが必要になる場合があります。 プラットフォーム チームは、ワークロードを別の管理グループに再配置する場合があります。

• ビジネス重要度評価: ワークロードのサービスレベル契約 (SLA) に変更がある場合は、プラットフォームチームとワークロード チームの間で新しいコラボレーション アプローチが必要になる場合があります。

• 所有権の変更: 所有権と連絡先の変更をプラットフォーム チームに伝えます。

ワークロードビジネス要件の変更

ワークロードのサービスレベル目標 (SLO) を維持するには、プラットフォーム チームがワークロード アーキテクチャの変更に関与する必要がある場合があります。 これらの変更には、プラットフォーム チームからの変更管理や、既存のガバナンスが変更された要件をサポートしていることを検証することが必要な場合があります。

たとえば、プラットフォーム チームがファイアウォール、Virtual Network Manager、またはその他のコンポーネントにそのフローを追加して必要なトラフィックをサポートできるように、以前に禁止されていたエグレス フローに変更を伝達します。 逆に、以前に許可されたエグレス フローが不要になった場合、プラットフォーム チームは、ワークロードのセキュリティを維持するために、そのフローをブロックする必要があります。 また、他の仮想ネットワークまたはクロスプレミス エンドポイントへのルーティングの変更、またはアーキテクチャ コンポーネントへの変更も伝達します。 各リソースは、ポリシーとエグレス ファイアウォール制御の対象となる可能性があります。

信頼性

このアーキテクチャは、ベースライン アーキテクチャでの信頼性の保証に合わせて調整されます。

信頼性のターゲット

エグレス ネットワーク制御などのコンポーネントにより、可能な最大複合 SLO は、ベースライン複合 SLO よりも低くなります。 ランディング ゾーン環境で一般的なこれらのコンポーネントは、このアーキテクチャに固有ではありません。 ワークロード チームがこれらの Azure サービスを直接制御する場合、SLO も同様に削減されます。

可能な限り低い最大 SLO にもかかわらず、重要な信頼性の側面は、機能チーム間でのワークロード コンポーネントの分割です。 この方法により、ワークロード チームは、このワークロードやその他のワークロードで使用される重要なインフラストラクチャの運用に重点を置いた専門チームの援助を受けられます。

詳細については、「信頼性目標の定義に関する推奨事項」を参照してください。

重要な依存関係

ワークロードがプラットフォームとアプリケーション ランディング ゾーンで実行するすべての機能を依存関係として表示します。 インシデント対応計画では、ワークロード チームがこれらの依存関係の連絡先と連絡方法の情報を認識している必要があります。 また、これらの依存関係をワークロードの障害モード分析 (FMA) に含めます。

このアーキテクチャでは、次の依存関係を考慮します。

• エグレス ファイアウォール: 複数のワークロードによって共有される一元化されたエグレス ファイアウォールは、ワークロードとは無関係に変更されます。

• ネットワーク ポートの不足: ネットワーク デバイスを共有するすべてのワークロードからの使用量が急増すると、エグレス ファイアウォールでネットワークの飽和またはポート不足が発生する可能性があります。

• DINE ポリシー: Azure DNS プライベート DNS ゾーン (またはその他のプラットフォームが提供する依存関係) の DINE ポリシーは ベスト エフォートであり、実行に SLA はありません。 DNS 構成の遅延により、アプリケーションがトラフィックを処理する準備が遅れる可能性があります。

• 管理グループ ポリシー: 環境間で一貫したポリシーが信頼性の鍵となります。 実稼働前環境が運用環境と類似していることを確認して、正確なテストを提供し、デプロイまたはスケールをブロックできる環境固有の偏差を防ぎます。 詳細については、「Azure ランディング ゾーンでのアプリケーション開発環境の管理」を参照してください。

これらの考慮事項の多くは Azure ランディング ゾーンがない場合がありますが、ワークロードチームとプラットフォーム チームは、ニーズが満たされるように、これらの問題に共同で対処する必要があります。

詳細については、「エラー モード分析を実行するための推奨事項」を参照してください。

セキュリティ

このアーキテクチャのセキュリティに関する考慮事項は、ベースライン アーキテクチャから引き継がされます。 次のセクションの推奨事項は、適切に設計されたフレームワークのセキュリティ設計レビュー チェックリストに基づいています。

ネットワーク管理

ワークロードがセキュリティで保護されるようにネットワーク制御を適切に構成します。

イグレス トラフィック

サブネット上の NSG またはリージョン ハブの非推移的本質または制御を使用して、組織内の他のワークロード スポークからワークロードを分離できます。 アプリケーションとそのインフラストラクチャの受信ネットワーク要件のみを許可する包括的な NSG を構築します。 セキュリティのために、ハブ ネットワークの非推移的本質だけに依存しないことをお勧めします。

プラットフォーム チームは、Azure ポリシーを実装して、Application Gateway で Web Application Firewall が [拒否モード] に設定されていることを確認し、サブスクリプションで使用できるパブリック IP の数やその他のチェックを制限する可能性があります。 これらのポリシーに加えて、ワークロード チームは、イングレス セキュリティ体制を強化するワークロード中心のポリシーをデプロイする責任を担う必要があります。

次の表に、このアーキテクチャのイングレス コントロールの例を示します。

ソース	目的	ワークロード制御	プラットフォーム制御
インターネット	ユーザー トラフィック フロー	パブリック トラフィックがフロントエンド VM に入るプライベート トラフィックへの移行を許可する前に、NSG、Web Application Firewall、およびルート指定規則を介してすべての要求をファネルします	なし
Azure Bastion	VM へのオペレーター アクセス	プラットフォームの指定された Azure Bastion サブネットからソース化されていない限り、リモート アクセス ポートへのすべてのトラフィックをブロックする VM サブネット上の NSG	なし
その他のスポーク	なし	NSG ルールを使用してブロックする	Azure Virtual WAN のセキュリティで保護されたハブの場合の非トランザクション ルート指定または Azure Firewall 規則

エグレス トラフィック

ソリューションの必要な送信接続要件を表す NSG ルールを適用し、それ以外をすべて拒否します。 ハブ ネットワークコントロールだけに依存しないでください。 ワークロード オペレーターは、望ましくないエグレス トラフィックを、実行可能なソースの近くで停止する必要があります。

仮想ネットワーク内でサブネットを所有している間、プラットフォーム チームは、キャプチャした要件をサブスクリプション サービス プロセスの一部として具体的に表すファイアウォール規則を作成した可能性があることに注意してください。 アーキテクチャの有効期間中のサブネットとリソース配置の変更が、元の要求と互換性があることを確認します。 または、ネットワーク チームと協力して、最小アクセスエグレス制御の継続性を確保することもできます。

次の表に、このアーキテクチャのエグレスの例を示します。

エンドポイント	目的	ワークロード (NSG) 制御	プラットフォーム (ハブ) コントロール
ntp.ubuntu.com	Linux VM のネットワーク タイム プロトコル (NTP)	フロントエンド VM サブネット上のインターネットへの UDP/123 (エグレス ファイアウォールによって、この広範な開放が狭くなります)	ワークロード制御と同じファイアウォール ネットワーク規則の許容量
Windows Update エンドポイント	Microsoft サーバーからの Windows Update 機能	TCP/443 と TCP/80 をバックエンド VM サブネット上のインターネットに接続する (エグレス ファイアウォールによって、この広範な開放が狭くなります)	WindowsUpdate FQDN タグ付きファイアウォール許容量規則
エージェント エンドポイントの監視	VM 上の監視拡張機能に必要なトラフィック	両方の VM サブネット上のインターネットへの TCP/443 (エグレス ファイアウォールによって、この広範な開放が狭くなります)	TCP/443 上のすべての特定の FQDN に必要なファイアウォール アプリケーション規則の許容量
nginx.org	ベンダーから直接 Nginx (アプリケーション コンポーネントの例) をインストールするには	フロントエンド VM サブネット上のインターネットへの TCP/443 (エグレス ファイアウォールによって、この広範な開放が狭くなります)	TCP/443 での nginx.org に必要なファイアウォール アプリケーション規則の許容量
Key Vault	Application Gateway と VM に TLS 認定資格証をインポート (トランスポート層セキュリティ) するには	両方の VM サブネットからプライベート エンドポイント サブネットへの - TCP/443 Application Gateway サブネットからプライベート エンドポイント サブネットへの - TCP/443 必要なアプリケーション セキュリティ グループ (ASG) の指定と Application Gateway サブネットでタグ付けされた VM からの - TCP/443	なし

DDoS Protection

ソリューションのすべてのパブリック IP を対象とする DDoS 保護プランの適用を担当するユーザーを決定します。 プラットフォーム チームは、IP 保護プランを使用することも、Azure Policy を使用して仮想ネットワーク保護プランを適用することもできます。 このアーキテクチャには、インターネットからのイングレス用のパブリック IP が含まれるため、カバレッジが必要です。

詳細については、「ネットワークと接続の推奨事項」を参照してください。

シークレットの管理

シークレット管理の場合、このアーキテクチャはベースライン アーキテクチャに従います。

ワークロード チームとして、Key Vault インスタンスにシークレットを保持し続けます。 アプリケーションとインフラストラクチャの操作をサポートするために、必要に応じてさらにインスタンスをデプロイします。

詳細については、「アプリケーション シークレットを保護するための推奨事項」を参照してください。

コストの最適化

ワークロード リソースの場合、ベースライン アーキテクチャのコスト最適化戦略もこのアーキテクチャに適用されます。

このアーキテクチャは、Azure ランディング ゾーン プラットフォーム リソースから大きなメリットを得られます。 チャージバック モデルを介してこれらのリソースを使用する場合でも、追加されたセキュリティとクロスプレミス接続は、それらのリソースを自己管理するよりもコスト効率が高くなります。

このアーキテクチャでは、プラットフォーム チームが次のリソースを管理します。 多くの場合、これらのリソースは従量課金ベース (チャージバック) であるか、ワークロード チームには無料である可能性があります。

• Azure Firewall
• セキュリティ情報およびイベント管理 (SIEM)
• Azure Bastion ホスト
• ExpressRoute などのクロスプレミス接続

プラットフォーム チームの他の一元化されたオファリングを活用して、SLO、目標復旧時間 (RTO)、または目標復旧ポイント (RPO) を妥協することなく、それらの利点をワークロードに拡張します。

詳細については、「コスト データの収集と確認の推奨事項」を参照してください。

このシナリオのデプロイ

このリファレンス アーキテクチャのデプロイについては、GitHub を参照してください。

次のステップ

ワークロード チームとプラットフォーム チームの間で共有されているコラボレーションと技術的な詳細を確認します。

サブスクリプションの自動販売