AWS IAM Service Principals Reference

What is an AWS service principal?

A service principal is an identifier that represents an AWS service in IAM policies. When you see something like lambda.amazonaws.com or ec2.amazonaws.comin a policy's Principal element, that's a service principal. These identifiers allow AWS services to assume IAM roles and perform actions on your behalf.

Think of service principals as the identity card that AWS services present when they need to access resources in your account. Without the correct service principal in your trust policy, an AWS service cannot assume the role you created for it.

The service principal is defined by AWS itself. You cannot create custom service principals or use wildcards like "Service": "*" in IAM policies. Each AWS service has its own specific identifier.

How to use this service principal list

1. Search for the AWS service name, such as Lambda, ECS Tasks, CloudTrail, or CodeBuild.
2. Copy the exact service principal value, for example lambda.amazonaws.com or ecs-tasks.amazonaws.com.
3. Add it to the Principal.Service field in your IAM role trust policy or resource-based policy.
4. Use the documentation link when you need AWS service-specific trust policy requirements.
5. Add aws:SourceAccount or aws:SourceArn conditions whenever the target AWS service supports them.

The most common mistake is copying a service name instead of the service principal. IAM needs the exact principal string in the policy, not the marketing name of the AWS service.

Service principal format and structure

The standard service principal format is:

service-name.amazonaws.com

Common examples include:

• lambda.amazonaws.com for AWS Lambda
• ec2.amazonaws.com for Amazon EC2
• s3.amazonaws.com for Amazon S3
• ecs-tasks.amazonaws.com for Amazon ECS tasks
• codebuild.amazonaws.com for AWS CodeBuild

When multiple services need to assume the same role, specify them as an array:

"Principal": {
  "Service": [
    "ecs.amazonaws.com",
    "elasticloadbalancing.amazonaws.com"
  ]
}

This syntax is useful when you need a shared role for services that work together. For a deeper CDK example, read the guide on creating IAM roles with multiple principals using AWS CDK.

How service principals enable service-to-service access

1. An AWS service, such as Lambda, needs to access resources in your account.
2. The service presents its service principal and calls sts:AssumeRole.
3. IAM checks the role's trust policy to verify the service principal is allowed.
4. If authorized, IAM returns temporary security credentials.
5. The service uses these credentials to access your resources.

This mechanism ensures that only the intended AWS services can assume roles in your account. The trust policy acts as the gatekeeper, and the service principal is the key.

Trust policies for IAM roles

Trust policies define which principals can assume an IAM role. For service roles, you specify the AWS service principal that should be able to assume the role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This trust policy allows AWS Lambda to assume the role. When Lambda needs to execute your function, it presents its service principal and calls sts:AssumeRole. IAM validates the trust policy and issues temporary credentials.

Resource-based policies

Service principals also appear in resource-based policies attached to AWS resources like S3 buckets, SNS topics, or SQS queues. These policies allow AWS services to access your resources directly.

For example, an S3 bucket policy that allows CloudTrail to write logs uses the cloudtrail.amazonaws.com service principal. Add aws:SourceAccount or aws:SourceArn conditions whenever possible so another account cannot misuse the service principal to write to your resource.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudTrailAclCheck",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::my-cloudtrail-bucket",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "111122223333"
        }
      }
    },
    {
      "Sid": "CloudTrailWrite",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-cloudtrail-bucket/AWSLogs/111122223333/*",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "111122223333"
        }
      }
    }
  ]
}

Service-linked roles

Service-linked roles are a special type of service role that's predefined by an AWS service. These roles include the permissions the service needs to operate, and only that specific service can assume them.

• AWS defines the permissions and trust policy for the role.
• Many services create the role automatically when you first use the service.
• You usually cannot delete the role until the dependent service resources are removed.
• The role name typically follows the AWSServiceRoleForServiceName pattern.

Regionalized service principals

Most service principals work globally across all AWS regions. For opt-in regions launched after March 20, 2019, service principal behavior changes for cross-region requests.

Common opt-in regions include:

• Same-region requests normally use service-name.amazonaws.com.
• Cross-region requests from opt-in regions use service-name.region.amazonaws.com.
• For IAM role trust policies, AWS recommends the non-regionalized format because IAM is global.

Example: an S3 bucket in ap-east-1 sending notifications to an SNS topic in another region may need s3.ap-east-1.amazonaws.com instead of s3.amazonaws.com.

{
  "Effect": "Allow",
  "Principal": {
    "Service": "s3.ap-east-1.amazonaws.com"
  },
  "Action": "SNS:Publish",
  "Resource": "arn:aws:sns:ap-southeast-1:111122223333:MyTopic",
  "Condition": {
    "StringEquals": {
      "aws:SourceAccount": "111122223333"
    },
    "ArnLike": {
      "aws:SourceArn": "arn:aws:s3:::my-bucket-*"
    }
  }
}

Confused deputy protection

The confused deputy problem occurs when an entity without permission tricks a more privileged service into performing actions on its behalf. With service principals, this usually appears in cross-service access.

Use these condition keys in resource policies where supported:

For multi-account environments, Resource Control Policies can enforce this centrally. The pattern below denies S3 access by AWS service principals unless the request comes from your AWS Organization:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceConfusedDeputyProtection",
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:SourceOrgID": "o-abc123xyz"
        },
        "Null": {
          "aws:SourceAccount": "false"
        },
        "Bool": {
          "aws:PrincipalIsAWSService": "true"
        }
      }
    }
  ]
}

Infrastructure as code examples

AWS CDK provides the ServicePrincipal class for trust policies:

import * as iam from 'aws-cdk-lib/aws-iam';

const lambdaRole = new iam.Role(this, 'LambdaExecutionRole', {
  assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
  description: 'Execution role for Lambda function',
});

In CloudFormation, define service principals in the AssumeRolePolicyDocument:

Resources:
  CloudFormationServiceRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: cloudformation.amazonaws.com
            Action: sts:AssumeRole

Troubleshooting service principal errors

• Invalid principal in policy: check the service principal format, avoid wildcards in the Service element, and verify the service principal exists in the table.
• Access Denied when a service assumes a role: verify the trust policy includes the correct service principal and allows sts:AssumeRole.
• Cross-region requests failing: check whether the source is in an opt-in region and needs the regionalized service principal format.
• Service-linked role cannot be deleted: remove the resources that depend on the service-linked role first.

IDE autocomplete

If you prefer working directly in your IDE, the IAM Service Principal Snippets extension autocompletes service principals directly in IAM policies.