This course covers the core learning objective to meet the requirements of the 'Designing Compute solutions in AWS - Level 3' skill
- Evaluate and enforce secure communications when using AWS elastic load balancers using HTTPS/SSL listeners
- Evaluate when to use a serverless architecture compared to Amazon EC2 based upon workload performance optimization
- Evaluate how to implement fully managed container orchestration services to deploy, manage, and scale containerized applications
Hello and welcome to this short lecture which will provide a high-level overview of server certificates and how they are used within your elastic load balancers.
As I mentioned in the previous lecture the Application Load Balancer provides a flexible feature set for your web applications running the HTTP or HTTPS protocols. As such, the ALB listener options available when creating your ALB are either the HTTP or HTTPS protocol on port 80 and 443 respectively. Configuration of your HTTP port 80 listeners is a fairly simple process, and I'll cover this in the next lecture. However, there will times when you would need to use the HTTPS encrypted protocol as a listener and this requires some additional configuration.
So let me run through some of the points when using HTTPS as a listener. HTTPS is an encrypted version of the HTTP protocol and this allows an encrypted communication channel to be set up between clients initiating the request and your Application Load Balancer. However, to allow your ALB to receive encrypted traffic over HTTPS it will need a server certificate and an associated security policy.
SSL or Secure Sockets Layer, to give it its full name, is a cryptographic protocol, much like TLS, Transport Layer Security. Both SSL and TLS are used interchangeably when discussing certificates for your Application Load Balancer. The server certificates used by the ALB is an X.509 certificate, which is a digital ID that has been provisioned by a Certificate Authority and this Certificate Authority could be the AWS Certificate Manager service also known as ACM. This certificate is simply used to terminate the encrypted connection received from the remote client, and as a part of this termination process the request is then decrypted and forwarded to the resources in the ELB target group.
When you select HTTPS as your listener, you will be asked to select a certificate using one of four different options available. Either choose a certificate from ACM, upload a certificate to ACM, choose a certificate from IAM, or upload a certificate to IAM. The first two options relate to ACM. An ACM is the AWS Certificate Manager and this service allows you to create and provision SSL/TLS server certificates to be used within your AWS environment across different services. This integration with ACM simplifies the configuration process of implementing a new certificate for your elastic load balancer and as a result, it's the preferred option.
The last two options allow you to use a third-party certificate by using IAM as your certificate manager and you would select this option when deploying your ELBs in regions that are not supported by ACM. For a list of supported regions, please see the following link. For detailed information on how to upload, retrieve, and list server certificates via IAM, please see the following AWS documentation. Using ACM as your certificate manager allows you to both create certificates from within ACM itself and also import existing certificates created from outside of AWS adding additional flexibility for your current third party certificates. The configuration of ACM is out of scope for this course. However, you can find further information on this service using the following link.
Now it's brought me to the end of this lecture. In the next few lectures I shall be looking at the configuration of each of the defined load balancers, application, network, and classic, to provide you with more information on their components starting with the Application Load Balancer, the ALB.
Software Development has been my craft for over 2 decades. In recent years, I was introduced to the world of "Infrastructure as Code" and Cloud Computing.
I loved it! -- it re-sparked my interest in staying on the cutting edge of technology.
Colleagues regard me as a mentor and leader in my areas of expertise and also as the person to call when production servers crash and we need the App back online quickly.
My primary skills are:
★ Software Development ( Java, PHP, Python and others )
★ Cloud Computing Design and Implementation
★ DevOps: Continuous Delivery and Integration