boto3-to-IAM action reference

aws-iam.io looks up the real IAM action for each boto3 method call in a static dataset built from AWS's own Service Authorization Reference — the same source of truth behind the IAM console's policy editor. For the rare method that dataset doesn't cover yet, it falls back to a simple rule: convert the snake_case method name to PascalCase and prefix it with the boto3 service id (e.g. put_object on s3 → s3:PutObject). This page shows common examples, the naming quirks that rule alone would get wrong, and what's still genuinely unresolved.

Common methods

For most services and methods, the action is a direct, unsurprising match:

Service	boto3 method	IAM action
S3	put_object	s3:PutObject
S3	get_object	s3:GetObject
S3	delete_object	s3:DeleteObject
S3	create_bucket	s3:CreateBucket
DynamoDB	put_item	dynamodb:PutItem
DynamoDB	get_item	dynamodb:GetItem
DynamoDB	query	dynamodb:Query
DynamoDB	scan	dynamodb:Scan
Lambda	create_function	lambda:CreateFunction
Lambda	update_function_code	lambda:UpdateFunctionCode
Lambda	list_functions	lambda:ListFunctions
EC2	run_instances	ec2:RunInstances
EC2	describe_instances	ec2:DescribeInstances
EC2	terminate_instances	ec2:TerminateInstances
SQS	send_message	sqs:SendMessage
SQS	receive_message	sqs:ReceiveMessage
SNS	publish	sns:Publish
SNS	create_topic	sns:CreateTopic
IAM	create_role	iam:CreateRole
IAM	attach_role_policy	iam:AttachRolePolicy
STS	assume_role	sts:AssumeRole
STS	get_caller_identity	sts:GetCallerIdentity

Naming quirks the dataset resolves automatically

AWS's own API-to-IAM naming isn't always a clean PascalCase match. These are real examples where a naive "just PascalCase the method name" guess would be wrong — aws-iam.io uses the real action on the right instead:

Code	Naive PascalCase guess	Real IAM action (used by aws-iam.io)	Why it diverges
lam.invoke(...)	lambda:Invoke	lambda:InvokeFunction	Lambda's invoke API operation maps to a differently-named IAM action.
sfn.start_execution(...)	stepfunctions:StartExecution	states:StartExecution	The boto3 service id is stepfunctions, but its IAM action prefix is states.
s3.list_objects_v2(...)	s3:ListObjectsV2	s3:ListBucket	Listing objects in a bucket is authorized via the ListBucket action regardless of API version.
s3.list_buckets(...)	s3:ListBuckets	s3:ListAllMyBuckets	A legacy S3 naming quirk predating consistent action naming conventions.
rds.describe_db_instances(...)	rds:DescribeDbInstances	rds:DescribeDBInstances	PascalCasing db gives Db; the real action capitalizes it as DB.

Still approximate: resource-style method calls

boto3's resource interface (as opposed to the lower-level client) exposes generic verbs like .delete() and .load() that don't name which resource type they act on:

Code	Generated action	Correct IAM action	Why
s3.Object(...).delete()	s3:Delete	s3:DeleteObject	The method name alone doesn't say whether this is an Object, Bucket, or another S3 resource type — that's static-analysis-only information the code doesn't carry.

This is the one class of case the AWS action dataset can't fix, since it's a code-parsing gap rather than a naming lookup — review resource-style calls in the generated policy manually.

Parser limitations

The code parser itself also has known blind spots, unrelated to IAM naming:

• Not comment-aware. A commented-out call like # s3.delete_bucket(...) is still parsed and included in the policy.
• Not string-literal-aware. Text that merely mentions a call inside a string, such as "remember to call s3.delete_object()", is also picked up.
• Inline chained calls without a variable assignment are missed. A one-liner like boto3.client('s3').put_object(...) (never assigned to a variable) is not detected, since the generator tracks service bindings through variable names.

See the FAQ for more context, and always review the generated policy before using it in production.

Try the generator