Try it now and let us know what you think. Switch to the new look >>
You can return to the original look by selecting English in the language selector above.
Managing Performance and Scaling for Aurora DB Clusters
You can use the following options to manage performance and scaling for Aurora DB clusters and DB instances:
Topics
Storage Scaling
Aurora storage automatically scales with the data in your cluster volume. As your data grows, your cluster volume storage grows in 10 gibibyte (GiB) increments up to 64 TiB.
The size of your cluster volume is checked on an hourly basis to determine your storage costs. For pricing information, see the Aurora pricing page.
When Aurora data is removed, such as by dropping a table or partition, the overall allocated space remains the same. The free space is reused automatically when data volume increases in the future.
Note
Storage costs are based on the storage "high water mark," the maximum amount that was allocated for the Aurora cluster at any point in time. Thus, you can manage costs by avoiding extract, transform, load (ETL) practices that create large volumes of temporary information. Similarly, you can manage costs by avoiding ETL practices that load large volumes of new data before removing unneeded older data.
If removing data from an Aurora cluster results in a substantial amount of allocated
but unused space,
resetting the high water mark requires doing a logical data dump and restore to a
new cluster, using a
tool such as mysqldump. Creating and restoring a snapshot does not
reduce the allocated storage because the physical layout of the underlying storage
remains the same
in the restored snapshot.
Instance Scaling
You can scale your Aurora DB cluster as needed by modifying the DB instance class for each DB instance in the DB cluster. Aurora supports several DB instance classes optimized for Aurora, depending on database engine compatibility.
Read Scaling
You can achieve read scaling for your Aurora DB cluster by creating up to 15 Aurora Replicas in a DB cluster that uses single-master replication. Each Aurora Replica returns the same data from the cluster volume with minimal replica lag—usually considerably less than 100 milliseconds after the primary instance has written an update. As your read traffic increases, you can create additional Aurora Replicas and connect to them directly to distribute the read load for your DB cluster. Aurora Replicas don't have to be of the same DB instance class as the primary instance.
For information about adding Aurora Replicas to a DB cluster, see Adding Aurora Replicas to a DB Cluster.
Managing Connections
The maximum number of connections allowed to an Aurora DB instance is determined by
the max_connections parameter in the instance-level parameter group for
the DB instance. The default value of that parameter varies depends on the DB
instance class used for the DB instance and database engine compatibility.
Managing Query Execution Plans
If you use query plan management for Aurora PostgreSQL, you gain control over which plans the optimizer runs. For more information, see Managing Query Execution Plans for Aurora PostgreSQL.
