AWS re:Invent 2025 - Revealing the northern lights: Amazon Aurora security deep dive (DAT456)

Securing AWS Aurora: A Deep Dive

Overview

• Presentation by Eric Branwine (VP and Distinguished Engineer, Amazon Security Team) and Andy (Principal Security Engineer, AWS Databases Team)
• Explores the security architecture and defense-in-depth approach used to protect the AWS Aurora cloud-native database service

The Challenge of Securing a Cloud Database Service

• Databases are traditionally designed as single-party systems, owned and operated by a single entity
• Transitioning databases to a multi-tenant cloud service introduces new security challenges:
  • Databases are not inherently designed as secure containers
  • Customers want deep, rich interfaces and the ability to run complex functionality
  • Customers often want to run older, unpatched versions of database engines
  • Patching and upgrading databases can be painful and disruptive

The Aurora Security Architecture

• Aurora splits the database into two components:
  1. The "head node" running the database engine (MySQL, PostgreSQL)
  2. A scalable, multi-tenant storage system
• This architecture allows Aurora to provide cloud-native benefits (scalability, availability, durability) while maintaining compatibility with existing database engines
• However, it also means the database engine itself cannot be treated as a secure container

Defense-in-Depth Approach

1. SE Linux: Enforces mandatory access control to restrict processes and resources on the Aurora head nodes
2. Chronicle: Telemetry service that monitors process execution and other system events, triggering alarms for anomalous activity
3. VPC Flow Logs: Captures network traffic to and from the Aurora head nodes, enabling analysis of connection patterns and anomalies

Protecting Against Zero-Day Vulnerabilities

• Researchers discovered a zero-day vulnerability in the PostgreSQL database engine that allowed privilege escalation
• When the researchers attempted to exploit this vulnerability against Aurora, the security controls were able to detect and block the attack, despite it being a previously unknown technique

Proactive Security Measures

1. Application Security Program: Comprehensive processes for threat modeling, risk identification, and security evaluation throughout the software development lifecycle
2. Bug Bounty Program: Collaboration with security researchers to identify and responsibly disclose vulnerabilities
3. Offensive Security Team: In-house "red team" that proactively tests the security of Aurora and other AWS services, working closely with engineers to improve defenses

Key Takeaways

• Aurora's security architecture is designed to protect the service itself, not rely on the security of the underlying database engines
• Depth of defense, telemetry, and automation are critical to detecting and responding to novel threats
• Collaboration between security and engineering teams is essential to building secure cloud services
• Proactive security measures, including bug bounties and offensive security testing, help identify and address vulnerabilities before they can be exploited

Technical Details

• SE Linux: Enforces mandatory access control to restrict processes and resources
• Chronicle: Telemetry service that monitors process execution and other system events
• VPC Flow Logs: Captures network traffic to and from the Aurora head nodes
• Application Security Program: Includes threat modeling, risk identification, and security evaluation
• Bug Bounty Program: Collaboration with security researchers to identify and disclose vulnerabilities
• Offensive Security Team: In-house "red team" that proactively tests the security of Aurora and other AWS services

Business Impact

• Enables customers to run their preferred database engines (MySQL, PostgreSQL) in a secure, cloud-native environment
• Protects against zero-day vulnerabilities and other emerging threats, even in the underlying database software
• Provides a high level of security and availability assurance for mission-critical database workloads

Example: Defending Against a Zero-Day Vulnerability

• Researchers discovered a previously unknown vulnerability in the PostgreSQL database engine that allowed privilege escalation
• When the researchers attempted to exploit this vulnerability against Aurora, the security controls were able to detect and block the attack:
  • SE Linux denied attempts to execute unauthorized code
  • Chronicle telemetry alerted the security team to anomalous activity
  • Network isolation and flow log monitoring prevented further pivoting or data access
• The security team was able to safely terminate the instance without disrupting the customer's production workloads