According to a recent study of Amazon Web Services (News - Alert), highly-available and scalable Web and application hosting can be a complex and expensive proposition: “Traditional scalable Web architectures have not only needed to implement complex approaches to ensure high levels of reliability, but have also required an accurate forecast of traffic to provide a high level of customer service.”

Dense peak traffic periods and wild swings in traffic patterns result in low usage rates of expensive hardware, study officials said, yielding “high operating costs to maintain idle hardware, as well as an inefficient use of capital for underused hardware.”

The traditional Web hosting architecture is easily portable to the cloud services provided by the AWS products with only a small number of modifications, but, as the study’s authors say, “the first question that should be asked is whether it makes sense to move this application into the cloud.”

The study would argue that there are cases where yes, it does make sense. “If you are responsible for running a Web application then there are a variety of infrastructure and architecture issues that you face for which AWS can give you an answer.”

The following are “just some of the benefits of using AWS over a traditional hosting model:”

A cost-effective alternative to oversized fleets needed to handle peaks. In the traditional hosting model, servers need to be provisioned to handle peak capacity and the unused cycles are wasted outside of peak periods. AWS-hosted web applications can use on-demand provisioning of additional servers, which allows capacity and costs to follow the traffic model.

A scalable way to handle unexpected traffic peaks. An even more dire consequence of the slow provisioning associated with a traditional hosting model is the inability to respond in time to unexpected traffic spikes.

An on-demand way to test, load, beta and pre-production environments. The hardware costs of building out a traditional hosting environment for production Web application don’t stop with the production fleet. Quite often pre-production, beta and testing fleets need to be created as well to ensure the quality of the web application at each stage of the development lifecycle before it is launched on the production fleet. While various optimizations can be made to ensure the highest possible usage of this testing hardware, it is often not the case that these parallel fleets are used optimally.