こんにちは。
今回は、この記事をベースに調べたことのメモです。
Azure Bastion とは
機能概要
Azure のサイトでは、Azure Bastion は以下のように紹介されています。
Azure Bastion は、より安全でシームレスな Remote Desktop Protocol (RDP) および Secure Shell Protocol (SSH) による仮想マシン (VM) へのアクセスを提供するフル マネージド サービスです。パブリック IP アドレスを通じて公開されることはありません。お客様のローカルまたはピアリングされた仮想ネットワークで直接サービスをプロビジョニングし、その中のすべての VM がサポートされます。
https://azure.microsoft.com/ja-jp/services/azure-bastion/
簡単な例をあげると、Azure のネットワーク内おく管理用の VM の接続などで VM に直接 RDP とかするのってちょっと抵抗あるじゃないですか。特に複数の管理用の VM とかあるなら、一度踏み台サーバとか立てたりしますよね。
この踏み台サーバを Azure Bastion が代替するという感じです。
感覚的には、踏み台サーバって本来はシステム上不要なので管理コストかけたくないので、そこを Azure Bastion で代替できるのはとてもいいと思います。
ちなみに2年くらい前に、プレビューの時にさわっているのですが、色々変わってるな～。
懐かしさを求めている方は、是非、その時の記事もみてみてくださいｗ
そんで、Standard が来たのでどんなもんなのかな？って調べた見たのですが、Basic と Standard は、Azure Bastion のインスタンス数が、Basic : 1個、Standard : 2～50 個って、違いくらいかなー。
他に何か違いがあるなら、教えて頂けるとめっちゃうれしいで～す♪
SKU の変更
Basic と Standard は、設定画面で変更することできます。
Stndard の最小インスタンスは 2 からで、最大 50 です。
ただ、以下がドキュメントに記載されてますので、Standard → Basic はできなくて、一度削除して作り直しらしい。。。
Downgrading from a Standard SKU to a Basic SKU is not supported. To downgrade, you must delete and recreate Azure Bastion.
https://docs.microsoft.com/en-us/azure/bastion/configuration-settings#upgradesku
価格
基本料金が、Standard の料金が 2 インスタンス分なので、Basic で数を増やすくらいなら、Standard で数を増やしていったほうが明らかにコストメリットがあるって感じですね。
料金については、変更等もあるかもなので、詳しいことは最新の情報をご確認ください。
SLA
SLA は、99.95%ってことらしいです。
特に記載がないから、Basic でも Standard でも分け隔てなく 99.95% ってことなんだろうな～。
インスタンス数の考え方
Basic と Standard で数と料金が違うだけなので、じゃー、どういうときに増やせばいいんよって話になるわけですよね。
で、Azure Bastion を別のリソースを使う場合。
これは、Azure Bastion で管理を行うネットワークが違うときとか権限なりセキュリティの境界を超えるとか要件が異なる場合です。
それ以外のときに、1 つのリソースに集約されるわけですね。
で、どういうときに分けるか
ドキュメントでは
ドキュメントでは、こんな感じで書かれてます。
Each instance can support 10-12 concurrent RDP/SSH connections.
https://docs.microsoft.com/en-us/azure/bastion/configuration-settings#instance
同時接続数として 10～12 くらいで考えるといいみたいですね。
ただ同時接続の予想って難しいですよね。
スモールスタートするか、多めで合わせていくかって感じですね。
ついでに、同じところにこんなこと書いてありますので、AzureBastionSubnet は、スケールを意識してサブネットを切る必要あるみたいっすね。今は MAX 50 インスタンスなので、「/26」くらいで切っておけばいいのかな。
Instances are created in the AzureBastionSubnet. For host scaling, the AzureBastionSubnet should be /26 or larger. Using a smaller subnet limits the number of instances you can create. For more information about the AzureBastionSubnet, see the subnets section in this article.
性能監視
予想が難しい同時接続数をキーにインスタンス数を考えるので、状態を監視しておくことが必要です。
監視のポイントは、以下のドキュメントに書いてあります。
こんなあたりが要チェックポイントかもしれないですね。
- Bastion communication status → Bastion の稼働状態のステータス
- Session count → 接続数
まぁーこれあるならオートスケールできるようにしてくれると、うれしいシーンもあると思うんだけどな～。
注意ポイント
以下の FAQ は一度見ておいたほうがいいかもです。
コピペはテキストのみOKとか、キーボードのレイアウトは「en-us-qwerty」とかちょっとおっとって思うようなことも書いてあったりするかも。
個人的には、ローカル PC 内と Azure Bastion 経由で接続するリモートホストの間でのコピペをさせたくないっていう要件の方が出てきやすい気もするんだけどな。
まとめ
Azure Bastion の使いどころって、こんな感じだと思うんですよね。
で、最近の Microsoft Azure って NW 周りのサービスが充実してきているんで、こんな構成も組めるようになってkitえるよ的なんだと思ってます。
ローカルの部分が、絵からは Site to Site であって、Point to Site ではないし、Point to Site だとルーティングお外にルーティングできたっけかなーって気はします。(最近ちゃんと調べてないからもしかしたらできるかも。)
進化すごいと思う。
で、Azure Bastion については、こういう使い方はあまり想像してなかったけど、MS のドキュメントでも書いているので、COVID-19 の影響でこういうニーズも少なくなかったのかな？
記事の中にも、こんな注釈ついてるし
This article describes how you can leverage Azure Bastion, Azure, Microsoft network, and the Azure partner ecosystem to work remotely and mitigate network issues that you are facing because of COVID-19 crisis.
ただ、このシナリオは、本格的な VDI を考える場合は、Azure Virtual Desktop だと思うし、低コストで台数もそこまでない時でかつ、以下が許容できる場合じゃないと難しいじゃないかな～っていうのは、正直な感想ですね。
- VDI をするときに、Azure Portal にサインインしてからブラウザ上で VM を操作する運用に耐えられるケース
- キーボードレイアウトが、「en-us-qwerty」でも大丈夫なケース(日本語だと結構めんどくさそう。。)
あと、オートスケールついてくれるとうれしい気がするっすね～。
コメント