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.
- 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 ipSpace.net 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.