Amazon Virtual Private Cloud (Amazon VPC) enables you to launch Amazon Web Services (AWS) resources into a virtual network that you've defined. This virtual network closely resembles a traditional network that you'd operate in your own data center, with the benefits of using the scalable infrastructure of AWS.

VPC

🔗Things to keep in mind.

🔗Normalize your network

First of all, do not invent IP's, please use and create a normalized range using the private ranges: https://en.wikipedia.org/wiki/Classful_network#Introduction_of_address_classes

If you chose something like 10.0.0.0/16 (class A), create your segments in ascending order, for example for the public segment (color yellow in the above image) in where instances can get an [Elastic IP Address](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses -eip.html) create small segments, something like:

10.0.0.0/24
10.0.1.0/24
10.0.2.0/24

mask 24 gives you 254 available IP's

For the private segment (color green) in where instances need NAT you can crate bigger segments (2046 hosts per segment):

10.0.8.0/21
10.0.16.0/21
10.0.24.0/21

mask 21 gives you 2046 available IP's

IPCalc can help you get going while setting your network:

$ brew install ipcalc

🔗Avoid using an SSH Bastion Host

If possible, the order of preference instead of having an instance listening for ssh connection:

Create a hardware VPN between your office and AWS.
Use a VPN instance with openvpn or L2TP.
If you still want to use a Bastion Host, at least chagne the default SSH port, or implement portknocking.

To keep it short the whole point of this is security. If you are already setting up a VPC, try to stick to it, the idea at the end is to have an infrastructure capable of scaling and running your applications as easy as possible but keeping in mind security.

🔗NAT GATEWAY

You can only have NAT GATEWAY for all subnets, just be sure to attach it to the public segment.

nat gateway

🔗Network segments

Based on the availability zones (A-Z) the public segment is partitioned in small subnets of 255 hosts:

public A segment 10.10.0.0/24
public B segment 10.10.1.0/24

If you were using EU(Ireland) you could add a public C segment:

public C segment 10.10.2.0/24

Within 10.10.0.0/21 you can create up to 8 subnets of 254 hosts each (a, b, c, d, e, f, g, h) so it gives plenty of space for the public segment.

🔗Private segment

Same as the public segment the private segment is created based on the availability zones, with the main difference that segments are bigger (mask 21 - 2046 hosts), this is because almost all the instances reside in the private segments.

private A segment 10.10.8.0/21
private B segment 10.10.16.0/21

🔗Segments based on the availability zones

When you create the subnets you are available to chose a zone or to chose No preference the idea in this case of specifying a zone is that when doing autoscaling you can have more control and prevent in advance in case of a failure happens. For example you could create an Load balancer and attach 2 instances each in one zone (A, B) in case of a failure in zone A, you still having an instance in zone B so your application still up and running.

🔗Why public and private segments

Public segments are the ones don't use a NAT gateway and need an elastic/public IP to be available to operate, therefore this segment is used for load balancer(ELB, HAproxy), vpn/bastion hosts or instances that need to be exposed and reached directly outside the VPN.

Private segments require a NAT gateway and can not be reached from the outside, if you attach/allocate a public IP to an instance located within the private segment, it simple will not work.

Some of the benefits with this approach:

Inherit security from VPC (no need to create multiple security groups).
Less use of elastic IP's.
Common IP's for all outgoing requests.

IT notes

AWS VPC