RDS MySQL / PostgreSQL

Amazon RDS is AWS’s managed relational database service. ZopDay creates an RDS instance as a MySQL or PostgreSQL job. It works in AWS with the cloud account you connected, and the job page shows each step as it runs.

What steps does ZopDay run to create an RDS database

An RDS job creates the subnet and security groups, creates the database, waits for it to be ready and stores its connection details. If you pick neither a cluster nor an existing VPC, the job first builds a new network.

The subnet and security groups are named after the database. For a database called orders, the job creates a DB subnet group, orders-db-sng, with at least 2 subnets in different zones. It also creates a security group, orders-sg, that allows TCP 3306, 5432 and 6379 from the VPC’s CIDR range. When you link the database to a ZopDay cluster, it uses that cluster’s VPC and its subnets (public and private). With an existing VPC, the Provision screen picks one subnet per zone, private subnets first.

The instance takes the job’s name. Its first database has the same name with dashes turned into underscores. The master user is root for MySQL or postgres for PostgreSQL, with a 24-character password ZopDay generates.

What can you set when creating an RDS instance

Pick MySQL Database or PostgreSQL Database, the cloud account, the region, a cluster or VPC, a name, an instance type and the storage. Instance types run from db.t3.micro to db.r6g.2xlarge, with db.t3.micro preselected. Storage starts at 20 GB (32 GB for PostgreSQL).

Advanced settings holds the engine version, with the latest preselected. It also holds High Availability (Multi-AZ), Public Access and Deletion Protection, all off by default, and an Automated Backups toggle. ZopDay does not apply that toggle when it creates the database. So instances created from the Provision screen always get backups kept for 7 days.

If you create the database through the ZopDay API and leave these out, ZopDay uses db.t3.medium, 20 GB, and MySQL 8.0 or PostgreSQL 16.

Which RDS storage and encryption settings are fixed

Storage is gp3 with encryption on. ZopDay sets no customer-managed KMS key, no maximum storage, no Enhanced Monitoring and no read replica. Public Access turns on the instance’s Publicly accessible setting, but the security group still admits only the VPC’s CIDR range.

How are RDS master credentials and app databases handled

ZopDay writes one Secrets Manager secret named after the database (zop-ds-orders for a database called orders). It holds the endpoint, port, username, password and database name. ZopDay stores only a pointer to the secret and does not keep its own copy of the password.

Each further database you add is created by a Kubernetes Job in the zop-system namespace of a connected cluster, so a private endpoint is reachable. ZopDay refuses to add a database until the RDS instance is connected to that cluster. That is because the Job reads the master credentials from the secret created by that connection.

For each database, the Job creates the database plus two users named after it. For a database called reports, these are an editor user, reports_user, and a read-only user, reports_rduser. It writes their credentials as Kubernetes Secrets in zop-system. Give the read-only user to BI tools instead of the master password.

How do RDS update and delete jobs work

An update job can change the instance class, storage, Multi-AZ, backup retention, deletion protection and public access. Changes apply immediately. Storage can grow, but RDS does not shrink it.

Deleting the job deletes the secret right away, with no recovery window. It turns off deletion protection and deletes the instance with no final snapshot, along with its automated backups. Then it removes the subnet group, the security group and any network ZopDay created. Take a manual snapshot first if you need the data.