Web Application Deployment in the Cloud Using Amazon Web Services – From Infancy to Maturity

Created by P3 InfoTech Solutions Pvt. Ltd., http://p3infotech.in | 1

Web Application Deployment in the Cloud

Using Amazon Web Services – From Infancy to Maturity

P3 InfoTech Solutions Pvt. Ltd

http://www.p3infotech.in

July 2013

http://www.p3infotech.in/

Web Application Deployment in the Cloud Using Amazon Web Services – From Infancy to Maturity


Web Application Deployment in the Cloud Using Amazon

Web Services – From Infancy to Maturity

1. Introduction

This case study describes three scenarios of a web application deployment in the Cloud

using Amazon Web Services (AWS) – starting from a basic one-server setup to an

advanced setup with Auto Scaling and High Availability. These scenarios reflect the

lifecycle of an application that starts with few users during its early days, then goes on

to having more users, and eventually becomes business-critical. These case studies

demonstrate the following key points:

● Application deployment on AWS is future-proof. Applications can be

deployed in AWS starting with a low-cost basic setup and then incrementally add

features such as Higher Performance, Scalability, and High Availability as the

need arises. This is a result of the great flexibility and extensibility that AWS

provides thanks to the large number of features available and the ability to

choose these features on an à la carte basis.

● Few changes (if any) are required to the application. The addition of features

to application’s deployment architecture requires only few changes to the

application, if any. In most cases, changes only need to be made to the

application’s deployment setup in AWS, without any changes to the application

itself. Where there are changes required to the application, they are easy to

accomplish thanks to AWS’ APIs which are available in all the programming

languages commonly used for web development.

2. AWS Architectural Components

An Amazon Elastic Compute Cloud (EC2) instance is a Virtual Machine (VM)

provided by AWS. EC2 instances are the basic unit of computing in AWS and come in

various CPU and memory configurations. For more information about EC2, refer

http://aws.amazon.com/ec2/.

Amazon Elastic Block Storage (EBS) is block storage attached to an EC2 instance.

EBS has been designed for high reliability and performance. An EBS instance (referred

to as an EBS volume) can only be attached to a single EC2 instance at any time. This

means that every application server needs to have its own EBS volume to store the

application code and data. Moreover, EBS volumes cannot be used as-is to share data

among EC2 servers. For more information about EC2, refer

http://aws.amazon.com/ebs/.

http://aws.amazon.com/ec2/

http://aws.amazon.com/ebs/



Amazon Simple Storage Service (S3) is a highly reliable and durable storage provided

by AWS. S3 has been designed for high reliability by maintaining multiple replicas of the

data. The design point for S3 is 99.999999999% durability and 99.99% availability of

objects over a given year. As opposed to EBS, S3 is not attached to any particular EC2

instance; rather, S3 storage is accessible from any EC2 instance and therefore can be

readily used to store data shared by EC2 instances. Another key thing to note about S3

is that browsers can directly connect to files stored in S3 via a unique URL for every file;

thus S3 can serve the data itself without the requirement of a separate EC2 server.

These attributes make S3 a great choice for serving static content such as CSS and

JavaScript files, Images, Videos, etc. For more information about S3, refer

http://aws.amazon.com/s3/.

Amazon Relational Database Service (RDS) is a hosted database service provided by

AWS. RDS provides standard SQL databases such as MySQL, Oracle and Microsoft

SQL, but takes care of common database management tasks so that the application

administrator is not burdened with them. For more information about RDS, refer

http://aws.amazon.com/rds/.

Amazon Elastic Load Balancing (ELB) is a hosted load balancing service provided by

AWS. ELB automatically distributes incoming load among the EC2 instances attached

to the ELB. ELB has in-built detection of unhealthy instances and ensures that load is

not distributed to those instances. For more information about ELB, refer

http://aws.amazon.com/elasticloadbalancing/.

Amazon CloudWatch provides monitoring for AWS resources, such as EC2, RDS and

ELB. It can be used to collect and track metrics to gain visibility into resource utilization,

application performance, and operational health. More importantly, since CloudWatch

monitors resources in real-time, it can be used to react immediately to keep the

application running smoothly. Some of the metrics that CloudWatch monitors are: CPU

utilization, Memory usage, Disk IO statistics, Request latency, Request counts, and

Network IO statistics. For more information about CloudWatch, refer

http://aws.amazon.com/cloudwatch/.

