VPC Security and Control
The course is part of these learning pathsSee 6 more
This course has been designed to give you an overview of the AWS Virtual Private Cloud and its associated networking components. This will help you to architect and build your VPC for a variety of different workloads and use cases. The topics covered within this course include:
- Virtual Private Clouds (VPCs)
- Route Tables
- Network Access Control Lists (NACLs)
- Security Groups
- NAT Gateways
- Bastion Hosts
- VPN and Direct connection
- VPC Peering
- AWS Transit Gateway
Who should attend this course?
Those who are relatively new to AWS to gain a better understanding of how to construct and architect virtual private cloud
Those looking to learn more about AWS networking features and components
Those studying for the AWS solutions architect certifications
- Confidently architect a VPC across multiple availability zones within a Region
- Explain different networking components commonly used within AWS VPCs
- Secure your VPCs, helping you to protect your resources within them
- Assess which method of connectivity to your VPCs would be best in different scenarios
To get the most from this course then you should have some exposure to AWS, for example, EC2, however, this is not essential.
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 firstname.lastname@example.org. 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.
About the Author
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 80+ courses relating to Cloud, mostly within the AWS category and with a heavy focus on security and compliance.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.