プレイブック

パスワードハッシュをオンプレミスに残し、フェールオーバー機能を備えたハイブリッドID認証。

→パススルー認証（PTA）とバックアップとして有効化されたパスワードハッシュ同期（PHS）を使用する Azure AD Connect。

理由: PTAはローカルの AD に対して検証を行うことでハッシュをオンプレミスに保持します。PHSはオンプレミス AD または Connect エージェントが利用できない場合に認証フェールオーバーを提供します。

リファレンス↗

ユーザー、場所、デバイスの健全性、およびリスクに基づいてきめ細かなアクセス制御を適用することで、ゼロトラストを実装する。

→名前付きの場所、デバイスコンプライアンス（Intune）、サインインリスク（Identity Protection）をMFAなどの許可コントロールと組み合わせた Microsoft Entra Conditional Access ポリシー。

理由: Conditional Access は Zero Trust の強制エンジンであり、アクセスを許可する前にリクエストごとに複数のシグナルを評価します。単一のポリシーでは、異なる条件に異なるコントロールを適用することはできません。

リファレンス↗

数十または数百のサブスクリプション全体で一貫したポリシー（タグ付け、許可されたリージョンなど）を適用する。

→ルートまたは親管理グループレベルで Azure Policy イニシアティブが割り当てられた管理グループの階層。

理由: 管理グループはサブスクリプションの上にガバナンススコープを提供し、ポリシーの継承を可能にします。イニシアティブは複数のポリシーをバンドルして割り当てを簡素化します。

リファレンス↗

承認ワークフローと監査機能を備えた、管理者へのジャストインタイム（JIT）特権アクセスを提供する。

→Microsoft Entra Privileged Identity Management (PIM) を使用して、ユーザーを永続的にアクティブな状態ではなく、ロールの対象とする。

理由: PIM は、ユーザーが期間限定でロールをアクティブ化することを要求し、オプションの MFA、正当化、および承認を伴うことで、最小特権を強制し、完全な監査証跡を作成します。

リファレンス↗

集中分析およびクエリのために、複数のサブスクリプションにわたるすべての Azure リソースからログを収集する。

→アクセス制御のためのリソースコンテキスト RBAC を備えた単一の集中 Log Analytics ワークスペース。

理由: 集中ワークスペースは、サブスクリプション間のクエリを可能にし、管理を簡素化し、データの重複を回避します。リソースコンテキスト RBAC は、ユーザーがアクセスできるリソースからのログのみをクエリできるようにします。

Azure リソース（例：App Service、Function、VM）が、保存された資格情報なしで他の Azure リソース（Key Vault、SQL、Storage）に安全にアクセスする必要がある。

→コンピューティングリソースにマネージドID（システム割り当てまたはユーザー割り当て）を割り当て、ターゲットリソースに対して RBAC ロールを付与する。

理由: マネージドIDは、資格情報管理（シークレット、証明書）を排除し、トークンの取得とローテーションを自動的に処理します。複数のリソース間でIDを共有するには、ユーザー割り当てを使用します。

リファレンス↗

Azure Policy によって識別された既存の非準拠 Azure リソースを自動的に修復する。

→"DeployIfNotExists" または "Modify" ポリシー効果を使用する。既存のリソースの場合、ポリシー割り当てに対して修復タスクを作成する必要があり、これには十分なアクセス許可を持つマネージドIDが必要となる。

理由: これらの効果を持つポリシーは、デフォルトでは新規/更新されたリソースにのみ適用されます。既存の非準拠リソースをスキャンして修正するには、修復タスクが必要です。

すべてのリソースに必須タグを適用し、親リソースグループからタグ（例：CostCenter）を自動的に継承する。

→必須タグには「Deny」効果を持つ Azure Policy を使用し、不足している場合はリソースグループからタグを継承するために「Modify」効果を持つ別のポリシーを使用する。

理由: Deny は作成時に準拠を強制します。Modify 効果はタグの伝播を自動化し、手作業を減らし、一貫性を確保します。

マルチティアまたはマイクロサービスアプリケーションを監視し、トランザクションをエンドツーエンドで追跡してパフォーマンスのボトルネックを特定する。

→すべてのサービスを Application Insights で計装する。依存関係の視覚化にはアプリケーションマップを、エンドツーエンドのリクエスト分析には分散トレースを使用する。

理由: Application Insights はネイティブの APM ソリューションであり、コンポーネント間のテレメトリを自動的に関連付け、トランザクションの統合されたビューを提供し、レイテンシの問題を特定します。

外部パートナーに対するアクセスを、リクエスト、承認、期間限定アクセス、および定期的なレビューを含めて管理する。

→Microsoft Entra ID Governance のエンタイトルメント管理。リソースをバンドルし、承認ワークフローを定義し、有効期限ポリシーを設定し、アクセスレビューをスケジュールするアクセスパッケージを作成する。

理由: 外部アクセスに対して完全で自動化されたライフサイクルを提供し、手動でのゲストアカウント管理と比較して、管理上のオーバーヘッドとセキュリティリスクを軽減します。

マネージドサービスプロバイダーまたは中央ITチームが、複数の顧客/部門の Azure AD テナントにわたってリソースを管理する必要がある。

→Azure Lighthouse。顧客のサブスクリプションをオンボードして、特定の RBAC ロールを持つ委任されたアクセスを管理テナントに付与する。

理由: Lighthouse は、ディレクトリを切り替えたりゲストアカウントを管理したりすることなく、テナント間管理のための単一のコントロールプレーンを提供し、顧客は完全な制御と所有権を保持します。

VPN を使用せずに、またはアプリケーションをインターネットに公開せずに、オンプレミスの Web アプリケーションへの外部ユーザー向けの安全なリモートアクセスを提供する。

→Microsoft Entra Application Proxy。

理由: Application Proxy は、Azure へのアウトバウンド接続を行う軽量なオンプレミス コネクタを使用します。リバースプロキシとして機能し、インバウンドファイアウォールルールやアプリケーションのパブリック IP なしで、Entra ID の事前認証と安全なアクセスを可能にします。

グローバルに分散されたアプリケーションで、10ms 未満の読み取り/書き込みレイテンシ、柔軟なスキーマ、99.999% の可用性を持つデータベースが必要である。

→マルチリージョン書き込みが有効になっている Azure Cosmos DB。ワークロードを均等に分散するためにパーティションキーを選択する必要がある。

理由: Cosmos DB は、ターンキーのマルチリージョン書き込みによるグローバル分散のために特別に構築されており、保証された低レイテンシと最高の可用性 SLA を提供します。他のデータベースは手動レプリケーションが必要であり、書き込みレイテンシには匹敵しません。

大容量の IoT テレメトリを Cosmos DB に取り込み、デバイスごとの効率的なクエリと古いデータの自動アーカイブを可能にする。

→パーティションキーとして `/deviceId` を使用する。古いドキュメントを自動削除するためにコンテナに TTL を構成する。削除前にデータをキャプチャするために Change Feed を使用し、コールドストレージ（例：Blob Storage）にアーカイブする。

理由: `deviceId` でパーティション分割することで、単一デバイスのデータをコロケーションし、クエリを効率化します。TTL は無料で自動削除を提供します。Change Feed はリアクティブなアーカイブパイプラインを可能にします。

予測不可能でバースト的なトラフィックと大幅なアイドル期間を持つワークロード向けに、費用対効果の高い Azure SQL DB の価格モデルを選択する。

→サーバーレスコンピューティング層を備えた vCore ベースのモデルを使用する。

理由: サーバーレスは、需要に基づいてコンピューティングを自動的にスケーリングし、アイドル期間中は自動一時停止し、使用されたコンピューティングに対して秒単位で課金します。これは、プロビジョニングされた層よりも断続的なワークロードにとって、はるかに費用対効果が高いです。

階層型名前空間とディレクトリレベルの ACL が必要な大規模データ分析プラットフォーム向けのストレージソリューション。

→Azure Data Lake Storage Gen2（階層型名前空間が有効になっているアカウント）。

理由: ADLS Gen2 はビッグデータ分析に最適化されており、オブジェクトストレージのスケーラビリティと真の階層型ファイルシステム、およびきめ細かなセキュリティのための POSIX 準拠 ACL を組み合わせています。

階層化された要件（読み取りアクセスを伴う最大の耐久性、DRのみ、リージョン内データセンター障害保護）に基づいてストレージ冗長性を選択する。

→1. 最大の耐久性/読み取り：RA-GZRS。2. DRのみ：GRS。3. リージョン内：ZRS。

理由: 特定の RPO/RTO とアクセスニーズに冗長性オプションを合わせます。RA-GZRS が最高層です。GRS はフェールオーバー専用です。ZRS はリージョン内のデータセンター障害から保護します。

