Category: Best Practices

Amazon DynamoDB is a fully managed, serverless NoSQL database that delivers single-digit millisecond performance for applications at any scale. DynamoDB global tables is a multi-active database feature that replicates data across AWS Regions, enabling local reads and writes. In this post, we explain why we strongly recommend all customers use the Current version for all global tables.

In this series of posts, we walk through the process of creating a DynamoDB data model using an example multi-tenant application, a customer issue tracking service. The goal of this series is to explore areas that are important for decision-making and provide insights into the influences to help you plan your data model for a multi-tenant application. In this last part of the series, we explore how to validate the chosen data model from both a performance and a security perspective. Additionally, we cover how to extend the data model as new access patterns and requirements arise.

In this series of posts, we walk through the process of creating a DynamoDB data model using an example multi-tenant application, a customer issue tracking service. The goal of this series is to explore areas that are important for decision-making and provide insights into the influences to help you plan your data model for a multi-tenant application. In this post, we continue the design process, selecting a partition key design and creating our data schema. We also show how to implement the access patterns using the AWS Command Line Interface (AWS CLI).

In this series of posts, we walk through the process of creating a DynamoDB data model using an example multi-tenant application, a customer issue tracking service. The goal of this series is to explore areas that are important for decision-making and provide insights into the influences to help you plan your data model for a multi-tenant application. In this post, we define the access patterns and decide on the table design.

In this post, we present proactive measures for optimizing AWS DMS implementations from the initial setup phase. By using strategic planning and architectural foresight, organizations can enhance their replication system’s reliability, improve performance, and avoid common pitfalls.

Authorization systems are a critical component of modern applications, yet traditional approaches like role-based access control (RBAC) and attribute-based access control (ABAC) struggle to meet the complex access control requirements of today’s enterprises. In this post, we introduce a relationship-based access control (ReBAC) as an alternative for enterprise scale authorization. We explore how the proposed […]

When getting started with DynamoDB, one of the first decisions you will make is choosing between two throughput modes: on-demand and provisioned. On-demand mode is the default and recommended throughput option because it simplifies building modern, serverless applications that can start small and scale to millions of requests per second. However, choosing the right throughput strategy requires evaluating your operational needs, development velocity, and application characteristics, with cost being a key consideration. In this post, we examine both throughput modes in detail, exploring their characteristics, strengths, and ideal use cases.

When you decide to upgrade your PostgreSQL database which is configured as source or target for an ongoing AWS DMS task, it’s important to factor this into your upgrade planning. In this post, we discuss the best practices to handle the AWS DMS tasks during PostgreSQL upgrades to minor or major versions.

In this post, we highlight often overlooked architectural designs and the inherent features of Aurora that optimize costs when deploying an open source database. The following sections examine various use cases, contrasting typical self-managed database configurations and their associated costs with the equivalent solution on Aurora, highlighting potential cost savings and operational efficiencies.

In this post, we show you a worked example of taking an existing application that works on PostgreSQL databases and adapting it to work with an Aurora DSQL database. In addition to adapting for the previously mentioned aspects, we also address some data type incompatibilities and work around some limits that currently exist in Aurora DSQL.