BootStrapping Aurora RDS Databases using Lambda and Terraform (Part 1)

Source: Dev.to | Jan 10, 2026 (UTC)

Table Of Contents

• The Problems
• Cluster Creation
  • Child Module
  • Root Module
  • YAML DataSet
  • Local Variables
  • Input Variables
• Roadmap

TL;DR
Terraform can create an Aurora cluster, but it cannot safely manage databases, users, or grants.
This series shows how we decouple infrastructure provisioning from database bootstrapping using Lambda — and later, Step Functions — without breaking Terraform’s declarative model.

The Problems

Terraform’s Limitations

While Terraform is ideal for provisioning Aurora clusters, it is poorly suited for managing database-level objects because:

• Limited Scope: It can only create one initial database; it cannot manage multiple databases, complex ownership models, or granular IAM-based access.

• State Conflict: Managing SQL internals within Terraform leads to brittle plans, partial failures, and irreversible drift.

• Risk: Running SQL during terraform apply creates tight coupling between infrastructure and runtime data, increasing operational risk.

The Manual Gap

Although it’s able to provision the cluster and an initial database in minutes, it leaves behind an operational vacuum. Once the cluster is live, the engineering team is frequently forced into a manual waiting game:

• Access Stagnation: The cluster exists, but there are no application-specific users.

• Security Hurdles: A platform engineer must manually log in to configure IAM authentication and map roles to database users.

• Permission Complexity: Defining granular Read/Write privileges, schema ownership, and grant structures becomes a ticket-driven manual task.

• Developer Friction: Application developers sit idle until the tasks above are completed because the Initial Database provided by AWS lacks the schema-level management required for actual deployment.

This creates a bottleneck where infrastructure is automated, but the database remains unusable until a human intervenes to bridge the gap between a cloud resource and a functional data store.

This post outlines a platform engineering approach to bootstrapping Amazon Aurora databases, arguing that database internals should be decoupled from Terraform state.

Terraform’s responsibility ends when the cluster becomes reachable.
Everything beyond that point is runtime behavior, not infrastructure state.

The Cluster Basics

While this post isn’t a deep dive into cluster creation itself, I will cover the essential infrastructure components to provide context for Part 2. My implementation utilizes the standard terraform-aws-rds-aurora module, wrapped within a custom child module to meet our specific requirements.

Child Module

module "cluster" { source = "terraform-aws-modules/rds-aurora/aws" version = "10.0.2" #<-- latest at the time of writing name = local.cluster_name engine = var.db_profile.engine engine_mode = "provisioned" #<-- NOT cluster-type engine_version = var.db_profile.engine_version storage_encrypted = true enable_http_endpoint = anytrue([ var.enable_db_managment, var.data_api_enabled ]) master_username = var.master_uname manage_master_user_password = true master_user_secret_kms_key_id = var.kms_key_id manage_master_user_password_rotation = true master_user_password_rotate_immediately = true master_user_password_rotation_schedule_expression = "rate(21 days)" vpc_id = var.vpc_id db_subnet_group_name = var.subnet_group_name security_group_ingress_rules = { for ci, dr in var.ingress_cidr_blocks : "cidr${ci}" => { cidr_ipv4 = dr } } cluster_monitoring_interval = 60 cluster_parameter_group = { name = local.cluster_name family = local.db_engine_family description = "${local.cluster_name} cluster parameter group" parameters = var.cluster_parameter_group_parameters } db_parameter_group = { name = local.cluster_name family = local.db_engine_family description = "${local.cluster_name} Database parameter group" parameters = var.db_parameter_group_parameters } apply_immediately = true deletion_protection = true skip_final_snapshot = true # ---------------------------------------------- # Only required for Serverless V2 clusters # ---------------------------------------------- serverlessv2_scaling_configuration = ( var.cluster_type == "serverless" ) ? { min_capacity = 2 max_capacity = 10 } : null cluster_instance_class = ( var.cluster_type == "serverless" ) ? "db.serverless" : var.db_profile.instance_class # ---------------------------------------------- # Based on the number of AZs, it creates # 1x RW-instance & 1x RO-inatance per AZ # ---------------------------------------------- instances = var.cluster_type == "serverless" ? { for ix, az in concat(var.aws_zones, [join("", var.aws_zones)]) : "${var.db_profile.engine_type}${ix + 1}" => {} } : merge( { "0rw" = { instance_class = lookup( var.db_profile, "rw_instance_class", var.db_profile.instance_class ) } }, { for ix, az in var.aws_zones : "${ix + 1}ro" => { instance_class = var.db_profile.instance_class } } ) #create_cloudwatch_log_group = true enabled_cloudwatch_logs_exports = ( var.db_profile.engine == "aurora-mysql" ? [ "audit", "error", "general", "slowquery", ] : ( var.db_profile.engine == "aurora-postgresql" ? ["postgresql"] : [] ) ) iam_database_authentication_enabled = true #<-- MUST be true tags = merge( var.extra_tags, { Name = local.cluster_name SubResource = "module.cluster" } ) }

Enter fullscreen mode

Exit fullscreen mode