If you’re using any cloud, you might regularly ask yourself questions like, “Why is the bill so high this month?” or “What would it actually cost to move this application to the cloud?” If so, this blog is for you. Today, I aim to make you familiar with the practices you need to control and predict your cost without compromising your performance.
Whether you’re part of the finance department in charge of controlling the budget, a business decision-maker evaluating a new project, or a DevOps engineer thinking of new functionality for your application, cloud cost management is mission-critical and can make or break your business. Accessing limitless possibilities is leading to cloud exuberance, and it’s time to tame the beast.
Tagging is my number one piece of advice I’d give to any organization starting in the cloud. Even if your environment is not structured well at the start, using tags, especially mandatory predefined and cost-tracking tags for consistency, allows you to classify your resources and then run search and bulk actions.
Think of tags as any string of text that you assign to a resource that describes resource type, environment (production, staging, or test), project name, roles, business unit, department, cost center, instance number, and so on. With those elements at hand without hierarchical constraints, you can quickly identify the high costs and their relevancy. Then you can automatically share your finding with the relevant stakeholders using Cost Analysis or directly perform bulk actions on a set of resources.
Furthermore, you can set a maximum budget and a budget alert for all resources using a specific tag, preventing accidental spending, as illustrated below.
For more detailed tips on tagging best practices, see Best Practices for Using Tags to Manage Costs, Operations, and Governance.
When Oracle launched Oracle Cloud Infrastructure (OCI), we introduced the concept of isolated compartments within a tenancy. Within that tenancy, administrators can separate resources per compartment in a hierarchical manner. Those compartments and sub-compartments can represent a project, a team, or any other group of resources you might need. For large organizations, we’ve as well introduced the concept of parent and child tenancies to simplify the administration tasks.
By separating resources by project or department in distinct compartments, you can track usage and cost. More importantly, you can set up service quotas. Service quotas are a powerful way to limit resources that are accessible by default to the team working in specific compartments. For example, you could choose to control that expensive Exadata resources are used only in production as illustrated below or fix a limit to the available storage in a project. Fixing quotas allows you to do both simply.
Let’s say you don’t want to allow CompartmentA to use the bare metal server, so you enter the following quota policy:
Zero compute limits /*bm*/ in compartment CompartmentA
Then you want to limit the resources to a compartment to just 2 Core X7, so you enter the following policy:
Zero compute quotas in compartment CompartmentA Set compute quotas vm-standard2-2-count to 2 in compartment CompartmentA
Lastly, let’s limit the use of Object Storage to 500 GB:
Set object-storage quota storage-bytes to 500000000000 in compartment CompartmentA
For further policy examples, see the Compartment Quotas documentation.
Separating your projects into compartments and sub-compartments and using service quotas is the best way to avoid surprise bills at the end of the month and keep your budget under control.
The business benefits of the cloud are the capacity to easily scale up your resource and pay only for the resources you use. So, you can exploit the associated benefit to scale down resources when you don’t need them. On OCI, Compute virtual machine (VM), bare metal, and even GPU instances are charged per hour. And your commitment is annual instead of monthly so that a lower month can compensate for one peak month over the year eliminating monthly over-usage cost.
But if production systems have to run 24/7, other VMs like test or development environments only need to run during office hours. Keeping them running during the night or weekends makes no sense. Turning on and off on-premises servers can be a tedious task. In the cloud, you can script this action. You can use your favorite language and add a cron job in an instance, or use the documented OKE CronJob to schedule downtime or even use our CLI command with our fully managed, serverless Functions-as-a-Service (FaaS) platform.
Just to give you an idea, by scheduling VMs to turn off between 9 P.M. and 6 A.M. every day and from 9 P.M. Friday to 6 A.M. on Monday, you realize almost 40% savings!
This possibility is unique to the cloud. Exploit its flexibility to assign different schedules to different groups of instances and run a clean shutdown script in advance so that it’s transparent for your developers working on those resources. And it doesn’t prevent one developer from relaunching an instance on the spot if they need it at an odd hour.
Another question that comes up when you move to the cloud is sizing. Selecting the wrong instance size or type has a large impact on cost. DevOps teams have continuous choices to make regarding the CPU, storage, and IOPS for their load to fit the need of their users.
Given that choice, you want to ensure the following factors:
The performance you choose is predictable.
You have full flexibility on those parameters.
Here, Oracle Cloud differs from others.
Thanks to its latest design, OCI offers predictable performance backed-up by an SLA. This SLA is possible because of several design innovations. Among them is the commitment of Oracle to not share thread across virtual machines. The ability to predict performance and the confidence that, with 1 OCPU, you get a physical core with dedicated thread to bring significant cost saving because 1 OCPU provides the equivalent performance of 2 VCPsU in other clouds.
Remember, 1 OCPU = 2 VCPU.
The real flexibility of Oracle Cloud is another innovation that helps lower cost by using exactly the shape you need and not just the one that fits best. As shown in the following example, you can select the CPU and the RAM you need without being constrained by a limited choice.
When you’re determined to lower your cloud cost, start with the low-hanging fruit first: look for ways to reduce the highest costs. Using Cost Analysis, you get access to a detailed analysis of your cost in the cloud and can orient your focus area.
If compute is the highest cost, use a scheduler or adjust the CPU to the minimum and use an instance pool for peak demand. If it’s storage, archive your storage earlier or adjust the storage performance more tightly. With OCI, you can adjust Block Storage performance or Object Storage performance easily. If the network is the highest cost, optimize your app and compress the data.
Applying those five tips can immediately have an impact on your bill. Stay tuned for part two of this blog in the coming days to get more cost-saving tips for your organization.
As always, you can try all these features for yourself with a free trial. If you don’t already have an Oracle Cloud Infrastructure account, sign up today.