Skip to content

Latest commit

 

History

History
25 lines (19 loc) · 2.03 KB

File metadata and controls

25 lines (19 loc) · 2.03 KB

The provided main.tf Terraform script in this path creates an RDS instance for the staging environment by restoring the latest snapshot of the production environment. It's a good approach, but you should be aware of a couple of points:

  1. Restoring an RDS snapshot creates a new RDS instance. In your script, if you run Terraform apply while the staging DB (db-uat) already exists, you will encounter an error because the identifier must be unique.

  2. The script sets skip_final_snapshot = true, which means when the DB instance is deleted, it won't create a final snapshot. Be careful with this setting in production environments. You might want to have a final snapshot when you delete a DB instance.

To solve the first issue, you might consider creating a unique identifier for the new staging DB each time you apply the script. For example, you can append a timestamp to the DB identifier:

resource "aws_db_instance" "db_uat" {
  instance_class       = "db.t2.micro"
  identifier           = "db-uat-${formatdate("YYYYMMDDhhmmss", timestamp())}"
  username             = "xxx"
  password             = "xxx"
  db_subnet_group_name = "db-private-subnet"
  snapshot_identifier  = data.aws_db_snapshot.db_snapshot.id
  vpc_security_group_ids = ["sg-4fd43532"]
  skip_final_snapshot = true
}

In the example above, I used the formatdate function to format the current timestamp and append it to the DB identifier.

Please be aware that creating unique DBs for every restore can lead to an accumulation of DBs over time. Make sure you have a process in place to clean up old staging DBs when they are no longer needed.

This solution also implies downtime for your staging environment because every time the script is run, the old staging DB is deleted and a new one is created from the snapshot. Depending on the size of your DB, it may take some time to complete. If you need to avoid downtime, you might consider a different strategy, like creating a new DB alongside the existing one, switching the connections to the new DB, and then deleting the old DB.