When we are looking at ‘controlling’ costs for Oracle Cloud we are really focusing in on the governance of Cloud spend. This is something that is vital to do, we want to ensure there are no unexpected Cloud bills. Governance therefore is ensuring that it doesn’t happen but if it does; we need to know about it. Subsequently, we will look at it from a number of different perspectives.
If we are looking to ensure it doesn’t happen we firstly need to define what our level of spend is. This is typically taken from the bill of materials (BoM). The BoM is going to define what resources we require in our Oracle Cloud Migration so the focus should be given to:
The majority of your Oracle Cloud infrastructure costs are going to be on these areas of spend; other costs can be attributed to: Load Balancing, WAF and Email Service but the majority will be the core resources. Remember, I’m talking about typical Cloud migrations; there are lots of other services in OCI which you may use but for this I’m just focusing on the common elements.
The biggest challenges in some Cloud providers is the difficulty to estimate usage elements of things like VPNs, NAT gateways or Load Balancers. This is because their charges are constructed two-fold; service charges and data processing charges. This makes it difficult to really estimate what the expected level of spend is. The good news is with an Oracle Cloud Migration there is no service charges for all gateways and there are NO data processing charges for elements like Load Balancers (although they have a small fixed service costs). Furthermore, general data egress is free up to 10TB per month; (and completely free over Fast Connect) giving further reassurance that your BoM cost will be very close to your actual cloud bill.
So if your VMs are correctly sized and associated Cloud costs are minimal or non-existent where do the problems arise? Well, the first one is curiosity. In the initial Cloud migration it’s not uncommon for teams to spin up infrastructure for testing; maybe an additional late requirement came in, maybe the DBAs wanted to just have a look at a PaaS instance. Therefore to help us control this we can use service limits both hard and soft.
Soft service limits are set within the Oracle Cloud console and they can be controlled by the OCI administrators; these can be broken down to compartments; regions or ADs depending on the requirement. Hard limits are set by Oracle and through the use of service requests these can be increased or decreased. The first job in controlling costs in an Oracle Cloud migration is to set your service limits at both a hard and soft level. If you know there are some resources you will never ever use just remove them altogether.
So, if you can use hard and soft limits to control general infrastructure over provisioning how can you ensure that you’re alerted if spend does increase? For that you can use OCI Budgets.
OCI Budgets allow you to set a monthly spend limit and an alert threshold to send an email alert when the threshold is breached. The threshold can be a percentage limit on spend so if you set yourself a limit of £1000 P/M you can get a notification when that hits £900 giving you time to react and investigate to either adjust the usage of those resources or at least have visibility and understanding of what causes this months breach. Budgets can be set at compartments (logical resource containers) or tags so there is enough flexibility for all use cases.
Both methods detailed above are really simple ways to maintain a level of governance with your Cloud spend and more importantly, they don’t take much time to implement. The great thing about Cloud is that anyone can spin up limitless infrastructure providing great flexibility; the bad thing about Cloud is that anyone can spin up limitless infrastructure providing great costs!
If you want to provide better governance over your Oracle Cloud spend look to use limits and budgets and if you would like further information please book a meeting with DSP-Explorer today.
Please find below some useful resources when it comes to Oracle Cloud Migration.