When should I attach AWSDataPipeline_PowerUser?

The reference page says you can attach AWSDataPipeline_PowerUser to your users, groups and roles, and describes it as full access to Data Pipeline with list access to related services and passRole for the default roles. Attach it for people who build and run pipelines.

What does AWSDataPipeline_PowerUser grant?

It allows datapipeline:* plus eleven list, describe and get actions for S3, DynamoDB, Redshift, RDS, SNS and IAM on all resources, and iam:PassRole on DataPipelineDefaultResourceRole and DataPipelineDefaultRole.

What are the security risks of AWSDataPipeline_PowerUser?

datapipeline:* gives full control of Data Pipeline, and iam:PassRole on the two default roles means pipelines can run with whatever permissions those roles hold. AWS managed policies don't grant least privilege permissions, and you must consider the security risk of granting principals more permissions than they need. AWS updates to the policy affect every identity it is attached to.

AWSDataPipeline_PowerUser

AdminAWS managedActiveReviewedShow on map Compare

Summary

Provides full access to Data Pipeline, list access for S3, DynamoDB, Redshift, RDS, SNS, and IAM roles, and passRole access for default Roles.

Permissions imported from the AWS Managed Policy Reference Guide; other sections reviewed against the listed AWS sources.

Identity

ARN: arn:aws:iam::aws:policy/AWSDataPipeline_PowerUser
Default version: v2
Created: 2017-01-19
Last edited: 2017-08-17
Services: datapipeline, dynamodb, iam, rds, redshift, s3, sns

Control-plane actions (47)

By access level: 23 List, 10 Read, 2 Tagging, 12 Write.

Control-plane actions by service
Service	Granted	Access levels and limits	Granted by
Data Pipeline	All 21 actions (see the Data Pipeline page)	2 List, 6 Read, 2 Tagging, 11 Write; 0 restricted, 0 conditional	datapipeline:*
DynamoDB	1 of 68	1 Read; 0 restricted, 0 conditional	dynamodb:DescribeTable
IAM	5 of 190	2 List, 2 Read, 1 Write; 1 restricted, 0 conditional	iam:GetInstanceProfile, iam:GetRolePolicy, iam:ListInstanceProfiles, iam:ListRoles, iam:PassRole
RDS	2 of 173	2 List; 0 restricted, 0 conditional	rds:DescribeDBInstances, rds:DescribeDBSecurityGroups
Redshift	2 of 167	1 List, 1 Read; 0 restricted, 0 conditional	redshift:DescribeClusterSecurityGroups, redshift:DescribeClusters
S3	15 of 155	15 List; 0 restricted, 0 conditional	s3:List*
SNS	1 of 40	1 List; 0 restricted, 0 conditional	sns:ListTopics

DynamoDB: 1 actions

dynamodb:DescribeTable (Read)

IAM: 5 actions

iam:GetInstanceProfile (Read)
iam:GetRolePolicy (Read)
iam:ListInstanceProfiles (List)
iam:ListRoles (List)
iam:PassRole (Write)

RDS: 2 actions

rds:DescribeDBInstances (List)
rds:DescribeDBSecurityGroups (List)

Redshift: 2 actions

redshift:DescribeClusterSecurityGroups (Read)
redshift:DescribeClusters (List)

S3: 15 actions

s3:ListAccessGrants (List)
s3:ListAccessGrantsInstances (List)
s3:ListAccessGrantsLocations (List)
s3:ListAccessPoints (List)
s3:ListAccessPointsForObjectLambda (List)
s3:ListAllMyBuckets (List)
s3:ListBucketMultipartUploads (List)
s3:ListCallerAccessGrants (List)
s3:ListJobs (List)
s3:ListMultiRegionAccessPoints (List)
s3:ListObjectAnnotations (List)
s3:ListObjectVersionAnnotations (List)
s3:ListStorageLensConfigurations (List)
s3:ListStorageLensGroups (List)
s3:ListTagsForResource (List)

SNS: 1 actions

sns:ListTopics (List)

Data-plane actions (3)

By access level: 3 List.

Data-plane actions by service
Service	Granted	Access levels and limits	Granted by
S3	3 of 25	3 List; 0 restricted, 0 conditional	s3:List*

S3: 3 actions

s3:ListBucket (List)
s3:ListBucketVersions (List)
s3:ListMultipartUploadParts (List)

Excluded and conditional actions

No patterns are excluded by NotAction or Deny statements.

Resource scope and attachment

Resource scope across granted actions: mixed.

Can be attached: Yes, to users, groups and roles.

Why this tier

Grants at least 80% of the write and permissions-management actions of: datapipeline (11 of 11).
Grants iam:PassRole, but only for scoped roles or under conditions (for example iam:PassedToService).

Guidance

Practical scope

Two statements. The first allows twelve actions on Resource "*": datapipeline:*, s3:List*, dynamodb:DescribeTable, rds:DescribeDBInstances, rds:DescribeDBSecurityGroups, redshift:DescribeClusters, redshift:DescribeClusterSecurityGroups, sns:ListTopics, iam:ListRoles, iam:GetRolePolicy, iam:GetInstanceProfile and iam:ListInstanceProfiles. The second allows iam:PassRole on two roles only: DataPipelineDefaultResourceRole and DataPipelineDefaultRole.

