AWS Service Principals List: Complete Reference with 578 Principals (2026)

When working with AWS IAM policies and trust relationships, you need to know the exact service principal for each AWS service. This comprehensive reference provides instant access to all 578 AWS service principals, making IAM policy development faster and more accurate.

In this guide, you'll learn:

• What service principals are and how they enable service-to-service access
• How to use the complete auto-updated reference table
• Trust policies, resource-based policies, and service-linked roles
• Regional service principal variations for opt-in regions
• How to protect against confused deputy attacks
• Infrastructure as Code examples for CDK and CloudFormation

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.com in 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've created for it.

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

Service Principal Format and Structure

Service principals follow a standardized naming convention. The standard format is:

service-name.amazonaws.com

Here are some common examples:

• 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, you can specify them using an array format:

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

This syntax is useful when you need a shared role for services that work together, like ECS and Elastic Load Balancing. You can learn more about creating such roles in my guide on how to create IAM roles with multiple principals using AWS CDK.

How Service Principals Enable Service-to-Service Access

Service principals work through a trust relationship mechanism. Here's how the flow works:

1. An AWS service (like 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.

Complete AWS Service Principals Reference (2026)

The table below contains every AWS service principal, automatically fetched from the AWS Policy Generator and updated for 2026. Use your browser's search function (Ctrl+F or Cmd+F) to quickly find the service you need:

Total Unique Service Principals: 578 | With Documentation Links: 91 | Last Updated: January 2, 2026

Note: The data is automatically fetched from the official AWS Policy Generator and parsed into this markdown table using a custom Node.js script. The table is regularly updated to include the latest AWS services.

How to Use This Service Principal List

Now that you have the complete reference, let's explore the three main contexts where you'll use service principals: trust policies, resource-based policies, and service-linked roles.

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. This is the most common use case.

Here's a basic trust policy structure:

{
  "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.

For Lambda execution roles specifically, the role also needs a permissions policy granting access to CloudWatch Logs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}

You can learn how to assign custom IAM roles to Lambda functions using AWS CDK for more advanced configurations.

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.

Here's an example S3 bucket policy that allows CloudTrail to write logs:

{
  "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"
        }
      }
    }
  ]
}

Notice the aws:SourceAccount condition. This is critical for security, and we'll cover why in the confused deputy protection section below.

Service-Linked Roles

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

Key characteristics of service-linked roles:

• Predefined by AWS: You cannot modify the permissions
• Automatic creation: Many services create them automatically when you first use the service
• Cannot be deleted until resources are removed: Ensures the service can continue operating
• Named with a specific pattern: Usually AWSServiceRoleFor<ServiceName>

Here's an example of common service-linked roles:

For container workloads, understanding roles is especially important. Check out my guide on ECS task role vs execution role to understand how ECS uses different service principals for different purposes.

Regionalized Service Principals: Opt-In Regions Guide

Most service principals work globally across all AWS regions. However, when you're working with opt-in regions (regions launched after March 2019), service principal behavior changes for cross-region requests.

Understanding this distinction is essential when building multi-region architectures or when your resources span both standard and opt-in regions.

When to Use Regionalized Format

AWS regions launched after March 20, 2019 are called opt-in regions. These include:

The key rule is:

• Same-region requests: Use the standard format service-name.amazonaws.com
• Cross-region requests from opt-in regions: Use the regionalized format service-name.{region}.amazonaws.com

For IAM role trust policies, AWS recommends always using the non-regionalized format because IAM is a global service.

Cross-Region Service Principal Examples

Let's say you have an S3 bucket in the opt-in region ap-east-1 (Hong Kong) and want to send bucket notifications to an SNS topic in ap-southeast-1 (Singapore).

Incorrect approach (will fail):

{
  "Principal": {
    "Service": "s3.amazonaws.com"
  }
}

Correct approach (will succeed):

{
  "Principal": {
    "Service": "s3.ap-east-1.amazonaws.com"
  }
}

Since the bucket is in an opt-in region and makes a cross-region request, you must use the regionalized service principal name s3.ap-east-1.amazonaws.com.

Here's a complete SNS topic policy example for this scenario:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "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 with Service Principals

The confused deputy problem is a critical security issue where an entity without permission can trick a more privileged entity (the "deputy") into performing actions on their behalf. When using service principals, this typically happens with cross-service access.

For example, without proper protection, an attacker could configure their own CloudTrail in a different account to write logs to your S3 bucket, if they know your bucket name and your bucket policy only checks the service principal.

This is why following AWS account security best practices includes implementing confused deputy protection in all resource-based policies.

