Hello and welcome to the final lecture of this course where I want to quickly summarize what we've covered throughout the previous lectures. 

Being able to architect your own isolated segment of AWS is a very simple process. However, understanding how to architect the VPC and its related network components and connectivity makes it a very powerful service. And so this course was intended and designed to give you an overview of what a virtual private cloud is, along with some of the network components.

I started off by explaining what a VPC is and how it fits within the AWS public cloud. The VPC can be defined as an isolated segment of the AWS network infrastructure, allowing you to securely provision your cloud resources. 

This then led onto a discussion surrounding subnets. I explained that subnets allow you to segment your VPC CIDR block, forming smaller network segments across multiple availability zones within your VPC region. This then helps you to isolate, organize, and manage your resources in addition to helping you implement resilience and high availability. 

I also touched on what an internet gateway is, and I explained that this is an AWS managed component attached to your VPC, and it provides a connection between your isolated VPC and the outside world, essentially the internet. To enable a subnet to use the internet gateway, it needs a route. 

Now, route tables enable you to configure where and how to route your network traffic based on its destination via different targets, such as an internet gateway, a NAT gateway, or virtual private gateway. 

I then shifted my focus to look at the security of a VPC. I began looking at network access control lists, more commonly known as NACLs. These effectively act as a logical firewall providing network level security at the subnet level. And they are stateless by design and provide a rule base allowing you to stipulate both the ingress and egress traffic based on protocols. And these rules have an action associated that will then either allow or deny the traffic. 

Keeping with security, I then spoke about security groups, and these are similar to NACLs in many ways, but they operate at the instance layer instead, providing a level of security to your instances residing within your subnets, again based on defined protocols. Now, security groups are stateful. And any rules within the rule based are considered allowed as security groups do not offer a deny function like NACLs do. 

Next, I touched on NAT gateways, and these allow instances located within a private subnet to access the internet, allowing them to download and perform patch updates for maintenance. Now, the NAT gateway prevents any inbound connection that is initiated from the internet, which helps to protect your private resources. The NAT gateway itself is located in a public subnet and is a managed instance provided by AWS. The final part relating to security in your VPC that I covered was the use of bastion hosts. 

Now, a bastion host is a secure and hardened instance that resides in the public subnet of your VPC. It has very restrictive security controls allowing restricted inbound connection from known and trusted IP addresses, usually using SSH or RDP protocols. And these security protocols then allow your engineers to perform a remote and secure connection to the bastion host where the instance acts as a jump server allowing engineers to SSH or RDP into instances residing in your private subnets. 

Following security, I began looking at connectivity options for your VPC to connect to remote locations, and then is when I discussed VPN connectivity. Now, a virtual private network or VPN connection allows two networks to securely connect to each other across the internet. You could use a VPN connection to allow your remote office or data center to connect your VPC, allowing traffic to move between both networks. Now, a Direct Connect connection also allows you to connect your VPC to remote office or data center. However, this connection is established across dedicated and secure infrastructure rather than the public internet. And this connection goes from your remote location to a Direct Connect location, which is usually managed by an AWS partner using dedicated infrastructure. From here, the connection is then made to the AWS network, allowing a secure and private connection to your VPC. 

I then looked at VPC peering. Now, VPC peering allows you to connect two VPCs together using the internal AWS infrastructure as if they were on the same network. There are some key points to bear in mind, mainly that the two VPCs are not allowed to have overlapping CIDR blocks, and VPC peering provides a one-to-one connection and so does not allow transitive peering to a third VPC. For example, if you have three VPCs connected, VPC one connected to VPC two, and VPC two connected to VPC three, then VPC one would not be able to connect to VPC three. You would have to either set up another peer between VPC one and VPC three or implement the AWS Transit Gateway. 

Now, the AWS Transit Gateway allows you to form a one-to-many relationships with your VPCs in addition to your remote networks as well. The Transit Gateway acts as a central hub within your network, allowing all VPCs and remote offices to connect to it. And this configuration simplifies multiple peering connections and reduces the overall connections required across your infrastructure, including those from remote locations as well. 

That has now brought me to the end of this course, and so I hope now that you have a clearer understanding of VPCs and its related network architecture. 

If you have any questions or feedback, positive or negative, please do get in touch with us here at Cloud Academy by sending an email to support@cloudacademy.com. Thank you again for taking the time to watch this course. I thoroughly enjoyed creating it. So that just leaves me to say good luck with your continued learning of cloud computing and thank you.