My Note

AWS Account Access Guide: Admin, Developer, Tester, Operator, Finance, Auditor, and CI/CD

May 2, 2026 • Category: devops • Tags: aws, iam, identity-center, devops, security, billing, cicd

A comprehensive Markdown guide for creating and managing new AWS access accounts/identities for different roles such as administrator, developer, tester, operator, billing/finance, security auditor, read-only user, and automation/CI/CD.

Last updated: 2026-05-02
Recommended model: AWS IAM Identity Center + Groups + Permission Sets
Fallback model: IAM Users + IAM Groups + Managed/Customer Policies

Table of Contents

  1. Terminology: AWS Account vs User Account
  2. Recommended Access Model
  3. Role Matrix
  4. Overall Architecture
  5. Method A: IAM Identity Center Setup
  6. Single AWS Account: Admin and Developer CLI Profiles
  7. Sandbox Development and Test Account Setup
  8. Method B: IAM User Fallback Setup
  9. Admin Account Setup
  10. Developer Account Setup
  11. Tester / QA Account Setup
  12. Operator / DevOps Account Setup
  13. Finance / Billing Account Setup
  14. Security Auditor Account Setup
  15. Read-Only Account Setup
  16. CI/CD and Automation Access
  17. Environment-Based Access Design
  18. Billing Visibility Setup
  19. MFA and Password Policy
  20. CLI Access Setup
  21. Custom Policy Examples
  22. Verification Checklist
  23. Troubleshooting
  24. Best Practices
  25. Reference Links

Terminology: AWS Account vs User Account

The word account can mean two different things in AWS.

1. AWS account

An AWS account is a billing, security, and resource boundary.

Examples:

Production AWS account
Development AWS account
Testing AWS account
Security AWS account
Management AWS account

2. User account / identity

A user account is a login identity used by a person or service.

Examples:

admin@example.com
developer@example.com
tester@example.com
operator@example.com
finance@example.com

In this document, “making new accounts” mostly means creating new user identities and access roles inside AWS.

Recommended Access Model

For human users, prefer:

IAM Identity Center
→ User
→ Group
→ Permission Set
→ AWS Account

For automation, prefer:

IAM Role
→ Short-lived credentials
→ Limited permissions

Avoid using:

Root user for daily work
Long-term access keys for humans
AdministratorAccess for everyone

Role Matrix

Role Main Purpose Recommended Permission Billing Access IAM Management Production Access
Admin Full account administration AdministratorAccess Optional / Yes Yes Yes
Developer Build and deploy application resources PowerUserAccess or custom No Usually no Limited
Tester / QA Test apps and inspect test resources Custom QA policy or limited PowerUserAccess No No Usually no
Operator / DevOps Monitor, operate, restart, deploy Custom operations policy No Limited / No Yes, limited
Finance / Billing View or manage costs AWSBillingReadOnlyAccess or Billing Yes No No
Security Auditor Review security posture SecurityAudit + read-only No No write access Yes, read-only
Read-Only Inspect resources ReadOnlyAccess No No Read-only
CI/CD Deploy from pipeline IAM role with scoped policy No Only iam:PassRole if needed Environment-specific
Emergency Admin Break-glass access AdministratorAccess Yes Yes Yes

Overall Architecture

flowchart TD
    Root[AWS Root User] --> RootMFA[Root MFA Enabled]
    Root --> BillingToggle[Activate IAM Billing Access if needed]
    Root --> Emergency[Emergency Break-Glass Admin]

    IC[IAM Identity Center] --> Users[Users]
    IC --> Groups[Groups]
    IC --> PS[Permission Sets]

    Users --> Groups
    Groups --> PS

    PS --> AdminPS[Admin Permission Set]
    PS --> DevPS[Developer Permission Set]
    PS --> TestPS[Tester Permission Set]
    PS --> OpsPS[Operator Permission Set]
    PS --> FinancePS[Finance Permission Set]
    PS --> AuditPS[Security Audit Permission Set]
    PS --> ReadOnlyPS[ReadOnly Permission Set]

    AdminPS --> AWSAccounts[AWS Accounts]
    DevPS --> AWSAccounts
    TestPS --> AWSAccounts
    OpsPS --> AWSAccounts
    FinancePS --> AWSAccounts
    AuditPS --> AWSAccounts
    ReadOnlyPS --> AWSAccounts

    CICD[CI/CD System] --> Role[IAM Role]
    Role --> AWSAccounts

Method A: IAM Identity Center Setup

IAM Identity Center is the recommended way to manage access for people.

Why use IAM Identity Center?

It helps you:

IAM Identity Center Flow

