Recommended AWS Resource Tagging Strategy

This document provides a comprehensive tagging framework for AWS EC2 and other AWS resources, including S3, RDS,
Lambda, and networking components. Tagging improves visibility, cost allocation, governance, and automation across environments.

Core Identification Tags

Cost Allocation & FinOps Tags

Security & Compliance Tags

Operations & Automation Tags

Cloud Migration & Governance Tags

Networking & Infrastructure Tags

Example Tagging Policy (JSON)

You can enforce tagging consistency via AWS Organizations Tag Policies or AWS Config rules. Example baseline policy:

{
  "tags": {
    "Environment": { "tag_key": "Environment", "tag_value": ["dev", "test", "prod"] },
    "Owner": { "tag_key": "Owner", "tag_value": ".*@company.com" },
    "CostCenter": { "tag_key": "CostCenter", "tag_value": "^[A-Z]{2}[0-9]{4}$" }
  }
}

The post AWS Resource Tag Recommendations appeared first on AWS Security Architect.

Overview

Compliance evidence refers to proof of control implementation and effectiveness—logs, configurations, reports, or monitoring records that demonstrate adherence to frameworks such as SOC 2, ISO 27001, HIPAA, or PCI DSS.

AWS supports two main categories of evidence:

1. AWS-Managed Evidence (for AWS’s own controls)
2. Customer-Managed Evidence (for your account and workloads)

1. AWS-Managed Evidence (AWS’s Shared Responsibility)

AWS provides attestation reports and certifications proving that AWS infrastructure and services meet global standards.

Where to Access:

• AWS Artifact – the centralized audit and compliance portal in the AWS Management Console.

Evidence Available in AWS Artifact:

Purpose: Auditors can download these to verify that AWS’s underlying infrastructure is compliant.

2. Customer-Managed Evidence (Your Shared Responsibility)

You are responsible for collecting evidence for your AWS account, configurations, and applications.

Common AWS Sources of Customer Evidence

3. AWS Audit Manager – Automated Evidence Collection

AWS Audit Manager is purpose-built for audit preparation. It automates evidence collection and maps data to compliance frameworks.

How It Works

1. Select a framework (e.g., CIS AWS Foundations, ISO 27001, PCI DSS, HIPAA).
2. Audit Manager automatically collects evidence from multiple AWS services (CloudTrail, Config, IAM, Security Hub).
3. Evidence is stored in Audit Manager’s evidence repository with metadata (timestamp, control mapping, source).

Examples of Automatically Collected Evidence

Exporting Evidence

• Export to S3 for auditors
• Share via Audit Manager assessment reports
• Retain per policy (e.g., 7 years for SOC audits)

4. Manual Evidence Storage Locations

Manual proof (screenshots, policies, reports) is stored and managed by the customer. Common storage options include:

• Amazon S3 (versioned bucket): Long-term, immutable audit repository.
• AWS Audit Manager Manual Upload: Attach manual files directly to controls.
• AWS WorkDocs / External GRC Systems: Used for collaborative evidence management.

Encryption (SSE-KMS) and versioning are recommended for integrity and retention.

5. Summary Table

6. Best Practice Workflow

1. Enable CloudTrail, Config, and Security Hub across all accounts.
2. Set up AWS Audit Manager with a baseline framework (CIS or ISO 27001).
3. Continuously collect and review evidence automatically.
4. Store manual evidence in versioned S3 with lifecycle policies.
5. Use AWS Artifact for AWS-provided compliance documentation.
6. Provide evidence packages via Audit Manager or secure S3 export.

The post AWS Audit Evidence for Compliance Purposes appeared first on AWS Security Architect.

AWS Systems Manager (SSM) for Patch Management

Centralized, automated scanning, installation, and compliance reporting for EC2 and on-premises servers.

Diagram

Overview

AWS Systems Manager (SSM) provides native, agent-based patch management across EC2 instances and on-premises servers (via hybrid activations). The Patch Manager capability automates:

