Streamlining IAM Role Creation for S3 Bucket Access with AWS Policy Generator: A Step-by-Step Guide

Last updated: October 2026

Creating IAM roles for Amazon S3 bucket access is essential for secure AWS cloud architecture. Proper governance, security, and cost controls start with well-defined access policies. AWS IAM roles provide least-privilege permissions without embedding long-term credentials, and the AWS Policy Generator simplifies writing the permissions policy by removing manual JSON editing.

This step-by-step IAM role guide walks you through creating an S3 bucket, setting up an IAM role with a least-privilege S3 access policy, and linking the role using the AWS Management Console and Policy Generator.

Pre-requisites

• An AWS account with access to the AWS Management Console.
• Appropriate IAM permissions to create S3 buckets and roles.

Step 1: Sign in to the AWS Management Console

Navigate to the AWS Management Console and sign in with your AWS account credentials. Once logged in, you’ll land on the AWS Console homepage.

Step 2: Access the S3 Service

In the AWS Console, type “S3” into the search bar at the top and select “S3” from the results. Alternatively, find “S3” under the “Storage” category in the services menu. This will take you to the S3 dashboard.

Step 3: Start Creating a Bucket

On the S3 dashboard, click the orange “Create bucket” button. This opens the “Create bucket” form where you’ll configure your bucket settings.

Step 4: Configure Bucket Settings

Fill out the required fields in the “Create bucket” form:

• Bucket Name: Enter a globally unique name for your bucket (e.g., my-unique-bucket-2025). Bucket names must follow AWS naming rules, such as being lowercase and not containing spaces.
• AWS Region: Select the region where you want your bucket to reside (e.g., US East (N. Virginia) us-east-1).
• Object Ownership: Keep “ACLs disabled”, the default for new buckets and the recommended setting, unless you need Access Control Lists.
• Block Public Access: Keep “Block all public access” turned on, which is the default for new buckets, unless your use case requires public access.
• Bucket Versioning: Optionally enable versioning if you need to keep multiple versions of objects.
• Encryption: S3 encrypts every new object with SSE-S3 by default, so choose SSE-KMS here only if you need control over the encryption keys.

Leave other settings as default unless you have specific requirements. Scroll to the bottom and click “Create bucket.”

Once your S3 bucket is created, configure permissions by setting up access policies or enabling public access for specific use cases like hosting static websites. Explore S3’s distributed architecture, which ensures high durability by replicating data across multiple Availability Zones in your chosen region. Upload raw data, such as CSVs or logs, using the Console’s drag-and-drop feature, and enable versioning to track changes. Monitor costs with the AWS Pricing Calculator, as S3 pricing depends on storage, requests, and data transfers, with savings possible through Lifecycle policies.

Step 5: Verify Bucket Creation

After clicking “Create bucket,” you’ll be redirected to the S3 dashboard, where your new bucket will appear in the list. Click on the bucket name to view its details and confirm it was created successfully.

Bucket Created

Your Amazon S3 bucket is ready. You can now use this bucket to store objects, host static websites, or integrate it with other AWS services. For more advanced configurations, explore features like lifecycle rules, bucket policies, or CORS settings in the AWS S3 documentation.

How to Link an IAM Role for an S3 Bucket

After creating an S3 bucket, you need to grant AWS services or users controlled access to it. An IAM role is a secure way to delegate permissions without embedding credentials. This section creates a role that a Lambda function can use to read myawsbucket8919. The same steps work for EC2 or another service, and only the service you pick in step 2, and with it the trust policy, changes.

Prerequisites

• An AWS account with administrative access.
• An existing S3 bucket (e.g. myawsbucket8919).

1. Navigate to the IAM Console

• Log in to the AWS Management Console.
• Search for "IAM" in the search bar and select the IAM service.
• In the left-hand menu, click Roles under "Access management."

2. Create a New IAM Role

• Click the Create role button.
• Under Trusted entity type, select AWS service.
• Under Service or use case, choose the service that will read the bucket, for example Lambda, and click Next. Choose S3 here only if Amazon S3 itself needs to assume the role, because the service you select decides which principal can use it.

3. Check the Role Trust Policy

The service you choose supplies the trust policy, which the wizard shows on its review page. For Lambda, it allows lambda.amazonaws.com to assume the role:

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

