ClickOps: What It Is, Why It Hurts, and How to Get Your AWS Back Into Code

ClickOps is the habit of building and changing cloud infrastructure by clicking through a web console, such as the AWS Management Console, instead of describing it in code. The name is a joke on DevOps and GitOps, but almost every team does it at some point.

This article explains when ClickOps is perfectly reasonable, the signs that it has become a problem, and a step-by-step way to move a hand-built AWS account into Terraform or OpenTofu without a big-bang rewrite.

ClickOps isn't always wrong

Clicking in the console is the fastest way to try something. It's a good choice when:

• You're exploring a service you've never used.
• You're building a throwaway proof of concept that will be deleted this week.
• You're in the middle of an incident and need to change something in the next two minutes.

The trouble starts when those resources stay. The proof of concept becomes production. The incident fix never makes it back into code.

Signs ClickOps has become a problem

You've probably outgrown it if any of these sound familiar:

1. Nobody can say for sure what's in the account. Answering "what does this security group protect?" means opening five browser tabs.
2. Staging and production don't match, and nobody knows exactly how they differ.
3. Only one person knows how to rebuild things, and they're on holiday.
4. Terraform plans show surprises. Someone changed a resource in the console that Terraform also manages, so the next apply wants to undo their fix. That's infrastructure drift.
5. An audit or customer asks who changed a setting and when, and the honest answer is "we'd have to check CloudTrail and guess."
6. Costs grow and nobody knows why, because resources were created by hand and never cleaned up.

What it costs you

The cost of ClickOps is rarely one big outage. It's a steady tax:

• Slow, risky changes. Without code, every change is a manual procedure someone has to remember.
• No review. A teammate can review a pull request. Nobody reviews a click.
• Painful recovery. Rebuilding an account or a region from memory is slow, especially for disaster recovery.
• Hidden security gaps. A port opened "temporarily" in the console stays open until someone notices.

Moving from ClickOps to code, one step at a time

You don't need to stop everything and rewrite your infrastructure. Treat it as a migration you do in small, safe pieces.

1. Take an inventory

List what exists before deciding anything. For AWS, useful sources are:

• AWS Resource Explorer or AWS Config for a list of resources across regions.
• Cost Explorer grouped by service, to see what actually costs money.
• Tags, if you have any, to tell environments and owners apart.

Mark each resource as one of: keep and manage in code, delete, or leave alone (for example, things AWS manages for you).

2. Stop the bleeding with a simple rule

Agree on one rule going forward: new infrastructure starts in code. The console stays available for reading and emergencies, but anything new goes through a pull request. This stops the problem growing while you clean up what already exists.

3. Import what you're keeping

Bring existing resources under Terraform without recreating them. Terraform's import block plans the import first, so you can review it before anything changes, and it can generate a first draft of the configuration for you. Our guide to Terraform import blocks walks through it with AWS examples.

Start with the resources that matter most and change most often, usually networking, security groups and the main application services. Leave the long tail for later.

4. Check for drift on a schedule

Once resources are in code, keep them that way. Run a scheduled terraform plan against each environment and alert when it shows changes nobody expected. See how to detect Terraform drift for the details, and the drift triage playbook for deciding what to do with each finding.

5. Make the console read-only for most people

When the important resources are in code, tighten IAM so most people can view the console but not change production. Keep a break-glass role for emergencies, and require that any emergency change is copied back into code afterwards.

How long does it take?

For a small startup account with a few dozen resources, a focused week gets the important pieces into code. For a larger account that grew over years, plan for a few weeks of steady work, done service by service. The inventory and the import work take most of the time; writing new Terraform is the easy part.

Where OrchesTerra fits

OrchesTerra is built for teams leaving ClickOps behind on AWS:

• It finds what isn't in code. Connect an AWS account and see resources that exist but aren't managed by Terraform.
• It adopts them without recreating them. Choose what to keep, and OrchesTerra generates the import and configuration for review.
• It watches for drift. Scheduled checks rank each console change by risk. A changed tag ranks low; a security group opened to the internet ranks high.
• It puts approvals in front of risky changes, so fixes are reviewed rather than applied silently.

You can click through all of this in the read-only demo, no sign-up needed, or start a 14-day trial and connect your own account.

Summary

• ClickOps is fine for experiments and emergencies, and costly as a way of running production.
• Start with an inventory and one rule: new infrastructure starts in code.
• Import what you're keeping, service by service, instead of rewriting everything.
• Check for drift on a schedule so the account doesn't slide back.