What's New in Amazon RDS for Open-Source & Commercial Databases
•
2 likes•833 views
by Kwesi Edwards, Business Development Manager, AWS
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to What's New in Amazon RDS for Open-Source & Commercial Databases
Similar to What's New in Amazon RDS for Open-Source & Commercial Databases (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (19)
What's New in Amazon RDS for Open-Source & Commercial Databases
- 1. Kwesi Edwards, Platform Business Development Manager Amazon Web Services, RDS RDS OverviewRDS Overview
- 2. Agenda • Why a Managed Database Platform • Relational Database Services Overview • RDS Features • RDS Commercial Engines • Summary/Q&A
- 3. Deployment Options On-Premises Hosted Managed EC2 DB Services
- 5. Why Managed Databases? Reduce Effort Risk Cost On-Premises Hosted Managed
- 6. Where do DBAs spend their time? Application Optmization Installation, Upgrades, and Patching Backup and Recovery, Data Import and Export, Licensing, Training, Security 8
- 7. Analyst Update Hot off the Presses! Key Findings • AWS is positioned as the top Leader in this evaluation top scores in all three categories – Current Offering, Strategy and Market Presence. • AWS has the broadest range of databases and the largest adoption. It also offers the widest range of offerings to support analytical, operational, and transactional workloads.
- 8. Customers succeeding with Amazon RDS
- 9. Amazon RDS Amazon DynamoDB Amazon Redshift Amazon ElastiCache Compute Storage AWS Global Infrastructure Database Application Services Deployment & Administration Networking AWS Database Services
- 10. RDS Managed Database Vision We make it easy to set up, operate, and scale relational databases in the cloud so customers can focus on application optimization. Higher bar on security, durability and availability than what’s available on-premises or on EC2 or any other cloud provider. Customers can choose the database that is right for them: Amazon Aurora, MySQL, MariaDB, PostgreSQL, Oracle, SQL Server. Tiny databases on small CPUs to enterprise-class databases on enterprise hardware. We work to save our customers money through elasticity and operational efficiencies.
- 11. Amazon RDS engines Commercial Open source Cloud native MySQL Compatible PostgreSQL Compatible Amazon Aurora
- 12. Server purchase and install hardware deploy stack (OS, database) Storage provision and configure Database provision and configure patch, upgrade, backup, monitor and scale Manual Partially Automated Fully Automated On-Premises Hosted Managed
- 13. If you host your databases on-premises Power, HVAC, net Rack & stack Server maintenance OS patches DB s/w patches Database backups Scaling High availability DB s/w installs OS installation you App optimization
- 14. If you host your databases in EC2 Power, HVAC, net Rack & stack Server maintenance OS patches DB s/w patches Database backups Scaling High availability DB s/w installs OS installation you App optimization
- 15. If you choose a managed DB service Power, HVAC, net Rack & stack Server maintenance OS patches DB s/w patches Database backups App optimization High availability DB s/w installs OS installation you Scaling
- 16. • Highly Available • Durable, PITR, Snapshots • Scalable • Secure & Compliant Encryption in transit and at rest TDE with Oracle Database and SQL Server Compliance realms • Integration across AWS • ... And A lot more RDS Key Features
- 17. Availability Zone A AWS Region 10.1.0.0/16 10.1.1.0/24 Availability Zone B 10.1.2.0/24 Synchronous Replication M S Single Availability Zone Configuration HA Multi Availability Zone Configuration
- 18. Cross Region Read Replicas • Bring data close to your customer’s applications in different regions • Relieve pressure on your master node for supporting reads and writes • Promote a Read Replica to a master for faster recovery in the event of disaster Within or cross-region • MySQL • MariaDB • PostgreSQL • Aurora
- 19. Automated Backups • MySQL, PostgreSQL, MariaDB, Oracle, SQL Server • Scheduled daily volume backup of entire instance • Archive database change logs • 35-day retention • Multiple copies in each AZ when running multi-AZ • Taken from standby when running multi-AZ • Aurora • Automatic, continuous, incremental backups • No impact on database performance • 35-day retention Every day during your backup window, the RDS service creates a storage volume snapshot of your database Every five minutes, RDS backs up the transaction logs of your database If database is Multi-AZ, the snapshot is taken from the standby • Single AZ deployment = multiple backup copies in one AZ • Multi AZ deployment = multiple backup copies in multiple AZs
- 20. Scaling Instances Up/Down AWS Management Console
- 21. Compliance Details Aurora • SOC 1, 2, 3 • ISO 20001/9001 • ISO 27107/27018 • PCI • HIPAA BAA MySQL • SOC 1, 2, 3 • ISO 20001/9001 • ISO 27107/27018 • PCI • FedRamp • HIPAA BAA • UK Gov. Programs • Singapore MTCS Oracle • SOC 1, 2, 3 • ISO 20001/9001 • ISO 27107/27018 • PCI • FedRamp • HIPAA BAA • UK Gov. Programs • Singapore MTCSMariaDB SOC 1, 2, 3 ISO 20001/9001 ISO 27107/27018 PCI PostgreSQL SOC 1, 2, 3 ISO 20001/9001 ISO 27107/27018 PCI UK Gov. Programs Singapore MTCS HIPAA BAA SQL Server SOC 1, 2, 3 ISO 20001/9001 ISO 27107/27018 PCI UK Gov. Programs Singapore MTCS https://aws.amazon.com/compliance/
- 22. Encryption at Rest with KMS • Two-tiered key hierarchy using envelope encryption • Unique data key encrypts customer data • AWS KMS master keys encrypt data keys • Available for all RDS engines • Benefits • Limits risk of compromised data key • Better performance for encrypting large data • Easier to manage small number of master keys than millions of data keys • Centralized access and audit of key activity Data key 1 Data key 2 Data key 3 Data key 4 Custom applications Amazon RDS instance 3 Amazon RDS instance 2 Amazon RDS instance 1 Customer master key(s)
- 23. Shweta Shrivastava Sr. Manager, Product Management, AWS RDS April 2017 Amazon Web Services Confidential - Shared under NDA What’s NewWhat’s New
- 24. Platform Features : What’s New • Encryption at Rest: data encryption using customer managed keys • Operating System Monitoring • Access to 57 OS-level metrics down to 1 second-granularity • All 6 RDS engines • Share database snapshots between accounts • M4 instance types: balanced compute, memory, and network resources, EBS optimized (40 virtual cores, 160 Gib) • Local time-zone support
- 25. RDS Platform Features: What’s New • New Instance Types • EBS Improvements • Instance Stop/Start
- 26. Launched in 2016: RDS Enhanced OS Monitoring • See inside your RDS instance • 57 OS metrics, up to 1/second • Free to use within CloudWatch Logs free tier for most users • Turn it on or off at any time • 3rd party integration
- 27. Enhanced RDS Monitoring with Datadog • Datadog is an infrastructure monitoring platform popular with AWS customers • Provides historical trends with full granularity, visualizations and alerts on live data • RDS MySQL metrics populate a pre-built, customizable dashboard
- 28. RDS Performance Insights – Preview Now, Available soon Amazon Performance Insights for RDS Database Load : Identifies bottlenecks Easy Powerful Identifies source of bottlenecks Top SQL Adjustable Time frame Hour, day, week and longer Max CPU
- 29. RDS PostgreSQL: What’s new • HIPAA BAA Eligible • The Federal Risk and Authorization Management Program (FedRAMP) • Allows RDS for US agencies that must meet FedRAMP regulations • Region: GovCloud • PostgreSQL 9.6.1 support • PostgreSQL CDC with Database Migration Service • Region: All Regions
- 30. MySQL and MariaDB: What’s New • One-Click Migration from MySQL to MariaDB • Manage access to your RDS for MySQL and Amazon Aurora databases using AWS IAM • Read Replicas of Encrypted Database Instances across Regions
- 31. Shweta Shrivastava Sr. Manager, Product Management, AWS RDS April 2017 Amazon Web Services Confidential - Shared under NDA Commercial EnginesCommercial Engines
- 32. Why Use RDS for Commercial Engines • Same as on premise - Dedicated Instances • Speed of provisioning, Secure, Fully Managed RDS experience • Single-click HA, Auto Scaling • Flexible Licensing models • BYOL (Bring-Your-Own-License) • LI (License Included) • SQL Server Express, Web, Standard & Enterprise editions supported – INCLUDING 2014 and 2016. • Oracle Standard and Enterprise Editions. • Broad set of Engine features supported
- 33. • Support for Siebel CRM applications– • Best Practices Configuration Guide for PeopleSoft • JD Edwards Best Practices • Support for Oracle Enterprise Manager– • Support for Standard Edition 2 License Included– • Outbound Network Access–Support for Oracle Email Utility • Support for Oracle Label Security Option Recently Launched Features – RDS Oracle
- 34. • RDS for SQL Server Native Backup/Restore Support • Local time zone support • Support for SQL Server 2016– • RDS for SQL Server Windows Authentication Support– • RDS for SQL Server Enhanced Monitoring Support • Support for Forced SSL Recently Launched Features – RDS SQL Server
- 35. RDS for SQL Server: Windows Authentication What you need to do
- 36. RDS for SQL Server Native Backup/Restore • RDS for SQL Server Native Backup/Restore (.bak file) support • Leverages the native SQL Server Backup/Restore functionality • Allows customers to save their .bak files to their Amazon S3 buckets • Can be used to restore on premise SQL Server backups to an RDS Instance • Database level operations • To enable Native/Backup restore on your RDS for SQL Server instance • Create a new Amazon S3 bucket or use an existing one • Create an AWS IAM role to grant RDS access to your S3 bucket or a folder in it • Attach the IAM role to your RDS for SQL Server instance using Option Groups • Use SQL Server Management Studio to call stored procedures that expose .bak .bak .bak
- 37. Shweta Shrivastava Sr. Manager, Product Management, AWS RDS April 2017 Summary and Q&ASummary and Q&A
- 38. Summary • Why a Managed Database Platform • Relational Database Services Overview • RDS Features • RDS Commercial Engines • Summary/Q&A
Editor's Notes
- Handle higher load or lower usage Naturally grow over time Control costs
- 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.
- 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.
- 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.
- 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
- 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.
- 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
- * 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.
- 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.
- Maintenance opt-in
- 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
- 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
- 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.
- 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.
- We support encryption for backup files immaterial of the license type.
- Handle higher load or lower usage Naturally grow over time Control costs