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

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/.

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

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.

● 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.

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

Recommended

Recommended

More Related Content

More from P3 InfoTech Solutions Pvt. Ltd.

More from P3 InfoTech Solutions Pvt. Ltd. (20)

Recently uploaded

Recently uploaded (20)

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