Cloud Cost Optimization: What Lock-In Costs a Fintech

Most cloud cost optimization work starts too late and in the wrong place. Someone opens Cost Explorer in month twenty, finds the idle instances, buys a Savings Plan, and takes eleven per cent off a bill that has been doubling every year. The eleven per cent is real. It is also the last easy win, because the shape of the bill was decided in week one by architecture nobody was thinking about as a purchasing decision.

Here is the position, and it is not a complaint about AWS. The lever that moves a cloud bill more than any Savings Plan is whether you could credibly run the workload somewhere else. Not whether you do. Whether you could.

Two failure modes we see regularly: a team on year-two credits that has quietly welded itself to four proprietary services, and a team that reads "cloud-agnostic" as "run on three clouds at once" and burns a quarter building an abstraction nobody needed.

Why does cloud cost optimization stall in year two?

Because by then the bill is mostly things you cannot switch off. Compute you can right-size. Storage you can tier. What grows underneath is data movement, managed-service premiums and the long tail of resources attached to a product feature somebody shipped and forgot.

Take the plumbing, which nobody models at the start. A NAT gateway costs $0.045 per hour plus $0.045 for every gigabyte processed, and the processing charge applies "regardless of the traffic's source or destination". Ten terabytes a month through that gateway is about $460 before a byte leaves AWS. Then egress: after the free 100 GB a month aggregated across services and regions, data transfer out to the internet starts at $0.09 per GB from US East, and the rate is "specific to the originating Region", so the Mumbai number is its own — look it up rather than assuming parity.

We wrote the detailed version of this in the post on what a fintech can cut from an AWS bill without failing an audit. The point here is different: every one of those lines is a price set by one vendor, on a workload that cannot move.

Is any one cloud actually cheaper?

No, and the honest answer is more useful than the marketing one. Kubernetes is the clean example, because the claim you will hear — EKS charges for the control plane, GKE does not — is wrong.

EKS is $0.10 per cluster per hour on a supported version, and $0.60 once the cluster drops into extended support: a version you did not upgrade costs six times more to keep. GKE charges the same $0.10 per cluster per hour, on every cluster, "irrespective of the mode of operation, cluster size, or topology". What Google adds is a free tier of $74.40 in monthly credits that covers one zonal or Autopilot cluster. One cluster free, then identical. If you run eight clusters, the two bills are the same and the decision belongs to something else entirely — which parts of the cluster you are still responsible for, which is its own question on EKS.

That pattern repeats. Compute list prices differ, and the discount mechanisms differ more; the gap opens on egress and on managed databases, where you pay for somebody else to run Postgres. Prices also move: AWS has cut Mumbai prices before and will again. So the useful question is not "which cloud is cheapest" but "when this line item doubles, what are my options".

What does lock-in cost when the price moves?

It costs the negotiation. A vendor that knows you cannot leave has no reason to discount, and every reason to let list prices drift. It also costs placement: a batch job that does not care about latency, sitting in your most expensive region because that is where everything lives.

The sharpest version is a rewrite. Lambda, DynamoDB and Cosmos DB are good services with no equivalent anywhere else, so the cost of leaving is not a migration, it is a rebuild of the application logic that grew inside them. We are not saying avoid them. We are saying price them as a decision that is expensive to reverse, and take them deliberately, for the pieces where the managed behaviour genuinely earns it.

Are startup credits a discount or a deposit?

Free credits are the cheapest lock-in a cloud vendor ever buys.

The numbers are generous and public. AWS Activate runs from $1,000 for self-funded founders up to $200,000 for portfolio startups, with more by invitation. The Google for Startups Cloud Program goes up to $200,000 over two years — the first year covering 100% of spend up to $100,000, the second covering 20% — and up to $350,000 for AI-first companies. Microsoft for Startups Founders Hub offers up to $150,000 in credits.

None of that is charity; it is customer acquisition, and it works. The mechanism is simple. Credits make the expensive managed services feel free at exactly the moment you are choosing your architecture. Two years later the credits end, the invoice arrives at list price, and the services you would most like to leave are the ones holding your data model.

There is a second trap in the expiry. Credits you do not spend are gone, which quietly rewards spending them badly — a cluster left running, a warehouse over-provisioned, a pipeline nobody turned off.

So take the money. Take all three programmes if you qualify. Just keep the credits on the parts that are portable — compute, storage, data transfer — and keep them out of the architecture decision. A team that stays portable can move to the next programme when the first ends, and can say so in the renewal conversation. That sentence is worth more than the discount.

What does cloud-agnostic mean, and what does it not mean?

In plain terms, four choices:

• Containers and Kubernetes for anything long-running, rather than a vendor-specific runtime.
• Postgres, Redis and Kafka rather than vendor-only stores and queues — managed by the vendor is fine, the protocol is what keeps you free.
• Terraform or OpenTofu, one codebase, providers swapped at the edges rather than a console click nobody can reproduce.
• Object storage behind an S3-compatible API, which every serious provider now speaks.

What it does not mean: running on three clouds from day one, or refusing managed services on principle. Both are expensive ways to feel virtuous. Multi-cloud is an operations bill — two IAM models, two networks, two on-call runbooks — and most teams should not pay it. Agnostic is cheaper than multi-cloud because it is a property of the code, not the deployment.

The benefits a CTO can put in a board pack: a negotiating position when a contract renews, placement of workloads where they are cheapest, a residency answer that does not depend on one vendor's region map — the reason RBI data localisation is an architecture question and not a procurement one — and a shorter list of red flags in technical due diligence. Buyers price lock-in. They have seen the year-three bill before.

What would you change on Monday?

Start with measurement, not migration. Find out what you are actually paying for movement and for the managed premium:

aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --query 'ResultsByTime[0].Groups[?contains(Keys[0], `DataTransfer`) || contains(Keys[0], `NatGateway`)]'

That one command tells you whether the plumbing is a rounding error or a second engineer's salary. Then, in order: list every vendor-only service you depend on and what leaving it would cost in engineering weeks; put new work on the portable options by default; get the application into containers; move the infrastructure into Terraform so the answer to "could we stand this up elsewhere" is a file, not a memory. Migrate only what pays for itself — a batch tier, a log archive, a dev environment. Nobody gets points for moving a working production database.

If you are on credits today, put an expiry date in the calendar now, with the list-price bill next to it. The teams that get hurt are the ones for whom that date is a surprise. Choosing who runs this — in-house or a partner — has its own set of questions about what you keep.

The short version

Cloud cost optimization is not only rightsizing; it is keeping the ability to say no. Measure egress and NAT processing this week, because that is where the bill grows quietly. Take every credit programme going, and keep the credits off the parts of the stack that decide your architecture. Put the infrastructure in code and the application in containers, so that moving is a decision rather than a project. Then use the position it buys you: the discount you negotiate with a credible alternative is larger than the one you negotiate without.

Prices in this post were taken from the vendors' own pages in September 2026 and change often. Check the current rate for your region before you put any of these numbers in a model.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.