AWS Solutions Architect Associate Certification
Designing for Security
Turning up Security on Database Services Part 2
In this article, we explore Amazon RDS Aurora as an extension of the standard Amazon RDS offerings (hereafter referred to as “plain vanilla RDS”). Aurora, available in PostgreSQL and MySQL variants, also offers serverless options; however, from a security perspective, the differences are minimal.
For instance, RDS PostgreSQL (displayed on the left) employs synchronous replication across two EBS volumes. In contrast, an Aurora cluster deploys three EBS volumes (one primary and two secondaries) and manages replication at the storage layer rather than at the database level. As shown on the right, the replication is handled by the storage node. Although these methods vary, their overall impact on security remains consistent.
Aurora Architecture Quiz
Fintech startups assessing a migration to Aurora often review its architecture to take advantage of high availability and enhanced performance. Consider the following statements regarding Aurora’s architecture:
- Aurora automatically replicates data across multiple Availability Zones in a single region with two copies per zone.
(This description oversimplifies the replication process.) - Aurora uses a single master node for both reads and writes without support for read replicas.
(This is incorrect; Aurora supports up to 15 or 16 read replicas.) - Aurora divides the database volume into 10 GB segments distributed across many disks, with each segment replicated six times across three Availability Zones.
(This is the most accurate portrayal, where each 10 GB chunk is replicated six ways regardless of overall data size.) - Aurora is a serverless database service that automatically starts up, shuts down, and scales based on demand.
(While Aurora Serverless does introduce automatic scaling, it simplifies the startup and shutdown process too much.)
Clearly, statement 3 most precisely describes Aurora's architecture.
IAM Integration and Authentication Options
Aurora supports both IAM-based and native database authentication methods. It integrates seamlessly with AWS IAM and can also synchronize with AWS SSO if required.
For example, a healthcare company migrating to Aurora must secure patient data with robust authentication. Only the authentication option that supports both IAM-based and native database authentication will meet these rigorous security requirements.
Additionally, Aurora integrates efficiently with AWS Secrets Manager. For example, in a MySQL Aurora cluster deployed in the AP South 1 region with one master and replication across two zones, you can secure credentials via Secrets Manager—even if IAM-based or native database authentication is not enabled.
When developing applications (such as those by companies like Intech), it is crucial not to store sensitive data in plain text or unsecured locations such as public S3 buckets. Instead, choose AWS Secrets Manager to generate, store, and automatically rotate database credentials.
Networking and VPC Configurations
Aurora’s networking setup follows a familiar pattern seen in other RDS products: one primary writer node with multiple reader instances. These reader nodes can scale within security groups, reside in private subnets, or in some cases, be publicly accessible (though they are typically kept private). Metrics and monitoring data are primarily emitted through CloudWatch.
For healthcare companies deploying patient management systems on Aurora, isolating the database environment and safeguarding access is essential. The best practice is to deploy Aurora within a VPC, assign it to a private subnet, and restrict network access via tightly controlled security group rules that allow only specific application instances (hosted on AWS Lambda, ECS, EKS, or EC2) to connect.
Furthermore, to prevent direct internet access, it is recommended to disable public accessibility and ensure that the application servers remain in the same VPC as the Aurora database.
Aurora also supports VPC endpoints. Note that only interface endpoints are available for Aurora, as gateway endpoints are reserved for DynamoDB and S3, ensuring secure and private connectivity to other AWS services.
Monitoring, Auditing, and Encryption
Aurora provides advanced monitoring and auditing capabilities. A notable feature is Aurora Database Activity Streams, which delivers real-time database activity data for enhanced monitoring and compliance. This is particularly valuable for fintech companies subject to strict financial regulations.
In addition to activity streaming, Aurora offers encryption for data at rest and in transit. Utilizing AWS KMS, you can enable the built-in encryption features and configure SSL/TLS for database connections to maintain data integrity and confidentiality.
To ensure robust encryption:
- Enable the built-in encryption-at-rest feature.
- Configure the database to enforce SSL/TLS connections.
Note
Implementing these encryption measures ensures that sensitive data—such as patient records—is securely stored and transmitted.
Aurora Serverless and Security Considerations
Aurora Serverless delivers scalability equivalent to traditional Aurora deployments while maintaining rigorous security standards. When using Aurora Serverless, it is imperative to enable built-in encryption and enforce SSL/TLS for all connections, just as you would with non-serverless deployments.
A fintech startup opting for Aurora Serverless should adhere to the same security best practices—leveraging built-in encryption and secure connectivity—instead of employing insecure methods such as storing sensitive data in plain text.
RDS Proxy Overview and Its Security Benefits
RDS Proxy is designed to efficiently manage connections between applications and RDS databases. It helps mitigate connection overloads during sudden traffic spikes by acting as an intermediary, thereby reducing the load on the RDS instances. Additionally, RDS Proxy offers enhanced logging, caching (if enabled), and improved failover handling.
RDS Proxy has its own endpoint and security group, is deployed within a VPC, and uses the same underlying engine as the RDS instance. For example, an application may retrieve database credentials securely from AWS Secrets Manager and connect through RDS Proxy without requiring significant code changes.
Warning
Always use AWS Secrets Manager in conjunction with RDS Proxy to securely manage database credentials. Avoid insecure methods such as storing credentials in plain text or using unsupported third-party tools.
RDS Proxy employs dedicated security groups to control network traffic. By configuring these security groups to allow communication only with the associated RDS instance’s security group, you ensure restricted and authorized access.
Enhanced logging is another valuable feature of RDS Proxy. It provides detailed insights into SQL statements for debugging and auditing. However, note that enabling enhanced logging can affect system performance and typically disables automatically after 24 hours.
In summary, both Aurora and RDS Proxy deliver enhanced high-availability, scalability, and security features. By leveraging multi-AZ replication, integrated IAM and Secrets Manager support, secure VPC deployments, and advanced logging capabilities, organizations ranging from healthcare providers to fintech startups can protect their databases and maintain robust performance across varying workloads.
For further details, consider exploring related topics such as Kubernetes Basics, Kubernetes Documentation, Docker Hub, and the Terraform Registry.
Watch Video
Watch video content