Streamline Amazon RDS management with consolidation techniques – Part 1

Managing dozens or hundreds of Amazon Relational Database Service (Amazon RDS) databases across your organization creates operational complexity and drives up costs. Database sprawl is a common challenge where teams end up with lightly used instances scattered across departments and applications.

In this first post of a two-part series, we share proven strategies for database consolidation that can help you reduce operational overhead and optimize resource utilization. In the second post, we introduce an open source tool that we developed called RDS Consolidator, which helps you visualize your current database landscape and plan consolidation scenarios.

Database consolidation fundamentals

Database consolidation reduces the number of database servers’ instances, lowering hardware, licensing, maintenance, power, and space costs while improving overall resource utilization. Centralizing databases simplifies administration (backups, patching, monitoring), improves security by reducing the number of access points, and creates a more unified data landscape that supports better analytics and decision‑making.

Moreover, consolidated platforms can improve performance and agility when coupled with proper capacity planning and standardization. Organizations also benefit from more consistent governance, more straightforward enforcement of common configurations, and faster provisioning of new environments or databases.

However, consolidation concentrates risk: a failure or misconfiguration on a shared resource can affect many applications at the same time, magnifying the impact of outages, security breaches, or performance incidents. Mixed workloads might contend for CPU, memory, storage, and network, and differing SLAs, compliance needs, or versions can complicate maintenance and change management.

To mitigate these issues, organizations should group compatible workloads, perform careful capacity and performance planning, and use strong isolation and resource controls. Robust high availability and disaster recovery (HA/DR) architectures, and consistent data governance are also essential to maintain availability, compliance, and data quality in a consolidated environment.

Consolidation strategy

You will now explore the essential architectural considerations for planning the resource allocation, design the high availability, mitigate the blast radius impact, enforce the security, define the backup and recovery strategies, and optimize the costs through effective billing management.

Resource planning

When multiple databases run on a single Amazon RDS instance, they compete for shared CPU, memory, and storage resources, leading to potential performance bottlenecks and resource contention that can impact all databases on the instance. Managing resource allocation effectively is important to support performance, provide stability, and protect a database from the noisy neighbor problem.

With Amazon RDS for Oracle, Oracle Database Resource Manager manages and controls CPU allocation and other resources among different users, applications, and even pluggable databases (PDBs) in a multitenant setup. The Oracle multitenant architecture alters a database, allowing it to act as a container database (CDB) with one or many PDBs. A PDB is a portable collection of schemas, schema objects, and non-schema objects that are attached to a container and appears to an Oracle Net client as a standalone database. With Oracle Database Resource Manager, you can control the following:

• Relative CPU shares – Higher shares mean a PDB gets a larger share of CPU resources when there is competition
• Utilization limits – You can enforce hard limits on the maximum CPU percentage a PDB can consume
• Parallel execution – You can limit how many parallel query servers a PDB can use
• Granularity – You can create plans within each PDB to allocate resources between users or sessions

Amazon RDS for PostgreSQL and Amazon RDS for MySQL don’t provide native tools to allocate CPU, memory, or IOPS per database within a single instance. All databases in a PostgreSQL instance share the underlying resources at the instance level. However, organizations can adopt Amazon Aurora Serverless. It automatically adjusts database compute and memory capacity in fine-grained increments as applications demand changes, scaling up rapidly during spikes and scaling down (even to zero) during periods of low activity. This hands-free scaling reduces manual provisioning and resizing of instances.

Microsoft offers Resource Governor to manage SQL Server workloads and resources by specifying limits and priorities on CPU, memory, and I/O usage for different workloads, users, or applications. SQL Server Resource Governor is available with Amazon RDS Custom SQL Server and with Amazon RDS for SQL Server.