sequenceDiagram
    participant Owner as Account Owner/Admin
    participant IC as IAM Identity Center
    participant Group as Group
    participant PS as Permission Set
    participant AWS as AWS Account
    participant User as New User

    Owner->>IC: Create user
    Owner->>IC: Create group
    Owner->>Group: Add user to group
    Owner->>PS: Create permission set
    Owner->>AWS: Assign group + permission set
    User->>IC: Sign in to AWS access portal
    IC->>AWS: Grants temporary access

Step 1: Enable IAM Identity Center

  1. Open the AWS Console.
  2. Search for IAM Identity Center.
  3. Enable IAM Identity Center.
  4. Choose the identity source:
    • Built-in Identity Center directory
    • External identity provider
    • Active Directory

For a small team, the built-in directory is usually enough.

Step 2: Create groups

Create groups based on job roles:

AWS-Admins
AWS-Developers
AWS-Testers
AWS-Operators
AWS-Finance
AWS-SecurityAuditors
AWS-ReadOnly

Group-based access is easier to manage than assigning permissions to every user individually.

Step 3: Create users

Example users:

admin@example.com
developer@example.com
tester@example.com
operator@example.com
finance@example.com
security@example.com
readonly@example.com

Then add each user to the appropriate group.

Step 4: Create permission sets

Suggested permission sets:

Permission Set Name Attach Policy
AdminAccess AdministratorAccess
DeveloperAccess PowerUserAccess or custom developer policy
TesterAccess Custom tester policy
OperatorAccess Custom operator policy
FinanceReadOnlyAccess AWSBillingReadOnlyAccess
FinanceFullAccess Billing
SecurityAuditAccess SecurityAudit + ReadOnlyAccess
ReadOnlyAccess ReadOnlyAccess

Step 5: Assign groups to AWS accounts

Example:

AWS Account Group Permission Set
Management AWS-Admins AdminAccess
Development AWS-Developers DeveloperAccess
Testing AWS-Testers TesterAccess
Production AWS-Operators OperatorAccess
Management AWS-Finance FinanceReadOnlyAccess
All accounts AWS-SecurityAuditors SecurityAuditAccess
All accounts AWS-ReadOnly ReadOnlyAccess

Single AWS Account: Admin and Developer CLI Profiles

Use this setup when you have one AWS account and one workstation, but you want to clearly separate daily developer access from occasional administrator access.

Do not create extra AWS accounts just to separate admin and developer work. Use one IAM Identity Center user, two groups, two permission sets, and two AWS CLI profiles.

you@example.com
├── AWS-Developers -> DeveloperAccess -> same AWS account -> CLI profile: dev
└── AWS-Admins     -> AdminAccess     -> same AWS account -> CLI profile: admin
Purpose Identity Center Group Permission Set AWS CLI Profile Daily Use
Normal development AWS-Developers DeveloperAccess dev Yes
Account administration AWS-Admins AdminAccess admin Only when needed

This gives one person two clearly named access paths without storing long-term IAM access keys on the machine.

Step 1: Enable IAM Identity Center

  1. Open the AWS Console as the account owner or an existing administrator.
  2. Search for IAM Identity Center.
  3. Enable IAM Identity Center.
  4. If AWS asks for an instance type, choose the organization instance for account access.
  5. Use the built-in Identity Center directory unless you already have another identity provider.

For a single AWS account, the organization can still contain only that one account. You do not need to create separate member accounts for this admin/developer split.

IAM Identity Center and AWS Organizations do not add a separate service charge, but normal AWS resource usage is still billed. If the account is still using free tier credits, review AWS free tier behavior before creating an organization.

Step 2: Create one user

Create one IAM Identity Center user for yourself.

Example:

you@example.com

This is different from an IAM user. IAM Identity Center users receive temporary credentials through SSO.

Step 3: Create two groups

AWS-Admins
AWS-Developers

Add the same user to both groups.

Step 4: Create two permission sets

Permission Set Attach Policy Suggested Session Duration
AdminAccess AdministratorAccess 1 hour
DeveloperAccess PowerUserAccess or custom developer policy 4 to 8 hours

Use AdminAccess only for account-level tasks such as IAM, billing setup, organization settings, and emergency fixes.

Use DeveloperAccess for normal application work such as S3, Lambda, ECS, ECR, DynamoDB, RDS, CloudWatch, and development deployments.

Step 5: Assign both groups to the same AWS account

In IAM Identity Center:

AWS account: your single AWS account
Group: AWS-Admins
Permission set: AdminAccess

AWS account: your single AWS account
Group: AWS-Developers
Permission set: DeveloperAccess

After assignment, the AWS access portal should show the same AWS account with two available roles.

Step 6: Find the SSO start URL

The SSO start URL is the AWS access portal URL.

Find it here:

IAM Identity Center -> Settings -> AWS access portal URL