A trust policy names a Principal and has no Resource element. A role trusted only by s3.amazonaws.com can be assumed only by Amazon S3 itself, so a Lambda function or EC2 instance couldn't use it.

4. Create the Permissions Policy Using AWS Policy Generator

• The permissions policy defines what the role can do. For this use case, we’ll create a read-only policy for myawsbucket8919.
• Open the AWS Policy Generator in a new browser tab and select IAM Policy as the policy type.
• Add a statement with Effect Allow, AWS Service Amazon S3, the ListBucket action and the ARN arn:aws:s3:::myawsbucket8919, then click Add Statement. Add a second statement for the GetObject action with the ARN arn:aws:s3:::myawsbucket8919/* in the same way.
• Click Generate Policy and copy the JSON.
• In the IAM console, open Policies in a new tab, click Create policy, switch the policy editor to JSON and paste the policy. IAM Access Analyzer checks the policy as you edit it and lists any errors or warnings below the editor.
• Click Next, name the policy S3ReadOnlyMyBucket, add an optional description (e.g., "Read-only access to myawsbucket8919"), and click Create policy.
• The generated policy is equivalent to:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::myawsbucket8919"
    },
    {
      "Sid": "ReadObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::myawsbucket8919/*"
    }
  ]
}

• Back in the role wizard, refresh the Permissions policies list, search for S3ReadOnlyMyBucket, select it, and click Next. Don't add broad AWS managed policies such as AmazonS3FullAccess or AmazonS3ReadOnlyAccess, which cover every bucket in the account.
• A Lambda execution role usually also needs the AWSLambdaBasicExecutionRole managed policy, so the function can write its logs to CloudWatch.

5. Name, Review and Create the Role

• Enter a Role name (e.g., myrole8919).
• Add an optional description (e.g., "Lets a Lambda function read myawsbucket8919").
• Check the trust policy and the attached policies on the same page.
• Add optional tags (e.g., Purpose: S3Access).
• Click Create role, then choose the role as the execution role when you create or edit the Lambda function.

Best Practices

• Least Privilege: Use specific actions (s3:GetObject, s3:ListBucket) instead of s3:*, on the bucket's own ARNs.
• Clear Naming: Use names like S3ReadOnlyMyBucket to indicate purpose.
• Validate Policies: Review the IAM Access Analyzer findings in the policy editor before saving a policy.
• Monitor Access: Use AWS CloudTrail to track role actions.

Troubleshooting

• JSON Syntax Errors: The Policy Generator avoids manual JSON input. If you edit JSON by hand, the policy editor's validation checks IAM grammar and best practices, which a generic JSON linter can't.
• Service Can't Assume the Role: Check that the trust policy names that service, for example "Service": "lambda.amazonaws.com" for a Lambda function.
• Resource in Trust Policy: Trust policies must not include a Resource element. The console builds the trust policy from the service you choose, and the bucket ARNs belong only in the permissions policy.
• Incorrect ARN: Verify myawsbucket8919 is entered correctly in the Policy Generator.

Conclusion

You’ve created an IAM role that a Lambda function can use to read myawsbucket8919, with a least-privilege permissions policy built in the AWS Policy Generator. For another service, repeat the steps and pick that service in step 2. If you are loading data from S3 into a cloud data warehouse, see our guide to working with unstructured data in Snowflake or our cloud migration strategies guide. For advanced setups, explore policy conditions or cross-account access.

Frequently Asked Questions

What is an IAM role in AWS?

An IAM role is an AWS identity with specific permissions that can be assumed by AWS services, users, or applications. Unlike IAM users, roles do not have permanent credentials and instead provide temporary security credentials for accessing AWS resources like S3 buckets.

Why should I use the AWS Policy Generator instead of writing JSON manually?

The AWS Policy Generator builds the policy JSON from a form, which avoids common syntax errors and keeps ARNs in the right format. The trust policy comes from the service you choose in the IAM role wizard, not from the generator, and the IAM policy editor validates the generated policy with IAM Access Analyzer when you paste it in.

What is the principle of least privilege for S3 access?

The principle of least privilege means granting only the minimum permissions needed. For S3 access, this means specifying exact actions like s3:GetObject and s3:ListBucket rather than using wildcard permissions like s3:*, and restricting access to specific bucket ARNs.