This chapter covers Public IP Address SKUs (Basic vs. Standard) and allocation methods (Dynamic vs. Static) in Azure. Understanding these concepts is critical for the AZ-104 exam, as questions on public IP configuration appear in approximately 10-15% of networking-related items. You will learn the exact differences, use cases, and how to choose the right SKU and allocation method for your workloads.
Jump to a section
Imagine a city with two types of lanes for cars entering a highway: Basic lanes and Standard lanes. Basic lanes are like a single-lane on-ramp with no traffic light; cars just merge whenever they can, but there's no coordination—if two cars try to merge at the same time, they might crash (no SLA). The entrance is not guaranteed to be open; sometimes construction closes it without notice (zone-redundant not supported). Traffic can be heavy and unpredictable. Standard lanes, on the other hand, are like a multi-lane on-ramp with a smart traffic management system. Each lane is assigned to a different highway entrance (availability zone), so even if one entrance is blocked, cars can still enter via another (zone-redundant). The system guarantees that at least 99.99% of the time, a car will be able to merge within a few seconds (SLA). The smart system also automatically blocks traffic from sources that are causing congestion (default outbound access no longer needed). A driver can request a specific lane (availability zone assignment) to ensure they always use the same entrance. Basic lanes are free but unreliable; Standard lanes cost a small fee but provide reliability and advanced features. In Azure, Basic public IPs are like Basic lanes—no SLA, no zone support, and open to all. Standard public IPs are like Standard lanes—SLA, zone-redundant, and secure by default with explicit outbound rules.
What are Public IP Address SKUs?
Azure offers two SKUs for public IP addresses: Basic and Standard. The SKU determines the features, availability, and behavior of the public IP. The choice impacts SLA, zone redundancy, security defaults, and outbound connectivity.
Basic SKU: Default for older deployments. No SLA, no availability zone support, open by default (inbound and outbound). Supports both Dynamic and Static allocation. Can be associated with any Azure resource that accepts a public IP (e.g., VM NIC, Load Balancer, VPN Gateway).
Standard SKU: Recommended for production. 99.99% SLA (when deployed in a zone-redundant configuration), supports availability zones, secure by default (inbound traffic is blocked unless a Network Security Group allows it). Supports only Static allocation. Can be associated with resources like Standard Load Balancer, Application Gateway, or VM NIC.
Allocation Methods: Dynamic vs. Static
Allocation method determines whether the IP address changes over time.
Dynamic: The IP address is not assigned at creation time. It is allocated when the resource (e.g., VM or load balancer frontend) is started or associated. The IP can change if the resource is deallocated (stopped) and restarted. For Basic SKU, Dynamic is the default. For Standard SKU, Dynamic is not supported; only Static is allowed.
Static: The IP address is assigned immediately at creation and remains fixed until the public IP resource is deleted or its allocation method is changed. For Standard SKU, Static is mandatory. For Basic SKU, Static is optional.
How SKU and Allocation Interact
Basic + Dynamic: IP changes on VM stop/start. No SLA. No zone support. Open to all traffic.
Basic + Static: IP fixed until deletion. No SLA. No zone support. Open to all traffic.
Standard + Static: IP fixed. 99.99% SLA. Zone-redundant or zonal. Secure by default (inbound blocked).
Availability Zones and SKU
Basic SKU: Not zone-redundant. Cannot be assigned to a specific zone. If the region supports zones, a Basic public IP is not zone-aware and may become unavailable if the zone it resides in fails.
Standard SKU: Supports zone-redundancy by default (if the region supports zones). You can also pin it to a specific zone (zonal) for latency optimization or fault isolation. Zone-redundant means the IP is replicated across multiple zones, so failure of one zone does not affect reachability.
SLA (Service Level Agreement)
Basic SKU: No SLA for public IP connectivity. The IP may be unreachable at times.
Standard SKU: 99.99% SLA for public IP connectivity (when deployed in a zone-redundant configuration in a region that supports availability zones). For zonal deployments, SLA is 99.99% within that zone.
Security Defaults
Basic SKU: Inbound traffic is allowed by default. No Network Security Group (NSG) is required for inbound traffic to reach the IP. This is a security risk.
Standard SKU: Inbound traffic is blocked by default. You must explicitly create and associate an NSG with the subnet of the resource using the public IP to allow inbound traffic. This is a security best practice.
Outbound Connectivity
Basic SKU: Provides default outbound access (SNAT) to the internet for VMs without a public IP. This is being deprecated in favor of explicit outbound methods.
Standard SKU: Does NOT provide default outbound access. You must explicitly configure outbound connectivity via a Standard Load Balancer outbound rules, NAT Gateway, or a public IP on the VM.
Idle Timeout and TCP Reset
Basic SKU: Idle timeout for TCP connections is 4 minutes by default. Can be configured from 4 to 30 minutes. No TCP reset on idle timeout.
Standard SKU: Idle timeout is 4 minutes by default. Configurable from 4 to 30 minutes. Supports TCP reset on idle timeout (sends a TCP RST packet to the client when idle timeout is reached), which helps applications know the connection was terminated.
DNS Name Label
Both SKUs support DNS name labels (e.g., myapp.eastus.cloudapp.azure.com). However, for Standard SKU, the DNS label must be unique within the region.
Migration and Changing SKU
You cannot change the SKU of a public IP after creation. You must create a new public IP with the desired SKU and update the resource association. For example, to upgrade from Basic to Standard, create a new Standard public IP, update the resource (e.g., load balancer frontend) to use it, then delete the old Basic IP.
Command Examples
Create a Basic Static public IP:
az network public-ip create \
--resource-group myRG \
--name myBasicStaticIP \
--sku Basic \
--allocation-method StaticCreate a Standard zone-redundant public IP:
az network public-ip create \
--resource-group myRG \
--name myStandardIP \
--sku Standard \
--zone 1 2 3Note: --zone 1 2 3 creates a zone-redundant IP. Omitting --zone also creates zone-redundant by default. To pin to a single zone, use --zone 1.
Verification
List public IPs:
az network public-ip list --output tableShow details:
az network public-ip show --name myIP --resource-group myRGCommon Exam Scenarios
Choosing SKU for a production web application: Standard SKU for SLA, zone redundancy, and security.
Understanding that Basic SKU does not support availability zones.
Knowing that Standard SKU requires Static allocation and NSG for inbound.
Recognizing that default outbound access is not available with Standard SKU.
Identifying that idle timeout can be adjusted up to 30 minutes for both SKUs, but TCP reset is only for Standard.
Create a Standard Public IP
Use Azure CLI, PowerShell, or Portal to create a public IP with SKU Standard and allocation method Static. For example, in CLI: `az network public-ip create -g MyRG -n MyStandardIP --sku Standard --allocation-method Static`. At this point, the IP is allocated immediately and will not change. The IP is not associated with any resource yet. No traffic can reach it because Standard SKU blocks inbound by default. The IP is zone-redundant if the region supports zones, meaning it is replicated across multiple availability zones. The IP resource is created in the specified resource group and region.
Associate with a Load Balancer Frontend
Create a Standard Load Balancer and associate the public IP with its frontend IP configuration. In CLI: `az network lb frontend-ip create -g MyRG --lb-name MyLB -n MyFrontend --public-ip-address MyStandardIP`. The public IP is now the entry point for traffic to the load balancer. The load balancer will distribute traffic to backend pool members. The public IP’s idle timeout and TCP reset settings apply to connections through the load balancer. The load balancer must have a backend pool with healthy VMs to accept traffic.
Configure NSG for Inbound Traffic
Since Standard SKU blocks inbound by default, you must create an NSG and associate it with the subnet of the backend VMs. For example, allow HTTP and HTTPS from the internet: `az network nsg rule create -g MyRG --nsg-name MyNSG -n AllowHTTP --priority 100 --destination-port-ranges 80 --protocol Tcp --access Allow`. Associate the NSG with the subnet: `az network vnet subnet update -g MyRG --vnet-name MyVNet -n MySubnet --network-security-group MyNSG`. Without this, traffic hitting the public IP will be dropped at the VM level. The NSG rules must match the load balancer health probe and application ports.
Configure Outbound Connectivity
Standard SKU does not provide default outbound access. To allow VMs behind the load balancer to reach the internet, configure outbound connectivity. Options: (1) Add an outbound rule to the load balancer: `az network lb outbound-rule create -g MyRG --lb-name MyLB -n OutboundRule --frontend-ip-configs MyFrontend --protocol All --idle-timeout 4 --allocated-outbound-ports 1024`. (2) Use Azure NAT Gateway attached to the subnet. (3) Assign a public IP directly to each VM's NIC (not recommended for scale). Without this, VMs cannot initiate outbound connections.
Verify Connectivity and SLA
Test inbound connectivity by accessing the public IP from the internet (e.g., http://<public-ip>). Verify that traffic reaches the backend VMs through the load balancer. Check the NSG logs if traffic is blocked. For outbound, verify that VMs can reach external endpoints (e.g., `curl ifconfig.me` from a VM). The Standard SKU provides a 99.99% SLA when zone-redundant. Monitor the IP's health via Azure Monitor metrics and logs. If connectivity fails, check NSG, load balancer health probes, and backend pool membership.
Enterprise Scenario 1: E-commerce Web Application
A company deploys a multi-tier e-commerce application on Azure VMs behind a Standard Load Balancer. They need a public IP that is highly available and secure. They choose Standard SKU with zone-redundancy to ensure the application remains accessible even if an entire Azure datacenter fails. The public IP is associated with the load balancer frontend. They configure NSGs to allow only HTTPS (port 443) from the internet. They also set up a NAT Gateway for outbound connectivity from the backend VMs to update product inventory via third-party APIs. The Standard SKU's TCP reset feature helps quickly terminate idle connections, freeing resources. The 99.99% SLA meets their compliance requirements. Common misconfiguration: forgetting to create an NSG, causing all inbound traffic to be dropped. They use Azure Policy to enforce Standard SKU for all public IPs in production subscriptions.
Enterprise Scenario 2: Hybrid VPN Gateway
A company uses a VPN gateway to connect on-premises to Azure. The VPN gateway requires a public IP. They use Basic SKU because the VPN gateway does not support Standard SKU public IP (as of certain gateway types). They allocate a Static IP to ensure the on-premises firewall can be configured with a fixed destination IP. Since Basic SKU has no SLA, they accept the risk for non-critical connectivity. They also note that Basic SKU does not support availability zones, so they deploy the gateway in a region without zones or accept zonal risk. They monitor the gateway's health and have a failover plan. This scenario highlights that not all resources support Standard SKU; always check compatibility.
Enterprise Scenario 3: Azure App Service with Custom Domain
An App Service web app uses a custom domain. They need a public IP for the app's inbound traffic. They assign a Standard SKU public IP to the App Service (via an App Service Environment or a front-end load balancer). The IP must be Static for DNS stability. They use a zone-redundant IP for high availability. They configure the NSG on the virtual network to allow traffic from the internet. They also set up a NAT Gateway for outbound traffic from the app to external services. The Standard SKU's security default ensures the app is not exposed accidentally. They use Azure Traffic Manager to route traffic to multiple regional deployments, each with its own Standard public IP. This setup achieves global load balancing and disaster recovery.
AZ-104 Exam Focus: Public IP SKUs and Allocation Methods
Objective Codes: This topic falls under Objective 4.2: Configure and manage virtual networking, including public IP addresses. Expect 2-3 questions directly testing SKU differences, allocation methods, and scenario-based choices.
Common Wrong Answers and Why Candidates Choose Them: 1. *Choosing Basic SKU for production because it's free*: Candidates see the cost difference and think saving money is wise. Reality: Basic has no SLA, no zone support, and is insecure. Azure recommends Standard for production. The exam expects you to prioritize reliability and security over cost. 2. *Selecting Dynamic allocation for Standard SKU*: Candidates assume Dynamic is always available. Reality: Standard SKU only supports Static. Dynamic is only for Basic. This is a direct fact. 3. *Thinking Basic SKU supports availability zones*: Candidates may assume all SKUs support zones. Reality: Only Standard supports zones. Basic is not zone-aware. 4. *Assuming default outbound access exists with Standard SKU*: Candidates may think all VMs have internet access by default. Reality: Standard SKU removes default outbound. You must explicitly configure it. 5. *Believing you can change SKU later*: Candidates think they can upgrade from Basic to Standard. Reality: SKU is immutable after creation. You must create a new IP.
Specific Numbers and Terms:
Idle timeout: 4 minutes default, configurable 4-30 minutes for both SKUs.
TCP reset: Only Standard SKU supports it (sent on idle timeout).
SLA: 99.99% for Standard zone-redundant; no SLA for Basic.
Allocation: Basic supports Dynamic (default) and Static; Standard supports only Static.
Zone support: Basic none; Standard zone-redundant or zonal.
Security: Basic open by default; Standard closed by default (requires NSG).
Edge Cases and Exceptions:
Some older Azure services (e.g., some VPN Gateway SKUs) may only support Basic public IPs. Always check service documentation.
If you create a Standard public IP without specifying zones in a non-zonal region, it will be created without zone redundancy, and SLA may be lower.
Moving a Basic public IP to a different resource group or subscription is supported, but SKU remains Basic.
How to Eliminate Wrong Answers:
When a question mentions high availability, SLA, or production workload, eliminate Basic SKU answers.
When a question mentions availability zones, eliminate Basic SKU.
When a question mentions security (e.g., prevent DDoS), Standard SKU is correct due to default NSG requirement.
When a question mentions outbound connectivity from a VM, if Standard SKU is used, look for NAT Gateway or Load Balancer outbound rules in the answer.
If a question asks for a public IP that never changes, choose Static. If it can change on VM stop, choose Dynamic (Basic only).
Standard SKU is required for production workloads due to SLA and security defaults.
Standard SKU supports only Static allocation; Basic supports both Dynamic and Static.
Standard SKU blocks inbound traffic by default; Basic allows it.
Availability zones are only supported with Standard SKU.
SKU cannot be changed after creation; must create new IP.
Standard SKU does not provide default outbound access; use NAT Gateway or Load Balancer outbound rules.
Idle timeout is 4 minutes default for both SKUs, configurable 4-30 minutes; TCP reset only for Standard.
Basic SKU has no SLA; Standard SKU has 99.99% SLA when zone-redundant.
These come up on the exam all the time. Here's how to tell them apart.
Basic SKU
No SLA for connectivity
No availability zone support
Inbound traffic allowed by default
Supports Dynamic and Static allocation
Provides default outbound access (SNAT) – being deprecated
Standard SKU
99.99% SLA (zone-redundant)
Supports zone-redundant and zonal deployments
Inbound traffic blocked by default (requires NSG)
Only Static allocation supported
No default outbound access; must configure explicitly
Mistake
Basic SKU provides an SLA for public IP connectivity.
Correct
Basic SKU has no SLA. Only Standard SKU provides a 99.99% SLA (when zone-redundant).
Mistake
You can change the SKU of a public IP after creation.
Correct
SKU is immutable. You must create a new public IP with the desired SKU and update the resource association.
Mistake
Standard SKU public IPs allow inbound traffic by default.
Correct
Standard SKU blocks inbound traffic by default. You must associate an NSG with the subnet to allow traffic.
Mistake
Dynamic allocation is supported for Standard SKU.
Correct
Standard SKU only supports Static allocation. Dynamic is only for Basic SKU.
Mistake
Basic SKU supports availability zones.
Correct
Only Standard SKU supports availability zones (zone-redundant or zonal). Basic SKU is not zone-aware.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. A Standard Load Balancer requires a Standard SKU public IP for its frontend. Basic public IPs are only compatible with Basic Load Balancer. This is a common exam point: always match SKUs between load balancer and public IP.
When a VM with a Basic Dynamic public IP is deallocated (stopped), the IP address is released. When the VM is started again, a new IP is assigned. If you need a fixed IP, use Static allocation with Basic or Standard SKU.
Currently, Azure public IPs support IPv4. IPv6 public IPs are available in preview for some regions and require Standard SKU. Most exam scenarios focus on IPv4.
Standard SKU does not provide default outbound access. You must configure outbound connectivity using one of these methods: (1) Assign a Standard public IP to the VM's NIC, (2) Use a NAT Gateway on the subnet, (3) Use a Standard Load Balancer with outbound rules. The exam expects you to know these options.
Yes, you can associate a Standard public IP with a VM's NIC. The VM will then have a public IP. However, you must still configure an NSG on the subnet to allow inbound traffic if needed. Also, outbound connectivity will use the public IP's outbound rules (if any) or you may need additional configuration.
Zone-redundant means the IP is replicated across all availability zones in the region, providing resilience to zone failure. Zonal means the IP is pinned to a specific zone, which can reduce latency for resources in that zone but is not resilient to zone failure. By default, Standard public IPs are zone-redundant if the region supports zones.
Yes. Basic public IPs are free (no charge). Standard public IPs incur a cost based on the number of IPs and data processed. However, for production, the reliability and features of Standard justify the cost. The exam does not test pricing in detail, but you should know Basic is free.
You've just covered Public IP Address SKUs and Allocation Methods — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?