Many developers use the default setting that reserves whole instances for their workloads, which then run 24x7. Development systems should not be running after hours unless manually activated. Another option is to use spot instances instead of reserved instances. Many people think spot instances get bumped when another workload comes into the environment, but in reality the instance quickly switches to another system with spare capacity.

The financial dashboards of cloud providers provide information on how much a particular system is used. It’s possible to set it up so that unused systems automatically decommission themselves. This can be done in phases over a long period of time. The amount of horsepower assigned to the system can be reduced, then the system can be turned off, then its data can be destroyed. It could be a year or more before the instance is destroyed, but in the meantime costs have been reduced.

Most on-premises storage systems automatically perform de-duplication to eliminate multiple copies of the same file. This significantly reduces the amount of storage resources required. Cloud systems do not perform de-deduplication natively, so customers are charged for storing multiple copies of files. There are third-party de-duplication components that can be added to cloud platforms.

Many organizations save multiple terabytes of log files that nobody has any interest in and are never going to use. The storage resources consumed become one of the most expensive things in the environment. Log files should be managed by defining which log information should be retained.

When cloud instances are provisioned, the user often has to guess what kind of resources that system will need. Yet no one ever goes back to review it and determine whether the resources are sized appropriately. Another problem is sizing instances based upon the maximum load. For example, financial applications come under heavier load at the end of each fiscal quarter and the greatest load at the end of the fiscal year. If the system is sized based upon year-end demand, resources are wasted the other 11 months. Performance optimizers can help determine what kind of resources are needed normally, and the resources scaled up when needed.

One of the biggest mistakes organizations make is in the routing design for their systems. They'll get into something called a “traffic hairpin,” which is where the traffic for a service goes through multiple accounts before reaching its destination, then back through multiple accounts on the return trip. This typically happens when a firewall is placed on an account, with other accounts attaching to it in a hub-and-spoke configuration. There’s no cost to send traffic to an account, but cloud providers charge for traffic to exit. As a result, traffic hairpins can double or even quadruple data transfer costs. There are a number of ways routing can be configured to avoid this problem.