There are many different answers to why moving to a Cloud-hosted environment might be beneficial but it depends on the end user. The shift may suit small teams but for mid-sized teams the effort saved begins to outweigh the cost. I start at mid-sized because this is the size that usually includes the two teams that benefit the most:

For a developer, the biggest benefit of Cloud providers is the ability to throw away entire environments. In a traditional developer setting, the developers usually develop their code locally, have access to a shared physical server, or have access to a virtual server of some type. Issues that usually arise out of these setups are that it's hard to enforce consistency and the servers can become stale over time. If each developer works locally, inconsistency can arise very quickly. Different versions of the core language or software could be used and might behave differently from machine to machine. One developer might use Windows and prefer registry look-ups while another developer may use Mac and prefer environment variables.

If the developers share a core server for development, other issues may arise such as permissions or possibly trying to modify services independent of each other causing race conditions. No matter what problems exist, known or unknown, they could be solved by always starting from the same base operating system state. The leading software for solving this issue is Vagrant. Vagrant provides the ability to spin up and destroy a virtual machine from a configuration file along with a configuration management suite such as Puppet, Chef, Docker, or Ansible. Vagrant itself is agnostic to the Cloud hosting tool in the sense that it does not require AWS. It can spin up instances at AWS given the credentials, but it can also spin up virtual machines locally from VirtualBox and VMWare.

Vagrant gives back consistency to the developers in the sense that it takes a base box (in AWS terms this is an Amazon Machine Image or AMI) and configures it via one of the configuration suites or shell to create a running virtual machine every time it is needed. If all the developers share the same configuration file then all of them are mostly guaranteed to work against the same environment. That environment can be destroyed just as easily as it was created, giving the resources back and incurring no charges until needed again.

The bringing up and destroying of the instances becomes a small invisible piece of their workflow. By virtue of enforcing a strategy like this on a team, a lot of issues can be found and resolved before they make their way up the chain to the testing or production environments.

The other team I mentioned that benefits from moving to the Cloud is the operations team. This team differs greatly in responsibility from company to company but it is safe to assume that the team is heavily involved with monitoring the applications and systems for issues and possible optimizations. AWS provides enough infrastructure for monitoring and acting on metrics and an entire book could be dedicated to the topic. However, I'll focus only on auto scaling groups and CloudWatch.

For AWS, an auto scaling group defines scaling policies for instances based on schedules, custom metrics, or base metrics such as disk usage, CPU utilization, memory usage, and so on. An auto scaling group can act on these thresholds and scale up or down depending on how they are configured. In a non-Cloud environment this same setup takes quite a bit of effort and depends on the software whereas, it's a core concept to AWS.

Auto scaling groups also automatically register instances with a load balancer and shift them into a round robin distribution. For an operations team, the benefit of moving to Amazon might justify itself only to alleviate all the work involved in duplicating this functionality elsewhere, allowing the team to focus on creating deeper and more meaningful system health checks.

Throw-away environments can also be beneficial to the operations teams. A sibling product to Vagrant, very recently released, is Terraform. Terraform, like Vagrant, is agnostic to the hosting environment but does not solely spin up virtual instances. Terraform is similar to CloudFormation in the sense that its goal is to take a central configuration file, which describes all the resources it needs. It then maps them into a dependency graph, optimizes, and creates an entire stack. A common example for Terraform would be to create a production environment from a few virtual machines, load balancers, Route53 DNS entries, and set auto scaling policies. This flexibility would be nearly impossible in traditional hardware settings and provides an on-demand mentality not just for the base application, but also for the entire infrastructure, leading to a more agile core.