Design Infrastructure Solutions — A Unit 4 Survey

This lesson provides a broad survey of the largest domain on the AZ-305 certification exam: Design infrastructure solutions. It establishes the mental model that connects four tightly coupled concerns — what runs your code (compute), how components talk to each other (application architecture), how workloads move to the cloud (migrations), and how traffic flows between everything (networking) — into a single, coherent infrastructure layer. By the end of this lesson you will understand how these four pillars support one another and where to dive deeper in the Topic- and Learning-Objective-level lessons that follow.

The Microsoft Azure Well-Architected Framework (WAF) defines five pillars: Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency. This unit maps primarily to Performance Efficiency (right-sizing compute, low-latency networking), Reliability (availability sets, zones, load balancing, geo-redundant networking), and Cost Optimization (serverless scaling, reserved instances, right-tier selection). The Cloud Adoption Framework (CAF) provides the migration methodology that Topic 3 directly implements.

Reference: Ch. 4, §§4.1–4.4, p. 139–175 of the AZ-305 exam book.

Why This Matters

Every Azure solution sits on top of infrastructure — virtual machines, containers, serverless functions, virtual networks, load balancers, and the migration path that brought the workload there. The AZ-305 exam dedicates more questions to this domain than any other because an architect who cannot choose the right compute platform, design resilient messaging, plan a migration wave, or lay out a hub-spoke network will produce solutions that are slow, fragile, and expensive. If you pass every other domain but stumble here, you will not pass the exam.

More importantly, these decisions are the hardest to reverse after production launch. Switching from an App Service to Azure Kubernetes Service six months later means rewriting deployment pipelines, rethinking scaling, and retraining operations teams. Getting compute, networking, and migration strategy right at design time is the single highest-leverage skill an Azure architect can develop. This lesson gives you the map; the Topic and LO lessons below give you turn-by-turn directions.

Prerequisites

• Azure fundamentals (AZ-900 level): Can you explain the difference between IaaS, PaaS, and SaaS and give one Azure service example of each?
• Resource hierarchy: Can you draw the management-group → subscription → resource-group → resource chain and explain why it matters for policy inheritance?
• Networking basics (TCP/IP): Can you explain what a CIDR block like 10.0.0.0/16 means and how many usable host addresses it provides?
• Identity & governance (Unit 1): Can you describe how Azure RBAC role assignments flow down the resource hierarchy?
• Data platform awareness (Unit 2): Can you name at least two Azure database services and one storage service?
• Business continuity concepts (Unit 3): Can you define RPO and RTO and explain why they influence infrastructure choices?

Learning Objectives

By the end of this unit you will be able to:

1. Evaluate compute options — VMs, containers, App Service, Functions, and Batch — and recommend the right platform for a given set of requirements.
2. Design application architectures that use messaging, eventing, caching, API management, and automated deployment to achieve loose coupling and resilience.
3. Plan migration strategies using the Cloud Adoption Framework, Azure Migrate, Azure Database Migration Service, and Azure Storage Migration tools.
4. Architect virtual networks with subnets, peering, ExpressRoute, VPN Gateway, load balancers, Azure Front Door, NAT Gateway, and network security controls.
5. Assess trade-offs across the five WAF pillars when making infrastructure decisions and justify your choices with data.
6. Integrate compute, application architecture, migration, and networking into a coherent landing-zone design.

Building Blocks

Compute platform — Analogy: choosing between renting an entire house (VM), a furnished apartment (App Service), a hotel room by the night (container instance), or a co-working hot desk billed by the minute (Functions). → Formal definition: the Azure service that executes your application code, ranging from full OS control (IaaS) to fully managed event-driven execution (serverless). → Why it matters: the compute choice determines your scaling model, operational burden, cost curve, and deployment pipeline.

