Building scalable and resilient web applications is the goal of every business. This is often a complex task to achieve, given the evolution of cloud computing and the plethora of tools available out there. 

In this article, I’d like to demonstrate how we can achieve application scalability and resilience using AWS. I’ll go through a list of AWS architectures of varying complexities where choices are made according to your budget and your traffic. Some of these architectures offer resilience and/or scalability.

But before we jump into the examples, let’s define what we mean by application scalability and application resilience.

AWS has an auto-scaling service that automatically resizes your instance clusters. You set the minimum and the maximum number of your instance pool. The machines start and stop automatically according to your needs and within your limits, the latter being generally driven by budget.

With CloudWatch, you can manage on what dimension you want to scale: CPU utilization, latency, bandwidth, storage. It is also possible to use custom metrics to set fine-tune scaling conditions that will trigger EC2 Auto Scaling groups accordingly.

AWS has several choices that provide your architecture resilience, such as the RDS Multi-AZ deployment that allows you to have multiple databases with different data centers, so if a data center with your database fails, the other replications take over. You can also do this with your web servers and ELB service to redirect your traffic only to the operational servers.

Architecture pattern #1

When you’re building your infrastructure you need basic components to start your web application. You have a single instance (Amazon EC2). You attach an Elastic IP address to it. And you put an entry in AWS-managed DNS service (Route 53). That’s simple to run your first app in AWS!

A more powerful instance will soon be needed if you have more traffic or actions on your application. It is possible to start with a “t3.micro” but if performance is of any concern, it will be necessary to move a larger instance type in the same family or to another family type with specialized capabilities (CPU, memory, network, storage). All the magic of AWS lies in the fact that you can increase the size of your servers on-demand, but this is a manual action. Attention, with this architecture there’s no failover, no redundancy.

RESILIENCE: No

SCALABILITY: No

Architecture pattern #2

Once there are several users on your web application, you should consider separating the database from the web server. That way you can scale your instances independently from each other. Indeed, the website & data have different needs.

The possibility of using a database management service makes it possible to not have a team specifically dedicated to administering the database. Here AWS offers Self-Managed services (Amazon EC2) or Fully Managed services (Amazon RDS, Amazon DynamoDB, Amazon Redshift). The objective of this approach is to have copies of your data in multiple places so you never lose it. Plus, if the web server instance falls over, you don’t lose your data and your database.

High server utilization is definitely one major reason to go for managed services instead of running them on all-purpose servers, at least for maintenance and upgrades. For example, add in an RDS multi-AZ for better failover. Note that it does not give you scalability and/or resiliency by default, these two are optional.

RESILIENCE: Partial (database and web server apart)

SCALABILITY: No

Architecture pattern #3

The more users there are on the web app, the more failover and redundancy issues arise. The first thing to do is to add a new web instance in a second availability zone.

The latency between these two availability zones is a few milliseconds.

Finally, Elastic Load Balancing (ELB) enables the users to be divided between web instances 1 or 2, according to the traffic in each of the availability zones. If one of the web servers becomes overloaded or temporarily unavailable, the load balancer redirects the traffic to the other web server (resilience).

RESILIENCE: Yes, full

SCALABILITY: No

Architecture pattern #4

By adding a multitude of web instances within each availability zone, it is possible to accommodate more than 100,000 concurrent users on your application.

Put static content in Amazon S3 (object-based store: good place to put all static content—JavaScript, CSS files, images, videos) and front it with Amazon CloudFront. Since these elements are not on the instances anymore but on external managed services , this allows for better performance and cost reduction.

RESILIENCE: Yes, full

SCALABILITY: Yes

Architecture pattern #5

Your app can accommodate over 1 million users using all of the above-mentioned items:

• Multi availability zone: by adding the number of instances your app needs in each of the multiple availability zones as required.
• Elastic Load Balancing
• Auto Scaling
• Service-oriented architecture (SOA)
• Serving content smartly
• Caching off DB

Beyond 1 million users, each availability zone then looks like this schema. It’s not just about scalability, but about high availability.

Other managed services  that can be added:

• Amazon SES: sending mail
• CloudWatch: monitoring → not only for auto-scaling but also for everything regarding your application in the AWS infrastructure
• Lambda and Worker Instance

RESILIENCE: Yes, full

SCALABILITY: Yes, full

I hope you found this article helpful! Book a demo with us If you’re interested in seeing how Artifakt is using AWS to provide you with the most seamless experience possible.