8 ms·

I mean, don't you automatically have one even if you don't define one? At least on AWS? In that sense, explicit configuration rather than relying on AWS default

I mean, don't you automatically have one even if you don't define one? At least on AWS? In that sense, explicit configuration rather than relying on AWS defaults that can change underneath you has value.

kempbellt 7y ago
You are correct. In AWS, there is a default one provided for you. The main benefit of creating your own is that you can define your base CIDR block to be something that makes more sense to you. With subnets separated out by use cases, in a more logical and memorable way. As an example: A root CIDR block of 10.0.0.0/16 will give you ~65536 usable addresses - more than enough for many projects. You can create a "public" subnet (10.0.1.0/24 - ~256 addresses available) and route all traffic in this subnet directly to an internet gateway. Things you want to put in here include load balancers, and your NAT gateway (which will be used by private subnets). Then create a "private" subnet (10.0.2.0/24) and route all traffic in this subnet to your NAT gateway (which lives in the public subnet). Resources in this subnet will have all internet traffic routed through the NAT gateway, preventing direct access from the internet, just like your home router is a buffer for your PC. You can get creative here. Adding a subnet 10.0.16.0/20 will give you ~4096 addresses, which is useful for lambdas that need to scale horizontally (each one consumes a private IP address). Also, if your lambdas need internet access, to call an API for example, you must route traffic through a NAT gateway. It may seem like a lot to setup, but once you have it up and running, you save yourself a lot of headache in the long run. You can quickly identify network configuration errors by knowing the local IP of a resource. "Why can't I ssh directly into my EC2 instance? Oh, because it's IP is 10.0.2.45, meaning it's in a my private subnet)"

kempbellt 7y ago

You are correct. In AWS, there is a default one provided for you. The main benefit of creating your own is that you can define your base CIDR block to be something that makes more sense to you. With subnets separated out by use cases, in a more logical and memorable way. As an example: A root CIDR block of 10.0.0.0/16 will give you ~65536 usable addresses - more than enough for many projects. You can create a "public" subnet (10.0.1.0/24 - ~256 addresses available) and route all traffic in this subnet directly to an internet gateway. Things you want to put in here include load balancers, and your NAT gateway (which will be used by private subnets). Then create a "private" subnet (10.0.2.0/24) and route all traffic in this subnet to your NAT gateway (which lives in the public subnet). Resources in this subnet will have all internet traffic routed through the NAT gateway, preventing direct access from the internet, just like your home router is a buffer for your PC. You can get creative here. Adding a subnet 10.0.16.0/20 will give you ~4096 addresses, which is useful for lambdas that need to scale horizontally (each one consumes a private IP address). Also, if your lambdas need internet access, to call an API for example, you must route traffic through a NAT gateway. It may seem like a lot to setup, but once you have it up and running, you save yourself a lot of headache in the long run. You can quickly identify network configuration errors by knowing the local IP of a resource. "Why can't I ssh directly into my EC2 instance? Oh, because it's IP is 10.0.2.45, meaning it's in a my private subnet)"