Azure Bastionとは?踏み台サーバーのマネージド代替・4つのSKUと接続方式・料金を実装者目線で解説
Azure Bastionは、仮想マシンにパブリックIPアドレスを付けないまま、ブラウザやネイティブクライアントからRDP/SSHで安全に接続できるようにするMicrosoft Azureのマネージドサービスです。実装で最初に押さえるべきは、これが自前で立てる踏み台サーバー(ジャンプサーバー)をAzureがPaaSとして肩代わりする位置づけであること、Developer・Basic・Standard・Premiumという4つのSKUで使える機能とスケールが変わること、そしてSKUによって料金の考え方が「無料」から「時間課金+データ転送」まで分かれることです。この記事では定義から、接続の仕組み、4つのSKUの機能差、接続方式とセキュリティ、自前踏み台やAWSの対応サービスとの違い、料金体系、そして「どんなシステムで採用し、どこでは見送るか」の判断基準までを、2026年時点の公式ドキュメントに基づいて整理します。
まとめ:Azure Bastionの要点と採用判断の分岐
Azure Bastionは、Azure上の仮想マシンへ管理接続する際に、VMにパブリックIPを付けず、踏み台サーバーも自前運用せずに済ませるためのマネージドサービスです。仮想ネットワーク内にAzureBastionSubnetという専用サブネットを用意してBastionを配置すると、利用者はAzureポータルやAzure CLIから、TLSで暗号化されたHTTPS経由でVMのRDP/SSHセッションに到達できます。VM側の管理ポート(3389/22)をインターネットに開けずに済むため、公開面を絞りつつ管理者の接続性を保てるのが核心の価値です。
採用が合理的なのは、Azure中心の構成で、VMへのパブリックIP付与やインターネット向けの管理ポート開放をやめ、踏み台の構築・パッチ運用から手を引きたい場合です。逆に、常時稼働のBastionが少数VMに対して割高になる小規模構成や、AWS/Google Cloud中心の環境、そもそもVMを持たないサーバーレス主体の構成では、Developer SKUや各クラウドのマネージドな接続手段など別の選択肢を先に検討します。自社システムでVMへの管理経路をどう設計するか迷う段階なら、ネットワークとセキュリティを含めてクラウド構成から相談できる開発会社に早めに当たると、後戻りの少ない設計にたどり着けます。
Azure Bastionの仕組みと踏み台サーバーのマネージド代替という位置づけ
Azure Bastionを理解する近道は、従来オンプレやクラウドで自前構築してきた踏み台サーバーの役割を思い出すことです。Bastionはその役割をAzureのサービスとして提供し、運用の手間と設定ミスの余地を減らします。
パブリックIPなしでVMへRDP/SSH接続するPaaSという定義
Azure Bastionは、Platform as a Service(PaaS)として提供される、仮想マシンへ安全にリモート接続するためのマネージドサービスです。従来は、インターネットからVMを操作するために、VMにパブリックIPを付けて管理ポートを開けるか、踏み台サーバーを1台立ててそこを経由させるのが定番でした。前者は攻撃面を直接さらし、後者は踏み台自体の構築・パッチ適用・監視という運用を背負い込みます。Bastionはこの中継役をマネージドで引き受け、対象VMにはパブリックIPも管理ポートの公開も不要にしたうえで、Bastion経由でのみRDP/SSHを通す形に置き換えるのが基本の立ち位置です。踏み台という概念そのものの整理は、踏み台サーバーの仕組みとSSH多段接続・採用判断を解説した記事で押さえておくと、Bastionが何をマネージド化しているのかが立体的に見えてきます。
AzureBastionSubnetとブラウザ/ネイティブクライアントからの到達経路
Bastionは、対象VMと同じ仮想ネットワーク内のAzureBastionSubnetという名前の専用サブネットに配置します(専用ホスト型のSKUでは/26以上のサイズが要件・2026年時点)。利用者の到達経路は2通りで、1つはAzureポータル上のブラウザから、TLSで暗号化されたHTTPS(443)越しにRDP/SSHセッションを開く方式です。もう1つは、上位SKUで使えるネイティブクライアント方式で、手元のAzure CLIやRDP/SSHクライアントからBastion経由でVMへつなぎます。いずれの場合もVMには到達可能なパブリックIPがなく、Bastionが仮想ネットワークの内側からプライベートIPでVMに接続する構造になります。
仮想ネットワークピアリングと1リージョン1Bastionの配置設計
Bastionは配置した仮想ネットワークを起点に動き、専用ホスト型のSKU(Basic以上)では、ピアリングした仮想ネットワーク内のVMにも到達できます。裏を返すと、ピアリングでつながっていない別の仮想ネットワークのVMには、そのネットワーク側に別のBastionを置くか、ハブ&スポーク構成でハブ側のBastionからピアリング経由で届かせる設計が要ります。多数の仮想ネットワークを抱える環境では、ハブに1つBastionをまとめてスポークVMへピアリングで届かせる集約設計が、コストと運用の両面で扱いやすくなるでしょう。なお、後述するDeveloper SKUはこのピアリング接続に対応しない点が設計上の分かれ目です。
Developer・Basic・Standard・Premiumの4つのSKUと機能差
Azure Bastionには4つのSKUがあり、使える機能・スケール・料金がはっきり分かれます(2026年時点)。設計はまず「どのSKUを選ぶか」から始まるため、代表的な差を先に押さえます。
共有インフラで無料のDeveloper SKUと専用ホスト型の3SKU
Developer SKUは、共有リソース上で動く無料のSKUで、AzureBastionSubnetもパブリックIPも要らず、ゼロ構成に近い手軽さで使えます。ただし一度に接続できるVMは1台のみ、仮想ネットワークピアリングや同時接続には対応せず、提供リージョンも限られます。用途は開発・テスト環境での一時的な接続に絞られ、本番ワークロードには向きません。一方のBasic・Standard・Premiumは、いずれも専用のBastionホストを持つ有料SKUで、AzureBastionSubnetとパブリックIP(Premiumのプライベートのみ構成を除く)を伴う、本番向けの構成になります。
ネイティブクライアント・ファイル転送・IPベース接続が要るならStandard以上
Basic SKUは、2インスタンス固定の専用デプロイで、同一/ピアリング仮想ネットワークのVMへブラウザからRDP/SSHをつなぐ基本機能を提供します。一方で、Azure CLIなどのネイティブクライアント接続、共有可能リンク、IPアドレスベースの接続、カスタム受信ポート、ファイルのアップロード/ダウンロードといった高度な機能はStandard以上でないと使えません。Standardはこれらの機能に加え、2〜50インスタンスへのホストスケーリングに対応し、最大構成で最大1,000のRDPまたは2,000のSSHセッションまでスケールします。実装で「手元のクライアントからつなぎたい」「ファイルを送りたい」といった要件があるなら、Basicではなく最初からStandardを選ぶのが現実的です。
セッション記録とPrivate-only構成が要るならPremium
Premium SKUは、Standardの全機能に加えて、コンプライアンスや監査で求められるセッションの記録と、パブリックIPを一切持たないプライベートのみのデプロイに対応します。監査証跡としてのセッション録画が義務付けられている、あるいはBastion自体をインターネットから完全に切り離したい、といった規制要件がある場合の選択肢です。主な機能差を次の表に整理します(2026年時点・Microsoft Learn準拠)。
| 機能 | Developer | Basic | Standard | Premium |
|---|---|---|---|---|
| 時間単位の料金 | 無料 | 有料 | 有料 | 有料 |
| 専用ホスト/ピアリング | 非対応 | 対応 | 対応 | 対応 |
| 同時VM接続 | 1台のみ | 複数 | 複数 | 複数 |
| ネイティブクライアント/ファイル転送 | 非対応 | 非対応 | 対応 | 対応 |
| セッション記録/Private-only | 非対応 | 非対応 | 非対応 | 対応 |
SKUは下位から上位へのアップグレードに対応する一方、ダウングレードには対応せず、下げたい場合はBastionを削除して作り直す必要があります(アップグレードは約10分・2026年時点)。まずは要件を満たす最小SKUで始め、機能が必要になった段階で引き上げる段階設計が無難です。
Azure Bastionの接続方式とセキュリティ:攻撃面を絞る勘所
Bastionを入れる目的は接続の利便性だけでなく、VMの攻撃面を減らすことにあります。どのプロトコルでどう守るのかを、実装の観点で押さえます。
WindowsのRDP・LinuxのSSHと上位SKUでのクロスプロトコル対応
基本の対応は、WindowsVMにはRDP、LinuxVMにはSSHで、これは全SKUで使えます。加えてStandard以上では、LinuxVMへのRDP、WindowsVMへのSSHといったクロスプロトコル接続にも対応する点が上位SKUの利点です。認証は、SSHの秘密鍵をAzure Key Vaultから読み込ませる連携や、Microsoft Entra IDを用いた方式に対応しており、鍵や資格情報を手元にばらまかずに接続を組めます。SSH鍵や接続文字列といった機密の保管先としては、Azure Key Vaultの仕組みとRBAC・保護機能を解説した記事と組み合わせると、Bastionの入口とその先の機密管理を一貫して設計できます。
VMのパブリックIPと管理ポート開放を不要にする境界防御の効果
Bastionを使う最大のセキュリティ上の効果は、対象VMからパブリックIPを外し、ネットワークセキュリティグループ(NSG)でインターネットからのRDP(3389)/SSH(22)の受信を閉じられることです。管理接続はすべてBastion経由に一本化されるため、インターネットに直接さらされる管理ポートがなくなり、総当たり攻撃やポートスキャンの対象面が縮みます。利用者側から見た通信もTLSで暗号化されたHTTPS(443)に集約され、クライアント端末にパブリックIPやVPNを用意せずとも、ブラウザだけで到達できます。こうした境界の考え方は、責任共有モデルを含むクラウド全体の守り方と地続きです。土台はクラウドセキュリティのリスクと責任共有モデルを解説した記事で押さえておくと、Bastionをどこまで自社で守るべきかの線引きがはっきりします。
共有可能リンクとNSGによる到達制御・常時課金など運用上の注意点
Standard以上では、一時的な外部協力者に対して共有可能リンクを発行し、Azureアカウントを持たない相手にもVMアクセスを許す運用が組めます。到達制御としては、AzureBastionSubnetに適用するNSGで、Bastionが受け付ける通信や、BastionからVMへ向かう通信を細かく制御できる仕組みです。運用上の注意点としては、Bastionは専用ホスト型SKUだと接続の有無にかかわらず時間課金が発生するため、常時稼働させる前提で費用対効果を見積もる必要があること、そして接続元を絞るならNSGやAzureポリシーでの制御を併用することが挙げられます。
Azure Bastionと自前踏み台・AWSの対応サービスの違い
Bastionの立ち位置は、自前の踏み台やAWSの対応サービスと並べると輪郭がはっきりします。移行やマルチクラウドを見据えるなら、この対応関係を押さえておくと設計を横展開できます。
自前で踏み台サーバーを運用する場合と比べたマネージド化の損得
自前で踏み台VMを立てる方式は、OSやツールを自由に構成でき、初期費用も小さなVM1台分に収まる利点があります。反面、踏み台自身のパッチ適用、OSの堅牢化、アクセスログの管理、可用性の確保といった運用を継続的に背負う必要があり、設定ミスがそのまま侵入経路になりかねません。Bastionはこれらの運用をマネージドに寄せる代わりに、専用ホスト型では常時課金が発生する点が対価です。つまり「運用の手離れ・設定ミスの削減」と「常時稼働コスト」を天秤にかける判断で、管理対象VMが増えるほど、また運用体制が薄いほど、マネージド側の利点が効いてきます。VMを使う別のリモートアクセス形態としては、Azure Virtual Desktopの基本概念を解説した記事のような仮想デスクトップもあり、用途(管理接続かデスクトップ提供か)で使い分けます。
AWS Session Manager・Instance Connectとの対応
AWS中心の構成では、Azure Bastionに近い役割を、AWS Systems Manager Session ManagerやEC2 Instance Connect Endpointが担います。いずれもインスタンスにパブリックIPや踏み台を用意せず、マネージドな経路でシェルやRDP/SSHへ到達させる考え方で、Bastionと発想は共通します。細部の仕組み(エージェントの要否、認可の効かせ方、料金の課金単位)は各サービスで異なるため、Azureでの設計をそのまま持ち込むのではなく、対応する概念として捉えて各クラウドの流儀に合わせるのが実務的です。
Azure Bastionを採用すべき場面と見送るべき場面の判断
ここからは判断です。Bastionは万能ではなく、真価を発揮する場面と、別の手段に委ねるべき場面がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。
Azure Bastionの採用が合理的になる実務上の主な条件
次のいずれかに該当するなら、Bastionが第一候補になります。
- Azure上のVMからパブリックIPを外し、管理ポート(3389/22)のインターネット公開をやめたい
- 踏み台サーバーの構築・パッチ適用・監視といった運用から手を引きたい
- 複数の管理者が、VPNやクライアント側の設定なしにブラウザだけでVMへ到達したい
- ファイル転送・ネイティブクライアント接続や、監査向けのセッション記録が要件化されている(Standard/Premium)
いずれもVMを一定数抱える本番環境で効く要件で、管理対象が増えるほど、また運用体制が薄いほど、マネージド化の利点が積み上がります。特に、管理ポートを閉じて接続経路をBastion経由に一本化できる点が、長期的な攻撃面の削減につながります。
Azure Bastionを選ぶべきでない場面と適切な代替手段
一方で、次の要件にはBastionをそのまま当てはめません。第一に、対象VMが少数で接続頻度も低い小規模構成では、専用ホスト型の常時課金が割高になりやすく、無料のDeveloper SKU(開発・テスト用途)や、just-in-timeアクセスなど別方式の方が費用に見合う場合があります。第二に、AWSやGoogle Cloud中心の構成なら、Session Managerなど各クラウドのマネージドな接続手段に寄せた方が、認可とネットワークの一貫性を保ちやすいでしょう。第三に、そもそもVMを持たないコンテナ・サーバーレス主体の構成では、Bastionの前提であるVMへのRDP/SSHという接続対象が薄く、Bastionの出番自体が限られます。第四に、DeveloperSKUは1台ずつ・ピアリング非対応・限定リージョンという制約があるため、本番の同時接続や複数ネットワークには使わず、必ずBasic以上を選びます。
受託開発におけるVM管理経路の設計の勘所と外注先への早めの相談
実際のシステムでは、Bastion単体ではなく、仮想ネットワークのサブネット設計、NSGによる到達制御、SKU選定、Entra IDやKey Vaultと連携した認証・鍵管理、そして常時課金を見込んだコスト設計を一体で組む必要があります。どのネットワークにBastionを置き、どのVMへピアリングで届かせ、誰にどの経路を許すかは、可用性・監査要件・運用体制・費用のトレードオフで決まり、後からの構成変更にはネットワークの作り直しが伴います。要件定義の段階で管理経路の方針まで固めておくほど、開発後半の手戻りを避けられる設計です。Azureを含むクラウドインフラの構築・移行の相談では、Bastionを含むネットワーク・認証・セキュリティの設計から実装・運用までを一貫して支援できます。
よくある質問
Azure Bastionの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。
Azure Bastionを使うとVMのパブリックIPは不要になりますか?
不要になります。Bastionは仮想ネットワークの内側からプライベートIPで対象VMに接続するため、VM側にパブリックIPを付けず、ネットワークセキュリティグループでRDP(3389)/SSH(22)のインターネット受信を閉じたまま管理接続できる構成です。利用者はTLSで暗号化されたHTTPS(443)越しに、ブラウザやネイティブクライアントからVMへ到達します。
Developer SKUと有料SKUは何が違いますか?
Developer SKUは共有リソース上で動く無料のSKUで、AzureBastionSubnetもパブリックIPも不要な代わり、一度に1台のVMにしか接続できず、仮想ネットワークピアリングや同時接続に対応せず、提供リージョンも限られます。用途は開発・テストの一時接続です。本番で複数VMへの同時接続やピアリング越しの接続が要るなら、専用ホストを持つBasic以上を選びます。
ファイル転送やネイティブクライアント接続はどのSKUで使えますか?
Standard以上です。Azure CLIなどのネイティブクライアント接続、ファイルのアップロード/ダウンロード、共有可能リンク、IPアドレスベースの接続、カスタム受信ポートといった高度な機能は、BasicやDeveloperでは使えず、Standardまたはより上位で有効になります。監査向けのセッション記録やパブリックIPを持たないプライベートのみの構成が必要なら、Premiumを選びます。
Azure BastionとAWSの踏み台レス接続はどう対応しますか?
役割は対応します。Bastionに近い「パブリックIPも踏み台も持たずにマネージドでVMへ到達する」考え方を、AWSではSystems Manager Session ManagerやEC2 Instance Connect Endpointが担う位置づけです。発想は共通しますが、エージェントの要否や認可の効かせ方、課金の単位は各サービスで異なるため、対応概念として捉えつつ各クラウドの流儀に合わせて設計します。
Azure Bastionは接続していない間も料金がかかりますか?
専用ホスト型のSKU(Basic/Standard/Premium)では、接続の有無にかかわらずデプロイしている時間に対して時間単位の料金がかかり、これに送信データ転送料金(毎月最初の5GBは無料・2026年時点)が加わります。無料のDeveloper SKUにはこの時間課金がありません。少数VMに常時Bastionを張ると割高になりやすいため、稼働時間と接続頻度から費用対効果を見積もっておくと安全です。
関連記事
- 踏み台サーバーとは?仕組み・SSH多段接続・AWS構築と採用判断【2026年版】:Azure Bastionがマネージド化している踏み台という概念そのものを確認できます。
- Azure Key Vaultとは?シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説:Bastion接続で使うSSH鍵や資格情報の保管先として連携します。
- Azure Virtual Desktopとは何か?その基本概念と特徴を解説:VMへのリモートアクセスの別形態として、管理接続とデスクトップ提供の違いを対比できます。
- クラウドセキュリティとは?リスクと責任共有モデルから見た企業の守り方:Bastionをどこまで自社で守るかの線引きの土台になります。