Coming in at number eight on the high-availability top ten is the Virtual Private Cloud. The Virtual Private Cloud is a core building block for designing highly-available, fault-tolerant environments. Since 2013, all accounts have a Virtual Private Cloud by default. Now the Virtual Private Cloud, or VPC, is a logically isolated section of the AWS Cloud dedicated to your environment. You have complete control over the VPC, including the IP range, subnets, routing tables, and security. VPCs use security groups and access control lists to secure access and protect against unauthorized entry access. In short, the VPC is your private CIDR block of the AWS cloud. You could have CIDR of 16 down to a CIDR of 28. Let's look at the core components and acronyms of the VPC. Subnet is a segment of the VPC's IP address range where you can place groups of isolated resources. The IGW is a great acronym to forget in the last five minutes of an exam. What does the IGW stand for? It's the Internet Gateway, the Amazon VPC side of a connection to the public internet. Hardware VPN connection is a hardware-based VPN between your Amazon VPC and your data centre or colo facility. VGW is another great one to forget when you see it written down on the question. VGW stands for the Virtual Private Gateway, and that's the Amazon VPC side of a VPN connection. With Virtual Private Gateways, you can connect existing networks to your VBC. How about CGW? Customer Gateway. Your side of a VPN connection. So routers interconnect subnets and direct traffic between Internet gateways, virtual private gateways, net gateways, and subnets. Peering connections enable you to route traffic via private IP addresses between two peered VPCs. Great feature is the VPC endpoint for S3. Now that enables Amazon S3 access from within your VPC without using an Internet gateway or net. So it allows you control the access using VPC endpoint policies. Subnets are CIDR blocks within the IP range of your VPC. What's a CIDR block, I hear you ask? That stands for Classless Inter-Domain Routing. It's essentially a block of IP numbers. A subnet is a distinct network segment with its own IP address range within the larger VPC classless inter-domain routing range. When planning the subnets, take the time to properly anticipate how many nodes you might need in future. You can't change the size of a VPC after you've created it. If your VPC is too small, create a new, larger VPC and then migrate your instances to the new VPC. The first four IP addresses and the last address of any subnet are not available. Now these are reserved by AWS for routers, DNS, broadcast, and network addresses. AWS won't allow you to create netmasks slower than /16 or higher than /28. Each subnet must be associated with a route table. Every subnet that you create is automatically associated with the main route table for the VPC. Each subnet must be associated with a network access control list. If you don't explicitly associate a subnet with a network access control list, the subnet is automatically associated with the default network access control list. We're allowed 200 subnets per VPC. The IGW, or Internet gateway, provides connectivity in and out of your VPC. In practice, it serves two functions. First, it provides a target in your VPC route tables for Internet-routable traffic. And secondly, it performs network address translation for instances that been assigned public IP addresses. If a subnet is associated with a route table that has a route to an Internet gateway, it's known as a public subnet. That subnet route table needs to contain a route that directs Internet-bound traffic to the Internet gateway. One approach to achieve this is to scope the route to all destinations not explicitly known to the route table, using 0.0.0.0/0. Or you can scope the route to specific IP addresses. You can create a VPN tunnel using IPSEC to onpremise or co-locations. If you need more predictable connectivity, or a private connection, use Direct Connect. Direct Connect is a private, dedicated connection between your on-premise network and your AWS Virtual Private Cloud. It uses 802.1 q VLAN standard. Network access control lists enable subnet-level control within a VPC. Security groups control resource-level permissions. Network access control lists manage subnet-level permissions. Your VPC comes with a default network access control list. That list allows inbound and outbound traffic by default. Network access control lists are stateless. So responses to allowed inbound traffic are subject to the rules for outbound traffic, and vice-versa. A network access control list contains a numbered list of rules that are read in order, starting with the lowest-numbered rule. A network access control list has separate inbound and outbound rules, and each rule can either allow or deny traffic. You can create a custom network access control list and associate it with a subnet. By default, each custom network access control list denies all inbound and outbound traffic until you add rules, which, if you remember, is different from the default network access control list, which allows all. Each subnet in your VPC must have a network access control list. If you don't explicitly associate your own network access control list to a subnet, the subnet is automatically associated with the default network access control list. You can associate a network access control list with multiple subnets. However, a subnet can be associated with only one network access control list. When you associate a network access control list with a subnet, the previous association is removed. A security group acts as a virtual firewall, to control inbound and outbound traffic to your instances. Security groups act at the instance level; network access control lists work at the subnet level. While network access control lists restrict or allow access to a subnet, security groups are your resource-level control. Instances, elastic load balances, et cetera. You can specify allow-rules, but not deny-rules. Instances in a subnet in your VPC could be assigned to a different set of security groups. If you don't specify a particular group at launch time, the instance is automatically assigned to the default security group for the VPC. Security groups are stateful. For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic. Note inbound traffic is allowed until you add inbound rules to the security group. Return traffic is allowed by default. Security groups are associated with your network interfaces. So here's a quick summary of the differences between security groups and network access control lists. The security group operates at the instance level, so it's your first layer of defense. The network access control list operates at the subnet level, so it acts as a second layer of defense. Security groups support allow-rules only. Network ACLs support allow-rules and deny-rules. Security group is stateful, and return traffic is automatically allowed, regardless of any other rules. The network ACL is stateless, so return traffic must be explicitly allowed by your rules. With security groups, they're evaluated before deciding whether to allow traffic; with network ACLs, rules are processed in number order when a decision is made to allow traffic or not. With a security group, it applies to an instance only if someone specifies the security group when launching that instance, or when the security group is associated with an instance once it's already launched. With a network ACL, that's automatically applied to all instances in a subnet it's associated with. So, it acts as a backup layer of defense. Here's a quick summary of the limits per a Virtual Private Cloud. We're allowed five Virtual Private Clouds per region. There's a default Virtual Private Cloud set up with each new AWS account. That one default VPC per region has a default Internet gateway, network access control list, and a routing table. We're allowed 500 security groups. We're allowed a maximum of five Internet gateways per region. This limit is correlated with the limit of VPCs per region. We're allowed 10 VPNs per VPC. We're allowed 200 subnets. And five elastic IP addresses.