Networking on AWS (2018) • Hacker News Board

Re: Networking on AWS (2018)

#61

Post by iheartpotatoes » Thu, Jan 17, 2019, 5:05 AM UTC

Ugh! That's the most complex explanation of AWS I've ever seen.

He just described a NETWORK, not AWS.

AWS has renamed lots of things, but all the scary text configs that used to be the domain of wizened sysadmins have been replaced with very simple single-page-app GUI controls. LIke routers and gateways: those terms are largely gone from the AWS vocabulary.

No need to get into subnets and route tables I think.

The majority of clients I've worked with use AWS for web hosting with an ELB load balancer (the most important part), an EC2 instance policy & image (for handling traffic fluctuations), an RDS (database), an S3 and Route53 (external DNS entries)

Point the load balancer to the outside world and then let it spin up instances. That's the most common model I've encountered.

IT's almost cartoonishly simple compared to what the OP wrote here. Almost. Having an understanding of network architecture helps, but not THAT much.

Re: Networking on AWS (2018)

#62

Post by iheartpotatoes » Thu, Jan 17, 2019, 5:09 AM UTC

benmanns wrote: post #19

NAT gateways are one of the things that blindsided me on the whole "serverless" idea for hobby projects. To have a Lambda function with access to the outside world and your private network resources your $0.01/month function becomes a $35/month+ expense if you don't want to manage your own t2 NAT instance (and required patches, upgrades, scaling, monitoring, etc). See https://forums.aws.amazon.com/thread.jspa?threadI…

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?

Re: Networking on AWS (2018)

#63

Post by iheartpotatoes » Thu, Jan 17, 2019, 5:10 AM UTC

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.

Agreed. I wish they would use the NAMES that I gave everything instead of the cryptic IDs. On the plus side, I'm improving my memory?

Re: Networking on AWS (2018)

#64

Post by iheartpotatoes » Thu, Jan 17, 2019, 5:11 AM UTC

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.

Dumb question: if the IPs are coming from Route53 for web addresses, why don't you just point them as aliases to the same load balancer? Done and done, right?

Re: Networking on AWS (2018)

#65

Post by baseballMan » Thu, Jan 17, 2019, 5:30 AM UTC

iheartpotatoes wrote: post #61

Ugh! That's the most complex explanation of AWS I've ever seen. He just described a NETWORK, not AWS. AWS has renamed lots of things, but all the scary text configs that used to be the domain of wizened sysadmins have been replaced with very simple single-page-app GUI controls. LIke routers and gateways: those terms are largely gone from the AWS vocabulary. No need to get into subnets and route tables I think. The ma…

It depends on how complex the environment you're working in is. If you're at a large enterprise that wants to build a platform capable of scaling to thousands of apps, you most definitely do need to care about everything written here, plus a lot more networking specific things not mentioned.

Re: Networking on AWS (2018)

#66

Post by sudhirj » Thu, Jan 17, 2019, 5:39 AM UTC

iheartpotatoes wrote: post #62

benmanns wrote: post #19

NAT gateways are one of the things that blindsided me on the whole "serverless" idea for hobby projects. To have a Lambda function with access to the outside world and your private network resources your $0.01/month function becomes a $35/month+ expense if you don't want to manage your own t2 NAT instance (and required patches, upgrades, scaling, monitoring, etc). See https://forums.aws.amazon.com/thread.jspa?threadI…

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 won't apply on a personal project.

Re: Networking on AWS (2018)

#67

Post by sudhirj » Thu, Jan 17, 2019, 5:43 AM 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…

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.

Re: Networking on AWS (2018)

#68

Post by late2part » Thu, Jan 17, 2019, 5:56 AM UTC

bg24 wrote: post #30

filmgirlcw wrote: post #28

Earlier quoted context omitted.

Microsoft employee here - I don’t work specifically on the networking side of Azure but this is really good feedback that I’ll share with the product teams.

I do not and did not work for Microsoft, but love this very attitude.

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

Re: Networking on AWS (2018)

#69

Post by jcrites » Thu, Jan 17, 2019, 6:17 AM UTC

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…

I would also add VPC PrivateLinks to the list, which let you establish private connections between systems in different VPCs without having to either peer them or connect them in other ways. PrivateLinks allow you to relieve the pressure that you might otherwise feel to build a lot of systems in the same VPC.

Another useful concept (not VPC-specific) is using the Infrastructure-as-Code paradigm (e.g., CloudFormation, Terraform) to capture all of your networking configuration in source control, along with who made any changes and the reasons or design documentation for them.

Re: Networking on AWS (2018)

#70

Post by sl1ck731 » Thu, Jan 17, 2019, 8:00 AM UTC

iheartpotatoes wrote: post #61

Ugh! That's the most complex explanation of AWS I've ever seen. He just described a NETWORK, not AWS. AWS has renamed lots of things, but all the scary text configs that used to be the domain of wizened sysadmins have been replaced with very simple single-page-app GUI controls. LIke routers and gateways: those terms are largely gone from the AWS vocabulary. No need to get into subnets and route tables I think. The ma…

As someone who has worked full time putting companies into AWS for almost 4 years as a cloud consultant, I've experienced only a couple occasions where your description is accurate and only for a small portion of the customer's portfolio.

Even when beanstalk is used, all of the stuff mentioned in the OP and more are usually required.

Simple weekend projects maybe, but only small enterprise services work in your model.