How cloud is charged?

The resources that you use in cloud are charged in distinct ways depending on several factors, first if you are using it as Infrastructure as a Service (IaaS) you have to be aware of the basic computing metrics involved (CPU number/type, RAM memory, Disk Size/Type, etc.).

A more advanced model is the Platform as a Service (PaaS) in which you paid Cloud Service Providers (CSPs) to take more responsibilities from you, specifically, you get Operative System, Middleware and Runtime management from external parties, and you are responsible for the specific data and application that you want to operate. Among others, Lambda Functions, API Gateway, ECS, EKS, RDS, Aurora and DynamoDB are common PaaS services that you can get from AWS.

Then you have the most abstracted form of cloud usage, which is the Software as a Service (SaaS), in which CSPs also takes care of data management and applications for you, in this way you pay to have a full service in which all functional and non-functional requirements to operate are part of the service.

Evident Costs

Some costs are easier to track, costs in an IaaS model are usually the most evident given that you can be easily understood from CSPs cost reports, IaaS expenditures are well known because it can be translated into direct metrics over time, i.e. an instance (Virtual Server) with some specs cost an standard rate per hour, so you just calculate the infrastructure cost of these by multiplying the number of instances per its costs/hour per the number of hours.

Cost of resource = number of instances * cost per hour * hours used

Specialization Costs

On top of IaaS and PaaS services you usually get some differences that are not so easy to track, those small changes that add/subtract some value from your cloud bill are marginal at the beginning but also they compound with volume and in the end can be a source of unexpected costs. For example, HTTP and REST APIs are supported through AWS API Gateway, but costs are significantly different:

REST APIs and HTTP APIs are both RESTful API products. But choosing an option to the other might imply different architectural consequences, following the example, HTTP APIs don’t support AWS Web Application Firewall protection, neither API Management thorough API Keys among other features.

There are several specialization options per CSP service that you use, the most common one is the geographical region in which you are going to deploy your solution, it could affect your costs instantly and also the availability of some services (not everyone can deploy on US-East-1), Be careful with your choices to keep your architecture evolvable and your costs on track.

Unseen Costs

Besides the things that can be tracked using standard CSPs cost utilities, there are several points of optimization that can be used to keep a continuous cost optimization, including but not limited to programming language selection -it can affect the performance of serverless executions-, over distribution in microservices-oriented architectures -which can get expensive fast in network latency and data duplication-, or tech stack modernization that will enhance data processing/analyzing.

Ignoring the cost of not adopting the ever-improving alternatives creates the culture of unchallenged success which leads to complacency. If there is a lesson from business that can be extrapolated to cloud environments is that only the paranoid thrive.

Tracking cloud costs

FinOps Cost and Usage Specification (FOCUS™) is a community effort to standardize the way that cloud billing data is generated by CSPs. Before FOCUS™ the way that each vendor track and make available the cloud cost information were unique, and that made it difficult to analyze and compare. In order to transform data points about cloud costs into usable information the first thing to do is tag each resource you deploy into a CSP. Tags allow you to map technology to business contexts and apply governance policies to resources. This may also enhance operational efficiency.

The second enabler practice to cloud cost management are monitoring and alerting tools, each CSP provides a way to set budgets and notifications about resources usage, the most practical and simple way to use them is attaching monitoring to every resource and set 50%, 75% and 90% usage alerts in a well-defined time window (for example in a month), this way you can be notified if the rate of spending is higher than expected (did you use 75% of your monthly budget in the first three days of the month? something might be wrong).

Tagging

Tags are simple and flexible labels that can be assigned to individual resources in CSPs. Each tag consists of a pair of label:value, for example, you can tag your work style as an early bird or a night owl depending if you like to work during morning or nights (I’m a work style:early bird_), in this case the tag label is work style and the tag value is early bird. Tags values can be validated against some simple rules, this way you can get some consistency in your tags, rules can be strict like allowing only certain values or flexible allowing values that look like some pattern.

AWS includes some default tags per resource automatically, those tags have the prefix aws: in their definition, but you can have up to 50 tags per resource to organize your cloud resources. Remember that tag labels are case-sensitive and that you can use some special characters in their naming: _ . : / = + - @.

Tags are used usually to:

• Resource organization: Grouping diverse types of resources under the same tag structure allows you to track data for applications that include multiple services, even different regions, in a consistent view. AWS Resource Groups Service includes a detailed guide to take advantage of this use case.

• Cost allocation: As we mentioned earlier, there is a community effort to standardize billing data using tags. While it is not automatically adopted in your AWS resources, you can always use some standard convention. AWS recommends the following tags as mandatory for every resource:

  • Business Unit
  • Cost Center
  • Financial Owner
  • Owner
  • Software Development Life Cycle (SDLC) Stage

AWS also includes the createdBy tag automatically in some of their services if you activate it manually. You can enforce (with some limitations) the tagging in AWS by setting a Tagging Policy.

• Operations and support: Usually a cloud environment is composed of multiple resources, accounts, folders, and workloads that have different service level agreements. Tags are useful to provide visibility in a simple way of those non-functional requirements and act accordingly with support teams.

• Data classification Tagging can be used to classify data origins and set access control policies, data retention policies or fulfill compliance requirements.

Monitoring and Alerting

Once you can find Resource Groups or individual resources in you CSP the real fun starts. Monitoring and Observability are considered critical in modern architectures, given that non-functional requirements compliance implies to keep a constant check over deployed systems. In this cost management specific scenario CSPs provides cost monitoring tools that can execute actions under certain circumstances,

AWS provides the Billing and Cost Management suite that lets you set soft limits over fixed values or a percentage of the forecasted value, once those limits are reached automated actions can be taken like notifications or policies application.

Budgeting itself is a long story, but the important thing is to setup a budget for each resource as soon as possible to establish the acceptable levels of expenses in a cloud-native solution.

Next steps

You can start with Tagging and Monitoring & Alerting at any time, many companies wait until cloud billing has surged in unexpected ways to react after having to pay large bills. Using aXumption your company can act in a preventive way to set automatically reasonable defaults for tagging/monitoring and cost management from the design phase. If you have already deployed resources to the cloud aXumption helps you to include cost-management as a non-functional requirement.