The cloud bill has a particular way of growing. Nobody decides to spend more. Nothing obviously changed. And yet each month is a little higher than the last, and nobody can quite say why.
The reason is simple once you see it: the cloud never switches anything off for you. Every server, disk, backup and address that exists is billed, by the hour or by the gigabyte, whether or not anybody is using it. So a bill that only ever goes up usually means things are being created faster than they are being removed.
This guide uses the cloud providers' own documentation to show where the money actually goes and what to fix first. It is written for owners and managers rather than engineers. You do not need to understand the technology to follow it, and most of the first fixes do not need a developer at all.
Why does a cloud bill keep growing?
A cloud bill keeps growing because resources are created easily and removed rarely, and the provider bills for everything that exists rather than everything that is used. Test servers outlive their tests, disks outlive their servers, backups accumulate, and data transfer rises with traffic. None of these is a decision anybody made. Each is an absence of a decision.
This matters because it tells you the fix is mostly about removal and habit, not about negotiating with the provider or moving somewhere cheaper.
There are four things you pay for, broadly:
Compute, meaning the servers, containers or functions that run your software. Usually billed per hour or per second while they exist.
Storage, meaning disks, file storage, databases and backups. Billed per gigabyte per month for as long as the data exists.
Data transfer, meaning data moving out of the cloud or between parts of it. Billed per gigabyte.
Managed services, meaning databases, load balancers, monitoring and similar components the provider runs for you. These cost more per unit than doing it yourself, and they remove operational work in exchange.
Compute is the line people expect. Storage and data transfer are the lines that surprise them.
How to read a cloud bill without being an engineer
Group the bill by service, compare it with the previous three months, and ask about the largest line and the fastest-growing one. You do not need to understand the technology to do that, and it is where every useful conversation about cost starts.
The raw invoice is hard to read because it lists hundreds of usage lines with names like region codes followed by resource types. Ignore that view. Every provider has a cost report that groups spending by service and by month, and on AWS it is the Cost Explorer console, which is free and shows up to 13 months of history [36].
Once the bill is grouped, the names become manageable. On AWS, EC2 is servers, EBS is the disks attached to them, S3 is file storage, RDS is managed databases, VPC charges usually mean NAT gateways and public addresses, and data transfer appears as its own line. Azure and Google Cloud use different names for the same ideas, and their cost reports group them the same way.
Three questions get you most of the way.
What is the largest line, and does its size make sense? If your servers are the largest cost, that is normal. If a NAT gateway or data transfer is near the top, something is probably worth investigating.
What has grown steadily over three months? Steady growth with no matching growth in customers or activity usually means accumulation: storage, snapshots or resources nobody removed.
Is there anything nobody recognises? A service that nobody in the business can explain is either something a supplier set up and never mentioned, or something left over from a test. Either way, somebody should find out.
Take those three answers to whoever manages the system. You are not asking them to justify every line. You are asking them to explain the shape of the bill, which anybody who runs it should be able to do in a few minutes.
The things that keep billing when nobody is using them
Stopped servers, leftover disks, old snapshots, idle load balancers and unused public addresses all keep billing when nobody is using them. This is where most unexplained growth lives, and the providers document it themselves.
Stopped servers still cost something. AWS states that you are not charged for usage or data transfer on a stopped instance, but charges are still incurred to store its disks [44]. An address attached to a stopped server is also charged. Stopping is not the same as removing.
Disks can outlive their servers. AWS documents that by default, data volumes attached after a server was launched are preserved when that server is terminated, and that preserved volumes continue to incur charges until you delete them [2]. This is a common source of silent cost: a server was removed months ago, its extra disks were not, and they have been billing ever since.
Old snapshots accumulate. Disk snapshots are billed per gigabyte per month [3]. Each new snapshot only stores what changed, which keeps individual snapshots small, but a long history of them adds up, and nobody is ever prompted to delete them.
Idle load balancers bill by the hour. AWS charges for each hour or partial hour an Application Load Balancer is running [4], whether or not any traffic reaches it. A load balancer left over from a test or an old version of the system is pure cost.
Public IP addresses are charged, even idle ones. AWS's pricing lists an hourly charge for public IPv4 addresses, and the same charge applies to addresses that are allocated but not attached to anything [5]. Small per hour, easy to forget, and they add up across a year.
Servers in regions nobody looks at. A test launched in a different region does not appear when you look at your usual region. AWS describes its EC2 Global View as especially useful for taking inventory and finding forgotten instances [1].
None of these requires technical skill to find. They require somebody to look.
Test environments running all weekend
Development and test environments are usually needed during working hours only, and most run all the time. This is often the single largest easy saving in an account.
AWS makes the point with its own arithmetic. Development and test environments are typically used about eight hours a day during the working week, so stopping them when they are not in use can save around 75 per cent of their cost: 40 hours of use against 168 hours in a week [6].
The fix is a schedule. AWS offers a solution called Instance Scheduler that stops and starts servers and databases automatically based on tags and a schedule you define, noting that running the scheduler itself carries additional charges [7]. Azure and Google Cloud have equivalent approaches.
Two conditions make this safe. First, environments have to be clearly labelled, so production is never on the schedule. Second, the team needs to know how to start an environment early when they are working late. With both in place, this is a change that saves money every week and costs nobody anything.
A note on UAE working weeks. If your schedule is set by somebody using a template built for a different weekend, check it. A schedule that keeps servers running on your weekend and stops them on a working day is worse than no schedule, because it will be switched off in frustration and never switched back on.
Servers bigger than they need to be
Most servers are sized at launch, by a guess, and never revisited. They were chosen for a peak that never came, or doubled "to be safe" during a stressful launch week, and have run at a fraction of capacity ever since.
Running each server at the size it actually needs is called rightsizing, and every major provider will help you find the candidates.
AWS Compute Optimizer analyses how your resources are configured and how busy they actually are, and recommends smaller sizes or identifies idle resources. It needs to be switched on, and looks back 14 days by default [8].
Azure Advisor identifies resources that were not used at all over the previous seven days and recommends shutting them down. Microsoft notes its savings estimates are based on retail rates, so the listed savings may be higher than you will actually achieve [9].
Google Cloud provides idle VM recommendations for machines that have not been used over the previous one to fourteen days, free of charge [10].
Treat the recommendations as a list of questions rather than instructions. A server that looks idle for two weeks may be the one that runs month-end reporting. Ask whoever owns it before resizing, and resize one step at a time rather than to the smallest size the tool suggests.
Data transfer: the line nobody predicts
Moving data out of the cloud is metered, and it is the charge people most often fail to anticipate. It is rarely the largest line, but it is frequently the most surprising, and it can grow with traffic without anybody changing anything.
The basic rules on AWS are these:
Data coming in from the internet is free. AWS states there is no charge for data transfer from the internet to AWS [11].
Data going out to the internet is charged, with the first 100 GB per month free across your account [12].
Data moving between regions is charged on the way out of the source region [11].
Data moving between availability zones in the same region is charged in both directions for many services [11]. A system spread across zones for resilience, which is good practice, pays for the traffic between them.
Azure follows a similar pattern, with inbound transfer free and outbound transfer charged after a free allowance [13].
The NAT gateway problem
One component deserves its own mention because it catches so many accounts. A NAT gateway lets servers without public addresses reach the internet, which is a sensible security design. AWS charges for it in two ways: an hourly charge for every hour it exists, and a data processing charge for every gigabyte that passes through it [5].
The costly pattern is private servers sending large volumes of data to storage in the same region through the NAT gateway. Every gigabyte picks up a processing charge that did not need to exist. AWS's own suggested fix in its pricing documentation is a gateway VPC endpoint, which avoids that charge for that traffic [5].
If a NAT gateway is one of your largest lines, ask whoever built the system what is flowing through it. The answer is frequently a quick fix.
Storage that only ever grows
Storage is the one thing almost nobody deletes. Logs, backups, customer uploads, old exports and snapshots all accumulate indefinitely unless a rule removes or archives them.
It rarely causes a sudden jump, which is exactly why it goes unnoticed. It just becomes a larger share of the bill every month.
Two tools on AWS address it directly, and the other providers have equivalents.
Lifecycle rules move files to cheaper storage classes as they age, or delete them after a set period. AWS describes S3 Lifecycle as transitioning objects to lower-cost classes or deleting expired objects on your behalf, noting that transition requests themselves carry a cost [14].
Intelligent-Tiering moves files between tiers automatically based on how often they are accessed, for a small monthly monitoring charge. AWS states savings of up to 40 per cent in its infrequent access tier, 68 per cent in its archive instant access tier and 95 per cent in its deep archive tier [15].
For disk snapshots specifically, AWS offers an archive tier that it says costs up to 75 per cent less for snapshots kept for 90 days or more and rarely accessed [16].
The decision that comes first is a retention policy. How long do you actually need each kind of data? Some of it you are legally required to keep for a period, and some of it you are required not to keep beyond a period. Our guide on data retention covers that side. Once the policy exists, lifecycle rules simply enforce it.
Paying less per hour: commitments
Once you are only running what you need, you can pay less for it by committing to a steady level of usage for one or three years. Every major provider offers this, and the discounts are substantial.
AWS states Savings Plans can save up to 72 per cent, with the more flexible Compute Savings Plans at up to 66 per cent, in exchange for committing to a consistent amount of usage per hour for one or three years [17]. Reserved Instances offer up to 72 per cent compared with on-demand prices [18].
Azure states Reservations can reduce costs by up to 72 per cent on one or three year terms, and its savings plan for compute up to 65 per cent. Microsoft notes savings plan purchases cannot be cancelled or refunded, that unused hourly commitment does not roll over, and that eligibility depends on your agreement type [19][20].
Google Cloud states committed use discounts of up to 55 per cent for most machine series and up to 70 per cent for memory-optimised machines, on one or three year terms. It also applies sustained use discounts automatically to certain older machine families that run for more than a quarter of a month [21][22].
Three things to understand before buying any of them.
These are ceilings, not typical outcomes. "Up to" figures usually apply to the longest term and the least flexible option. Your actual saving depends on what you run.
You pay whether you use it or not. That is the deal. A commitment covering usage you later remove is money spent on nothing.
Order matters more than anything else. Remove waste first, then commit. If you commit before cleaning up, you lock in a discount on servers you did not need. The FinOps Foundation distinguishes usage optimisation, which is using less, from rate optimisation, which is paying less per unit [23]. Do them in that order.
Spot capacity, for work that can wait
AWS also sells spare capacity as Spot Instances, which it describes as up to 90 per cent off on-demand prices [24], with the condition that AWS can take the capacity back with a two-minute warning [25]. That makes Spot excellent for work that can be interrupted and restarted, such as batch processing or some testing, and entirely unsuitable for your website, your database, or anything a customer is waiting on.
Does hosting in the UAE cost more?
Cloud prices differ by region, and AWS states this directly: each region operates within local market conditions, with differences in the cost of land, connectivity, power and taxes [26]. We have not published a percentage difference because it varies by service and changes over time. Compare the specific services you use in the provider's pricing calculator.
AWS's own cost guidance is useful here. It advises deploying in higher-cost regions only where latency, data residency or data sovereignty requires it [26].
Where you can host in the UAE today:
AWS opened its Middle East (UAE) region, me-central-1, on 29 August 2022, with three availability zones. It must be enabled in your account before use [27][28].
Microsoft Azure has UAE North in Dubai and UAE Central in Abu Dhabi. Microsoft lists UAE Central as access-restricted, intended for specific scenarios such as disaster recovery [29].
Oracle Cloud has regions in Dubai and Abu Dhabi [30].
Google Cloud's official region list shows no UAE region. Its nearest Middle East regions are in Doha and Dammam [31].
For most private businesses there is no blanket legal requirement to keep all data in the UAE, but sector rules, government work and customer contracts can require it. Our guide on where your data lives covers the position.
The practical cost option some businesses use is keeping production systems and personal data in a UAE region while running non-sensitive development and testing elsewhere, where their regulators and contracts allow it. That is a decision to make deliberately and document, not a default to drift into.
Budget alerts warn you. They do not stop you.
A budget alert is an early warning, not a spending limit, and treating it as a limit is a common and expensive misunderstanding.
Microsoft is explicit: when a budget threshold is exceeded, resources are not affected and consumption is not stopped. It also notes cost data typically arrives within 8 to 24 hours and budgets are evaluated every 24 hours [32].
AWS makes the same point in its own way, noting that you might incur costs beyond your notification threshold before AWS Budgets is able to notify you [33]. AWS Budgets notifications themselves are free.
The practical response is to set alerts below the number you care about. If AED 5,000 a month is your real limit, alert at a lower figure, and alert on forecast spend as well as actual spend, which AWS Budgets supports [33]. The aim is that the warning arrives while there is still time to act.
Anomaly detection catches what budgets miss. A sudden spike in one service can still leave the month under budget and trigger nothing. AWS Cost Anomaly Detection uses machine learning to flag unusual spending patterns, and AWS notes it can take up to 24 hours to detect an anomaly after the usage occurs [34]. It will not prevent a spike, but it shortens the time between something going wrong and somebody knowing.
Knowing whose cost it is: tagging
If you cannot say which project, client or team a cost belongs to, you cannot manage it. Tags solve that.
A tag is a label attached to a resource: owner, project, environment, client. With tags in place, the bill can be broken down by any of them, and every conversation about cost starts from a report rather than an investigation.
On AWS, tags have to be activated as cost allocation tags before they appear in cost reports, and AWS notes they can take up to 24 hours to appear [35].
Three tags are enough to start: who owns it, what it is for, and whether it is production, staging or development. The third one also makes scheduling safe, because it is how the scheduler knows what never to touch.
The hard part is not the tagging, it is the habit. Make a tag a condition of creating anything new, and do a one-off pass on what already exists. Anything nobody will claim during that pass is a strong candidate for removal.
The free tools you already have
Most businesses already have more cost visibility than they use.
On AWS: the Cost Explorer console is free and shows up to 13 months of history with a forecast [36]. Budgets notifications are free [33]. Compute Optimizer is available once you opt in [8]. Cost Anomaly Detection can be switched on alongside them [34].
One catch on AWS: Trusted Advisor's cost-saving checks, which flag idle load balancers, underused disks, low-utilisation servers, idle databases and unattached addresses, require a paid AWS support plan [37][38]. Do not assume you have them.
On Azure: Advisor cost recommendations and Cost Management budgets are built in [9][32].
On Google Cloud: idle VM recommendations are free [10].
The tools are not the constraint. The constraint is that nobody has been asked to look at them regularly.
A monthly routine that keeps the bill honest
One hour a month, with alerts running in between, is enough for most small and mid-sized businesses. The FinOps Foundation describes the practice as three repeating phases: Inform, Optimize and Operate [23]. In plain terms, that is look, decide, act.
Look. Compare this month with last month, by service. Note anything that grew and anything nobody recognises.
Decide. For each increase, write one sentence explaining it. "Traffic grew after the campaign" is a fine answer. "Not sure" goes on a list with a name next to it.
Act. Remove what is unused, resize what is oversized, and fix whatever produced the increase. Once or twice a year, revisit whether a commitment now makes sense for the steady baseline.
Who owns this matters more than how it is done. The FinOps Foundation describes the practice as creating financial accountability through collaboration between engineering, finance and business teams [39]. In a small business that usually means finance sees the bill, the technical lead explains it, and one named person is accountable for acting on it. When the bill belongs to everybody, the forgotten test server belongs to nobody.
If a supplier runs your cloud for you
Ask them to explain the three largest lines on your bill, and whether each one reflects a choice they would make again. It is a fair question and a revealing one.
Some architectures move a lot of data between zones, regions or through NAT gateways, or run more always-on components than the workload needs. None of that is wrong in itself. It should be a decision rather than an accident.
Make sure the account is yours. The cloud account should be registered to your business, with the billing visible to you, and the supplier given access rather than ownership. Our guide on the accounts your business must own covers why this matters and how to set it up.
Be cautious about rebuilding for cost reasons. Moving to a different architecture or provider can reduce costs, and it is also a project with its own cost and risk. Waste tends to follow you if the habits that produced it do not change. Clean up the platform you have first, and only then decide whether a bigger change is justified. Our guide on moving to the cloud covers the migration side.
The first week, in order
- Set up a budget alert and switch on anomaly detection. Free, ten minutes, and from now on surprises arrive as notifications rather than invoices.
- Look at the last three months by service. Note the largest line, anything that has grown steadily, and anything nobody recognises.
- Hunt for things that exist but do nothing. Stopped servers, unattached disks, old snapshots, idle load balancers, unused public addresses, and servers in other regions.
- Put test environments on a working-hours schedule, once production is clearly labelled.
- Check the NAT gateway and data transfer lines and ask what is flowing through them.
- Set a retention policy and lifecycle rules for logs, backups and uploads.
- Resize what is oversized, one step at a time.
- Watch the bill settle for a month or two, then consider commitments for the steady baseline that remains.
On deleting things you are not sure about: snapshot or back up first, stop or detach rather than delete, and wait a few weeks to see if anybody notices. Deleting a production resource by mistake costs far more than any saving.
On how much you will save: it depends on how much waste exists, which is why we do not quote a percentage. An account that has never been reviewed usually has obvious savings. One that is already well managed has less. A review tells you which you have, in specific amounts.
When to get help
A cloud cost review covering your last three months of spending, unused and oversized resources, data transfer, storage and whether commitments make sense starts from around AED 3,000 with us. We deliver it as a list of specific changes, each with its expected saving. No official body publishes rates for this work, so these are our own figures. Implementing the changes is quoted separately by scope. Final pricing depends on scope.
Whether or not you use anybody, set up the budget alert this week. It costs nothing, and it is the difference between watching the bill and being surprised by it.
References
- AWS, stop and start Amazon EC2 instances
- AWS, preserve data when an instance is terminated
- AWS, Amazon EBS pricing
- AWS, Elastic Load Balancing pricing
- AWS, Amazon VPC pricing
- AWS Well-Architected, Cost Optimization Pillar design principles
- AWS, Instance Scheduler on AWS
- AWS, what is AWS Compute Optimizer
- Microsoft, Azure Advisor cost recommendations
- Google Cloud, idle VM recommendations
- AWS, understanding data transfer charges
- AWS, Amazon EC2 on-demand pricing
- Microsoft, Azure bandwidth pricing
- AWS, managing the lifecycle of objects in Amazon S3
- AWS, Amazon S3 storage classes
- AWS, Amazon EBS snapshots archive
- AWS, Savings Plans
- AWS, Amazon EC2 Reserved Instances
- Microsoft, save costs with Azure Reservations
- Microsoft, Azure savings plan for compute
- Google Cloud, committed use discounts
- Google Cloud, sustained use discounts
- FinOps Foundation, FinOps phases
- AWS, Amazon EC2 Spot Instances
- AWS, Spot Instance interruption notices
- AWS Well-Architected, select Regions based on cost
- AWS, now open: AWS Region in the United Arab Emirates
- AWS, Regions list
- Microsoft, list of Azure regions
- Oracle Cloud Infrastructure, regions and availability domains
- Google Cloud, regions and zones
- Microsoft, create and manage budgets
- AWS, managing your costs with AWS Budgets
- AWS, detecting unusual spend with AWS Cost Anomaly Detection
- AWS, organizing and tracking costs using cost allocation tags
- AWS, analyzing your costs with AWS Cost Explorer
- AWS, Trusted Advisor
- AWS, Trusted Advisor cost optimization checks
- FinOps Foundation, what is FinOps
- SKIMBOX, cloud migration to AWS in the UAE
- SKIMBOX, data residency and where your data lives
- SKIMBOX, the accounts your business must hold in its own name
- SKIMBOX, data retention for UAE businesses
- AWS, how Amazon EC2 instance stop and start works
Cloud prices, discount ceilings and product features change frequently. The figures here are the providers' own published maximums as of September 2026, not typical outcomes. Check the linked pages for current terms before making a commitment.
