What's New in Amazon RDS for Open-Source & Commercial Databases

Editor's Notes

1. Handle higher load or lower usage Naturally grow over time Control costs
2. There are lots of different choices for your database engine on RDS. Each of these engines operate differently, offer different functionality, and have different licensing requirements. Everyone has their favorite engine and they use them for specific purposes. On the commercial side we have Oracle and Microsoft SQL Server On the open source side we have MySQL, PostgreSQL, and MariaDB And in its own category we have Amazon Aurora which is a My SQL compatible relational database built to take advantage of many of the properties that exist with modern cloud computing. Relational databases have existed … but standard relational technology is not the best fit for cloud platforms – hence Aurora – we also kept in mind opensource and compatibility, easy for customers to mograte – hence MySQL and now Postgres compatibility -------- MariaDB - https://en.wikipedia.org/wiki/MariaDB MariaDB – Fork of the MySQL database. Led by the original developers of MySQL after concerns when it was acquired by Oracle and that the project might become a closed project. Works to maintain high compatibly with MySQL. Also has features to support non-blocking operations and progress reporting.
3. All the time that’s freed up by offloading undifferentiated labor to AWS can be used to do the app optimizations you always wanted to have time to do.
4. Talk about how to configure a single az rds instance in a VPC. RDS Multi-AZ deployments provide enhanced availability and durability for Database (DB) Instances, making them a natural fit for production database workloads. When you create a multi-az rds instances or modify your single az DB Instance to run as a Multi-AZ deployment, RDS automatically provisions and maintains a synchronous “standby” replica in a different Availability Zone. Updates to your DB Instance are synchronously replicated across Availability Zones to the standby in order to keep both in sync and protect your latest database updates against DB Instance failure. In the event of planned database maintenance, DB Instance failure, or an Availability Zone failure, Amazon RDS will automatically failover to the standby so that database operations can resume quickly without administrative intervention. Multi-AZ deployments utilize synchronous replication, making database writes concurrently on both the primary and standby so that the standby will be up-to-date in the event a failover occurs. While the Multi-AZ DB Instance implementation maximizes data durability in failure scenarios, it does not allow the standby from being accessed directly or used for read operations. * Call out that you can modify your environment from single AZ to multi-AZ.
5. Amazon RDS provides two distinct replication options to serve different purposes. We discussed multi-AZ configurations. The second option is read replicas When your master database becomes overloaded in trying to handle read and write requests you can either try and scale the master itself or you can take the path of adding read replicas to handle the read workload. To help you to scale beyond the capacity constraints of a single DB Instance for read-heavy database workloads, Amazon RDS offers Read Replicas. You can create a Read Replica of a given source DB Instance using the AWS Management Console, the RDS API, or the AWS Command Line Interface. Once the Read Replica is created, database updates on the source DB Instance will be propagated to the Read Replica. You can create multiple Read Replicas for a given source DB Instance and distribute your application’s read traffic amongst them. Read Replicas are supported by Amazon RDS for MySQL, PostgreSQL, MariaDB and Aurora. Unlike Multi-AZ deployments, Read Replicas for these engines use each's built-in replication technology and are subject to its strengths and limitations. In particular, updates are applied to your Read Replica(s) after they occur on the source DB Instance (“asynchronous” replication), and replication lag can vary significantly. This means recent database updates made to a standard (non Multi-AZ) source DB Instance may not be present on associated Read Replicas in the event of an unplanned outage on the source DB Instance. As such, Read Replicas do not offer the same data durability benefits as Multi-AZ deployments. While Read Replicas can provide some read availability benefits, they and are not designed to improve write availability. You can use Multi-AZ deployments and Read Replicas in conjunction to enjoy the complementary benefits of each. You can simply specify that a given Multi-AZ deployment is the source DB Instance for your Read Replica(s). That way you gain both the data durability and availability benefits of Multi-AZ deployments and the read scaling benefits of Read Replicas. With RDS read replicas do a couple of things. First they allow you to create read only copies of your master database that are kept in synch with your master database. You can then point your read queries from your applications or end users at these read replicas helping to keep the read workload on your master database low. Depending on the database engine you can also place your read replica in a different region from your master which may give you the ability to have a read closer to a particular locality. Finally, read replicas give you the ability to have another avenue for failover when there is a problem with the master, giving you the ability to have coverage in the event of a disaster. ----------- Benefits Offload reads that would normally happen against your master database, allowing the master database to be able to focus on serving up writes and maintaining the integrity of the transactions in your database. Support read intensive applications for specific business units Promote read replica to your production database in the case of failure ** *More on this one – Have to figure out how to tie this one in with High Availability
6. Let’s start with backups. When it comes to backups with RDS you get one scheduled backup a day. You can choose what time window is appropriate for you in regards to your backup window. Along with this, since this is a managed service, you get all the monitoring of the backup job to make sure that it completed successfully and that it is executing on time. Making sure that backups are happening can be a big operational burden if you are doing this on your own. For MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server these backups are of your entire instance and your transaction logs. You get to choose how long you want your backups to be retained up to 35 days. In order to ensure durability and availability of your backups the service keeps multiple copies of your backup in each Availability Zone where you have an instance deployed. During the automatic backup window, storage I/O might be briefly suspended while the backup process initializes (typically under a few seconds) and you might experience a brief period of elevated latency. No I/O suspension occurs for Multi-AZ DB deployments, because the backup is taken from the standby. When it comes to Aurora things are a little different for backups With Aurora you do not schedule backups because everything is automatically backed up continuously to the storage environment of Aurora Just like with the other engines you can configure your automatic backup retention period up to thirty-five days. With Aurora your backups are stored in S3 so you get the benefit of S3’s availability and durability. With Aurora these backups give no Impact on database performance. *** Need to call out why. Is this because the storage is de-coupled from the database entirely? Backup retention period. - You don’t pay extra for using the 35 day backup retention so why not take advantage of it. Keeping a longer backup retention gives you greater possibility of being able to recover or restore, even when you do not think that you need it.
7. Compute scaling in Aurora is by creating a new read replica, and do a failover - can be done in 10-15 seconds versus a host replacement type operations which is a few minutes Aurora storage volume is 10GB and we do auto scaling, Let’s take some time to dive deeper into a particular use case around scaling the database master instance. Here is a quick example of what it would take to scale your RDS database instance up or down. Here we have screen shots of what you do when you want to change the instance size. Choose the Modify option from the Instance Actions menu of the RDS console. Then choose what you want your new DB Instance Class to be. Finally, determine if you want to apply the change immediately or not. If you do not apply the change immediately then the change will be scheduled to occur during the preferred maintenance window that you defined when creating the database. Keep in mind that when you are applying the change immediately you could incur some downtime as the instance size is changed so be aware of what your applications that are accessing the database can tolerate in regards to downtime. http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html
8. * Here is a listing of our compliance certifications and which database engines they currently apply to on RDS. You can see here that we have a wide range of certifications covering MySQL, Oracle, SQL Server, and PostgreSQL. As you can see there is a lot of coverage among these four different engines around key areas of compliance.
9. KMS is managed service Scaleability, Reliability, Durability, Security, Key deletion, Key creation, Key rotation You get to focus on your application and integrating with the service. For RDS you get an extra layer of protection around access to the underlying storage Encryption uses industry standard AES-256 encryption to protect the data. How you enable encryption for RDS CloudTrail integration Not only encrypting the DB Instance Storage but also… Automated Backups Read Replicas Snapshots Available for all six engines at no additional cost -------------------- So here is how RDS provides you the ability to encrypt your data. It is done using the AWS Key Management Service (KMS) KMS is a managed service that provides you the ability to create and manage encryption keys and then encrypt and decrypt your data with those keys. All of these keys are tied to your own AWS account and are fully managed by you. KMS takes care of all the availability, scaling, security, and durability that you would normally have to deal with when implementing your own key store. With KMS performing these management tasks it allows you the ability to focus on using the keys and building out your application. On top of all this the KMS team has also focused on making all of this very easy for you to use. Specific to RDS KMS gives you an additional layer of protection to guard against un-authorized access to the underlying storage of your RDS instance. For the data encryption KMS uses industry standard AES-256 encryption to protect the data that is stored on the underlying host that your RDS instance is running on. A little bit on how this works. We are using a two key hierarchy for encrypting data on your RDS instance. When you are launching an RDS instance you can choose to make the database encrypted. If you do nothing else besides turning on encryption this will result in an AWS managed key for RDS being created or the existing RDS customer master key will be used. This is good if you just want encryption and don’t want to think about anything else related to the key. Once this key is created it can only be used for RDS encryption and not with any other AWS service so you right away have scoped down the use of the key If you want you can create your own customer master key within KMS and then reference that key when you are creating your RDS instance. When you go the approach of creating your own key you get much more control over the use of that key such as when it is enabled or disabled, when the key is rotated, and what the access policies are for the key. Whatever your approach for the master key these keys cannot leave the service. You cannot export a plaintext version of that key out of the service. All you can do is ask that encrypt and decrypt operations happen against that key. When RDS wants to encrypt data on the instance it will make a call to KMS using the necessary credentials. KMS will then give RDS a data key that is actually used to encrypt the data on that instance. This data key is encrypted using the master key that was created when you launched the instance or that you created and specified for use during the instance creation. This data key is specific to that RDS instance and will not be used with another RDS instance. Without the presence and access to this data key the data within RDS is useless to someone accessing it throughout the normal path. So with this you have an overall master key that is then vending out data keys for each instance that you choose to encrypt. ------- Some of the benefits of using this service. Encryption and decryption are handled transparently so you don’t have to modify your application to access your data. Limited risks of a compromised data key Better performance for encrypting large data sets and there is no performance penalty for using KMS encryption with your RDS instance. You only have to manage a few master keys and not many data keys You get centralized access and audit of key activity via cloudtrail so that you can see every time a key is accessed in used from your KMS configuration. -------- Talk about why you should trust AWS with your keys There are no tools in place to access your physical key material. Your plaintext keys are never stored in nonvolatile memory. You control who has permissions to use your keys. Separation of duties between systems that use master keys and ones that use data keys. Multiparty controls for all maintenance of KMS systems that use your master keys. Third-party evidence of these controls: Service Organization Control (SOC 1) PCI-DSS See AWS Compliance packages for details ---- Enhance this slide to show some different RDS clusters each with a different data key.
10. Maintenance opt-in
11. Talk Track: Together with the new edition of Amazon Aurora we are also announcing a new database monitoring feature called Performance Insights.  Performance Insights is designed to help customers quickly assess whether there are any performance bottlenecks in their relational database workloads and where to take action. Performance Insights collects detailed database performance data through light weight mechanisms and uses the data to drive an intuitive graphical interface that provides a simple and complete view of recent database performance. For questions: Roadmap: will be rolling out incrementally to all RDS engines over 2017 First release will be on Postgres compatible edition of Aurora followed by the MySQL compatible version of Aurora in Q2. Q2 will introduce support for Mysql, MariaDB and Postgres Q3 will introduce support for SQL Server and Oracle See the preview in the demo grounds Feature is free. Will be supported on all instances except micros Feature will keep 35 days of historical data
12. Key features – Windows Auth, .bak support, LTZ support, SSIS/SSRS/SSAS on EC2 connected to RDS, TDE, Database Rename, TempDB configurations, Linked Servers in limited VPC and IP based configurations, Full text search, SSL, change tracking enablement ------------- Same as on premise - Dedicated Instances. Not true multi-tenanted with other customers. Single click HA – MultiAZ Autoscaling – Not on SQL Server Ease of migration – DMS .bak GG
13. OEM – Single pane of glass Major version of upgrade – Oracle Email Utility – sends outbound email from database in RDS; some old school applications that need this For customers who are using this capabiity built into the database, they can move to AWS without refactoring the app OLS – Mostly in Government but not so much outside it.
14. Bring on premise credentials to the cloud securely. Build a one-way Trust between the AWS Directory instance and the on-premise instance. Establishing a trust between on-remise domain and cloud domain. After you setup the forest trust, you can create logins from your on-premise directory just as you do today.
15. We support encryption for backup files immaterial of the license type.
16. Handle higher load or lower usage Naturally grow over time Control costs