Using aws:SourceAccount and aws:SourceArn

AWS provides condition keys to prevent confused deputy attacks. Here's when to use each:

Most effective approach - use aws:SourceArn with the full ARN:

{
  "Effect": "Allow",
  "Principal": {
    "Service": "appstream.amazonaws.com"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/script.ps1",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:fleet/MyFleet"
    }
  }
}

If the ARN doesn't contain the account ID, use both aws:SourceArn and aws:SourceAccount:

{
  "Condition": {
    "StringEquals": {
      "aws:SourceAccount": "111122223333"
    },
    "ArnLike": {
      "aws:SourceArn": "arn:aws:s3:::my-bucket-*"
    }
  }
}

Organization-Wide Protection with RCPs

For organizations managing multiple AWS accounts, Resource Control Policies (RCPs) provide centralized enforcement of confused deputy protection. Instead of modifying individual resource policies, you can apply organization-wide controls.

Here's an RCP that denies AWS service principals access to S3 unless the request originates from within your 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"
        }
      }
    }
  ]
}

This policy ensures that AWS service principals can only access S3 buckets when the request originates from your organization. For more on organization-level controls, see my guide on Service Control Policies and AWS Organizations best practices.

Service Principals in Infrastructure as Code

When defining IAM roles in infrastructure as code, you need to correctly specify service principals. Here are examples for both AWS CDK and CloudFormation.

AWS CDK Examples

AWS CDK provides the ServicePrincipal class for defining service principals in trust policies:

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

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

// Add permissions to write to CloudWatch Logs
lambdaRole.addToPolicy(new iam.PolicyStatement({
  effect: iam.Effect.ALLOW,
  actions: [
    'logs:CreateLogGroup',
    'logs:CreateLogStream',
    'logs:PutLogEvents',
  ],
  resources: ['arn:aws:logs:*:*:*'],
}));

For roles that need multiple service principals, use CompositePrincipal:

const multiServiceRole = new iam.Role(this, 'MultiServiceRole', {
  assumedBy: new iam.CompositePrincipal(
    new iam.ServicePrincipal('ecs.amazonaws.com'),
    new iam.ServicePrincipal('elasticloadbalancing.amazonaws.com'),
  ),
});

Learn more about this pattern in my detailed guide on creating IAM roles with multiple principals using AWS CDK.

CloudFormation Trust Policy Templates

In CloudFormation, define service principals in the AssumeRolePolicyDocument:

AWSTemplateFormatVersion: '2010-09-09'
Description: CloudFormation service role example

Resources:
  CloudFormationServiceRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: CloudFormationServiceRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: cloudformation.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/PowerUserAccess
      Description: Service role for CloudFormation deployments

For cross-account deployments using cross-account assume role, you can combine service principals with account principals.

Troubleshooting Service Principal Errors

When working with service principals, you may encounter common errors. Here are the most frequent issues and how to resolve them:

"Invalid principal in policy"

• Check that the service principal format is correct (service-name.amazonaws.com)
• Verify you haven't used wildcards (*) in the Service element
• Ensure the service principal exists (check the table above)

"Access Denied" when a service tries to assume a role

• Verify the trust policy includes the correct service principal
• Check that the sts:AssumeRole action is allowed
• For opt-in regions, ensure you're using the correct format (regionalized vs non-regionalized)

Cross-region requests failing

• If the source is in an opt-in region and the destination is in another region, use the regionalized format
• Example: s3.ap-east-1.amazonaws.com instead of s3.amazonaws.com

Service-linked role cannot be deleted

• Service-linked roles can only be deleted after removing all associated resources
• Check for remaining resources in the service that created the role

Confused deputy protection blocking legitimate access

• Verify your aws:SourceAccount or aws:SourceArn conditions match the actual source
• For organization-wide RCPs, ensure the aws:SourceOrgID is correct

For CLI-based troubleshooting, you can assume IAM roles via CLI to test whether your trust policies are configured correctly.

VS Code Extension for Service Principal Autocomplete

If you prefer working directly in your IDE, I've created a VS Code extension that automatically generates IAM service principal snippets for you.

Instead of looking up this table every time, you can use the IAM Service Principal Snippets extension to autocomplete service principals directly in your IAM policies.

Related AWS Reference Resources

• AWS CloudFormation Resource Attributes - Complete reference of all CloudFormation resource types and their attributes
• AWS CloudFormation Resource Properties - Comprehensive table of all CloudFormation resource properties
• Amazon Resource Names (ARNs) - Complete reference list of ARNs for all AWS services
• AWS IAM Documentation - Official guide to IAM policy principals