Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Networking on AWS (2018)

grahamlyons.com

Post reply on HN
Print view View original

41–50 of 104 posts

Re: Networking on AWS (2018)

#41

Post by dvtrn »

AmericanChopper wrote: post #40
dvtrn wrote: post #33

Earlier quoted context omitted.

Network ACLs [...] Whilst they are optional, having a default set it straightens out a lot of duplication that may end up in Security Groups (which are more stateful in nature). I inherited an infrastructure that had NetACLs and security groups with duplicate entrypoints and policies, years of accumulated cruft because it was poorly designed and the documentation was even worse (read: nonexistent), security groups al…

I guess it’s a matter of preference, but I strongly prefer security groups over ACLs, which I don’t use at all. Even if only from a compliance perspective, a security group is equivalent to a host firewall (which personally helps me with PCI - no need for iptables and windows firewall). Whereas an ACL is a bit harder to make that case with. I also find them easier to audit.

I'm slightly inclined to agree, it's one of those YMMV scenarios. What happened to me was there was some unholy combination of both going on, duplicating each other, in some cases weaving in and out of each other with some bastard frankenstein topology of route tables to nowhere...

those were frightening times. Entire services would fall over, dogs and cats living together

Re: Networking on AWS (2018)

#42

Post by kondro »

Gelob wrote: post #14

AWS security groups and ACLs are the most worthless things. you cant treat them like a real firewall. you end up just allowing anything outbound or inbound. they dont let you be detailed enough

100% disagree with this. There's no reason to not use whitelist first for almost everything… especially inbound.

Even if you do want to make your internal comms life easier, you can use security-group-based rules that do any/any between the members of the group itself, effectively constructing VLANs easily between services.

Re: Networking on AWS (2018)

#43

Post by llama052 »

scubbo wrote: post #38

Something that's missing from this (otherwise great!) guide, that has puzzled me for a while - what's the point? What does this configuration actually gain you/AWS? My best guess is that private subnets are for DDOS protection, but that seems like something that would be better handled by throttling. Given the amount of complaints I've heard about how difficult VPC/Subnet setup is, why bother with it at all? Staving…

Not sure I'm qualified to answer all of your questions on this but, from a networking perspective..

Private subnets will allow you to reduce your exposure to the Internet, also can reduce costs with something like a NAT gateway. It's useful for things that don't need to be public facing. Generally things on the private subnet can go outbound directly but not have anything come direct into that subnet, you'd need a solution that interfaces with the public side to facilitate that, or manually create a public IP association per instance.

You generally don't want one big subnet in general, it's a broadcast domain and it can be quite chatty when you get a lot of devices on it. Alongside that if you're doing multi-AZ and spanning layer-2 you end up with a lot of additional complexity to get that network to span and be highly available over multiple AZ's, while another subnet can be mostly independent. I know of some weird edge cases where you'd have to span layer-2, but if you're doing anything cloud-native you should be able to build around it.

Re: Networking on AWS (2018)

#44

Post by athrun »

scubbo wrote: post #38

Something that's missing from this (otherwise great!) guide, that has puzzled me for a while - what's the point? What does this configuration actually gain you/AWS? My best guess is that private subnets are for DDOS protection, but that seems like something that would be better handled by throttling. Given the amount of complaints I've heard about how difficult VPC/Subnet setup is, why bother with it at all? Staving…

Typically, compliance requirements will drive you to implement private subnets.

Auditors will want to know which isolation mechanisms you have put in place, and private subnets should be part of your isolation strategies.

Other use-cases:

- Legacy (or third-party) apps whose security model assumes they are behind some sort of private firewall.

- Hybrid deployment where you need to bridge on-premises (or other clouds) address space(s) with your VPC.

> Or, to ask it another way - what would be the downside of all your resources being in 1 single-Subnet VPC, spread evenly across AZs?

Note that a subnet cannot spread across AZs. So, even if you only need/want public subnets, you will want to deploy at least 1 public subnet per AZ.

Re: Networking on AWS (2018)

#45

Post by javadocmd »

AmericanChopper wrote: post #40
dvtrn wrote: post #33

Earlier quoted context omitted.

Network ACLs [...] Whilst they are optional, having a default set it straightens out a lot of duplication that may end up in Security Groups (which are more stateful in nature). I inherited an infrastructure that had NetACLs and security groups with duplicate entrypoints and policies, years of accumulated cruft because it was poorly designed and the documentation was even worse (read: nonexistent), security groups al…

I guess it’s a matter of preference, but I strongly prefer security groups over ACLs, which I don’t use at all. Even if only from a compliance perspective, a security group is equivalent to a host firewall (which personally helps me with PCI - no need for iptables and windows firewall). Whereas an ACL is a bit harder to make that case with. I also find them easier to audit.

I like using ACLs for my coarse-grained "this subnet is allowed to talk to this subnet" rules, and security groups for everything finer-grained. Maybe I'm over-cautious, but I don't want one rogue security group opening up a tunnel to sensitive subnets.

Re: Networking on AWS (2018)

#46

Post by AmericanChopper »

javadocmd wrote: post #45
AmericanChopper wrote: post #40

Earlier quoted context omitted.

I guess it’s a matter of preference, but I strongly prefer security groups over ACLs, which I don’t use at all. Even if only from a compliance perspective, a security group is equivalent to a host firewall (which personally helps me with PCI - no need for iptables and windows firewall). Whereas an ACL is a bit harder to make that case with. I also find them easier to audit.

I like using ACLs for my coarse-grained "this subnet is allowed to talk to this subnet" rules, and security groups for everything finer-grained. Maybe I'm over-cautious, but I don't want one rogue security group opening up a tunnel to sensitive subnets.

That’s a reasonable design pattern. For my usecase we have those segmentations in place at the VPC level, so ACLs wouldn’t add anything for us.

Re: Networking on AWS (2018)

#47

Post by ajbourg »

javadocmd wrote: post #45
AmericanChopper wrote: post #40

Earlier quoted context omitted.

I guess it’s a matter of preference, but I strongly prefer security groups over ACLs, which I don’t use at all. Even if only from a compliance perspective, a security group is equivalent to a host firewall (which personally helps me with PCI - no need for iptables and windows firewall). Whereas an ACL is a bit harder to make that case with. I also find them easier to audit.

I like using ACLs for my coarse-grained "this subnet is allowed to talk to this subnet" rules, and security groups for everything finer-grained. Maybe I'm over-cautious, but I don't want one rogue security group opening up a tunnel to sensitive subnets.

Yes, this is one of the best reasons to use network ACLs. (You can also achieve this with routes)

I think the idea is that separate teams with different responsibilities can manage the two different layers. Your app team may manage the security groups but the security team manages network ACLs which limit what can go into or come out of a subnet.

Re: Networking on AWS (2018)

#48

Post by justnoise »

Gelob wrote: post #34
AzMoo_ wrote: post #22

Earlier quoted context omitted.

Why are you just allowing anything outbound or inbound? You can specify Allow/Deny on any combination of source subnet, dest subnet, source port, dest port for starters. That gets you a pretty comprehensive ability to lock down a VPC on its own.

Say I want to allow outbound http/https to 10 different IPs. I can't do that in 1 rule like a traditional firewall.

Just in case those IPs are within your AWS account: you can apply a single security group to those machines and then use that security group as the destination in the outbound rule.

If they're outside your account then, you're right, that's a shortcoming in AWS (Azure and GCP both allow multiple destinations in a single rule).

Re: Networking on AWS (2018)

#49

Post by tlynchpin »

llama052 wrote: post #26

Off topic, but as a network guy by heart I've always been fairly happy with how AWS implements the network side of things, especially in comparison to something like Azure. AWS you have the same basic concepts of a network, and the terminology aligns enough that you can make sense of it fairly quick if you're in the network realm. Azure however takes all of that 'network' stuff and turns it into this abstraction wher…

Transit Gateway was announced at re:invent 2018. That's a few months ago. DirectConnect Gateway and Transit VPC were announced the year before. I would guess about nobody is currently in production with Transit Gateway.

Re: Networking on AWS (2018)

#50

Post by simonebrunozzi »

The title says "everything you need to know about networking on AWS". I wish it were this simple.

The article is well written, but it simply represents maybe 1% of what you need to know here. I would have called it "A simple introduction to networking on AWS".

Post reply on HN