Amazon Web Services Networking Overview

Traditional networking engineers, or virtualization engineers familiar with vSphere or VMware NSX, often feel like Alice in Wonderland when entering the world of Amazon Web Services. Everything looks and sounds familiar, and yet it all feels a bit different

I decided to create a half-day workshop (first delivery: June 13th in Zurich, Switzerland) to make it easier to grasp the fundamentals of AWS networking, and will publish high-level summaries as a series of blog posts. Let’s start with an overview of what’s different:

Configuration and monitoring

  • Like everything else with AWS, you have to use API calls to create networking and network security objects;
  • You can configure AWS with a GUI, a CLI, infrastructure-as-code tools (example: CloudFormation) or other deployment tools, but all of them use the same API behind the scenes (Junos designers must be proud :).


  • Even though some AWS services still don’t work over IPv6, AWS networking fully supports IPv4 and IPv6
  • Instance (VM) IPv4 and IPv6 addresses are dynamically assigned by AWS or configured through API calls
  • Amazon overlay virtual networking software routes on addresses known to orchestration system, not on what VMs think they should have
  • VMs have to use IP addresses assigned to them through the orchestration system (or things break). They can use REST API calls to find their own IP addresses if needed.

Packet forwarding

  • There’s no IP multicast or broadcast
  • Layer-2 tricks don’t work. First-hop router redundancy protocols like HSRP or VRRP don’t work at all.
  • Clustering solutions that rely on moving the service IP address to another node using gratuitous ARP don’t work (finally).
  • You can move an IP address to another EC2 instance, but you have to do that with AWS API calls.

Next time, we’ll cover routing and network security.

The draft slide deck is online – if you’re an active subscriber you can already download it. However, I’m sure the Zurich workshop will be much more interesting than browsing a slide deck – register now.


  1. AWS VPC doesn't support multicast but they suggest a workaround with an overlay:
    With its obvious downsides this of course is meant for a lift and shift of legacy software to the cloud and not to be used for new applications. Opinions on this would be welcome
    1. How nice is that. So the multicast packets are replicated at the source and sent via GRE tunnels. Thus it's a very scalable solution. Amazon've done a great job. So this means now I can host my Webex server and they are doing MOH via multicast streaming with my music source (radio).
    2. Of course it is not scalable. I did say "lift and shift of legacy software" which implies the application needs to be redesigned at some point. If you need to stream to multiple clients from a vpc there are other aws services that can be used. It is the suggested hack that interest me. I am not a network engineer but replicating packets at the source is such an obvious bad idea I was wondering if there could really be applications out there relying on this?
    3. Yes of course. There are a lot of multicast applications out there. E.g. financial trading and music/video streaming. So I see a big potential for banks moving to the cloud. We use multicast for our Checkpoint VSX cluster sync over a stretched VLAN across 2 DCs (about 500 miles apart). It works really great.
  2. Hello Ivan

    How do you tackle the 'on-prem' equivalent of app visibility (e.g. Extrahop) type functionality on AWS (or Azure)?
Add comment