AWS DevOps Pro Certification Blog Post Series: Amazon Single Signon, CloudFront, Autoscaling and Route53


This is part of the blog post series: AWS DevOps Pro Certification

Caveat emptor

Using AWS costs money, some of these services may not be part of the AWS Free Tier. You can keep costs down by tearing down anything you've created whilst learning, but it's still possible to run up a hefty bill so pay attention to the instances you setup!

I'm very lucky to be able to use my employer's AWS account. You should ask your place of work if a similar arrangement can be made as part of your study.

Velocius quam asparagi conquantur

The format of the blog posts is liable to change as I try to refine my mental model of each domain, so be sure to revisit the blog posts on a regular basis.

What?

Amazon Single Sign-On is a managed single sign-on (SSO) service that you can use to simplify access to applications and 3rd party services. If SSO is not a term you're familiar with, if you've ever signed up for a service using your Google, Facebook or Twitter account (instead of using your email address and password specific to that site) then you've used SSO.

Amazon CloudFront is a managed Content Delivery Network (CDN) service, you may have heard of CloudFront's competitors like CloudFlare, Akamai and Fastly. CDN speed up your website performance by strategically placing mirrors of popular content (static files, API or streaming audio/video) at locations nearer to the user accessing your website. These mirrors are referred to as Edge locations popular content for the region (not specific to client) is cached here. In more densely populated areas there are also Regional Caches that hold content for longer than Edge locations.

Amazon Route53 is a managed Domain Name Service (DNS). At its very basic level of functionality DNS servers allow you to connect to servers using friendly domain names i.e. dev.to rather than IP addresses like 151.101.123.4, 151.101.12.34, 151.101.1.234. It's designed to work with other Amazon Web Services that is you can point DNS records directly to Elastic Load Balancer, S3 and EC2 instances.

Autoscaling as we saw in the Domain intro comes in two varieties: AWS Auto Scaling and Amazon EC2 Auto Scaling. The general rule of thumb for use if you want to just autoscale EC2 instances then use EC2 Auto Scaling service, otherwise, AWS Auto Scaling is a better use case for when you want to scale multiple resources (not just EC2) i.e. DynamoDB tables and indexes, ECS tasks.

An important thing to note that to use AWS Auto Scaling, your resource must be created using CloudFormation or Elastic Beanstalk.

For the rest of this post, we'll only be referring to Amazon EC2 Auto Scaling.

Why?

Amazon Single Sign-On or generically any single sign-on (SSO) service is better than managing the administrative overhead of keeping separate logins for each application / service, you reduce the impact on day to day operations should disaster strike (think the number of helpdesk tickets will be raised for DR systems that rarely get used). You'll also get the undying love of your users because it means fewer logins to track, which in turn means they will be less likely to keep a scrap paper lying around their desk with the various logins and passwords written down.

Amazon CloudFront distributes your content geographically rather than storing in a single location or S3 bucket. By careful design (falling back graceful should the backend be unavailable) ensures your website is highly available.

Amazon Route 53 provides the following routing policies whose attributes are suitable for this domain:

Amazon EC2 Auto Scaling allows you to launch or terminate a number of EC2 instances by defining conditions when scaling out (increase) or scaling in (decreasing) the number of instances. The condition might be metrics like CPU or Memory utilisation, or health checks. This combined with an elastic load balancer provides a system that can be highly available and fault tolerant.

Terminology to be aware of:

When?

Amazon Single Sign-On should ideally be implemented as soon as possible, but it's still possible to retrofit into an existing environment. Doing this soon rather than later could mean you're not having to re-organise the team who are responsible for user and access management if the headcount reduces because of efficiency savings through the implementation of SSO.

Amazon CloudFront should be implemented once you have some metrics (via Amazon X-Ray or something similar) to indicate you have customers in regions that are experiencing poor response times because of their proximity in relation to the region where your load balancers, EC2 instances or S3 buckets are hosted.

Amazon Route 53's routing policy provides a lot of desirable features that are relevant for this domain. This combined with the fact that Amazon also offers an [SLA] of 100% availability and the ability to create and modify DNS record programmatically mean the use of Route 53 is a bit of a no-brainer.

Amazon EC2 Auto Scaling has the concept of lifecycle hooks. These allow you to perform custom actions by pausing the instances as the ASG launches (EC2_INSTANCE_LAUNCHING) or terminates (EC2_INSTANCE_TERMINATING) them. Whilst the instance is paused, it is in a wait state until you complete the action by issuing the complete-lifecycle-action action in the CLI/API or the timeout period ends (one hour by default). You can extend the timeout period by either:

The maximum time you can place an instance in a wait state is 48 hours or 100 times the heartbeat timeout (whichever is smaller).

How?

Amazon Single Sign-On requires an AWS Organization to exist and then you can enable single sign-on via the AWS Console. The specifics for setting up the service with the AWS Account or Cloud Applications (3rd party services) can be found in the [guide][sso_guide]. There is an option to link to your existing Microsoft Active Directory, but if you don't need this option then the service will use its own directory.

Amazon CloudFront to setup you define a distribution that determines the content origins (S3 bucket or HTTP server), access, security (TLS/SSL/HTTPS), session/object tracking, geo restrictions and logging. The provisioning of CloudFront can take a while as the content is being distributed to edge locations.

I've found the following article in the AWS blog very helpful in terms of an application that I was already familiar with, but also knew the difficulty in optimising for response time: How to accelerate your WordPress site with Amazon CloudFront

Amazon EC2 Auto Scaling terminology:

API and CLI features and verbs

Amazon Single Sign-On

This service has no API/CLI.

Amazon CloudFront

Features

Verbs (CRUD)

Outliers

Amazon Route 53

I've opted for the main API/CLI for Route 53 instead of Domains and Resolvers as I've been using this more on a day to day basis.

Features

Verbs (CRUD)

Outliers

EC2 Auto Scaling

Features

The API has a lot of features, but the API actions I've focussed on have been around the Lifecycle Hooks.

Verbs (CRUD)

Outliers

AWS DevOps Pro Certification Blog Post Series



Tweet