Menu
Laying the Foundation: Setting Up Your Environment for Cost Optimization
AWS Whitepaper

Enable Teams to Architect for Cost

Cost optimization is a pillar of the Well-Architected Framework. It prevents developers and engineering teams from having to optimize workloads after the fact and when it is often too late and not economical to address issues built into the environment at early decision points.

Teams that are empowered to architect for cost can iterate quickly and learn over time so that best practices become embedded in day-to-day operations. The following practices can help teams architect for cost:

  • Drive and foster transparency by creating visibility and by using tools to promote consistent reporting, measurement, and accountability.

  • Drive the right type of behavior by creating positive incentives when the right actions are taken (e.g., email from management highlighting optimization wins).

  • Establish control policies while maintaining agility (e.g., have a process to identify and address oversized resources, have an opt-out policy for non-production resources to switch off outside of work hours).

The following are some ideas that can help you drive cost-optimization behaviors:

  • Incentives – These include visualization and gamification of metrics, as well as positive communication from leadership based on results. They encourage teams to understand that efficiency and frugality are valued and help developers and engineers consider the cost implications of their decisions. They also provide a way to discourage inefficiency.

  • Chargeback of costs to users – Chargeback creates incentive for business users to care about IT efficiency. This results in treating IT as a resource that’s used by and paid for by the business instead of as a cost center.

  • Removal of process barriers – Occasionally, there are barriers that limit developers and engineers from undertaking optimization. For example, policies may be in place that require that any change made to the environment must go through a change review process. This will hamper initiatives to promote right sizing and elasticity. An amendment of such policies can streamline the optimization effort.

  • Agile working methods – If design iteration cycles include cost as a metric, then your organization’s ability to deliver the same or better outcomes at a lower cost will improve over time.

  • Training and onboarding – Individuals typically solve problems using the tools and techniques they know. This can be addressed through training and onboarding that incorporate the latest practices to maximize efficiency (e.g., using serverless architectures, using Amazon CloudFront to reduce compute demand).

The following approaches can also be effective, but present risks to agility if not implemented with care:

  • Executive support/pressure – Support for best practices is preferred over cost pressure due to their positive impact on staff satisfaction. Cost pressure can create an incentive to hide inefficiency and can lead to budget lockdown, resulting in loss of agility and ability to innovate.

  • Architectural review – There is typically a reasonable balance between no architecture review (or optional review) and mandatory review. Excessive mandatory reviews can create bottlenecks. High-consequence and high-cost projects may require review with boundaries that are defined by each organization.

  • Orchestration control – Approval workflows for projects and resources place agility and innovation at risk to protect finances and budget. One way to balance control and agility is to place fewer (or no) cost controls on revenue-generating services. You can counterbalance this by having advanced metrics in place for these services.