Avoiding billing challenges: Best practices for Savings Plans and RI management during Organizations consolidations

Introduction

When enterprises consolidate multiple AWS Organizations through acquisitions, mergers, or restructuring, the focus is often on technical dependencies, such as AWS Identity and Access Management (IAM), networking, AWS Control Tower, and resource sharing. One of the costliest financial oversights is the gap between when AWS accounts migrate and when RIs and Savings Plans follow.

Technical Account Managers (TAMs) that support AWS Enterprise customers through large-scale migrations frequently observe this billing gap.

This article outlines best practices to manage RI and Savings Plan commitments during organization consolidations. It highlights the RI and Savings Plan (RISP) Group Sharing feature as a post-consolidation alternative to transfers within a single organization. It also highlights billing challenges across enterprise migrations.

Customer scenario

A large Enterprise customer must consolidate two Organizations into a single unified organization. The consolidation migrates accounts in Organizations A across development, staging, and production environments, along with multiple RIs and Savings Plans, to Organizations B.

During the first phase of migration, the team moves 10 accounts from Organizations A to Organizations B. The account transfer includes invitation acceptance and organizational placement and completes in hours. However, the Savings Plans remain in Organizations A. The Finance team doesn't submit a Savings Plans transfer support case for 3 weeks because they don't know that plan transfers require a separate support case from the source account. The team also assumes that the Savings Plans automatically get transferred with the accounts.

As a result, Organizations A continues to pay Savings Plans commitments that cover zero workloads. Meanwhile, Organizations B runs the same workloads at on-demand rates with no plan coverage. The following formula equals the total cost exposure during a gap:

((Savings Plans hourly commitment x 24 x gap days) for the wasted commitment in Organizations A) + ((on-demand rate - Saving Plan-covered rate) x usage hours for the incremental cost in Organizations B) = Total cost exposure

For this customer, the 3-week gap produces a five-figure unrecoverable cost that they can prevent with proper transfer coordination.

Solution overview

The solution resolves the RI and Savings Plans billing gap through a two-phase approach. During migration, you coordinate Savings Plans transfers with explicit effective dates that you align to account migration dates to prevent the period of double payment. After you consolidate the Organizations, you implement RISP Group Sharing with Cost Categories. This controls how you allocate commitments across business units in your single organization and reduces the requirement for future transfer cases.

This article provides a phased timeline from discovery through post-migration. This article also includes best practices for Cost and Usage Report 2.0 (CUR 2.0) exports, cost allocation tags, tax settings, and RISP Group Sharing configuration.

The Problem: the migration gap

As mentioned in the customer scenario, the RI and Savings Plan commitments don't automatically transfer when their accounts migrate between Organizations.

Savings Plan and RI commitments scope to the Organizations where you purchased them, not to specific workloads or accounts. When you remove accounts from Organizations, the commitment remains and continues to incur charges against the source Organizations bill.

Migration Gap Timeline

Day 0	Weeks 1–3: GAP PERIOD	Week 3+
Accounts migrate from Organization A to Organization B	DOUBLE-PAYMENT GAP	Saving Plan transfer case raised and processed
Technical migration completes successfully	Organization A: Pays Saving Plan commitment — zero workloads (wasted spend). Organization B: Runs workloads at on-demand rates (no Saving Plan coverage).	Saving Plan coverage transfers to Organization B with explicit effective date
→	→	RESOLVED

What causes the migration gap

The following process gaps contribute to this problem:

• Savings Plans and RI transfers require a support case from the source account.

  The owner of the source account assumes that the destination account initiates the transfer. However, the Reserved Instance Purchase Operations (RPO) team requires the source or selling account to submit the case. This requirement can add days of delay.

• The effective date defaults to the case creation date. Unless explicitly requested, the Savings Plan transfer takes effect on the date that you create the case, not the date that the accounts migrated. If there's a gap between migration and case creation, you incur unrecoverable costs.

• You can't back date transfers after billing periods close. After the billing period closes, RPO can't retroactively apply Savings Plan coverage, and the cost gap becomes permanent.

Managing commitments across Organizations: modern approaches

AWS launched two capabilities in November 2025 that change how organizations can manage billing commitments. Depending on your consolidation goals, one or both capabilities potentially apply.

Option 1: AWS Billing Transfer avoids consolidation

Set up Billing Transfer so that a management account designates an external account to manage and pay for its consolidated bill. Billing Transfer allows you to centralize billing management across multiple Organizations without physically migrating accounts so that it isn’t necessary to transfer the Savings Plan.

When to use Billing Transfer instead of consolidation

• Your primary goal is financial visibility and centralized invoice management, not technical unification, such as a shared service control policy (SCP), centralized networking, and unified IAM roles.

• You must maintain separate organizational boundaries for compliance, security, or operational independence.

