Self-Service Terraform: 8 Modules That Killed 60% of Our Platform Tickets

Platform teams do not fail because they hire the wrong people. They fail because the right people spend most of their time fielding the same eight requests over and over: provision a new service on EKS, add an RDS instance, create an S3 bucket with the right IAM policy. The requests are not hard. They are just constant.

We measured this across four platform teams. The average ticket took 2.3 hours to resolve end-to-end, counting the back-and-forth clarification, the Terraform write, the PR review, and the apply. A developer filing the ticket waited a day or two. The platform engineer context-switched twice. Nobody was happy.

The fix was not hiring more platform engineers. It was building a self-service Terraform module library: eight opinionated modules that developers invoke directly, enforce sane defaults without asking, and apply through a PR workflow that never requires a platform engineer to be in the loop.

Within 90 days of rolling out those eight modules and wiring them to Atlantis, ticket volume dropped 60%.

Why Platform Teams Drown in Repeat Tickets

The slow path for infrastructure provisioning looks like this:

Every step in that flow is a handoff. Handoffs create delay. Platform engineers lose half a day to context-switching. Developers lose a day or two waiting. The same resources get provisioned slightly differently each time because Terraform is written fresh from memory rather than from a tested module.

The resource types in those tickets are not random. When we clustered six months of tickets by resource type, eight categories accounted for 80% of total volume: EKS services, RDS instances, S3 buckets, SQS queues, Lambda functions, VPC subnets, IAM roles, and ECR repositories. That clustering is what drove the eight-module number. It is not an arbitrary figure. Most platform teams find that six to ten resource types cover the bulk of their load.

The 8 Modules and What Each One Enforces

Each module exposes a minimal interface to developers: the things they legitimately need to choose, like service name and instance size. Each module hard-codes the things developers routinely skip: encryption, tagging, network placement, deletion protection.

The pattern matters. Modules fail adoption when they are opinionated about things developers care about, like forcing a specific instance type, while staying silent on things developers forget, like enabling encryption at rest. We inverted that: flexible on sizing, strict on compliance.

Module	Resource	Developer Inputs	Enforced Defaults
`eks-service`	EKS Deployment + Service	name, image, replicas, cpu/memory limits	resource limits required, liveness probe required, namespace, labels schema
`rds-instance`	RDS (Postgres/MySQL)	engine, instance class, db name	encryption at rest, deletion protection on, automated backups 7 days, private subnet only
`s3-bucket`	S3 + Bucket Policy + IAM	bucket name, allowed principals	versioning on, public access blocked, server-side encryption AES-256, lifecycle rule 90 days
`sqs-queue`	SQS Standard or FIFO	queue name, visibility timeout	server-side encryption, dead letter queue wired, max receive count 3
`lambda-function`	Lambda + IAM Role + Log Group	function name, runtime, handler, memory	least-privilege execution role, CloudWatch log group with 30-day retention, X-Ray tracing on
`vpc-subnet`	Subnet + Route Table	CIDR, availability zone, subnet type	private by default, no public IP auto-assign, VPC flow logs enabled
`iam-role`	IAM Role + Policy	role name, trusted principal, policy statements	no wildcard resources allowed (validation), path `/service/`, permission boundary attached
`ecr-repo`	ECR Repository	repo name	image scanning on push, tag immutability on, lifecycle policy 30 untagged images

The tagging enforcement deserves specific mention. Every module writes a local block that constructs a standard tag map from required inputs: environment, team, cost-center, and managed-by = terraform. Resources come out of the module tagged correctly by default. Our internal governance audit showed this eliminated 90% of untagged resource drift. The manual alternative: a compliance scan finds untagged resources, creates a ticket, an engineer tracks down the owner, the owner tags the resource. That loop took three to five days per resource. The module collapses it to zero.

How the Registry Makes It Truly Self-Service

Modules alone are not enough. If developers still need to ask a platform engineer to run terraform apply, the ticket volume drops but does not disappear. The platform team becomes the apply button instead of the Terraform author. That is a smaller problem, but it is still a bottleneck.

The registry layer removes the human from the apply step. We use Atlantis, which runs as a pod in the cluster and watches pull requests in the infrastructure repository. The self-service flow looks like this:

A developer using this flow from PR open to resource live in under 10 minutes. No platform engineer in the loop. The plan output in the PR comment shows exactly what will be created, which resources, which tags, which costs if Infracost is wired in. Developers can review their own plan before applying.

