Azure AZ-305 Solutions Architect Infrastructure Design

For an Azure Solutions Architect, infrastructure design is the art of translating business and technical requirements into a secure, performant, and resilient cloud solution. The AZ-305 exam tests your ability to make foundational decisions about compute, networking, migration, and high availability, balancing trade-offs between cost, complexity, and capability. This guide moves beyond service names to the critical reasoning process you must demonstrate to excel.

Mastering Compute Selection

The foundation of any workload is its compute hosting model. Your first decision is rarely about the "best" service, but the most appropriate one for the workload's characteristics: stateless vs. stateful, scalability needs, and management overhead.

For long-running, stateful, or legacy applications requiring full control over the OS and software stack, Azure Virtual Machines (VMs) are the baseline IaaS option. You are responsible for patching, security, and runtime, but you gain maximum flexibility. When you need to run server-side web applications (like ASP.NET, Node.js, or Java) without managing VMs, Azure App Service is the premier PaaS offering. It provides automatic scaling, built-in CI/CD, and handles the underlying infrastructure. For event-driven, microsecond-scale scaling with functions that execute in response to triggers (e.g., a blob upload or a message queue), Azure Functions is the serverless compute choice. You pay only for execution time, with no idle costs.

For modern applications packaged as containers, you have two primary paths. Azure Container Apps is a serverless container platform ideal for microservices and background job processing where you don't want to manage Kubernetes clusters. It handles scaling and networking automatically. For full container orchestration with advanced scheduling, service discovery, and granular control, Azure Kubernetes Service (AKS) is the enterprise-grade choice, though it carries significant operational complexity.

Exam Strategy: Expect scenario-based questions that pit these options against each other. Key discriminators include: management responsibility ("lift-and-shift" vs. "modernize"), scaling pattern (predictable vs. bursty), and runtime duration (continuous vs. seconds). A question describing a monolith with custom dependencies often points to VMs or App Service Containers, while a scenario about processing millions of IoT messages per minute screams Functions or Container Apps.

Designing Network Topologies

A well-architected network provides security, isolation, and controlled communication. The canonical pattern for enterprise connectivity in Azure is the hub-spoke virtual network architecture. In this model, a central hub virtual network contains shared services like firewalls, VPN/ExpressRoute gateways, and DNS servers. Individual workloads or environments (development, production) reside in their own spoke virtual networks, which peer directly to the hub but not to each other. This centralizes security inspection and control while isolating workloads.

Critical services reside in the hub. Azure Firewall is a stateful, cloud-native firewall-as-a-service for controlling outbound and east-west traffic using application, network, and NAT rules. For inbound HTTP/S traffic, Azure Application Gateway operates as a Layer 7 load balancer, offering features like SSL termination, path-based routing, and Web Application Firewall (WAF) protection. Virtual Network Peering connects the hub and spokes, allowing traffic to flow through the firewall.

Exam Insight: You must know when to use which service. Azure Firewall controls non-HTTP/S traffic and outbound internet access. Application Gateway/WAF protects and routes web applications. For global HTTP/S routing and acceleration, you would use Azure Front Door (covered later). A common exam pitfall is selecting a Network Security Group (NSG) when the scenario requires deep packet inspection or centralized policy—NSGs are for subnet/network interface-level rules, not application-layer filtering.

Planning Migration Strategies

Migration is a journey, not a single event. Azure provides a suite of tools to assess, migrate, and modernize. The starting point is Azure Migrate, the central hub for discovery, assessment, and migration of on-premises servers, infrastructure, applications, and data. It provides tools to analyze dependencies and generate readiness and cost assessments for both IaaS (to VMs) and PaaS (to App Service, AKS) targets.

For database migrations, the Azure Database Migration Service helps migrate databases to Azure data platform services with minimal downtime. It supports homogeneous migrations (e.g., SQL Server to Azure SQL) and heterogeneous migrations (e.g., Oracle to Azure Database for PostgreSQL). A critical enabler for any migration is establishing hybrid connectivity. This is achieved via Azure ExpressRoute for private, high-bandwidth, reliable connections or Site-to-Site VPN for secure, encrypted tunneling over the public internet.

Design Consideration: A phased approach—assess, migrate, optimize—is standard. The exam will test your ability to choose the right migration tool and connectivity method based on requirements for downtime, bandwidth, and data sensitivity. For example, a "lift-and-shift" of VMs with minimal downtime points to Azure Migrate with agentless replication over ExpressRoute, while migrating a web app to App Service might use a CI/CD pipeline instead.

Designing for High Availability and Disaster Recovery

Resilience is designed across multiple levels: within a region (availability zones) and across regions. For intra-region high availability, deploy critical VMs, AKS clusters, or PaaS services across Availability Zones—physically separate datacenters within an Azure region. For cross-region disaster recovery, you implement geo-redundancy, which often involves paired regions.

Traffic distribution is key to both performance and failover. Azure Traffic Manager is a DNS-based traffic load balancer that routes user requests to services across global Azure regions. It uses methods like priority (for failover), geographic, or weighted routing. It operates at the DNS level, so it's not suitable for SSL termination or path-based routing. Azure Front Door is a modern, scalable entry point that uses the Microsoft global edge network. It provides Layer 7 load balancing, SSL offloading, global routing, and built-in DDoS protection. Crucially, it performs active health probes to your backend endpoints and can fail over in seconds.

Critical Distinction (Exam Focus): Know the layering. Use Front Door for global HTTP/S routing, caching, and WAF at the edge. Use Application Gateway for region-specific, internal HTTP/S routing and WAF within your virtual network. Use Traffic Manager for non-HTTP/S failover scenarios (e.g., routing to a backend SQL endpoint) or when you need simple DNS-based global routing without the edge network features.

Common Pitfalls

1. Over-Engineering Compute: Choosing AKS for a simple, static website. Correction: Always start with the simplest service that meets the requirements. A static site belongs in Azure Storage static websites, not a managed Kubernetes cluster. Evaluate management overhead versus benefit.

1. Confusing Traffic Routing Services: Using Traffic Manager for SSL termination or path-based routing. Correction: Remember the layer: Traffic Manager works at DNS (Layer 4). For any HTTP/S content inspection, routing, or SSL tasks, you need a Layer 7 service like Application Gateway (regional) or Front Door (global).

1. Neglecting Hybrid Connectivity in Migrations: Planning a large database migration without considering network bandwidth and latency. Correction: Always factor in connectivity. Use Azure Migrate to assess network requirements. For large data sets, you might need an ExpressRoute circuit or even the Azure Data Box physical transfer service to seed initial data.

1. Assuming PaaS is Automatically Highly Available: Deploying an App Service plan or an Azure SQL database in a single region without configuring geo-replication. Correction: While PaaS services have built-in resilience within a region (often across zones), cross-region disaster recovery is usually a configuration you must enable and test, such as failover groups for Azure SQL.

Summary

• Compute selection is a trade-off: Choose VMs for control, App Service for web apps, Functions for event-driven tasks, Container Apps for simple containers, and AKS for full orchestration. The decision hinges on management responsibility, scalability, and workload pattern.
• Network design follows patterns: Implement a hub-spoke topology for enterprise segmentation, using Azure Firewall for centralized policy and Application Gateway for secure web traffic ingress.
• Migration is a structured process: Leverage Azure Migrate for assessment and server migration, the Database Migration Service for data, and establish reliable hybrid connectivity via VPN or ExpressRoute as a foundation.
• High availability is multi-layered: Use Availability Zones for intra-region resilience and services like Front Door (for global HTTP/S) or Traffic Manager (for DNS-based failover) to route traffic and fail over across regions.