Coming in at number 8 on the high availability top 10 is the virtual private cloud. The virtual private cloud is a core building block for designing highly available fault tolerating 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, sub nets, routing tables, and security. VPC's 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 AWS cloud, you can have a CIDR of 16 down to a CIDR of 28. Let's look at the core components and equinums of VPC. Sub net is a segment of the VPC's IP address range where you can place groups of isolated resources, the ITW is a great equinum 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 center or facility. VGW is another great one to forget when you see it written down on a 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 VPC. How about CGW, customer gateway, your side of a VPN connection, so routers tend to connect sub nets and direct traffic between internet gateways, virtual private gateways, net gateways and sub nets. Peering connections enable you to route traffic via private IP address between two peered VPC's. Great feature is the VPC endpoint for S3, that enables amazon S3 access from within your VPC without using internet gateway or net, so it allows you to 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. That's essentially a block of IP numbers, a sub net is a distinct network segment with it's own IP address range within the larger VPC classless inter-domain routing range. When planning the sub nets, take the time to properly anticipate how many nodes you might need in the 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 sub net are not available, now these are reserved by AWS for routers DNS broadcast and network addresses. AWS won't allow you to create net masks lower than slash 16, or higher than slash 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 router traffic. And secondly it performs network address translation for instances that have 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 and your AWS virtual private cloud. It uses the 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 allow 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 reared 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 the 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 Network ACL can have up to 20 rules.

 A security group acts as a virtual fire wall to control inbound and outbound traffic to your instances. Security groups act at the instance level, network access control lists work at the sub net level. While network access control lists restrict or allow access to a sub net, security groups are your resource level control, instances are less to grow balances etc... You can specify allow rules, but not deny rules. Instances in a sub net in your VPC could be a sign 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. No 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 is 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 sub link 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? But security groups, they are evaluated before deciding whether to allow traffic, with network ACLs rules are processed in number order when the decision is made to allow traffic or not. What the security group it applies to an instance only if someone specifies the security group when launching that instance, or when their security group is associated with an instance once it's already launched. 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 virtual private cloud. We're allowed 5 virtual private clouds per region. There's a default virtual private cloud set up with each new AWS account. That default virtual private cloud 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 VPCs per region. We're allowed 10 VPN's per VPC. We're allowed 200 subnets and 5 elastic IP addresses. Okay let's discuss the sample question, the question is you are configuring a new virtual private cloud for one of your clients for a cloud migration project, only a public VPN will be in place. After you've created your VPC, you've created a new sub net, a new internet gateway, and attached your internet gateway to the VPC, that all sounds pretty good so far doesn't it? After launch, your first instance into your VPC, you realize that you cannot connect to the instance, even if it is configured with an elastic IP address. What should be done to access the instance?

- So it's always important to read these questions very carefully, they give us all the facts that we need to answer this. So the first thing that we're gonna note is that we've created a new sub net, it's got an internet gateway, therefore it is a public sub net, and we've attached the internet gateway to the VPC, so by all means and purposes that public sub net should have connectivity to the public domain. So let's read through our options, the first one, a network access control list should be created and allow all outbound traffic. For the network access control list, it's our out of perimeter security isn't it that goes on our sub net, do you remember our security groups give us resource level permissions and those allow rules and our network access control list is stateless, and they can do allow and deny rules. So this is quite a tricky option, if we had specifically had given to us that we created a network access control list, then any custom access control list we would set policies for inbound and outbound, but because we haven't been told that, we just have to assume that we're using the default network access control list. And that allows all by default. So we're gonna have to discount this as an option. So option B is a route should be created as 0.0/0, and your internet gateway is a target, now that is very in the right, keep in mind view, because what's missing from the description that we have above is the route and remember that every VPC needs to have a route table to point traffic from any instance inside the VPC out to the external domain, so I'm going to go with that one at this stage, a route should be created, okay, and the third option we have is a net instance should be created and all traffic should be forwarded to the net instance, no, that would be appropriate if we had a private sub net that was trying to connect to the internet for example, and it was a private sub net that would be one way of connecting using a bastion host to have instances that are in a private sub net connect to the external or public domain. So I'm not gonna go with that one, option D is attach another elastic network interface to the instance and connect via that plastic network interface, now that's a very interesting option, I don't think that's what in any way gonna solve our connectivity problem, so attaching another network instance can be done, yes, but it's not going to provide us with any more connectivity, having followed those I think that the best option there is that we need that route, and thinking back to those basics we had around BPC, every access needs to have a route table.