データウェアハウス内の大規模な構造化データと、データレイク内の半構造化データを、統合された分析プラットフォームを使用してクエリする。

→Azure Synapse Analytics。構造化データには専用の SQL プールを、データレイク上のアドホッククエリにはサーバーレス SQL プールを使用する。

理由: このハイブリッドアプローチは、パフォーマンスとコストの両方を最適化します。専用プールはマネージドデータウェアハウスに高いパフォーマンスを提供し、サーバーレスプールはデータレイク内の生データへのクエリごとのアクセスを提供します。

100 GB を超えるメモリと高可用性が必要なセッション状態および製品データ用のキャッシングソリューション。

→クラスタリングが有効な Azure Cache for Redis Enterprise または Premium レベル。

理由: Premium/Enterprise レベルのクラスタリングにより、データを複数のノードにシャーディングすることで、単一ノードのメモリ制限を超えてキャッシュをスケールさせることができ、スループットも向上します。

多くの小規模でスパイク的なワークロードに対してコストを最適化しながらテナントを隔離する SaaS アプリケーション向けのデータベースアーキテクチャ。

→Azure SQL Elastic Pools。リソースを共有するためにテナントをプールにグループ化し、大規模な「ノー​​ジーネイバー」テナントには専用のデータベースを用意する。

理由: Elastic Pools は、リソース共有のコストメリットを提供しつつ、データベースごとのパフォーマンス制限を適用することで、ノー​​ジーネイバー問題とテナントごとのデータベースのコスト高との間のバランスをとります。

SQL Agent、クロスデータベースクエリ、CLR などの機能を使用する複雑なオンプレミス SQL Server データベースを PaaS サービスに移行する。

→Azure SQL Managed Instance。

理由: SQL Managed Instance は、オンプレミスの SQL Server エンジンとほぼ100%の互換性を提供し、Azure SQL Database がサポートしないインスタンスレベルの機能をサポートします。これは、最小限のコード変更でのリフトアンドシフトに最適です。

すべてのデータおよび顧客管理の暗号化キーが特定の地理的境界内（例：EU）に留まるようにする。

→すべてのリソースを境界内のリージョンにデプロイする。これを強制するために「許可された場所」効果を持つ Azure Policy を使用する。顧客管理キー（CMK）も境界内にある Azure Key Vault に保存する。

理由: 厳格なデータ主権規制を満たすためには、物理的なデプロイ場所、ポリシーベースの強制、およびキーの所在地の組み合わせが必要です。

ハイブリッドデータ環境（Azure、オンプレミス、他のクラウド）全体でデータの検出、分類、およびリネージの追跡を行う。

→Microsoft Purview。

理由: Purview は、自動スキャン、ビジネス用語集、分類、および幅広いデータソースにわたるリネージ追跡を備えた統合データガバナンスソリューションを提供します。

データ（例：財務記録）を、定義された保持期間中、消去不能で変更不能な（WORM）状態に保存する。

→コンテナに時間ベースの不変ポリシーを設定し、その後ロックする Azure Blob Storage。

理由: ロックされた不変ポリシーは、保持期間が終了するまで、管理者を含むいかなるユーザーによる BLOB の削除または変更も防止し、厳格な規制コンプライアンス要件を満たします。

RPO が数分、RTO が1時間未満の Web アプリケーション（App Service + SQL DB）向けの DR ソリューションを設計する。

→Azure SQL Database 自動フェールオーバーグループ、セカンダリ App Service デプロイ、およびルーティング用の Azure Front Door または Traffic Manager。

理由: このパターンは、各層の DR に対応します。SQL フェールオーバーグループはデータレプリケーションとフェールオーバーを処理します。事前デプロイされた App Service はデプロイの遅延を回避します。グローバルルーター（Front Door/Traffic Manager）はアクティブなリージョンにトラフィックを誘導します。

直列アプリケーション（A -> B -> C）の複合 SLA が低すぎる。どのように改善するか？

→個別の SLA が最も低いコンポーネント（「最も弱いリンク」）を特定し、並列インスタンス（例：ロードバランサーを使用してリージョンまたはゾーン間で）をデプロイして冗長化する。

理由: 直列チェーンの複合 SLA は、SLA を乗算して計算されます（SLA_A * SLA_B * SLA_C）。コンポーネントに並列インスタンスを追加すると、その実効 SLA が向上し、複合 SLA に最大のプラスの影響を与えます。

単一の Azure リージョン内で VM の可用性を可能な限り高める。

