A finance API runs in a spoke VNet without public IP addresses and calls Azure SQL, Key Vault and a partner’s public SaaS endpoint. The network team installs private endpoints for SQL and Key Vault, disables public access, and announces that the application is private. The next deployment fails because the custom DNS resolver still returns the public SQL address. Meanwhile the partner SaaS call continues to leave through an unreviewed NAT path. A private subnet, a private endpoint, DNS and outbound policy solve distinct problems; all must be designed together.
For Microsoft AZ-305, network architecture includes internet reachability, on-premises connectivity, network optimization, security, load balancing and routing. The existing hub-and-spoke network article explains overall topology. This focused guide examines endpoint and name-resolution behavior for private Azure PaaS access, along with deliberate outbound connectivity and evidence that one service cannot bypass the intended network boundary.
Draw the actual caller-to-service path
For each dependency, write the source subnet and identity, requested DNS name, resolved address, route, network appliance, destination endpoint and resource authorization. “Database is private” is not testable until these facts are known. A service hostname resolving to a public IP may be reachable through a public path even though the compute instance itself has no public address. Conversely, a private IP alone does not establish that an authenticated SQL query is allowed.
Separate the packet path from the service permission path. A connection can fail on DNS, user-defined routes, security groups, Azure Firewall, the private endpoint’s approval state, or service RBAC. Changing role assignments to repair a DNS problem weakens security and does not fix the actual failure. Trace the stack from name to wire to identity, preserving evidence at each layer.
Understand private endpoints and Private Link scope
Azure Private Link allows supported services to be reached through private endpoints within a VNet, subject to service-specific settings. The private endpoint is a network interface with a private IP; it does not create a generalized private route to every Azure service. The Private Link overview explains the service-consumer relationship and approval model.
A private endpoint may allow access to an Azure SQL logical server, a Key Vault or a supported storage subresource, but details differ. Blob and file services can use distinct private endpoint subresources, for example, so enabling one does not necessarily cover every API an application uses. Inventory the exact services and DNS zones needed before turning off public network access.
Make private DNS part of the deployment contract
Private endpoint integration typically depends on DNS mapping the usual service hostname through appropriate privatelink zones to the endpoint address where supported. Resolve the hostname from the actual application subnet, not from an administrator’s laptop on a different network. A custom DNS server, forwarding rule, or split-horizon namespace can override expected resolution and quietly return a public destination.
Hybrid DNS complicates the path because on-premises clients may need a conditional forwarder or Azure DNS Private Resolver endpoints to reach private names. The hybrid connectivity discussion gives circuit context; the added design task is to make sure DNS queries reach the resolver that knows the intended private record. Test the same service name from application VNet, on-premises, and recovery VNet if all three are authorized consumers.
Avoid assuming VNet peering makes endpoint access automatic
Peered VNets can exchange traffic under compatible routing and security rules, but private endpoint placement, DNS zone linking and policies still matter. An organization might centralize selected endpoints in a shared services VNet or place them near each workload. Centralization can reduce duplication but introduce shared-failure and DNS complexity. Distributed endpoints can improve isolation but add operational objects and charges.
Choose the topology from workload ownership, trust boundaries, region, throughput, DNS control and total cost. A shared endpoint reachable from every spoke may be a less secure default than scoped endpoints for regulated data. Conversely, a company with hundreds of small apps may find standard shared patterns easier to govern if access permissions remain correctly separated.
Distinguish service endpoints from private endpoints
Azure virtual network service endpoints and Azure Private Link represent different architectures. Service endpoints can extend VNet identity into supported Azure services while the destination remains on the service’s public endpoint model; private endpoints provide a private IP interface for supported private-service access. They differ in DNS, on-premises reachability, policy and pricing implications.
Do not replace a functioning private endpoint with a service endpoint simply because both appear in a list of network security options. Assess whether the requirement specifically forbids public endpoints, requires private inbound service addresses, needs hybrid access, or depends on service-specific firewall semantics. The exact requirement should determine the choice.
Design outbound traffic deliberately
A private application may still need package updates, payment processors and SaaS APIs that are not exposed through Azure private endpoints. Consider NAT Gateway, Azure Firewall, proxy services, or other supported egress patterns based on destination policy, predictable source IP, traffic volume and inspection requirements. NAT translates outbound connections; it does not decide whether a destination is trusted. Define the permitted destinations and where filtering occurs.
A multi-zone application using centralized egress should consider the shared service’s availability, route symmetry and throughput. User-defined routes that funnel every packet through one inspection appliance can create a regional-looking outage when that appliance fails. Where supported, choose zone-redundant or appropriately resilient services and test failure. Architecture should not infer redundancy from the fact that the egress component is managed.
Keep authorization after private connectivity succeeds
A private endpoint does not grant a workload permission to query a database, read a secret or download a blob. Use managed identities or appropriate Microsoft Entra authentication where supported and apply narrow resource permissions. Test a legitimate principal and a deliberately unauthorized one from the same private network. If both succeed, the resource permission boundary needs investigation; if both fail, begin with network or policy evidence.
The Azure governance and RBAC article provides the platform permission model. Apply it alongside service-specific data-plane roles and endpoint configuration. Auditing should identify the principal and resource rather than treating all requests from a private CIDR as fully trusted.
Test one change at a time with evidence
In a lab, create a private storage or SQL endpoint, link the needed private DNS zone, and verify the name resolves to the intended private address from the workload. Deny the test identity and confirm authorization fails even though TCP connects. Then remove the DNS association in a controlled environment to produce a different failure. Capture routes, DNS answers, endpoint connection state and request results before restoring the intended setup.
For cost, compare per-endpoint charges where applicable, egress via NAT, cross-VNet transfer and centralized inspection overhead. A design that sends high-volume storage traffic through expensive shared egress when direct private access is suitable may fail its efficiency target. AZ-305 network architecture is complete when DNS, route, access and outbound paths are documented and proved independently—not when a diagram contains a blue lock icon.