• You must avoid the complexity of RI and Saving Plan transfers, Cost and Reports migration, and cost allocation tag recreation.

Primary considerations

Billing Transfer integrates with AWS Billing Conductor for cost visibility controls. The following pricing plans are available:

• AWS managed

• Customer managed

The AWS managed plan is included at no additional charge. For the Customer managed pricing plan, AWS charges for each organization.

Within the AWS managed pricing plan, the Passthrough plan passes billable data directly without rate customization. If you require centralized billing without custom pricing, then the Passthrough plan is a good option. For more information, see AWS Billing Conductor Pricing.

Note: Before you transfer your accounts, you must export cost and usage data. After the transfer, historical cost and usage data is no longer available to the bill-source account, or the account whose charges transfer.

The account that assumes billing responsibility must be a management account of an organization. Your existing destination organization's management account qualifies as the bill-transfer account. The bill-source management account, not the bill-transfer account, controls the RI and Saving Plan discount sharing preferences.

If your primary goal for consolidation is technical unification, with shared networking, unified identity, and centralized governance, then implement the RISP Group Sharing option.

Option 2: RISP Group Sharing post-consolidation

In November 2025, AWS launched RISP Group Sharing, a feature that offers granular control over how you allocate commitments in your organization.

Important: RISP Group Sharing works in a single organization. It doesn’t share commitments across separate organizations. It helps you manage allocation after consolidation, but not during the migration gap between two organizations. During migration, Savings Plan transfers must still avoid cost gaps. However, after you consolidate accounts under one organization, Group Sharing removes the need for future transfers and provides continual control.

How it works

Prerequisite: The Cost Category for RISP Group Sharing uses only the Accounts dimension to define groups based on linked account membership. RISP Group Sharing doesn't support tags, services, or other types of dimensions. Each account can belong to only one sharing group. The management account can't belong to a sharing group. Groups must be mutually exclusive with no overlapping accounts. You create a dedicated Cost Category for Saving Plan and RI sharing rather than using an existing cost allocation category that doesn’t meet these requirements.

RISP Group Sharing uses Cost Categories to define account groups. By default, RI and Savings Plan discounts use open sharing, which applies discounts across all accounts in the organization.

RISP Group Sharing provides the following modes that give you granular control:

• For Prioritized group sharing, Savings Plan benefits apply to the purchasing account first, then to accounts in a defined group. Benefits then flow to the other sharing-activated accounts in the broader organization. Prioritized group sharing is good to use post-consolidation. Group migrated accounts together to make sure that they receive Savings Plan coverage before benefits flow to other parts of the organization.

• For Restricted group sharing, Savings Plan benefits stay exclusively in defined groups. There's no sharing outside the group. Restricted group sharing isolates finances between business units or subsidiaries.

Why RISP Group sharing is important for organization consolidations

After you consolidate organizations under a single organization, RISP Group Sharing offers the following savings:

• Removes the need for future Savings Plan transfer cases. You manage allocation through Cost Categories.

• Prevents Savings Plan leakage across business units. Your commitments stay where they're intended.

• Simplifies internal cost allocation, or chargeback. Each group's costs and commitments stay aligned.
  Note: Chargebacks aren’t refunds.

• Offers self-service. You configure RISP Group Sharing through the AWS Billing and Cost Management console, without the need to engage AWS Support.

Important: During the migration, you must still carefully plan Savings Plan transfers.

Best practices for organization consolidation billing

Based on observed patterns across enterprise migrations, the following are best practices for organization consolidation billing.

Plan your RI and Savings Plan strategy before you migrate accounts

Before you migrate an account, take the following actions:

• Note all RIs and Savings Plans across both organizations.

• Map the accounts that own commitments and the accounts that use benefits.

• On the RI and Savings Plan Summary tab, use the Cost and Usage Dashboard Operations Solution (CUDOS) Dashboard to visualize owner-consumer relationships.

• Decide whether to transfer Savings Plans or implement RISP Group Sharing.

AWS offers the following Saving Plan types with different transfer considerations:

• Compute Savings Plans are the most flexible, offer low prices, apply across Amazon Elastic Compute Cloud (Amazon EC2), AWS Fargate, and AWS Lambda regardless of AWS Region, instance family, or operating system (OS). This Savings Plan supports 1-year or 3-year terms and all payment options.

• EC2 Instance Savings Plans apply to a specific instance family and Region. This Savings Plan supports 1-year or 3-year terms and all payment options.

• Amazon SageMaker AI Savings Plans apply to SageMaker AI usage regardless of instance family or Region, supports a 1-year or 3-year term, and all payment options.

