Setup decisions
Three values are fixed once a data plane has databases. There’s no automated migration path today — changing any of them requires manual recovery.Agent name
The agent name is theagents map key for a data plane — agents = { "<AGENT_NAME>" = { ... } } — reused as Fargate agent_name or Helm superblocks.agentName. It’s the identity Superblocks uses everywhere the data plane touches AWS:
- IAM scoping. Every create and mutate is gated on the tag
AgentName=<AGENT_NAME>, stamped by the lifecycle worker on every resource it creates. - Role and policy naming. Each data plane gets its own lifecycle worker and connector role.
- OpenTofu state isolation.
app_db_prereqsderives this data plane’s state prefix from it (defaultapp-db/<AGENT_NAME>), scopes S3 permissions to that prefix, and exports it asagents["<AGENT_NAME>"].key_prefix.
AccessDenied.
Changing the agent name means Terraform destroys and recreates the IAM roles under the new name — the data plane can’t manage its database pool again until it’s redeployed with the new role ARNs. No data is lost, but it’s a coordinated migration, not a rename.
Data tag names
Database and role names are derived from a hash of the tag:sbndb_<profile-token>_<application-token> for the database, sbndb_<profile-token>_<application-token>_runtime for its role. <profile-token> is the first 16 hex characters of SHA-256(lowercase(tag)); <application-token> is a 24-hex hash of the application ID. The connector role’s permissions are scoped to that pattern, so renaming a tag orphans every existing database and role under the old name. Tag names must be non-empty and unique across all agents in the module invocation.
VPC
Every IAM policy created for a data plane is scoped to its VPC. Changing it means none of the existing roles can act on resources in the new VPC.How databases go from edit to deployed
A database is created when a builder with database creation permission asks for one in the Superblocks editor. If an existing Aurora PostgreSQL cluster has capacity under your scaling settings, Superblocks queues a task to create an isolated logical database on that cluster. Your data plane picks tasks up from the queue and applies them. Clark generates the database schema and stores it as.sql files in the application code. Once the database is ready, Clark queues a task for the data plane to run the migrations.
Databases follow your data plane layout and the data tags each data plane serves. When an app is deployed, Superblocks can create a separate database for the deploy-time data tag before the deploy finishes.
The diagram below traces one app’s database end to end. While a builder is still editing, Clark asks for a database, your data plane creates it, and Clark’s generated schema is applied. On deploy, the same sequence can run again against a separate database for the deploy-time data tag. Superblocks only queues work; your data plane claims it and calls AWS.
What Superblocks creates in your AWS account
Resources arrive in two waves with very different lifetimes. Setup creates a small, fixed set of control resources that live as long as the feature is enabled. Everything else is created on demand as the pool grows, and those are the resources you manage day to day.At setup: control resources
The Terraform module creates these once. They are inexpensive to keep, and removing them disables provisioning. Lifecycle worker IAM role: your data plane assumes this role to manage database infrastructure. Its permissions are narrowly scoped: every mutation (create, modify, delete) is tag-gated, so the role can only act on resources that Superblocks itself tagged at creation time. It cannot touch resources in other VPCs or resources it did not create. See IAM permissions for the full breakdown. Connector IAM role: one role per data plane. This is the identity your data plane uses to reach app databases at query time. To run a query, the data plane assumes this role and uses the resulting credentials to sign a short-lived RDS IAM auth token, which PostgreSQL accepts in place of a password. Provisioning creates the PostgreSQL role the token authenticates as and grants itrds_iam; the PostgreSQL role name follows sbndb_<profile-token>_<application-token>_runtime (see Connector role), and is unrelated to the connector role’s ARN. The trust policy limits who can assume this role to the lifecycle worker role for that data plane. See Connector role for how the permissions are narrowed on each connection.
Enhanced Monitoring IAM role: one account-level role shared by every App Database cluster and instance. RDS assumes this role to publish operating-system metrics. The lifecycle worker can pass only this role, and only to rds.amazonaws.com.
S3 bucket: stores OpenTofu state so Superblocks can manage your database resources over time (modify, delete, track drift). Key properties:
- One bucket per account and region
- Versioning enabled, so state can be recovered if corrupted
- Public access blocked
- Encrypted at rest with SSE-S3 by default (AWS-managed keys, no KMS charges). Optionally bring your own KMS key via
kms_key_arnto use SSE-KMS. When provided, the lifecycle worker IAM policy scopes KMS access to that specific key ARN only - Superblocks reads and writes to this bucket; you own and retain it
- Each data plane is IAM-scoped to its own prefix (default
app-db/<AGENT_NAME>, exported asagents["<AGENT_NAME>"].key_prefix). State keys follow{key_prefix}/{tag}/{resource_key}.tfstate
As the pool grows: one set per Aurora cluster
pool.max_databases (Fargate) / pool.maxDatabases (EKS) caps how many app databases land on one cluster before another is added to the pool. Lowering it spreads apps across more clusters, which shrinks the blast radius of a failover or an engine patch and raises your baseline cost; raising it does the reverse. Along with the ACU range, this is the main control over what the pool costs as it grows.
Your data plane creates the following each time it adds a cluster to the pool (first when you click Provision, and again whenever existing clusters reach max_databases):
- Aurora PostgreSQL cluster and its instances: named
sb-{hash}, IAM authentication enabled, public accessibility disabled, storage encrypted at rest, and the master password managed by AWS Secrets Manager so there are no plaintext passwords - CloudWatch log group: a per-cluster
/aws/rds/cluster/<cluster-id>/postgresqlgroup that retains exported PostgreSQL logs for 30 days - DB cluster parameter group: logs every statement running for at least 5 seconds, samples 10% of statements running between 1 and 5 seconds, and excludes bound parameter values
- DB subnet group: scoped to the subnets you specified in
physical_module_inputs - Security group and its ingress/egress rules: controls which sources (security groups or CIDRs) can reach the database on port 5432. The security group and each rule are separate AWS resources and both carry the tags below.
Observability defaults
The default configuration provides the following signals in your AWS account:- Standard RDS CloudWatch metrics
- Enhanced Monitoring at 60-second resolution through the account- and region-level
RDSOSMetricsCloudWatch Logs group, with one log stream per database instance. Its retention is independent of the per-cluster PostgreSQL log group’s 30-day setting - Database Insights Standard, with Performance Insights retained for 7 days
- PostgreSQL logs exported to CloudWatch Logs with 30-day retention
- PostgreSQL diagnostic logs for lock waits and deadlocks, temporary files larger than 64 MiB, checkpoints, and autovacuum operations running at least 5 seconds
- Slow-query logging for every statement running at least 5 seconds and a 10% sample of statements running between 1 and 5 seconds. Statements under 1 second are not duration-logged. Bound parameter values are excluded, although the parameterized statement text is retained
pg_stat_statementstracking for top-level statements. Its storage is bounded and shared across the cluster, so older or less-used entries can be evicted; the module does not fix a universal entry limit
monitoring_interval comment in Step 1. Settings declared in the physical module inputs or supplied by its defaults—including log retention and PostgreSQL parameters—are managed through OpenTofu, so a later lifecycle apply can revert manual console changes. Superblocks does not ingest these signals or monitor your databases on your behalf. Your organization controls access to CloudWatch, pays any associated AWS charges, and owns the dashboards, alarms, subscriptions, and incident-response processes it builds on top.
How everything is tagged
Every App Database AWS resource carries two kinds of tags. IAM scoping tags (required for the lifecycle worker to mutate the resource):AgentName={agents-map-key}— the agent name for this data plane (Terraformagentsmap key, Fargateagent_name, or Helmsuperblocks.agentName)ManagedBy=superblocks-app-database-lifecycleVpc={your-vpc-id}
AgentName itself; physical modules merge ManagedBy; Vpc comes from your networking inputs.
Ownership and partnership tags (required on every Superblocks-created resource, including runtime Aurora):
superblocks:owned=trueaws-apn-id=pc:ctelqp437y3cvjkv5rv0z2w4f
aws-apn-id is a fixed Superblocks constant (pc:ctelqp437y3cvjkv5rv0z2w4f); copy it verbatim — it is not per-account.
app-db-prereqs enforces both keys on setup resources. The Fargate app-db module merges the same pair into runtime module inputs, overwriting conflicting caller values. On EKS, the Helm chart does not inject them — set both keys under databaseLifecycle.physicalModuleTags (see Step 1). Without them, IAM create on runtime Aurora, RDS, subnet groups, and security groups fails with AccessDenied. The lifecycle worker IAM policy also denies removing either key from runtime resources.
The lifecycle worker IAM policy also denies removing any of the five keys above (AgentName, ManagedBy, Vpc, superblocks:owned, and aws-apn-id), including via named Deny Sids (DenyRemoveProtectedTags / DenyDeleteProtectedTags / DenyUntagProtectedTags) so AccessDenied is attributable. EC2 DenyDeleteProtectedTags is further scoped with AgentName / ManagedBy / Vpc ResourceTags so attaching policies via existing_role_name cannot Deny DeleteTags on unrelated security groups.
Find everything the feature manages with a Resource Group or the CLI:
S3 state bucket properties
The bucket is created unconditionally: one per account and region, shared across all data planes in the same module invocation. Default naming issb-app-db-<REGION>-<ACCOUNT_ID>, where the sb-app-db prefix comes from the s3_name_prefix variable.
When creating it manually, configure the following properties:
Security
IAM permissions
Lifecycle worker role
Your data plane runs as this role to manage database infrastructure. Its policies cover state, RDS provisioning and mutation, EC2 networking, Secrets Manager, and observability. State backend policy. Scoped exclusively to the S3 bucket the Terraform module creates, with no wildcards:- S3:
ListBucket(prefix-conditioned),GetObject,PutObject,DeleteObjectunder that agent’skey_prefixin the state bucket only - KMS (only when
kms_key_arnis provided):Encrypt,Decrypt,GenerateDataKeyon the specific key ARN. Superblocks cannot use any other KMS key in your account.
AgentName={agent-map-key}, ManagedBy=superblocks-app-database-lifecycle, and Vpc={your-vpc-id}. Create actions must supply all three tags as request tags. Delete and modify actions require all three tags to already exist on the target resource. The IAM policy only permits removing tags other than AgentName, ManagedBy, Vpc, superblocks:owned, and aws-apn-id, so the scoping and ownership tags cannot be stripped. An explicit Deny Sid (DenyRemoveProtectedTags / DenyDeleteProtectedTags) makes that failure attributable in IAM diagnostics.
Additional constraints enforced in the policy:
- RDS instance ARNs are restricted to the
sb-*namespace, so Superblocks cannot modify your existing RDS instances rds:PubliclyAccessiblemust befalseon all create actions: the policy rejects any create that asks for a public endpointrds:ManageMasterUserPasswordmust betrueon standalone RDS creates, so master credentials are always managed by Secrets Manager and never set as a static password. This condition also discriminates standalone RDS creates from Aurora cluster member creates: Aurora member creates do not pass this key (the master password is inherited from the cluster), sords:ManageMasterUserPasswordevaluates to false and only the Aurora member statement matches.rds:DatabaseEngineis pinned topostgres(standalone RDS) andaurora-postgresql(Aurora cluster) at create time, so the lifecycle worker cannot provision any other engine typerds:StorageEncryptedmust betrueon standalone RDS and Aurora cluster creates. Storage encryption is enforced by IAM at create time, not only by module configuration.- Security group mutations are scoped to the same
AgentName,ManagedBy, andVpctag triple - EC2 security group creation is additionally scoped to the specific VPC ID via the
ec2:VpcIDcondition, so Superblocks cannot create resources in other VPCs in your account - KMS access for RDS storage encryption is gated on
aws:CalledVia: rds.amazonaws.com, so Superblocks cannot use your KMS keys directly
DescribeDBInstances, DescribeDBSubnetGroups, DescribeVpcs, DescribeSubnets, and similar) are read-only and apply to "Resource": "*". This is required by AWS, because describe APIs do not support resource-level restrictions, but no data is retained by Superblocks.
Master secrets policy. Scoped to RDS-managed master secrets (rds!db-* and rds!cluster-* ARN prefixes):
- Read:
GetSecretValueandDescribeSecreton RDS-managed secrets tagged withAgentName,ManagedBy, andVpc: the master credentials for databases Superblocks created - Write (create and tag): only allowed via
aws:CalledVia: rds.amazonaws.com. Superblocks cannot directly create Secrets Manager secrets; only RDS can, on behalf of Superblocks. - IAM:
CreateServiceLinkedRolescoped tords.amazonaws.com. This is a one-time action required to create the RDS service-linked role if it does not already exist in your account.
Connector role
One connector role is created per data plane. The role grantsrds-db:connect scoped to the DB users Superblocks provisions for that data plane: one statement per data tag, matching the pattern sbndb_<profile-token>_*_runtime in your region. <profile-token> is the first 16 hexadecimal characters of the SHA-256 digest of the lowercased data tag (for example, printf '%s' '<DATA_TAG>' | shasum -a 256 | cut -c1-16). The connector role can only authenticate as DB users that Superblocks created for the declared data tags. It cannot connect as any other DB user, or to databases in your account that Superblocks did not create.
The trust policy limits who can assume the connector role to the specific lifecycle worker role ARN for that data plane. No other principal can assume it.
How a connection is authenticated
Neither the connector role’s ARN nor the lifecycle worker’s identity appears inside PostgreSQL. The database only ever sees a PostgreSQL role name and an auth token, and IAM decides whether that token is valid. The sequence for a single query is:- Provisioning creates the app’s PostgreSQL role (
sbndb_<profile-token>_<application-token>_runtime, where<profile-token>comes from the data tag as described above and<application-token>is a 24-hex hash of the application ID) and grants itrds_iam. That grant makes PostgreSQL delegate authentication for this role to IAM instead of checking a stored password. No password is ever generated for it. - The data plane checks the target against the connector role ARN it was configured with, and refuses the connection if they disagree. A compromised control plane cannot redirect the data plane at an IAM role its operator never approved.
- The data plane assumes the connector role, attaching an inline session policy that allows exactly one action on exactly one resource:
rds-db:connecton this cluster, as this one PostgreSQL role. The credentials it gets back are narrower than the connector role itself. - It signs an RDS IAM auth token for that PostgreSQL role with those session credentials, and connects using the token as the password, over TLS with full certificate and hostname verification.
sbndb_<profile-token>_*_runtime users for the declared data tags, and the per-connection session policy narrows that to the single user for the single app being served. One app’s credentials cannot reach another app’s database, even though both use the same connector role.
Raw IAM policy JSON
The Terraform module creates the following IAM resources per data plane. If your organization requires policies to be pre-approved or manually provisioned before Terraform can attach them, use the JSON below.iam_name_prefix prefixes the IAM role and policy names below, and s3_name_prefix prefixes the state bucket name. Both default to sb-app-db, which is what the example values show.
Placeholders to substitute before use:
Lifecycle worker role: trust policy (ECS Fargate)
Lifecycle worker role: trust policy (ECS Fargate)
Lifecycle worker role: trust policy (EKS with IRSA)
Lifecycle worker role: trust policy (EKS with IRSA)
<OIDC_PROVIDER_URL> is the OIDC provider URL without the ARN prefix (everything after oidc-provider/). The sub condition scopes trust to the specific Kubernetes service account. Adjust namespace and service_account_name if you deviate from the Superblocks defaults.Policy 1: Assume connector (sb-app-db-<AGENT_NAME>-assume-connector)
Policy 1: Assume connector (sb-app-db-<AGENT_NAME>-assume-connector)
Policy 2: State backend (sb-app-db-<AGENT_NAME>-state-bucket-<REGION>)
Policy 2: State backend (sb-app-db-<AGENT_NAME>-state-bucket-<REGION>)
key_prefix only (default app-db/<AGENT_NAME>; override via agents["<AGENT_NAME>"].key_prefix). Replace <KEY_PREFIX> with the same string you wire into the data plane (see Agent name).GetBucketLocation / GetBucketVersioning live in a separate statement from ListBucket because those metadata APIs do not send s3:prefix and would fail closed if they shared the list condition.The last statement (StateBucketKms) handles bucket encryption. Without a customer KMS key (the default, SSE-S3), the resource is "*" and access is constrained to calls originating from S3, as shown below. With a customer KMS key (kms_key_arn set), replace "Resource": "*" with the specific key ARN and remove the Condition block entirely.Policy 3: RDS provisioning (sb-app-db-<AGENT_NAME>-rds-provisioning-<REGION>)
Policy 3: RDS provisioning (sb-app-db-<AGENT_NAME>-rds-provisioning-<REGION>)
sb-* namespace and the declared VPC. All create actions enforce tagging at request time, publicly_accessible = false, and manage_master_user_password = true. The RdsCreateDbInstance and RdsCreateAuroraClusterInstance statements both cover rds:CreateDBInstance but are cleanly discriminated: standalone RDS creates pass rds:ManageMasterUserPassword = true and Aurora member creates do not, so each request matches exactly one statement.Policy 4: RDS mutation (sb-app-db-<AGENT_NAME>-rds-mutation-<REGION>)
Policy 4: RDS mutation (sb-app-db-<AGENT_NAME>-rds-mutation-<REGION>)
AgentName, ManagedBy, and Vpc resource tags, so the lifecycle worker cannot modify any RDS resource it did not create. RdsRemoveTagsExceptProtectedTags only Allows removing non-protected tags. DenyRemoveProtectedTags is an explicit Deny that blocks removing AgentName, ManagedBy, Vpc, superblocks:owned, or aws-apn-id, so AccessDenied is attributable to that Sid.Policy 5: EC2 networking (sb-app-db-<AGENT_NAME>-ec2-provisioning-<REGION>)
Policy 5: EC2 networking (sb-app-db-<AGENT_NAME>-ec2-provisioning-<REGION>)
Ec2CreateSecurityGroupVpcScope statement additionally restricts CreateSecurityGroup to the specific VPC resource via ec2:VpcID, so the lifecycle worker cannot create security groups in any other VPC. Ec2CreateTagsOnCreateSecurityGroup authorizes create-time tagging for CreateSecurityGroup and for AuthorizeSecurityGroupIngress / AuthorizeSecurityGroupEgress, so ownership tags can land on both the security group and its individual rules when they are created. Ec2DeleteTagsExceptProtectedTags only Allows removing non-protected tags from managed security groups and rules when aws:TagKeys is present; DenyDeleteProtectedTags Denies removing the scoping and ownership keys; DenyDeleteTagsWhenTagKeysAbsent Denies the delete-all request that omits Tags / aws:TagKeys.Policy 6: Secrets Manager (sb-app-db-<AGENT_NAME>-secrets-<REGION>)
Policy 6: Secrets Manager (sb-app-db-<AGENT_NAME>-secrets-<REGION>)
aws:CalledVia: rds.amazonaws.com, so the lifecycle worker cannot directly create Secrets Manager secrets; only RDS can, on its behalf.The last statement (DecryptRdsManagedSecretKmsKey) handles KMS decryption for the RDS-managed master secret. Without a customer KMS key (rds_secret_kms_key_arn not set), Resource is "*" and access is constrained via kms:ViaService and kms:EncryptionContext as shown below. With a customer KMS key, replace "Resource": "*" with the specific key ARN.Connector role: trust policy
Connector role: trust policy
Connector role: policy (superblocks-app-db-connector-<AGENT_NAME>)
Connector role: policy (superblocks-app-db-connector-<AGENT_NAME>)
rds-db:connect for each declared data tag, scoped to DB users matching sbndb_<profile-token>_*_runtime on both RDS instances and Aurora clusters. <profile-token> is the first 16 hex characters of SHA-256(lowercase(tag)) — compute it with printf '%s' '<DATA_TAG>' | shasum -a 256 | cut -c1-16. Add or remove statements to match your declared agent_tags. The example below shows two data tags (<PROFILE_TOKEN_1> and <PROFILE_TOKEN_2>).This is the outer bound, not the effective permission on a connection. The data plane assumes this role with a session policy allowing rds-db:connect on one specific cluster and DB user, so each connection is authorized for exactly the app it is serving. See How a connection is authenticated.Policy 7: Observability (sb-app-db-<AGENT_NAME>-observability-<REGION>)
Policy 7: Observability (sb-app-db-<AGENT_NAME>-observability-<REGION>)
logs:DescribeLogGroups must be scoped to "Resource": "*" because AWS does not support resource-level restrictions on describe log group APIs.logs:UntagResource is split into an Allow that excludes protected keys (CloudWatchUntagExceptProtectedTags) and an explicit Deny (DenyUntagProtectedTags), matching the RDS/EC2 protected-tag pattern. logs:TagResource is similarly split (CloudWatchTagResourceWithCanonicalOwnership) so ownership request-tag values cannot be overwritten.iam:PassRole is conditioned on iam:PassedToService: rds.amazonaws.com, which is the service principal that RDS uses when calling CreateDBInstance — not monitoring.rds.amazonaws.com, which is what the monitoring agent assumes later.Enhanced Monitoring role: trust and permissions
Enhanced Monitoring role: trust and permissions
app_db_prereqs creates one account-level role named sb-app-db-enhanced-monitoring (or <iam_name_prefix>-enhanced-monitoring) with the following trust policy. Additional regional prerequisite stacks reuse this same role through existing_monitoring_role_arn. If your organization must create IAM roles out of band, create the role with this policy and pass its ARN as existing_monitoring_role_arn to every prerequisite invocation.arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole policy to this role. If you create the role out of band, attach the same policy. The trust policy uses monitoring.rds.amazonaws.com, while the lifecycle worker’s iam:PassRole condition above intentionally uses rds.amazonaws.com; these principals serve different parts of the Enhanced Monitoring flow.
