On this page · 13 sections
- Why the rupee makes cloud cost different in India
- 1. Reclaim the 18% GST you are already paying
- 2. Hedge the dollar with commitments
- 3. Choose the right Indian region
- 4. Kill idle resources and rightsize
- 5. Cut egress and inter-region transfer
- 6. Build INR-aware FinOps discipline
- The two Indian AWS regions
- The rupee-cost factors at a glance
- What it means for Indian teams in practice
- FAQ
- How eCorpIT can help
- References
Summary. For an Indian company, the AWS bill has a problem most cost guides ignore: it is effectively dollar-linked while your revenue is in rupees, so the bill rises when the rupee weakens, on top of whatever you actually used. India's public cloud spending is set to reach $17.5 billion in 2026, up about 28% from $13.7 billion in 2025, and Indian teams that do not optimise commonly waste 20% to 40% of it. The useful news is that several of the biggest savings are India-specific. If you are GST-registered, the 18% GST that AWS India charges is input tax credit you can reclaim, which is close to a free reduction many teams miss. Commitments such as Reserved Instances and Savings Plans cut the steady-state price by up to 72% and, just as usefully, lock part of your dollar exposure. And choosing the Mumbai or Hyderabad region keeps data in India for the DPDP Act while avoiding cross-region egress charges. This guide sets out six rupee-economics moves to cut your AWS bill. None of it is tax or financial advice; confirm the tax points with your accountant.
The general FinOps playbook still applies, and we cover it in our guides on cutting AI cloud bills and how Indian companies cut cloud costs. What follows is the part those guides do not: the moves that are specific to running cloud from India, where the currency, the tax, and the region all change the maths.
Why the rupee makes cloud cost different in India
A cloud bill in India carries a currency layer that a US company never sees. List prices are set in dollars, and even when AWS India invoices you in rupees, the amount is the dollar cost converted at the invoice-date rate, so a weaker rupee means a larger bill for the same usage. That makes cloud spend a mild, unhedged foreign-exchange exposure, which is one more reason to control it tightly rather than let it drift.
This is where FinOps earns its place. As J.R. Storment, executive director of the FinOps Foundation, puts it, "FinOps practices will be critical to enable c-level decisions about multi-year strategic technology investments across infrastructure types." For an Indian company, those decisions also have a currency dimension, and the six moves below address it directly.
1. Reclaim the 18% GST you are already paying
The most overlooked saving in India is not a discount, it is a tax credit. AWS India charges Goods and Services Tax on its cloud services, 18% in total, either as 9% CGST plus 9% SGST or as 18% IGST depending on your state. If your business is GST-registered, that 18% is input tax credit you can set off against your own GST liability, which means the real cost of your cloud is the bill minus the GST you reclaim.
To get it, register your GSTIN and your correct legal name and registered address on your AWS payer and linked accounts, so AWS India issues a proper tax invoice with your details. Without that, you pay the GST but cannot reclaim it, which is money left on the table every month. The mechanics are a matter for your accountant, but the principle is simple: a GST-registered business should never treat the 18% as a cost.
2. Hedge the dollar with commitments
Commitments are the largest discount lever anywhere, and in India they do a second job. Reserved Instances and Savings Plans cut the price of steady-state compute by up to 72% in exchange for a one or three-year commitment, and because they fix a large part of your bill in advance, they also reduce how much of your spend floats with the dollar. A committed baseline is both cheaper and more predictable in rupee terms.
The discipline is the same as anywhere: commit only to your stable baseline, the workloads you know you will run, and leave the variable layer on demand or spot, so you are not locked into capacity you stop using. The median enterprise covers only 55% to 65% of compute with commitments while the best-run teams reach 70% to 80%, so for most Indian teams the fastest large saving is simply lifting that coverage against a baseline they can already see.
3. Choose the right Indian region
Where you run matters for cost, latency, and law. AWS has two Indian regions: Mumbai, ap-south-1, open since June 2016 with three availability zones, and Hyderabad, ap-south-2, which opened in November 2022 as AWS's 30th region. Both keep your data inside India, which matters for the Digital Personal Data Protection Act and for RBI and SEBI-regulated workloads, and both deliver sub-10-millisecond latency to most Indian users.
Running in an Indian region for Indian users avoids two costs at once. It removes the cross-region data-transfer charges you pay when compute and data sit in different regions, and it removes the latency penalty of serving Indian users from the United States. Mumbai carries roughly a 10% to 25% premium over a US region such as N. Virginia for equivalent instances, but for an India-facing product the residency, latency, and avoided egress usually outweigh that premium. Mumbai has the widest service availability; Hyderabad is the natural in-country disaster-recovery pair.
4. Kill idle resources and rightsize
The cheapest rupee is the one you do not spend. Idle compute is the single largest source of cloud waste, and over-provisioned instances add more, so switching off what is not used and matching instance sizes to real workloads is the quick win every Indian team should do first. Scheduling non-production environments to stop nights and weekends commonly returns 15% to 20% within the first month, with no commitment and no architecture change.
In rupee terms the point is sharper: an idle instance is a dollar charge converted to rupees for nothing in return, every hour. A weekly look at utilisation, and a policy that development and staging environments shut down outside working hours, removes that waste before any of the slower, larger moves even begin.
5. Cut egress and inter-region transfer
Data transfer is the trap that surprises Indian teams at scale, because it is billed in dollars and is easy to ignore until the bill arrives. Moving data out of AWS to the internet, or between regions and availability zones, all carries charges, and an application that was architected without thinking about data flow can run up a transfer bill larger than its compute.
The fixes are structural. Keep compute and the data it uses in the same Indian region so there is no inter-region transfer. Use a content delivery network for anything served repeatedly to users, so it is cached at the edge rather than fetched from origin each time. And for AI workloads moving large training or document sets, treat egress as a line item to design around, not an afterthought. For an India-facing product, staying inside ap-south-1 or ap-south-2 solves most of it.
6. Build INR-aware FinOps discipline
The first five moves are tactics; the sixth keeps them working. A FinOps practice means tagging every resource so cost maps to a team or product, tracking budgets in rupees so finance and engineering read the same number, automated anomaly detection so a spike raises an alert the same day, and a regular review where the two sides look at the figures together. For an Indian company, that dashboard should also surface the GST reclaimed and the share of spend covered by commitments, because those are the two India-specific levers most easily forgotten.
The payoff is documented: teams that run lifecycle and cost management well typically save 25% to 30% of monthly cloud spend, while those that skip it after migration leave 20% to 40% unnecessary. With the rupee adding currency risk on top of the raw waste, that discipline is worth more in India than the percentage alone suggests.
| Move | What it cuts | The India angle |
|---|---|---|
| 1. Reclaim GST input credit | The effective bill, by up to 18% | India-only, for GST-registered firms |
| 2. Commit to discounts | Steady-state price and dollar risk | Hedges USD exposure in rupees |
| 3. Choose an Indian region | Egress and latency cost | Data residency for the DPDP Act |
| 4. Kill idle and rightsize | Idle and oversized machines | 15-20% in the first month |
| 5. Cut egress | Dollar-billed data transfer | Stay inside ap-south-1 or ap-south-2 |
| 6. INR-aware FinOps | Untracked, unowned spend | Track GST and commitments in rupees |
The two Indian AWS regions
For an India-facing workload, the region decision is usually between these two, and often both for resilience.
| Region detail | Mumbai (ap-south-1) | Hyderabad (ap-south-2) |
|---|---|---|
| Region code | ap-south-1 | ap-south-2 |
| Opened | June 2016 | November 2022 |
| Data residency | Inside India | Inside India |
| Service availability | Widest in India | Growing, slightly behind Mumbai |
| Best role | Primary for most workloads | In-country disaster recovery |
The rupee-cost factors at a glance
These are the levers that are specific to, or sharper in, the Indian context.
| Factor | Why it matters in India | Action |
|---|---|---|
| 18% GST | Reclaimable input tax credit if registered | Register GSTIN with AWS India |
| USD-to-INR | The bill floats with the rupee | Hedge the baseline with commitments |
| Mumbai premium | About 10-25% over a US region | Justified by residency and egress savings |
| Egress | Dollar-billed and easy to miss | Keep data and compute in one region |
| Idle spend | Largest single source of waste | Schedule and rightsize first |
What it means for Indian teams in practice
The sequence that works for most Indian companies is to start with the moves that need no commitment and pay back fastest, then build. Confirm your GST registration is set up with AWS India so you are reclaiming the 18% from day one, then switch off idle resources and schedule non-production environments for an immediate 15% to 20%. With a month of clean usage data, buy commitments against your steady baseline to cut the price and the currency risk together, and make sure your India-facing workloads sit in ap-south-1 or ap-south-2 so you are not paying egress or breaching data-residency expectations. Then stand up the FinOps dashboard that tracks all of it in rupees.
For a young company watching every rupee, the appeal is that most of this costs nothing to start. The GST credit is a registration step, idle cleanup is a policy, and the region choice is a deployment decision. The larger moves, commitments and a full FinOps practice, come once the spend justifies them. The mistake to avoid is the common one: migrating to the cloud and then never doing the financial-optimisation phase, which is exactly where that 20% to 40% of waste lives.
FAQ
How eCorpIT can help
eCorpIT is a CMMI Level 5 technology organisation in Gurugram whose senior engineering teams run FinOps for Indian companies on AWS and other clouds. We set up GST-correct billing, lift commitment coverage against your real baseline to cut cost and currency risk, place workloads in the right Indian region for residency and latency, and build the rupee-aware dashboards and anomaly detection that keep spend predictable. You can read more about eCorpIT and its director Manu Shukla. To scope a cloud cost review, contact our team.
References
_Last updated: 21 June 2026._