Amazon Elastic IP Addresses are static addresses assigned to AWS resources (an

EC2 or ELB). Elastic IP addresses are associated with an account and not a particular

EC2 instance, allowing them to be remapped to another instance in case of an

EC2/ELB failure. For more information on Elastic IP addresses, refer

http://aws.amazon.com/ec2/.

Auto Scaling allows application owners to scale EC2 capacity up or down automatically

according to the conditions defined (based on CloudWatch metrics). Auto Scaling is a

very powerful feature that can be provided only due to the elastic, on-demand and

immediate properties of Cloud Computing. With Auto Scaling, EC2 instances can be

increased seamlessly during demand spikes to maintain performance, and decreased

http://aws.amazon.com/s3/

http://aws.amazon.com/rds/

http://aws.amazon.com/elasticloadbalancing/

http://aws.amazon.com/cloudwatch/

http://aws.amazon.com/ec2/



automatically during demand lulls to minimize costs. Auto Scaling is particularly well

suited for applications that experience significant variability in usage. For more

information on Auto Scaling, refer http://aws.amazon.com/autoscaling/.

Availability Zones are distinct datacenters that are engineered to be insulated from

failures in other Availability Zones and provide inexpensive, low latency network

connectivity to other Availability Zones in the same Region.

Amazon CloudFront is a content distribution network (CDN) provided by AWS. It

enables fast access to static data such as photos and streaming videos by storing the

data at edge locations close to users. For more information about CloudFront, refer

http://aws.amazon.com/cloudfront/.

3. Case Study #1 – Starter Plan for Small Application

This scenario applies to a non-business-critical small application. The application’s

availability requirement ranges between 99% and 99.9% – this translates to a downtime

of 438 minutes to 44 minutes per month.

The application itself consists of web server and possibly a separate app server, a

relational database, and a bunch of static files (CSS, JavaScript, Images, etc.). The

application could be hosted on either a Windows or Linux operating system.

3.1. Key points regarding the deployment architecture

Figure 1: Architecture Diagram for Starter Setup

● The application is hosted on a single EC2 instance.

● The EC2 instance hosts both the Web server and the database server.

http://aws.amazon.com/autoscaling/

http://aws.amazon.com/cloudfront/



● The size of the EC2 instance can vary between a micro instance to large

instance, depending on the performance and usage requirements.

● The root volume of the EC2 instance is an Elastic Block Store (EBS) volume.

This is a best practice and safeguards against data loss in case of failure of the

EC2 instance.

● The application code as well as the database files are stored on the EBS volume.

● Amazon S3 is used for storing and serving static content such as CSS,

JavaScript, images, audio files, video files, documents, etc. The benefit of

serving static files from S3 is that it offloads this work from the EC2 instance,

thus reducing the load on it.

3.2. Changes Required to Application

Compared to a non-AWS deployment, the application needs to be modified in the

following ways for this deployment.

Awareness of S3: The application will need to be modified a little bit to be aware

of S3, but only if it has any user-generated content. The user-generated files

should be temporarily uploaded to the local EBS volume attached to the EC2

instance and then transferred to S3. This can be easily done with a little working

knowledge of the S3 APIs. If the application does not have any user-generated

content, then the move to S3 should only involve a change to URL used to server

static data in the application’s settings.

3.3. Deployment Tips

1. The AWS region used for deployment should be carefully selected. The AWS

region that is closest to most of the application’s users should be selected.

2. Amazon CloudWatch should be used to monitor the EC2 instance and be

configured to send out notifications if something goes wrong. Notifications can be

sent via email or SMS (only supported in US).

3. If the application will keep running for a long duration (more than 6 months) and

for several hours of a day (more than 12 hours) , use a Reserved EC2 instance

instead of OnDemand instance; this can greatly reduce your EC2 costs.

4. Auto Scaling can be used to further reduce downtime in case the EC2 instance

fails. To achieve this, Auto Scaling should be setup with a ‘minimum size’ and

‘maximum size’ set to 1. With this setup, if the EC2 instance fails, the Auto

Scaling feature will start a new instance from the same image.



5. Hourly or daily backups of the EBS volume should be taken to reduce the

extent of data loss if something bad happens to the EBS volume. For an even

higher degree of data protection, a remote copy of this backup should be

maintained on a different AWS region.

3.4. Benefits of using Starter plan

Following are the key benefits of this deployment compared to a non-AWS deployment.

