Azure Bastion での信頼性
この記事では、Azure Bastion での信頼性のサポートについて説明します。 可用性ゾーンによるリージョン内の回復性について説明します。 また、複数リージョンのデプロイについても説明します。
回復性は、お客様と Microsoft の間の共同責任であるため、この記事では、お客様がニーズに合った回復性の高いソリューションを作成する方法についても説明します。
重要
Azure Bastion リソースのゾーン冗長機能は、現在プレビュー段階です。 ベータ版、プレビュー版の Azure の機能、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加の使用条件」を参照してください。
Azure Bastion は、プライベート IP アドレスを介して仮想マシンへの高セキュリティ接続を提供するためにプロビジョニングする、フル マネージドのサービスとしてのプラットフォーム (PaaS) です。 Azure portal から TLS 経由で直接、またはローカル コンピューターに既にインストールされているネイティブ SSH または RDP クライアントを介して、仮想マシンへのシームレスな RDP/SSH 接続が提供されます。 Azure Bastion 経由で接続するときは、仮想マシンにパブリック IP アドレス、エージェント、特別なクライアント ソフトウェアのいずれも必要ありません。
運用環境デプロイに関する推奨事項
運用環境のデプロイでは、Azure Bastion リソースがサポートされているリージョン内にある場合は、ゾーン冗長を有効にする必要があります。
一時的な障害
"一時的な障害" とは、コンポーネントでの短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 短期間経過すると、自然に修正されます。 アプリケーションが、通常は影響を受ける要求を再試行することにより、一時的な障害を処理することが重要です。
一時的な障害が仮想マシンまたは Azure Bastion ホストに影響する場合、セキュリティで保護されたソケット ホスト (SSH) プロトコルやリモート デスクトップ プロトコル (RDP) を使用するクライアントは、通常、自動的に再試行します。
可用性ゾーンのサポート
リソースが複数の可用性ゾーンに分散されるよう、Azure Bastion を "ゾーン冗長" に構成できます。 リソースを複数の可用性ゾーンに分散させると、運用ワークロードの回復性と信頼性を実現できます。
どの可用性ゾーンまたはゾーンに Azure Bastion リソースをデプロイするかを指定できます。 Azure Bastion により、インスタンスがゾーン全体に分散されます。 次に示す図では、Azure Bastion のインスタンスが 3 つのゾーンに分散されています。
Note
所有するインスタンスの数よりも多くの可用性ゾーンを指定した場合、Azure Bastion によりインスタンスは可能な限り多くのゾーンに分散されます。 1 つの可用性ゾーンが使用できない場合、障害のあるゾーンのインスタンスは、正常なゾーンの別のインスタンスに置き換えられます。
要件
ゾーン冗長で Azure Bastion リソースを構成するには、Basic、Standard、または Premium SKU を使ってデプロイする必要があります。
Bastion には、Standard SKU のゾーン冗長パブリック IP が必要です。
サポートされているリージョン
ゾーン冗長 Azure Bastion リソースは、次のリージョンにデプロイできます。
| アメリカ | ヨーロッパ | 中東 | アフリカ | アジア太平洋 |
|---|---|---|---|---|
| カナダ中部 | 北ヨーロッパ | カタール中部 | 南アフリカ北部 | オーストラリア東部 |
| 米国中部 | スウェーデン中部 | イスラエル中部 | 韓国中部 | |
| 米国東部 | 英国南部 | |||
| 米国東部 2 | 西ヨーロッパ | |||
| 米国西部 2 | ノルウェー東部 | |||
| 米国東部 2 EUAP | イタリア北部 | |||
| メキシコ中部 | スペイン中部 |
コスト
Azure Bastion では、ゾーン冗長の使用に追加のコストはかかりません。
可用性ゾーン構成のサポート
新しいリソース: Availability Zones をサポートするリージョンに新しい Azure Bastion リソースをデプロイする場合は、デプロイ先の特定のゾーンを選びます。 ゾーン冗長のためには、複数のゾーンを選択する必要があります。
重要
Azure Bastion リソースをデプロイした後で、可用性ゾーンの設定を変更することはできません。
使用する可用性ゾーンを選択した場合、実際には "論理可用性ゾーン" を選択していることになります。 別の Azure サブスクリプションの他のワークロード コンポーネントをデプロイした場合、別の "論理可用性ゾーン" 番号を使用して、同じ物理可用性ゾーンにアクセスできる場合があります。 詳細については、「物理ゾーンと可用性ゾーン」を参照してください。
移行: 可用性ゾーンをサポートしていない既存のリソースに、それを追加することはできません。 代わりに、新しいリージョンに Azure Bastion リソースを作成して、古いものを削除する必要があります。
ゾーン間のトラフィック ルーティング
SSH または RDP セッションを開始するとき、選択した任意の可用性ゾーン内の Azure Bastion インスタンスにそれをルーティングできます。
接続している仮想マシンとは異なる可用性ゾーンの Azure Bastion インスタンスに、セッションが送信される可能性があります。 次の図では、ユーザーからの要求はゾーン 2 の Azure Bastion インスタンスに送信されますが、仮想マシンはゾーン 1 にあります。
ほとんどのシナリオでは、ゾーン間の待機時間は微々たるものです。 ただし、Azure Bastion ワークロードの待機時間要件が異常に厳しい場合は、専用の単一ゾーンの Azure Bastion インスタンスを仮想マシンの可用性ゾーンにデプロイする必要があります。 この構成ではゾーン冗長は提供されず、ほとんどのお客様にはこれをお勧めしません。
ゾーンダウン エクスペリエンス
検出と対応: Azure Bastion が可用性ゾーンの障害を検出して対応します。 お客様は、可用性ゾーンのフェールオーバーを開始する必要はありません。
アクティブな要求: 可用性ゾーンが使用できない場合、障害のある可用性ゾーンで Azure Bastion インスタンスを使用する進行中の RDP または SSH 接続は終了されるため、再試行する必要があります。
接続先の仮想マシンが影響を受ける可用性ゾーンにない場合は、仮想マシンに引き続きアクセスできます。 VM のゾーンダウン エクスペリエンスの詳細については、「仮想マシンの信頼性: ゾーン ダウン エクスペリエンス」を参照してください。
トラフィックの再ルーティング: 新しい接続では、存続している可用性ゾーン内の Azure Bastion インスタンスが使用されます。 全体として、Azure Bastion は動作可能な状態を維持します。
フェールバック
可用性ゾーンが復旧すると、Azure Bastion は以下を実行します。
- 可用性ゾーン内のインスタンスを自動的に復元する。
- 他の可用性ゾーンに作成されたすべての一時インスタンスを削除する。
- インスタンス間のトラフィックを通常どおりに再ルーティングする。
ゾーン障害のテスト
Azure Bastion プラットフォームは、ゾーン冗長 Azure Bastion リソースのトラフィック ルーティング、フェールオーバー、フェールバックを管理します。 この機能は完全に管理されているため、お客様は何も開始したり、可用性ゾーンの障害プロセスを検証したりする必要はありません。
マルチリージョン サポート
Azure Bastion は、仮想ネットワーク内またはピアリングされた仮想ネットワーク内にデプロイされて、Azure リージョンに関連付けられます。 Azure Bastion は、単一リージョンのサービスです。 そのリージョンが使用できなくなった場合、Azure Bastion リソースも使用できなくなります。
Azure Bastion は、グローバルにピアリングされた仮想ネットワーク内の仮想マシンへの接続をサポートしていますが、Azure Bastion リソースをホストしているリージョンが使用できなくなると、Azure Bastion リソースを使用できなくなります。 回復性を高めるには、ソリューション全体をリージョンごとに個別の仮想ネットワークを持つ複数のリージョンにデプロイした場合、各リージョンに Azure Bastion をデプロイしてください。
別の Azure リージョンにディザスター リカバリー サイトがある場合は、そのリージョン内の仮想ネットワークに Azure Bastion をデプロイしてください。
サービス レベル アグリーメント
Azure Bastion のサービス レベル アグリーメント (SLA) には、サービスの期待される可用性と、その可用性の期待を達成するために満たす必要のある条件が記述されています。 それらの条件を理解するには、オンライン サービスの SLA を確認することが重要です。