Auto-Tagging EC2 Instances with AWS Config + SSM: No Terraform Required

Is tagging really essential ?!

Let us understand this through a scenario

You’ve just joined a new company as a DevOps engineer. On your very first day, your manager says:

"We have over 500 AWS resources spread across multiple regions. EC2 instances, S3 buckets, RDS databases, you name it. Can you find out which ones belong to the finance team, which ones are used for prod, and which ones we can shut down to save costs?"

It may sound simple, but it's a Herculean task as there are no labels, no categories, and no clue about ownership. You can’t tell if an instance is running a critical customer-facing app or just a leftover from last quarter’s testing.

This is where tagging becomes a lifesaver

With proper tagging, every resource carries its own identity. Instead of hunting down resource IDs, you’d see something like:

• Environment: Production

• Team: Finance

• Application: Billing

• Owner: John Doe

Now suddenly everything makes sense as we can filter out the resources by team, track cost per project, enforce compliance and even automate tasks like shutting down non-prod servers at night.

It can help us to identify which Team's “Friday-night experiment server” is still running and burning money & we can shut it down.

Also, during Audits, instead of manually chasing who owns which resource, tags act like nameplates: “This S3 bucket belongs to Finance, storing invoices,” making compliance checks painless.

Why not use Terraform here ?!

1. Terraform only knows what’s in its state; it would not touch it unless you import it.

2. Terraform enforces tags only when you run terraform apply

• That means compliance happens only at deploy time, not after.

• If someone forgets a tag while creating something manually in the AWS Console, Terraform won’t magically fix it until you go back and run it again.

3. Terraform doesn’t auto-heal; we need a re-run in Terraform

Why use the AWS native Tools (Config+SSM)?!

AWS Config is like a police officer that keeps checking:

“Hey, does this EC2 have the required Environment=Production tag?”

• If the tag is missing, it immediately calls SSM Automation, which is like a mechanic that fixes the problem by adding the missing tag.

• This happens automatically, all the time, even if someone created the resource manually from the AWS Console.

Demo Time

Below is a console-first, step-by-step guide that uses AWS Config (detect + trigger) and SSM Automation (remediate) to automatically add the tag Environment=Production to any EC2 instance that doesn’t have it.

Prequisites

• Admin user/user with the permission to create IAM Roles/ policies, S3 Buckets, AWS Config Rules, and SSM Automation Documents

• Region in which you will use this.

Turn on the AWS Config

• Open AWS Config → Get started (if not already enabled).

  

• Record all resources (or at least EC2 Instances).

• Delivery channel: select/create an S3 bucket for Config data.

  

• Click Enable.

  This creates the service-linked role AWSServiceRoleForConfig automatically.

Create the SSM Automation execution role

This is the role that the SSM Automation runbook will assume to call the EC2 API.

1. Open IAM → Roles → Create role.

2. Trusted entity: AWS service → choose Systems Manager → Systems Manager use case → Systems Manager again → Continue.

   

   

3. Attach the FullEC2Access for the Role

   

4. Name the role, e.g., ec2-tracking-compliance-role, and create it.

   

   NOTE: KEEP the Role ARN Handy.

Create the SSM Automation runbook (the fixer)

We’ll make a tiny runbook that calls the EC2 CreateTags API.

1. Open AWS Systems Manager → Automation → Create runbook.

2. Author in YAML, name it e.g., AutoTag-EC2-Environment.

1. Paste this content:

   ---
   schemaVersion: '0.3'
   description: "Auto-tag an EC2 instance with Environment=Production if missing"
   assumeRole: "{{ AutomationAssumeRole }}"
   parameters:
     AutomationAssumeRole:
       type: String
       description: "IAM role ARN for Automation to assume (e.g., arn:aws:iam::<acct-id>:role/SSM-Automation-AutoTag-Role)."
     InstanceId:
       type: String
       description: "EC2 Instance ID to tag (e.g., i-0123456789abcdef0)."
   mainSteps:
     - name: AddEnvironmentTag
       action: "aws:executeAwsApi"
       inputs:
         Service: ec2
         Api: CreateTags
         # EC2 CreateTags expects 'Resources'
         Resources:
           - "{{ InstanceId }}"
         Tags:
           - Key: Environment
             Value: Production

2. Create Runbook

   This runbook does not require SSM Agent on the instance, because it calls the EC2 API, not Run Command.

Allow AWS Config to start remediations

When AWS Config triggers remediation, it needs to start your Automation and pass the execution role.

Give Config permission to pass the Automation role

Open IAM → Roles → AWSServiceRoleForConfig.

Create the AWS Config managed rule

• Open AWS Config → Rules → Add rule.

• Search required-tags (managed rule) and select it.

  

• Scope of changes: select Specific resource types → choose EC2: Instance.

• Rule parameters:

  • tag1Key = Environment

  • (optional) tag1Value = Production

    • If set, resources with a different value are also non-compliant.

      

      

      

• Evaluation: leave default (change-triggered); you can enable Periodic if you want regular sweeps.

  

  

• Hit ->Add rule.

NOTE: This rule detects instances missing the tag or with the wrong value.

Attach remediation to the rule

• In AWS Config Rules, click your required-tags rule → Actions → Manage remediation.

• Remediation action: SSM automation document → select AutoTag-EC2-Environment.

  

• Parameters:

  • InstanceId → choose Resource ID (special token from Config).

  • AutomationAssumeRole → paste the role ARN from step 2 (e.g., arn:aws:iam:::role/SSM-Automation-AutoTag-Role).

  

• Remediation role: choose the default service-linked role for Config (or your custom one).

• Hit SaveChanges.
  
  NOTE: Now, when the rule finds a non-compliant EC2 instance, it will automatically start the runbook that adds the tag.

Check the flow

• Launch or pick an EC2 instance with no Environment tag.

  

• In AWS Config → Resources → EC2 Instances, wait for evaluation (or click Re-evaluate on the rule).

• The instance should show Noncompliant.

  

  

• In the rule page, open Remediation history → you should see an execution.

• In SSM → Automation → Executions, confirm the runbook ran successfully.

  

• Open the EC2 instance → Tags tab → you should now see Environment=Production.

  

Conclusion

Auto-tagging makes life easier when managing AWS resources. It ensures every EC2 instance carries the right tags automatically, so nothing slips through the cracks. During monitoring, this means you instantly know who owns what and why it exists. For compliance and audits, it saves you from the nightmare of manual fixes and missing data. In short, auto-tagging keeps your cloud clean, compliant, and audit-ready without the extra effort.

EzyInfra.dev – Expert DevOps & Infrastructure consulting! We help you set up, optimize, and manage cloud (AWS, GCP) and Kubernetes infrastructure—efficiently and cost-effectively. Need a strategy? Get a free consultation now!