• Database Savings Plans apply to Amazon Aurora, Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB, Amazon ElastiCache (Valkey only), Amazon DocumentDB (with MongoDB compatibility), Amazon Neptune, Amazon Keyspaces (for Apache Cassandra), Amazon Timestream, AWS Database Migration Service (AWS DMS), and Amazon OpenSearch Service. This Savings Plan supports only 1-year terms and no upfront payment. You can't extend or restructure a Database Saving Plan during a consolidation.

Savings Plans that member accounts purchase move with the account when the account transfers to a new organization. Only Savings Plans that the management account owns require an explicit transfer case through RPO. If you purchased a Savings Plan in a member account, then contact AWS Support to determine whether your Savings Plan transfers with the account. It’s a best practice to determine whether your Savings Plan transfers with the account for queued or payment-pending Saving Plans.

Note: After you transfer your Savings Plan, you can't return the Saving Plan because the management account changes. Note the accounts that own each Savings Plan to determine the accounts that you must submit transfer cases for.

Set up CUR 2.0 exports before you migrate

When accounts leave an organization, you can't access the account's historical cost and usage data from the migrated account's new organization. Before you migrate the account, make sure to export the data. You remain able to view historical data for the migrated account in the source organization's management account for retrospective gap analysis.

Deploy CUR 2.0 to Amazon Simple Storage Service (Amazon S3) in each management account. CUR 2.0 provides your cost and usage data with a static schema and additional account name columns. If you require container-level cost attribution, then activate split cost allocation data separately for the following services:

• Amazon Elastic Container Service (Amazon ECS)

• Amazon Elastic Kubernetes Service (Amazon EKS)

• AWS Batch

• Fargate

Opt-in to IAM principal-based cost allocation for only supported services, including Amazon Bedrock.

To centralize your cost and usage data, take the following actions:

• Set up Amazon S3 replication to a central data collection account.

• Deploy the CUDOS Dashboard for consolidated visibility.

• Before you migrate accounts, check that you have sufficient cost and usage data history.

• For temporary cross-organization cost visibility during phased migrations, use Custom Billing Views to combine cost management data from multiple organizations into a single view. Custom Billing Views doesn’t require full consolidation.

Plan for RISP Group Sharing post-consolidation

After all accounts are under one organization, take the following actions:

• Activate RISP Group Sharing in the consolidated organization.

• Create Cost Category groups that align with your business units.

• Use Prioritized or Restricted group sharing based on your financial reporting needs.

Transfer Savings Plans (if necessary)

If you can't use RISP Group Sharing, such as for organizations with separate Private Pricing Agreements (PPAs), then take the following actions:

• Before you migrate accounts, submit the transfer case from the source account.

• Explicitly request the effective date to match the account migration date.

• Coordinate with your TAM to make sure that RPO processes the transfer in time.

• Begin to migrate accounts only after the Savings Plan transfer confirms.

Note: As of November 2025, Organizations supports direct account transfers between organizations. Organizations no longer requires you to remove accounts as standalone before you invite them to the destination organization. This simplifies the migration step and reduces the time that accounts don't have organizational governance. It’s a best practice to do a Savings Plan gap analysis before you initiate direct transfer.

Important: Savings Plan returns are available only within 7 days after you purchase the plan, and the 7 days must be within the same calendar month. The management account can't exceed 10 returns each calendar year and must be the same management account used at the time of purchase. For the full return eligibility requirements, see Returning a purchased Savings Plan. After you migrate an account to a new organization, you can't return a Savings Plan from the new organization regardless of the 7-day return window.

Coordinate tax settings and Accounts Payable processes

To align tax and payment processes across both organizations, take the following actions:

• Make sure that Tax Registration Numbers (TRNs) match between organizations. If the TRNs don't match, then you can't transfer residency.

• Make sure that your Accounts Payable team tracks invoices on both organizations during the transition.

• Make sure that you pay all invoices during the migration so that you don't accumulate late payment fees.

Monitor cost allocation tags

Export and recreate cost allocation tags in the destination organization. Cost allocation tags are case-sensitive and can take up to 24 hours to appear after you create them.

Resolve outstanding credit memos before you close the source organization

If your source organization operates under a different operational unit or Seller of Record from the destination organization, then you can't transfer credit memos. For example, you bill Organization A through AWS EMEA SARL (EUR) and Organization B through AWS Inc. in USD. You can't apply a EUR credit memo in Organization A to invoices in Organization B, even if both organizations belong to you. Valid credits remain in the organization that you’re about to close.

Before you close the source organization, take the following actions:

• Identify outstanding credit memos or unapplied payments in the source organization’s accounts.

• Confirm that the source and destination organizations share the same operational unit and billing currency.

• If they don't match, then work with Support to resolve all credits before you close the source organization. In some situations, you can apply the credit to an open invoice in the source organization or request a refund.

How AWS Enterprise Support helped the Enterprise customer