Amazon RDS for Db2 manages resources across multiple databases on one instance using IBM Db2 workload management. You configure logical workloads and service classes, then provision and monitor the instance to balance needs. You can also apply general best practices, such as implementing connection pooling at the application level to minimize connection overhead and enhance concurrency handling, or using read replicas to balance read operations across multiple database instances.

High availability design and blast effect impact

When multiple databases are consolidated on the same instance, if one database or workload encounters an issue (such as a crash, resource exhaustion, or security breach), the negative impact can spread to other databases sharing that environment. The blast effect can lead to higher downtime, degraded performance, data corruption risks, or security exposure for multiple tenants or applications at once.

Amazon RDS offers multiple solutions to align the availability of your databases to the defined service level agreement (SLA). However, these solutions (backup and restoration strategy, read replicas, multi-AZ architecture) act at the instance level, as we’ve partially discussed already.

Amazon RDS multi-AZ is a deployment configuration where a primary database instance is synchronously replicated to a standby instance in a different Availability Zone within the same AWS Region. This setup provides enhanced availability, automatic failover support, and increased data durability, helping you meet disaster recovery and business continuity objectives for all the databases hosted in the instance. It means that, the criticality of the databases needs to be aligned when grouping workloads.

Your use case might require replicating a single database from one RDS instance to another:

• With Amazon RDS for MySQL and Amazon RDS for MariaDB, you can use replication filtering to specify which databases and tables are replicated with a read replica. Replication filters can include databases and tables in replication or exclude them from replication. For details about setting up replication filtering, see Configuring replication filters with MySQL and Configuring replication filters with MariaDB.
• For Amazon RDS for PostgreSQL, you can use logical replication (for example, publish and subscribe) to replicate specific schemas or tables.
• SQL Server replication offers similar granularity, which can be implemented with RDS Custom SQL Server.
• With Oracle, because the classical version of Data Guard acts at the CDB level, you might need to use GoldenGate for selective replication between RDS instances.
• AWS Database Migration Service (AWS DMS) supports replicating individual databases or tables between RDS instances, including cross-engine migration.

Alternatively, you might opt for Amazon Aurora for MySQL and PostgreSQL databases. Aurora separates compute from a distributed storage layer that spans multiple Availability Zones and replicates data six ways, protecting against Availability Zone and disk failures. All instances share the same storage, so failover promotes a read replica—no data copying or synchronization is required. The storage layer handles redo logs and page versions, eliminating traditional crash recovery on the instance. As a result, a new primary database can resume operations immediately after failure. The design of Aurora delivers fast failover, high durability, and simplified operations. The post Deep dive on Amazon Aurora and Amazon RDS for PostgreSQL architecture and features can help you decide between Aurora and Amazon RDS.

Security and access control

How can you achieve proper logical isolation and granular permissions for each database, when all databases share the same instance-level security boundaries?

This requires meticulous management of unique users, roles, and schemas within each database to prevent unauthorized cross-database access while effectively controlling connections and privileges at both the instance and database levels.

Additionally, access to the AWS account hosting the RDS instance and overall infrastructure must be carefully managed. Your consolidation strategy is influenced by your organization’s AWS account design. AWS best practices isolate production, development, and testing environments in distinct accounts. This separation facilitates precise access control at the account level, with AWS Organizations supporting centralized management of multiple accounts and enforcement of governance policies, preventing restricted users from accessing unauthorized instances.

At the database level, access control is achieved through a combination of AWS security features and native database engine controls. The native access controls of the database engine (such as MySQL, PostgreSQL, SQL Server, or Oracle) provide their own mechanisms to manage access within an instance. You create database users and roles, granting permissions that specify what databases, schemas, or tables users can access and what operations they can perform. This is the primary method for enforcing fine-grained access control at the database level inside an RDS instance.

For MySQL, MariaDB, and PostgreSQL, Amazon RDS supports AWS Identity and Access Management (IAM) database authentication. IAM authentication can be combined with database-level permissions to limit user capabilities within a specific database. IAM controls who can request authentication tokens and connect, providing centralized credential management instead of using traditional database passwords. These tokens are short-lived (valid for 15 minutes) and alleviate the need to store database passwords in application code.

