AWS IAM In-Service Workflows — Inline Role Creation Explained (2026 Launch)

On March 5, 2026, AWS shipped a small but long-overdue feature — IAM in-service workflows. You can now create and scope an IAM role directly inside the service console you are setting up (Lambda, EC2, Glue, ECS, and more) without opening a second browser tab to the IAM console. This post walks through what actually changed, the new simplified statement builder, how it interacts with your Terraform code, and the one gotcha that can silently widen your blast radius.

For the deeper IAM security fundamentals that still apply — least privilege, permission boundaries, MFA, and role trust policies — see AWS IAM Best Practices — 12 Production-Tested Security Rules.

The Problem This Solves

If you have set up any AWS service that needs to call another AWS service — Lambda reading from S3, ECS pulling a secret, Glue crawling an S3 bucket — you have done this dance:

1. Open the service console (say, Lambda)
2. Reach the "Execution role" field and realize you need a role
3. Open a second tab to the IAM console
4. Create a role, attach policies, copy the ARN
5. Switch back to the Lambda tab, paste the ARN
6. Realize you picked the wrong trust relationship, fix it, repeat

This dance takes five to ten minutes per role, breaks flow, and encourages bad habits — the path of least resistance is to reach for AdministratorAccess or AmazonS3FullAccess just to keep the build moving.

What In-Service Workflows Actually Do

When you are setting up a service that needs an IAM role, a new panel now appears inline — inside the same console, same tab. The panel lets you:

• Pick from default policies scoped to what this service typically needs (e.g., AWSLambdaBasicExecutionRole for Lambda, AmazonECSTaskExecutionRolePolicy for ECS).
• Use the new simplified statement builder to write a custom policy without touching JSON.
• Combine both — start with a default, add a custom statement for your specific bucket or secret.

The role is created, the trust relationship is set correctly for the calling service, and you are returned to the original workflow. No tab switching, no copy-paste of ARNs.

Old Flow vs New Flow

flowchart LR
  subgraph OLD["OLD: Context switch"]
    direction TB
    A1[Open Lambda console]:::old --> A2[Need a role]:::old
    A2 --> A3[Switch to IAM tab]:::old
    A3 --> A4[Create role + policy]:::old
    A4 --> A5[Copy ARN]:::old
    A5 --> A6[Switch back to Lambda]:::old
    A6 --> A7[Paste + pray]:::old
  end
  subgraph NEW["NEW: Inline"]
    direction TB
    B1[Open Lambda console]:::new --> B2[Inline role panel]:::new
    B2 --> B3[Pick policy / builder]:::new
    B3 --> B4[Done — role created]:::new
  end
  classDef old fill:#4A1DB5,stroke:#6C3CE1,color:#fff
  classDef new fill:#00B893,stroke:#00D4AA,color:#0F0F1A
              

The Simplified Statement Builder

The statement builder is the interesting part. Instead of writing JSON like this:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": [
      "arn:aws:s3:::my-data-lake",
      "arn:aws:s3:::my-data-lake/raw/*"
    ]
  }]
}

You pick from three dropdowns:

1. Service → S3
2. Actions → GetObject, ListBucket (multi-select)
3. Resource → paste an ARN or pick the bucket from a searchable list, then optionally scope to a prefix

The builder emits the JSON for you and validates the ARN format. Small thing, but it removes a common source of "Access Denied but IAM says allowed" bugs — most of which come from malformed resource ARNs or wildcard mistakes.

In-Service Workflows vs Full IAM Console vs IaC

Use the right tool for the right job. Here is when to reach for each:

Does This Replace Terraform? No.

The launch is a console feature. Nothing changed about the IAM API, Terraform's aws_iam_role resource, CloudFormation's AWS::IAM::Role, or CDK's iam.Role construct. Roles created by in-service workflows are normal IAM roles — you can import them into Terraform state if you want to manage them in code later.

The One Real Risk: Default Policies Are Broad

The one place this feature can bite you is the default-policy dropdown. AWS managed default policies are convenient — but they are almost always broader than what you actually need.

What to do instead:

• Prefer the simplified statement builder over the default-policy dropdown for anything beyond service execution basics.
• Run IAM Access Analyzer on any new role before promoting it to prod. Access Analyzer will flag roles that are broader than their actual usage over a 90-day window.
• Add a permission boundary at the OU or account level so nothing created through in-service workflows can exceed the boundary — regardless of what default was picked.

Where This Shows Up Today

As of the launch, in-service workflows are available in the consoles for the services most commonly needing role setup:

• Lambda (execution roles)
• EC2 (instance profiles)
• ECS / Fargate (task execution and task roles)
• Glue (crawlers and jobs)
• SageMaker (notebook and training roles)
• EventBridge (targets that need IAM)
• Step Functions (state machine roles)

AWS has indicated more services will roll out through the year. If you use a service that hasn't been updated yet, the old flow still works.

What This Means for the IAM Interview Question

"Walk me through creating an IAM role for a Lambda" is a common DevOps interview question. The correct 2026 answer has shifted:

• Pre-2026 answer: "Open IAM, create role, select trusted entity = Lambda, attach AWSLambdaBasicExecutionRole, add custom policy for S3..."
• 2026 answer: "For a one-off: use the inline workflow in the Lambda console and the statement builder to scope the S3 access. For anything that will live past the prototype: write it in Terraform so it is code-reviewed, version-controlled, and reproducible across environments."

Interviewers are not looking for you to recite clicks. They want to hear that you know when console IAM is fine and when it is a smell.

Frequently Asked Questions

What are AWS IAM in-service workflows?

Inline IAM role creation inside other AWS service consoles. Instead of switching tabs to the IAM console, you scope permissions directly while setting up Lambda, EC2, ECS, Glue, and so on. Launched March 5, 2026.

Does this replace Terraform or CloudFormation for IAM?

No. It is a console-only workflow. The IAM API, Terraform providers, and CloudFormation resources are unchanged. Use the feature for prototypes, not for production IaC.

What is the simplified statement builder?

A dropdown-based UI that generates IAM policy JSON from service + actions + resource selections. Removes the need to hand-write JSON for common scopes. Useful but not a substitute for reviewed, version-controlled policies.

Can in-service workflows create overly permissive roles by accident?

Yes — if you pick broad default policies without reviewing them. Mitigate with IAM Access Analyzer and permission boundaries at the account or OU level.

Which AWS services support in-service IAM workflows?

At launch: Lambda, EC2, ECS / Fargate, Glue, SageMaker, EventBridge, and Step Functions. AWS is rolling the experience out to more services over time.

Related Reading

• AWS IAM Best Practices — 12 Production-Tested Security Rules
• CI/CD for AWS with GitHub Actions — OIDC, No Access Keys
• 10 DevOps Incident Scenarios — Senior vs Junior Answers
• Kubernetes RBAC — Roles, Bindings & Service Accounts
• Platform Engineering vs DevOps vs SRE — 2026 Career Guide