In Part 1, we laid out the basic framework for our new VPC infrastructure design. Now, we need to setup internet connectivity for our instances.
There are two popular ways instances can get to the internet. The Internet Gateway allows for instances with an elastic IP to reach the internet. A NAT Gateway will allow multiple instances connect to the internet while only using one public IP. Typically, we would use the internet gateway for our externally hosted assets, as they are handling the majority of the traffic flow. NAT Gateways should not be used to handle incoming external traffic, but can be used for trivial, low-bandwidth tasks. How these are used can greatly affect the cost and security of your AWS stack.
Let's revisit our basic infrastructure layout:
We segmented the networks by function, but these are all considered "inside networks". Typically, we would not want things in our internal networks to be accessed directly from the outside. So what happens when we need to host sites from our "prod" subnet? Let's create a DMZ subnet to fix this issue.
Using a DMZ subnet to host assets that are accessed from the internet is considered best practice for both physical data center and cloud stacks. Generally, we host load balancers to funnel site requests to the internal instances we have in our "inside" subnets. This, in turn, saves on overall Elastic IP usage within the stack, instead of assigning one to each of your individual servers. Below is what our infrastructure will look like after adding internet access: