Figure 1: Auto-scaling
Auto-scaling is applied to all Elastic Cloud Compute (EC2) instances in the public subnets. This takes care of scaling for us based on certain load criteria.
The default setting recommendation for the auto-scaling groups is Balance availability and cost. Furthermore, by default, only EC2 instances should be part of the auto-scaling group. However, if needed other resources can be configured to be added to the group.
At this point in the project, it is unknown what metric would best serve Farmacy Foods' best interests. At this point we would advise:
- CPU utilization > 75%
- Memory utilization > 85%
Metric reporting is crucial to guide your choice of scaling options.
Figure 2: Load balancing
Figure 2 shows instance 1 to instance n. For the purpose of this document, we intend this to mean N instances of a particular resource in the ASG.
Amazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. [...] Amazon Route 53 effectively connects user requests to infrastructure running in AWS – such as Amazon EC2 instances, Elastic Load Balancing load balancers, or Amazon S3 buckets – and can also be used to route users to infrastructure outside of AWS. You can use Amazon Route 53 to configure DNS health checks to route traffic to healthy endpoints or to independently monitor the health of your application and its endpoints.1
The Application Load Balancer provided by AWS is responsible for distributing traffic among our internet-facing services and EC2 instances. For some services, we do this indirectly by using the Auto Scaling Group (AGS). The ALB is a request level load balancer. (Layer 7)
Using the ALB allows us to balance on the basis of an application interface. In our case this mostly means that we can have, REST API, resource bound load balancing. This is includes application specific resources but also resources on the authentication api provided by Cognito. (See: Authentication)
In Figure 2 we see two rules in the ruleset:
- Redirect HTTP to HTTPS.
- /Ordering
The first rule is responsible for redirecting HTTP based traffic to HTTPS. In essence, this stops the use of HTTP. The second rule is used to forward requests to /Ordering to a certain endpoint. We also apply this forwarding rule type when we, for instance, want to route in a balanced wat to an Auto Scaling Group or a resource on the Cognito API.
Another advantage of the ALB is the native ability to force HTTPS connections only. We do this by making use of a configurable rule in the rulesets of the load balancer.
The AWS Certificate Manager is used to store TLS certificates. In our case, we use ACM to store both Certificate Authority acknowledged certificates and private certificates. The latter is used for development and test environments.
A listener is a process that checks for connection requests, using the protocol and port that you configured. You can configure HTTP or HTTPS on the standard port but you could also add additional listeners on non-standard ports.
Rulesets are attached to an ALB and contain rules that can be used to perform specific Actions on incoming requests. We use this to:
- redirect a non-authenticated user to Cognito for authentication.
- check a JWT against Cognito to verify the correct authentication of the user. (Redirecting the user when the JWT is not valid.)
- forward traffic to the scaling group based on the requested resource path.
We use target groups to point to the actual resource behind the ALB. For instance, our ASG, an EC2 instance or any other kind of service resource that we want to be internet-facing.