Spacelift and Terraform Cloud provide equivalent workflows if you prefer a managed control plane over a self-hosted Atlantis pod. The mechanism is the same: PR triggers plan, comment triggers apply, platform engineer is not required.

The infrastructure repository where modules live is version-controlled separately from application repositories. Developers open PRs against a modules/ directory, reference the shared module using a relative path or private registry source, and supply only the variables the module exposes. Platform engineers review module updates, not individual resource provisioning requests.

What the Ticket Data Showed Before and After

We tracked tickets for 60 days before rollout and 90 days after. The before period establishes the baseline. The after period starts 30 days post-rollout to account for the learning curve as developers adopted the new workflow.

Ticket Category	Before (per month)	After (per month)	Delta
EKS service provisioning	47	6	-87%
RDS instance requests	31	9	-71%
S3 bucket + policy setup	28	4	-86%
SQS queue creation	19	3	-84%
Lambda function setup	14	5	-64%
VPC subnet requests	11	2	-82%
IAM role requests	38	22	-42%
ECR repository setup	9	1	-89%
Other (one-off, complex)	41	39	-5%
Total	238	91	-62%

IAM role tickets showed the smallest reduction for a specific reason: a significant portion of IAM work involves cross-account trust relationships and fine-grained permission debugging that the module cannot automate. The module handles the common case, not the edge case. Developers who need non-standard IAM configurations still file tickets, and those are genuinely complex.

The "other" category barely moved. Those tickets involve multi-region failover setups, cross-account peering, custom WAF rules, and one-off compliance remediation. Those are not repeat tickets. They are genuinely novel work, which is exactly what platform engineers should be spending time on.

Platform engineers reclaimed roughly 180 person-hours per month from ticket work. That time went into module maintenance, Atlantis operations, and building the next layer of automation.

Where Modules Break: The Failure Modes

Self-service Terraform is not maintenance-free. Three failure modes appear consistently in production.

Failure Mode	Cause	Mitigation
State drift	Developer modifies resource outside Terraform (console, CLI)	`terraform refresh` on a schedule; lock console access for module-managed resources
Version mismatch	Teams pin old module versions; a security fix in v1.4 never reaches teams on v1.1	Enforce minimum version in CI; send breaking change notifications to module users
Bad default blast radius	A wrong default (too-permissive security group, wrong retention) propagates to every resource using the module	Test module changes in staging first; use semver and never silently change defaults in a patch release

The version mismatch problem is the one teams underestimate. Once a module ships, teams pin to a version and stay there. If a security default changes in a later version, every team on the old version keeps the old behavior. We address this with two controls: Atlantis is configured to warn on modules older than two minor versions, and we maintain a CHANGELOG.md in the module repo with explicit callouts for default changes.

Drift is a related problem. The module enforces defaults at creation time. If an engineer later modifies the resource in the AWS console, the module does not know. Scheduled terraform plan runs catch this: any plan that shows unexpected changes signals drift. We run these on a 24-hour schedule and route non-empty plans to a Slack channel.

The blast radius concern is real but manageable. A bad default in a module is worse than a bad default in a one-off Terraform file because it propagates to every resource ever created with that module. This is also why modules are strictly better than shared snippets: you can fix a bad default in one place and roll the fix forward via version bumps, something you cannot do with copy-pasted Terraform.

How to Ship Your First Module in a Week

The practical starting point is not architecture. It is your ticket backlog.

Pull three months of tickets. Cluster them by resource type. The top cluster is your first module. Write that one module, wire it to one pilot team with Atlantis, and measure for 30 days before adding the next module.

The temptation is to build all eight modules at once before shipping any of them. This is how module projects stall: the scope grows, the work drags, and the platform team ships nothing while the ticket queue keeps filling. One module in production teaches you more about your team's usage patterns than eight modules in a design document.

The module itself should take two to three days for a senior engineer to write, test, and document. The Atlantis setup takes another day. The remaining time in the week goes to piloting with one team, collecting feedback, and hardening the variable validation.

If you want to see how internal developer platforms structure self-service infrastructure alongside cost guardrails, that pattern extends naturally from module-level enforcement to platform-level policy-as-code governance. The module is the unit. The platform is the system.

The goal is not eight modules. The goal is 60% fewer tickets. Start with one. Measure. Ship the next one when the data tells you to.