AWS Resource Groups and Tag Editor

Tags are metadata labels consisting of a key-value pair (e.g., Environment:Production) that you can attach to most AWS resources. They are not a service but a feature integrated across hundreds of AWS services. Tags enable you to:

Tags are free, but there are limits: each resource can have up to 50 tags. Tag keys must be unique per resource, and both keys and values are case-sensitive. AWS does not enforce any tag schema—you define your own naming conventions. However, AWS provides predefined tags for some services (e.g., aws:cloudformation:stack-name).

A Resource Group is a collection of AWS resources that match a specified set of criteria. There are two types:

Resource Groups are not containers; they are queries that return a set of resource ARNs. You can perform actions on the group as a whole, such as viewing aggregated CloudWatch metrics or running Systems Manager commands across all instances in the group.

Tag Editor is a tool in the AWS Management Console that allows you to:

Tag Editor uses the Resource Groups Tagging API (RGT API) behind the scenes. The API supports operations like TagResources, UntagResources, GetResources, and GetTagKeys. The API is rate-limited; for example, TagResources and UntagResources have a maximum of 20 resources per call. For bulk operations, you must iterate.

When you create a tag-based resource group, you specify a tag key and optionally a tag value. AWS builds a query that is executed against the Resource Groups Tagging API. The group's membership is evaluated each time you view the group or use it in an action—it is not a static snapshot. This means group membership is always up-to-date.

For CloudFormation stack-based groups, the group is linked to the stack ID. When you delete the stack, the group is also deleted (or becomes empty).

Using AWS CLI:

Create a tag-based resource group:

aws resource-groups create-group \
    --name MyProjectGroup \
    --resource-query '{"Type":"TAG_FILTERS_1_0","Query":"{\"ResourceTypeFilters\":[\"AWS::AllSupported\"],\"TagFilters\":[{\"Key\":\"Project\",\"Values\":[\"Alpha\"]}]}"}'

List resources in a group:

aws resource-groups list-group-resources --group MyProjectGroup

Tag resources using Tag Editor (RGT API):

aws resourcegroupstaggingapi tag-resources \
    --resource-arn-list arn:aws:ec2:us-east-1:123456789012:instance/i-abc123 \
    --tags Key=Project,Value=Alpha

Find resources missing a tag:

aws resourcegroupstaggingapi get-resources \
    --tag-filters Key=Project --no-include-compliance-details

Using IAM Policies:

To enforce tag-based access, use IAM conditions like aws:ResourceTag and aws:RequestTag. Example policy that allows starting instances only if they have tag Environment=Production:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:StartInstances",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Environment": "Production"
                }
            }
        }
    ]
}

A large enterprise runs hundreds of EC2 instances, RDS databases, and Lambda functions across multiple projects. Without tags, the finance team cannot attribute costs to specific projects. The company implements a mandatory tag Project with values like Alpha, Beta, Gamma. They use AWS Organizations tag policies to enforce that all new resources must have this tag. Tag Editor is used to backfill tags on existing resources. They then create resource groups per project (e.g., Project-Alpha) and use Cost Explorer to filter costs by the Project tag. This allows accurate chargeback to each business unit. A common misconfiguration is allowing resources to be created without tags, leading to untagged resources that are invisible in cost reports. The company sets up an AWS Config rule to detect untagged resources and triggers a Lambda function to automatically tag them with Project=Unknown. They also use IAM policies to deny creation of resources without the required tag.

A DevOps team manages a fleet of 500 EC2 instances spread across multiple environments. They use tags to differentiate environments: Environment=Production, Staging, Development. They create resource groups for each environment, e.g., Staging-Instances. Using AWS Systems Manager, they schedule patching for the staging group on weekends and for production on a different schedule. They also use the resource group as a target for Run Command to execute a script that collects logs. Without resource groups, they would have to manually maintain instance lists or use complex scripts. A common issue is that the resource group query may include instances that are not supposed to be patched (e.g., if tags are incorrectly applied). To mitigate, they use tag policies to enforce consistent tag values. They also set up CloudWatch Events to trigger a Lambda function that validates tags on new instances and alerts if they are missing.

A security team wants to enforce that only users in the 'developers' group can terminate EC2 instances in the Development environment, but not in Production. They create an IAM policy that allows ec2:TerminateInstances only if the resource tag Environment equals Development. They also add a condition that the request must include the tag Purpose=Testing to prevent accidental termination. This is implemented using aws:ResourceTag and aws:RequestTag conditions. Resource groups are not directly used for access control—tags are. However, resource groups help administrators quickly see all instances in an environment. A common mistake is to use resource group ARNs in IAM policies; resource groups are not resources you can control access to—they are queries. The exam tests this distinction.