Category: Security, Identity, & Compliance

In this post, you will learn how to integrate Okta with AWS IAM Identity Center and implement Amazon Relational Database Service (Amazon RDS) AWS Identity and Access Management (AWS IAM) authentication to create a unified authentication flow. You configure attribute-based access control (ABAC) that automatically maps user identities from your IdP to database permissions, supporting interactive user sessions and helping you avoid shared accounts. By the end, you have a working system where database authentication works exactly like your application authentication.

In this post, we show you how to build a multi-Region Kerberos authentication system that matches your Aurora Global Database’s resilience using AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) with multi-Region replication and a one-way forest trust to your on-premises Active Directory, so your Linux clients can authenticate without joining the AD domain.

In this post, we review the options for changing the AWS KMS key on your Amazon RDS database instances and on your Amazon RDS and Aurora clusters. We start with the most common approach, which is the snapshot method, and then we include additional options to consider when performing this change on production instances and clusters that can mitigate downtime. Each of the approaches mentioned in this post can be used for cross-account or cross-Region sharing of the instance’s data while migrating it to a new AWS KMS key.

In this post, we demonstrate how to configure IAM database authentication in AWS Database Migration Service (AWS DMS). You’ll also learn the structured troubleshooting approach you follow to address the errors when configuring IAM database authentication with AWS DMS

AWS Organizations now supports an upgrade rollout policy, a new capability that provides a streamlined solution for managing automatic minor version upgrades across your database fleet. This feature supports Amazon Aurora MySQL-Compatible Edition and Amazon Aurora PostgreSQL-Compatible Edition and Amazon RDS database engines MySQL, PostgreSQL, MariaDB, SQL Server, Oracle, and Db2. It eliminates the operational overhead of coordinating upgrades across hundreds of resources and accounts while validating changes in less critical environments before reaching production. In this post, we explore how upgrade rollout policy works, its key benefits, and how you can use it to implement a systematic approach to database maintenance across your organization.

You can access an Amazon Aurora DSQL cluster by using a public endpoint and AWS PrivateLink endpoints. In this post, we demonstrate how to control access to your Aurora DSQL cluster by using public endpoints and private VPC endpoints through PrivateLink, both from inside and outside AWS.

For encrypting data at rest, Amazon RDS for Oracle offers two choices: AWS KMS and Oracle TDE. Although both AWS KMS and Oracle TDE provide encryption at rest capabilities, there are various factors to consider when choosing between them, such as licensing, edition dependency, encryption granularity, and feature restrictions. In this post, we provide guidance on choosing between the AWS KMS and Oracle TDE options for encrypting data at rest in RDS for Oracle, focusing on these key aspects.

When using Secrets Manager to manage your master user passwords, you cannot create new read replicas for your database instance. This applies to all DB engines except Amazon RDS for SQL Server, potentially impacting your organization’s ability to efficiently scale its read operations while maintaining secure credential practices. In this post, we present a solution that automates the process of rotating passwords for a primary instance with read replicas while maintaining secure credential management practices. This approach allows you to take advantage of the benefits of both read scaling and automated credential rotation.

Many organizations rely on Windows Authentication and Kerberos for secure access to their SQL Server databases. When using Amazon RDS for SQL Server with a self-managed Active Directory, organizations can enhance their authentication beyond the default NTLM protocol to support Kerberos authentication. In this post, we show you how to manually configure and maintain Kerberos authentication for Amazon RDS for SQL Server DB instances joined to a self-managed Active Directory. We walk through the process of configuring service principal names (SPNs), adding necessary user principal name (UPN) suffixes, and automating SPN updates to handle failovers and host replacements.

With Amazon RDS for Db2, you can seamlessly authenticate your users and groups with or without Kerberos authentication using a single AWS Microsoft AD directory that can serve multiple accounts. In this post, we use AWS Managed Microsoft AD from an AWS account to provide Microsoft AD authentication to Amazon RDS for Db2 in a different account.