1. Can be notified via CloudWatch in case something goes wrong.

2. Serving of static files is offloaded to S3, thus freeing up resources on the EC2

instance for running the application and database.

3. Flexibility: this deployment provides flexibility as a result of the many options

offered by AWS. For example:

As the application’s performance requirement increases, it can be easily

moved to a bigger EC2 instance at any time.

The size of the EBS volume can be easily increased at any time.

The application can be migrated to a different AWS region.

4. Future-proof: this deployment architecture can be easily extended to a more

reliable deployment (e.g. the next 2 deployment scenarios) when the need

arises.

4. Case Study #2 – Intermediate Plan with Auto Scaling

This scenario is applicable to a non-business-critical medium sized application that

gets traffic load throughout the day. The traffic has highs and lows during certain

periods of the day that reflect peak and low usage times for the application. The

application is not business critical, and doesn’t require investing in a high availability

or disaster recovery solution. The application can tolerate downtime of up to a few hours

per month, translating to availability requirement in the range 99% and 99.9% (438

minutes to 44 minutes per month).

As in the previous scenario, the application itself consists of web server, a relational

database, and a bunch of static files (CSS, JavaScript, Images, etc.). The application

could be hosted on either a Windows or Linux operating system.




Figure 2: Architecture Diagram for Scalable Setup

● Dynamic scaling is achieved via AWS Auto Scaling feature. With Auto Scaling

the application can be scaled automatically when demand increases or

decreases.

For instance, consider the following EC2 uptime data we got from one of our

clients.

o The application is deployed with up to 4 EC2 instances

o EC2 instances #1 and #2 are always running, i.e. 100% of the time



o EC2 instances #3 and #4 handle the additional load during peak hours or

traffic burst periods.

o EC2 instance #3 runs for 40% of the time

o EC2 instance #4 runs for 20% of the time

● Elastic Load Balancer (ELB) is used to distribute incoming application traffic

across the EC2 instance.

● A separate EC2 instance is used for the DB server which is a best practice for

any but the most simplest of applications.

Note: Although we have shown the database on a separate EC2 instance, this

could be replaced with RDS also which is essentially an EC2 instance +

database software that is managed by AWS.

● 5 EBS-storage volumes are used, one for each EC2 instance.

Note: there are 4 EC2 instances for the application and 1 EC2 instance for the

database.

● As with the previous case study, Amazon S3 is used for storing static content

such as images, audio files etc.

4.2. Changes Required to Application

This setup requires no further changes in the application compared to the starter plan.


Following are some deployment tips for this plan, in addition to the deployment tips for

the starter plan.

1. Auto Scaling Rules should be carefully specified taking into account the

application’s traffic profile and performance characteristics as well as the hosting

budget.

2. The utilization of the EC2 instances that are part of the Auto Scaling Group

should be reviewed. For instances that will be running most of the time, using

Reserved EC2 instances instead of OnDemand instances can result in

significant cost savings.

4.4. Benefits of Intermediate plan

The intermediate plan has the following benefits over the starter plan.



1. Higher capacity due to multiple application instances: This deployment

architecture uses multiple EC2 instance to host the application, enabling the

application to handle much more load than with a single instance.

2. Auto Scaling: This scenario demonstrates how the application can scale

seamlessly in AWS by using the Auto Scaling feature. Dynamic scaling helps

provision resources for the application to closely match the actual demand. This

ensures a great experience for the users of the application, while keeping costs

low. With Auto Scaling, it is possible to configure rules for when and how to scale

up or scale down the number of EC2 instances used by the application.

3. Separate DB: The deployment uses a separate EC2 instance for the database.

This is a deployment best practice. By having the database served out of a

separate EC2 instance, the application and the database do not contend for the

same resources. This provides more reliable application performance and makes

it easier to any diagnose performance problems.

4. Non-disruptive software upgrades: Software upgrades can be performed in a

rolling fashion, one EC2 instance at a time. While the EC2 instance is being

upgraded, the other EC2 instances of the Auto Scaling group will continue to

serve requests.

5. Case Study #3 – Advanced Plan with High Availability for Business

Critical Applications

The major difference between this scenario and the previous ones is that the application

is business critical and therefore cannot tolerate any downtime. The availability

requirement of the application is 99.99% uptime (less than 5 minutes of downtime per

month).

As in the previous scenario, the application itself consists of web server, a relational