• Scanning for missing patches
• Approving/denying updates via patch baselines
• Installing patches during defined maintenance windows
• Recording compliance in a central dashboard and integrated services

Key Components & Workflow

1) SSM Agent

• Lightweight agent on each managed instance.
• Communicates over HTTPS (443) to SSM endpoints; no inbound SSH/RDP required.
• Executes patch commands and reports results.
• Supported OS: Amazon Linux, RHEL, Ubuntu, SUSE, Windows Server; also on-prem nodes via hybrid activation.

2) Patch Baselines

• Define which patches are approved/denied.
• Use AWS-provided defaults or create custom baselines.
• Rules by classification (Security/Critical), severity, product family (e.g., Windows Server 2019), and auto-approval delays (e.g., 7 days after release).

3) Patch Groups

• Tag-based logical groupings (e.g., PatchGroup=Production).
• Associate different baselines per environment/workload.

4) Maintenance Windows

• Define when patching runs (e.g., Sun 02:00–04:00).
• Register tasks that run SSM documents (e.g., AWS-RunPatchBaseline).

5) Patch Manager Operations

6) Compliance Reporting

• Instance status: Compliant, Non-Compliant, or Unknown relative to its baseline.
• Visible in SSM Compliance dashboard; also integrates with AWS Config, Security Hub, and EventBridge/SNS for alerts.

Example: Automated Patch Flow

1. Tag instances with PatchGroup=Prod.
2. Associate a custom baseline (e.g., only Security and Critical updates; 7-day auto-approval delay).
3. Create a maintenance window: Sundays 02:00–04:00.
4. Register a task using AWS-RunPatchBaseline to Scan then Install.
5. SSM Agent downloads and installs approved patches, optionally reboots, then reports to Compliance.

Integrations

• AWS Config – Tracks drift & state changes.
• AWS Security Hub – Aggregates patch findings.
• AWS Organizations – Manage patching at scale across accounts.
• Amazon EventBridge / SNS – Alerting on failures/drift.

Advantages

• Centralized, agent-based control (no SSH/RDP).
• Works for EC2 and on-prem nodes.
• Custom baselines, patch groups, and maintenance windows.
• Strong compliance visibility and native integrations.

The post AWS Patch Management using Systems Manager appeared first on AWS Security Architect.

AWS Retroactive Tagging – Enforcement Playbook

“Retroactive” tagging (fixing existing resources) usually takes a mix of detection, bulk edit, and guardrails so drift doesn’t come back. Here’s a practical playbook with concrete AWS-native options you can use right away:

1) Find untagged or wrongly-tagged resources

• AWS Resource Explorer / Tagging Console (Resource Groups → Tag Editor): search across accounts/Regions; export lists; bulk-apply tags.
• AWS Resource Groups Tagging API: programmatic inventory of tags across services.
  • GetResources to list by TagFilters; TagResources to apply in bulk across services.
  • Handy for scripts/Lambda to sweep and tag nightly.
• AWS Config (Detective): enable the managed rule required-tags (or custom rules) to mark resources non-compliant when keys/values are missing.
• Cost Explorer / CUR (cost allocation tags): turn on Untagged costs and Cost categories to see where spend lacks tags and prioritize remediation.

2) Bulk tag existing resources (the “retroactive” fix)

• Tag Editor (console): filter → select → apply tags to many resources in one shot.
• CLI/SDK sweep using Tagging API:

  aws resourcegroupstaggingapi get-resources --resource-type-filters ec2:instance ...
  aws resourcegroupstaggingapi tag-resources --resource-arn-list arn1 arn2 --tags Env=Prod Owner=TeamX

• Event-driven auto-tagging: EventBridge rule on Create* API calls → Lambda reads CloudTrail event to infer owner/account/OU and backfill tags on the new resource; schedule a nightly sweep for older ones too.
• AWS Config + SSM Automation remediation: attach an SSM document that, on non-compliance, writes default tags (e.g., CostCenter, Environment) or looks up a CMDB to set accurate values.

