AWS MAP 2.0 Tagging Guide: How to Track Credits Correctly

Which Resources Need MAP Tags?

Every AWS resource that is part of your migration scope needs the MAP tag. This includes EC2 instances, RDS databases, S3 buckets, Lambda functions, EBS volumes, and networking components. The MAP 2.0 Included Services List, updated in March 2026, covers over 200 AWS services.

Some resources are easy to miss. Elastic Load Balancers, NAT Gateways, CloudWatch log groups, and data transfer costs are often overlooked. These ancillary resources contribute to your total eligible spend. Missing them reduces your credit calculation.

As of December 2024, AWS expanded MAP to include Amazon Bedrock and select third-party Large Language Models. If your modernization strategy includes generative AI workloads, these resources are now eligible for MAP credits when properly tagged. This expansion opens new credit opportunities for organizations pursuing AI-driven modernization.

What Are the Most Common MAP Tagging Mistakes?

The first common mistake is using the wrong tag key. The key must be exactly map-migrated in lowercase. Variations like MAP-Migrated, map_migrated, or MapMigrated will not register. AWS tag keys are case-sensitive, and even a single character deviation breaks credit tracking.

The second mistake is applying tags only to primary compute resources. Teams tag their EC2 instances but forget the associated EBS volumes, Elastic IPs, and security groups. A thorough tagging strategy covers every resource in the migration scope, not just the visible ones.

Third, teams often delay tagging. Resources that run untagged for weeks or months generate spend that falls outside the MAP credit window. Best practice is to include tagging in your deployment automation so resources are tagged at creation. Understanding your MAP credits structure helps prioritize this effort.

Fourth, some organizations fail to update tags when resources are replaced or scaled. Auto Scaling groups, for example, launch new instances that need to inherit MAP tags. Without Launch Template configuration, new instances spin up untagged and credits are lost.

How Can You Automate MAP Tagging?

AWS Tag Editor is the simplest starting point. It lets you search for untagged resources across multiple regions and apply tags in bulk. For one-time cleanup, this tool works well. But it does not prevent future untagged resources from appearing.

AWS Config rules provide enforcement. You can create a rule that checks whether all resources carry the map-migrated tag. Non-compliant resources trigger notifications or automated remediation through AWS Systems Manager. This approach catches tagging gaps before they affect your credits.

Infrastructure as Code is the most reliable method. Whether you use CloudFormation, Terraform, or AWS CDK, you can embed MAP tags in every resource definition. This ensures that every resource deployed through your IaC pipeline is tagged from the moment of creation. No manual intervention required.

Service Control Policies (SCPs) add another layer. You can create an SCP that prevents resource creation in migration accounts unless the map-migrated tag is present. This is a preventive control rather than a detective one. It stops untagged resources from existing in the first place.

How Do You Validate Your Tagging Strategy?

Regular audits are essential. Schedule weekly reviews of your CUR data to verify that tagged spend aligns with your migration scope. AWS Cost Explorer lets you filter by tag, so you can quickly see your total MAP-eligible spend versus your expected spend.

Create a tagging compliance dashboard in AWS CloudWatch or your preferred monitoring tool. Track the percentage of resources with correct MAP tags across all accounts and regions. A compliance rate below 95% signals that credits are being left behind.

Work with your AWS partner to run quarterly reconciliation reports. Compare your tagged resource inventory against your original migration assessment. This catches drift where resources have been terminated, replaced, or moved without proper tag inheritance. Organizations using professional AWS migration services typically maintain compliance rates above 98%.

What Role Does the Cost and Usage Report Play?

The CUR is the source of truth for MAP credit calculations. AWS generates this report daily, and it includes every tagged resource along with its associated costs. Your MAP credits are calculated as a percentage of the eligible spend that appears in tagged CUR line items.

To maximize credit accuracy, enable the CUR with resource-level granularity. This breaks down costs by individual resource rather than just service category. Resource-level detail lets you verify that each migrated workload is contributing to your credit total.

