AWS Reserved Instance in the Wrong Region: Your Options
If you bought an Amazon EC2 Reserved Instance in the wrong AWS Region, you cannot transfer that RI to another Region. Your realistic recovery paths are to contact AWS Account and Billing Support if the purchase was accidental, find matching EC2 usage in the purchased Region, let qualifying usage in another account consume the billing benefit through AWS Organizations, modify supported RI attributes inside the same Region, exchange a Convertible RI for a more useful configuration inside that Region, or sell an eligible Standard RI on the EC2 Reserved Instance Marketplace. The counterintuitive part is that Convertible does not mean globally movable: even a Convertible RI keeps the same Region for its entire term. Check the reservation's Region, scope and offering class before you pick one.
The first thing to understand is that an EC2 Reserved Instance is not a special virtual machine that sits in a rack waiting for you. It is primarily a billing discount applied automatically to matching On-Demand EC2 usage. That distinction explains why terminating an instance does not cancel the commitment and why moving an application to another Region does not drag the RI discount along with it.
The second thing is to identify exactly what you bought before trying to repair it. Standard versus Convertible, regional versus zonal, instance family, size, operating system or platform, tenancy, payment option, quantity, start date, end date, and purchasing account can all change which recovery paths are available.
First Confirm What Went Wrong
"Reserved Instance bought in the wrong Region" sounds like one problem, but several situations look similar in the console. You do not want to use a drastic solution for a smaller mismatch.
- Confirm the Region containing the RI. In the Amazon EC2 console, switch Regions and open Reserved Instances. Do not rely on the Region where the EC2 server is running.
- Confirm Standard or Convertible. This determines whether exchange or Marketplace resale can even enter the conversation.
- Check regional or zonal scope. A zonal problem inside one Region may be fixable even when a true cross-Region problem is not.
- Check the RI state. An active commitment is different from a failed or queued purchase.
- Check the platform and tenancy. A Region can be correct while the discount still misses your workload because another required attribute does not match.
- Look across your organization. The purchasing account may show no useful workload while another account has matching EC2 usage.
For CLI users, start with an inventory rather than a modification command:
aws ec2 describe-reserved-instances \
--region us-east-1
Replace us-east-1 with the Region you believe contains the reservation. Useful fields include ReservedInstancesId, State, OfferingClass, OfferingType, InstanceType, ProductDescription, InstanceTenancy, AvailabilityZone, Scope, Start, and End.
If you do not know which Region contains the RI, repeat the read-only command for your commonly used Regions. That is tedious, but it is safer than running a modification command against the wrong assumption.
🙋♂️ Jake's Reality Check
"I can see a Region selector at the top of the EC2 console. If I switch from Mumbai to N. Virginia before editing the RI, doesn't that move it?"
No. The console's Region selector changes which regional EC2 resources you are viewing. It does not rewrite the Region attached to an existing RI.
Why the RI Region Cannot Be Changed
An EC2 Reserved Instance is associated with a specific AWS Region. That Region is part of the reservation for the duration of its term.
This matters because AWS applies the RI billing discount only to eligible EC2 usage that matches the reservation rules. If the reservation belongs to us-east-1, a server in ap-south-1 does not become eligible simply because it has the same instance type.
People often confuse three different ideas:
- changing the Region viewed in the console;
- changing an RI's Availability Zone or scope inside its Region;
- changing the RI's Region itself.
The first is navigation. The second can be a supported RI modification. The third is not supported.
| Situation | Possible? | What it really means |
|---|---|---|
| View another Region in the console | Yes | Changes the resources displayed, not the RI's Region |
| Change supported Availability Zone attributes | Sometimes | Same Region only |
| Change supported RI scope | Sometimes | Regional versus zonal behavior inside the same Region |
| Exchange a Convertible RI | Yes, subject to exchange rules | Replacement remains in the same Region |
| Transfer RI to a different Region | No | No modification or exchange provides a cross-Region transfer |
Ethan explains it to Jake with a lease analogy: "The Region is the city written into the commitment. Modification can sometimes change the apartment details. It doesn't rewrite the city."
That one distinction eliminates a lot of bad troubleshooting. You are not looking for a hidden "destination Region" setting. You are deciding how to recover value from a commitment that stays where it was bought.
Can You Cancel or Refund a Reserved Instance Bought by Mistake?
A completed EC2 Reserved Instance purchase is normally non-refundable and cannot simply be canceled after purchase.
That sounds final, but it does not mean you should stay silent when the purchase was genuinely accidental. Open an Account and Billing support case promptly and explain the specific mistake.
The useful wording is not:
Please move this RI from Mumbai to N. Virginia.
That asks for an unsupported cross-Region RI operation.
A better explanation is:
I accidentally purchased this EC2 Reserved Instance in ap-south-1, but the intended workload and planned commitment are in us-east-1. I understand that the RI Region cannot be changed and that RI purchases are normally non-refundable. Can you review whether any billing resolution is available for this accidental purchase?
Include:
- the Reserved Instance ID;
- the account ID that purchased it;
- purchase Region;
- intended Region;
- approximate purchase time and date;
- Standard or Convertible;
- instance type;
- platform;
- tenancy;
- payment option;
- quantity;
- and whether matching usage has consumed any of the billing benefit.
Billing support cases are available even when you do not have a paid technical support plan. This is a billing issue, not a request for architectural debugging.
⚠️ Do not plan around a guaranteed refund
The purchase commitment remains the baseline. Open the case because an accidental transaction deserves review, but do not buy another long-term commitment on the assumption that the first one will definitely be reversed.
There is also old advice online telling people to leave an RI payment unpaid so that the reservation will somehow disappear later. Do not build a recovery plan around that. First inspect the reservation's actual state and your AWS payment status. An active purchased RI is a commitment; deliberately ignoring a payment problem is not a supported way to move it to another Region.
Options for a Standard RI Bought in the Wrong Region
Standard Reserved Instances provide less configuration flexibility than Convertible RIs, but an eligible Standard RI has a recovery route Convertible does not: resale on the EC2 Reserved Instance Marketplace.
Before jumping to resale, use the cheapest recovery order first.
- Open the billing case if the purchase was accidental.
- Check whether the RI is already being consumed. Cost Explorer or RI utilization data can stop you from selling something that is quietly saving money elsewhere.
- Search the purchased Region for matching usage. The workload does not have to be the application you originally intended to reserve.
- Check AWS Organizations sharing. Another account may have qualifying usage.
- Check whether a supported same-Region modification fixes the mismatch.
- Only then evaluate Marketplace resale.
This order matters because Marketplace resale is not instant, not universally available, and not free.
Suppose Jake runs his customer-booking application in N. Virginia but accidentally buys a Standard RI in Mumbai. His instinct is to sell immediately.
Ethan asks one question first: "Does your company run anything useful in Mumbai already?"
If a matching internal workload already runs there, the reservation might not be economically wasted. The buying mistake still happened, but the organization may be able to redirect the discount to useful consumption without changing the application's Region.
If nothing matches, then modification or resale becomes more important.
Selling the Wrong Standard RI on the Reserved Instance Marketplace
The EC2 Reserved Instance Marketplace exists specifically for Standard RIs that customers no longer need. Moving workloads to a new Region is one of the situations where resale can become useful.
But "Standard RI" does not automatically mean "sellable today."
Current restrictions include:
- Only Amazon EC2 Standard regional and zonal RIs can be sold.
- Convertible EC2 RIs cannot be sold there.
- RIs for services such as RDS or ElastiCache cannot be sold through the EC2 RI Marketplace.
- At least one month must remain in the RI term.
- You cannot sell a Standard RI in a Region that is disabled by default.
- No Upfront, Partial Upfront, and All Upfront Standard RIs can be eligible, but the RI must have been active in the account for at least 30 days.
- If the RI includes an upfront payment, AWS must have received it before the RI can be sold.
- An RI purchased using a volume discount cannot be sold.
- A listing cannot be edited directly. To change its parameters, cancel the listing and create another one.
- The EC2 RI Marketplace charges a service fee equal to 12 percent of the total upfront price charged by the seller.
- Seller registration requires the qualifying seller setup used by the RI Marketplace.
- AWS India customers cannot register as EC2 RI Marketplace sellers.
That final restriction deserves its own section because it changes the answer completely for some accounts.
Worked example: the 12 percent Marketplace seller fee
Suppose you decide to list an eligible Standard RI with an illustrative upfront seller price of $900. This is an example chosen to show the arithmetic, not an AWS price quote for a particular instance.
The Marketplace service fee would be:
$900 x 12% = $108
That leaves:
$900 - $108 = $792
If the RI sells at that illustrative upfront price, the service fee alone reduces the $900 amount by $108.
Do not compare $900 with the original RI purchase price and assume the difference is your total loss. Your actual economics depend on how much of the commitment has already been used, any hourly component still attached to the reservation, remaining term, the price a buyer accepts, applicable taxes, and the alternative value of keeping the RI.
The marketplace also does not promise a buyer. Listing an RI makes it available for sale; it does not immediately transfer the commitment away from you.
🙋♂️ Jake's Reality Check
"If I list the RI for sale today, can I stop treating it as my commitment today?"
No. A listing is an offer. Until ownership actually transfers through a sale, the RI remains yours.
Marketplace Console and CLI Route
For the console route, open Amazon EC2 in the RI's Region and choose Reserved Instances. Select the Standard RI. If the RI and account meet the requirements and seller registration is complete, use the action for selling Reserved Instances.
If this is your first sale, seller registration is part of the process. Do not treat the existence of the "sell" documentation as proof that your account is already eligible.
For the CLI, inventory the RI first:
aws ec2 describe-reserved-instances \
--reserved-instances-ids ri-0123456789abcdef0 \
--region us-east-1
Once seller registration and eligibility are in place, the listing API is exposed through create-reserved-instances-listing. A schematic example looks like this:
aws ec2 create-reserved-instances-listing \
--reserved-instances-id ri-0123456789abcdef0 \
--instance-count 1 \
--price-schedules Term=31536000,Price=900,CurrencyCode=USD \
--client-token wrong-region-ri-listing \
--region us-east-1
The ID, term, price, quantity, and Region above are example inputs. Do not paste them unchanged into a production account.
View listings with:
aws ec2 describe-reserved-instances-listings \
--region us-east-1
The listing lifecycle matters when troubleshooting. A listing can be active, partially fulfilled, fulfilled, canceled, or otherwise reflect the current sale process. If only part of a multi-instance listing sells, do not assume the entire original quantity has disappeared from your account.
If the price is wrong, you cannot edit the existing listing directly. Cancel it when cancellation is allowed and create a replacement listing with the new parameters.
⚠️ Check the workload before a sale completes
When you no longer own the RI, your account no longer receives that reservation's billing benefit. If EC2 usage had started matching it while the listing was waiting for a buyer, that usage may return to another applicable rate after the RI is sold.
AWS India Accounts Have a Major Marketplace Limitation
If your account is an Amazon Web Services India Private Limited customer, you cannot register as a seller on the EC2 Reserved Instance Marketplace and cannot list or sell EC2 Reserved Instances there, even if you have a US bank account.
That makes generic advice such as "sell the wrong Standard RI" incomplete.
If the wrong-Region purchase belongs to an AWS India account, use this recovery order:
- Open the Account and Billing support case promptly.
- Check whether matching usage already exists in the purchased Region.
- Check organization-wide RI benefit sharing.
- Check whether a supported same-Region modification makes the RI useful.
- If it is Convertible, check whether a same-Region exchange makes it useful.
- Check whether a legitimate workload can be moved or created in that Region for architectural reasons that already make sense.
- If none of those work, account for the remaining RI commitment and prevent a repeat purchase.
Do not confuse the EC2 Reserved Instance Marketplace with the broader AWS Marketplace seller program. The EC2 RI Marketplace has its own seller restrictions. An India-based organization being able to sell some AWS Marketplace products does not automatically mean its AWS India account can resell EC2 RIs.
If your seller-of-record relationship later changes away from AWS India, treat seller eligibility as something to re-evaluate at that time rather than assuming an old account state still applies.
What If the Wrong-Region RI Is Convertible?
This is where the word "Convertible" tricks people.
A Convertible RI can be exchanged for another Convertible RI with different supported configuration attributes. That can include instance family, operating system, and tenancy.
But the Region is fixed.
You cannot take a Convertible RI in ap-south-1 and exchange it for another Convertible RI in us-east-1.
You also cannot sell a Convertible RI on the EC2 Reserved Instance Marketplace.
That means a Convertible RI purchased in the wrong Region has a narrower set of recovery paths:
- billing support for the accidental purchase;
- matching EC2 usage in that Region;
- organization-wide eligible usage;
- supported RI modification;
- Convertible exchange into a more useful configuration in the same Region;
- or carrying the commitment until expiration.
The exchange rules also matter. The existing Convertible RI must be active, it cannot be waiting on a previous exchange request, and it must have enough remaining term to satisfy the exchange requirements. The replacement must be a currently offered Convertible RI, and the economics of the exchange must meet the equal-or-higher-value rule.
If the replacement configuration costs more than the value being exchanged, the exchange can require a true-up payment. That is the extra amount needed to reach the new configuration's value.
If you only want to exchange part of a Convertible reservation, a useful pattern is to split the original reservation through modification and exchange only the portion you need.
Convertible RI console route
- Open Amazon EC2 in the RI's Region.
- Choose Reserved Instances.
- Select the Convertible RI.
- Choose Actions → Exchange Reserved Instance.
- Select the target configuration.
- Choose Find offering.
- Review the number of replacement RIs and any additional cost.
- Review again before choosing Exchange.
Convertible RI CLI route
First find offerings:
aws ec2 describe-reserved-instances-offerings \
--offering-class convertible \
--region us-east-1
Then obtain an exchange quote with get-reserved-instances-exchange-quote. Review the quantity of replacement reservations and the true-up cost. Only then use accept-reserved-instances-exchange-quote.
Do not change --region to the Region you wish you had bought in and expect that to transform the RI. The command is operating against the EC2 regional endpoint that already owns the reservation.
✅ Why an exchange can still rescue value
The wrong Region cannot be fixed, but the wrong instance family or platform inside that Region sometimes can. If another legitimate workload exists there, exchanging into a configuration that matches it can turn a completely unused commitment into a useful one.
Modification Helps With the Wrong AZ, Not the Wrong Region
Both Standard and Convertible RIs can support certain modifications.
Typical supported changes can include:
- Availability Zone;
- scope;
- instance size inside supported same-family rules;
- and splitting or combining portions of eligible reservations.
A simple example shows why this matters.
You purchased a zonal RI for us-east-1a. Your EC2 workload is actually in us-east-1b.
That is not a wrong-Region problem. Both Availability Zones belong to us-east-1. A supported modification may fix the mismatch.
Now change the example.
You purchased the RI in us-east-1. Your workload is in ap-south-1.
No RI modification moves that reservation between those Regions.
A CLI modification can look like:
aws ec2 modify-reserved-instances \
--reserved-instances-ids ri-0123456789abcdef0 \
--target-configurations AvailabilityZone=us-east-1b,InstanceCount=1 \
--region us-east-1
The important trap is the final --region us-east-1.
That flag does not mean "move this reservation into us-east-1." It tells the AWS CLI which regional EC2 API endpoint to send the request to.
If the RI already lives in us-east-1, that is where the modification request belongs.
You can inspect modification requests with:
aws ec2 describe-reserved-instances-modifications \
--region us-east-1
A modification also creates replacement reservation records rather than magically editing every field of the original object in place. If you split a reservation covering several instances, you can end up with multiple resulting reservations.
That is useful when only part of your commitment needs a different configuration.
Regional vs Zonal RI: The Scope Trap
A regional RI and a zonal RI can have the same Region while behaving differently.
A zonal RI is purchased for a specific Availability Zone. It provides the RI billing benefit for matching usage there and includes the capacity-reservation behavior associated with that zonal reservation.
A regional RI is purchased for the Region rather than one specific Availability Zone. It provides Availability Zone flexibility for qualifying usage but does not provide the zonal capacity reservation.
The scope does not change the Region.
| Feature | Regional RI | Zonal RI |
|---|---|---|
| Geographic scope | Region | Specific Availability Zone inside the Region |
| AZ flexibility | Yes for qualifying usage | No; matching usage is tied to the AZ |
| Capacity reservation | No | Yes for the reservation's matching capacity |
| Cross-Region benefit | No | No |
This is why "regional" is an unfortunate word for beginners. It means flexible within one selected Region, not usable across every AWS Region.
If your workload moves frequently among Availability Zones inside one Region and you do not need the zonal capacity reservation, regional scope may fit better.
If guaranteed reserved capacity in a particular Availability Zone matters, the zonal behavior can be important.
Neither choice solves Mumbai versus N. Virginia.
Can Another AWS Account Use the RI Discount?
Yes, in some AWS Organizations billing setups, another account's qualifying EC2 usage can receive an unused RI billing benefit.
For consolidated billing purposes, RI benefits can be shared across eligible accounts based on the organization's current RI and Savings Plans discount-sharing preferences.
That creates an important recovery path:
- Account A owns the wrong RI in
us-east-1. - Account A's intended application runs in
ap-south-1. - Account B in the same organization happens to run qualifying EC2 usage in
us-east-1. - The organization's sharing configuration allows Account B to receive the unused benefit.
Account B's usage can make the commitment economically useful even though Account A bought it for the wrong project.
The Region rule still applies. Organization sharing does not transform a us-east-1 RI into an ap-south-1 discount.
Current sharing modes
The management account can configure RI and Savings Plans discount sharing. Current billing preferences include three broad sharing models:
- Open sharing: discounts can be available across sharing-enabled accounts in the organization.
- Prioritized group sharing: benefits go to the purchasing account first, then designated groups, then other eligible sharing accounts.
- Restricted group sharing: benefits remain inside defined groups rather than flowing throughout the entire organization.
Group-based sharing uses Cost Categories to define the account groups.
The practical lesson is that "we use AWS Organizations" is not enough information. You need to inspect the actual discount-sharing configuration.
Console route
- Sign in to the management account.
- Open Billing and Cost Management.
- Choose Billing preferences.
- Find the Reserved Instances and Savings Plans discount sharing section.
- Inspect which accounts have sharing activated.
- Inspect whether sharing is open, prioritized by group, or restricted by group.
Changing these preferences can change the AWS bill, so this is not a setting to toggle casually just to make a dashboard look better.
⚠️ Discount sharing is not capacity sharing
A zonal RI's reserved capacity belongs to the owning account. Sharing the financial RI benefit across accounts should not be confused with sharing that zonal reserved EC2 capacity.
Why the RI May Still Look Unused After You Find Workload in the Same Region
Finding an EC2 instance in the correct Region is necessary, but it may not be sufficient.
The reservation still needs to match the usage rules that apply to its scope and attributes.
For a zonal RI, matching is stricter. The running instance must match the relevant tenancy, platform, Availability Zone, instance family, and instance size.
For a regional RI, Availability Zone flexibility is built into the regional scope. Eligible Linux/UNIX regional reservations with default tenancy can also receive instance-size flexibility inside supported families.
That is why this can happen:
Jake finds an EC2 instance in the same Region as his mistaken RI. He expects the utilization graph to jump immediately. It does not.
Ethan asks:
"Same Region, yes. Same platform? Same tenancy? Correct family rules? Is the RI regional or zonal?"
The Region was only the first mismatch.
Use describe-reserved-instances for the commitment and describe-instances for the running workload, then compare the relevant attributes.
aws ec2 describe-reserved-instances \
--reserved-instances-ids ri-0123456789abcdef0 \
--region us-east-1
aws ec2 describe-instances \
--instance-ids i-0123456789abcdef0 \
--region us-east-1
The RI benefit is applied automatically when qualifying On-Demand usage matches. You do not manually attach an RI ID to an EC2 instance.
That is another common misunderstanding. There is no "bind reservation to this server" button you should be hunting for after the purchase.
What the Wrong RI Does to Your Bill
The financial damage is not that AWS launches a mysterious extra EC2 server. The problem is that you have made a commitment whose discount may not be landing on useful compute.
If your intended workload remains in the correct application Region while the RI sits unused somewhere else, you can end up with two simultaneous costs:
- the RI commitment in Region A;
- and EC2 usage in Region B that is not covered by that RI.
Stopping the Region B server would reduce its compute usage cost, but it does not erase the RI commitment in Region A.
Terminating an instance in Region A also does not "terminate the Reserved Instance." Remember: the RI is a billing construct rather than the virtual machine itself.
Cost Explorer's RI utilization and coverage views are useful here.
Utilization helps answer: how much of the RI benefit is actually being consumed?
Coverage helps answer: how much eligible usage is receiving reservation benefits?
Those are related questions, but they are not the same.
If utilization is poor, investigate unused commitment.
If coverage is poor, investigate eligible workload that is still billed without enough reservation benefit.
A wrong-Region purchase can produce both at once: low utilization on the mistaken RI and low coverage on the workload in the Region where you really wanted the commitment.
Should You Move the Workload to the RI's Region?
This sounds like an obvious way to "use the reservation," but it can turn a purchasing mistake into an architecture mistake.
Region choice can affect:
- customer latency;
- data residency;
- database placement;
- disaster-recovery design;
- dependent service availability;
- cross-Region data movement;
- network architecture;
- and operational processes.
Do not move a production workload to a less appropriate Region only so an RI utilization graph turns green.
🙋♂️ Jake's Reality Check
"But I've already paid for the reservation. Isn't not using it wasting money?"
The commitment is already the problem. Ethan says: "Don't spend another dollar or weaken the architecture just to make a past purchase feel justified."
The better question is:
Do we already have a legitimate workload that belongs in this Region and could consume the RI?
A development environment, internal service, batch job, reporting worker, staging system, or another approved workload might fit.
If yes, repurposing can be sensible.
If no, creating unnecessary infrastructure solely to consume the RI can increase the total bill rather than reduce the damage.
Standard vs Convertible Recovery Options
| Recovery option | Standard RI | Convertible RI |
|---|---|---|
| Cancel purchase normally | No | No |
| Ask Billing Support about accidental purchase | Yes | Yes |
| Modify supported same-Region attributes | Yes, subject to rules | Yes, subject to rules |
| Exchange to another RI configuration | No | Yes, same Region only |
| Sell on EC2 RI Marketplace | Potentially, if eligible | No |
| Use matching workload elsewhere in organization | Potentially | Potentially |
| Transfer to another Region | No | No |
The table explains why neither class is universally "safer."
Standard has the resale path but not Convertible exchange.
Convertible has exchange flexibility but no RI Marketplace resale.
Both keep the Region fixed.
That Region rule is what makes checking the purchase screen before confirmation so important.
Do Not Immediately Buy Another RI in the Correct Region
The most expensive reaction to one mistaken RI can be a second mistaken commitment.
Before purchasing a replacement, confirm:
- the workload's actual Region;
- the expected duration of that workload;
- the instance family and size;
- platform;
- tenancy;
- whether a regional or zonal RI is appropriate;
- whether the application needs reserved capacity or only a billing discount;
- how much eligible EC2 usage already has another RI or Savings Plans benefit;
- organization-wide commitment sharing;
- and whether the workload is stable enough for another term commitment.
If your real requirement is flexible compute spending rather than a particular RI configuration, compare Savings Plans before buying another RI.
That does not mean "Savings Plans are always better." They solve a different commitment problem.
A zonal RI can provide reserved capacity in a particular Availability Zone. If capacity assurance is the actual requirement, that matters.
The point is to choose deliberately rather than buying the same product again because you are trying to repair the first transaction quickly.
Decision Path: What Should You Do With the Wrong-Region RI?
Step 1: Is this actually a different AWS Region?
If the mismatch is only us-east-1a versus us-east-1b, investigate modification first.
If it is us-east-1 versus ap-south-1, continue.
Step 2: Was the purchase accidental?
If yes, open the Account and Billing support case now rather than after weeks of experimentation.
Step 3: Is the RI already providing savings somewhere?
Check RI utilization, matching EC2 usage, and organization-wide sharing before calling it unused.
Step 4: Standard or Convertible?
Standard opens the Marketplace question. Convertible opens the exchange question.
Step 5: Can same-Region modification repair the mismatch?
If the real mismatch is Availability Zone, scope, or an eligible size configuration, modification may solve it.
Step 6: Can another legitimate workload use it?
Look beyond the original project, including other organization accounts.
Step 7: Standard RI only — can you sell it?
Check the 30-day active requirement, one-month remaining term, volume-discount restriction, Region eligibility, payment state, seller registration, and AWS India restriction.
Step 8: Convertible RI only — can you exchange it into something useful?
The new RI remains in the same Region, but changing family, platform, or tenancy may rescue value.
Step 9: Is a replacement commitment still necessary?
Only after the first RI is understood should you decide whether to purchase another RI or a different commitment model.
What to Gather Before Opening the Billing Case
A support engineer should not have to ask three rounds of questions before understanding what happened.
Gather this first:
- Reserved Instance ID;
- AWS account ID;
- Region purchased;
- Region intended;
- purchase date;
- approximate purchase time;
- Standard or Convertible;
- regional or zonal;
- instance type;
- platform;
- tenancy;
- term;
- payment option;
- quantity;
- current RI state;
- whether any of its benefit has been consumed;
- and whether a replacement commitment has already been purchased.
That last point matters. If you immediately purchased another RI in the correct Region, tell Support. Do not make them discover it later in the account history.
If the wrong purchase is a large financial commitment, also preserve the internal approval trail: who intended which Region, which workload was supposed to be covered, and where the mismatch happened.
This is useful even if Support cannot reverse anything. You need it for the prevention step afterward.
When Nothing Works: The Honest End of the Decision Tree
There are real cases where no clean exit exists.
You may have:
- an active Convertible RI in the wrong Region;
- no useful workload there;
- no eligible organization usage;
- no helpful same-Region exchange;
- no cancellation;
- and no Marketplace resale because Convertible RIs are not sellable.
Or you may have an eligible-looking Standard RI but the account is under AWS India, which removes the seller path.
At that point, stop searching for secret Region-transfer syntax.
There is no supported CLI parameter, hidden console page, or Convertible exchange trick that moves an existing EC2 RI between Regions.
Shift from "undo the purchase" to "minimize the remaining damage."
- Document the remaining term.
- Document the remaining payment obligation.
- Track RI utilization.
- Periodically re-check whether legitimate matching usage has appeared in the Region.
- Check organization-wide matching usage when accounts or sharing groups change.
- Do not queue another automatic purchase based on the mistaken configuration.
- Restrict future RI purchase permissions.
- Add a second-person Region check before future commitments.
Most importantly, do not launch unnecessary EC2 instances just to make the RI show 100 percent utilization.
If the instance itself has no business purpose, you are adding cost to hide an existing cost problem.
Preventing the Next Wrong-Region Purchase
The easiest wrong RI to recover is the one nobody is allowed to buy without a review.
EC2 RI purchasing uses the ec2:PurchaseReservedInstancesOffering permission. A developer may need to create, start, stop, resize, or terminate EC2 instances without needing authority to enter the company into a one-year or three-year commitment.
Separate those responsibilities where practical.
A useful purchase checklist is:
- Copy the Region directly from the production workload inventory.
- Confirm the exact account that should own the RI.
- Confirm the instance family and size.
- Confirm platform.
- Confirm tenancy.
- Confirm Standard versus Convertible.
- Confirm regional versus zonal.
- Confirm quantity.
- Confirm term.
- Confirm payment option.
- Review current RI and Savings Plans inventory.
- Review organization-wide discount sharing.
- Have a second person compare the purchase summary with the intended workload.
For larger environments, centralizing RI and Savings Plans purchases with a FinOps, cloud platform, or infrastructure team can prevent teams from independently buying overlapping commitments.
Jake laughs at the idea of needing two people to buy a discount.
Ethan answers: "You don't need two people to buy lunch. You might want two people to review a multi-year cloud commitment."
That is the right level of seriousness. An RI purchase deserves more review than starting an On-Demand EC2 instance because the financial behavior is fundamentally different.
AWS Reserved Instance Bought in Wrong Region FAQ
1. Can I change the Region of an AWS EC2 Reserved Instance?
No. An EC2 Reserved Instance is associated with a specific AWS Region for its term. You can modify some RI attributes inside that Region, but you cannot transfer the RI to a different Region.
2. Can AWS Support move a Reserved Instance to another Region?
There is no supported cross-Region RI transfer operation. If the purchase was accidental, open an Account and Billing support case and ask whether any billing resolution is available for the mistaken transaction rather than asking for a technical Region transfer.
3. Can I cancel an EC2 Reserved Instance after I buy it?
A completed EC2 Reserved Instance purchase normally cannot be canceled and is non-refundable. An accidental purchase is still worth reporting promptly through an Account and Billing case.
4. Can I sell a Reserved Instance that I bought in the wrong Region?
An eligible Standard EC2 Reserved Instance can be listed on the EC2 Reserved Instance Marketplace if the account and RI satisfy the seller requirements. Convertible Reserved Instances cannot be sold there.
5. How long must I own a Standard RI before I can sell it?
A Standard RI must generally have been active in your account for at least 30 days before it can be sold on the EC2 Reserved Instance Marketplace. At least one month must also remain in its term, and other restrictions still apply.
6. What fee does AWS charge when a Standard RI sells?
The EC2 Reserved Instance Marketplace service fee is 12 percent of the total upfront price charged by the seller for the Standard RI.
7. Can AWS India customers sell EC2 Reserved Instances?
No. Amazon Web Services India Private Limited customers cannot register as sellers on the EC2 Reserved Instance Marketplace and cannot list or sell EC2 RIs there, even with a US bank account.
8. Can I exchange a Convertible Reserved Instance into another Region?
No. Convertible RI exchanges can change supported configuration attributes, but the Region remains fixed. The replacement Convertible RI must remain in the same Region as the reservation being exchanged.
9. Can I sell a Convertible Reserved Instance?
No. The EC2 Reserved Instance Marketplace supports eligible Standard RIs. Convertible RIs cannot be listed for sale there.
10. Can I change a Reserved Instance from one Availability Zone to another?
A supported RI modification can change Availability Zone attributes inside the same AWS Region. That is different from transferring an RI between Regions.
11. What does regional Reserved Instance mean?
A regional RI is scoped to one AWS Region and can provide Availability Zone flexibility for qualifying usage inside that Region. "Regional" does not mean that the discount works across every AWS Region.
12. Can another AWS account use my Reserved Instance discount?
Qualifying EC2 usage in another account in the same AWS Organization can receive unused RI billing benefits when the organization's RI and Savings Plans discount-sharing settings allow it. The usage still has to satisfy the reservation's Region and matching requirements.
13. Does terminating my EC2 instance cancel the Reserved Instance?
No. An EC2 Reserved Instance is a billing commitment rather than the running EC2 virtual machine. Terminating an EC2 instance does not cancel the RI term.
14. Why is my Reserved Instance unused even though I have EC2 in the same Region?
The running usage may fail another matching requirement such as platform, tenancy, Availability Zone for a zonal RI, or instance-family and size rules. Compare the RI attributes with the running EC2 usage instead of checking Region alone.
15. Should I immediately buy another RI in the correct Region?
Not before checking the mistaken RI, Billing Support, organization-wide matching usage, modification or exchange options, and Marketplace eligibility. Buying a second commitment too quickly can leave you paying for two long-term commitments.
16. How do I stop someone from buying an RI in the wrong Region again?
Limit the ec2:PurchaseReservedInstancesOffering permission to approved purchasing roles, centralize commitment purchases where practical, and require a review of Region, account, instance attributes, quantity, term, and payment option before confirming a purchase.
The Bottom Line
An EC2 Reserved Instance bought in the wrong Region cannot be transferred into the Region where you intended to use it. That is the fixed boundary around every recovery option.
If the purchase was accidental, create an Account and Billing case promptly. Then identify whether the RI is Standard or Convertible. Check for matching usage in the purchased Region, including eligible usage across your AWS Organization. If the mismatch is inside one Region, investigate modification. If the RI is Convertible, investigate a same-Region exchange. If it is Standard, investigate EC2 RI Marketplace eligibility, remembering the holding-period, remaining-term, seller, fee, and AWS India restrictions.
If none of those routes works, do not compound the mistake by moving the wrong workload, launching unnecessary servers, or buying another commitment before reviewing the first one. Document the remaining cost, monitor for useful matching usage, tighten purchasing permissions, and make Region verification part of the next commitment review.
If you have just noticed the mistake, start with the RI ID, Region, class, scope, payment option, and purchase time. Those six facts will tell you much more than staring at the monthly bill and wondering why the discount did not follow the server.
📌 If you keep one line from this page
You can change several things about an EC2 Reserved Instance, but you cannot change the AWS Region it belongs to.
Recover the value where the RI already lives instead of searching for a cross-Region transfer that does not exist.
Revision note. Written October 3, 2026, with the 12 percent Marketplace fee in place. A wrong-Region reservation stings, but it is rarely a total loss; gather the details first, and the right option usually becomes plain.