AWS VPC !!!!!!

VPC tidbits 

Resembles our own datacenter like our own on premisis private corporate network.

Has private and public subnets and a scalable architecture. Ability to extend corporate/on-premise network to the cloud as if it was part of our network (using VPN).

Benefits of VPC :

• Launch instances into subnet
• Define custom CIDR(IP address range) inside each subnet.
• Configure route tables between subnets
• Configure internet gateways and attach them to subnets
• Create a layered network of resources.
• Security settings to protect cloud resources.
• Expand network in cloud with VPN/tunnelling.
• Layered Security
• Instance security group
• Network ACL at subnet level

Default VPC : Has an internet gateway attached Each instance has a default private and public IP address(defined on subnet settings).Public IP address are attached to an Elastic Network Interface that has a private IP address associated with it. This is called NATing. i.e. routing from public IP to private IP and eventually to the instance.

VPC peering : Direct network route between one VPC and another. Allows sharing of resources as if they were on same network. 

• VPC peering can happen between other AWS accounts and other VPCs within the same region.
• VPC peering cannot occur between two regions.
• Scenarios -
• Peering two VPCs - Multiple VPCs of a company linked under one private network.
• Peering to a VPC - Multiple VPCs can connect with a central VPC but cannot communicate with each other. The only communication that can occur is between the peered VPC and the primary. Eg. If Third party wanted sharing of resource like a File share etc.

VPC Limits :

• 5 VPC per region
• 5 internet gateways (this is equal to per VPC as we can only have one internet gateway per VPC)
• 50 customer gateways per region.
• 50 VPN connections per region
• 200 route tables per region/ 50 entries per route table
• 5 elastic IP address
• 500 security groups per VPC
• 50 rules per security group (Remember security groups act at VPC level)

All instances launched into the default SG can communicate with each other.

By default each instance has a route to each other instance in the subnet which it is created in.

The difference between Public and Private subnet is having an internet gateway and not having an internet gateway.

In order to connect to the internet an instance must have an internet gateway and also a public IP.

For high availability you should have multiple instances in multiple AZs. And you can use Load Balancer to achieve the high availability.

Unless required, never expose instances to the internet by assigning it with public IP address.

Some takeaways :

• Each subnet must be associated with a route table.
• By default all subnets traffic is allowed to each other available subnet within our VPC which is called local route.
• We cannot modify or delete local route.
• Best practice is to leave the default route and create new routes as needed.
• To enable access to/from internet for instances in a VPC subnet, we must attach internet gateway to VPC and also ensure that the subnet's route table should point to the internet gateway.
• In order to download software and updates to a private instance one can use a NAT instance. 
• NAT instance must be created in a public subnet.
• NAT instance must be part of private subnet's route table.

AWS provides DNS servers for VPCs so each instance has a host name.

VPC Security

Security Groups

• Operate at instance level
• Supports allow rules only
• Is stateful - so return traffic requests are allowed regardless of rules.
• Evaluates all rules before deciding to allow traffic

Network ACL

• Operates at subnet level
• Stateless - so return traffic must be explicitly allowed through an outbound rule.
• Processes rules in number order. So if a traffic is allowed at a higher number rule and denied at a lower number rule then the traffic will be denied.
• Applies at network level - so one deny will block all traffic for all instances.
• Deny all is the default rule for NACL
• Example : in the below snap, the DENY on port 80 wont make any difference because all traffic is allowed at a lower level.

NAT instance - There are NAT specific AMIs present in AWS marketplace to create a NAT instance.
NAT instance must be inside public subnet and it must have a public/Elastic IP associated to it. Ports (HTTP/HTTPS) must be open. On NAT instance the source/destination check must be disabled ; This will allow traffic from our private subnet to the internet via NAT.

Extending VPC to on premises must always be controlled and encrypted. VPN allows one subnet from one geographic location to extend to another geographic location. This means it can extend to on-premisis network too. SO we would connect to all resources internally without need for public/private addresses.
VPG (Virtual Private Gateway) - It acts like a connector on the VPC side of the VPN connection.
VPG is conected to VPC. and the VPN is associated with the customer gateway creating the endpoint. A Customer Gateway acts as a connector on the on-premises side of VPN. This is where you configure the public IP address for the on-premise network.

Both VPG and the Customer Gateway are required to establish a VPN connection.

Only one VPG is attached to a VPC.

Alternate methods for deploying a VPN to AWS - Configure an OpenVPN instance which lives in a public subnet and we can connect to the public IP using the OpenVPN client.
But one must also consider high availability to this instance. What is this instance fails ? A single point of failure ? So High Availability must be applied to this instance.

VPC peering

You cannot do a VPC peering between two VPCs in different region. Both VPCs should reside in same region. VPCs are not AZ specific.

When peering you need to make sure that each VPC should have different CIDR ranges.
If one VPC is connected to second VPC, and second VPC is connected to third VPC then first and third VPC cannot communicate to each other unless explicitly connected.

You can create peering connections from VPC-VPC, VPC-Subnet, VPC-Instance too.

Limitations : You cannot just extend VPC connections from a Cloud network to an on-prem network. You still need a VPN and a VPGateway inorder to connect.
Even you cannot access an S3 end point which is present in second VPC from a first VPC (inspite of having a peering connection)