Set up CUR delivery to an S3 bucket and configure Athena queries for automated analysis. This lets you build custom reports that show credit-eligible spend by application, team, or migration wave. These insights help you prioritize tagging remediation where the financial impact is greatest.

How Should You Structure Tags for Multi-Account Environments?

Most enterprise migrations use AWS Organizations with multiple accounts. Each account in your migration scope needs the same MAP tag applied consistently. The tag key and value remain identical across all accounts covered by your MAP agreement.

Use AWS Organizations tag policies to enforce consistency. Tag policies define the allowed values for specific tag keys. By setting a tag policy for map-migrated, you prevent teams from using incorrect values that would invalidate credit tracking.

Consider supplementary tags beyond the required MAP tag. Tags like migration-wave, source-server, and migration-date do not affect credit calculations. But they provide operational context that helps during the migrate and modernize phase and beyond.

How Do You Handle Tagging for Auto Scaling and Dynamic Resources?

Auto Scaling groups present a unique tagging challenge. When an Auto Scaling group launches new EC2 instances, those instances do not automatically inherit tags from other resources. You must configure the Auto Scaling group itself to propagate the map-migrated tag to every instance it creates.

In your Auto Scaling group configuration, add the MAP tag and set the PropagateAtLaunch property to true. This ensures every instance launched by the group — whether from scaling events, health check replacements, or scheduled actions — carries the correct tag from creation. Without this setting, dynamically launched instances generate untagged spend.

Lambda functions, Step Functions, and other serverless resources also need MAP tags. These resources are often created through CI/CD pipelines that may not include tagging logic. Update your deployment pipelines to inject MAP tags into every serverless resource definition. CloudFormation stack-level tags can help by automatically applying tags to all resources within a stack.

Container workloads on ECS and EKS require attention at multiple levels. Tag the ECS cluster, service definitions, and task definitions. For EKS, tag the cluster, node groups, and associated resources like load balancers created by Kubernetes ingress controllers. Container orchestrators create and destroy resources frequently, so automated tagging is essential.

What Happens After Your MAP Agreement Ends?

MAP tags should remain on resources even after your agreement concludes. They serve as a permanent record of which resources were part of the migration. This historical data is valuable for cost analysis, compliance reporting, and future migration planning.

Credits earned during the MAP period continue to apply until they are consumed or expire, depending on your agreement terms. Removing tags after the agreement ends does not claw back previously earned credits. But keeping them supports long-term cost attribution.

If you plan a second MAP engagement for additional workloads, existing tags from the first engagement remain valid. New migrations receive their own tag values. This separation lets you track credits from multiple MAP agreements independently within the same AWS environment.

How Do Third-Party Tools Help with MAP Tagging?

Several third-party platforms offer automated MAP tagging capabilities. Tools like nOps provide a MAP Tracker that automatically identifies untagged resources, applies the correct tags, and monitors compliance across your AWS accounts. These platforms reduce the manual effort required to maintain tagging discipline.

CloudHealth by Broadcom offers MAP credit categorization features that reconcile your tagged spend against received credits. This reconciliation helps identify discrepancies where tags exist but credits are not being calculated correctly, or where credit amounts do not match expected percentages.

Regardless of which tools you choose, the principle remains the same. Automated tagging eliminates human error, continuous monitoring catches drift, and regular reconciliation ensures you capture every credit your migration generates. The cost of these tools is typically a fraction of the credits they help recover.

Getting Your Tagging Strategy Right from Day One

MAP 2.0 tagging is straightforward in concept but demands discipline in execution. Start by documenting your tag key-value pair, distribute it to every team involved in the migration, and automate enforcement through SCPs, Config rules, and IaC templates.

The financial stakes are significant. With MAP offering up to 25% of eligible spend back as credits, every untagged resource is money left on the table. A 2,000-server migration with $5 million in annual AWS spend could lose hundreds of thousands in credits from tagging gaps alone.

Partner with an experienced AWS migration services provider like Opsio to establish tagging governance before your first workload moves. The right foundation ensures you capture every credit your migration earns.