VPC Security and Control
Basic Networking Concepts
VPC Sharing using the AWS Resource Access Manager
Inter-Regional and Intra-Regional Communication Patterns
Understanding Direct Connect, Implementation and Configuration
Understanding AWS Direct Connect - Connectivity Options
Examining AWS Routing
DNS & Content Delivery on AWS
Managing Public and Private SSL/TLS Certificates using AWS Certificate Manager
The course is part of this learning path
This section of the AWS Certified Solutions Architect - Professional learning path introduces you to the core networking concepts and services relevant to the SAP-C02 exam. We start with an introduction to the AWS Virtual Private Network (VPC) and networking services. We then understand the options available and learn how to select and apply AWS networking, DNS, and content delivery services to meet specific design scenarios relevant to the AWS Certified Solutions Architect - Professional exam.
- Get a foundational understanding of VPCs, their security, and connectivity
- Learn about VPC sharing using the AWS Resource Access Manager
- Discover inter-regional and intra-regional communication patterns in AWS
- Learn about AWS Direct Connect, along with its implementation, configuration, and connectivity options
- Understand routing in AWS, including static and dynamic routing
- Understand the basics of networking, including Elastic IP addresses, Elastic Network Interfaces, networking with EC2, VPC endpoints, and AWS Global Accelerator
- Learn about the DNS and content delivery services Amazon Route 53 and Amazon CloudFront
In this section, we will discuss two examples of using CloudFront to cache and secure access to content.
Pattern 1 – Using CloudFront to cache and secure content when an Application Load Balancer is the Origin.
In this pattern we have an Application Load Balancer, load balancing HTTP port 80 and HTTPS port 443 traffic to a set of EC2 instances hosting a website. To integrate with CloudFront we would create a CloudFront distribution with the application load balancer as the origin. It is worth remembering that CloudFront can work with any public endpoint whether AWS or external. This Load Balancer will be an internet-facing load balancer.
For this pattern to work, we will need to do a couple of things.
Work with Route 53
Secure connections to the application load balancer
Originally the nice friendly name for your website will be mapped to the name of the application load balancer, but now we want the friendly name of your website to route people through CloudFront. For this to work, we need to edit the Alias record in Route53 to map the friendly name to the DNS name that CloudFront has provided you when you created your distribution. Remember we are using an internet-facing load balancer, so if someone knows the DNS name of the load balancer or its IP addresses then they might be able to connect to load balancer directly, bypassing your CloudFront distribution and the performance and security benefits it provides. To secure the connection between our CloudFront distribution and the Application Load Balancer we can do the following:
Firstly, Configure CloudFront to add a custom HTTP header to requests. When creating or editing your CloudFront distribution add a custom header. The custom header will be included in each request sent to the origin. Next. Configure an Application Load Balancer to only forward requests that contain a specific header. To do this we need to select the listeners configured on the load balancer and edit its rules. We then adjust the rules:
Rule 1: if the custom header is included in the request forward traffic to the target group.
Rule last: If the request does not include the custom header then return a 403 error.
With everything saved, if someone tries to access your website using the Application Load Balancers hostname or IP Addresses they should see a 403 error similar to the error below. By using HTTPS for origin requests we are configuring an encrypted connection between our distribution and the Load Balancer. This will help keep your custom header secret. This setting is configured on your CloudFront distribution and requires the appropriate secure listener to be configured on your Application Load Balancer. It is important you rotate the custom header in your distribution and on the load balancer. If you do not rotate the custom header then over time there is a greater chance that the header name and value will be discovered undermining your security.
To do this:
Add a second custom header to the CloudFront distribution
Add a new rule to the load balancer listener that uses the new custom header as the condition and forwards traffic to the target group
Remove the old custom header and rule from the cloudfront distribution and the load balancer listener
Pattern 2 – Using CloudFront to cache and secure content when an S3 bucket is the origin
Using S3 to deliver content is a common feature of many AWS Architectures, in S3 content is stored in buckets and buckets are in a single region. Because of this your applications can suffer from latency issues if you have customers globally who need to access content from a centralized bucket. CloudFront can help solve this problem by allowing content to be cached closer to the users who need to access it. We can also use S3 to host a website, this has lots of advantages, one of which is we no longer need compute resources such as EC2 to host our static content. When using S3 to host static content we:
- Create a bucket and enable it for static website hosting
- Then Enable public read access on the bucket
You will be given a URL that can be used to access your index document, S3 only supports HTTP access when using static website hosting. We have several problems here.
What if you wish to use HTTPS instead of HTTP?
What if you don’t or can’t allow public access to content?
What about latency? Our website is still stored in a bucket in a single region
CloudFront can solve these issues.
- CloudFront can distribute your content globally reducing latency for your customers.
- When we create a CloudFront distribution we can add an alternate domain name and a certificate allowing us to use or even enforce HTTPS.
- We can also remove public access to the S3 bucket and secure access so that only the CloudFront distribution can access content.
To enable HTTPS you will need a digital certificate. AWS provides the AWS Certificate Manager service (ACM), through which we can request digital certificates for free. Using ACM we can request internal certificates or trusted public certificates. If you are planning on integrating your CloudFront distribution with AWS Certificate Manager (ACM) please keep in mind that CloudFront works with ACM in the North Virginia region. It is from here that you should create your certificate requests.
To make sure that only your distribution can request content from your S3 bucket and to allow you to remove the public access that static website hosting needs, we use Origin Access Identity (OAI) and S3 Bucket Policies. This process is important, without it users could still use the bucket's URL to access your content, by passing the security and performance benefits of CloudFront.
Begin by creating an Origin Access Identity (OAI) in cloudfront and then associate it with your CloudFront distribution. Here you can see an OAI that has been created in the CloudFront console, notice the Name and ID. Next, you can see that we have associated the newly created OAI with our distribution
You can then select the option to automatically update the bucket policy of the S3 bucket or you can edit the bucket policy yourself. Here we can see the bucket policy that would be created on the S3 bucket that contains our content. We can see that the principal is the ARN of the OAI and that the effect is set to allow. You can adjust the actions as required, here we are allowing the S3.GetObject action on the bucket.
Finally, notice that public access is blocked. If someone was to obtain the bucket url and tried to access content using the url they would receive an access denied message. But if they use your friendly name mapped to the CloudFront distribution DNS name then access will be allowed. Here is an example of how that record might look in Route 53, we use an alias record mapped to the distribution DNS name.
Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.