We're moving toward infrastructure as code, but I'm struggling to see how it improves day-to-day work for AWS policies. If each application is represented by a YAML or Terraform configuration, a simple change seems to require finding the right repository and template, pulling the code, editing it, committing and pushing, waiting for deployment, and then checking the result in the AWS console or with the CLI anyway. That feels slower and introduces more layers that could fail compared with making the change directly.
I understand the arguments about having a source of truth, version history, and repeatability, but I'm also concerned about Terraform modules, dependencies, and the difficulty of finding where a particular policy is defined. We manage more than 30 AWS accounts with a relatively small team, so waiting for a basic policy change is frustrating. What practical benefits should we expect, and how can we keep the setup simple instead of creating a complicated system that is difficult to maintain?
4 Answers
The benefits are also operational: you get a durable change log, approval history, drift detection, and a straightforward rollback path. If a permission change causes trouble, the commit and deployment history help identify the cause quickly. Peer review also catches overly broad permissions before they reach production.
It’s reasonable to keep the console or CLI available for investigation and emergency work. The important distinction is that permanent changes should eventually be captured in code so the declared configuration and the real environment do not slowly diverge.
For a small environment, console or CLI changes can feel quicker. The value becomes more obvious when multiple accounts, environments, services, and teams are involved. Manual changes are difficult to audit and reproduce, and after a year it can be nearly impossible to determine why a policy has its current permissions.
That said, infrastructure as code won’t fix a disorganized process by itself. Your repository should make routine changes easy to locate, and console access can generally be read-only except for a controlled emergency process.
The main benefit isn’t that every individual change is faster. It’s that changes become reviewable, auditable, repeatable, and easier to recover from. With policies in version control, you can see what the intended state is, who changed it, why it changed, and what the previous version looked like. Pull requests provide peer review, and Terraform plans show the proposed effect before anything is applied.
Over time, this also reduces inconsistency between accounts and environments. Once the workflow is mature, you should need fewer manual verification steps because the plan, state, and automated checks give you confidence that the expected change was applied.
This sounds more like a convention and workflow problem than a Terraform problem. If every engineer or coding assistant creates policies differently, the repository will become harder to understand than the console.
Keep the initial design explicit and boring: define an obvious location for each policy, use consistent naming, document ownership, and establish one approved pattern for common changes. Avoid excessive modules, indirection, and abstractions until there is a real need for reuse. Infrastructure code should reduce the number of decisions people make for routine work, not increase them.
Exactly. Reusing a module is useful when it enforces a standard, but hiding a simple policy behind several layers of modules can make small changes unnecessarily difficult.
That’s probably where much of my frustration comes from. We have more than 30 accounts, but no consistent structure for where changes belong, so even a simple policy update can turn into a search through several projects.