It usually looks like:

https://d-xxxxxxxxxx.awsapps.com/start

Step 7: Configure the developer CLI profile

Run:

aws configure sso

Example answers:

SSO session name: my-aws
SSO start URL: https://d-xxxxxxxxxx.awsapps.com/start
SSO region: ap-northeast-2
SSO registration scopes: sso:account:access
CLI default client Region: ap-northeast-2
CLI default output format: json
CLI profile name: dev

When the browser opens, sign in. Then choose:

AWS account: your single AWS account
Role / permission set: DeveloperAccess

Step 8: Configure the admin CLI profile

Run the wizard again:

aws configure sso

Use the same SSO start URL and SSO region, but choose the admin role and profile name:

SSO session name: my-aws
SSO start URL: https://d-xxxxxxxxxx.awsapps.com/start
SSO region: ap-northeast-2
SSO registration scopes: sso:account:access
CLI default client Region: ap-northeast-2
CLI default output format: json
CLI profile name: admin

When prompted for the account and role:

AWS account: your single AWS account
Role / permission set: AdminAccess

Step 9: Verify both profiles

Login and verify the developer profile:

aws sso login --profile dev
aws sts get-caller-identity --profile dev

Login and verify the admin profile:

aws sso login --profile admin
aws sts get-caller-identity --profile admin

The account ID can be the same for both profiles. The role name should be different.

Daily usage pattern

Make developer access the default for normal shells:

export AWS_PROFILE=dev
aws sts get-caller-identity

Run admin commands only with an explicit profile:

aws iam list-users --profile admin

Optional shell aliases:

alias aws-dev='AWS_PROFILE=dev aws'
alias aws-admin='AWS_PROFILE=admin aws'

Expected AWS CLI config

The AWS CLI stores SSO profile settings in:

~/.aws/config

Example:

[sso-session my-aws]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = ap-northeast-2
sso_registration_scopes = sso:account:access

[profile dev]
sso_session = my-aws
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
region = ap-northeast-2
output = json

[profile admin]
sso_session = my-aws
sso_account_id = 123456789012
sso_role_name = AdminAccess
region = ap-northeast-2
output = json

Safety rules for this setup

Sandbox Development and Test Account Setup

Use this setup when you want a safe place to build and test AWS services before anything becomes production-like.

The best practice is to use a separate AWS account for sandbox and early testing.

Management account
└── Sandbox account
    ├── SandboxDeveloperAccess -> profile: sandbox-dev
    ├── SandboxTesterAccess    -> profile: sandbox-test
    └── AdminAccess            -> profile: sandbox-admin

This keeps experimental resources, service quotas, logs, and mistakes away from production and billing administration.

If you currently have only one AWS account, you can still use IAM Identity Center profiles to separate behavior, but the isolation is weaker. In that case, use strict naming, tags, budgets, and cleanup rules.

Suggested accounts

For one person or a small team:

AWS Account Purpose Who Uses It
Management IAM Identity Center, billing, organization administration Admin only
Sandbox Development experiments and test deployments Developers and testers

For a larger setup:

AWS Account Purpose
Management IAM Identity Center, billing, organization administration
Sandbox Temporary experiments and learning
Development Active app development
Testing QA and integration tests
Production Real users and real data

Do not promote a sandbox account into production. Treat sandbox resources as temporary.

Suggested IAM Identity Center groups

AWS-Admins
AWS-SandboxDevelopers
AWS-SandboxTesters
AWS-SandboxReadOnly

For a one-person setup, your IAM Identity Center user can belong to both AWS-Admins and AWS-SandboxDevelopers.

Suggested permission sets

Permission Set Attach Policy Account Assignment Purpose
AdminAccess AdministratorAccess Management and Sandbox Account setup and emergency changes
SandboxDeveloperAccess PowerUserAccess or custom developer policy Sandbox only Build and modify sandbox resources
SandboxTesterAccess Custom tester policy or ReadOnlyAccess plus test actions Sandbox only Run tests and inspect resources
SandboxReadOnlyAccess ReadOnlyAccess Sandbox only Inspect resources without changing them

Avoid giving sandbox developers billing, organization, account-closure, or unrestricted IAM administration permissions.

Account assignments

In IAM Identity Center, assign groups to the sandbox account like this:

AWS account: Sandbox
Group: AWS-SandboxDevelopers
Permission set: SandboxDeveloperAccess

AWS account: Sandbox
Group: AWS-SandboxTesters
Permission set: SandboxTesterAccess

AWS account: Sandbox
Group: AWS-Admins
Permission set: AdminAccess

Keep management account access narrow:

AWS account: Management
Group: AWS-Admins
Permission set: AdminAccess

Developers should not need normal access to the management account.