Container orchestration — Analogy: a shipping port that automatically loads, unloads, and reroutes containers across docks based on demand. → Formal definition: a system — typically Azure Kubernetes Service (AKS) — that manages the lifecycle, scheduling, networking, and scaling of containerised workloads. → Why it matters: containers give you app-level isolation without VM overhead, but orchestration complexity is the trade-off.

Serverless — Analogy: a taxi that only charges you while you are riding; no parking fees, no idle engine. → Formal definition: a compute model where the cloud provider dynamically allocates and deallocates resources per request, billing only for execution time (e.g., Azure Functions, Azure Container Apps with scale-to-zero). → Why it matters: serverless eliminates capacity planning for spiky or unpredictable workloads but imposes cold-start latency and execution-time limits.

Message broker — Analogy: a post office that holds letters until the recipient picks them up, guaranteeing delivery even if the recipient is temporarily offline. → Formal definition: a service — Azure Service Bus (enterprise messaging) or Azure Queue Storage (simple queues) — that decouples producers from consumers via durable, ordered message delivery. → Why it matters: message brokers absorb traffic spikes and let components fail and recover independently.

Event-driven architecture — Analogy: a newspaper subscription — the publisher pushes new editions to subscribers the moment they are printed. → Formal definition: a pattern where components communicate via lightweight event notifications routed by Azure Event Grid or streamed through Azure Event Hubs. → Why it matters: events enable reactive, scalable systems where producers and consumers evolve independently.

Virtual network (VNet) — Analogy: a private campus LAN that you build in the cloud, with buildings (subnets), security checkpoints (NSGs), and gates to the public road (gateways). → Formal definition: an isolated network address space in Azure, subdivided into subnets, where resources communicate privately. → Why it matters: VNets are the foundation of all Azure networking — every VM, AKS node, and private endpoint lives inside one.

Hub-spoke topology — Analogy: an airport (hub) that connects many regional cities (spokes) through a single central terminal. → Formal definition: a network architecture where a central VNet (hub) contains shared services — Azure Firewall, VPN Gateway, ExpressRoute — and spoke VNets peer to the hub. → Why it matters: hub-spoke centralises security inspection and on-premises connectivity while isolating workload VNets from each other.

Cloud Adoption Framework (CAF) — Analogy: a travel itinerary that breaks a complex trip into phases — plan, book, pack, travel, arrive, settle in. → Formal definition: Microsoft's prescriptive methodology with seven phases (Strategy, Plan, Ready, Migrate, Innovate, Govern, Manage) for moving workloads to Azure. → Why it matters: the AZ-305 exam tests migration questions through the lens of CAF; skipping CAF means losing easy marks.

Deep Dive

Topic 1 — Design a Compute Solution

Azure offers a spectrum of compute platforms. The architect's job is to match application requirements to the platform that minimises operational burden without sacrificing necessary control.

[!TIP] The exam loves to test the boundary between App Service and AKS. Rule of thumb: if the team has no Kubernetes experience and the app is a single deployable unit, App Service wins. If you need fine-grained pod-level control, sidecar containers, or service mesh, choose AKS.

VM availability is governed by availability sets (fault/update domains within a single data centre) and availability zones (physically separate data centres within a region). For the highest SLA (99.99%), deploy across at least 2 availability zones behind a Standard Load Balancer.

See the Topic 1 lesson for a detailed decision tree covering every compute SKU tested on the exam.

Topic 2 — Design an Application Architecture

Once you have chosen a compute platform, the next question is: how do the pieces talk to each other? This topic covers messaging and eventing, API front-doors, caching, configuration, and automated deployment.

Messaging vs. eventing is the most-tested distinction.

[!WARNING] Do not confuse Event Grid with Event Hubs. Event Grid is a routing service (low-latency, push). Event Hubs is a streaming ingestion platform (high throughput, pull-based consumer groups). The exam tests this distinction directly.

Azure API Management (APIM) sits in front of your APIs and provides rate limiting, OAuth validation, response caching, and developer portal. For internal micro-service communication behind APIM, use the Internal VNet mode so that the gateway has a private IP.

