EC2 and AutoScaling

EC2 and the Developer Associate Exam

When I completed the AWS exam the questions in EC2 weren’t extensive, but you do need a decent amount of knowledge of the workings so you’re not caught out. This week I’ve set things out a little differently. There are two sets of tables based on your existing experience. There’s a ‘refresher’ and ‘newbie’ section below.

If you want to test yourself on the ‘exam level trivia’ of EC2 then the exam guides from Whizlabs will help you nail it. I can recommend those tests as a resource that helped me tighten the gaps I had from my day job/studies. (I get an affiliate commission for those).

For those of you that want a distilled set of tutorials, this course (which I don’t get commission for) comes highly recommend, including from the AWS Certification community on Reddit. It’s not cheap, but if you can afford it it (or are able to claim back on tax) it’s worth considering as, all your practical lab needs can be found in one place. It’s a time and money trade off.

It’s fine to carry on with this study plan of course, but you’ll need to seek out your own tutorials from the resources given. Again I’m just pointing out the time to money trade off you may want to consider in terms of hands-on experience.

Regardless of our means of tuition though, our focus here is focus on fundamentals and then be able to recall them for the exam. And since EC2 has not been completely overtaken by serverless yet, it would also be something we need to know about in your day job.

Refresher (if familiar with EC2)

I made this summary table for those of you who have already had exposure to EC2.

Overview (EC2 Newbies)

And for those of you who also want to learn the fundamentals, have a refresher, go with these tutorials on top of the above.

EC2 Overview

I’m going to go out on a limb and assume you don’t need cloud computing explained to you at this stage of the course, nor the idea of ‘pay as you go’ computing. You’re probably also aware that AWS promote of lot of Serverless solutions for greenfield projects. But the humble EC2 instance still features in a lot of our day jobs.

So to get started, just read through the first page here. This is actually great because it gives us all we need for a top level view of the world of EC2. In a post I wrote recently, forming connections before we prime the brain is a great way to get going. So we’re all on the same page before we start, we can look at making connections.

An instance is the ‘unit of currency’, one runtime that has been built out to run some app.

You can use templates called AMIs to build images (like the same way a Dockerfile builds an image) and then launch these (like a container is launched from an image).

We have configuration as an abstraction (think T-shirt sizes in Agile) to specify the RAM/CPU/Network capacity. This stops us having an explosion of permutations – one AMI has multiple configurations, not a seperate AMI for small/medium/large.

Storage can be temporary (like when a docker container that isn’t committed back to an image), or permanent (like a volume mounted outside of docker).

We have first class citizens in AWS to do firewalling, namely Security Groups and Network Access Lists.

Tags exist for many reasons, but in an enterprise, billing is a common use case for them – tagging lets us see which team is using what.

Elastic IP addresses are needed for the instances to be reached by load balancers and the outside world.

Virtual networks (VPCs) are where these instances run.

Tutorial

Follow the getting started page here with the following tutorial and be sure to clean up after yourself! It will give you experience of the useful concepts of connecting via SSH, how Security Groups affect that and an app server that needs to communicate with a DB Server in many practical EC2 scenarios in the workplace.

EC2 Security

There are a few parts to this, this diagram shows the role of both Security Groups and Network Access Control Lists (NACLS). Note that that the Security Groups are at the instance level.

Also notice the following about security group sg-1a2b3c4d:

• The 3 instances EACH have a security group applied to them.
• There is an inbound rule that allows access from a host that is using SSH, from a sole instance (172.31.2.2/32, which happens to live outside of the VPC).
• SSH traffic is allowed out as a reply because Security Groups allow replies – there is no explicit OutBound rule. However, none of the EC2 instances can initiate an SSH communication outside of the Security Group.
• There is also a second inbound rule that allows access to any hosts belonging to security group sg-1a2b3c4d – in this case you can think of the host being ‘anything that has security group sg-1a2b3c4d assigned to it’.
• Any instance that has security group sg-1a2b3c4d assigned to it is not stopped from initiating comms outside of the SecurityGroup. This would be important for something like an EC2 instance that needs to talk to a DB. And that DB often lives in a different subnet altogether.
• Finally an interesting quirk to be aware of. If we added a third inbound rule to the sg-1a2b3c4d group and said “All traffic sg-5b3d4e6a” – what do you think would happen to the security group sg-1a2b3c4d? It wouldn’t actually apply extra rules rules from sg-5b3d4e6a as you might expect at a first glance. In fact you’re actually saying ‘if you’re a host assigned to sg-5b3d4e6a, come on in, you have a free pass’.

On the other hand Network Access Control Lists are at the subnet level. So in this case there is a different set up to a security group.

• We have to allow SSH traffic in and out with ALLOW rules – fail to put the Outbound 172.31.2.2/32 ALLOW rule in place, and your SSH connection won’t happen.
• Nothing can reach outside of the 10.0.1.0/24 subnet as there are inbound and outbound DENY rules.
• All the rules of the network list are evaluated before access is considered, a single DENY stops access.

This is relevant for 2 reasons.

• You want to understand (to troubleshoot) if something is being blocked by a subnet rule, or an instance (Security Group) rule.
• You want to understand the way that the rules are applied – since these are different.

I’ve summarised those differences here.

Network Security is covered more fully here and Security Groups are covered here.

Load Balancing

I’m sure load balancers are a familiar enough concept for most, simply because they’re multi-purpose. Not only can you ensure that individual instances don’t get overwhelmed during your day-day running, they provide an architecture for ascertaining whether new instances are healthy before cutting over to them in a deployment.

The types of balancer

From the guide here we can see that Elastic Load Balancing supports three types of load balancers:

• Application Load Balancers
• Network Load Balancers
• Classic Load Balancers

the difference being whether you register a target group of instances (Application and Network) or individual instances (Classic) with the load balancer.

Target groups and Availability Zones

Again, I encourage you to do your own reading, but to help you visualise take a look at the diagram belows.

Cross Load Balancing

This is an interesting concept and when I read about it, I had an instinctive feel it’s the sort of thing that just leads itself to exam trivia. Simply put look at the load balancers below.

• There is one for Availability Zone A and one for Availability
• There are 2 targets in Availability Zone A
• There are 8 targets in Availability Zone B

The difference is in the detail. Cross load balancing means each target gets 10% of the traffic, because each load balancer can access targets outside of its own availability zone. Without it, a load balancer can only route it target instances in its own zone. Put another way

• With cross-zone, each node gets 10% of the traffic
• Without it 50% of the traffic goes to zone 1 and then 25% of the overall traffic goes to each node
• Zone 2 gets 50% of the traffic to the load balancer and the 8 nodes get an 6.25% of the overall traffic – i.e. 50/8.

Target Groups and Listeners

For both Network and Application load balancing, at least an understanding of target groups is needed, since that’s how the conversations happen between EC2 and the load balancers. A useful components diagram is here.

• You register a target group as a set of instances that can be used interchangeably
• You set up listener rules to send to the target group when certain conditions are met.
• The listener then is responsible for collaboration between the load balancers and the target group, by using its set of rules
• Path based routing is one common example – where the rules registered with the listener are essentially saying ‘yeah I have targets that match this path’
• There is a ‘target-group-level’ health check – the load balancer uses this to constantly monitor the health of each target in the group, and take them in and out of service as required.

Certificates and SSL Termination

Finally there is a very important kind of listener, the HTTPS one – since connections to the load balancer from clients are invariably encrypted. In terms of exam questions etc.. just be aware of the pattern of registering certificates with the ELB so that the expensive computation can be done in one place. That’s explained well here. Then the targets themselves can process unencrypted traffic if desired.

Load Balancing Exam Points

• Have a quick skim of the overview of AWS Certificate Manager to see terms how how this certificate is administered
• Be aware of that CloudWatch metrics is the key player for communicating instance health back to the ELB – again skim to understand this.
• Skim this Route 53 doc to understand how DNS is the ‘front door’ to your load balancer (from web traffic at least) – remember that load balancers aren’t quite as ephemeral as underlying instances but they ARE less permanent than domain names.
• Skim the overview on WAF to at least know that this is an option for protection of your load balancer. This falls into the ‘exam trivia’ category.

AutoScale Groups

Elasticity and autoscaling go hand in hand. The ability to scale something in response to demand is elasticity, and autoscaling is the way to make this happen without human intervention (by use a policy).

Note that desired capacity is a ‘snapshot’ between the minimum and maximum instances. The important logic to understanding is here, explaining that desired capacity is just on part of the scaling puzzle – all that does is keep the number of instances at a certain level.

If there are no other scaling conditions attached to the Auto Scaling group, the group maintains this number of running instances even if an instance becomes unhealthy.

However with an autoscale policy in effect (for example firing when an instance is a 50% CPU capacity) the desired count shifts automatically – within the max and minimum constraints. I’d read and understand the dynamic scaling page and understand Target Tracking Scaling Policies and Step and Simple Scaling Policies so that you don’t get caught out my subtly different multiple choice options in the exam.

AutoScaling Configuration

Scaling plans are the magic that let you specify the when and the what (i.e. the policy) against the which (the resources). You can apply a plan against:

• A CloudFormation stack – in other words, you can apply a policy at the stack level – not having to set up a policy for each of the EC2 instances, DB Instances, DynamoDB instances under a stack. Since a stack is a ‘logical whole’ – scaling is applied as such.
• Tags are another way of achieving this – resources that ‘share’ a tag can be scaled as one logical whole.
• Or you can just add an EC2 Auto Scaling group to a plan – so just as we use for deploy/cutover, we have a nice ‘unit’ we can apply for spinning up and down.

Autoscale Group and Target Groups

I think of the relationship between the two groups as:

• An Auto Scaling group acts upon instances in a Target Group
• This is where they are removed from/added to based on policy rules and actual load.

A read through of this section may help to clarify this. Let’s check a few more points on the exam trivia next.

Exam question overview

I’d be looking to understand:

• What kinds of resources are autoscaling applicable to? Have a look here for a heads up, but bear in mind it’s not just EC2.
• However, also bear in mind that serverless technology is not on this list. We’ll cover how they get scaled another week, but remember that scaling groups don’t apply ‘as such’ to serverless.
• Exam questions might want you to compare availability and cost – which policies apply to which? Which are a blend/compromise?
• What are common use cases for scaling? Think about patterns of how your business might run.
• How do availability zones with work auto–scaling groups?
• Understand the difference between dynamic and predictive scaling and how they work.

Conclusion

EC2, ELBs and target groups are closely related in terms of delivering solutions at scale so it pays to have an understanding of them. Remember, we want to do the job, not just pass the exam.

If you’re just after exam pointers, hopefully the question sheets I’ve provided over the last few weeks are of use to you. I have a study plan offer where you can get all the study plan flashcard sets for free when you buy your exam papers through my Whizlabs link.

Remember that my question sets are generated around ‘meta’ principles. In other words – the questions will fall into categories like ‘Best Practice’, Cost-Saving, Troubleshooting, Scalability and so on. Other times they will just be necessary ‘exam trivia’.

I hope you found this week useful. Please feel free to give feedback as ever. Next week we’ll look at VPCs and Security groups in more detail.