→リージョン内のすべての利用可能な Availability Zones に複数の VM をデプロイする。

理由: Availability Zones は、独立した電源、冷却、ネットワークを備えた物理的に分離されたデータセンターです。これにより、データセンターレベルの障害から保護され、リージョン内で最高の 99.99% の SLA を提供します。

オンプレミスの VMware または Hyper-V 仮想マシン向けに、Azure へのディザスターリカバリソリューションを提供する。

→Azure Site Recovery (ASR)。Azure へのレプリケーションを構成し、オーケストレーションされたフェールオーバー用のリカバリプランを作成し、非破壊的な DR ドリルにはテストフェールオーバーを使用する。

理由: ASR は、オンプレミス（および Azure）VM の DR レプリケーション用に特別に構築された Azure サービスであり、継続的なレプリケーション、オーケストレーションされたリカバリ、および分離されたテスト機能を提供します。

Azure SQL Database で、データ損失ゼロ（RPO=0）と読み取りスケーリング機能を備えたリージョン内最高可用性を実現する。

→ゾーン冗長が有効な Business Critical サービス層を使用する。

理由: Business Critical 層は、複数のレプリカ間で同期レプリケーションを行う Always On Availability Group を使用し、RPO 0 を提供します。ゾーン冗長は、異なる AZ にレプリカを配置し、99.995% の SLA を実現します。読み取り可能なセカンダリレプリカが含まれます。

グローバルアプリケーションは、最も近いリージョンからユーザーにサービスを提供し、自動的かつ即座にフェールオーバーする必要がある。

→レイテンシベースのルーティングとヘルスプローブベースのフェールオーバーのために Azure Front Door を使用し、複数のリージョンにわたるアクティブ/アクティブデプロイパターンを使用する。

理由: Azure Front Door は、最も低レイテンシのバックエンドへのグローバルエニーキャストルーティングを提供します。そのヘルスプローブはリージョン障害を検出し、数秒以内に健全なリージョンにトラフィックを自動的に再ルーティングし、シームレスなアクティブ/アクティブアーキテクチャを可能にします。

Kubernetes オブジェクト定義と永続ボリュームデータの両方を含む、AKS 上のステートフルアプリケーションをバックアップする。

→Azure Backup for AKS を使用する。

理由: Azure Backup for AKS は、クラスター状態（etcd）と永続ボリュームデータ（CSI スナップショット経由）の両方に対して、統合されたポリシーベースのバックアップを安全な集中 Backup Vault に提供するネイティブソリューションです。

規制コンプライアンスのために、管理者によるものを含む偶発的または悪意のある削除からバックアップを保護する。

→Azure Backup または Recovery Services コンテナでイミュータブルコンテナを有効にする。

理由: イミュータビリティは、コンテナレベルの設定であり、バックアップリカバリポイントが一度作成されると、有効期限が切れるまで誰も削除できないことを保証し、最高レベルのバックアップ保護を提供します。

App Service Environment v3 (ASEv3) が1つのリージョンで重要なアプリケーションをホストしており、別のリージョンに DR ソリューションが必要である。

→DR リージョンに2番目の ASEv3 をデプロイする。グローバルロードバランシングとフェールオーバーには Azure Front Door を使用する。適切なテクノロジー（例：SQL 自動フェールオーバーグループ）を使用してデータをレプリケートする。

理由: ASEv3 はリージョンデプロイです。DR の場合、2番目の ASE をデプロイし、Front Door のようなグローバルルーターを使用してトラフィックを管理する必要があります。ASR は App Service の DR には使用されません。

集中接続（ExpressRoute/VPN）、共有サービス、およびワークロード分離を備えたエンタープライズ向けのスケーラブルなネットワークを設計する。

→ハブアンドスポークトポロジ。ハブ VNet にはゲートウェイ、Azure Firewall、その他の共有サービスが含まれます。スポーク VNet にはアプリケーションワークロードが含まれ、ハブにピアリングされる。

理由: これは、標準的で推奨されるエンタープライズパターンです。セキュリティと接続性を集中させ、コストと複雑さを削減し、スポークは強力なワークロード分離を提供します。

グローバル Web アプリケーションで、Layer 7 ロードバランシング、Web Application Firewall（WAF）、SSL オフロード、および URL ベースのルーティングが必要である。

→Azure Front Door（Standard または Premium）。

理由: Front Door は、これらの機能を単一のサービスに統合する最新のクラウド CDN およびグローバルロードバランサーであり、Traffic Manager とリージョンの Application Gateways を組み合わせるよりも優れたパフォーマンスと簡素化された管理を提供します。