Azure Managed Redis reduces database pressure. The exam tests tier selection: Basic (no SLA, dev/test), Standard (replication, 99.9% SLA), Premium (persistence, VNet injection, clustering), Enterprise (RediSearch, RedisBloom, active geo-replication).

See the Topic 2 lesson for worked examples of event-driven architectures, APIM policy expressions, and caching strategies.

Topic 3 — Design Migrations

Migration is not just "lift and shift." CAF defines the five Rs: Rehost (lift-and-shift), Refactor (repackage for PaaS), Rearchitect (redesign for cloud-native), Rebuild (rewrite), and Replace (adopt SaaS). The architect must assess each workload and choose the right R.

[!IMPORTANT] Azure Migrate is the single pane of glass for migration projects. Even when you use DMS for databases or AzCopy for storage, Azure Migrate tracks the overall migration project, dependencies, and assessment scores. The exam expects you to start every migration answer with Azure Migrate.

The migration workflow follows CAF phases: Assess → Migrate → Optimise → Secure/Manage. During assessment, Azure Migrate produces a readiness report, right-sizing recommendations, and monthly cost estimates for each discovered workload.

See the Topic 3 lesson for detailed migration wave planning, DMS cutover procedures, and Data Box logistics.

Topic 4 — Design Network Solutions

Networking ties everything together. An AZ-305 architect must be able to design VNets, control traffic flow, connect to on-premises, and expose services to the internet — securely.

VNet design starts with IP address planning. Azure reserves 5 addresses per subnet (network, gateway, first two DNS, broadcast). A /24 subnet gives $256 - 5 = 251$ usable addresses. Plan address spaces generously — overlapping CIDRs prevent peering.

Connectivity options:

Load-balancing decision:

Network security layers: NSGs (subnet/NIC-level L3/L4 rules) → Azure Firewall (centralised L3–L7 with threat intelligence) → Azure DDoS Protection (volumetric attack mitigation). NSGs are free; Firewall and DDoS Protection carry significant cost — the exam tests when each is justified.

See the Topic 4 lesson for subnet planning worksheets, ExpressRoute peering configuration, and Front Door routing rules.

Worked Examples

Example 1 — Easy: Single-Region Web Application

Problem: Contoso Publishing runs a content-management web app serving $50{,}000$ daily users. The team has no Kubernetes experience. They need 99.9% availability, TLS termination, and auto-scaling. Budget is moderate.

Step-by-step solution:

1. Compute: Azure App Service (Standard S2 plan) — PaaS, built-in auto-scale, no K8s overhead.
2. Networking: Application Gateway v2 with WAF — L7 load balancing, TLS termination, OWASP rule set.
3. Database: Azure SQL Database (General Purpose, 4 vCores) with zone redundancy.
4. Caching: Azure Managed Redis Standard tier for session state.
5. Deployment: Azure DevOps pipeline with staging slot swap for zero-downtime deployment.

[!NOTE] The Standard App Service plan provides 99.95% SLA. Combined with Application Gateway (zone-redundant) and Azure SQL zone redundancy, the composite SLA exceeds 99.9%. No need for multi-region at this scale and budget.

Example 2 — Medium: Multi-Region SaaS Platform with Migration

Problem: Fabrikam is migrating a three-tier application (IIS front-end, .NET middle tier, SQL Server back-end) from on-premises to Azure. They have 50 TB of data, require $<4$ hours RTO, and want to modernise the middle tier to microservices over 12 months. The front-end must serve users in North America and Europe with $<100$ ms latency.

Step-by-step solution:

1. Assess: Use Azure Migrate to discover all dependencies. The SQL Server assessment recommends Azure SQL Managed Instance (compatibility score 98%).
2. Migration wave 1 — Data: Use DMS online mode for SQL Server → Managed Instance (minimal downtime cutover). Use AzCopy for 50 TB blob migration with incremental sync.
3. Migration wave 2 — Compute: Rehost IIS front-end to App Service (Refactor R). Rehost .NET middle tier to App Service initially; plan Rearchitect to AKS in wave 3.
4. Networking: Hub-spoke topology in East US 2 (primary) and West Europe (secondary). Azure Front Door with origin groups for global HTTP routing and WAF. ExpressRoute circuits in both regions for hybrid connectivity during migration.
5. Post-migration optimise: Enable Azure Monitor Application Insights for APM. Right-size based on actual consumption data after 30 days.

[!NOTE] The phased approach (rehost first, rearchitect later) is a classic CAF pattern. It lets Fabrikam exit the data centre quickly while modernising incrementally.

Example 3 — Hard: Event-Driven IoT Platform with Global Networking

Problem: Woodgrove Bank is building an IoT platform for $100{,}000$ ATMs across 20 countries. Each ATM sends telemetry every 10 seconds, transaction events, and daily cash-level reports. Requirements: $<500$ ms event processing, 99.99% availability, data sovereignty (EU data stays in EU, US data in US), end-to-end encryption, and the ability to replay events for audit.

Step-by-step solution:

1. Ingestion: Azure Event Hubs (Premium, 16 throughput units) in each region — high-throughput streaming with Kafka-compatible endpoint. Partition by ATM region.
2. Processing: Azure Functions (Premium plan, VNet-integrated) consuming from Event Hubs. Functions route transactions to Service Bus topics for guaranteed at-least-once processing. Telemetry flows to Azure Data Explorer for near-real-time dashboards.
3. Compute orchestration: Azure Kubernetes Service for the core transaction processing microservices (fraud detection, balance reconciliation). AKS uses availability zones (99.99% SLA).
4. Networking: Azure Virtual WAN with secured hubs (integrated Azure Firewall) in 4 regional hubs (East US, West Europe, Southeast Asia, Brazil South). ATMs connect via site-to-site VPN to the nearest hub. Azure Front Door exposes the management portal globally.
5. Data sovereignty: Separate Event Hubs namespaces and storage accounts per region. Azure Policy enforces allowedLocations per subscription. Service Bus geo-disaster recovery pairs within the same geography (EU primary → EU secondary).
6. Replay/Audit: Event Hubs Capture writes every event to Azure Data Lake Storage Gen2. Retention set to 7 days on Event Hubs, indefinite on ADLS. Azure Purview catalogs the data lineage.

[!TIP] The exam may present a similar scenario and test whether you choose Event Grid or Event Hubs. At $100{,}000$ devices × 6 events/minute, you need a streaming platform (Event Hubs), not an event router (Event Grid). Event Grid excels at discrete cloud events, not sustained high-throughput telemetry.

Visual Explanations

Compute Decision Tree

Hub-Spoke Network Topology

Migration Strategy Decision Tree

Load Balancer Selection

Availability Zone Architecture (TikZ)

Figure: A zone-redundant deployment across three availability zones. The Standard Load Balancer distributes traffic to healthy instances regardless of which zone experiences a failure, achieving a 99.99% composite SLA.

Messaging vs. Eventing Comparison

Common Mistakes

❌ Myth: Azure Kubernetes Service is always better than App Service because it is more flexible. ✅ Reality: AKS introduces significant operational complexity — cluster upgrades, node pool sizing, network plugin configuration, RBAC for the Kubernetes API. For a single web app with a small team, App Service delivers faster time-to-market at lower total cost of ownership. Why it's tricky: Candidates confuse capability with suitability. AKS can run a simple web app, but that does not mean it should.

❌ Myth: Event Grid and Event Hubs are interchangeable because both handle events. ✅ Reality: Event Grid is a routing service for discrete events (resource created, blob uploaded). Event Hubs is a streaming platform for high-volume telemetry. Choosing Event Grid for IoT at $100{,}000$ events/second would overwhelm it; choosing Event Hubs for a simple "blob created → trigger function" workflow is overkill. Why it's tricky: The word "event" appears in both names, and both can trigger Azure Functions, so the surface-level behaviour looks identical.