As an additional measure, you can define RDS resource tags that IAM policies can reference to allow or deny access to specific RDS resources. However, fine-grained, database-level access control inside the RDS instance itself depends on the database engine’s user and role management.

Backup and recovery strategy

Amazon RDS backup and restore options act at the instance level, covering all instances equally and simultaneously. What if you have requirements specific to a single database?

Let’s first review how Amazon RDS backup and restore works. Unless you set the retention time to zero, Amazon RDS automatically creates daily backups of the entire database instance during a configurable backup window. This backup captures the full storage volume snapshot of the database instance, which includes all databases inside that instance. Automated backups support point-in-time recovery (PITR) for up to 35 days.

You can also create manual database snapshots at any time. The first snapshot is a full backup; subsequent snapshots are incremental, only saving changes since the last snapshot, which helps save on storage costs. Backups—both automated and manual—are stored in Amazon Simple Storage Service (Amazon S3) and contribute to the total backup storage, which is separate from the main database instance storage.

You can use Amazon RDS automated backups to spin up a new database instance at any point in time within the configured retention period, while you can use manual snapshots to create a new instance containing the data exactly as it was when the snapshot was taken. In both cases, backup and restore operations apply to the full database instance rather than individual databases, meaning you can’t select a single database for backup or perform partial restores of only a subset of databases.

If you only need to restore a single database, you must restore the instance separately in isolation, then export and import the required data manually using database engine tools such as Data Pump for Oracle, pg_dump and pg_restore with PostgreSQL, native backup and restore for SQL Server, and mysqldump for MySQL.

Billing

How can service providers (or IT services acting as such) accurately allocate costs to individual tenants when multiple tenants share the same database instance?

This common challenge arises because data on resource consumption is difficult to obtain in a shared environment. Service providers want to maximize efficiency by grouping multiple tenants within a single database instance, but the primary issue lies in determining how much of the database resources each tenant uses.

The consumption cost of Amazon RDS instances is typically managed through cost allocation tags. The resource owner assigns user-defined tags (key-value pairs) to RDS instances that represent an organizational structure, such as project, department, cost center, or team. With tagging, you can categorize and attribute costs to specific entities or business units and generate reports with AWS Cost Explorer.

Because of the instance-level cost allocation granularity, determining the consumption of a single database within an RDS instance can be challenging. You can, however, approximate resource usage for each database by combining several approaches and tools, such as querying system views or tables to monitor resource consumption (CPU, disk) per database. This is rarely satisfying because of the setup complexity and the difficulty to address some situations (for example, how to bill unused CPU or pre-allocated storage space).

To work around this constraint, you can combine Amazon RDS Performance Insights (to be replaced by CloudWatch Database Insights) and AWS Cost and Usage Reports (CUR) analyzed with Amazon Athena. This provides detailed visibility into resource consumption and costs per tenant or database user. For more details, see Improve cost visibility of an Amazon RDS multi-tenant instance with Performance Insights and Amazon Athena. Note that the database licensing impact of the consolidation isn’t covered if you bring your own licenses.

With this approach, customers running multi-tenant RDS or Aurora instances can manage and allocate costs with accuracy using AWS monitoring and analytics capabilities, improving transparency and cost-efficiency in shared database environments.

Conclusion

With the challenges, opportunities, and solution patterns for Amazon RDS consolidation now mapped out—from fragmented fleets and underutilized instances to right‑sizing, instance class rationalization, and governed multi‑tenant designs—we’re ready to move from principles to practice.

Our next post (Part 2) introduces RDS Consolidator, a practical tool designed to optimize Amazon RDS costs and streamline database consolidation by identifying the best database stacking strategies to maximize resource utilization and cut spendings without compromising SLAs.

About the authors