複数のチーム向けに、様々なワークロードタイプ（CPU、GPU、メモリ集約型）に対応するプロダクショングレードの AKS クラスターを設計する。

→専用のシステムノードプールと、異なる VM SKU（例：CPU 向け F シリーズ、メモリ向け E シリーズ、GPU 向け N シリーズ）を持つ複数のユーザーノードプールを使用する。クラスターオートスケーラーを使用し、稼働時間 SLA のために Standard/Premium 層を有効にする。

理由: 複数のノードプールにより、適切なハードウェアを適切なワークロードに合わせることができ、パフォーマンスと費用対効果を高めます。システム Pod の分離は安定性を向上させます。財政的に裏付けられた SLA には Standard/Premium 層が必要です。

イベント駆動型のサーバーレスワークフローで、Functions Consumption プランの10分制限を超える実行時間が必要である。

→Premium プランまたは App Service プランで Azure Functions を使用するか、オーケストレーションに Azure Durable Functions を使用する。

理由: Premium プランは最大60分（デフォルト30分）の実行をサポートし、コールドスタートを回避します。Durable Functions は、人間のインタラクションや長い待機時間を含む可能性のある、長時間実行されるステートフルなワークフローをオーケストレーションするのに理想的です。

ファンアウトイベント通知システムと、信頼性の高い順序付けられたコマンド処理システムのためのメッセージングサービスを選択する。

→ファンアウトでリアクティブなイベント処理には Azure Event Grid を使用する。信頼性の高いトランザクションコマンド処理には Azure Service Bus Queues（順序付けにはセッションを使用）を使用する。

理由: Event Grid は、リアクティブプログラミングに最適化された軽量のプッシュベースのイベントルーティングサービスです。Service Bus は、エンタープライズメッセージング向けに FIFO（セッション）、デッドレタリング、トランザクションなどの機能を備えた堅牢なメッセージブローカーです。

プライベート VNet で実行されている API を、レート制限と認証のポリシーを適用して、外部パートナーに安全に公開する。

→内部 VNet モードで Azure API Management (APIM) をデプロイし、公開イングレスのために WAF を備えた Azure Application Gateway をフロントエンドとして使用する。

理由: このパターンは多層防御を提供します。VNet 内の APIM はプライベートバックエンドにアクセスできます。App Gateway は SSL を終端し、WAF でトラフィックを検査し、プライベート APIM インスタンスに転送します。APIM ポリシーは認証、レート制限などを処理します。

数百の支社と VNet を、自動化された任意対任意の接続でグローバルに接続する。

→Azure Virtual WAN。

理由: Virtual WAN は、大規模なグローバルトランジットネットワーキングのためのマネージド Microsoft ソリューションです。複雑なルーティングを自動化し、VPN、ExpressRoute、VNet スポークを接続するための統合ハブを提供します。

数千コアと低レイテンシの MPI 通信を必要とする、大規模な並列バッチジョブ（例：CFD シミュレーション）を実行する。

→低優先度（Spot）価格設定を使用して、InfiniBand 対応 VM（例：HB シリーズ）のプールを備えた Azure Batch。

理由: Azure Batch は HPC 向けに設計されたジョブスケジューラです。InfiniBand 対応 VM は、MPI に必要な高スループット、低レイテンシの RDMA ネットワークを提供します。低優先度 VM は、フォールトトレラントなワークロードのコストを大幅に削減します。

VNet 内のアプリケーションが、トラフィックをパブリックインターネット経由でルーティングせずに PaaS サービス（SQL、Storage）にアクセスする必要がある。

→PaaS サービス用にプライベートエンドポイントを作成する。これにより、サービスに VNet 内のプライベート IP アドレスが割り当てられる。

理由: Private Endpoint は、プライベート PaaS 接続のための最も安全な方法です。これにより、トラフィックが Microsoft のバックボーンにとどまり、PaaS サービスのパブリックエンドポイントを完全に無効にすることができます。

サーバーレス API バックエンド、CI/CD 統合、およびカスタムドメインを備えたモダンなシングルページアプリケーション（SPA）をホストする。

→Azure Static Web Apps。

理由: これは、この正確なパターン向けに特別に構築された、合理化されたサービスです。静的コンテンツホスティング、API 用の統合された Azure Functions、GitHub/Azure DevOps 統合、および無料の SSL 証明書付きのマネージドカスタムドメインを組み合わせています。

