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

81–90 of 104 posts

Re: Networking on AWS (2018)

#81

Post by fideloper »

becauseiam wrote: post #6

There's quite a few things you've missed that are significant and should have been included, maybe one for part two: * Network ACLs, which describe the ruleset (consider it like a stateless firewall) for subnets and their respective routes. 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). * Elastic (public) I…

How do folks use Network ACLs? I haven't used them personally - relying more on security groups and segmenting subnets to specific tasks (e.g. attached to public network via IGW, or private network only)

I'd love to hear your use cases for Network ACLs.

Re: Networking on AWS (2018)

#82

Post by Gelob »

justnoise wrote: post #48
Gelob wrote: post #34

Earlier quoted context omitted.

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).

Yes coming from outside aws, you're fucked

Re: Networking on AWS (2018)

#83

Post by jugg1es »

devonkim wrote: post #80

The part that irks me is that if you’re doing any VPC design that’s going to even potentially include peering you need to carefully understand the limitations first. This means that within the same region you can refer to security groups in rules as if they’re in the same VPC, but you can’t do that if you’re peering across regions. Then add in some DNS restrictions (like not being able to directly resolve a peer VPC’…

Planning your network is something everyone has to do whether or not they are using AWS. I think its unreasonable to expect to just throw stuff in AWS without thinking about it and then complain when something comes up unexpectedly.

Re: Networking on AWS (2018)

#84

Post by manishsharan »

sudhirj wrote: post #67
sudhirj wrote: post #66

Earlier quoted context omitted.

Lambda isn't the problem here, the private network (subnet) is. Basically default to public subnet with security groups configured for your incoming connections. If you really want / need the airgapping that private subnets provide, you'd better be willing to pay for them, and that makes sense to me personally - outside of PCI DSS or HIPAA compliance (or similar) I don't see any reason to use private subnets. That wo…

There's another gotcha, though is that Lambdas seem to default to inside the VPC by default, which triggers the NAT Gateway cost if you want to do anything useful with them. You'll need to explicitly remember to host the Lambdas outside the VPC.

You may consider using NAT instance of EC2. A micro instance which can also serve as your bastion host.

Or if you are a true extreme penny pincher -- have your lamba function invoke aws api to set up a NAT Gateway and update the subnet route, then execute your business function and then clean up the NAT.

Re: Networking on AWS (2018)

#85

Post by vvanders »

voltagex_ wrote: post #60
vvanders wrote: post #16

Earlier quoted context omitted.

Yeah, totally depends on what you're using for a router/gateway/firewall. I've got a mix of Ubiquiti gear and pfSense. Most of it was a matter of just setting up a static route(like in the article) where when I'm on the 192.x.x.x(192.0.0.0/24) network and want to talk to 10.0.0.0/24 I'd put in the gateway(10.0.0.1) as the next hop. Without knowing more about your setup it's hard to say. r/homelab is also a pretty dec…

I've got an all-Ubiquiti setup (and once you start digging into the forums / need IPv6, boy is it unimpressive) It seems like going with the Ubiquiti USG instead of the EdgeRouter or a pfsense box was a big mistake. I'm heavily space/heat/power constrained though.

Same USG here. If you're on two different networks in the Unifi setup you'll also probably need a firewall rule between them. In my case the 10.0.0.0/24 was on pfSense so the Unifi router just passed it along and didn't do anything else.

Re: Networking on AWS (2018)

#86

Post by joemag »

curiouserrr wrote: post #79
tlynchpin wrote: post #49

Earlier quoted context omitted.

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.

Except you can’t yet do cross-account transit, which makes their Transit VPC offering pretty much useless. The whole point of transit is so you can talk to other VPCs across accounts.

EC2 engineer here.

You can connect transit gateway to VPCs owned by different accounts.

Re: Networking on AWS (2018)

#87

Post by Hikikomori »

curiouserrr wrote: post #79
tlynchpin wrote: post #49

Earlier quoted context omitted.

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.

Except you can’t yet do cross-account transit, which makes their Transit VPC offering pretty much useless. The whole point of transit is so you can talk to other VPCs across accounts.

You can. Share it with Resource Access Manager, can even share it to accounts outside of your own AWS organisation.

Re: Networking on AWS (2018)

#88

Post by mz1290 »

becauseiam wrote: post #6

There's quite a few things you've missed that are significant and should have been included, maybe one for part two: * Network ACLs, which describe the ruleset (consider it like a stateless firewall) for subnets and their respective routes. 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). * Elastic (public) I…

Agreed! I recently transitioned into a developer role and my first project was working with AWS cloudformation to build a network template.

I think the post does a good job covering the high-level material. NACLs, EIP, and perhaps peering routes would also be good to mention.

Re: Networking on AWS (2018)

#89

Post by Hikikomori »

joemag wrote: post #86
curiouserrr wrote: post #79

Earlier quoted context omitted.

Except you can’t yet do cross-account transit, which makes their Transit VPC offering pretty much useless. The whole point of transit is so you can talk to other VPCs across accounts.

EC2 engineer here. You can connect transit gateway to VPCs owned by different accounts.

Will BYOIP be sharable with RAM?

Re: Networking on AWS (2018)

#90

Post by devonkim »

jugg1es wrote: post #83
devonkim wrote: post #80

The part that irks me is that if you’re doing any VPC design that’s going to even potentially include peering you need to carefully understand the limitations first. This means that within the same region you can refer to security groups in rules as if they’re in the same VPC, but you can’t do that if you’re peering across regions. Then add in some DNS restrictions (like not being able to directly resolve a peer VPC’…

Planning your network is something everyone has to do whether or not they are using AWS. I think its unreasonable to expect to just throw stuff in AWS without thinking about it and then complain when something comes up unexpectedly.

The issue is that lots of folks get started on AWS (or any cloud provider) and because everything’s built around getting developers in a hurry to push out some code this step is increasingly taking less and less time. Sure, it’s not a big deal for the usual start-up that fizzles in a couple years but once it’s going and there’s actual users the system is setup that there will be a forced outage of some sort when a couple hours investment would have prevented a lot of headaches.

The common pivot for a company is to go from a b2c company to b2b and that means regulations. That means you can’t do cowboy infrastructure setup like people setup their home network (in fact, most home networks are more secure than what most SaaS devs do as a rule sans router firmware exploits).

Post reply on HN