CSP platforms are inherently built to be cost transparent. There are no hidden fees or service charges that a customer can't see until they begin building on the platform. All pricing is posted and kept updated on the sites of the big three and is readily available to anyone interested in pricing out an architecture. As mentioned earlier, pricing calculators are available from the CSPs to help prospective customers price out an environment before building. This trend was first established by AWS when they released their initial cloud services and have remained true to this day.
In a similar vein, once systems have been built on the cloud, each CSP has native services to help monitor, drill down, and explore service consumption and their related costs. AWS's Billing & Cost Management Dashboard is a perfect example of these cloud native capabilities. Features such as AWS Cost Explorer allow users to drill down into monthly bills, look at historical spends, and anticipate future spending. Budgets allow users to set custom budgets that can trigger alerts or alarms when the cost or usage of something has exceeded the set limits. These tools allow cloud admins to confidently set guardrails around the usage and costs incurred through cloud services:
We can very easily ascertain the last, current, and next month's costs in one simple view. On the right, we can see which services we are incurring costs for.
Central to being able to navigate the thousands or millions of resources that an enterprise will provision in a cloud environment is tagging. Tagging is the fundamental method with which resources can be assigned to cost centers, programs, users, lines of businesses, and purposes. Without tagging, a cloud environment would be almost impossible to properly maintain across a large organization. We will cover best practices for tagging as it relates to cost management in the next section.
Historically, IT budgets have been exposed to capital investment models that are expended upfront. With the cloud, this was shifted to OpEx models where consumers had more control over operational costs. The next step in this evolution is the ability to set hard or soft limits for spending within portions or across the entire IT landscape of an enterprise. These budgets are enforced natively in the platform through APIs or notification services that alert admins when consumption is exceeding these thresholds.
AWS Budgets (https://aws.amazon.com/aws-cost-management/aws-budgets/), Azure Spending Budgets (https://docs.microsoft.com/en-us/partner-center/set-an-azure-spending-budget-for-your-customers), and GCP Budgets (https://cloud.google.com/billing/docs/how-to/budgets) are examples of cloud native methods to control and limit spending. This is a critical feature for large organizations where the activities and spending of certain groups may not immediately be visible to leadership or budget owners.
Budget thresholds can be set to alert administrators when costs exceed limits, when the use of certain services/features exceed set limits, or when consumption of pre-paid resources (such as Reserved Instances on AWS EC2) exceed set limits. These budgets can be aligned on different periods (monthly, quarterly, or annually), giving admins flexibility in how they choose to enforce constraints across the organization. Optionally, notifications can be set to alert you when you're approaching certain percentages of the budget:
Setting budgets is an effective way of monitoring cloud costs. Systems will automatically notify you when you are approaching or exceed set spend amounts. The following shows you this setting:
Billing alarms can be configured to trigger email notifications. This allows you to minimize overspending and keep your cloud environment cost optimized. The following screenshot shows the notification setup:
There are also third-party tools that work across different cloud platforms to aggregate, display, and predict costs—these will be introduced in the Cloud Native Toolkit at the end of the chapter.
When taking into account best practices for deployment and management discussed in the previous chapters, immutable architectures require a unique approach. Since each deployment replicates the entire stack or a modular component of it, we can price it out before deployment. Using AWS Cloudformation, on the final confirmation page before deployment, you can confirm the stack's monthly cost using the Cost link beside Estimate Cost. This navigates the user to a prepopulated Simple Monthly Calculator:
When managing deployments as stacks expressed as code, each stack can be priced out before deployment (as in the preceding case of the CloudFormation stack being deployed on AWS).
The following screenshot shows an example simple monthly calculator estimate, which was generated from a sample CloudFormation template deployment (shown in the previous screenshot):
