Hello, and welcome to this final lecture. By now, you should have a solid understanding of how to architect your VPC subnets and configure routine appropriately for various different configurations and scenarios. However, in this last lecture, I just want to reiterate some of the key points that we made throughout the previous lectures.

We started off by looking at VPC CIDR blocks. Where this lecture focused on the effects of subnetting your VPC CIDR block and here were some of the key points.

- Subnetting is the process of splitting a CIDR block into smaller CIDR blocks within the same range of the larger block.
- Subnetting enables you to divide your VPC CIDR block into small networks.
- The VPC CIDR block range encompasses the entire IP address space that you can use within that VPC.
- The maximum and minimum masks for your VPC CIDR block are /16 to /28.
- AWS reserves the first three host IP addresses of each subnet for internal AWS usage. The first host is used for the VPC router. The second is for DNS and the third is reserved for future use.
- An IPv4 CIDR block range for your VPC is mandatory but you can also associate an IPv6 block as well.

Next we focused on the topic of why subnet your VPC? And here we looked at some of the reasons why you may want to subnet your VPC by looking at some of the advantages and benefits.

- Logical network division. When you create multiple networks it allows you to create logical network divisions between your resources.
- Security. By having multiple subnets with similar resources grouped together, as per the previous point it allows for greater security management.
- Accessibility. Having multiple subnets allows you to create both Private and Public subnets.
- Communication. You may want some of your subnets to route out the internet, some to remain private and some to communicate back to your corporate-on-premise network via VPN. Subnetting allows you to do this with the help of IWS routing.
- High availability. If your solution requires a level of high availability, it's best practice to deploy services across multiple availability zones within a region. Remember, a single subnet cannot span across two availability zones.

Once we understood the reasoning of benefits behind VPC subnets I delved into what a VPC subnet looks like within the management console and its associated components such as the network access control list. Here we learned that the subnet itself has five components.

- The summary, and this summarizes all the elements and metadata associated with the subnet. Such as the IPv4 CIDR block, the VPC the Asian and route table associated exception.
- The Route Table. This defines which route table that the subnet is using along with its routes.
- The NACL. The network ACSL shows the current NACL associated to the subnet displaying both Inbound and Outbound rule sets.
- Flow Logs. Shows you any Flow Logs that you have set up and created for the subnet to capture IP traffic flow information.
- Tags. And this allows you to add any custom key value pairs to help with the tagging of your subnet.

Following the definitions made in this lecture I then discussed the different kinds of subnets, Private and Public. Key points of this lecture.
- Public subnets have direct access to the internet. Whereas your private subnets do not.
- There are 2 components required to make a public subnet. An attached Internet Gateway to your VPC and a route pointing to the target Internet Gateway.
- By default, all subnets have the automatic assigned of public IP addressing turned off
- You can modify IP addressing behavior of a subnet using the 'modify auto-assign IP settings' option within the Management Console for your subnet.

Next, I focused on what consideration should be made when peering VPCs together from a subnet point-of-view. The key points here were that:
- VPC peering allows you to connect two or more VPCs together using IPv4 or IPv6 as if they were a part of the same network.
- The connectivity between the VPCs is implemented through the AWS network, and so it is highly valuable with no bandwidth bottleneck.
- Overlapping or duplicate CIDR ranges between VPCs cannot be peered together. Each AWS VPC will only communicate with its peer.

Following this, I then covered how to monitor your subnets using Flow Logs.

-Subnet Flow Logs can help you troubleshoot networking problems.
- They can capture IP traffic going into and out of your network interfaces.
- The log data can be sent to a CloudWatch Logs log group where you are able to filter information and monitor specific metrics.

To end this section on subnets I then demonstrated how to set-up and configure a VPC with both public and private subnets.

Following this, I then spoke about AWS routing. Starting by looking at AWS routing fundamentals and route tables. Within this lecture, we learned that:

