The purpose of this post is to illustrate the application architecture for a database-driven, e-commerce web application with traditional on-site hosting and hosting with Amazon Web Services (AWS). We’ll take it one step further and explore associated costs using AWS’s Simple Monthly Calculator, an online tool used to help customers estimate their monthly bill.
The following diagram depicts an architecture used in conventional web hosting environments. Application requests are routed by a single web load balancer after negotiating a network firewall. An additional firewall blocks network-level attacks before another load balancer routes requests coming from either web server. A single database stores all data relevant to our application, and replication tasks ensure elimination of data ambiguity and inconsistency. Nightly data backups are stored on premises.
Employing several key components of an AWS implementation, Figure 2 shows a common configuration for the same application.
DNS addressing is managed by Amazon Route 53, which resolves domain name requests to an elastic load balancer (ELB) between two availability zones (AZ). Spreading the application architecture across multiple AZs nearly guarantees that the application will not suffer downtime from outages.
Once reaching an availability zone, requests are load balanced, and directed to auto-scaling groups comprised of a dynamic number of web and application servers, known as EC2 instances. A service called Amazon CloudWatch monitors these EC2 instances, and based on user-defined criteria, triggers the creation of additional instances. These events are configured through an Amazon Machine Image (AMI) template. For added security, firewalls are present at every EC2 instance.
The Amazon S3 bucket is responsible for storing application object data, backups and static content, like CSS files and images, while Amazon CloudFront provides efficient content delivery from external resources.
The database (Amazon RDS) tier is deployed across two availability zones for increased reliability. Replication tasks are responsible for ensuring the databases are virtual clones of one another.
Cloud Hosting Costs
The following estimate, prepared on February 20, 2015 using the AWS Simple Monthly Calculator, reflects costs associated with the above architecture using one standard MS SQL Server DB engine. Two different pricing options offered by AWS are listed: No Contract and a 3 Year Contract.
Application size, bandwidth, and database transfer rate metrics represent a moderately-sized, e-Commerce application.
It’s important to consider other costs accompanying cloud hosting. Below are likely expenses associated with migrating an existing application to a cloud provider.
Hidden ("clouded") Costs
Applications with large volumes of data may require significant bandwidth to move that data to the cloud. Customers can easily pay thousands of dollars for a one-time migration.
Once an application is migrated to a cloud provider, there may be features, such as third party SDKs, which have not been run in a cloud environment. Testing these areas of the application will require time and money to prepare them for the cloud.
The illustrations (above) in this post are simple architectures meant to illustrate the key differences between an AWS hosting implementation and conventional on-premises hosting. Depending on the complexity of an application including integrating Active Directory or sophisticated third-party components, there can be significant integration costs.
Given cloud applications are hosted in a more complex environment that traditional hosting, it’s reasonable to assume that troubleshooting issues will take more analysis leading to increased costs for resolving problems.
Cost Savings in the Cloud
The true benefits of a cloud implementation, in terms of cost savings and resource efficiency, are observed through elastic computing. AWS’s CloudWatch manages the number of EC2 instances by monitoring specific events. If an online storefront application experiences a surge of traffic on Black Friday, for instance, the number of web and application server instances will be increased, but only enough to provide sufficient computing power to handle the upsurge. In a traditional architecture, customers will need to accurately forecast traffic during peak times. This can be costly and wasteful. Rather than purchasing the required hardware to accommodate infrequent periods of high traffic, we might consider “renting” resources only when they’re needed.
Operating costs, such as energy bills and costs related the maintenance and care of existing hardware, would also be avoided with cloud hosting.
Based on application complexity, size, and network traffic, the benefits of cloud hosting will not be realized for every application. Hobby sites and small e-Commerce applications are better suited for self-hosting or even private hosting providers. To justify AWS Cloud pricing, an application should demonstrate the need for high availability, on-demand computing power.