CLI profiles

Configure one profile per sandbox role:

aws configure sso

Suggested profile names:

sandbox-dev
sandbox-test
sandbox-admin

Use the sandbox developer profile for daily development:

aws sso login --profile sandbox-dev
aws sts get-caller-identity --profile sandbox-dev

Use the sandbox tester profile for test verification:

aws sso login --profile sandbox-test
aws sts get-caller-identity --profile sandbox-test

Use admin only for account setup:

aws sts get-caller-identity --profile sandbox-admin

Sandbox resource rules

Use consistent names and tags so resources are easy to find and delete.

Recommended tags:

Environment = Sandbox
Owner       = your-email@example.com
Project     = project-name
ExpiresOn   = YYYY-MM-DD
ManagedBy   = Manual or Terraform

Recommended naming:

sandbox-project-service
sandbox-project-bucket-name
sandbox-project-lambda-name
sandbox-project-db

For Route 53, avoid using the production hosted zone directly from sandbox work. Prefer a delegated subdomain:

sandbox.example.com
dev.example.com
test.example.com

For data, do not copy production secrets, customer data, payment data, or private production backups into sandbox.

Sandbox cost controls

Set cost controls before giving broad sandbox access.

Minimum controls:

If using AWS Organizations, consider service control policies for sandbox accounts to restrict expensive or risky services and Regions.

One-account fallback

If you are not ready to create a separate sandbox AWS account, use one AWS account with stronger discipline:

Profile: admin        -> AdminAccess
Profile: sandbox-dev  -> SandboxDeveloperAccess
Profile: sandbox-test -> SandboxTesterAccess

Use tags and resource prefixes to separate sandbox resources:

Environment = Sandbox
Name starts with sandbox-

This is acceptable for learning and early experiments, but move to a separate sandbox account before storing important data or running production-like services.

Method B: IAM User Fallback Setup

Use this only when IAM Identity Center is not available or your setup is very small.

IAM User Fallback Flow

flowchart TD
    A[Create IAM User] --> B[Create IAM Group]
    B --> C[Attach Managed or Custom Policy]
    C --> D[Add User to Group]
    D --> E[Enable MFA]
    E --> F[Test Console/CLI Access]

Suggested IAM groups

Admins
Developers
Testers
Operators
Finance
SecurityAuditors
ReadOnlyUsers

Important

Avoid attaching policies directly to users.

Prefer:

User → Group → Policy

instead of:

User → Policy

Admin Account Setup

Administrators can manage almost everything in the AWS account.

AdministratorAccess

Use admin access for

Do not use admin access for

IAM Identity Center setup

Group: AWS-Admins
Permission set: AdminAccess
AWS managed policy: AdministratorAccess

IAM fallback setup

aws iam create-group --group-name Admins

aws iam attach-group-policy \
  --group-name Admins \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

aws iam add-user-to-group \
  --user-name admin-john \
  --group-name Admins

Admin access diagram

flowchart LR
    AdminUser[Admin User] --> AdminGroup[AWS-Admins Group]
    AdminGroup --> AdminPS[AdminAccess Permission Set]
    AdminPS --> AdminPolicy[AdministratorAccess]
    AdminPolicy --> AWS[AWS Account]

Developer Account Setup

Developers usually need to create, update, and debug application resources, but they should not manage IAM or billing by default.

Start with:

PowerUserAccess

Then reduce to custom least-privilege policies later.

Developer can usually access

Developer should usually not access

IAM Identity Center setup

Group: AWS-Developers
Permission set: DeveloperAccess
AWS managed policy: PowerUserAccess

Developer flow

flowchart TD
    Dev[Developer] --> DevGroup[AWS-Developers]
    DevGroup --> DevPS[DeveloperAccess]
    DevPS --> PowerUser[PowerUserAccess]
    PowerUser --> DevAccount[Development AWS Account]
    DevPS -. limited assignment .-> ProdAccount[Production AWS Account]

IAM fallback setup

aws iam create-group --group-name Developers

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/PowerUserAccess

aws iam add-user-to-group \
  --user-name dev-john \
  --group-name Developers

If this developer only needs AWS CLI access, do not create a console password. The admin still needs to create an access key for the user, because PowerUserAccess does not allow the developer to manage IAM access keys by default.

Tester / QA Account Setup

Testers usually need to inspect application behavior, run test environments, view logs, and possibly trigger test deployments.

Use a custom QA policy.

For small teams, you can start with limited access to the testing account only.

Tester can usually access

Tester should usually not access

IAM Identity Center setup

Group: AWS-Testers
Permission set: TesterAccess
Policy: Custom tester policy
Account assignment: Testing account

Tester flow

