Introduction Of VPC

A Virtual Private Cloud Is A Virtual Network That Closely Resembles In Traditional Networking that you operate in your own data center with the benefits of using the scalable infrastructure. Aws provides an features to setup an private cloud which includes server,router,gateways and network translation and storage as well aws assure the customer to provide an security with in aws premises.

OR

VPC is a virtual network that or data centre inside AWS for one client. It is logically isolated from other virtual network with in cloud.

Characteristics Of VPC

AWS provides us max 5 VPC creation with in one region for eg.(Oheo Region. If we need to create more then 5 need to request to AWS for additional support.
With in one VPC can create about 200 subnets and 200 Route table.
With in one VPC we can allocate max 5 elastic IP by default still if the requirement is more we can reach to AWS support for more elastic IP.
Once we created VPC there are some of the features by default it is available with in aws vpc premises are as below "DHCP", "NACL" And Security group.
VPC confined to AWS region does not extend between regions.
VPC always created inside region not in the availability zone.

Architecture Of VPC

The following diagram shows the key components for the configuration of VPC for the scenario

Note: Vpc exits on region not on the availability zone,all the properties are regional with in vpc premises.

The configuration of the following scenario as below, here we are referring an example of Mumbai Region.

A VPC with a size /16 IPv4 CIDR block (example: 10.0.0.0/16). This provides 65,536 private IPv4 addresses.
A public subnet with a size /24 IPv4 CIDR block (example: 10.0.0.0/24). This provides 256 private IPv4 addresses. A public subnet is a subnet that's associated with a route table that has a route to an Internet gateway.
A private subnet with a size /24 IPv4 CIDR block (example: 10.0.1.0/24). This provides 256 private IPv4 addresses.
An Internet gateway. This connects the VPC to the Internet and to other AWS services.
Instances with private IPv4 addresses in the subnet range (examples: 10.0.0.5, 10.0.1.5). This enables them to communicate with each other and other instances in the VPC.
Instances in the public subnet with Elastic IPv4 addresses (example: 198.51.100.1), which are public IPv4 addresses that enable them to be reached from the Internet. The instances can have public IP addresses assigned at launch instead of Elastic IP addresses. Instances in the private subnet are back-end servers that don't need to accept incoming traffic from the Internet and therefore do not have public IP addresses; however, they can send requests to the Internet using the NAT gateway (see the next line).
A NAT gateway with its own Elastic IPv4 address. Instances in the private subnet can send requests to the Internet through the NAT gateway over IPv4 (for example, for software updates).
A custom route table associated with the public subnet. This route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC over IPv4, and an entry that enables instances in the subnet to communicate directly with the Internet over IPv4.
The main route table associated with the private subnet. The route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC over IPv4, and an entry that enables instances in the subnet to communicate with the Internet through the NAT gateway over IPv4.

Routing

In this scenario, the VPC wizard updates the main route table used with the private subnet, and creates a custom route table and associates it with the public subnet.

In this scenario, all traffic from each subnet that is bound for AWS (for example, to the Amazon EC2 or Amazon S3 endpoints) goes over the Internet gateway. The database servers in the private subnet can't receive traffic from the Internet directly because they don't have Elastic IP addresses. However, the database servers can send and receive Internet traffic through the NAT device in the public subnet.

Any additional subnets that you create use the main route table by default, which means that they are private subnets by default. If you want to make a subnet public, you can always change the route table that it's associated.

Here the examples for route table associate:

Main Route Table The first entry is the default entry for local routing in the VPC; this entry enables the instances in the VPC to communicate with each other. The second entry sends all other subnet traffic to the NAT gateway (for example, nat-12345678901234567).

Destination Target 10.0.0.0/16 local 0.0.0.0/0 nat-gateway-id

Custom route table The first entry is the default entry for local routing in the VPC; this entry enables the instances in this VPC to communicate with each other. The second entry routes all other subnet traffic to the Internet over the Internet gateway (for example, igw-1a2b3d4d).

Destination Target 10.0.0.0/16 local 0.0.0.0/0 internet-gateway-id

Security

AWS provides two features that you can use to increase security in your VPC Security groups and network ACLs. Security groups control inbound and outbound traffic for your instances, and network ACLs control inbound and outbound traffic for your subnets. In most cases, security groups can meet your needs; however, you can also use network ACLs if you want an additional layer of security for your VPC.

For scenario 2, you'll use security groups but not network ACLs. If you'd like to use a network ACL.

VPC comes with a default security group. An instance that's launched into the VPC is automatically associated with the default security group if you don't specify a different security group during launch. For this scenario, we recommend that you create the following security groups instead of using the default security group.

WebServerSG: Specify this security group when you launch the web servers in the public subnet.
DBServerSG: Specify this security group when you launch the database servers in the private subnet.

The instances assigned to a security group can be in different subnets. However, in this scenario, each security group corresponds to the type of role an instance plays, and each role requires the instance to be in a particular subnet. Therefore, in this scenario, all instances assigned to a security group are in the same subnet.

The following table describes the recommended rules for the WebServerSG security group, which allow the web servers to receive Internet traffic, as well as SSH and RDP traffic from your network. The web servers can also initiate read and write requests to the database servers in the private subnet, and send traffic to the Internet; for example, to get software updates. Because the web server doesn't initiate any other outbound communication, the default outbound rule is removed. Please refer the table for Inbound traffic

The following table describes the recommended rules for the DBServerSG security group, which allow read or write database requests from the web servers. The database servers can also initiate traffic bound for the Internet (the route table sends that traffic to the NAT gateway, which then forwards it to the Internet over the Internet gateway).

(Optional) The default security group for a VPC has rules that automatically allow assigned instances to communicate with each other. To allow that type of communication for a custom security group, you must add the following rules:

(Optional) If you launch a bastion host in your public subnet to use as a proxy for SSH or RDP traffic from your home network to your private subnet, add a rule to the DBServerSG security group that allows inbound SSH or RDP traffic from the bastion instance or its associated security group.

Virtual Private Cloud In AWS