Virtual Private cloud (VPC)

Configured and ready for you to use.
It has a default subnet in each Availability Zone in the Region, an attached internet gateway, a route in the main route table that sends all traffic to the internet gateway, and DNS settings that automatically assign public DNS hostnames to instances with public IP addresses and enable DNS resolution through the Amazon-provided DNS server*.

A default VPC includes an internet gateway, and each default subnet is a public subnet.

By default the following are created:

Defualt VPCs can be modified.

If deleted Default VPCs can be recreated via the console.

A route table contains a set of rules, called routes, that are used to determine where network traffic from your VPC is directed. You can explicitly associate a subnet with a particular route table. Otherwise, the subnet is implicitly associated with the main route table.

Main route table: The route table that automatically comes with your VPC. By default, when you create a nondefault VPC, the main route table contains only a local route. If you Create a VPC and choose a NAT gateway, Amazon VPC automatically adds routes to the main route table for the gateways. You can’t delete the main route table but you can replace the main route table by associating a custom route table with a subnet. You can change which route table is the main one.

Custom route table: If you Create a VPC and choose a public subnet, Amazon VPC creates a custom route table and adds a route that points to the internet gateway. One way to protect your VPC is to leave the main route table in its original default state. Then, explicitly associate each new subnet that you create with one of the custom route tables you’ve created. This ensures that you explicitly control how each subnet routes traffic.

Destination: The range of IP addresses where you want traffic to go (destination CIDR).

Target: The gateway, network interface, or connection through which to send the destination traffic.

Route table association: The association between a route table and a subnet, internet gateway, or virtual private gateway. Each subnet in your VPC must be associated with a route table. A subnet can be explicitly associated with custom route table, or implicitly or explicitly associated with the main route table.

Subnet route table: A route table that’s associated with a subnet.

Local route: A default route for communication within the VPC. They always take precedence, regardless of specificity.

Propagation: If you’ve attached a virtual private gateway to your VPC and enable route propagation, we automatically add routes for your VPN connection to your subnet route tables. This means that you don’t need to manually add or remove VPN routes.

Gateway route table: A route table that’s associated with an internet gateway or virtual private gateway. You can associate a route table with an internet gateway or a virtual private gateway. When a route table is associated with a gateway, it’s referred to as a gateway route table. You can create a gateway route table for fine-grain control over the routing path of traffic entering your VPC. For example, you can intercept the traffic that enters your VPC through an internet gateway by redirecting that traffic to a middlebox appliance (such as a security appliance) in your VPC.

Edge association: A route table that you use to route inbound VPC traffic to an appliance. You associate a route table with the internet gateway or virtual private gateway, and specify the network interface of your appliance as the target for VPC traffic.

If you frequently reference the same set of CIDR blocks across your AWS resources, you can create a customer-managed prefix list to group them together. You can then specify the prefix list as the destination in your route table entry.

Every route table contains a local route for communication within the VPC. This route is added by default to all route tables. If your VPC has more than one IPv4 CIDR block, your route tables contain a local route for each IPv4 CIDR block. If you’ve associated an IPv6 CIDR block with your VPC, your route tables contain a local route for the IPv6 CIDR block. You can replace or restore the target of each local route as needed.

You can add a route to your route tables that is more specific than the local route. The destination must match the entire IPv4 or IPv6 CIDR block of a subnet in your VPC. The target must be a NAT gateway, network interface, or Gateway Load Balancer endpoint.

If your route table has multiple routes, we use the most specific route that matches the traffic (longest prefix match) to determine how to route the traffic.

You can’t add routes to IPv4 addresses that are an exact match or a subset of the following:

You can specify the network configurations that are provided by Amazon DHCP servers by using DHCP option sets. Each Region has a default DHCP option set. Each VPC uses the default DHCP option set for its Region unless you either create and associate a custom DHCP option set with the VPC or configure the VPC with no DHCP option set. You cannot edit the default Option Set

Options:

If at least one of the attributes is set to false, the following occurs:

The allowed block size is between a /16 netmask (65,536 IP addresses) and /28 netmask (16 IP addresses). After you’ve created your VPC, you can associate additional IPv4 CIDR blocks with the VPC.

In addition:

Elastic IP addresses remains allocated to your AWS account until you explicitly release it.

An Elastic IP address is a property of a network interface. The advantage of associating the Elastic IP address with the network interface instead of directly with the instance is that you can move all the attributes of the network interface from one instance to another in a single step.

Rules:

Creates a private and encrypted link between TWO VPCs, the VPCs can also be cross-account and cross-region. Cross-region traffic between peers transits over the AWS Global Network.

The link is not transitive: if A is peered to B, which is peered to C, A CANNOT communicate with C!

It uses a request-accept architecture: the requester VPC sends an invitation which must be accepted.

It’s essential that there’s no CIDR ranges OVERLAP beetwteen the peered VPCs.

Once the peering is established both VPC must be configured in their route tables how to route traffic, it’s not automatic.

If both VPCs are in the same region Security Groups from each VPC can directly reference Security Groups in the other, even cross-account.

Peering comes at no additional cost, normal traffic charges apply, so cross-AZ and cross-Region traffic is billed at a higher cost but *traffic within the same AZ even if it flows cross-account is free.

You can enable an option to have public hostnames of resources in the other VPC resolve to private IP addresses.

VPC sharing allows multiple AWS accounts to create their application resources into shared, centrally-managed virtual private clouds (VPCs). The account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from AWS Organizations. After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner.