Lazy but Cautious: AWS Cloudformation RDS Aurora Cluster + DB Instance Template
New to RDS and looking to learn how to provision a secure RDS Aurora DB cluster? A “lazy” cloud platform developer looking to save your time and effort? Simply hunting for answers on Google?
How is this Medium blog different from any other?
The idea is to highlight the best practices to keep in mind when developing AWS infrastructure as code. In this case, it’s RDS. The practice of keeping cloud security in mind when developing makes you not only a good developer, but is central to the concept of zero trust architectures in AWS, at the very least. So go ahead, read on!
Additional reading material if you’re curious: Best Practices for Amazon RDS
A (slightly elaborate) introduction:
Relational Database Service (RDS) is AWS’s relational database service that offers a variety of databases on demand, with various instance sizes to choose from, depending on your application’s needs.
Amazon Aurora (Aurora) is a fully managed relational database engine that’s compatible with MySQL and PostgreSQL. With certain workloads, Aurora can deliver up to 5X the throughput of MySQL and up to 3X the throughput of PostgreSQL.
Assuming you already know the storage, memory and network configurations (the VPC, the subnets, ports to be opened or used by the DB), keep scrolling ahead.
What concepts you need to know before you provision a simple RDS Aurora DB cluster:
1. DB Instance
A DB instance is an isolated database environment running in the cloud. It can contain multiple user-created databases, and can be accessed using the same client tools and applications you might use to access a standalone database instance. ~~ AWS Documentation
Points to remember: A DB instance allows you to create multiple databases in it, and can be accessed just like you would any other database you usually do.
2. DB Parameter Group
A DB parameter group acts as a container for engine configuration values that are applied to one or more DB instances. If you create a DB instance without specifying a DB parameter group, the DB instance uses a default DB parameter group. ~~ AWS Documentation
Points to remember: Figure out if there are customized parameters you need for your database. Otherwise, stick to the default. FYI, you cannot alter the default parameter group settings, so be careful.
3. DB Cluster
A DB cluster consists of one or more Aurora DB instances and a cluster volume that manages the data for those DB instances.
Points to remember: A cluster is useful when you are managing multiple database instances. Yes, DB clusters are specific to Aurora for now.
4. DB Cluster Parameter Group
A DB cluster parameter group acts as a container for engine configuration values that are applied to every DB instance in an Aurora DB cluster. If you create an Aurora DB cluster without specifying a DB cluster parameter group, the DB cluster uses a default DB cluster parameter group. ~~ AWS Documentation
Points to remember: Figure out if there are customized parameters you need for your Aurora DB cluster. Otherwise, stick to the default. FYI, you cannot alter the default cluster parameter group settings, so be careful.
5. DB Subnet Group
A DB subnet group is a collection of subnets (that you create in a VPC) and that you then designate for your DB instances.
You can only create an Amazon Aurora DB cluster in a VPC in a region that has at least 2 Availability Zones (AZs). The DB subnet group that you choose for the DB cluster must cover at least two Availability Zones. This configuration ensures that your DB cluster always has at least one DB instance available for failover, in the unlikely event of an AZ failure. ~~ AWS Documentation
Points to remember: Create a VPC with subnets in at least 2 AZs before you begin. Create a DB subnet group with these subnets added to it. Keep the subnets private typically.
6. Security Group
Security groups control the access that traffic has in and out of a DB instance. By default, network access is disabled for a DB instance. You can specify rules in a security group that allow access from an IP address range, port, or security group. Once ingress rules are configured, the same rules apply to all DB instances that are associated with that security group. You can specify up to 20 rules in a security group. ~~ AWS Documentation
Points to remember: Be EXTREMELY careful of the ingress rules. Allow access to specific CIDR blocks to specific ports only.
7. High Availability (Multi-AZ)
In a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different AZ. The primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy, eliminate I/O freezes, and minimize latency spikes during system backups. ~~ AWS Documentation
Points to remember: Primary in one AZ, synchronous replication, standby replica in another AZ. Implication: Provides high availability in case of an AZ failure.
Basic Security Concepts for RDS
In the world we live in, building security into your code CANNOT be an afterthought. So always keep security in mind when developing infrastructure resources.
Here are some basic tips to keep in mind:
- Keep your RDS instances in private subnets.
Most typical use cases for needing a database end up having to store sensitive information that the world should definitely not have access to. I needn’t tell you about what potential losses can occur if sensitive data is stolen or lost. So, keep your RDS DB instances in private subnets.
- Uncheck the Publicly Accessible option when creating your DB instance.
Unless absolutely necessary for you to expose your database to the internet, uncheck that option.
- Enable Encryption at rest for your DB instance.
You can encrypt your Amazon RDS DB instances and snapshots at rest by enabling the encryption option for your Amazon RDS DB instances. Data that is encrypted at rest includes the underlying storage for DB instances, its automated backups, read replicas, and snapshots.
- Avoid using the master user in your applications.
AWS strongly recommends that you do not use the master user directly in your applications. Instead, create and use a database user with the minimal privileges required for your application.
- Create an IAM role/user with minimal privileges for Amazon RDS.
Don’t use AWS root credentials to manage Amazon RDS resources. Minimal privileges can reduce the chances of someone mishandling your database and affecting your application, knowingly or unknowingly. Use an IAM role/user to connect to your database.
- Store your RDS credentials in a secrets management system.
It is a general best practice to store your RDS credentials, especially the master username and password in a secrets management system like AWS Systems Manager’s Parameter Store/AWS Secrets Manager/Hashicorp Vault, depending on your need or architecture. Reference them appropriately in your application!
Coming to the actual code!
Public gist so you can very well just Ctrl + C (or Cmd + C) and Ctrl + V (or Cmd +v) your way.
Although the basic security concepts covered above will get you by, but for additional reading, about enhanced logging and monitoring, go ahead and read the AWS documentation!
Keep checking out the next parts in this series! Thanks for reading!