AWS EC2 Cloud Architecture In a Nutshell

In this medium post, I will explain some of the key concepts of the AWS Cloud EC2 Architecture and the different approaches.

Let’s start with traditional architecture. In a nutshell, clients talk with the web server over Http/Https, and it can return a JSON data, HTML+CSS+JS output or other responses based on your RESTful API design (Fig. 1).

Figure 1: Traditional Server Architecture

You can simply design same architecture with AWS Elastic Cloud Computing (EC2) instance (Fig. 2).

Figure 2: AWS EC2 Architecture

However, you only have a single server to provide an infrastructure for your web service, and you also need a database (DB) to do Create, Read, Update, and Delete (CRUD) operations. This is a very simple deployment architecture to start with (Fig. 3).

Figure 3: AWS EC2 Architecture with a DB

Now, we deployed our architecture with a server and DB. However, if you consider about the high peak loads from the user, you can scale vertically. However, this can create single point of failure which means if your server is down, and it can cause a domino effect for your rest of the application. We can solve it by scaling horizontally and include an Application Load Balancer (ELB) in front of your instances (Fig. 4).

Figure 4: AWS EC2 Architecture with a DB and ALB

Now, you can handle with the peak demand by easily adding more servers. But there are two main problems, manual handling, and cost management. You need to provision your resources manually. Also, your website doesn’t have a constant load for all the times. For instance, if you have an e-commerce website, your website can have more traffic during black Friday, Christmas, or weekends. However, you must meet your peak load and continue to pay these servers even they’re not used. Thanks to cloud, you can solve this problem easily. You can add an Auto Scaling Group (ASG) to automate demand of your EC2 instances and terminate your instances by following your application’s load (Fig. 5).

Figure 5: AWS EC2 Architecture with a DB, ALB, and ASG

So, for now, you solve the manual handling and cost management problem by adding an ASG to your EC2 instances. Now your app is highly elastic, and you want to ensure that your website must be available and fault tolerant. You can deploy your instances across different Availability Zones (AZs) even if one of the AZs has a failure, your application will be still accessible from another available data centre.

Figure 6: AWS EC2 Architecture with a DB, ALB, ASG, and multiple AZs

This can easily be implemented by providing the correct ALB and ASG configuration to increase your instances across different availability zones. Now, you have a highly available architecture which can elastically scales out or in to handle your peak demand while managing your cost savings off-peak load. This can be very common architecture to implement highly scalable and available system. However, there are some drawbacks for this approach both developers and architectures side.

You have your own code and system logic which are unique for your product. You need to manage your own operating system/runtime patching, provision instances, servers’ health, scaling policies, availability zone mapping, recovery latency, and list goes on.

In my next medium post, I will explain how you can benefit from serverless architecture and remove obstacles from your architecture with a serverless approach by focusing more on your unique applications.