flowchart TD
    Tester[Tester / QA] --> TestGroup[AWS-Testers]
    TestGroup --> TestPS[TesterAccess]
    TestPS --> TestAccount[Testing AWS Account]
    TestPS --> Logs[CloudWatch Logs]
    TestPS --> TestDeploy[Trigger Test Jobs]
    TestPS -. no access .-> Billing[Billing]
    TestPS -. no access .-> IAM[IAM Management]

Example tester policy concept

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ViewLogsAndMetrics",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:Get*",
        "cloudwatch:List*",
        "logs:Get*",
        "logs:Describe*",
        "logs:FilterLogEvents"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ReadApplicationResources",
      "Effect": "Allow",
      "Action": [
        "lambda:Get*",
        "lambda:List*",
        "apigateway:GET",
        "s3:GetObject",
        "s3:ListBucket",
        "dynamodb:Describe*",
        "dynamodb:List*",
        "rds:Describe*"
      ],
      "Resource": "*"
    }
  ]
}

Operator / DevOps Account Setup

Operators manage running systems. They may need production access, but it should be controlled.

Use a custom operations policy.

Operator can usually access

Operator should usually not access

IAM Identity Center setup

Group: AWS-Operators
Permission set: OperatorAccess
Policy: Custom operator policy
Account assignment: Production and staging accounts

Operator flow

flowchart TD
    Operator[Operator / DevOps] --> OpsGroup[AWS-Operators]
    OpsGroup --> OpsPS[OperatorAccess]
    OpsPS --> Prod[Production Account]
    OpsPS --> CW[CloudWatch]
    OpsPS --> ECS[ECS Operations]
    OpsPS --> EC2[EC2 Start/Stop/Reboot]
    OpsPS --> SSM[SSM Session Manager]
    OpsPS -. no billing .-> Billing[Billing]

Example operator policy concept

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Observe",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:*",
        "logs:*",
        "xray:Get*",
        "xray:BatchGet*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "OperateEC2",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "OperateECS",
      "Effect": "Allow",
      "Action": [
        "ecs:Describe*",
        "ecs:List*",
        "ecs:UpdateService"
      ],
      "Resource": "*"
    }
  ]
}

Finance / Billing Account Setup

Finance users need cost and billing visibility, not infrastructure administration.

For read-only billing:

AWSBillingReadOnlyAccess

For broader billing and cost management:

Billing

Finance can usually access

Finance should usually not access

Important billing requirement

Billing access requires a root-level setting:

Activate IAM access to Billing

Without this, IAM users and roles may not see billing information even with policies attached.

Finance flow

flowchart TD
    Root[Root User] --> BillingToggle[Activate IAM Access to Billing]
    Finance[Finance User] --> FinanceGroup[AWS-Finance]
    FinanceGroup --> FinancePS[Finance Permission Set]
    FinancePS --> BillingPolicy[AWSBillingReadOnlyAccess or Billing]
    BillingToggle --> BillingConsole[Billing Console]
    BillingPolicy --> BillingConsole

IAM Identity Center setup

Group: AWS-Finance
Permission set: FinanceReadOnlyAccess
AWS managed policy: AWSBillingReadOnlyAccess

or:

Group: AWS-FinanceManagers
Permission set: FinanceFullAccess
AWS managed policy: Billing

Security Auditor Account Setup

Security auditors need to inspect configuration, risks, and compliance posture.

SecurityAudit
ReadOnlyAccess

Security auditor can usually access

Security auditor should usually not access

Security auditor flow

flowchart TD
    Auditor[Security Auditor] --> AuditGroup[AWS-SecurityAuditors]
    AuditGroup --> AuditPS[SecurityAuditAccess]
    AuditPS --> SecAudit[SecurityAudit]
    AuditPS --> ReadOnly[ReadOnlyAccess]
    SecAudit --> Accounts[All AWS Accounts]
    ReadOnly --> Accounts

Read-Only Account Setup

Read-only users can inspect AWS resources but cannot modify them.

ReadOnlyAccess

Read-only users can usually access

Read-only users should not access

IAM Identity Center setup

Group: AWS-ReadOnly
Permission set: ReadOnlyAccess
AWS managed policy: ReadOnlyAccess

Read-only flow

flowchart LR
    User[Read-Only User] --> Group[AWS-ReadOnly]
    Group --> PS[ReadOnlyAccess Permission Set]
    PS --> Policy[ReadOnlyAccess]
    Policy --> Account[AWS Account]

CI/CD and Automation Access

Do not create normal human user accounts for CI/CD when possible.

Prefer IAM roles.

Good model

GitHub Actions / GitLab CI / Jenkins
→ Assume IAM role
→ Temporary credentials
→ Deploy only required resources

Bad model

CI/CD server
→ Long-term IAM user access key
→ AdministratorAccess

