Amazon Cloud Technology announces the full launch of Amazon Aurora I/O-Optimized cluster configuration

Since the launch of Amazon Aurora in 2014, thousands of customers have chosen Aurora to run their most demanding applications. Aurora provides unparalleled high performance and availability globally, is fully compatible with MySQL and PostgreSQL, and costs only one-tenth of commercial databases.
Many Amazon Web Services customers benefit from Aurora's current simple pay-per-request pricing for input/output (I/O) usage, eliminating the need to provision I/O ahead of time. Customers also benefit from other cost-saving innovations, such as Amazon Aurora Serverless v2 (ASv2), which scales seamlessly in granular increments based on application needs. For workloads with peak demand, you can save up to 90% compared to using ASv2 to provision capacity for peak loads.
On May 15, Amazon Cloud Technology announced the general availability of Amazon Aurora I/O-Optimized, a new cluster configuration for customers with I/O-intensive applications such as e-commerce applications and payment processing systems. Better value for money and predictable pricing. Aurora I/O-Optimized improves performance, increases throughput, and reduces latency to support the most demanding workloads.
Now, costs for the most I/O-intensive workloads can be predicted with confidence, resulting in cost savings of up to 40% when I/O spend exceeds 25% of current Aurora Database spend. If you use Reserved Instances, you can save even more.
There is now the flexibility to choose from an existing configuration called Aurora Standard, an existing pay-per-request pricing model that is cost-effective for applications with low to moderate I/O usage. New Aurora I/O-Optimized configuration for I/O-intensive applications.
 
Getting Started with Aurora I/O-Optimized
Create a new database cluster using the Aurora I/O-Optimized configuration, or convert an existing database cluster with a few clicks in the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDK.

 

80a7ac52286b4f69baeff7dfdcb954bd.png

 

 For Aurora MySQL-compatible editions and Aurora PostgreSQL-compatible editions, you can choose between Aurora Standard or Aurora I/O-Optimized configurations.
Aurora I/O-Optimized configurations are available in the latest versions of Aurora MySQL version 3.03.1 and higher, Aurora PostgreSQL v15.2 and higher, v14.7 and higher, and v13.10 and higher.
This configuration supports Intel-based Aurora Database instance types such as t3, r5, and r6i, Graviton-based database instance types such as t4g, r7g, and x2g, Aurora Serverless v2, Aurora Global Database, on-demand Aurora Database instances, and Reserved Instances.
Amazon Aurora's R7g instances are powered by the latest generation of AWS Graviton3 processors. Compared with R6g instances, Aurora's performance is improved by up to 30% and the price/performance ratio is improved by up to 20%.
In an existing Aurora cluster, you can switch the storage configuration to Aurora I/O-Optimized once every 30 days, or switch back to Aurora Standard at any time. Cluster storage configuration changes can only be made at the cluster level, and the changes apply to all instances in the cluster.
After changing the configuration, you can take advantage of the price/performance of Aurora I/O-Optimized without restarting the database instances in the cluster. Amazon Aurora I/O-Optimized configurations now available Amazon Aurora MySQL-compatible version and Aurora PostgreSQL-compatible version available in most Amazon Cloud Technology regions where Aurora is available, China (Beijing), China (Ningxia), AWS GovCloud (US East
 
)
) and AWS GovCloud (US-West) regions are coming soon.
Aurora billing methods are different for two configurations: Aurora Standard or Aurora I/O-Optimized. The latter does not charge I/O fees, compared to the former, which charges a fixed price for computing and storage. For I/O-intensive applications, the price/performance ratio will be even higher, with cost savings of up to 40%.
 

Guess you like

Origin blog.csdn.net/m0_71839360/article/details/130847281