AWS Database Blog
Resolve to follow Amazon DynamoDB best practices in 2019
We recommend that you follow Amazon DynamoDB best practices in 2019 to help you maximize the performance and optimize the costs of your mission-critical workloads when working with DynamoDB. This post highlights DynamoDB content that will help you keep such a resolution. Design and use partition keys effectively The primary key that uniquely identifies each […]
The top 20 most-viewed Amazon DynamoDB documentation pages in 2018
The following 20 pages were the most viewed Amazon DynamoDB documentation pages in 2018. I have included a brief description with each link to explain what each page covers. Use this list to see what other AWS customers have been viewing and perhaps to pique your own interest in a topic you’ve been meaning to explore. […]
Another Database Migration Playbook goes live—migrate from Microsoft SQL Server to Amazon Aurora MySQL!
We’re excited to present the first edition of the Microsoft SQL Server to Amazon Aurora MySQL Compatibility Migration Playbook. AWS Database Migration Service (AWS DMS) and AWS Schema Conversion Tool (AWS SCT) help you reduce the effort associated with migration from commercial engines to open-source and Amazon-managed databases. Thus, they help reduce cost and avoid […]
Monitor your Microsoft SQL Server using custom metrics with Amazon CloudWatch and AWS Systems Manager
In this blog post, we show you how to configure the CloudWatch agent on Amazon EC2 Windows instances to capture custom metrics for SQL Server from Windows performance monitor. We also show you how to publish those custom metrics and monitor them on Amazon CloudWatch console. We also walk you through on how to store custom configuration in AWS Systems Manager Parameter Store used by CloudWatch agent to capture those metrics and reuse the same configuration across multiple fleets of SQL Server instances where similar kind of metrics are needed.
Best practices for securing sensitive data in AWS data stores
This blog post focuses on general data security patterns and corresponding AWS security controls that protect your data. Although I mention Amazon RDS and DynamoDB in this post, I plan to cover the implementation-specific details related to Amazon RDS and DynamoDB in two subsequent posts.
Amazon RDS Under the Hood: Single-AZ instance recovery
This post describes Amazon RDS Single-AZ RTO and RPO expectations for MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server databases. Amazon Aurora uses a different technology and storage subsystem designed for the cloud. Its single instance recovery process and scenarios are described in the Aurora FAQ.
How to use Amazon DynamoDB global tables to power multiregion architectures
More and more, AWS customers want to make their applications available to globally dispersed users by deploying their application in multiple AWS Regions. These global users expect fast application performance. In this post, I describe how to use Amazon DynamoDB to power the database of a global backend deployed in multiple AWS Regions. I use […]
Analyze user behavior using Amazon Elasticsearch Service, Amazon Kinesis Data Firehose and Kibana
September 8, 2021: Amazon Elasticsearch Service has been renamed to Amazon OpenSearch Service. See details. February 9, 2024: Amazon Kinesis Data Firehose has been renamed to Amazon Data Firehose. Read the AWS What’s New post to learn more. Let’s assume that you work for an ecommerce company and you want to provide the best user […]
How to use DynamoDB global secondary indexes to improve query performance and reduce costs
In this post, I demonstrate several ways to use global secondary indexes to query your data, accelerate your application’s performance, and reduce your monthly DynamoDB bill.
Intuit story: Automate migration from on-premises MySQL to Amazon Aurora
Databases are core to many of our applications at Intuit. The database team has been working out which architecture to standardize on and what run books and tools to build in order to migrate and then operate in the cloud. We realized that the fastest way to resolve our questions would be to take one of our existing on-premises applications and run it through an actual migration to Amazon Aurora.









