Blog
AWSBedrockGenAILessons Learned

Claude on Bedrock Wouldn't Bill in India — So I Shipped on Nova

·Ankit Bhardwaj

Most build blockers are technical. This one was a payment method — and it taught me to design AI features so the model is the least load-bearing decision I make.

I was adding an "Ask AI" feature to qiyas.ae, my Dubai property-price tool: let people ask in plain English — "median price of a 1BR in Dubai Marina?" — and answer them from real Dubai Land Department sale records. I wanted Anthropic's Claude on Amazon Bedrock to do the language understanding. Bedrock was the obvious choice: managed, pay-per-token, no GPUs to babysit, and it sits right next to the rest of my AWS stack.

What actually happened

Everything was ready. The intent prompt was written, the IAM user was scoped down to a single bedrock:InvokeModel permission, the region had the model listed. Then I went to enable Claude — and hit a wall.

My AWS account is under AISPL — Amazon Internet Services Private Limited, the entity that resells AWS to customers in India. On Bedrock, third-party foundation models like Claude are gated behind an AWS Marketplace subscription. And that subscription wouldn't go through: an India-issued card under AISPL, with RBI's card rules in the middle, simply couldn't complete a Marketplace purchase. The model was listed in my region. I had permission to invoke it. I just couldn't do the one thing in between — pay for it.

I burned real time convincing myself it was something else. Was it a region-availability gap? A missing model-access request? An IAM policy typo? None of the above. The models I could see but not enable were all the third-party ones routed through Marketplace. The distinction that finally clicked: Amazon's own first-party models don't go through Marketplace at all.

The escape hatch: make the model swappable

Here's the decision that saved the day. Instead of calling a model-specific endpoint, I built the integration on Bedrock's Converse API — the unified, model-agnostic interface where the request and response shape are identical no matter which model answers. The model is just an ID string in the call.

That let me ship on Amazon Nova Lite — Amazon's own model, no Marketplace subscription, available in the Asia-Pacific region, and cheap. It went live the same afternoon. The feature works, users get grounded answers, and the whole thing costs a rounding error per query.

The quiet win is what didn't have to change. Because everything goes through Converse, moving to Claude later — once I sort out billing on a US-based AWS Inc. account, or the Marketplace path opens up — is a one-line change to the model ID. No rewrite of the prompt, the parsing, or the request signing. The blocker downgraded itself from "can't ship" to "ship on Nova now, upgrade the model later," and the code doesn't care which day that happens.

One more gotcha, for the next person

Calling Bedrock from PHP (my API runs on shared hosting, no AWS SDK) meant hand-signing requests with SigV4. If you ever do this: the Nova model IDs contain a colon (apac.amazon.nova-lite-v1:0). That colon has to be percent-encoded in the request path and then encoded again in the canonical URI that goes into the signature — a double-encode. Miss it and you get a signature-mismatch 403 that looks exactly like a credentials problem but isn't. That one cost me an hour.

The takeaway

Two things I'm keeping:

  • Billing and region eligibility are part of your architecture, not an afterthought. "Is the model available in my region?" is the wrong question. The right one is "can this specific account, with this specific payment method, actually transact for it?" On AISPL and other local AWS resellers, that answer can be different from what the console implies.
  • Abstract the vendor before you're forced to. The Converse API turned a hard blocker into a config value. The best time to make a dependency swappable is before it blocks you — because the day it does, you want the fix to be a string, not a sprint.

If you're building on Bedrock from India — or anywhere AWS is resold locally — check that you can complete a Marketplace subscription before you design around a specific third-party model. And either way: build so the model is the easiest thing to change, not the hardest.

AB

About the Author

Ankit Bhardwaj

Site Reliability Engineer with 12+ years in software engineering and 4+ years operating production cloud infrastructure on AWS and Kubernetes. Currently running six Kubernetes clusters at 99.99% uptime.

Get in touch