iTranslated by AI
re:Invent 2025: Cost Savings and Efficient Operations for Amazon RDS for SQL Server and Oracle
Introduction
By transcribing various overseas lectures into Japanese articles, we aim to make hidden valuable information more accessible. The presentation we're covering in this project, based on this concept, is here!
For re:Invent 2025 transcription articles, information is compiled in this Spreadsheet. Please check it out.
📖re:Invent 2025: AWS re:Invent 2025 - Cut costs & operate efficiently on Amazon RDS for SQL Server & Oracle (DAT325)
In this video, Mehul Shah from AWS explains how to reduce costs and operate efficiently with RDS for SQL Server and Oracle. By using additional storage volumes, you can scale up to 256 terabytes, allowing for flexible configurations combining IO2 and GP3. Utilizing SQL Server Developer Edition can reduce development and testing environment costs by 74%, and switching to Web Edition can achieve up to a 58% cost reduction. Upgrading to 7th-generation instances and using the Optimize CPU feature can save up to 55% in costs, while using bare-metal instances for Oracle can yield a 25% cost reduction. Practical operational improvement measures, such as high availability support with Multi-AZ configurations and downtime-free storage addition/removal features, are introduced with specific pricing examples.
- Please note that this article is automatically generated while maintaining the content of the original presentation as much as possible. There may be typos or incorrect information.*
Main Part
Introduction to RDS for SQL Server and Oracle: Ease of Migration and Benefits of Managed Services
Hello, everyone. Welcome to session DAT325. Today, we're going to talk about how you can use RDS for SQL Server and Oracle to reduce your costs and operate more efficiently. My name is Mehul Shah. I'm the director for RDS databases, SQL Server, Oracle, DB2, and Oracle Database on AWS. Before we get started, I want to get a sense of the room. How many of you are already using Amazon RDS? Most of you. Okay. How many of you are using SQL Server? About half the room, more than 50% of you. How many of you are using Oracle? Okay, quite a few. Good. Looks like we have the right audience. So let's get started.
Here's our agenda for today. We'll start with a quick introduction to RDS, and then we'll dive deep into some of the improvements that we've been making with respect to how you use storage volumes. There have been a couple of recent launches, which make it more flexible in terms of how you use storage volumes and allow you to operate a little bit more efficiently than you could before. And then we'll talk about some new service capabilities, which will help you reduce your costs when you're running SQL Server and Oracle on RDS.
Relational databases at AWS. If you look at relational databases, Amazon provides Aurora, which has a PostgreSQL-compatible edition and a MySQL-compatible edition. And there's also Aurora DSQL, which is a serverless distributed SQL service. There's also Amazon RDS for open source databases. This includes RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB. And then there's RDS for commercial database engines, which includes RDS for Oracle, SQL Server, and DB2. Most of our discussion today will focus on RDS for commercial database engines, which includes SQL Server and Oracle.
So why do we offer RDS for commercial database engines? First, ease of migration. We know that thousands of customers are already using Oracle and SQL Server on-premises. When these customers move to the cloud, when they move to AWS, the easiest way for them to migrate is to use the same databases and run them on AWS. Because they don't have to change their application. They don't have to change their schema, rewrite it to a new database schema. They don't have to change their stored procedures. It just works. So if you have an application that is running on SQL Server or Oracle on-premises and you want to run it in the cloud and use the same database, SQL Server and Oracle, it's an easier migration.
Flexible licensing options. Many of our customers have long-term agreements with Microsoft for SQL Server or with Oracle to use Oracle, and this includes their licensing and support terms. So for those customers, they often use what we call a bring your own license model, where they can bring their existing agreement, their existing support model, and simply run it as is on AWS. But we also provide a license included offering, and this is particularly attractive for many customers for several reasons.
First, a license included offering includes the license for the software and server usage, all included. And essentially, you're paying on an hourly basis, only for the time you're using it, for both your server usage and your license. So if your needs change over time, meaning you need more licenses, or fewer licenses, or your usage goes up or down, you're essentially paying for what you need, rather than signing up for a long-term agreement.
And it becomes particularly interesting because many customers want to change to a different database over time. For example, their application might change from using SQL Server to using an open-source database, or from a relational store to a non-relational store. In those cases, typically they make those changes over a period of time, and they can't always predict when and how it will happen. So by having a usage-based model, you ensure that you're only paying for what you need, and then you can gradually migrate. So that's where the license included model becomes very attractive for many customers.
Third, RDS provides managed services for running these engines. Things like software patching, software updates, backups, storing your backups into a separate region for disaster recovery, all of these operational aspects are automated. For example, if you want to apply a software update, RDS provides you with the latest updates. You just specify a maintenance window, and RDS will apply the update during your maintenance window. You can choose when you want to apply the update, or you can even instruct RDS to apply the update automatically.
In fact, we recently launched a new capability where you can stage your upgrades. So for many of you, if you have a test environment, a development environment, and a production environment, you simply tag your different instances and say, this is my test instance, this is my production instance. And then the software updates will automatically get applied to your test instances first, and then a couple of weeks later, they will get applied to your production instances.
What this does is it ensures that you have time to test, and you're not surprised by an update that suddenly shows up on your production instance and then your application's performance changes. So it gives you that window. All of this is automated, and you don't have to do any manual work around it. So managed services provides a lot of benefits that frees up your time to do application-specific work.
And finally, there are many options to achieve high availability. RDS provides you with Multi-AZ configurations, which essentially allow you to recover much more easily in the event of, let's say, a hardware failure or a software failure, or even a power failure, and it allows you to quickly fail over to a standby instance. These options are configurable, so you simply specify what you need. You can specify that you want a highly available service with a Multi-AZ configuration, or you can specify that you want read replicas, and the installation will be automatically handled.
Additional Storage Volumes Feature to Solve Storage Challenges
Let's take a look at what a typical Multi-AZ configuration looks like. So you have your application. Your application communicates with an RDS instance endpoint. The instance endpoint communicates with an instance, which is typically your primary instance in an availability zone. Your database instance is backed by an EBS volume, a storage volume. When you specify a Multi-AZ configuration, RDS automatically sets up a standby instance in a separate availability zone. This protects you from any failures that might happen to your instance. Your standby instance has its own storage volume on EBS, and data is synchronously replicated from the primary instance to the standby instance. Synchronous means that when a transaction is written, it is written to both primary and standby before the transaction is committed.
Now, we've worked with thousands of customers over the years, and we found a couple of areas where we could make the service better for our customers. Let me give you some examples. In RDS, you choose the size of your storage that you need, and the volume can be up to 64 terabytes. Now, we've seen some customers who have very large databases, and they are larger than 64 terabytes. It doesn't happen often, but it does happen from time to time. Even if it doesn't happen, if you're reaching 40 or 50 terabytes, you want to know that the service will continue to operate, and you have a path to scale up in the event your storage size increases over time.
The ability to scale up and scale down. Many times you have scenarios where you need a large amount of storage for a short period of time. You might be running a data processing job once a month, or you might have annual peak seasons where your storage volumes increase. Or you might be restoring a backup in Oracle, where you copy a backup to the volume, restore from the backup, delete the backup file, and then you want to shrink your storage size. So there's a need to grow and shrink your storage over time in many scenarios.
IO2 and GP3. EBS provides different volume types. You can choose IO2 storage for your database, or you can use GP3 storage for your database. We recommend IO2 for critical workloads. IO2 provides the highest level of availability, durability, and consistent low-latency performance that you would expect for high-transaction workloads in production. We also offer GP3, which is a general purpose EBS volume. GP3 volumes tend to be more cost-effective, and in many cases, GP3 volumes are sufficient for running production workloads.
If some of your data in your database always needs high performance, high transaction capabilities, high durability, low latency, while you have some data that is not frequently accessed, meaning it's rarely used, maybe it's older data, but from time to time it gets accessed as part of the same database, ideally you would want to be able to pick and choose and say, I want IO2 for this data, and I want GP3 for this data, which allows you to optimize your costs more efficiently and use the right storage volume for the right set of data. But you have to pick one. So what often ends up happening is you pick IO2, even though your entire database storage doesn't need IO2.
And finally, when we replicate data from primary to standby instance, there's a replication channel. The replication channel provides throughput of about 625 megabytes per second. When you write a lot of data in a short period of time, from time to time you can run into the limits of this replication channel's throughput, and that can slow down your transaction rate. So we wanted to look at how we can improve this.
To address this, we've added the capability to have additional storage volumes. How does this work?
This diagram shows you the same environment. You have a Multi-AZ configuration, application instance endpoint, primary instance, standby instance, and they're each backed by an EBS volume. But what you can now do is you can add additional volumes on different mount points and connect them to the same instance. And you can add up to three additional volumes in addition to your primary volume. This gives you the ability to quadruple your storage. So you can now have up to 256 terabytes of storage for your database instance. You also have the ability to add and remove storage volumes over time. So that means you don't have to have all your volumes at the start. As your data grows, you can add volumes. If you don't need the storage, you can remove the volumes, and all of this can be done without application downtime. So this gives you enhanced flexibility to adjust your storage based on your needs.
Additional Storage Volume in Practice: Tablespace Movement and IO2/GP3 Combinations
And I'm showing Oracle in this example, but this capability is available for both RDS for Oracle and RDS for SQL Server. You can use it in the exact same manner for both database engines. So let's see how you can use it. In this case, I have a database instance that I've just created. My primary instance is using Oracle, and it has a single volume. If I want to add additional storage, there's a command modify DB instance. You specify your database instance. In this case, it's called my instance. You specify the volume name you want to use, the volume mount point you refer to. I call it rdsdbdata2, and I specify the properties such as storage type IO2, the amount of storage I need, and the amount of IOPS I need for the additional volume. When I run this, I'll get a second volume, and I can refer to that volume using the name that I specify. In this case, I'm using rdsdbdata2.
Now that I've added a volume, the next thing I want to do is allow my database to use that volume. If I'm using Oracle, the easiest way to do that is to update the default location that Oracle uses when it creates new data files. If I'm using RDS, it's very easy to do that simply by updating a parameter. There's a parameter called DB_CREATE_FILE_DEST, and that specifies the default location for new storage tablespaces. In this case, the default was rdsdbdata, which is my primary volume. I use an alter session command to change the default location to rdsdbdata2. And after I change it, I want to confirm that the change has taken effect, so I call show parameter again. As you can see, the default location has been changed to rdsdbdata2. When I run this, if I create new tablespace files, they will automatically be created on the additional volume. So if you're growing your storage over time, this might be an easy way to start putting new tablespaces on new volumes.
But there's something even more interesting you can do with additional storage volumes. Let's say, for example, you want to move a tablespace from your primary volume to the additional volume you just added. Maybe that tablespace is growing, or you expect it to grow very large in a short period of time. In that case, you just want to move your existing tablespace from the primary volume to the additional volume that you just created. And then you let it grow for a period of time. It grows, it grows, it grows, and then a couple of weeks later, you may not need that storage anymore. The data size shrinks, and a couple of weeks later, you may want to move it back to your primary volume. And you don't want to pay for storage you're not using, so you delete the additional volume. So what this allows you to do is move to an additional volume, use it for a short period of time, move it back to the primary volume, and then delete the additional volume. So how do you do that?
To move the tablespace to the additional volume, I call the select command. In this case, my tablespace is named my tablespace. I call the command to get the properties of the tablespace. I can see that the tablespace's file ID is six, and the tablespace resides on the primary volume rdsdbdata, and it has a tablespace file name. I then call the command move datafile and specify that I want to move the datafile with file ID six to the additional volume rdsdbdata2. After I run the command, I call the select command again to confirm the properties of the tablespace. As you can see, the tablespace file has been moved to the new storage volume I just added, rdsdbdata2. This can be done without any application downtime. It's done in the background.
Let's say I used the tablespace for a while. It grew, it changed over time, and now it's much smaller, and I want to move it back to my primary volume and delete the additional volume. To do that, first I need to clean up the additional volume.
First, I check all the tablespace files that have been created on the additional volume. I call the select command and specify that I want to see all the tablespace files in the additional volume. Again, I see only one file with file ID six. Then, I call the execute command again to move the data file back to the primary volume. And I confirm again to see if the file name has been moved to the primary volume. I can see that it's moved back to rdsdbdata, which is the primary volume. And then I call the command to see if there are any tablespace files remaining on the additional volume, and I see that there are no tablespace files remaining anymore. The volume has been cleaned up.
Once I'm done cleaning up the volume, the next thing I can do is delete the volume. To do that, I call the modify DB instance command again to delete a storage volume. And I set for delete to true. When I run this, the volume will be marked for deletion, and I will no longer be billed for the volume I was using before. Now, when I call the command to delete a volume, if there are any files in use, it will give me an error. That ensures that I don't accidentally delete a volume that is actually in use. So once I ensure all my files are moved off the volume, I can delete the volume and stop incurring costs for that additional volume.
Now, there's an even more interesting capability with volumes. You can now mix and match io2 and gp3 volumes. So for example, many times you have older data that is not very frequently used, and you can create a gp3 volume and then move your tablespace files for those data tables to the additional volume. So essentially you can mix and match volumes, and you can mix and match the volume type as you please when you're using RDS. When you're mixing and matching, we typically recommend that you use an io2 volume for your primary volume. Why is that? When you write to a database, the database first writes to a write-ahead log. The write-ahead log is always on the primary volume. So if you're using a combination of io2 and gp3, we recommend using an io2 volume for your primary volume and then using gp3 for your additional volumes.
There's also a benefit in the Multi-AZ replication scenario. As I mentioned, when you write a transaction, the data gets replicated to two zones before it gets committed. And a single replication channel for a single volume provides 625 megabytes per second of throughput. But when you add a second volume, you get a second channel to replicate the second volume. A third volume will have its own channel. A fourth volume will also have its own channel. So essentially you get more throughput. So if you're writing a lot of data to certain tables in a short period of time, or in the case of SQL Server, you have multiple databases on the same instance, and some databases are writing a lot of data, it might be beneficial to put those databases or tablespace files on additional volumes. The additional volumes will then have their own dedicated channels for replicating data in a Multi-AZ configuration.
So in summary, when you use additional storage volumes, you have multiple benefits. You can use it to get more storage. This capability is available for both SQL Server and Oracle. You have the ability to add and remove volumes without downtime. You can use additional volumes as temporary storage for short-term needs. In some cases, when you're creating temp files in SQL Server, many applications and workflows and jobs will create a lot of temp files in SQL Server. If you need a lot of storage with temp files during the job run, you can use additional volumes. Once the job run is completed, you can delete the additional storage volumes. You can mix and match io2 and gp3 volumes. And when you're setting up a Multi-AZ configuration with RDS, when you add or remove volumes, RDS automatically replicates the changes to both your primary instance and your standby instance in the background, so you don't have to do any management tasks or operational tasks to ensure consistency.
Reduce Development and Test Environment Costs by 74% with SQL Server Developer Edition
Now, let's talk about some new service capabilities that will help you reduce your costs. SQL Server Developer Edition. Microsoft provides SQL Server Developer Edition, and it is now fully supported on Amazon RDS. So what that means is you can now use Developer Edition of SQL Server with all the capabilities that you typically use with Amazon RDS. SQL Server Developer Edition is a full-featured version of SQL Server. It has all the capabilities available in SQL Server Enterprise, and it is free of licensing costs because it is intended for non-production use and for development and testing purposes.
If you look at most development environments, many developers have a development environment where they're building new applications. Many times they have a test environment or pre-production environment where they bring all their applications and do performance testing and application testing, and then they have a production instance where they run their production workloads. In this case, you can start switching all your development environments and your test environments, your test instances, to use Developer Edition, and you can only use Standard or Enterprise Edition for your production instances. What happens when you do this? Let's take a look at the costs when you start using different editions.
Now, this diagram shows you an example of different editions and the costs that you incur per hour when you use different editions of SQL Server. In this case, I've taken two instance types, M6i XL and R6i XL, and these are the costs of different editions. These are public prices for the Virginia region, but even if you're using it in other regions, the prices will be similar, and the variations will be similar. If you switch from Standard Edition to Developer Edition on an M6i XL instance, the price changes from $0.977 per hour to $0.60. If you switch from Enterprise Edition for your pre-production testing to Developer Edition, the price changes from $2.501 per hour to $0.74.
So essentially, simply by switching all your development and test environments to use Developer Edition, you can reduce the costs of all your development and test environments by 74%. And all you have to do is start using Developer Edition for these environments. How do you use it? It's very simple. First, you download the ISO image for SQL Server Developer Edition from Microsoft's website. That's required for license compliance. You notify us that you're using SQL Server Developer Edition, you download it from the website, and that indicates that it's an instance you want to use for development and test purposes, non-production purposes.
After you download the ISO image, you simply upload it to an S3 bucket. You can upload it to any S3 bucket you like. In this case, I'm uploading it using S3 CP to a bucket called My Test Bucket, but you can upload it to any bucket you prefer. Once you upload the ISO image, you notify us and create what is called an RDS custom engine version. Why is that needed? Because once you have a Developer Edition image, you want to be able to use Developer Edition across multiple development and test environments, across multiple instances.
So once you build what we call a custom image, which is a Developer Edition image based on the ISO image you provided, you can then use it for all your instances for development and testing. To do that, you use a simple RDS command called create DB engine version. You specify the bucket name where you uploaded the ISO image. In this case, it was My Test Bucket. You specify the file name that you uploaded for the ISO image, and then you name your engine version. These are names that you can name so that it's easy for you to remember what engine version you're using.
For example, if you're using different versions of SQL Server, I would recommend putting the version name of SQL Server you're using so that it's easy to remember when you're creating the instance. Once you create your custom engine version, you can start creating instances using Developer Edition. To do that, you use the same create DB instance command from RDS. This is the same command that you use when you create production instances or development instances. The only difference is that you specify the custom engine version that you just created.
We created an engine version called My RDS SQL Server 22 Dev in the previous step. You specify the same engine version, and then you specify your instance name and your instance properties. For example, which region you want to create your instance in, how you want to configure your instance. Do you want it to be a single availability zone instance, or do you want it to be a Multi-AZ configuration? You can specify all these configurations. And that's it. When you run this, you will create an RDS instance for SQL Server. It will be using SQL Server Developer Edition, and all the capabilities available in RDS will be available to you for your development and test environments.
SQL Server Web Edition with Multi-AZ Support Enables Up to 58% Cost Savings
SQL Server Web Edition. This is also provided by Microsoft. Web Edition is designed for web hosting providers. It's optimized for web hosting. So if you have a website, if you have web services, if you have ASP pages, if you have internal web applications, and you're using a database to power those web applications, SQL Server Web Edition is designed for that. It also has a lower licensing cost compared to SQL Server Standard Edition and SQL Server Enterprise Edition.
Now, if you have web applications and websites, you need high availability for your websites, right?
You want to ensure that your system doesn't go down, your web services don't go down, and you want to ensure high availability so that in the event of a hardware failure or a power outage, you're able to recover from that failure. So we looked at the high availability capabilities across different SQL Server editions. SQL Server uses something called Always On Availability for high availability. But if you look at the availability of this capability, it's available in Enterprise Edition, it's available in Standard Edition, but it's not available in Web Edition. So we asked ourselves, how can we solve this problem?
In Amazon RDS, we're launching high availability support for SQL Server Web Edition. How do we do that? We use synchronous block-level replication in a Multi-AZ configuration. This is very similar to what you saw earlier for the Oracle example. Your application talks to the RDS instance endpoint. The instance endpoint talks to the SQL Server primary instance, and this instance is backed by an EBS volume. And we do block-level replication from the primary instance's EBS storage to the standby instance's EBS storage in a second availability zone.
And we're ensuring that the license applies only to one instance at a time. Because you're only actually using the primary instance, and the data is simply being replicated to the standby instance, but not actually being used. So essentially, you're not using SQL Server on the standby instance. Now, RDS also automatically detects failures. The RDS instance endpoint is routing requests to the primary instance. When it detects that the primary instance has failed, it automatically detects the failure. It stops the block-level replication that was happening from primary to standby. It routes requests to the standby instance. At this point, the standby instance becomes the new primary, and then it replicates in reverse. It replicates from the standby, the new primary, to the previous primary instance, and the previous primary instance becomes the standby instance.
All of this detection, switching, rerouting, creating a new standby happens behind the scenes. RDS does all of this behind the scenes for you to provide high availability. So what's the benefit? The benefit is that many of your applications, your web applications, that you were previously running on SQL Server Standard Edition, you can now run them on Web Edition. What's the benefit? Let's take a look at the pricing. These are public prices for license included in the US East Virginia region, but similar pricing will apply in all other regions.
In this case, these are Multi-AZ configuration prices. I'm taking two instances, M6i XL and R6i XL, as an example. If I switch from Standard Edition to Web Edition, the price drops from $2.45 per hour to $1.01. For R6i, if I switch, the price goes from $3.04 per hour to $1.69. So essentially, simply by switching all your web applications and ASP pages, web services, from Standard Edition to Web Edition, you can reduce the cost of running RDS SQL Server by up to 58%. If you're only using Web Edition and you're using it in a single AZ configuration, you can now use a Multi-AZ configuration for high availability. And to do this is very simple.
If you're doing it from the console, there's an option called Modify DB Instance. There's an attribute called Multi-AZ deployment. You simply change the value of this attribute to say, yes, I need a Multi-AZ deployment. You apply the changes, and RDS will create a standby instance for you behind the scenes. And that's it. Your application can continue to run. There are no changes required to your application. vCPU-based licensing costs. This is also very interesting. When you use Microsoft SQL Server, the licensing charges are based on the number of virtual CPUs, or vCPUs, that you use in your instance.
Up to 55% License Cost Reduction with Optimize CPU Feature and 7th Generation Instances
Now, on a typical Intel instance, for each physical CPU core, there are two virtual CPUs, or two logical CPUs. Why is that? This is because of a technology called SMT, or Simultaneous Multi-Threading. What SMT does is it allows you to run two parallel threads on each physical CPU core. However, it does not give you two times the performance. Because there's only one physical CPU core. So in this example, you don't get the performance of four CPUs because there are only two physical cores.
But you don't get two times the performance for each core. However, you pay two times the licensing cost. So you get a slight performance gain, but you're paying two times the licensing cost for each physical CPU core. So we asked ourselves, how can we leverage this to be more cost-effective? Turns out, you can turn off SMT on your instance.
When you turn off SMT on your instance, you have one logical CPU for each physical CPU. But your licensing costs are half of the vCPU count that you were previously running. So let's look at some examples. Many database workloads tend to be memory-bound or IO-bound, rather than CPU-bound.
In this example, I'm using metrics for a workload on an R7i 8xlarge machine. As you can see, the free memory available for this workload is about 25%. So that means I'm using about 75% of the memory available on the instance, and that seemed like a good utilization for the machine. Then I look at my CPU utilization. On the same machine, my CPU utilization is only about 10%.
This is what a workload looks like when it's memory-bound, not CPU-bound. So what happens if I turn off SMT for this type of workload? So I tried turning it off. In this case, when SMT was on, the utilization was about 10%, and I was using 32 vCPUs, and I was being charged a licensing cost for 32 vCPUs. When I turn off SMT, I go to 16 vCPUs, and I have the same number of physical CPUs. All my physical CPUs are available and being used.
And my performance is still less than 20%. So my CPU is still not being fully utilized. But what happened here is my licensing cost switched from a license for 32 vCPUs to a license for 16 vCPUs. So what we've done in RDS is we've introduced a capability called Optimize CPU to leverage this. What we're doing now for our 7th generation instances and all upcoming future instances is we're optimizing the SMT settings for these instances based on the size and performance characteristics of the instance so that you get better cost performance out of the box with these instances.
So essentially, simply by switching from your older 6th generation instances to your 7th generation instances, you'll get a lower price. It's a lower price because it has optimized CPU settings. So if I was using an R6i 2xlarge instance with SQL Server Enterprise, and I simply upgraded to an R7i 2xlarge instance, which has the same number of physical CPU cores, my price would drop from $7.202 per hour to $3.868. For SQL Server Standard, the price would drop from $6.080 per hour to $2.848.
This was an R6i example. If I take an M6i instance and upgrade to an M7i, similarly, I'm upgrading M6i 2xlarge to M7i 2xlarge. It has the same number of physical CPU cores, and the Enterprise price goes from $6.657 to $3.295. For Standard, it goes from $5.096 to $2.275. As you can see, simply by making an upgrade to a newer generation instance, you can get up to 55% in cost savings. No changes are required to your application. You have the same amount of memory, the same amount of physical CPU. Simply by doing an instance upgrade, you get a lower price.
This is simply what you get by upgrading, but you can do even more. You can fine-tune your performance even further. In the previous example, even when I optimized and turned off SMT, I saw that my CPU utilization was about 20%, which meant 80% of my CPU was still not being fully utilized. In those scenarios, you can fine-tune your CPU settings with a feature called Optimize CPU.
In this case, you can set the number of active CPUs, and you can do this by turning on or turning off physical cores in the machine. In this case, I have an instance with a default number of physical cores of eight. I'm using one thread per physical core, so SMT is off, but I can change this value of eight to a lower value, such as seven or six, depending on what my application needs. And that will reduce my vCPU count, and remember, a lower vCPU count means a lower software licensing cost.
By upgrading to 7th generation instances, you can achieve significant performance improvements. If you want to fine-tune even further, you can configure optimized CPU settings and adjust them to your application to get even greater cost savings.
25% Cost Reduction with RDS for Oracle EC2 Bare Metal Instances and Session Summary
For RDS for Oracle, we have support for EC2 bare metal instances. What are EC2 bare metal instances? EC2 bare metal instances are instances that are backed by a full physical server. They bypass the hypervisor, so there's no hypervisor layer. Because there's no hypervisor, your application software directly communicates with the physical hardware. If you have a large database that uses large virtual memory instances, you can switch to using bare metal instances. It gives you the same amount of CPU and the same amount of memory, and it bypasses the hypervisor. In this example, I have an m7i.24xlarge instance with 96 vCPUs and 384 GiB of memory, and I can switch to using a metal instance, which provides the same amount of vCPUs and the same amount of memory.
Similarly, for r7i.24xlarge, a similar metal instance is available, and while the CPU and memory profiles are different, there's consistency between virtual machines and physical machines. The same applies to x2iedn instances, where large VMs and bare metal instances have the same amount of memory and the same amount of CPU. All RDS capabilities and all Oracle capabilities work exactly as they did on virtual instances. No changes to your application, and you get better performance. If you switch from large virtual machines to bare metal instances, you get a 25% cost reduction benefit by switching. So if you're running large Oracle databases on large VMs, in most cases, you'll get cost reduction benefits by switching to bare metal instances for better costs with the same application performance.
In summary, we talked about how RDS helps our customers and provides managed services for running SQL Server and Oracle. We talked about how you can use additional storage volumes to get more flexibility and cost efficiency. We talked about how you can reduce your costs using new RDS capabilities. We talked about how you can use RDS SQL Server Developer Edition for all your development and test environments. We talked about how you can use RDS SQL Server Web Edition for your web applications. In many cases, you can downgrade from SQL Server Standard Edition to SQL Server Web Edition, get the same high availability, and reduce your costs.
We talked about how for M instances, R instances, and other instance types, simply by upgrading to 7th generation instances, you can get immediate cost reductions because of optimized CPUs. And if you want to save even more costs, you can fine-tune your optimized CPU settings. And finally, we talked about how if you're using RDS for Oracle, using bare metal instances compared to large VMs can get you 25% or more in cost savings. That's all from me, but there's still time to get some swag. If you go to the Venetian, go to the expo hall in the Venetian, you can go to the database booth, and you can tell them one unique thing you learned from this session. You can tell them about how you can upgrade to new instances to reduce your costs, or you can tell them about how you can use metal instances to reduce your costs, and you can get some swag. Thank you.
- This article was automatically created using Amazon Bedrock, maintaining the information from the original video as much as possible.
Discussion