3) Enforce going forward (so you don’t have to retro-tag again)

• SCP deny without mandatory tags (preventive): At the org/OU, block Create* when required tags aren’t supplied.

  {
    "Version": "2012-10-17",
    "Statement": [{
      "Sid": "DenyCreateWithoutTags",
      "Effect": "Deny",
      "Action": ["ec2:RunInstances","rds:CreateDBInstance","s3:CreateBucket","*"],
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:RequestTag/CostCenter": "true",
          "aws:RequestTag/Environment": "true"
        }
      }
    }]
  }

  Tip: you can also require that specific tag keys exist using aws:TagKeys, and for certain services require propagation (e.g., EC2 TagSpecifications in RunInstances).

• IAM conditions (fine-grained): on roles used to provision, require tags or specific values:

  "Condition": {
    "ForAllValues:StringEquals": { "aws:TagKeys": ["CostCenter","Environment"] }
  }

• AWS Organizations Tag Policies (governance, not hard enforcement): define allowed keys/values and get org-wide compliance reports; pairs well with Config for enforcement.
• AWS Control Tower guardrails (where used): use detective (and when available, proactive) controls tied to tag compliance, plus blueprints that inject mandatory tags via IaC.
• IaC defaults:
  • CloudFormation: set Tags on stacks/stacksets and use Stack-level Tags so resources inherit.
  • Terraform: use default_tags at provider level; enforce via tflint/policy-as-code (OPA/Conftest).
  • Service Catalog: TagOptions / constraints to force tag keys/values on provisioned products.

4) “Encourage” retro-tagging on existing prod by restricting ops

• SCP conditional denies on untagged resources: prevent StartInstances, Modify*, or Delete* when aws:ResourceTag/CostCenter is absent. That motivates teams to add tags without fully blocking their ability to create in greenfield.

{
  "Sid": "DenyOpsOnUntagged",
  "Effect": "Deny",
  "Action": [
    "ec2:StartInstances",
    "ec2:ModifyInstanceAttribute",
    "ec2:TerminateInstances"
  ],
  "Resource": "arn:aws:ec2:*:*:instance/*",
  "Condition": { "Null": { "aws:ResourceTag/CostCenter": "true" } }
}

5) Useful “auto-fill” patterns for retro tags

• Creator/Owner tag from CloudTrail: parse userIdentity and set Owner, CreatorArn, or ProvisioningTool.
• Env/CostCenter from account or OU: map Account ID → Environment, CostCenter via a lookup (DynamoDB/SSM Parameter Store).
• Propagate from parents:
  • EC2 from ASG/Launch Template tags
  • EBS from instance tags
  • EKS nodes from cluster tags
  • S3 by org policy + automation script

6) Reporting & accountability

• Tag Policy compliance reports (per OU/account/service) to track gap closure.
• Budget filters by tag + Cost Categories that include “Untagged” to show chargeback/showback.
• Dashboards (QuickSight/Athena over CUR) for “Untagged spend by account/service”.

Quick start recipe (minimal friction)

1. Turn on Config required-tags across all accounts/Regions.
2. Use Tag Editor to bulk tag the top 20% cost drivers.
3. Deploy a Lambda sweep using the Tagging API to fill defaults nightly.
4. Add a lightweight SCP denying Create* without Environment + CostCenter in dev/sandbox OUs first.
5. Enable Organizations Tag Policies to standardize values and monitor drift.
6. Make mandatory tags part of CloudFormation/Terraform scaffolding.

If you want, tell me your mandatory keys (e.g., Environment, Application, CostCenter, Owner), and I’ll draft:

• an org-ready SCP pack (create + modify + ops-on-untagged),
• a Config + SSM remediation document, and
• a Lambda that retro-tags from CloudTrail and an account/OU map.

The post Retroactive Tagging for AWS Resources appeared first on AWS Security Architect.