3 ms·

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 c

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.

baseballMan 8y ago
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.
sl1ck731 8y ago
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.
jrockway 8y ago
Having just gone through the process of using EKS, which requires a VPC, I think the article is quite applicable to anyone doing anything of average complexity. I found myself quite often wondering things like "do I have to run an Internet Gateway in every availability zone?" (no) and "do I attach my NAT Gateway to the public subnet or the private subnet in each AZ?" (public, and then add an entry for the gateway in the private subnet). Amazon does not clearly document any of this. (I think if you read enough you'll eventually figure it out, but experimentation was the most straightforward procedure here). As for just using a single EC2 instance and RDS... that is something you can do, but not everyone's workload is so simple that they can run it on one machine. And not everyone can afford do be down simply because one AZ is down. Hence, multi-AZ VPC setups.
CloudNetworking 8y ago
The fact that you don't need to know it because you only work with very small customers doesn't mean other folks don't need it :) Op's article is great IMHO.

baseballMan 8y ago

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.

sl1ck731 8y ago

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.

jrockway 8y ago

Having just gone through the process of using EKS, which requires a VPC, I think the article is quite applicable to anyone doing anything of average complexity. I found myself quite often wondering things like "do I have to run an Internet Gateway in every availability zone?" (no) and "do I attach my NAT Gateway to the public subnet or the private subnet in each AZ?" (public, and then add an entry for the gateway in the private subnet). Amazon does not clearly document any of this. (I think if you read enough you'll eventually figure it out, but experimentation was the most straightforward procedure here). As for just using a single EC2 instance and RDS... that is something you can do, but not everyone's workload is so simple that they can run it on one machine. And not everyone can afford do be down simply because one AZ is down. Hence, multi-AZ VPC setups.

CloudNetworking 8y ago

The fact that you don't need to know it because you only work with very small customers doesn't mean other folks don't need it :) Op's article is great IMHO.