❌ Myth: VNet peering is transitive — if VNet A peers with VNet B and VNet B peers with VNet C, then A can reach C. ✅ Reality: VNet peering is not transitive. A cannot reach C unless A also peers directly with C, or traffic is routed through an NVA/Azure Firewall in VNet B with user-defined routes (UDRs). This is exactly why hub-spoke works: every spoke peers with the hub, and the hub's firewall forwards inter-spoke traffic. Why it's tricky: On-premises networks are typically flat and transitive, so candidates assume Azure peering works the same way.

❌ Myth: Azure Migrate is only for VMs. ✅ Reality: Azure Migrate includes integrated tools for web app migration (App Service Migration Assistant), database migration (DMS integration), and data migration. It is the unified migration hub, not just a VM mover. Why it's tricky: Early versions of Azure Migrate were VM-only, and many study guides still describe it that way.

Practice Exercises

🟢 Easy — Exercise 1: Compute Selection

A startup wants to deploy a single Python Flask API. The team has 2 developers, no DevOps engineer, and traffic is expected to be 500 requests per hour. Which compute platform would you recommend and why?

▶💡 Hint

Think about operational overhead and team size. Does the startup need container orchestration?

▶✅ Solution

Azure App Service (Basic B1 plan). The team is too small for AKS overhead, traffic is low enough for a single instance, and App Service provides built-in TLS, custom domains, and deployment slots. Azure Functions (Consumption) is also viable, but a Flask API maps more naturally to an always-on App Service.

🟢 Easy — Exercise 2: Peering Basics

You have VNet-A ($10.1.0.0/16$) peered to VNet-Hub ($10.0.0.0/16$), and VNet-B ($10.2.0.0/16$) also peered to VNet-Hub. Can a VM in VNet-A communicate directly with a VM in VNet-B? What do you need to enable if communication is required?

▶💡 Hint

Recall the transitivity rule for VNet peering.

▶✅ Solution

No — VNet peering is non-transitive. VNet-A cannot reach VNet-B through VNet-Hub by default. To enable communication: deploy Azure Firewall (or an NVA) in VNet-Hub, create UDRs on VNet-A and VNet-B subnets pointing to the firewall's private IP, and enable "Allow forwarded traffic" on both peering connections.

🟡 Medium — Exercise 3: Migration Strategy

Contoso has a legacy .NET Framework 4.5 application running on Windows Server 2012 R2 with a SQL Server 2014 back-end. They want to move to Azure with minimal code changes and less than 4 hours of downtime. What migration strategy and tools would you recommend?

▶💡 Hint

Consider the "five Rs" and which R minimises code changes. Think about DMS online mode for the database.

▶✅ Solution

Strategy: Rehost (lift-and-shift) for the app tier; Refactor for the database. Use Azure Migrate to assess the workload. Migrate the .NET app to Azure App Service using the App Service Migration Assistant (it supports .NET Framework 4.5). Migrate SQL Server 2014 to Azure SQL Managed Instance using DMS online mode (continuous replication with a final cutover < 1 hour). Managed Instance supports full SQL Server compatibility, avoiding code changes.

🟡 Medium — Exercise 4: Messaging Design

An e-commerce platform needs to decouple its order service from its payment, inventory, and shipping services. Order processing must be exactly-once with FIFO ordering per customer. Which messaging service and configuration would you choose?

▶💡 Hint

Think about which Azure messaging service supports sessions for ordered delivery.

▶✅ Solution

Azure Service Bus Premium tier with sessions enabled. Set the session ID to the customer ID, guaranteeing FIFO per customer. Use a topic with 3 subscriptions (payment, inventory, shipping) so each service processes the order independently. Premium tier provides dedicated resources, message size up to 100 MB, and VNet integration. Event Grid would not work here because it lacks ordering guarantees.

