This post will discuss how to achieve high availability in aws and focus on high availability and scalability for the associate AWS solutions architects exam. But, first, we will go over four essential questions we need to ask ourselves in the exam, where we end up with a question that appears to connect to Scaling and high availability.
How to achieve high availability in aws:
The following questions will help us for the associate aws solutions architects exam and also understand how to achieve high availability in aws.
First: Is it highly available?
We consistently desire to pick answers that contain high availability on them. Even if the question isn’t explicitly questioning: Is this solution highly available? We still hope to gear ourselves toward choosing highly available answers unless we are shown the condition that explicitly screams out that we do not require high availability. Although it only focuses on cost, we always want to be convinced that our resources can resist failure and spread out across those numerous availability zones.
Horizontal or Vertically Scale?
Whenever we notice a scaling situation question, we have to ask ourselves, should this be horizontal or vertically scaled? As discussed in those previous posts, we typically focus on horizontal Scaling because we can continue to create more resources. It allows us to achieve more highly available, where vertical Scaling changes the size of that instance and has that genuine limitation. That doesn’t suggest that we never want to scale vertically on the exam. You might notice a question that states, we want to improve that network throughput for that t2.nano instance. The most excellent honest answer there is you must scale it vertically. It would be best if you upsized that to an instance that is more usable. So we generally want to prefer horizontal, but that doesn’t imply we consistently wish to choose Vertical Scaling.
Now let’s see our next question related to high availability and scalability for associate aws solutions architects:
Next question: Is cost-friendly this scaling solution?
We must always consider the cost, even if the question is not explicitly highlighted for a cost-effective solution. For example, you might notice a question that states, how do we scale out this architecture? And one of the answers is we require to create a collection of instances using a huge instance c5a.24xlarge types. Would that technically resolve the problem? Yes, but that will be an expensive solution, a lot more money than it should be. In scenarios like this, we need to balance: how much will the solution cost? Does it match the problem we’re being provided with?
Could we change our database to resolve our problem?
It is general knowledge that changing databases is a highly complex job to achieve high availability in aws on the databases side. But, there’s no easy way to push to shift from a relational database to a NoSQL database. However, in the beautiful world of AWS questions on the exam, we can notice some questions without real work. So when you’re examining a case, if it states, possibly we control that relational database that’s just falling over. We’re paying money considerably, and we need something more elastic; we might want to believe that the DynamoDB alternative would work for us. We can pick an answer that does that migration even though accomplishing that migration would be a massive commitment for our team.
Now that we’ve got those four questions and scenarios in mind, let’s go through some straightforward tips focusing on auto-scaling.
Our first point to keep in mind is:
Auto Scaling is exclusively for EC2 instances. There is no other service on AWS that could add an Auto Scaling Group. Therefore, it cannot be utilized to attach load balancers, lambda, RDS databases, or Fargate, for example.
Some of those services we saw can scale, but that is different and separated from those EC2 Auto Scaling groups. And this is a typical trap. Also, you might be presented with a scenario question that states, we’ll scale the RDS database by utilizing an Auto Scaling group. And that’s not imaginable.
Create your own AMIs to decrease provisioning times
It’s a common question with scenarios that present us: How can we improve our Auto Scaling groups? And one of the troubles that you might face on the exam is that your instances are taking just too long to get ready. You have an expensive provisioning time, and that’s generating an issue when you require those instances to react to a workload that has just hit your production environment. So whenever we can, we want to include everything we need inside that AMI. Creating those AMIs and packing it up with our application dependencies will be quicker than attempting to do it by employing that user data. So we won’t concentrate on selecting answers containing short provisioning time whenever possible.
Get ahead of the workload
We desire to pick answers that get along with the workload whenever we can. So, for example, we wouldn’t choose a response that says we’re creating instances after that workload has begun. If we have a consistent pattern to what’s happening, we must get ready before. So, for example, choose an answer that tells us maybe we’re creating those instances at 12:35 to get ahead of that 12:45 rush. It’s more reasonable to be earlier.
Let’s grab additional essential information:
Steady-state AWS groups
This permits us to make a case where the failure of a legacy codebase or resource that can’t be scaled can automatically recuperate from a failure.
Recall that the Auto Scaling group defines a min, max, and desired capacity. That feature is excellent for that case where maybe we have that NAT instance, that legacy instance, that resource where there can’t have more than one in parallel. For example, Auto Scaling will automatically recover that architecture if that instance fails. So hold this in mind if you’re asked to build a highly available architecture for an old resource where we can’t have more than one running simultaneously.
Multiple Availability Zones AWS
Be sure you are using your Auto Scaling groups over multiple Availability Zones.
We desire to guarantee that we are spreading out. You will never choose the correct answer on the exam containing only one availability zone. We consistently need to spread our instances over at least two availability zones because you can’t design a highly available solution in a single availability zone. So guarantee that your auto-scaling groups, and other resources, are spread out across multiple AZs. That provides us the capability for that one AZ to fail, the solution to have issues, and keeping that plan B.
AWS ELB High Availability
We saw that we couldn’t attach a load balancer with Auto Scaling groups for scaling goals. However, they are most suitable with an Auto Scaling group when balancing the traffic to those instances and determining if an instance has failed on the health check and requires to be terminated and replaced with a new instance. But this doesn’t occur by default. So make sure that you are choosing answers that contain a load balancer to spread the traffic and that you’ve checked that check box (see the screenshot) to guarantee that the Auto Scaling group kills any unhealthy instances attached to the load balancer.
<screenshot from auto-scaling group>
Keep in mind that that is not the default behavior, and therefore we have to make sure that it is explicitly highlighted in the answers we are picking.
AWS Scalable Database
RDS – has the most database scaling options
Horizontal Scaling – is usually preferred over vertical
Read Replicas – are your friend
DynamoDB Scaling – comes down to access patterns.
Let’s review a few topics that we need to remember and involve scale databases. You’re going to run into several scaling questions that have to do with RDS because RDS has the most amount of database scaling options available to us. Also, keep in mind that we can scale vertically, which occasionally is required. Remember that the EC2 instance is a t2.nano; we’re likely to need something a little bit bigger. We can scale out with extra storage if we’re running out of storage in that database server, and we also can do Horizontal Scaling. To achieve that, we can leverage the Read Replicas.
Read Replicas in AWS
If you read a question that contains a read-heavy workload, you automatically want to assume read replicas. So we need to create read replicas and change my code to point my reads to that read replica out from that primary database.
Scaling with DynamoDB
Regarding DynamoDB, it’s a lot easier for us because AWS manages almost everything. If we have a uniform access pattern where it’s predictable and where we slowly need to scale up and then later scale those reads and writes down, we would like to select as Auto Scaling method. If we notice a scenario given to us that has an unexpected workload, where that access pattern spikes up and down, and we can’t anticipate what we need, then we are likely to pick an on-demand alternative. So when talking about scaling DynamoDB, it’s all around that access pattern.
Conclusion
Hopefully, this was valuable for you to recapitulate all of the topics we need to review about High Availability and Scaling.
Also, high availability and scalability for associate aws solutions architects it’s the most important topic, and understanding how to achieve high availability in aws is crucial.
