docs.aws.amazon.com
Open in
urlscan Pro
18.66.147.13
Public Scan
URL:
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/migrate-iam-permissions.html
Submission: On July 07 via manual from US — Scanned from DE
Submission: On July 07 via manual from US — Scanned from DE
Form analysis 0 forms found in the DOM
Text Content
SELECT YOUR COOKIE PREFERENCES
We use essential cookies and similar tools that are necessary to provide our
site and services. We use performance cookies to collect anonymous statistics so
we can understand how customers use our site and make improvements. Essential
cookies cannot be deactivated, but you can click “Customize cookies” to decline
performance cookies.
If you agree, AWS and approved third parties will also use cookies to provide
useful site features, remember your preferences, and display relevant content,
including relevant advertising. To continue without accepting these cookies,
click “Continue without accepting.” To make more detailed choices or learn more,
click “Customize cookies.”
Accept all cookiesContinue without acceptingCustomize cookies
CUSTOMIZE COOKIE PREFERENCES
We use cookies and similar tools (collectively, "cookies") for the following
purposes.
ESSENTIAL
Essential cookies are necessary to provide our site and services and cannot be
deactivated. They are usually set in response to your actions on the site, such
as setting your privacy preferences, signing in, or filling in forms.
PERFORMANCE
Performance cookies provide anonymous statistics about how customers navigate
our site so we can improve site experience and performance. Approved third
parties may perform analytics on our behalf, but they cannot use the data for
their own purposes.
Allow performance category
Allowed
FUNCTIONAL
Functional cookies help us provide useful site features, remember your
preferences, and display relevant content. Approved third parties may set these
cookies to provide certain site features. If you do not allow these cookies,
then some or all of these services may not function properly.
Allow functional category
Allowed
ADVERTISING
Advertising cookies may be set through our site by us or our advertising
partners and help us deliver relevant marketing content. If you do not allow
these cookies, you will experience less relevant advertising.
Allow advertising category
Allowed
Blocking some types of cookies may impact your experience of our sites. You may
review and change your choices at any time by clicking Cookie preferences in the
footer of this site. We and selected third-parties use cookies or similar
technologies as specified in the AWS Cookie Notice.
CancelSave preferences
UNABLE TO SAVE COOKIE PREFERENCES
We will only store essential cookies at this time, because we were unable to
save your cookie preferences.
If you want to change your cookie preferences, try again later using the link in
the AWS console footer, or contact support if the problem persists.
Dismiss
Contact Us
English
Create an AWS Account
1. AWS
2. ...
3. Documentation
4. AWS Billing and Cost Management
5. User Guide
Feedback
Preferences
AWS BILLING
USER GUIDE
* What is AWS Billing?
* Getting started
* Getting help
* Avoiding unexpected charges
* Managing your account
* Managing an AWS account
* Managing an account in India
* Closing an account
* Using the AWS Billing console dashboard
* Viewing your bill
* Viewing your monthly charges
* Getting an invoice emailed to you
* Managing your payments
* Managing your AWS payments
* Making payments, checking funds, and viewing history
* Managing your credit card and ACH payment methods
* Managing your AWS payments in CNY
* Managing your PIX payment method in Brazil
* Managing your payments in India
* Managing your payments in AWS Europe
* Managing your AWS Europe payment methods
* Making payments, checking funds, and viewing payment history in AWS
Europe
* Managing your AWS Europe credit card payment methods
* Managing your AWS Europe credit card payment verifications
* Managing your SEPA direct debit payment methods
* Managing your Advance Pay
* Managing your payment profiles
* Creating your payment profiles
* Editing your payment profiles
* Deleting your payment profiles
* Managing your AWS payment preferences
* Viewing your customer carbon footprint tool
* Understanding your customer carbon footprint tool overview
* Understanding your carbon emission estimations
* Managing your purchase orders
* Setting up purchase order configurations
* Adding a purchase order
* Editing your purchase orders
* Deleting your purchase orders
* Viewing your purchase orders
* Reading your purchase order details page
* Enabling purchase order notifications
* Use tags to manage access to purchase orders
* Managing your costs with AWS Cost Categories
* Creating cost categories
* Tagging cost categories
* Viewing cost categories
* Editing cost categories
* Deleting cost categories
* Splitting charges within cost categories
* Using AWS cost allocation tags
* AWS-generated cost allocation tags
* Activating the AWS-generated cost allocation tags
* Deactivating the AWS-generated cost allocation tags
* Restrictions on AWS-generated cost allocation tags
* User-defined cost allocation tags
* Activating user-defined cost allocation tags
* User-defined tag restrictions
* Monthly cost allocation report
* Using the AWS Free Tier
* Tracking your AWS Free Tier usage
* Using the Billing preferences page
* Using the AWS Price List API
* Using the bulk API
* Finding prices in an offer file
* Finding Savings Plan prices in an offer file
* Reading an offer file
* Reading the offer index file
* Using the query API
* Setting up notifications
* Consolidated billing for AWS Organizations
* Consolidated billing process
* Consolidated billing in AWS EMEA
* Consolidated billing in India
* Effective billing date, account activity, and volume discounts
* Credits
* Reserved instances
* Billing examples for specific services
* Reserved Instances and Savings Plans discount sharing
* Understanding Consolidated Bills
* Requesting shorter PDF invoices
* Organization support charges
* Security
* Data protection
* Identity and access management
* Overview of managing access
* Using IAM policies for Billing
* AWS Billing policy examples
* Migrating access control
* How to use the affected policies tool
* Use scripts to bulk migrate your policies to use fine-grained IAM
actions
* Mapping fine-grained IAM actions reference
* Logging and monitoring
* Logging API calls with CloudTrail
* Compliance validation
* Resilience
* Infrastructure security
* Quotas and restrictions
* Document history
* AWS glossary
Use scripts to bulk migrate your policies to use fine-grained IAM actions - AWS
Billing
AWSDocumentationAWS Billing and Cost ManagementUser Guide
OverviewPrerequisitesStep 1: Set up your environmentStep 2: Create the
CloudFormation stack setStep 3: Identify the affected policiesStep 4: Review the
suggested changesStep 5: Update the affected policiesStep 6: Revert your changes
(Optional) IAM policy examples
USE SCRIPTS TO BULK MIGRATE YOUR POLICIES TO USE FINE-GRAINED IAM ACTIONS
PDFRSS
The following AWS Identity and Access Management (IAM) actions will reach the
end of standard support on July 2023: aws-portal namespace,
purchase-orders:ViewPurchaseOrders, and purchase-orders:ModifyPurchaseOrders.
See the Using fine-grained AWS Billing actions to replace these actions with
fine-grained actions so you have access to AWS Billing, AWS Cost Management, and
AWS accounts consoles.
If you created your AWS account, or are a part of an AWS Organizations created
before March 6, 2023, 11:00 (PDT), the fine-grained actions will be effective
starting July 2023. We recommend you to add the fine-grained actions, but not
remove your existing permissions with aws-portal or purchase-orders prefixes.
If you created your AWS account, or are a part of an AWS Organizations created
on or after March 6, 2023, 11:00 (PDT), the fine-grained actions are effective
immediately.
To help migrate your IAM policies to use new actions, known as fine-grained
actions, you can use scripts from the AWS Samples website.
You run these scripts from the payer account of your organization to identify
the following affected policies in your organization that use the old IAM
actions:
* Customer managed IAM policies
* Role, group, and user IAM inline policies
* Service control policies (SCPs) (applies to the payer account only)
The scripts generate suggestions for new actions that correspond to existing
actions that are used in the policy. You then review the suggestions and use the
scripts to add the new actions across all affected policies in your
organization.
You use these scripts to:
* Streamline the policy updates to help you manage the affected policies from
the payer account.
* Reduce the amount of time that you need to update the policies. You don't
need to sign into each member account and manually update the policies.
* Group identical policies from different member accounts together. You can
then review and apply the same updates across all identical policies, instead
of reviewing them one by one.
* Ensure that user access remains unaffected after AWS retires the old IAM
actions on July 6, 2023.
For more information about policies and service control policies (SCPs), see the
following topics:
* Managing IAM policies in the IAM User Guide
* Service control policies (SCPs) in the AWS Organizations User Guide
OVERVIEW
Follow this topic to complete the following steps:
TOPICS
* Prerequisites
* Step 1: Set up your environment
* Step 2: Create the CloudFormation stack set
* Step 3: Identify the affected policies
* Step 4: Review the suggested changes
* Step 5: Update the affected policies
* Step 6: Revert your changes (Optional)
* IAM policy examples
PREREQUISITES
To get started, you must do the following:
* Download and install Python 3
* Sign in to your payer account and verify that you have an IAM principal that
has the following IAM permissions:
"iam:GetAccountAuthorizationDetails",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetUserPolicy",
"iam:GetGroupPolicy",
"iam:GetRolePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicyVersion",
"iam:ListPolicyVersions",
"iam:PutUserPolicy",
"iam:PutGroupPolicy",
"iam:PutRolePolicy",
"iam:SetDefaultPolicyVersion",
"organizations:ListAccounts",
"organizations:ListPolicies",
"organizations:DescribePolicy",
"organizations:UpdatePolicy",
"organizations:DescribeOrganization",
"sts:AssumeRole"
TIP
To get started, we recommend that you use a subset of an account, such as a test
account, to verify that the suggested changes are expected.
You can then run the scripts again for remaining accounts in your organization.
STEP 1: SET UP YOUR ENVIRONMENT
To get started, download the required files from the AWS Samples website. You
then run commands to set up your environment.
TO SET UP YOUR ENVIRONMENT
1. Clone the repository from the AWS Samples website. In a command line window,
you can use the following command:
git clone https://github.com/aws-samples/bulk-policy-migrator-scripts-for-account-cost-billing-consoles.git
2. Navigate to the directory where you downloaded the files. You can use the
following command:
cd bulk-policy-migrator-scripts-for-account-cost-billing-consoles
In the repository, you can find the following scripts and resources:
* billing_console_policy_migrator_role.json – The CloudFormation template
that creates the BillingConsolePolicyMigratorRole IAM role in member
accounts of your organization. This role allows the scripts to assume the
role, and then read and update the affected policies.
* action_mapping_config.json– Contains the one-to-many mapping of the old
actions to the new actions. The scripts use this file to suggest the new
actions for each affected policy that contains the old actions.
Each old action corresponds to multiple fine-grained actions. The new
actions suggested in the file provide users access to the same AWS
services before the migration.
* identify_affected_policies.py – Scans and identifies affected policies in
your organization. This script generates a
affected_policies_and_suggestions.json file that lists the affected
policies along with the suggested new actions.
Affected policies that use the same set of old actions are grouped
together in the JSON file, so that you can review or update the suggested
new actions.
* update_affected_policies.py – Updates the affected policies in your
organization. The script inputs theaffected_policies_and_suggestions.json
file, and then adds the suggested new actions to the policies.
* rollback_affected_policies.py – (Optional) Reverts changes made to the
affected policies. This script removes the new fine-grained actions from
the affected policies.
3. Run the following commands to set up and activate the virtual environment.
python3 -m venv venv
source venv/bin/activate
4. Run the following command to install the AWS SDK for Python (Boto3)
dependency.
pip install -r requirements.txt
NOTE
You must configure your AWS credentials to use the AWS Command Line
Interface (AWS CLI). For more information, see AWS SDK for Python (Boto3).
For more information, see the README.md file.
STEP 2: CREATE THE CLOUDFORMATION STACK SET
Follow this procedure to create a CloudFormation stack set. The stack set then
creates the BillingConsolePolicyMigratorRole IAM role for all member accounts in
your organization.
NOTE
You only need to complete this step once from the management account (payer
account).
TO CREATE THE CLOUDFORMATION STACK SET
1. In a text editor, open the billing_console_policy_migrator_role.json file,
and replace each instance of <management_account> with the account ID of the
payer account (for example, 123456789012).
2. Save the file.
3. Sign in to the AWS Management Console as the payer account.
4. In the CloudFormation console, create a stack set with the
billing_console_policy_migrator_role.json file that you updated.
For more information, see Creating a stack set on the AWS CloudFormation
console in the AWS CloudFormation User Guide.
After CloudFormation creates the stack set, each member account in your
organization has an BillingConsolePolicyMigratorRole IAM role.
The IAM role contains the following permissions:
"iam:GetAccountAuthorizationDetails",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetUserPolicy",
"iam:GetGroupPolicy",
"iam:GetRolePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicyVersion",
"iam:ListPolicyVersions",
"iam:PutUserPolicy",
"iam:PutGroupPolicy",
"iam:PutRolePolicy",
"iam:SetDefaultPolicyVersion"
NOTES
* For each member account, the scripts call the AssumeRole API operation to get
temporary credentials to assume the BillingConsolePolicyMigratorRole IAM
role.
* The scripts call the ListAccounts API operation to get all member accounts.
* The scripts also call IAM API operations to perform the read and write
permissions to the policies.
STEP 3: IDENTIFY THE AFFECTED POLICIES
After you create the stack set and downloaded the files, run the
identify_affected_policies.py script. This script assumes the
BillingConsolePolicyMigratorRole IAM role for each member account, and then
identifies the affected policies.
TO IDENTIFY THE AFFECTED POLICIES
1. Navigate to the directory where you downloaded the scripts.
cd policy_migration_scripts/scripts
2. Run the identify_affected_policies.py script.
You can use the following input parameters:
* AWS accounts that you want the script to scan. To specify accounts, use the
following input parameters:
* --all – Scans all member accounts in your organization.
python3 identify_affected_policies.py --all
* --accounts – Scans a subset of member accounts in your organization.
python3 identify_affected_policies.py --accounts 111122223333, 444455556666, 777788889999
* --exclude-accounts– Excludes specific member accounts in your
organization.
python3 identify_affected_policies.py --all --exclude-accounts 111111111111, 222222222222, 333333333333
* –-action-mapping-config-file– (Optional) Specify the path to the
action_mapping_config.json file. The script uses this file to generate
suggested updates for affected policies. If you don't specify the path, the
script uses the action_mapping_config.json file in the folder.
python3 identify_affected_policies.py –-action-mapping-config-file c:\Users\username\Desktop\Scripts\action_mapping_config.json –-all
NOTE
You can't specify organizational units (OUs) with this script.
After you run the script, it creates two JSON files in a
Affected_Policies_<Timestamp> folder:
* affected_policies_and_suggestions.json
* detailed_affected_policies.json
affected_policies_and_suggestions.json
Lists the affected policies with the suggested new actions. Affected policies
that use the same set of old actions are grouped together in the file.
This file contains the following sections:
* Metadata that provides an overview of the accounts that you specified in the
script, including:
* Accounts scanned and the input parameter used for the
identify_affected_policies.py script
* Number of affected accounts
* Number of affected policies
* Number of similar policy groups
* Similar policy groups – Includes the list of accounts and policy details,
including the following sections:
* ImpactedPolicies – Specifies which policies are affected and included in
the group
* ImpactedPolicyStatements – Provides information about the Sid blocks that
currently use the old actions in the affected policy. This section
includes the old actions and IAM elements, such as Effect, Principal,
NotPrincipal, NotAction, and Condition.
* SuggestedPolicyStatementsToAppend – Provides the suggested new actions that
are added as new SID block.
When you update the policies, this block is appended at the end of the
policies.
EXAMPLE AFFECTED_POLICIES_AND_SUGGESTIONS.JSON FILE
This file groups together policies that are similar based on the following
criteria:
* Same old actions used – Policies that have the same old actions across all
SID blocks.
* Matching details – In addition to affected actions, the policies have
identical IAM elements,such as:
* Effect (Allow/Deny)
* Principal (who is allowed or denied access)
* NotAction (what actions are not allowed)
* NotPrincipal (who is explicitly denied access)
* Resource (which AWS resources the policy applies to)
* Condition (any specific conditions under which the policy applies)
NOTE
For more information, see IAM policy examples.
EXAMPLE AFFECTED_POLICIES_AND_SUGGESTIONS.JSON
[{
"AccountsScanned": [
"111111111111",
"222222222222"
],
"TotalAffectedAccounts": 2,
"TotalAffectedPolicies": 2,
"TotalSimilarPolicyGroups": 2
},
{
"GroupName": "Group1",
"ImpactedPolicies": [{
"Account": "111111111111",
"PolicyType": "UserInlinePolicy",
"PolicyName": "Inline-Test-Policy-Allow",
"PolicyIdentifier": "1111111_1-user:Inline-Test-Policy-Allow"
},
{
"Account": "222222222222",
"PolicyType": "UserInlinePolicy",
"PolicyName": "Inline-Test-Policy-Allow",
"PolicyIdentifier": "222222_1-group:Inline-Test-Policy-Allow"
}
],
"ImpactedPolicyStatements": [
[{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccounts"
],
"Resource": "*"
}]
],
"SuggestedPolicyStatementsToAppend": [{
"Sid": "BillingConsolePolicyMigrator0",
"Effect": "Allow",
"Action": [
"account:GetAccountInformation",
"account:GetAlternateContact",
"account:GetChallengeQuestions",
"account:GetContactInformation",
"billing:GetContractInformation",
"billing:GetIAMAccessPreference",
"billing:GetSellerOfRecord",
"payments:ListPaymentPreferences"
],
"Resource": "*"
}]
},
{
"GroupName": "Group2",
"ImpactedPolicies": [{
"Account": "111111111111",
"PolicyType": "UserInlinePolicy",
"PolicyName": "Inline-Test-Policy-deny",
"PolicyIdentifier": "1111111_2-user:Inline-Test-Policy-deny"
},
{
"Account": "222222222222",
"PolicyType": "UserInlinePolicy",
"PolicyName": "Inline-Test-Policy-deny",
"PolicyIdentifier": "222222_2-group:Inline-Test-Policy-deny"
}
],
"ImpactedPolicyStatements": [
[{
"Sid": "VisualEditor0",
"Effect": "deny",
"Action": [
"aws-portal:ModifyAccount"
],
"Resource": "*"
}]
],
"SuggestedPolicyStatementsToAppend": [{
"Sid": "BillingConsolePolicyMigrator1",
"Effect": "Deny",
"Action": [
"account:CloseAccount",
"account:DeleteAlternateContact",
"account:PutAlternateContact",
"account:PutChallengeQuestions",
"account:PutContactInformation",
"billing:PutContractInformation",
"billing:UpdateIAMAccessPreference",
"payments:UpdatePaymentPreferences"
],
"Resource": "*"
}]
}
]
detailed_affected_policies.json
Contains the definition of all affected policies that the
identify_affected_policies.py script identified for member accounts.
The file groups similar policies together. You can use this file as reference,
so that you can review and manage policy changes without needing to sign in to
each member account to review the updates for each policy and account
individually.
You can search the file for the policy name (for example,
YourCustomerManagedReadOnlyAccessBillingUser) and then review the affected
policy definitions.
EXAMPLE: DETAILED_AFFECTED_POLICIES.JSON
[{
"Account": "111111111111",
"PolicyType": "CustomerManagedPolicy",
"PolicyName": "AwsPortalviewAccount",
"PolicyIdentifier": "arn:aws:iam::111111111111:policy/AwsPortalviewAccount",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount"
],
"Resource": "*"
}]
}
},
{
"Account": "222222222222",
"PolicyType": "CustomerManagedPolicy",
"PolicyName": "AwsPortalviewAccount",
"PolicyIdentifier": "arn:aws:iam::222222222222:policy/AwsPortalviewAccount",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount"
],
"Resource": "*"
}]
}
},
{
"Account": "111111111111",
"PolicyType": "CustomerManagedPolicy",
"PolicyName": "AwsPortalModifyAccount",
"PolicyIdentifier": "arn:aws:iam::111111111111:policy/AwsPortalModifyAccount",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Deny",
"Action": [
"aws-portal:ModifyAccount"
],
"Resource": "*"
}]
}
},
{
"Account": "222222222222",
"PolicyType": "CustomerManagedPolicy",
"PolicyName": "AwsPortalModifyAccount",
"PolicyIdentifier": "arn:aws:iam::222222222222:policy/AwsPortalModifyAccount",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Deny",
"Action": [
"aws-portal:ModifyAccount"
],
"Resource": "*"
}]
}
}
]
STEP 4: REVIEW THE SUGGESTED CHANGES
After the script creates the affected_policies_and_suggestions.json file, review
it and make any changes.
TO REVIEW THE AFFECTED POLICIES
1. In a text editor, open the affected_policies_and_suggestions.json file.
2. In the AccountsScanned section, verify that the number of similar groups
identified across the scanned accounts is expected.
3. Review the suggested fine-grained actions that will be added to the affected
policies.
4. Update your file as needed and then save it.
EXAMPLE 1: UPDATE THE ACTION_MAPPING_CONFIG.JSON FILE
You can update the suggested mappings in the action_mapping_config.json. After
you update the file, you can rerun the identify_affected_policies.py script.
This script generates updated suggestions for the affected policies.
You can make multiple versions of the action_mapping_config.json file to change
the policies for different accounts with different permissions. For example, you
might create one file named action_mapping_config_testing.json to migrate
permissions for your test accounts and action_mapping_config_production.json for
your production accounts.
EXAMPLE 2: UPDATE THE AFFECTED_POLICIES_AND_SUGGESTIONS.JSON FILE
To make changes to the suggested replacements for a specific affected policy
group, you can directly edit the suggested replacements section within the
affected_policies_and_suggestions.json file.
Any changes that you make in this section are applied to all policies within
that specific affected policy group.
EXAMPLE 3: CUSTOMIZE A SPECIFIC POLICY
If you find that a policy within an affected policy group that needs different
changes than the suggested updates, you can do the following:
* Exclude specific accounts from the identify_affected_policies.py script. You
can then review those excluded accounts separately.
* Update the affected Sid blocks by removing the affected policies and accounts
that need different permissions. Create a JSON block that includes only the
specific accounts or excludes them from the current update affected policy
run.
When you rerun the identify_affected_policies.py script, only the relevant
accounts appear in the updated block. You can then refine the suggested
replacements for that specific Sid block.
STEP 5: UPDATE THE AFFECTED POLICIES
After you review and refine the suggested replacements, run the
update_affected_policies.py script. The script takes the
affected_policies_and_suggestions.json file as input. This script assumes the
BillingConsolePolicyMigratorRole IAM role to update the affected policies listed
in the affected_policies_and_suggestions.json file.
TO UPDATE THE AFFECTED POLICIES
1. If you haven't already, open a command line window for the AWS CLI.
2. Enter the following command to run the update_affected_policies.py script.
You can enter the following input parameter:
* The directory path of the affected_policies_and_suggestions.json file that
contains a list of the affected policies to be updated. This file is an
output of the previous step.
python3 update_affected_policies.py --affected-policies-directory Affected_Policies_<Timestamp>
The update_affected_policies.py script updates the affected policies within the
affected_policies_and_suggestions.json file with the suggested new actions. The
script adds a Sid block to the policies, identified as
BillingConsolePolicyMigrator#, where # corresponds to an incremental counter
(for example, 1, 2, 3).
For example, if there are multiple Sid blocks in the affected policy that use
old actions, the script adds multiple Sid blocks that appear as
BillingConsolePolicyMigrator# to correspond to each Sid block.
IMPORTANT
* The script doesn't remove old IAM actions from the policies, and or change
existing Sid blocks in the policies. Instead, it creates Sid blocks and
appends them to the end of the policy. These new Sid blocks have the
suggested new actions from the JSON file. This ensures that the permissions
of the original policies aren't changed.
* We recommend that you do not change the name of the
BillingConsolePolicyMigrator# Sid blocks in case you need to revert your
changes.
EXAMPLE: POLICY WITH APPENDED SID BLOCKS
See the appended Sid blocks in the BillingConsolePolicyMigrator1 and
BillingConsolePolicyMigrator2 blocks.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ce:*",
"aws-portal:ViewAccount"
],
"Resource": "*",
"Principal": {
"AWS": "arn:aws:iam::111111111111:BillingRole"
},
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "true"
}
}
},
{
"Sid": "BillingConsolePolicyMigrator1",
"Effect": "Allow",
"Action": [
"account:GetAccountInformation",
"account:GetAlternateContact",
"account:GetChallengeQuestions",
"account:GetContactInformation",
"billing:GetContractInformation",
"billing:GetIAMAccessPreference",
"billing:GetSellerOfRecord",
"payments:ListPaymentPreferences"
],
"Resource": "*",
"Principal": {
"AWS": "arn:aws:iam::111111111111:BillingRole"
},
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "true"
}
}
},
{
"Sid": "BillingConsolePolicyMigrator2",
"Effect": "Deny",
"Action": [
"account:CloseAccount",
"account:DeleteAlternateContact",
"account:PutAlternateContact",
"account:PutChallengeQuestions",
"account:PutContactInformation",
"billing:PutContractInformation",
"billing:UpdateIAMAccessPreference",
"payments:UpdatePaymentPreferences"
],
"Resource": "*"
}
]
}
The script generates a status report that contains unsuccessful operations and
outputs the JSON file locally.
EXAMPLE: STATUS REPORT
[{
"Account": "111111111111",
"PolicyType": "Customer Managed Policy"
"PolicyName": "AwsPortalViewPaymentMethods",
"PolicyIdentifier": "identifier",
"Status": "FAILURE", // FAILURE or SKIPPED
"ErrorMessage": "Error message details"
}]
IMPORTANT
* If you re-run the identify_affected_policies.py and
update_affected_policies.py scripts , they skip all policies that contain the
BillingConsolePolicyMigratorRole#Sid block. The scripts assume that those
policies were previously scanned and updated, and that they don't require
additional updates. This prevents the script from duplicating the same
actions in the policy.
* After you update the affected policies, you can use the new IAM by using the
affected policies tool. If you identify any issues, you can use the tool to
switch back to the previous actions. You can also use a script to revert your
policy updates.
For more information, see How to use the affected policies tool and the
Changes to AWS Billing, Cost Management, and Account Consoles Permissions
blog post.
* To manage your updates, you can:
* Run the scripts for each account individually.
* Run the script in batches for similar accounts, such as testing, QA, and
production accounts.
* Run the script for all accounts.
* Choose a mix between updating some accounts in batches, and then updating
others individually.
STEP 6: REVERT YOUR CHANGES (OPTIONAL)
The rollback_affected_policies.py script reverts the changes applied to each
affected policy for the specified accounts. The script removes all Sid blocks
that the update_affected_policies.py script appended. These Sid blocks have the
BillingConsolePolicyMigratorRole# format.
TO REVERT YOUR CHANGES
1. If you haven't already, open a command line window for the AWS CLI.
2. Enter the following command to run the rollback_affected_policies.py script.
You can enter the following input parameters:
* --accounts
* Specifies a comma-separated list of the AWS account IDs that you want to
include in the rollback.
* The following example scans the policies in the specified AWS accounts,
and removes any statements with the BillingConsolePolicyMigrator# Sid
block.
python3 rollback_affected_policies.py –-accounts 111122223333, 555555555555, 666666666666
* --all
* Includes all AWS account IDs in your organization.
* The following example scans all policies in your organization, and removes
any statements with the BillingConsolePolicyMigratorRole# Sid block.
python3 rollback_affected_policies.py –-all
* --exclude-accounts
* Specifies a comma-separated list of the AWS account IDs that you want to
exclude from the rollback.
You can use this parameter only when you also specify the --all parameter.
* The following example scans the policies for all AWS accounts in your
organization, except for the specified accounts.
python3 rollback_affected_policies.py --all --exclude-accounts 777777777777, 888888888888, 999999999999
IAM POLICY EXAMPLES
Policies are considered similar if they have identical:
* Affected actions across all Sid blocks.
* Details in the following IAM elements:
* Effect (Allow/Deny)
* Principal (who is allowed or denied access)
* NotAction (what actions are not allowed)
* NotPrincipal (who is explicitly denied access)
* Resource (which AWS resources the policy applies to)
* Condition (any specific conditions under which the policy applies)
The following examples show policies which IAM might or might not consider
similar based on the differences between them.
EXAMPLE 1: POLICIES ARE CONSIDERED SIMILAR
Each policy type is different, but both policies contain one Sid block with the
same affected Action.
Policy 1: Group inline IAM policy
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount",
"aws-portal:*Billing"
],
"Resource": "*"
}]
}
Policy 2: Customer managed IAM policy
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount",
"aws-portal:*Billing"
],
"Resource": "*"
}]
}
anchoranchor
* Policy 1: Group inline IAM policy
* Policy 2: Customer managed IAM policy
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount",
"aws-portal:*Billing"
],
"Resource": "*"
}]
}
EXAMPLE 2: POLICIES ARE CONSIDERED SIMILAR
Both policies contain one Sid block with the same affected Action. Policy 2
contains additional actions, but these actions aren't affected.
Policy 1
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount",
"aws-portal:*Billing"
],
"Resource": "*"
}]
}
Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount",
"aws-portal:*Billing",
"athena:*"
],
"Resource": "*"
}]
}
anchoranchor
* Policy 1
* Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount",
"aws-portal:*Billing"
],
"Resource": "*"
}]
}
EXAMPLE 3: POLICIES AREN'T CONSIDERED SIMILAR
Both policies contain one Sid block with the same affected Action. However,
policy 2 contains a Condition element that isn't present in policy 1.
Policy 1
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount",
"aws-portal:*Billing"
],
"Resource": "*"
}]
}
Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount",
"aws-portal:*Billing",
"athena:*"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "true"
}
}
}]
}
anchoranchor
* Policy 1
* Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:ViewAccount",
"aws-portal:*Billing"
],
"Resource": "*"
}]
}
EXAMPLE 4: POLICIES ARE CONSIDERED SIMILAR
Policy 1 has a single Sid block with an affected Action. Policy 2 has multiple
Sid blocks, but the affected Action appears in only one block.
Policy 1
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:View*"
],
"Resource": "*"
}]
}}
Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:View*"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"cloudtrail:Get*"
],
"Resource": "*"
}
]
}
anchoranchor
* Policy 1
* Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:View*"
],
"Resource": "*"
}]
}}
EXAMPLE 5: POLICIES AREN'T CONSIDERED SIMILAR
Policy 1 has a single Sid block with an affected Action. Policy 2 has multiple
Sid blocks, and the affected Action appears in multiple blocks.
Policy 1
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:View*"
],
"Resource": "*"
}]
}
Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:View*"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Deny",
"Action": [
"aws-portal:Modify*"
],
"Resource": "*"
}
]
}
anchoranchor
* Policy 1
* Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:View*"
],
"Resource": "*"
}]
}
EXAMPLE 6: POLICIES ARE CONSIDERED SIMILAR
Both policies have multiple Sid blocks, with the same affected Action in each
Sid block.
Policy 1
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:*Account",
"iam:Get*"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Deny",
"Action": [
"aws-portal:Modify*",
"iam:Update*"
],
"Resource": "*"
}
]
}
Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:*Account",
"athena:Get*"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Deny",
"Action": [
"aws-portal:Modify*",
"athena:Update*"
],
"Resource": "*"
}
]
}
anchoranchor
* Policy 1
* Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:*Account",
"iam:Get*"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Deny",
"Action": [
"aws-portal:Modify*",
"iam:Update*"
],
"Resource": "*"
}
]
}
EXAMPLE 7
The following two policies aren't considered similar.
Policy 1 has a single Sid block with an affected Action. Policy 2 has a Sid
block with the same affected Action. However, policy 2 also contains another Sid
block with different actions.
Policy 1
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:*Account",
"iam:Get*"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Deny",
"Action": [
"aws-portal:Modify*",
"iam:Update*"
],
"Resource": "*"
}
]
}
Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:*Account",
"athena:Get*"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Deny",
"Action": [
"aws-portal:*Billing",
"athena:Update*"
],
"Resource": "*"
}
]
}
anchoranchor
* Policy 1
* Policy 2
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"aws-portal:*Account",
"iam:Get*"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Deny",
"Action": [
"aws-portal:Modify*",
"iam:Update*"
],
"Resource": "*"
}
]
}
Javascript is disabled or is unavailable in your browser.
To use the Amazon Web Services Documentation, Javascript must be enabled. Please
refer to your browser's Help pages for instructions.
Document Conventions
How to use the affected policies tool
Mapping fine-grained IAM actions reference
Did this page help you? - Yes
Thanks for letting us know we're doing a good job!
If you've got a moment, please tell us what we did right so we can do more of
it.
Did this page help you? - No
Thanks for letting us know this page needs work. We're sorry we let you down.
If you've got a moment, please tell us how we can make the documentation better.
Did this page help you?
Yes
No
Provide feedback
Next topic:Mapping fine-grained IAM actions reference
Previous topic:How to use the affected policies tool
Need help?
* Try AWS re:Post
* Connect with an AWS IQ expert
PrivacySite termsCookie preferences
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
ON THIS PAGE
--------------------------------------------------------------------------------
* Overview
* Prerequisites
* Step 1: Set up your environment
* Step 2: Create the CloudFormation stack set
* Step 3: Identify the affected policies
* Step 4: Review the suggested changes
* Step 5: Update the affected policies
* Step 6: Revert your changes (Optional)
* IAM policy examples
DID THIS PAGE HELP YOU? - NO
Thanks for letting us know this page needs work. We're sorry we let you down.
If you've got a moment, please tell us how we can make the documentation better.
Feedback