The Enterprise customer's TAM identified the billing gap during a routine cost review and immediately engaged with the customer's Cloud Operations and Finance teams.

The TAM discovered the following findings during the consultation:

• The customer had no documented process to coordinate Savings Plan and RI transfers with account migrations.

• The Finance team didn't know that Savings Plan commitments are tied to the organization, not the workload.

• The customer couldn’t access the source organization's cost and usage data in accounts that joined the destination organization.

Working closely with the customer, the TAM developed a detailed billing migration plan to resolve the immediate gap and prevent future occurrences. The plan coordinated with the RPO team to expedite the remaining Savings Plan transfers with explicit effective dates. The plan also deployed CUR 2.0 before the customer migrated more accounts and recommended RISP Group Sharing for post-consolidation allocation control.

Putting it all together

The following is a recommended timeline for a billing-safe organization consolidation.

Week 1–2: Discovery

• Note all RIs, Savings Plans, AWS Marketplace agreements.

• Map owner-consumer relationships.

• Document cost allocation tags.

• Set up CUR 2.0 exports on all management accounts.

• Use AWS Cost Optimization Hub for a consolidated view of Saving Plan and RI recommendations across accounts and Regions. Cost Optimization Hub provides cross-account commitment visibility without the requirement to deploy the CUDOS Dashboard.

Week 3–4: Preparation

• Deploy the CUDOS Dashboard on the central Data Collection Account.

• Activate RISP Group Sharing and create Cost Category groups.

• Check that you have all your historical cost and usage data.

• Work with your TAM on Enterprise agreements.

Week 5+: Migration

• Migrate accounts in phases, from suspended to sandboxes to workloads.

• If you enrolled accounts in AWS Control Tower, then deactivate AWS Control Tower baselines before you initiate the direct account transfer. AWS Control Tower baselines include Config rules, AWS Backup policies, and non-preventive controls.

• Update RISP Group Sharing definitions as you migrate accounts.

• Every day, check your billing for anomalies.

• Check your Savings Plan coverage and utilization after each migration phase.

Post-Migration

• Activate RISP Group Sharing on the consolidated organization.

• Create Cost Category groups for each business unit.

• After you've tracked enough usage history in your new organization, confirm that the Saving Plan and RI recommendations are accurate. For Savings Plan recommendations, wait until at least 14 days have passed. For RI recommendations, wait for at least 30 days.

• Clean up your source organization.

• Review and optimize your Savings Plan and RI strategy for the new structure.

Getting started

• Reserved Instances and Savings Plans discount sharing](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-off.html)

• Cloud Intelligence Dashboards](https://docs.aws.amazon.com/guidance/latest/cloud-intelligence-dashboards/)

• What are AWS Cost and Usage Reports?

Note: Group Sharing and Cost Optimization Hub are available at no additional charge. CUR 2.0 data that you store in Amazon S3 incurs standard S3 storage costs. Cloud Intelligence Dashboards require Amazon Quick Sight Enterprise Edition licensing. The AWS Billing Conductor Customer Managed plan incurs monthly costs for each organization.

Cleanup

After you complete the consolidation, take the following actions:

• To reduce continued S3 storage costs, remove unnecessary CUR 2.0 exports from the source organization's management account.

• To keep billing reports clear and current, delete unused Cost Category groups from the pre-consolidation configuration.

• After you've transferred all accounts, Savings Plans, RIs, and AWS Marketplace agreements, close the source organization so that it no longer requires management.

• To reduce security risks from old trust relationships, review and remove unused IAM roles or cross-account access policies that referenced the old organization.

Conclusion

Organization consolidations are complex, but the billing challenges are preventable. During migration, plan your Savings Plan transfer with explicit effective dates to avoid the costly gap between when accounts migrate and when commitments follow. After you consolidate, RISP Group Sharing provides continual control over how you allocate commitments across business units in an organization. Group Sharing also removes the requirement for future transfers.

The main takeaway is to plan your financial migration with the same rigor as your technical migration. The accounts can migrate in minutes, but the effects of billing can last months.

Support engineers and TAMs can help you with general guidance, best practices, troubleshooting, and operational support during organization consolidations. To learn more about our plans and offerings, see AWS Support.

About the Authors

Jatin Makani is a Senior TAM supporting Energy customers in AWS Enterprise Support. He is passionate about Cloud Governance, DevOps, Infrastructure as Code, and modernization, and enjoys partnering with customers to solve their most complex operational challenges.

Ambrish Kumar Srinivasan is a TAM at AWS, supporting strategic enterprise customers in the Financial Services industry. He has extensive experience across cloud operations, cost optimization, and AI-powered automation. He focuses on building proactive solutions that help customers manage their AWS environments more effectively, from serverless lifecycle alerting to GenAI cost attribution and multi-cloud observability.