3. Intelligent Routing and Network Segmentation Strategies
AWS VPC & Azure Virtual Network Security Configurations
In today’s cloud-driven landscape, network security is the invisible shield around our resources. Both AWS and Azure offer virtual private networks (AWS Virtual Private Cloud and Azure Virtual Network) that isolate your cloud resources. However, the tools and models they use have important differences. This article walks through those differences (focusing on firewalls, routing tables, and network ACLs) and shows how to build isolated networks step by step. We’ll also touch on emerging AI techniques for smarter routing and anomaly detection, and even how Kubernetes fits into cloud networking. Our target readers (cloud architects, security and DevOps pros) will gain a deep, practical understanding of how to secure AWS and Azure virtual networks.
Virtual Network Architecture: AWS VPC vs. Azure VNet
Both AWS and Azure let you carve out private address spaces in the cloud. AWS VPC and Azure VNet each give you full control over IP ranges, subnets, and gateways. One core difference is how subnets relate to availability zones: AWS subnets are tied to a single Availability Zone, whereas Azure subnets are regional and can span zones. In practical terms, an Azure VM can move between zones without changing its IP, simplifying failover.
Each platform also handles security placement differently. AWS uses Security Groups (stateful, instance-level) plus Network ACLs (stateless, subnet-level). Azure, by contrast, relies mainly on Network Security Groups (NSGs) which are stateful and can apply to either subnets or individual network interfaces. (Azure also has Application Security Groups to group VMs, and an optional Azure Firewall, discussed below.) In short, AWS employs a split model, instance firewalls vs subnet ACLs, while Azure’s network filter is uniformly stateful and more flexible in placement.
Firewalls and Traffic Filters: AWS vs. Azure
AWS Security Groups (SGs) act as virtual firewalls on instances. They are stateful: if you allow inbound traffic on port 80, the outbound response is automatically allowed. By contrast, AWS Network ACLs (NACLs) are stateless, operating at the subnet level. Each NACL has separate inbound and outbound rules, and return traffic must be explicitly allowed by rules. Every AWS subnet must be associated with a NACL (by default the “default” NACL). NACLs evaluate rules in priority order, allowing or denying packets at the subnet border. For example, if a NACL denies all inbound traffic on a subnet, no instances in that subnet can be reached from outside, unless explicitly permitted by a rule.
AWS also offers AWS Network Firewall, a managed stateful firewall service for VPCs. This appliance-style firewall uses Suricata and lets you define deep-packet-inspection rules. You can place it in your VPC by reconfiguring your route tables to direct traffic through the firewall endpoints. In effect, Network Firewall can enforce additional filtering (intrusion detection/prevention, threat lists, domain filtering, etc.) on traffic entering or leaving a VPC.
On the Azure side, Network Security Groups (NSGs) are the primary traffic filters. An NSG contains rules that explicitly allow or deny inbound/outbound traffic between Azure resources. Because NSGs are stateful, you need only an allow rule in one direction to permit a return flow (much like AWS SGs), there is no need to create a separate “return-traffic” rule. Azure’s default NSG rules already include broad allowances and denies: for example, a default “DenyAllInbound” rule (priority 65500) blocks all inbound Internet traffic unless an earlier rule permits it. This means that by default, an Azure VM is isolated from internet traffic until you explicitly open ports.
For more advanced perimeter protection, Azure provides Azure Firewall, a fully managed, cloud-native, stateful firewall service. Azure Firewall features built‑in high availability and cloud-scale throughput. It inspects both north-south (internet) and east-west (between subnets) traffic, and can enforce policy with both network and application rules. Azure Firewall taps into Microsoft threat intelligence feeds to block malicious IPs/domains. The Premium SKU even includes signature-based IDS/IPS. In practice, you might deploy Azure Firewall in a designated “hub” subnet (often called a firewall subnet) and route traffic from other subnets through it for centralized inspection.
Key comparison: AWS provides instance-level (SG) and subnet-level (NACL) filters; Azure NSGs can cover either level. AWS Security Groups only allow traffic (no explicit “deny” rules), whereas Azure NSGs allow both allow- and deny-type rules. AWS NACLs are stateless (you must mirror rules for both directions), but Azure NSGs (like AWS SGs) are stateful. AWS’s managed firewall (Network Firewall) is similar in role to Azure Firewall, but they differ in implementation details (AWS is layered on VPC traffic via route changes, Azure is a central service integrated via Virtual WAN or route tables). In summary, both clouds let you build multiple layers of defense (host firewall, subnet firewall, network appliance), but the components and naming are not identical.
Routing and Connectivity: VPC vs VNet
Routing tables in AWS and Azure let you steer network traffic. In AWS, each VPC has main and custom route tables. A route table contains rules (destination CIDR → target) that control where traffic goes from each subnet. For example, a public subnet’s route table might send 0.0.0.0/0 (all internet traffic) to an Internet Gateway (IGW). Private subnets might send 0.0.0.0/0 to a NAT Gateway instead. AWS also has specialized targets like VPC peering, Virtual Private Gateway (for VPN) and AWS Transit Gateway for hub-and-spoke architectures.
In Azure, the equivalent concept is user-defined routes (UDRs) attached to subnets. Azure creates default system routes (for VNet address space, Internet, Azure infrastructure) but you can override or augment them with UDRs. For instance, to force traffic from a subnet through a Network Virtual Appliance or Firewall, you’d add a UDR pointing 0.0.0.0/0 to that NVA’s IP. Azure also has Virtual WAN and Virtual Network Manager which can automate complex routing.
One noteworthy difference: AWS route tables and Azure UDRs both accomplish the same goal of directing traffic, but AWS requires each subnet to be in one Availability Zone, whereas Azure subnets are zone-independent. Thus, an AWS route table attaches to subnets that are AZ-bound, while an Azure UDR can apply to a subnet spanning zones.
In both clouds, isolation often hinges on routing. If a subnet’s route table has no route to an Internet Gateway or VPN, that subnet is cut off from outside networks. Using private-only CIDRs and avoiding default Internet routes is a common pattern. Likewise, using peering or VPN/ExpressRoute connections with carefully crafted routes keeps traffic internal. By customizing routes and targets, you isolate segments (for example, sending subnet traffic through a firewall instead of letting it go straight to the Internet).
Network Access Control Lists vs. Azure NSGs
We’ve already discussed AWS NACLs briefly – they are a core VPC feature for subnet-level control. NACL rules are allow or deny filters evaluated in numeric order. Because NACLs are stateless, you always create companion rules for reply traffic. A default NACL allows all inbound and outbound traffic (if you don’t add rules), but any custom NACL starts with a default “deny all” until rules open ports.
Azure does not have a separate “stateless ACL” object for VNets in the same way. Instead, NSGs fulfill the role of filtering, with the twist that they are stateful. You associate NSGs with subnets or NICs (or both), and the rules inside an NSG determine what flows. Because NSGs are stateful, an allowed inbound flow automatically permits the response, as noted earlier.
Azure also has default deny rules built in NSGs. For instance, any NSG has default rules that allow VNet-to-VNet traffic and deny all other inbound by default. This is conceptually similar to having a NACL that denies everything unless specified. You can then add custom rules to permit needed traffic. Application Security Groups (ASGs) let you group VMs in Azure; these groups can be used as source/destination in NSG rules, simplifying management.
Example: Isolating a Network in AWS (Step-by-Step)
Let’s walk through a typical isolation example in AWS. Imagine you want a public-facing subnet and a private subnet within a VPC:
Create a VPC with a CIDR (e.g. 10.0.0.0/16).
Create subnets: e.g. PublicSubnet (10.0.1.0/24) in AZ-a, PrivateSubnet (10.0.2.0/24) in AZ-b.
Attach an Internet Gateway (IGW) to the VPC. Update the main route table to route 0.0.0.0/0 to the IGW. This makes any subnet associated with this table “public”.
Create a NAT Gateway in the public subnet (with an Elastic IP) for outbound Internet from the private subnet.
Route tables: Associate the public subnet with the main route table (which sends 0.0.0.0/0 to IGW). Create a custom route table for the private subnet, routing 0.0.0.0/0 to the NAT Gateway (no direct IGW route). Associate the private subnet with this route table.
Network ACLs: By default, both subnets use the VPC’s default NACL (which allows all traffic). To isolate further, create a custom NACL for the private subnet. In that NACL add inbound rules allowing necessary traffic from known sources (e.g. allow VPC internal range and NAT gateway) and deny all else. Similarly adjust outbound rules. Remember NACLs are stateless, so every desired flow needs both inbound and outbound “allow” rules. For example, to let internal VPC traffic out, you might allow outbound to 10.0.0.0/16 with the return flow covered by a matching inbound rule.
Security Groups: Launch instances in each subnet. Attach a Security Group to each instance (SG is stateful). For the public subnet’s server (e.g. a web server), add an SG rule allowing HTTP/S inbound from 0.0.0.0/0 and allowing all outbound. For the private subnet’s server (e.g. a database), use an SG that only allows inbound from the web server’s SG (or IP range) and blocks inbound 0.0.0.0/0. Because SGs are stateful, responses don’t need explicit rules.
Verify isolation: The web server can talk to the internet (via IGW) and to the database (via the private subnet). The database cannot be reached from the internet (no IGW route and SG blocks it). Instances in the private subnet can initiate outbound traffic through the NAT but cannot be publicly addressed.
These steps use AWS’s layering: public vs private subnets defined by route tables, with NACLs and SGs reinforcing the isolation. Remember that each subnet must have an NACL associated, so customizing them is key. An Admin could also deploy a firewall instance in the public subnet and force all traffic from private to go through it by adjusting the private subnet’s route to point to the firewall’s ENI.
Example: Isolating a Network in Azure (Step-by-Step)
Now, let’s do a similar pattern in Azure:
Create a Virtual Network (VNet) with a range (e.g. 10.1.0.0/16).
Define subnets within the VNet: a Public-Subnet (10.1.1.0/24) and a Private-Subnet (10.1.2.0/24). Subnets in Azure can span AZs by design.
Deploy an Azure Firewall or NAT if needed. If using a NAT Gateway, associate it with the Private-Subnet to allow outbound internet access. Alternatively, an Azure Firewall would be in a separate “AzureFirewallSubnet” and require UDRs.
Routing: By default, VNet routing allows all internal traffic and sends the internet-bound traffic to the Internet. To create a “private” segment, create a User-Defined Route Table and set a route 0.0.0.0/0 to the NAT Gateway or Firewall for the Private-Subnet. Apply this route table to the Private-Subnet. This ensures Private-Subnet VMs use NAT/firewall for outbound. For the Public-Subnet, you can leave the default route or explicitly route to Internet.
Network Security Groups (NSGs): Azure associates NSGs at the subnet or NIC level. Create an NSG for each subnet. For Public-Subnet NSG, add inbound rules to allow specific traffic (e.g. allow TCP 80/443 from Internet Service Tag) and possibly outbound rules as needed. For Private-Subnet NSG, you might have a default “DenyAllInbound” in place (deny all from Internet) and add rules to allow only traffic from the public subnet or trusted IPs. By default, Azure already has a rule to allow all VNet traffic. Attach the Public-Subnet NSG to Public-Subnet, and the Private-Subnet NSG to Private-Subnet.
Virtual Machines: Deploy a VM in the Public-Subnet (e.g. a web server) and one in Private-Subnet (e.g. a database). Their NICs inherit the subnet NSG rules. Optionally, tighten security by also associating NSGs to individual NICs.
Verify isolation: The public VM can receive internet traffic (subject to NSG rules) and can reach the private VM (default allows VNet traffic). The private VM cannot be reached from the Internet (its NSG “DenyAllInbound” blocks it) and any outbound traffic goes through the Azure NAT/Firewall as per routing.
Azure’s defaults help a lot here: every new NSG includes rules that allow inter-subnet (VNet) traffic and only permit Internet traffic if you explicitly allow it. Thus, by default your private subnet is already isolated from the Internet until you add an inbound rule. This makes step-by-step configuration more straightforward than AWS in some ways – less reliance on manual ACL rules.
AI and Anomaly Detection in Cloud Networks
Modern clouds are integrating AI/ML into network security. For example, AWS GuardDuty is a managed threat detection service that continuously analyzes VPC Flow Logs, CloudTrail logs, and DNS logs using machine learning and anomaly detection. GuardDuty can spot unusual API calls or traffic patterns (e.g. port scanning within a VPC) that deviate from your normal baselines. When it detects an anomaly or malicious activity, it generates findings for you to act on. In practice, enabling GuardDuty (and its AWS-Managed ML models) can automatically flag if a new subnetwork suddenly talks to a known malicious IP, or if an instance appears to be exfiltrating data.
On Azure, Azure Sentinel and Microsoft Defender for Cloud play a similar role. Sentinel’s UEBA (User and Entity Behavior Analytics) uses ML to find anomalies across network and log data. Defender for Cloud can ingest Network Watcher flow logs and apply analytics (using threat intelligence and ML) to detect unusual traffic. Additionally, Azure Traffic Analytics (built on Network Watcher) uses cloud-scale log analytics to surface network hotspots and potential misconfigurations, and can feed into ML pipelines. While Azure’s documentation doesn’t single out a single “anomaly detection” label for VNets as prominently as GuardDuty, the combination of these services effectively applies AI to network telemetry.
Regarding intelligent routing, the clouds also leverage data. For instance, AWS Route 53 (DNS service) offers routing policies (latency-based, geolocation) that could be considered a form of “intelligent” traffic steering, though not strictly AI-driven. Similarly, Azure Traffic Manager and Front Door optimize web traffic routes globally (based on performance metrics). One can imagine combining real-time network monitoring with machine learning to predict congested paths or preemptively adjust VNet peering routes, though such features are still emerging. In short, AI in cloud networking today mainly helps with security analytics (anomaly detection, threat intel), while “AI-based routing” is more about sophisticated policy engines and analytics that are evolving.
Kubernetes Networking and Cloud VNets
Containers add another layer of networking on top of VPCs/VNets. In AWS EKS or Azure AKS, the Kubernetes nodes live in your cloud subnets, and Pods get IPs either from the VPC/VNet CIDR or a secondary range. To isolate workload traffic inside Kubernetes, you use Kubernetes Network Policies. A NetworkPolicy (declared in YAML) can whitelist which Pods or external IPs can talk to a given Pod. For example, you might label database pods with and frontend pods , and write a policy that only allows traffic to from pods with . This policy enforces a micro-segmentation layer inside the cluster. These Kubernetes-level policies complement the cloud’s VPC isolation: even if your subnets allow broad traffic, a NetworkPolicy can lock down Pod-to-Pod communication.
If needed, you might configure something like this (in conceptual terms):
Define a NetworkPolicy in YAML that selects the DB pods and allows ingress only from pods with the “frontend” label on port 3306. All other ingress to DB pods is denied by default. This policy is deployed to the cluster’s network plugin (for instance, Azure CNI with Calico or AWS CNI with Calico) and enforces the rules at the virtual NIC level for Pods.
No matter whether it’s AWS or Azure, the Kubernetes CNI plugin integrates with the underlying cloud networking. For example, Azure’s advanced networking (Azure CNI) lets Pods have IPs in the VNet, so NSGs and routing policies can even apply to Pod traffic. On AWS, EKS with Calico can tag and group EC2 instances/ENIs to align with VPC security groups and NACLs. The key point is that Kubernetes adds its own firewall-like layer, but it relies on the same underlying networking.
Key Takeaways
Security Layers: AWS VPC uses Security Groups (stateful, instance-level) and Network ACLs (stateless, subnet-level). Azure Virtual Network primarily uses Network Security Groups (NSGs) which are stateful and can apply at either subnet or NIC. Both clouds have managed firewall services (AWS Network Firewall, Azure Firewall) for deeper inspection.
Routing: Both platforms support custom routing. AWS route tables (per subnet) direct traffic to IGWs, NATs, VGWs, or TGWs. Azure uses user-defined routes (UDRs) to override default system routes for subnets. AWS subnets are tied to AZs; Azure subnets are regional (can span zones).
Default Isolation: Azure has built-in denies – default NSG rules block unsolicited inbound Internet traffic. AWS’s default NACL allows all unless changed, and SGs allow all outbound by default. You should always tighten these defaults: add NACL rules and SG rules in AWS, and NSG rules in Azure, to enforce the isolation boundaries you need.
Step-by-Step Example: We saw how to create a public and private subnet in each cloud. Key steps were attaching Internet/NAT gateways, setting correct route tables, and applying ACL/SG/NSG rules. For instance, AWS requires you to explicitly associate subnets with NACLs and write both inbound and outbound rules. Azure’s NSG model automates much of the “deny by default” stance, but you still must define the allowances for your scenarios.
AI and Monitoring: Use cloud-native security monitoring: AWS GuardDuty (ML-based threat detection on VPC logs) and Azure Defender/Sentinel provide anomaly detection on network flows. Traffic analytics and flow logs can feed into AI/ML systems for spotting unusual patterns. Routing “AI” is more about intelligent policies (latency/priority-based routing) than machine learning today.
For cloud architects and security teams, understanding these tools is crucial. AWS’s two-tier firewall model (SG+NACL) versus Azure’s one-tier NSG model leads to different best practices. At the end of the day, both platforms can achieve highly secure, segmented networks, it’s a matter of using their native constructs correctly. Keep route tables tight, use subnets for segmentation, apply NACLs/NSGs thoughtfully, and consider managed firewalls for extra scrutiny. Finally, leverage the emerging AI-driven services (GuardDuty, Sentinel, Traffic Analytics) to continuously monitor those networks for anomalies. By combining these practices, your AWS VPC or Azure VNet will be locked down yet flexible, exactly what cloud-native security demands.