The purpose of the Migration Acceleration Program (MAP) is to help AWS customers accelerate their migration to AWS. As a customer moves their existing on-premises workloads to AWS, the migrated workloads are identified through a mechanism called tagging, which enables them to display AWS Cost and Usage Report (CUR) based on the migrated resources, which can be utilized to report migrated workloads’ spend and generate appropriate credits.
You must follow the MAP Tagging Instructions to turn on Daily Cost and Usage Reporting and Tag Based Cost Allocation in the AWS Console for each Designated Account in your Migration Plan at least 48 hours before migrating MAP Workloads. The Cost and Usage Reports must be named with the pre-fix: “map-migrated-report”. We will access the Cost and Usage Reports in order to calculate your MAP Credits. All Designated Accounts identified in your Migration Plan must be Management Accounts with Cost and Usage Reporting turned on in order for Spend to be tracked and included in MAP Credit calculations.
Tagging your migrated resources is a requirement as part of the MAP 2.0 program. Not enabling CUR or not tagging the migrated resources will result in not applying MAP credits in your account.
This process is divided in 3 steps
The next section will walk you through step-by-step implementation of this mechanism.
This guide helps customers with their migration to AWS as part of the Migration Acceleration Program by detailing how to use tagging for their migrated workloads. Tagging enables customers to display Cost and Usage Report (CUR) based on the migrated resources, which can be utilized to report migrated workloads’ spend and generate appropriate credits.
This guide is only valid for customers who signed MAP term after 12-April-2022. For customers who signed before 12-April-2022, please use the following reference guide https://s3-us-west-2.amazonaws.com/map-2.0-customer-documentation/html/latest/en/index.html
You must follow the MAP Tagging Instructions to turn on Daily Cost and Usage Reporting and Tag Based Cost Allocation in the AWS Console for each Designated Account in your Migration Plan at least 48 hours before migrating MAP Workloads. The Cost and Usage Reports must be named with the pre-fix: “map-migrated-report”. We will access the Cost and Usage Reports in order to calculate your MAP Credits. All Designated Accounts identified in your Migration Plan must be Management Accounts with Cost and Usage Reporting turned on in order for Spend to be tracked and included in MAP Credit calculations.
Customers are responsible for making their own independent assessment of the information in this document. The content provided in this document: (a) is for informational purposes only, (b) represents current AWS product offerings and practices, which are subject to change without notice, and (c) does not create any commitments or assurances from AWS or its affiliates, suppliers, or licensors. AWS content, products, and services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document does not modify those agreements.
There are 2 existing methods to enable CUR in your AWS account and have it ready for MAP. The CUR setup can be MANUAL or AUTOMATED through the utilization of AWS CloudFormation Scripts.
Please check below to determine which process is suitable for your needs.
Automated (RECOMMENDED!) | Manual | AMS Advanced Customers |
---|---|---|
![]() |
![]() |
![]() |
This is a one-time process done for each management (payer) account in your Migration Plan, and needs to be done at least 48 hours before the planned migration.
In the case of SAP workloads if you are participating in MAP for SAP, this step must be done 48 hours before a purchase of RI or Savings Plan, not the actual migration.
The steps mentioned above should be used when configuring CUR on your AWS account for the first time, with a single Migration Plan MPE number. For multiple Migration Plan MPE numbers, execute one of the options above, then add the additional accounts later using the manual process listed here.
You can utilize the Automated option to quickly setup your Cost and Usage Report (CUR) in your management account(s) listed in your Migration Plan and generate a Server ID that you will be using to tag your MAP eligible workload.
With the Automated option, you use a CloudFormation template that creates the necessary resources and configuration in your account to correctly setup your Cost and Usage Report (CUR) for MAP.
The following steps should be used when configuring CUR your AWS account for the first time, with a single Migration Plan MPE number. For multiple Migration Plan MPE numbers, please add the additional accounts later using the manual process listed here.
MPE
followed by the MPE number. MPE
is case sensitive and must be upper case. E.g. MAP12345
The CUR should have now been created. To confirm, go to Services > Billing > Cost & Usage Reports. You should see a map-migrated-report report name.
Only 1 (one) CUR with the prefix map-migrated should exist in the management (payer) account. Having multiple CUR with prefix map-migrated will disrupt the credit calculation.
In the next 24 hours, your first report will be delivered to the Amazon S3 bucket you configured during the report creation.
Step 1 - Setup CUR & Generate ServerID is completed! Please move forward to Step 2 - Activating Tags
This page describes how to manually setup CUR and generate the Server ID in AWS Migration Hub. If you already used the Setup CUR - AUTOMATED approach, the steps here will not be necessary and you can skip to Step 2 - Activating Tags
This Video Tutorial provides guidance to perform the necessary steps to setup CUR and activate tags as described in this section of the guide.
The Cost and Usage Report (CUR) is enabled once per management account by the team with the right privileges to the management account. An associated Cost and Usage Report then needs to be created to allow tracking of MAP tagged resources.
Your Cost and Usage Report now displays in the console as follows
In the next 24 hours, your first report will be delivered to the Amazon S3 bucket you configured during the report creation
Only 1 (one) CUR with the prefix map-migrated should exist in the management (payer) account. Having multiple CUR with prefix map-migrated will disrupt the credit calculation.
For general MAP workloads (workloads other than Database & Analytics workloads, and customers in the MAP for SAP program), we will use the tag key map-migrated. For Database & Analytics workloads, and customers in the MAP for SAP program, an alternative tag(s) will be required. Refer to the section What tags should I use? for SAP and Database & Analytics workloads.
After setting up the Cost and Usage Report, you need to activate the tag allocation for the MAP tags. To do this, you need to initially use those tags at least for one of the resources. For this purpose, use the Amazon S3 bucket you’ve configured to deliver the report in the previous step to have the following tags applied but with no value:
Tag keys are case sensitive. Make sure you use lower case in all the tag names
samplehostname-MPE
. The MPE number is provided at the top of your Migration Plan. E.g. samplehostname-MPE12345aws-migration-project-id:MPE
. The MPE number is provided at the top of your Migration Plan. MPE
is case sensitive and must be upper case. E.g. aws-migration-project-id:MPE12345Now, you need to import the CSV file into the Migration Hub:
In the example above MPE11111 is used. You should see the MPE number related to your MAP term.
To find the value that should be used as part of the migration requirements, open AWS Console, Migration Hub, Servers. Select the server that represents samplehostname-MPE. Look for the Server ID value. The Server Id value starts with d-server-
and is followed by a unique identification value. E.g. of Server Id is d-server-02q6ulnles5jdj
.
This page describes how to request Amazon AMS team to setup CUR in your account. Only use this instruction if you are an Amazon AMS Advanced Customer. If you are an AWS AMS Accelerate Customer, please follow the AUTOMATED or MANUAL options.
To setup the MAP 2.0 automation solution there is one manual RFC that needs to be submitted from your management account. After the RFC is complete, the AMS team will provide you the Server ID value which will be used to tag your migrated workloads to calculate MAP Credit.
Submit a Create other RFC requesting an IAM role to be deployed and a CloudFormation stack to be created. Use the following language for the RFC details:
Account: Management account
RFC Type: Create other
Details:
Please execute the following steps: Create the IAM role needed for the MAP 2.0 Automator from this link:
https://map-automation.s3.us-west-2.amazonaws.com/cur-server-ids-automator-iam.yaml
Create a stack using the following CloudFormation from this link:https://map-automation.s3.us-west-2.amazonaws.com/cur-server-ids-automator-ams.yaml
Stack name:
map-automator
Parameters
S3Region - {{Choose the home region for MALZ}}
MPE - {{Customer MPE ID (e.g: MPE12345)}}
Finally, from the stack output, provide the customer with theServerID
value. This is the value they must use when tagging their workloads.
Only regions supported by AWS Migration Hub are valid. For a list of the support regions check https://docs.aws.amazon.com/general/latest/gr/migrationhubn.html.
After setting up CUR you have to wait 24 hours before executing the steps below.
Regardless of using the AUTOMATED or the MANUAL process, the tags will have to be manually activated in the billing console.
As part of this process, we generate all the tags that you may use for MAP. For general MAP workloads (workloads other than SAP, and Database & Analytics workloads), you only need to activate map-migrated tag.
For SAP, and Database & Analytics workloads, please refer to the section What tags should I use?.
Tag keys are case sensitive. All cost allocation tags for MAP are in lower case.
The CloudFormation template used in the previous section creates the necessary tags. You need to activate the cost allocation tags that apply to your workload using the following steps:
Once you use your cost allocation tags for the first time (e.g., map-migrated), it may take up to 24 hours to be visible in your account. If you can’t see the tags in your account as shown above, revisit this step after 24 hours
Skip to 04:17
Now that AWS CUR is set up, the AWS tags have been activated in CUR, and you already have your Server ID it’s time to start tagging the migrated resources properly so that they are included in your MAP Credit calculations.
If you don’t properly identify the Migration Plan for a MAP Workload when generating Server IDs or tagging MAP Workloads, and multiple Migration Plans utilize the same Designated Account, we will include that MAP Workload in the Spend calculations for the most recently accepted Migration Plan.
If you’re using an Infrastructure-As-Code tool (e.g., AWS CloudFormation or Terraform) to create your migrated resource on AWS then you can add a tag line to your templates with the Server ID generated in Step 1.
If you’re creating resources directly using AWS Console then you can tag the resources individually, or you can bulk tag them using AWS Tag Editor.
Automation | Manual | AWS Tag Editor |
---|---|---|
![]() |
![]() |
![]() |
Before start tagging, make sure your CUR is set up as per Step 1 - Set up CUR and tags are active as per Step 2 - Activate Tags.
AWS CloudFormation enables you to create and provision AWS infrastructure deployments predictably and repeatedly. It helps you leverage AWS products such as Amazon EC2, Amazon Elastic Block Store, Amazon SNS, Elastic Load Balancing, and Auto Scaling to build highly reliable, highly scalable, cost-effective applications in the cloud without worrying about creating and configuring the underlying AWS infrastructure. AWS CloudFormation enables you to use a template file to create and delete a collection of resources together as a single unit (a stack).
You can use the Resource Tags property to apply tags to resources, which can help you identify and categorize those resources. You can tag only resources for which AWS CloudFormation supports tagging. For information about which resources you can tag with CloudFormation, see the individual resources in AWS resource and property types reference.
In this section we will show you a simple example of using Cloudformation for tagging the migrated resources. For further information on how to use CloudFormation, please check the service documentation page
{
"Key" : "map-migrated",
"Value" : "d-server-12345"
}
Replace d-server-12345 by ServerID
from Step 1
The AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to define your cloud application resources using familiar programming languages.
In this section we will show you a simple example of using AWS CDK to tag the resources. For more information please visit CDK documentation. A tag applied to a given construct also applies to all of its taggable children. Tags are included in the AWS CloudFormation template synthesized from your app and are applied to the AWS resources it deploys.
Tags.of(myConstruct).add('map-migrated', 'd-server-12345');
Replace d-server-12345 by ServerID
from Step 1
AWS Application Migration Service (AWS MGN) is the primary migration service recommended to lift and shift your applications to AWS. Customers considering CloudEndure Migration are encouraged to use AWS Application Migration Service for future migrations. For more details on how to use MGN for tagging the migrated resources please check the MGN service documentation
In this section we will show you a simple example of using MGN to tag the migrated resources.
Add tags
box, use map-migrated
as the Tag Key
and use the ServerID
from Step 1 as the Value
then click Add
.All the resources migrated by MGN will receive the designated tags.
CloudEndure Migration Factory Solution coordinates and automates large scale migrations to the AWS Cloud, involving numerous servers. Enterprises can improve performance and prevent long cutover windows by automating manual processes and integrating multiple tools efficiently. This is possible through this solution’s orchestration platform options, which includes CloudEndure Migration and, as of version 2.0.0, AWS Application Migration Service (AWS MGN). We recommend AWS MGN to rehost servers to AWS at scale. Today, this solution is used by AWS Professional Services, AWS Partners, and other enterprises. For more details on CEMF, please check the CEMF solutions page
In this section we will show you a simple example of CEMF tagging the migrated resources.
To add tags to all imported servers in CEMF, a special script is required. Please use the script located here
Add tags
.Add tags
box, use map-migrated
as the Tag Key
and use the ServerID
from Step 1 as the Value
then click Add
.The AWS Serverless Application Model (SAM) is an open-source framework for building serverless applications. It provides shorthand syntax to express functions, APIs, databases, and event source mappings. With just a few lines per resource, you can define the application you want and model it using YAML. During deployment, SAM transforms and expands the SAM syntax into AWS CloudFormation syntax, enabling you to build serverless applications faster.
In this section we will show you a simple example of using AWS SAM to tag the resources. For more information please visit SAM documentation.
Globals:
Function:
Tags:
HttpApi:
Tags:
Replace d-server-12345 by ServerID
from Step 1
In order to start tagging, you need the generated Server ID from Step 1 - Set up CUR & Generate Server ID.
In this section we will show you a simple example of manual tagging for one of the migrated resources. We will use the AWS Management Console for this purpose.
If you used the Step 1 - Set up CUR & Generate Server ID process to generate your Server ID’s, please use the CloudFormation output value Server ID as reference for tags.
Add tags
.Add tags
box, use map-migrated
as the Tag Key
and use the Server ID
you copied from the previous step as the Value
then click Add
.
For more details about tagging resources, please use AWS documentation.
In order to start tagging, you need the generated Server ID from Step 1 - Set up CUR & Generate Server ID.
In this section we will show you a simple example of manual tagging for one of the migrated resources. We will use the AWS Management Console for this purpose.
If you used the Step 1 - Set up CUR & Generate Server ID process to generate your Server ID’s, please use the CloudFormation output value ServerI D as reference for tags.
The Server Id value that must be used as part of the tagging process starts with d-server-
and is followed by a unique identifier. The Server Id value for your migration can be found here
For Migration Plans in the MAP for SAP program, using the MAP for SAP Migration Tracking and Incentive Guide, an alternative tag, map-sap
, will be required to be activated and used for MAP for program. Migration Plans that are not part of MAP for SAP must not use this tag.
This tool was developed to guide you to select the right tags for your workload.
For Migration Plans whose Migration Tracking and Incentive Guide includes Databases and Analytics MAP Credits.
For Migration Plans in the MAP for SAP program, using the MAP for SAP Migration Tracking and Incentive Guide. Migration Plans that are not part of MAP for SAP do not use these tags.
Some examples on what tags should be used during your MAP 2.0 migration
Select Source | Select Destination |
Context: | |
Tag keys to be used: | |
Tag Examples: | |
Additional Notes: |
For Migration Plans whose Migration Tracking and Incentive Guide includes Databases and Analytics MAP Credits, an alternative tag(s) needs to be activated in cost allocation tags and to be used for the migrated resources. Several scenarios based on the source and destination are listed in the following table.
For a complete list of services that are included in MAP - Database & Analytics (DB&A) please check this link
Source | Destination | Tag Key | Tag Value |
---|---|---|---|
On-premises Commercial DB&A | Any AWS DB&A Service | map-dba | ServerID generated from Step 1 |
On-premises non-commercial DB&A | Any AWS DB&A Service | map-migrated | ServerID generated from Step 1 |
On-premises Commercial DB&A | EC2 | map-migrated | ServerID generated from Step 1 |
On-premises non-commercial DB&A | EC2 | map-migrated | ServerID generated from Step 1 |
EC2 Commercial DB&A | Any AWS DB&A Service | map-dba aws-migration-project-id |
ARN value of the source EC2 instance MPE Number |
EC2 non-commercial DB&A | Any AWS DB&A Service | map-migrated aws-migration-project-id |
ARN value of the source EC2 instance MPE Number |
A commercial database is defined as any third-party database engine, data warehouse, or analytics offering for which you have paid a fee for use rights, enhancements, maintenance, or support for that third party offering. A non-commercial database is defined as any third-party database engine, data warehouse, or analytics offering for which you have not paid a fee for use rights, enhancements, maintenance, or support for that third party offering.
For more information on ARN format, please check the ARN section on Additional Resources page.
MPE is case sensitive and must be upper case.
For Migration Plans in the MAP for SAP program, using the MAP for SAP Migration Tracking and Incentive Guide, an alternative tag, map-sap
, will be required to be activated and used for MAP for program. Migration Plans that are not part of MAP for SAP do not use this tag.
Source | Destination | Tag Key | Tag Value |
---|---|---|---|
on-premises | AWS | map-sap | ServerID generated from Step 1 |
When using AWS Launch Wizard for SAP to deploy your SAP workloads, please make sure you define the MAP tags as part of your infrastructure definition. Tag Key:map-sap, Tag Value: ServerID generated from Step 1.
For a complete list of services included in MAP for SAP, please check this link
For a complete list of services that are eligible for MAP, please check this link
Customer is moving from on-premises to AWS using a lift-and-shift (re-hosting) migration pattern, and decided to use MGN for the migration.
Tag Key (automated) | Value (automated) |
---|---|
map-migrated |
ServerID from Step 1 |
Customer is moving different workloads from on-premises to AWS using various migration patterns (re-hosting, re-architecting, etc.) as part of general MAP.
Tag Key | Value |
---|---|
map-migrated |
ServerID from Step 1 |
Customer is moving a commercial databases from Amazon EC2 instances on AWS to Amazon RDS as part of MAP for Database.
Tag Key | Value |
---|---|
map-dba |
ARN value of the source EC2 instance |
aws-migration-project-id |
MPE Number |
Customer is moving from on-premises commercial database server to Amazon DynamoDB. This example is for a Migration Plan that is eligible for Database & Analytics MAP Credits, including both if you are modernizing directly from on-premises or modernizing after migrating to EC2 as a first stage of MAP.
Tag Key | Value |
---|---|
map-dba |
ServerID from Step 1 |
For more information on ARN format, please check the ARN section on Additional Resources page.
A complete and successful tagging setup should result in the following:
In the management/payer account console, Open Billing Dashboard, Cost & Usage Reports
A map-migrated-report should exist, and have the following configurations
In the management/payer account console, Open Billing Dashboard, Cost allocation tags. Search for map-
.
The following cost allocation tags should be in Active
status
In the management/payer account console, Open CloudFormation, select the Stack that was used in Step 1. Select the Outputs tab.
You can use the Tag Editor for validating the workloads that have been tagged.
Majority of usecases require the use of only one Server Id generated in Step 1. There are a few special cases where it is required to generate additional Server Id. The special cases and the procedure to generate additional server Id are listed below:
You will be required to generate additional Server Id for the following:
169.254.37.81
or 169.254.37.82
or so on. The simple method to create an unique IP Address is increment last octet in the example.samplehostname-1-MPE
. The MPE number is provided at the top of your Migration Plan. Please use an Hostname that is NOT already in the Server list. Assuming MPE number is 12345, example Hostname can be samplehostname-1-MPE12345
or samplehostname-2-MPE12345
or so on. The simple method to create an unique Hostname is increment digit between the two -
.aws-migration-project-id:MPE
. The MPE number is provided at the top of your Migration Plan. MPE
is case sensitive and must be upper case. E.g. aws-migration-project-id:MPE12345
In the example above MPE11111 is used. You should see the MPE number related to your MAP term.
The Server ID obtained from the AWS Migration HUB has a value of d-server-… This should be the value used to tag your migrated workloads.
Migration tracking for Amazon EKS will continue to rely on the existing MAP 2.0 tagging process. The tag-key and tag-value will be same as the standard MAP tags as detailed in the MAP Tagging Instruction Guide.
Since Amazon EKS potentially launches multiple AWS services, all of the resources and services launched by Amazon EKS should be tagged. The below guide gives detailed instructions on how to tag all of the Amazon EKS resources correctly.
EKS does not propagate tags as of now. The instructions detailed below are required as an alternate solution until EKS supports tag propagation.
While Kubernetes API allows multiple resource types to be defined from within the context of a cluster, AWS models these resources as internal to the cluster if the resource cannot be shared across multiple clusters or AWS resources. Pricing is based on Amazon EKS cluster hours and the following internal cluster resources:
In order to apply tags to the Kubernetes cluster itself and all the paid internal cluster resources such as nodes, load balancers and EBS volumes follow the instructions below.
Tags can be added to new or existing Kubernetes clusters using the Amazon EKS console,eksctl, AWS CLI, AWS API, or infrastructure-as-a-code tools.
Tagging nodes within a nodegroup -Amazon EKS cluster can schedule pods on any combination of self-managed nodes and EKS managed nodes. To make sure managed nodes or self managed nodes are tagged properly,follow the instructions below
The AWS Load balancer controller manages AWS Elastic Load Balancers for a Kubernetes cluster. The controller provisions
The Amazon EBS Container Storage Interface (CSI) driver provides a CSI interface that allows Amazon EKS clusters to manage the lifecycle of EBS volumes. To add tags to the dynamically provisioned EBS volumes, use the command option –extra-tags in the CSI driver. For detailed instructions visit the documentation.
AWS Fargate with Amazon EKS is not included on the MAP 2.0 Services List
The tagging instructions are also available in the EKS documentation
It is important for you to know the Migration tracking for Amazon EMR (previously called Amazon Elastic MapReduce) when the service is part of your migration plan.
Amazon EMR for the most part will continue to rely on the existing MAP2.0 tagging process. The tag-key will be same as the standard MAP tags as detailed in the MAP tagging instruction Guide. For the tag-value, it is important to make a note of the following:
EMR allows for tagging propagation. Thus, in most cases, it is sufficient to tag EMR resources, and the resources launched by EMR (like EC2) automatically carry the EMR tags. In select scenarios where there is no actual new resources creation done by EMR (e.g. job submitted to virtual clusters without creation); it is expected that you will tag the respective resources of the dependent AWS services in same way as that of EMR.
The tagging instructions are also available in the Amazon EMR documentation.
The script available at Step 1 - Set up CUR & Generate Server ID / AUTOMATED can validate an existing CUR if the customer has already created one (the existing report name should start with map-migrated). If the current CUR has some parameters that aren’t setup as per MAP requirements, the script will throw logs in CloudWatch notifying the user about the misconfigurations and how to correct them.
This is an example of a broken report validation in CloudWatch.
To get to the logs screen go to Resources in CloudFormation, click the Lambda function resource and go to Monitoring > View logs in CloudWatch
Since CUR must be created in a management (payer) account, if a customer runs the script in a non-management account, the script will detect that and won’t create the report. It will notify customer in CloudWatch that they need to switch to a management account.
The Cost and Usage Report (CUR) is enabled once per management account by the team with right privileges to the management payer account. An associated Cost and Usage Report then needs to be created to allow tracking of MAP tagged resources.
After you have tagged the target AWS resources, if you want to see how much the target AWS resources are used for each management account in your Migration Plan, you can use Cost Explorer to see the approximate amount of the target AWS resources. For more information, see the AWS Billing and Cost Management - Analyzing your costs with Cost Explorer User Guide.
Why is tagging required for MAP?
Tagging is a way to assign a label to an AWS resource. Tags enable you to categorize your AWS resources in different ways. For example, you can categorize by purpose, owner, department,or environment. Each tag consists of a key and an optional value (for example, Department: Finance
), both of which you define.
For the purposes of MAP, tagging of migrated workloads with the specific map-migrated
tag (tag key is case sensitive) is necessary to enable the following:
The tagging exercise is done when the workload is migrated to AWS. Typically, tags are applied by the workload owners who will be migrating their workloads. This process is repeated as workloads are moved across until the entire MAP migration scope has been migrated.
Tagging your AWS resources is a best practice even outside of MAP. For more information, see the Tagging Best Practices Whitepaper.
Why CUR is required for MAP?
The AWS Cost and Usage Reports (AWS CUR) contain the most comprehensive set of cost and usage data available. You can use Cost and Usage Reports to publish your AWS billing reports to an Amazon Simple Storage Service (Amazon S3) bucket that you own. You can receive reports that break down your costs by the hour, day, or month, by product or product resource, or by tags that you define yourself. AWS updates the report in your bucket once a day in comma-separated value (CSV) format. You can view the reports using spreadsheet software such as Microsoft Excel or Apache OpenOffice Calc, or access them from an application using the Amazon S3 API.
AWS Cost and Usage Reports track your AWS usage and provide estimated charges associated with your account. Each report contains line items for each unique combination of AWS products, usage type, and operation that you use in your AWS account. You can customize the AWS Cost and Usage Reports to aggregate the information either by the hour, day, or month.
AWS Cost and Usage Reports can do the following:
Migration tracking through tagging?
We rely on existing, publicly available services within AWS: Custom tags, AWS Cost andUsage Reports(AWS CUR), and AWS Migration Hub. MAP’s migration tracking mechanism uses native AWS functionality which we will configure in four steps:
For more information about AWS Cost and Usage Reports please check on this link
What does CUR-Server-Ids Automator script do?
The script does two things: it first create and configure CUR and it then generated a Server ID that customers need to use to tag their migrated workload.
Which AWS account customers should use to log into and execute Step 1 - Set up CUR & Generate Server ID?
If customers decide to follow the automated approached then they must run the script in the management (payer) account. If they decide to use the manual steps then they must create CUR in the management account, and they can generate the Server ID in the management account or any another member (linked) account in the same AWS Organization.
Should migrations occur under the same management (payer) account?
All accounts to which migrations happen must be linked to the management (payer) account where the Cost and Usage Report (CUR) is enabled
The documentation states that an MPE number is required. Where do I find that number?
We need the MPE number identified on your Migration Plan to be part of the Step 1 - Set up CUR & Generate Server ID. This is to facilitate multiple Migration Plans per customer and per account. You can find this number when it is sent to you for acceptance by your account team. MPE
is case sensitive and must be upper case.
Once I finish Step 1 - Set up CUR & Generate Server Id, how do I get the ServerID information?
There are two ways to get the information:
How do I tag my migrated resources in AWS with map-migrated tag?
There are several ways to tag resources in AWS. It can be as simple as going to each resource in AWS console and create tags or you can write custom scripts to bulk tag your resources during or after the creation.
I’ve already onboarded to MAP 2.0 and have been following the tagging process that required a Server ID for each source server. How should I proceed going forward?
If you are already tagging migrated resources using a Server ID for each source server, you can continue to do so as that process will still be supported. Alternatively, you now have the option to simplify tagging for future migrations by selecting 1 (one/any) Server ID from Migration Hub to tag all migrated resources going forward.
Please note that deletion of previously generated tags is not necessary or recommended. If you decide to delete previous Migration Hub imports, it will invalidate the existing Server ID values in the tagged migrated resources and impact spend tracking for credits. If a resource has been tagged with a Server ID that has been deleted, the resource will need to be re-tagged with a valid active Migration Hub Server ID.
It is not recommended to re-tag previous existing resources that already have map-migrated tag key and a Server Id value. For newly created resources is acceptable if you prefer to use a single Server ID.
Does this script generate multiple Server IDs for customers who have multiple MPEs under the same management (payer) account?
Currently, this solution generates a Server ID only for the first MPE. For customers who have subsequent MPEs they can use this solution to generate Server ID for the first MPE and then follow the manual steps to generate Server IDs for the other MPEs.
What is the process for baseline AWS services that cannot be tagged but may also be included in MAP (which can include VMare Cloud on AWS, Amazon Connect or AWS Managed Services)?
For Amazon Connect, VMware Cloud on AWS, and AWS Managed Services (AMS) this is an automated process.
I’m planning to migrate only non-taggable services (Amazon Connect, AWS Managed Services (AMS), VMwareCloudonAWS). Do I still need to set up CUR?
Yes, the management (payer) account listed in the MAP agreement must always be configured using the MAP-specific Cost & Usage Report as per Step 1 - Set up CUR & Generate Server Id.
If I tag an existing AWS resource, will I receive MAP Credits?
The Program Terms clearly state that only MAP resources that are launched after the agreement acceptance date are eligible for MAP Credits.
Can I use an Amazon S3 bucket that existed before the MAP agreement as destination for my migration? You are recommended to use new S3 buckets for migration workloads. If for any reason you have to use existing S3 buckets for migration workloads, you need to provide to your account team the ARNs for each of the existing S3 buckets to be used for migration and each bucket’s current baseline spend, so that information is included in the MAP agreement. You will then need to tag these buckets during migration. Please follow this instruction on how to baseline the existing S3 buckets.
Which services are in scope for MAP?
You can find all eligible services for MAP in the Included Services list. Certain Specialized Services may also be included in your Migration Plan or MAP Migration Tracking and Incentive Guide. Eligible services for MAP for SAP are provided in the MAP for SAP Migration Tracking and Incentive Guide.
What is the cost of running Step 1 - Set up CUR & Generate Server ID
Step 1 - Set up CUR & Generate Server ID will use S3 to store CUR and the uploaded inventory respectively. These files are typically small (a few KBs) and it will take time before they start incurring charges. Check Amazon S3 pricing for details. Step 1 - Set up CUR & Generate Server Id - AUTOMATED will use a Lambda function for a time (a few seconds) that’s short enough to not incur charges on customers’ accounts (Lambda free tier). Check AWS Lambda Pricing for details.
I need more details about the permissions required to implement Step 1 - Set up CUR & Generate Server ID in the my AWS account. Where do I find more details about that?
Are tags case sensitive?
Yes. AWS custom tags are case sensitive. For MAP, all the tag keys used are lower case and should be adhered to.
Can I use Amazon EC2 Dedicated Hosts as part of MAP 2.0?
Yes. It is possible to use Amazon EC2 Dedicated Hosts as part of MAP 2.0.
Do I have to launch my resources in the same AWS region as Migration Hub?
You can launch your resources in any AWS region as per your convenience. Although Migration Hub is available in selected regions, there is no requirement that your resources need to be launched in the same region.
Do I have to launch my resources in the same region as CUR and the S3 bucket used by CUR?
You can launch your resources in any AWS region as per your convenience. CUR is an account level configuration, so by following the steps defined in Step 1 - Set up CUR & Generate Server Id should be sufficient.
I don’t see map-migrated tag in the Cost allocation tags screen. What should I do?
The map-migrated tag should must be used in at least 1 AWS resource before it is available in the Cost allocation tags screen. We recommend tagging the S3 bucket used for the CUR daily report generation with map-migrated. The Step 1 - Set up CUR & Generate Server Id - Automated scripts will tag the mentioned S3 buckets automatically. After the S3 bucket is tagged, it might take up to 24 hours for the map-migrated tag to be available at the Cost allocation screen.
Can I have multiple CUR setup in my management (payer) account? Yes. You can configure multiple CUR in the management (payer) account for different business reasons. However, only 1 (one) CUR with the prefix map-migrated should exist in the management (payer) account. Having multiple CUR with prefix map-migrated will impact the credit calculation.
How can I see the MAP credits that have been applied to my account?
The MAP credits information will be listed in your invoice and CUR report with the following description:
PromotionName - SLS_MAP5k_xxxxxxxxx_CustomerName_MPExxxxx Promotion Description - Migration_Acceleration_Program_Credit
You can use AWS billing console to track MAP 2.0 related credits (used and remaining). In order to do so, you can go to the billing console, and see MAP 2.0 credit line items under ‘credits’.
I am migrating DB&A workloads to AWS under MAP 2.0, what tags should I use?
MAP 2.0 Customers are eligible for enhanced incentives when they migrate DB&A workloads to eligible DB&A managed services (included services for DB&A). Customers are not eligible for enhanced incentives when migrating DB&A workloads to EC2.
When customer is migrating DB&A workload to DB&A managed service (from on premisses or EC2), if the source workload is considered commercial, customer should use map-dba
tag-key. If customer is migrating from non-commercial workload, customer should use map-migrated
tag-key.
If customer is migrating a DB&A workload to EC2, customer should always use map-migrated
.