- Routing provides a mechanism to allow a network packets to be forwarded to the correct destination.
- Within the VPC, all routing is configured via routing tables associated to your subnets which use virtual routers that are fully managed by AWS.
- An implicit router will be linked to your VPC as a part of your VPC creation process.
- A default route table, known as the Main Route Table is also created for your VPC.
- The Main Route Table cannot be deleted.
- When you create a new subnet, this Main Route Table will be implicitly associated to it unless you specify an alternate custom route table.
- A subnet can only have one route table association at any one time. Although, multiple subnets can all use the same route table.
- Subnets can either be explicitly or implicitly associated to a route table.
- Any route table can take over as the Main Route Table.
- A route in the route table has values for destination, target, status and propagated fields.
- The destination field shows CIDR block ranges for any network that you need to route to outside of your current subnet.
- The target field provides the gateway to allow you to get to that destination.
- The status shows the states of your routes within the table.
- The propagated field will determine which routes within the route table are propagated via a virtual private gateway.
- The local route in every route table allows all subnets within your VPC to route to each other.
- Subnets can be explicitly associated to a route table.
- Route propagation via a private gateway will automatically add routes representing your VPN connection to the route table if propagation has been enabled for that virtual private gateway.

Next, routing priorities were discussed to understand how overlapping routes within the same route table were managed.

- The rule of thumb is that AWS will use the most precise route available within the table to route traffic to a specific target.
- This is also known as the longest prefix match.
- There are some circumstances where the longest prefix match route is not selected.
- When propagated routes have overlapping destinations with your VPCs local route, then your VPC local route will have precedence even if your propagated routes have the longest prefix match.
- If you have any propagated routes with the same destination as any existing static routes then the rule of longest prefix match will not be applied. Instead, the following priority is executed against any static routes that have the following gateways as the target first. Internet gateway, virtual private gateway network interface, an instance ID a VPC peering connection, a NAT gateway and, finally, a VPC endpoint.

Next I started to look at different routing configurations for different scenarios.

Starting off with VPC peering.

- A peered connection if pre-fixed with pcx in the target.
- Routing must be set up on each side of the peer to allow each VPC to know where to route traffic to.
- Peering can only exist if the IP CIDR blocks do not overlap in anyway.
- Every subnet that requires connectivity to a peered VPC, a route must exist in the route table for that subnet pointing to the pcx.
- VPC peering does not support unicast reverse path forwarding.
- Use the longest prefix-match rule for any VPC that is peered to multiple VPCs that have the same CIDR block ranges.

Next was the routing configuration for VPN connectivity via a virtual private gateway.

-Virtual private gateways are used to help create a VPN connection between your VPC and your corporate network outside of AWS.
- Before you can set up a route for a VPN over virtual private gateway you need to create and attach a virtual private gateway to your VPC.
- To route across your VPN, you must update the route tables for any subnets that intend to do so using the target of your virtual private gateway.
- By enabling propagation on this virtual private gateway your route table will automatically include the routes used by your VPN connection.
- If you do not enable propagation, you will need to add static routes for all the networks used by the VPN connection that you want to route to.
- AWS does not currently support IPv6 traffic across a VPN connection.

Following this, I then looked at routing for Internet gateways and NAT gateways.

-The Internet Gateway, or IGW, provides a means of communicating out to the Internet.
- Once your internet getway is attached to your VPC, you have a gateway to the internet.
- The destination value in a route table of 0.0.0.0/0 essentially implies that for any destinations that are not known by the route table, then use this route.
- Any subnet which has a route table associated to that point is to an internet gateway is considered a public subnet.
- A NAT gateway allows instances within a private subnet access to the internet. However, access to the instances within these private subnets cannot be initiated from the internet.
- Instances in a private subnet must have a route to the NAT gateway which is located in the public subnet.
- Routing for a NAT gateway requires the use of a public subnet to be configured.

Then, finally, the last routing lecture I discussed was on VPC endpoints.

- A VPC endpoint is a virtual device which allows you to connect your VPC to another AWS service without traversing any gateway.
- Currently, the only supported endpoint is for S3.
- When communicating between the VPC endpoint and your VPC, the traffic remains inside the global AWS network.
- VPC endpoint routing is implemented automatically during the creation of the endpoint.
- The VPC endpoint creation will add a new rule with a new destination and a target value of the 'vpce ID' for the selected route table.

That has now brought me to the end of this lecture, and to the end of this course.

I hope it has given you a good understanding of some of the advanced AWS network concepts surrounding subnets and routing and has left you comfortable enough to start designing and architecting your own AWS network.

If you have any feedback on this course positive or negative, please do leave a comment on the course landing page. We do look at these comments, and your feedback is greatly appreciated.

Thank-you for your time and good luck with your continued learning of Cloud computing.

Thank-you.