Networking on AWS (2018) • Hacker News Board

Re: Networking on AWS (2018)

#101

Post by mvanbaak » Fri, Jan 18, 2019, 8:38 AM UTC

bmurphy1976 wrote: post #10

cygned wrote: post #8

In my opinion, the most annoying thing about AWS networking - and some other services - is that they often use IDs and do not show labels which forces me to remember them partly, go back and forth or have multiple windows open. The AWS console is not the best UX piece on the web, but this part is especially error prone.

Having to reference security groups by id instead of name in cloudformation stacks, terraform, and a variety of other places is one of the most infuriating things. Makes everything much more difficult to configure and maintain because the IDs are so opaque and unique. Somebody has to do the grunt work of looking them and and copy/pasting them or writing scripts to propagate configuration forward. What a waste of time…

Since you mention cloudformation here my tips to make it easier: - tag all groups so its easier to remember - use Export in outputs so you can use ImportValue in other templates - use only cloudformation, no edit/create/add actions in the console

Now the ID thing is 0 problems as you never have to worry about them anymore

Same goes for terraform or any other InfrastructureAsCode

Re: Networking on AWS (2018)

#102

Post by mvanbaak » Fri, Jan 18, 2019, 8:46 AM UTC

grahamlyons wrote: post #99

mvanbaak wrote: post #5

For the public subnets where the NAT gateways are, you can use 1 route table for all public subnets together. Besides that: nice article

Would the default route table do that job? Subnets would be associated with that if they weren't explicitly assigned to another route table, right?

Yes. But i prefer to create my own. Create a riutetable, call it “public” using a tag, attach the internetgateway and attach all public subnets, add a default route that points to the internetgateway and you’re done

Re: Networking on AWS (2018)

#103

Post by late2part » Sun, Jan 20, 2019, 7:11 AM UTC

CloudNetworking wrote: post #74

late2part wrote: post #68

Earlier quoted context omitted.

Well, it’s pointless, really. They’ve been given feedback that blocking I Mp is harmfulmsince 2011 and it’s done no good.

Disclaimer: I have worked for Azure in the past -not anymore- and specifically in Networking. Do you have evidence that they've been saying they block ICMP because of security reasons that I can forward to the right folks? I can help getting this feedback to them to correct that, because I can guarantee 100% that's not the reason why ICMP is not forwarded by the SLB (and engineering/PM would never say it's for securi…

I don’t know why they do it and I didn’t say it’s because of security. It’s harmful enough to my experience that I haven’t used them since.

Re: Networking on AWS (2018)

#104

Post by iheartpotatoes » Sun, Jan 20, 2019, 9:37 PM UTC

sudhirj wrote: post #66

iheartpotatoes wrote: post #62

Earlier quoted context omitted.

There are a bunch of microcharges like this that pop up, but reading your thread are you sure AWS is right for your application? You essentially can't afford it and want a free tier and near-free access? That seems a bit unrealistic. Maybe lambda isn't the right solution?

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…

Yeah, exactly!