database, and a bunch of static files (CSS, JavaScript, Images, etc.). The application

could be hosted on either a Windows or Linux operating system.




Figure 3: Architecture Diagram for Scalable + Highly Available Setup

● This deployment adds high availability to the application. High availability

means that there is no single point of failure. If any single component in the

setup fails, the application will continue to be operational (though, with a slightly

reduced performance).

● This setup uses two AWS availability zones. The setup of the advanced plan

replicates the intermediate plan setup in 2 availability zones. By launching

instances in two availability zones, the application is protected from failures

within a single availability zone. Even if one entire availability zone fails, the

application will still be able to operate from the other availability zone.

● High-availability for database using a replicated master-slave setup. Data is

synchronously replicated from the master to the slave to ensure there is no loss

of data when the master fails. When the master database fails, the slave will be



promoted as the master and will start serving both read and write requests. The

master-slave setup provides 2 benefits:

1. High-availability for the database

2. Better read performance for the database since reads can be served from

both the master and the slave

● ELB is a highly available service by design; hence only one ELB is required.

● Amazon CloudFront is used to cache static data on edge locations near to the

users. User requests for static content are automatically served from the

CloudFront edge location nearest to the user. This helps improve the application

experience for the users as the data gets downloaded faster on the users’

computers.

5.2. Changes Required in Application Design

Awareness about Database Master-Slave Architecture (optional): To make best

use of this architecture, the application needs to be aware of the Master-Slave setup of

the database. This is an optional enhancement for the application that results in better

database performance; however, this configuration can also be used without this

enhancement.

One of the DB instances acts as the master and the other as a slave. All application

servers must write data only to the master.

The application servers in availability zone 2 (the one with the slave DB server) should

send read requests to the slave DB server. This reduces the load on the Master DB

Server by distributing the reads between the Master and the Slave servers, resulting in

better database performance and greater scalability.


Following are some deployment tips for this plan, in addition to the deployment tips for

the intermediate plan.

1. We recommend using RDS for the database, as it provides a simple way to use

a replicated multi-availability zone setup.

2. For a predictable, balanced, and reliable setup, the Auto Scaling

configurations should be identical in the two availability zones. This

configuration includes things such as: size of the EC2 instances, size of EBS

volumes, and Auto Scaling rules.



5.4. Benefits over Intermediate Plan

● High Availability: In this configuration, there is no single point of failure enabling

the application can withstand the failure of any single component. This

significantly increases the availability of the application.

● Increased Database Capacity and Performance: Distributing database reads

among two instances doubles the database read capacity.

● Faster load times for static files: Use of Amazon CloudFront for serving static

files results in faster load times as the data is served from a server closer to the

user. This leads to a better user experience for the users.

6. Summary

In this case study, we have described 3 architectures for deploying applications in AWS:

starter plan, intermediate plan, and advanced plan. We started with the starter plan

which consists of a single EC2 instance and is suitable for small applications non

business-critical for business. Then, we moved to the intermediate plan which is

suitable for medium or large sized applications non business-critical for business. The

intermediate plan introduced the use of Auto Scaling group for elastically scaling the

application capacity. Finally, we discussed the advanced plan that is meant for

business-critical applications that need to be highly available.

While discussing these case studies, we made use of several AWS features: EC2, EBS,

RDS, Elastic IP, S3, CloudFront, CloudWatch, EBS Snapshots, Auto Scaling, and

Availability Zones. One of the best things about using AWS is that it provides a large set

of services, which can be used à la carte. This allows an application to start with a basic

deployment such as the starter plan with only a basic set of services. As the

application’s use grows and its deployment requirements become more demanding for

performance and availability, the deployment architecture can be easily scaled up and

other AWS services can be incorporated to provide enterprise grade performance and

availability. All this without any up-front investments and paying only for the resources

you use.

About P3 InfoTech Solutions Pvt. Ltd.

P3 InfoTech Solutions Pvt. Ltd. helps organizations achieve business breakthroughs by

adopting Cloud Computing through our Outsourced Product Development and Cloud Consulting

service offerings. Discover our passion for Cloud Computing and Web Applications at

http://www.p3infotech.in.

http://www.p3infotech.in/

Web Application Deployment in the Cloud Using Amazon Web Services – From Infancy to Maturity

Technology

amazon web services

web application deployment

aws resources

amazon cloudwatch

aws apis

ec2 instances

application performance

application server