Use cases

Let users create and manage AWS Data Pipeline pipelines, with list and describe access to related services, and permission to pass the two default Data Pipeline roles.

Best practices

AWS managed policies don't grant least privilege permissions. The IAM User Guide suggests using IAM Access Analyzer to see which permissions principals actually use, then writing a custom policy or generating one with only the required permissions.

Security considerations

datapipeline:* on all resources gives full control of Data Pipeline. iam:PassRole is limited to DataPipelineDefaultResourceRole and DataPipelineDefaultRole, so a principal can configure pipelines to run with whatever permissions those two roles hold.
Passing a role to a service needs iam:PassRole. The IAM User Guide says that to pass a role to an AWS service, a user must have permission to pass the role to the service, which helps administrators ensure that only approved users can configure a service with a role that grants permissions.
It also includes iam:GetRolePolicy and iam:GetInstanceProfile on all resources, which let a principal read role policy details.
You cannot change the permissions in an AWS managed policy. If AWS updates the policy, the update affects every user, group and role it is attached to.

Assignment guidance

You can attach this policy to your users, groups and roles. The reference page also links to guidance on creating a permission set using AWS managed policies in IAM Identity Center. It fits where building and running Data Pipeline pipelines is intended.

Same service

Same domain

Frequently asked questions

When should I attach AWSDataPipeline_PowerUser?: The reference page says you can attach AWSDataPipeline_PowerUser to your users, groups and roles, and describes it as full access to Data Pipeline with list access to related services and passRole for the default roles. Attach it for people who build and run pipelines.
What does AWSDataPipeline_PowerUser grant?: It allows datapipeline:* plus eleven list, describe and get actions for S3, DynamoDB, Redshift, RDS, SNS and IAM on all resources, and iam:PassRole on DataPipelineDefaultResourceRole and DataPipelineDefaultRole.
What are the security risks of AWSDataPipeline_PowerUser?: datapipeline:* gives full control of Data Pipeline, and iam:PassRole on the two default roles means pipelines can run with whatever permissions those roles hold. AWS managed policies don't grant least privilege permissions, and you must consider the security risk of granting principals more permissions than they need. AWS updates to the policy affect every identity it is attached to.

Policy JSON

Download policy.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:List*",
        "dynamodb:DescribeTable",
        "rds:DescribeDBInstances",
        "rds:DescribeDBSecurityGroups",
        "redshift:DescribeClusters",
        "redshift:DescribeClusterSecurityGroups",
        "sns:ListTopics",
        "iam:ListRoles",
        "iam:GetRolePolicy",
        "iam:GetInstanceProfile",
        "iam:ListInstanceProfiles",
        "datapipeline:*"
      ],
      "Effect": "Allow",
      "Resource": [
        "*"
      ]
    },
    {
      "Action": "iam:PassRole",
      "Effect": "Allow",
      "Resource": [
        "arn:aws:iam::*:role/DataPipelineDefaultResourceRole",
        "arn:aws:iam::*:role/DataPipelineDefaultRole"
      ]
    }
  ]
}

Version history

Current version v2, edited by AWS on 2017-08-17. Version history is recorded from 2026-11-11. Earlier versions are in the IAM console under Policy versions.

Attach snippets

AWS CLI

aws iam attach-role-policy --role-name ROLE_NAME --policy-arn arn:aws:iam::aws:policy/AWSDataPipeline_PowerUser
aws iam attach-user-policy --user-name USER_NAME --policy-arn arn:aws:iam::aws:policy/AWSDataPipeline_PowerUser
aws iam attach-group-policy --group-name GROUP_NAME --policy-arn arn:aws:iam::aws:policy/AWSDataPipeline_PowerUser

CloudFormation

Resources:
  ExampleRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument: {}  # replace with your trust policy
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AWSDataPipeline_PowerUser

Terraform

resource "aws_iam_role_policy_attachment" "awsdatapipeline_poweruser" {
  role       = aws_iam_role.example.name
  policy_arn = "arn:aws:iam::aws:policy/AWSDataPipeline_PowerUser"
}

CDK (TypeScript)

role.addManagedPolicy(
  iam.ManagedPolicy.fromAwsManagedPolicyName("AWSDataPipeline_PowerUser"),
);

Sources

AWSDataPipeline_PowerUser (AWS Managed Policy Reference Guide) (retrieved 2026-11-13; supports summary, practicalScope, useCases, securityConsiderations, assignmentGuidance, faqs)
Grant a user permissions to pass a role to an AWS service (IAM User Guide) (retrieved 2026-11-13; supports securityConsiderations)
Managed policies and inline policies (IAM User Guide) (retrieved 2026-11-12; supports securityConsiderations, faqs)
AWS managed policies for job functions (IAM User Guide) (retrieved 2026-11-12; supports bestPractices, faqs)