CI/CD access flow

sequenceDiagram
    participant CI as CI/CD System
    participant OIDC as OIDC Provider
    participant STS as AWS STS
    participant Role as IAM Deploy Role
    participant AWS as AWS Account

    CI->>OIDC: Request identity token
    CI->>STS: Assume role with web identity
    STS->>Role: Validate trust policy
    Role->>CI: Temporary credentials
    CI->>AWS: Deploy with limited permissions

CI/CD role recommendations

Pipeline Suggested Permission
Frontend deploy to S3/CloudFront S3 write to one bucket + CloudFront invalidation
Lambda deploy Lambda update + IAM PassRole for specific execution role
ECS deploy ECS update service + ECR push + limited IAM PassRole
Terraform plan Read-only + state access
Terraform apply Scoped infrastructure permissions, preferably per environment

Environment-Based Access Design

For better security, separate environments.

flowchart TD
    Org[AWS Organization] --> Mgmt[Management Account]
    Org --> Sandbox[Sandbox Account]
    Org --> Dev[Development Account]
    Org --> Test[Testing Account]
    Org --> Stage[Staging Account]
    Org --> Prod[Production Account]
    Org --> Security[Security Account]
    Org --> Logs[Logging Account]

    Admins[AWS-Admins] --> Mgmt
    Admins --> Sandbox
    SandboxDevelopers[AWS-SandboxDevelopers] --> Sandbox
    SandboxTesters[AWS-SandboxTesters] --> Sandbox
    Developers[AWS-Developers] --> Dev
    Testers[AWS-Testers] --> Test
    Operators[AWS-Operators] --> Stage
    Operators --> Prod
    Auditors[AWS-SecurityAuditors] --> Dev
    Auditors --> Test
    Auditors --> Stage
    Auditors --> Prod
    Auditors --> Security
    Finance[AWS-Finance] --> Mgmt

Example access design

Environment Admin Developer Tester Operator Auditor Finance
Management Yes No No No Read-only Billing
Sandbox Yes Broad sandbox access Test access No Read-only No
Development Yes Power user Limited Limited Read-only No
Testing Yes Limited Test access Limited Read-only No
Staging Yes Limited Limited Operator Read-only No
Production Yes Usually no Usually no Operator Read-only No
Security Security admin No No No Read-only No

Billing Visibility Setup

Even full administrators can get confused here.

Important rule

To allow IAM users and roles to access Billing pages, the root user must activate IAM access to Billing.

Steps

  1. Sign in as the AWS account root user.
  2. Open the AWS Console.
  3. Click the account name in the top-right.
  4. Choose Account.
  5. Find:
IAM User and Role Access to Billing Information
  1. Choose Edit.
  2. Select:
Activate IAM Access
  1. Save/update.

Billing access decision tree

flowchart TD
    A[User cannot see Billing] --> B{Root activated IAM access to Billing?}

    B -->|No| C[Root user opens Account page]
    C --> D[Activate IAM Access]
    D --> E[Try again]

    B -->|Yes| F{User has billing policy?}
    F -->|No| G[Attach AWSBillingReadOnlyAccess or Billing]
    F -->|Yes| H[Check Organizations management account/member account behavior]

    G --> E
    H --> I[Billing should be visible if account and policy are correct]

MFA and Password Policy

Minimum MFA requirements

Enable MFA for:

Root user
Admins
Developers
Operators
Finance users
Security auditors
CI/CD admin maintainers

MFA flow

flowchart TD
    User[User Created] --> Password[Set Temporary Password or Invitation]
    Password --> FirstLogin[User First Login]
    FirstLogin --> MFA[Enroll MFA]
    MFA --> Access[Allow Normal AWS Access]

Password policy

Recommended:

CLI Access Setup

IAM Identity Center CLI

Recommended for humans, especially when one machine needs separate admin and developer profiles.

For a single AWS account, configure two profiles:

dev    -> DeveloperAccess permission set
admin  -> AdminAccess permission set

aws configure sso

Use the AWS access portal URL as the SSO start URL:

https://d-xxxxxxxxxx.awsapps.com/start

Find it here:

IAM Identity Center -> Settings -> AWS access portal URL

Run the wizard once for dev and once for admin.

Login:

aws sso login --profile dev
aws sso login --profile admin

Verify:

aws sts get-caller-identity --profile dev
aws sts get-caller-identity --profile admin

Use dev by default:

export AWS_PROFILE=dev

IAM user CLI fallback

Only create access keys when necessary.

An IAM user does not need a console password to use the AWS CLI.

Console password  -> AWS Management Console sign-in
Access key pair   -> AWS CLI, SDK, and API access

Use this model when a developer user already exists in IAM, is added to the correct group, and should only use command-line access.