🔴 Hard — Exercise 5: Global Landing Zone Design

Woodgrove Financial is deploying a global SaaS platform across 3 regions (East US, West Europe, Southeast Asia). Requirements: hub-spoke networking per region, ExpressRoute from their London and New York offices, global HTTP load balancing with WAF, inter-region spoke-to-spoke communication blocked, and centralised egress through the hub's firewall. Design the networking architecture.

▶💡 Hint

Think about Azure Virtual WAN vs. manual hub-spoke, and which load balancer operates at the global layer.

▶✅ Solution

Use Azure Virtual WAN (Standard tier) with 3 secured virtual hubs (integrated Azure Firewall in each region). Connect the London office via ExpressRoute to the West Europe hub and New York via ExpressRoute to East US hub. Virtual WAN provides automatic any-to-any connectivity between hubs, but configure Azure Firewall routing intent to force all inter-spoke traffic through the hub firewall — then apply deny rules for spoke-to-spoke across regions. Use Azure Front Door (Premium) as the global HTTP entry point with WAF policies, origin groups pointing to the regional App Service / AKS endpoints. Front Door handles failover if an entire region goes down. All internet egress from spokes routes through the hub's Azure Firewall via default route propagation.

🔴 Hard — Exercise 6: Compute Modernisation Wave Plan

Fabrikam has 200 VMs on-premises: 120 are IIS web servers (identical config), 50 are .NET middle-tier services (various versions), 20 are legacy C++ batch processors, and 10 are SQL Server instances. Design a 3-wave migration plan, choosing the right compute target for each group.

▶💡 Hint

Group by migration complexity. Wave 1 should be the lowest risk. Consider which workloads can move to PaaS and which must stay as IaaS.

▶✅ Solution

Wave 1 (lowest risk): Rehost 120 IIS web servers to Azure App Service using the App Service Migration Assistant. Identical config means high automation potential. Simultaneously migrate 10 SQL Servers to Azure SQL Managed Instance via DMS online mode.

Wave 2 (moderate complexity): Refactor 50 .NET middle-tier services. Assess each for .NET version compatibility. Services on .NET 6+ → containerise and deploy to AKS. Services on .NET Framework 4.x → deploy to App Service (Windows) or rehost to VMs if dependencies require OS-level access.

Wave 3 (specialised): Rehost 20 C++ batch processors to Azure Batch (custom VM images with the C++ runtime). These require OS-level control and are compute-intensive, making Batch the natural fit with auto-scaling node pools.

Use Azure Migrate as the project hub across all three waves, tracking dependencies and readiness scores.

Summary & Concept Map

• Compute selection is the first infrastructure decision: match the workload's control needs, scaling pattern, and team skill to the right platform (VMs → App Service → AKS → Functions → Batch).
• Application architecture determines how components communicate: use Service Bus for reliable messaging, Event Grid for reactive events, Event Hubs for high-throughput streaming, APIM for API governance, and Redis Cache to reduce latency.
• Migration strategy follows CAF's five Rs: Rehost, Refactor, Rearchitect, Rebuild, Replace. Azure Migrate is always the starting point, with DMS for databases and AzCopy/Data Box for bulk data.
• Networking is the connective tissue: VNets with hub-spoke topology, NSGs for micro-segmentation, Azure Firewall for centralised inspection, and the right load balancer (L4 regional, L7 regional, L7 global, DNS-based).
• Availability zones are the go-to for high availability (99.99% SLA) within a single region; multi-region deployment adds disaster recovery.
• WAF pillars (Reliability, Security, Cost, Operational Excellence, Performance) are the lens through which every infrastructure decision should be evaluated.
• The four topics in this unit are deeply interdependent: you cannot choose compute without considering networking, you cannot plan migration without knowing the target compute and network, and application architecture patterns (messaging, caching) shape both compute and network requirements.

