Controlling costs is one of the grea challenges facing IT and Finance managers today. The cloud, by nature, makes it easy to spin up new environments and resources that can cost thousands of dollars each month. And, while there are many ways to help control costs, one of the simplest and most effective methods is to set and manage cloud spend-to-budget. While most enterprise budgets are set at a business unit or department, for cloud spend, mapping that budget down to the workload can establish strong accountability within the organization.
One popular method that workload owners use to manage spend is to track month-over-month cost variances. However, if costs do not drastically increase from one month to another, this method does very little to control spend. It is only until a department is faced with budget issues that workload owners work diligently to reduce costs. That’s because, when budgets are set for each workload, owners become more aware of how their cloud spend impacts the company financials and tend to more carefully manage their costs.
In this post, we provide four easy steps to help you manage workload spend-to-budget effectively.
Step 1: Group Your Cloud Resources by Workload and Environment
Use a financial management tool such as 2nd Watch CMP Finance Manager to group your cloud resources by workload and its environment (Test, Dev, Prod). This can easily be accomplished by creating a standard where each workload/environment has its own cloud account, or by using tags to identify the resources associated with each workload. If using tags, use a tag for the workload name such as workload_name: and a tag for the environment such as environment:. More tagging best practices can be found here.
Step 2: Group Your Workloads and Environments by Business Group
Once your resources are grouped by workload/environment, CMP Finance Manager will allow you to organize your workload/environments into business groups. For example:
a. Business Group 1
i. Workload A
1. Workload A Dev
2. Workload A Test
3. Workload A Prod
ii. Workload B
1. Workload B Dev
2. Workload B Test
3. Workload B Prod
b. Business Group 2
i. Workload C
1. Workload C Dev
2. Workload C Test
3. Workload C Prod
ii. Workload D
1. Workload D Dev
2. Workload D Test
3. Workload D Prod
Step 3: Set Budgets
At this point, you are ready to set up budgets for each of your workloads (each workload/environment and the total workload as you may have different owners). We suggest you set annual budgets aligned to your fiscal year and have the tool you use programmatically recalculate the budget at the end of each month with the amount remaining in your annual budget.
Step 4: Create Alerts
The final step is to create alerts to notify owners and yourself when workloads either have exceeded or are on track to exceed the current month or annual budget amount. Here are some budget notifications we recommend:
ME forecast exceeds month budget
MTD spend exceeds MTD budget
MTD spend exceeds month budget
Daily spend exceed daily budget
YE forecast exceeds year budget
YTD spend exceeds YE budget
Once alerts are set, owners can make timely decisions regarding spend. The owner can now proactively shift to spot instances, purchase reserved instances, change instance sizes, park the environment when not in use, or even refactor the application to take advantage of cloud native services like AWS Lambda.
Our experience has shown that enterprises that diligently set up and manage spend-to-budget by workload have more control of their costs and ultimately, spend less on their cloud environments without sacrificing user experience.
AWS enables enterprises to trade capital expense for variable expense, lower operating costs and increase speed and agility. As enterprises begin to deploy cloud services across their business, it is critical to have a standardized approach to allocate usage costs to the appropriate department or cost center. By tracking costs at the cost center level, Enterprises gain visibility throughout their organization – and specifically who is spending precious IT funds.
To allocate costs, usage must first be grouped. AWS provides two methods to group usage; Resources Tags and AWS accounts. Each method is useful but also comes with downsides.
Using AWS Tagging to group usage
Grouping by tag enables enterprises to run all of their workloads (applications) in a single AWS account, simplifying management within the AWS console.
A tagging schema needs to be created, universally deployed and tightly controlled.
Care has to be taken to ensure all individual AWS resources are tagged properly as any mistake in tagging will cause a resource to be left out of the group and not reported properly.
Many AWS resources are un-tagable, which will require the creation and maintenance of a separate cost distribution scheme to allocate those costs across the enterprise.
Reserved Instance (RI) discounted usage pricing cannot be linked to a single tag group and can result in significant costing inaccuracies.
Using Multiple AWS Accounts to group usage
Using individual AWS accounts for each workload provides the most accurate and detailed reporting of costs and usage.
By creating a separate AWS account for each workload, enterprises can track all associated costs (including RIs) and allocate them to cost centers, departments and/or business units.
When using AWS accounts to group usage, each account must be manually set up.
There is no method of sharing resources, such as databases, with multiple workloads as each workload is located in separate AWS accounts.
Given the challenges of both “account based” and “tag based” grouping, we have found that the tracking methodology needs be aligned to the applications or workloads. For deployments where the resources are 100% dedicated to a specific workload, grouping by AWS accounts is ideal as it is the only way to ensure fully accurate costing. Using AWS tagging should be used when you need to share resources across multiple workloads, however enterprises must note that the costing will not be 100% accurate when using tag groups.
Tracking and Allocating Costs for Workloads with Dedicated Resources
As stated above, workloads that do not need to share resources should be set up in unique AWS accounts. This can be accomplished by establishing individual AWS accounts for each workload and mapping them directly to your enterprise organizational structure. The example below illustrates how a complex enterprise can organize its cloud expenses and provide showback or chargeback reports across the enterprise.
In this example, the enterprise would receive two bills for their cloud usage – Business Unit 1 and Business Unit 2. Under each business unit there are multiple levels of cost centers that roll up to each subsequent higher level – which is typical with many Enterprise organizations. In this example, AWS accounts are created for each project/workload then rolled up to provide consolidated usage information by department and business unit. This type of structure enables:
The owners at the “resources and workload cost accrual and tracking” levels to track their individual usage by AWS accounts, which captures 100% of the cost associated with each AWS account
The management of department level to view the consolidated usage for their respective cost centers and workloads
The management of each business unit to view usage by department and AWS account and receive a bill for its entire consolidated usage
This provides a reliable and accurate methodology to track and allocate cloud usage based on your distinct enterprise organizational structure. It does, however, require a disciplined approach to creating new projects and updating your expense management platform to provide executive-level dashboards and the ability to drill-down to detailed consumption reports by cost center. This enables Enterprise IT to provide executive-level transparency while keeping excessive resource consumption under control and reduce IT costs.
Tracking and Allocating Costs for Workloads with Shared Resources
In many organizations there is a need to share key resources, such as databases, across multiple workloads. In these cases it is a best practice to use AWS tags to group your expenses. This method requires careful set up of resources and the creation of a schema to allocate shared resources and resources that cannot be tagged across the enterprise.
Tagging allows enterprises to assign its own metadata to each tag-able resource. Tags do not have any semantic meaning to AWS resources and are interpreted strictly as a string of characters. Tags are made up of both a “Key” and a “Value”. AWS allows up to 10 Keys for each resource, and each Key can have can have unlimited values enabling very detailed grouping of resources. Tagging should be set up based on the needs of the organization and the AWS architecture design. The image below illustrates how to establish a tagging scheme for a 2-Tier Auto-scalable Web Application.
As the project moves from Web Sandbox to Web Staging to Web Production, you can use tags to track usage. When the application is in the Sandbox all resources are tagged with the key “Web Sandbox” and the appropriate value (Environment, Owner, App and/or IT Tower). When the project moves to “Web Staging” you simply replace the original key and values with the ones associated with the next step in development.
While there is no one-size-fits-all solution to AWS expense management, deploying one or both of these methods can provide you the visibility necessary to successfully meet the tracking and analytical needs of your enterprise.
As firms progress through the transition from traditional IT to the AWS Cloud, there is often a moment of fear and anxiety related to managing cost. The integration and planning group has done an excellent job of selecting the right consulting partner. Contracts have been negotiated by legal and procurement. Capital funding has been allocated to cover the cost of application migrations. Designs are accepted and the project manager has laid out the critical path to success. Then at the last hour, just before production launch, the finance team chimes in – “How are we going to account for each application’s monthly usage?”
So much planning and preparation is put into integration, because we’ve gone through this process with each new application. But moving to the public cloud presents a new challenge, one that’s easily tackled with a well-developed model for managing cost in a usage-based environment.
AWS allows us to deploy IaaS (Infrastructure as a Service), and that infrastructure is shared across all of our applications in the cloud. With the proper implementation of AWS Resource Tags, cloud resources can be associated with unique applications, departments, environments, locations and any other category for which cost-reporting is essential.
Firms must have the right dialog in the design process with their cloud technology partner. Here’s an outline of the five phases of the 2nd Watch AWS Tagging Methodology, which has been used to help companies plan for cloud-based financial management:
Phase 1: Ask Critical Questions – Begin by asking Critical Questions that you want answered about utilization, spending and resource management. Consider ongoing projects, production applications, and development environments. Critical Questions can include: Which AWS resources are affecting my overall monthly bill? What is the running cost of my high availability features like warm standby, pilot light or geo-redundancy? How do architectural changes or application upgrades change my monthly usage?
Phase 2: Develop a Tagging Strategy – The Cloud Architect will interpret these questions and develop a tagging strategy to meet your needs. The strategy then turns into a component of the Detailed Design and later implemented during the build project. During this stage it’s important to consider the enforcement of standards within the organization. Configuration drift is when other groups don’t use standardized AWS Resource Tags, or those defined in a naming convention. Later when it’s time for reporting, this will create problems for accounting and finance.
Phase 3: Determine Which AWS Resources Are In Scope – Solicit feedback from your internal accounting department and application owners. Create a list of AWS Resources and applications that need to be accounted for. Refer frequently to AWS online documentation because the list of taggable resource types is updated often.
Phase 4: Define How Chargebacks and Showbacks Will Be Used – Determine who will receive usage-based reports for each application, environment or location. Some firms have adopted a Chargeback model in which the accounting team bills the internal groups who have contributed to the month’s AWS usage. Others have used these reports for Showback only, where the usage & cost data is used for planning, forecasting and event correlation. 2W Insight offers a robust reporting engine to allow 2nd Watch customers the ability to create, schedule and send reports to stakeholders.
Phase 5: Make Regular Adjustments For Optimization – Talk to your Cloud Architect about automation to eliminate configuration drift. Incorporate AWS tagging standards into your cloud formation templates. Regularly review tag keys and values to identify non-standard use cases. And solicit the feedback of your accounting team to ensure the reports are useful and accurate.
Working with an AWS Premier Consulting Partner is critical to designing for best practices like cost management. Challenge your partner and ask for real-world examples of AWS Resource Tagging strategies and cost reports. Planning to manage costs in the cloud is not a step that should be skipped. It’s critical to incorporate your financial reporting objectives into the technical design early, so that they can become established, standardized processes for each new application in the cloud.
Implementing Cloud Infrastructure in the Enterprise is not easy. An organization needs to think about scale, integration, security, compliance, results, reliability and many other factors. The pace of change pushes us to stay on top of these topics to help our organization realize the many benefits of Cloud Infrastructure.
Think about this in terms of running a race. The race has not changed – there are still hurdles to be cleared – hurdles before the race in practice and hurdles on the track during prime time. We bucket these hurdles into two classes: pre-adoption and operational.
Pre-adoption hurdles come in the form of all things required to make Cloud Infrastructure a standard in your enterprise. A big hurdle we often see is a clear roadmap and strategy around Cloud. What applications will be moving and when? When will new applications be built on the Cloud? What can we move without refactoring? Another common hurdle is standards. How do you ensure your enterprise can order the same thing over and over blessed by Enterprise Architecture, Security and your lawyers. Let’s examine these two major pre-adoption hurdles.
Having a clear IT strategy around Cloud Computing is key to getting effective enterprise adoption. Everyone from the CIO to the System Admin should be able to tell you how your organization will be consuming Cloud and what their role in the journey will be. In our experience at 2nd Watch, this typically involves a specific effort to analyze your current application portfolio for benefits and compatibility in the Cloud. We often help our customers define a classification matrix of applications and workloads that can move to the Cloud and categorize them into classes of applications based on the effort and benefits received from moving workloads to the Cloud. Whether you have a “Cloud First,” “Cloud Only” or another strategy for leveraging Cloud, the important thing is that your organization understands the strategy and is empowered to make the changes required to move forward.
Standardization is a challenge when it comes to implementing Cloud Computing. There are plenty of Cloud Service Providers, and there are no common standards for implementations. The good news is that AWS is quickly becoming the de facto standard for Cloud Infrastructure, and other providers are starting to follow suit.
2nd Watch works closely with our customers to define standards we call “Reference Architectures” to enable consistency in Cloud usage across business units, regions, etc. Our approach is powered by Cloud Formation and made real by Cloud Trails, enabling us to deploy standard infrastructure and be notified when someone makes a change to the standard in production (or Test/Dev, etc.). This is where the power of AWS really shines.
Imagine… A service catalog of all the different application or technology stacks that you need to deploy in your enterprise – now think about having an automated way to deploy those standards quickly and easily in minutes instead of days/weeks/months. Standards will pay dividends in helping your organization consume Cloud and maintain existing compliance and security requirements.
Operational hurdles for Cloud Computing come about due to the different types of people, processes and technology. Do the people who support your IT infrastructure understand the new technology involved in managing Cloud infrastructure? Do you have the right operational processes in place to deal with incidents involving Cloud infrastructure? Do you have the right technology to help you manage your cloud infrastructure at enterprise scale?
Here are some people related questions to ask yourself when you are looking to put Cloud infrastructure to work in your enterprise:
How does my IT organization have to change when I move to the cloud?
What new IT roles are going to be required as I move to the cloud?
What type of training should be scheduled and who should attend?
Who will manage the applications after they are moved to the cloud?
People are critical to the IT equation, and the Cloud requires IT skills and expertise. It has been our experience that organizations that take the people component seriously have a much more effective and efficient Cloud experience than those who might address it after the fact or with less purpose. Focus on your people – make sure they have the training and support they need to ensure success once you are live in the Cloud.
Cloud infrastructure uses some of the same technology your enterprise deploys today – virtualization, hypervisors, hardware, network, etc. The difference is that the experts are managing the core components and letting you build on top. This is a different approach to infrastructure and requires enterprise IT shops to consider what changes will need to be made to their process to ensure they can operationalize Cloud computing. An example: How will your process deal with host management issues like needing to reboot a group of servers if the incident originates from a provider instead of your own equipment?
Finally, technology plays a big role in ensuring a successful Cloud infrastructure implementation. As users request new features and IT responds with new technology, thought needs to be given to how the enterprise will manage that technology. How will your existing management and monitoring tools connect to your Cloud infrastructure? To what pieces of the datacenter will you be unable to attach? When will you have to use Cloud Service Provider plugins vs. your existing toolset? What can you manage with your existing tools? How do you take advantage of the new infrastructure, including batch scheduling, auto-scaling, reference architectures, etc.? Picking the right management tools and technology will go a long way to providing some of the real benefits of Cloud Infrastructure.
At 2nd Watch we believe that Enterprise Architecture (in a broad sense) is relevant regardless of the underlying technology platform. It is true that moving from on premises infrastructure to Cloud enables us to reduce the number of things demanding our focus – Amazon Web Services vs. Cisco, Juniper, F5, IBM, HP, Dell, EMC, NetApp, etc.
This is the simplicity of it – the number of vendors and platforms to deal with as an IT person is shrinking, and thank goodness! But, we still need to think about how to best leverage the technology at hand. Cloud adoption will have hurdles. The great news is that together we can train ourselves to clear them and move our businesses forward.
In an effort to simplify the Reserved Instances (RI) model, AWS announced yesterday a change in the model based on customer feedback and purchasing patterns.
AWS will move from three types of RIs – Fixed Price: Heavy, Medium and Light Utilization RIs – to a single type with three payment options. All continue to provide capacity assurance and discounts when compared to On-Demand prices.
The three new payment options give you flexibility to pay for the entire RI upfront, a portion of the RI upfront and a portion over the term, or nothing upfront and the entire RI over the course of the term.
What does this mean for you? These changes will really benefit predictable workloads that are running >30% of the time. In cases where usage is less consistent, it may be better for companies to stick with on-demand rates. We’ve developed some related research on usage trends. Meanwhile, our role as a top AWS partner continues to be simplifying procurement of all AWS products and services.