オンプレミスおよび他のクラウド（例：AWS）で実行されているサーバーを、Azure から管理し、ガバナンス（Azure Policy）を適用する。

→非 Azure サーバーに Azure Arc エージェントをインストールして、それらを Azure Arc 対応サーバーとしてプロジェクションする。

理由: Azure Arc は、Azure のコントロールプレーンをあらゆるインフラストラクチャに拡張します。サーバーが Arc 対応になると、ネイティブの Azure VM と同様に、Azure Policy、Monitor、Defender for Cloud などで管理できます。

レガシーなモノリシックアプリケーションから新しいマイクロサービスへ、"ビッグバン"切り替えなしで段階的に機能を移行する。

→Azure API Management または Application Gateway のようなリバースプロキシを使用して、Strangler Fig パターンを適用する。

理由: リバースプロキシはモノリスへの呼び出しを傍受し、特定の機能のトラフィックを新しいマイクロサービスに選択的にルーティングします。時間が経つにつれて、プロキシはより多くのトラフィックをリダイレクトすることでモノリスを「締め付け」、最終的に古いシステムを廃止できるようになります。

VM が強制トンネリング（すべてのインターネットトラフィックがオンプレミスにルーティングされる）が設定された VNet にあるが、Azure PaaS サービスにアクセスできない。

→強制トンネリングは、Azure のパブリックエンドポイントへの直接アクセスを遮断します。PaaS アクセスには、サービスエンドポイントまたはプライベートエンドポイントを使用する。あるいは、特定の Azure サービスタグに対して「インターネット」を次ホップとする UDR を追加して、トンネルをバイパスすることもできる。

理由: PaaS サービスにはパブリックエンドポイントがあります。強制トンネリングはそのトラフィックをオンプレミスに送信します。PaaS サービスをプライベートにする（エンドポイント）か、特定のルート例外を作成する（サービスタグ付き UDR）かのいずれかで、例外パスを作成する必要があります。

ハブスポークネットワークで、Azure からオンプレミス DNS 名を解決し、オンプレミスから Azure プライベート DNS ゾーンを解決する必要がある。

→ハブ VNet に Azure DNS Private Resolver をデプロイする。オンプレミスから Azure DNS を解決するためのインバウンドエンドポイントと、Azure からオンプレミス DNS を解決するための転送ルールセットを備えたアウトバウンドエンドポイントを構成する。

理由: これは、カスタム DNS サーバー VM を管理する必要性を置き換える、ハイブリッド DNS 解決のための現代的な PaaS ソリューションです。プライベート DNS ゾーンとオンプレミス DNS フォワーダーにネイティブに統合されます。

複数の VNet が、外部サービスによるホワイトリスト登録のために、すべての送信トラフィックに対して予測可能で静的なパブリック IP を必要とする。

→ハブスポークトポロジで、スポークからのすべての送信トラフィック（0.0.0.0/0）をハブ VNet 内の Azure Firewall または NAT Gateway を介してルーティングする。

理由: ハブでのエグレスの集中化により、すべての送信トラフィックがハブのファイアウォール/NAT Gateway のパブリック IP を使用することが保証され、管理と外部ホワイトリスト登録が簡素化されます。NAT Gateway は純粋な SNAT ではより単純ですが、Firewall はセキュリティ検査を追加します。

メモリ内で使用中であっても暗号化され、クラウドオペレーターから保護される方法で、非常に機密性の高いデータを処理する。

→Intel SGX または AMD SEV-SNP を備えた Azure Confidential Computing VM（DCsv3/ECsv3 シリーズ）を使用して、ハードウェアベースの信頼実行環境（TEE）または暗号化されたメモリでコードを実行する。

理由: Confidential Computing は、従来の保管時および転送中の暗号化では対応できないセキュリティの「データ使用中」の柱に対応します。検証可能なハードウェアレベルの分離を提供します。

SaaS プロバイダーが、自社の VNet で実行されているサービスを、顧客の VNet 内の顧客に、Azure プライベートネットワーク経由でのみ公開する必要がある。

→プロバイダーは自身の Standard Load Balancer 上に Azure Private Link Service を作成する。顧客は自身の VNet に、そのサービスに接続する Private Endpoint を作成する。

理由: Private Link は、安全でプライベートなテナント間サービス公開のための決定的なパターンです。パブリックインターネットへの露出、IP 重複の問題、および複雑な VNet ピアリング構成を回避します。