AWS networking deep dive

[dlots]

Alot of packet pushers stuff has a tendency to be on speculation type stuff, or on things that are super specific. and thus not as interesting as it might be, but this AWS podcast is very good. If you think you might ever want to do AWS stuff I highly recommend listening before you start.  Even if you aren't planning to do it the concepts are quite cool.  I am ~30% though and listening to it I kinda wish real networking was more AWS like.

http://packetpushers.net/podcast/podcasts/datanauts-090-aws-networking-deep-dive/

[ZiPPy]

Good stuff dlots.  I've actually been intrigued as of late by AWS, along with Azure and GCP.  I've been wanting to try one of them, free version to start and some introduce to them to my lab. I've been fighting Cloud for awhile, but maybe it's time to embrace it as that seems to be the future.

Cheers,

[deanwebb]

Thought I'd keep notes here as I listened...

1. Sounds like every host is on its own /32 network. No broadcast domains.
2. Traffic is controlled by security policy.
3. Security is host-based, not network-based. Comms go from point to point, not VLAN to VLAN.
4. Every host pretty much has its own firewall - but those firewalls can be given common policies. Those common policies are security groups.
5. Every host gets a security group. No exceptions.
6. Your AWS VPC will be a /16. Don't worry, /16 is good here.
7. You may need multiple VPCs if you have multiple billing centers and each one will be responsible for its own AWS usage.
8. Otherwise, why not just have it all in one VPC? If you need more than 500 security groups, which is a hard limit. Think of scaling and what devices are going in there and what the devices need to talk to.
9. May want dev in its own VPC because dev.
10. Security group management is best done by object reference and metadata, NOT IP addresses.
11. Groups will include servers spinning up and spinning down - another reason to not worry about IP addresses. AWS will auto-scale.
12. Groups may even include "serverless" functions that are running to execute a single function for a few moments. You can get 1000 of these all of a sudden, another argument in favor of the /16.
13. Networking the AWS environment is more like architecture. You will tell AWS what you want in terms of devices talking to each other, as in, "Devices in Security Group RENDERING should be able to communicate with Security Group PREPRODUCTION unless that host is also in Security Group FINANCE" or whatever. AWS will handle the specifics of that operation. You specify what is to be done, the AWS people will decide what tools and techniques to use to make that happen.

14. Load balancing in AWS doesn't work the way it does in the datacenter.
15. AWS handles the NAT for publicly-facing applications. You don't set that up, AWS handles it. Multiple AWS hosts can share the same NAT/hostname - the AWS load balancing can handle that, don't worry. You're not configuring the Riverbed or F5 or anything like that.
16. Vendors will want you to use their stuff on AWS, and they have cool stuff for you to consider using in AWS. If the vanilla AWS doesn't give you what you want, a vendor is there to help provide that functionality.
17. AWS security groups only go up to layer 4 (port numbers). If you want Layer 7 firewalling, time to get a NGFW for AWS.
18. East-west traffic most likely will be AWS native. North-south will likely involve a vendor product in AWS. (My own note - vendor governance tools for AWS are still needed, don't forget that detail!)
19. You still need to follow due diligence when putting together AWS: Amazon does not absolve you from having proper security and DR in place.
20. Vendor gear in AWS won't match 1:1 their gear in the real world.
21. Failover in AWS can take 20 seconds or more to attain. If you need subsecond failover, keep it on-prem. (My own note - see also the articles Wintermute posted regarding cloud sticker shock, required reading!)
22. Traffic you think is going through the firewall might not be. Check carefully, especially for very sensitive data.
23. If you provision it, you pay for it. Therefore, automate your networking once you understand what you're doing.
24. It's very possible for these cloud networks to originate among developers and then get handed over to networking - where the networkers get to clean up all the any-any-all security groups.
25. This AWS stuff will make it into the datacenter and campus, eventually. Ponder that as you probe AWS stuff.

[icecream-guy]

The worst thing about AWS, specifically in my previous employer's case at MegaGovernment Corp, was the inability to deliver east-west traffic visibility to security and to the SOC. Seniors ended up having to architect and build an overlay network on top of AWS, which is not a recommended practice.

[deanwebb]

Are there third-party products to do that? I would imagine that there are... but then the next question is if they're up and running, is AWS still a cost-effective service that makes good business sense?

[ZiPPy]

The worst thing about AWS, specifically in my previous employer's case at MegaGovernment Corp, was the inability to deliver east-west traffic visibility to security and to the SOC. Seniors ended up having to architect and build an overlay network on top of AWS, which is not a recommended practice.

Interesting point here.  I wonder how so many people are working around, or with this aspect.  Since I hear about going to the cloud every single day.  I feel like I'm the only one that isn't in the cloud, or knows much about it.  That AWS page is intimidating with all the features, but I have to jump in some time.

[deanwebb]

Quite a few people are working completely ignorant of that aspect... those that are aware either roll their own overlay or get a 3rd-party product to do the job.

[wintermute000]

You have NSGs which is an ACL. W00t (interestingly that's also NSX's massive claim to fame...)

I've seen (literally) a large integration proposal (multi million, entire enterprise workload migration) proposed with security being NSGs + outbound proxy, because AWS reasons (too hard to properly integrate a real NGFW / traditional DMZ posture with purely native AWS tooling, no desire to make AWS infra dependent upon instances/VMs and custom config).


Here's how to do 'real' networking through AWS constructs, it ain't pretty and lot of people have no idea its possible. Note I'm not talking about purely inserting a 3rd party VM as a VPN gateway or internet gateway, that's common as mud.


http://docs.aws.amazon.com/solutions/latest/cisco-based-transit-vpc/welcome.html