Admin creates the developer IAM user

If the user does not already exist:

aws iam create-user --user-name dev-john

aws iam add-user-to-group \
  --user-name dev-john \
  --group-name Developers

Do not run aws iam create-login-profile if the user should not have an AWS Console password.

Admin creates an access key

Create an access key from an admin profile:

aws iam create-access-key \
  --user-name dev-john \
  --profile admin

The output contains:

AccessKeyId
SecretAccessKey

The SecretAccessKey is shown only once. Store it securely and give it to the developer through a secure channel.

Developer configures AWS CLI

On the developer machine:

aws configure --profile dev-john

Enter:

AWS Access Key ID
AWS Secret Access Key
Default region name
Default output format

Verify:

aws sts get-caller-identity --profile dev-john

Use the profile in CLI commands:

aws s3 ls --profile dev-john

Or set it for the current terminal session:

export AWS_PROFILE=dev-john
aws sts get-caller-identity

Local credential files

The AWS CLI stores the named profile in:

~/.aws/credentials
~/.aws/config

Example:

# ~/.aws/credentials
[dev-john]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

# ~/.aws/config
[profile dev-john]
region = ap-northeast-2
output = json

Do not commit these files or paste access keys into Git, tickets, chat, or documentation.

Rotate or remove the access key

List keys:

aws iam list-access-keys \
  --user-name dev-john \
  --profile admin

Deactivate a key:

aws iam update-access-key \
  --user-name dev-john \
  --access-key-id ACCESS_KEY_ID \
  --status Inactive \
  --profile admin

Delete a key after confirming it is no longer used:

aws iam delete-access-key \
  --user-name dev-john \
  --access-key-id ACCESS_KEY_ID \
  --profile admin

Avoid

Root access keys
Shared access keys
Long-term admin access keys
Access keys committed to Git

Custom Policy Examples

Example: S3-only developer

This allows a developer to work with one specific S3 bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::my-development-bucket"
    },
    {
      "Sid": "ObjectAccessInSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-development-bucket/*"
    }
  ]
}

Example: Lambda developer

This allows updating Lambda functions and reading logs.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LambdaDevelopment",
      "Effect": "Allow",
      "Action": [
        "lambda:Get*",
        "lambda:List*",
        "lambda:UpdateFunctionCode",
        "lambda:UpdateFunctionConfiguration",
        "lambda:InvokeFunction"
      ],
      "Resource": "arn:aws:lambda:ap-northeast-2:123456789012:function:dev-*"
    },
    {
      "Sid": "ReadLambdaLogs",
      "Effect": "Allow",
      "Action": [
        "logs:Get*",
        "logs:Describe*",
        "logs:FilterLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

Example: Operator EC2 start/stop only

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeEC2",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "StartStopRebootTaggedInstances",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Environment": "production"
        }
      }
    }
  ]
}

Example: Billing read-only

For most finance users, prefer the AWS managed policy:

AWSBillingReadOnlyAccess

You can also create custom billing policies, but billing permissions change over time, so use AWS managed policies where possible.

Verification Checklist

For every user

Admin

Sandbox

Developer

Tester

Operator

Finance

Security auditor

Troubleshooting

User cannot see Billing

Check:

  1. Was IAM access to Billing activated by root?
  2. Is the user assigned a billing policy?
  3. Is the user in the management account or a member account?
  4. Has the user signed out and signed in again?

User has PowerUserAccess but cannot manage IAM

That is expected.

PowerUserAccess gives broad access to AWS services and resources, but it does not allow management of IAM users and groups.

Use admin access only for trusted administrators.

User cannot see the expected AWS account in IAM Identity Center

Check:

  1. User is in the correct group.
  2. Group is assigned to the AWS account.
  3. Permission set is provisioned.
  4. User is logging in through the correct AWS access portal.
  5. The correct IAM Identity Center region is being used.

CLI access does not work

Run:

aws sts get-caller-identity --profile your-profile

For IAM Identity Center:

aws sso login --profile your-profile

Check:

User can do too much

Fix:

  1. Remove broad managed policies.
  2. Create custom least-privilege policies.
  3. Assign access by environment.
  4. Use resource tags and conditions.
  5. Review access with IAM Access Analyzer and last accessed data.

Best Practices

1. Use IAM Identity Center for humans

For people, use IAM Identity Center whenever possible.

User → Group → Permission Set → AWS Account

2. Use IAM roles for machines

For CI/CD, apps, and automation, use IAM roles.

Workload → Assume role → Temporary credentials

3. Use groups

Do not assign access one user at a time.

Good:

Alice → AWS-Developers → DeveloperAccess
Bob → AWS-Developers → DeveloperAccess

Bad:

