Build Azure Bastion host configs with SKU selection, scale units, tunneling, IP Connect, Kerberos, and NSG rules.
Build Azure Bastion host configs with SKU selection, scale units, tunneling, IP Connect, Kerberos, and NSG rules.
Required Fields
nameresourceGrouplocationskuvirtualNetwork.bastionSubnet.addressPrefixpublicIpAddress.nameOutput will appear here...Build an Azure Bastion host configuration with SKU (Basic vs Standard, where Standard unlocks scaleUnits-based horizontal scaling and features like IP Connect and Kerberos), a dedicated AzureBastionSubnet sized appropriately, and explicit NSG inbound rules for the required control-plane sources (GatewayManager, AzureLoadBalancer) that Bastion's own documentation mandates. The AzureBastionSubnet name is not cosmetic, Azure requires the subnet backing a Bastion deployment to be named exactly AzureBastionSubnet (case-sensitive) and sized /26 or larger, a differently-named or too-small subnet fails Bastion deployment outright regardless of how correct the rest of the configuration is.
No, Azure Bastion requires the subnet to be named exactly AzureBastionSubnet (case-sensitive), this is a hard platform requirement, not a naming convention suggestion, a differently-named subnet, even if otherwise correctly sized and configured, causes Bastion deployment to fail outright.
A /26 CIDR block (64 addresses) is the documented minimum, undersizing this subnet below /26 also causes deployment to fail. If you anticipate scaling scaleUnits significantly in the future, consider sizing somewhat larger than the bare minimum for headroom, though /26 is sufficient for the currently documented scaling range in most cases.
Yes, per Microsoft's documented Bastion NSG requirements, each of these serves a specific control-plane function, the Internet rule allows client HTTPS connections, GatewayManager allows Azure's own management plane to reach Bastion, AzureLoadBalancer allows health probes, and the VirtualNetwork rule on 8080/5701 allows Bastion host instances to communicate with each other for internal coordination. Omitting any of these can cause Bastion to fail to provision correctly or to behave unpredictably even if it does deploy.
The builder validates that name, resourceGroup, location, sku, virtualNetwork.bastionSubnet.addressPrefix, and publicIpAddress.name all resolve before accepting the JSON as a valid Bastion host definition, the fields Azure needs to provision the host, its dedicated subnet, and its public IP; it can't verify the subnet is actually named AzureBastionSubnet or sized /26 or larger, those platform-level requirements are only enforced at actual deployment time.
Always name the dedicated subnet exactly AzureBastionSubnet and size it at least /26, these are Azure platform hard requirements, not conventions, get either wrong and deployment fails with an error that at least names the problem clearly.
Don't try to trim the four required NSG inbound rules down to just the Internet-facing HTTPS one, the GatewayManager, AzureLoadBalancer, and internal VirtualNetwork rules serve genuine control-plane functions Bastion depends on, removing them causes subtle failures rather than an obvious block.
Standard SKU unlocks meaningfully more capability (IP Connect, Kerberos, scaleUnits, session recording) than Basic for a moderate cost increase, evaluate whether Basic's more limited feature set genuinely fits your use case before defaulting to it purely for the lower listed price.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.