Azure Virtual Network (VNet): Network Foundation for Berlin Small Business Cloud Deployments

When a small business in Berlin deploys its first Azure resources — virtual machines, databases, storage accounts — those resources need network isolation, controlled connectivity, and integration with on-premises infrastructure. Azure Virtual Network (VNet) is the foundational building block that provides all three: an isolated, customizable private network within Azure that you fully control, connected to your other infrastructure on your terms.

What a VNet Provides

An Azure VNet is logically isolated from all other Azure VNets by default — resources in your VNet cannot communicate with resources in another organization’s VNet, and Azure Internet traffic does not automatically reach resources inside your VNet unless you explicitly configure public IP addresses or load balancers.

Within a VNet, you define an address space — a private IP range in RFC 1918 space (e.g., 10.10.0.0/16) — and divide it into subnets. Each subnet serves as a logical isolation boundary: a database subnet, an application tier subnet, a gateway subnet for VPN connectivity, and a management subnet for administrative tools. Resources deployed into a subnet receive private IP addresses from that subnet’s range and can communicate with other subnets within the same VNet by default.

Subnet-Level Security with Network Security Groups

Network Security Groups (NSGs) applied to subnets enforce traffic filtering rules that control which sources can reach resources in that subnet and which destinations resources in that subnet can reach. A database subnet with an NSG that permits inbound traffic only on port 1433 from the application subnet — and denies all other inbound traffic — ensures that the database cannot be reached directly from the internet or from other subnets, even if a VM in another subnet is compromised.

This east-west segmentation — controlling traffic between subnets — is a critical defense against lateral movement in breach scenarios. A compromised web tier VM cannot reach the database tier if NSG rules explicitly block that traffic path, containing the blast radius of the initial compromise.

Hybrid Connectivity: VPN Gateway

A VNet that cannot communicate with your Berlin office network is an island. Azure VPN Gateway provides the IPsec/IKEv2 tunnel that connects your on-premises network to your Azure VNet, making Azure VMs and services appear as extensions of your local network from the perspective of routing and DNS resolution.

The VPN Gateway is deployed into a dedicated GatewaySubnet within your VNet and requires a public IP. Once the site-to-site tunnel is established, resources in Azure can reach on-premises servers by private IP and vice versa — without routing through the public internet for that traffic. For Berlin SMBs with on-premises Active Directory, file servers, or legacy applications, VPN Gateway is the prerequisite for true hybrid operation.

Eliminating Public Endpoints with Private Endpoints

Platform-as-a-service resources — Azure Storage, Azure SQL, Azure Key Vault, Azure Container Registry — are by default accessible over the public internet to anyone who authenticates. Private Endpoints assign these services a private IP address from your VNet, making them accessible only from within the VNet (or connected networks via VPN). Disabling the public endpoint entirely eliminates the attack surface: no credential stuffing, no exposure in external attack surface scans, no public DNS record resolving to a reachable endpoint.

For a Berlin SMB, deploying Private Endpoints for Key Vault and storage accounts used by production workloads is a one-time configuration that permanently removes those resources from internet exposure without impacting function for legitimate users accessing them from within the VNet or over the VPN tunnel.

North-South Traffic Inspection with Azure Firewall

Azure Firewall deployed within a VNet inspects and filters outbound traffic from Azure resources to the internet, and can be configured as the next hop for inbound traffic via User Defined Routes. For VNets where resources initiate outbound connections — downloading updates, calling external APIs, communicating with SaaS services — Azure Firewall enforces application-layer rules: allow only specific FQDNs, block all non-approved destinations, log all outbound traffic for security monitoring.

VNet Design for Berlin SMBs

A practical starting point for a Berlin small business is a single VNet (10.10.0.0/16) divided into subnets: GatewaySubnet (10.10.0.0/27) for VPN, ApplicationSubnet (10.10.1.0/24) for VMs and app services, DataSubnet (10.10.2.0/24) for databases, AzureFirewallSubnet (10.10.3.0/26) if using Azure Firewall, and AzureBastionSubnet (10.10.4.0/27) for Bastion secure VM access. NSGs on ApplicationSubnet and DataSubnet enforce segmentation. VPN Gateway in GatewaySubnet provides hybrid connectivity. Private Endpoints for Key Vault and storage provide PaaS isolation.

This VNet architecture is not a one-time configuration — it is the foundation that every subsequent Azure security control relies on. Conditional Access, Defender for Cloud recommendations, Private Endpoints, and NSG rules all assume a well-structured VNet beneath them.