Alice → custom permissions
Bob → different custom permissions
Charlie → direct policy attachment

4. Use least privilege

Start with AWS managed policies when learning, but reduce permissions over time.

Example evolution:

flowchart LR
    Broad[Start: AWS Managed Policy] --> Observe[Observe Actual Usage]
    Observe --> Reduce[Create Customer Managed Policy]
    Reduce --> Review[Review Last Accessed Data]
    Review --> Least[Least Privilege]

5. Separate environments

Avoid giving every developer production access.

Recommended:

Sandbox: broad but temporary developer/test access
Development: broad developer access
Testing: tester and developer access
Staging: operator and limited developer access
Production: operator/admin access only

6. Protect the root user

Root user should be used rarely.

Use root only for:

7. Avoid shared accounts

Do not create accounts like:

developer1
team-admin
shared-prod

Use individual named identities.

Good:

john@example.com
sarah@example.com
minji@example.com

8. Audit regularly

Review:

Recommended Starting Setup

For a small team, start with this:

flowchart TD
    IC[IAM Identity Center] --> Admins[AWS-Admins]
    IC --> SandboxDevs[AWS-SandboxDevelopers]
    IC --> SandboxTesters[AWS-SandboxTesters]
    IC --> Devs[AWS-Developers]
    IC --> Testers[AWS-Testers]
    IC --> Ops[AWS-Operators]
    IC --> Finance[AWS-Finance]
    IC --> Auditors[AWS-SecurityAuditors]
    IC --> ReadOnly[AWS-ReadOnly]

    Admins --> AdminPS[AdministratorAccess]
    SandboxDevs --> SandboxDevPS[PowerUserAccess on Sandbox]
    SandboxTesters --> SandboxTestPS[Custom tester access on Sandbox]
    Devs --> DevPS[PowerUserAccess on Dev]
    Testers --> TestPS[Custom QA on Test]
    Ops --> OpsPS[Custom Ops on Stage/Prod]
    Finance --> FinancePS[AWSBillingReadOnlyAccess]
    Auditors --> AuditPS[SecurityAudit + ReadOnlyAccess]
    ReadOnly --> ReadOnlyPS[ReadOnlyAccess]

Minimum groups

AWS-Admins
AWS-SandboxDevelopers
AWS-Developers
AWS-ReadOnly
AWS-Finance

Better groups

AWS-Admins
AWS-SandboxDevelopers
AWS-SandboxTesters
AWS-Developers
AWS-Testers
AWS-Operators
AWS-Finance
AWS-SecurityAuditors
AWS-ReadOnly
AWS-EmergencyAdmins

Quick Setup Summary

Admin

Group: AWS-Admins
Permission: AdministratorAccess
MFA: Required
Billing: Optional

Sandbox Developer

Group: AWS-SandboxDevelopers
Permission: SandboxDeveloperAccess
Account: Sandbox only
MFA: Required
Billing: No
Production: No

Sandbox Tester

Group: AWS-SandboxTesters
Permission: SandboxTesterAccess
Account: Sandbox only
MFA: Required
Billing: No
Production: No

Developer

Group: AWS-Developers
Permission: PowerUserAccess or custom
MFA: Required
Billing: No
Production: Usually no

Tester

Group: AWS-Testers
Permission: Custom QA policy
MFA: Required
Billing: No
Production: No

Operator

Group: AWS-Operators
Permission: Custom operations policy
MFA: Required
Billing: No
Production: Limited yes

Finance

Group: AWS-Finance
Permission: AWSBillingReadOnlyAccess or Billing
MFA: Required
Billing: Yes
Infrastructure: No

Security Auditor

Group: AWS-SecurityAuditors
Permission: SecurityAudit + ReadOnlyAccess
MFA: Required
Billing: No
Write access: No

CI/CD

Identity type: IAM Role
Permission: Custom deployment policy
Credential type: Temporary
AdministratorAccess: Avoid

Reference Links

Official AWS documentation:

Final Recommendation

Use this default structure:

IAM Identity Center
├── AWS-Admins              → AdministratorAccess
├── AWS-SandboxDevelopers   → SandboxDeveloperAccess on sandbox only
├── AWS-SandboxTesters      → SandboxTesterAccess on sandbox only
├── AWS-Developers          → PowerUserAccess on dev/test only
├── AWS-Testers             → Custom QA policy
├── AWS-Operators           → Custom production operations policy
├── AWS-Finance             → AWSBillingReadOnlyAccess or Billing
├── AWS-SecurityAuditors    → SecurityAudit + ReadOnlyAccess
├── AWS-ReadOnly            → ReadOnlyAccess
└── CI/CD                   → IAM roles, not human users

This gives you a clean, scalable, and safer AWS access model.