Connections & Next Steps

This Unit 4 survey connects to the rest of the AZ-305 curriculum as follows:

1. Topic 1: Design a compute solution — deep-dives into VM sizing, App Service plans, AKS architecture, Functions hosting plans, and Batch pools. Start here if you need to master the compute decision tree.
2. Topic 2: Design an application architecture — covers messaging patterns, APIM policies, Redis caching tiers, Azure App Configuration, and CI/CD pipeline design. Start here if your workload involves multiple communicating services.
3. Topic 3: Design migrations — walks through CAF methodology, Azure Migrate assessments, DMS online/offline modes, and Data Box logistics. Start here if you are planning an actual migration project.
4. Topic 4: Design network solutions — covers VNet design, subnetting, hub-spoke, ExpressRoute, VPN Gateway, NSGs, Azure Firewall, and load-balancer selection. Start here if networking is your weakest area.

Cross-unit connections: Unit 1 (identity and governance) provides the RBAC and Policy foundation that secures the infrastructure designed here. Unit 2 (data platform) supplies the databases and storage accounts that your compute workloads connect to. Unit 3 (business continuity) defines the RPO/RTO targets that drive your availability zone, multi-region, and backup decisions.

Real-World Applications

Case Study 1: Global Retail Platform Migration (Contoso Retail)

Contoso Retail operates 300 stores across North America and Europe with an on-premises e-commerce platform handling 2 million orders per month. They migrated to Azure over 6 months using a 4-wave CAF plan: Wave 1 rehosted the 80 web front-end VMs to App Service. Wave 2 migrated 15 SQL Server instances to Azure SQL Managed Instance using DMS online mode (average cutover time: 45 minutes per database). Wave 3 rearchitected the order-processing monolith into 8 microservices on AKS with Service Bus for inter-service messaging. Wave 4 deployed Azure Front Door for global load balancing and Azure Front Door Standard for static assets, reducing page-load times from $3.2 seconds to $0.8 seconds. Post-migration, compute costs dropped 35% through reserved instances and auto-scaling, while availability improved from 99.5% to 99.97%.

Case Study 2: Financial Services Hub-Spoke Network (Woodgrove Bank)

Woodgrove Bank needed to connect 12 Azure subscriptions (one per business unit) to their 3 on-premises data centres while meeting regulatory requirements for network segmentation. They deployed a hub-spoke topology using Azure Virtual WAN with 2 secured hubs (East US, West Europe). Each business unit has its own spoke VNet peered to the regional hub. ExpressRoute (Global Reach enabled) provides 10 Gbps private connectivity from London and New York. Azure Firewall in each hub enforces micro-segmentation — the trading desk spoke cannot communicate with the HR spoke, but both can reach shared services (DNS, Active Directory) in the hub. Azure DDoS Protection Standard covers all public-facing endpoints. The architecture reduced their network operations team's incident response time from 4 hours to 20 minutes through centralised logging in Azure Monitor.

Case Study 3: IoT Fleet Telemetry Platform (Adatum Logistics)

Adatum Logistics deployed $50{,}000$ GPS trackers on delivery vehicles across 8 countries. Each device sends location and engine telemetry every 15 seconds — $3.3 million events per minute at peak. They chose Event Hubs (Dedicated tier) for ingestion, partitioned by geographic region. Azure Stream Analytics processes the events in near-real-time, triggering Azure Functions for geo-fence alerts via Event Grid. Historical data flows to Azure Data Explorer for fleet analytics dashboards. The compute layer runs on AKS with KEDA (Kubernetes Event-Driven Autoscaling) scaling pods based on Event Hubs lag. Networking uses Azure Virtual WAN with 4 regional hubs and ExpressRoute to their central operations centre. The platform processes 99.998% of events within the 500 ms SLA, and the event-replay capability (Event Hubs Capture → Data Lake) has been used 3 times for regulatory audits.