All Tools View Categories About Contact Privacy

Serverless Framework IAM Role Generator

Convert IAM policy JSON into a serverless.yml IAM role block — modern (v3+) or legacy syntax.

Generates a starting-point YAML block to merge into your serverless.yml — review indentation and merge conflicts. Runs entirely in your browser.

Pick which Serverless Framework syntax to view after generating — both are computed from the same policy, so you can flip between them freely.


  

About Serverless Framework IAM Role Generator

Serverless Framework IAM Role Generator converts a pasted IAM policy JSON document into the IAM role block for your serverless.yml, in both syntaxes real projects actually use today: the modern provider.iam.role.statements syntax introduced in Serverless Framework v3, and the legacy provider.iamRoleStatements syntax used by v1/v2 projects and still common in the wild. A tab switches between the two without re-entering anything, since both are generated from the same statements.

Each Statement in your policy becomes one YAML list item with Effect, Action (always rendered as a YAML list, even for a single action), and Resource (also always a YAML list) — matching how these blocks are conventionally written by hand. A Condition block, when present, is embedded inline as JSON, which YAML accepts directly and preserves exactly.

This is a starting-point block to merge into your existing serverless.yml, not a full file: check that indentation lines up with the rest of your file and that it merges cleanly with any provider.iam/iamRoleStatements content you already have.

Features

  • Modern syntaxprovider.iam.role.statements (Serverless Framework v3+).
  • Legacy syntaxprovider.iamRoleStatements (pre-v3), one tab away.
  • Action/Resource always rendered as YAML lists, matching hand-written convention.
  • Condition blocks preserved via inline JSON.
  • Works on any valid JSON, with a structural warning if it does not look like a complete IAM policy.
  • One-click copy of either syntax.
  • 100% client-side — nothing is uploaded.

How to Use

  1. Paste your policy JSON, or click the sample.
  2. Click Generate.
  3. Switch between the "Modern (v3+)" and "Legacy" tabs to see the syntax that matches your Serverless Framework version.
  4. Copy the YAML block and merge it into your serverless.yml.

Examples

Example. An S3 read-only Allow statement produces, in modern syntax: provider.iam.role.statements: - Effect: Allow Action: [s3:GetObject] Resource: [arn:aws:s3:::my-bucket/*]; the legacy tab shows the identical statement under provider.iamRoleStatements instead.

Benefits

  • Covers both syntaxes real projects use — no guessing which one your Serverless version expects.
  • Matches hand-written YAML conventions — lists, not inline arrays.
  • Preserves Condition blocks exactly.
  • Private — generation runs entirely in your browser.

Frequently Asked Questions

Which Serverless Framework syntax should I use — modern or legacy?
If you are on Serverless Framework v3 or later, use the modern <code>provider.iam.role.statements</code> syntax shown by default. If your project is still on Serverless Framework v1/v2, use the legacy <code>provider.iamRoleStatements</code> syntax instead — both are generated from the same pasted policy JSON so you can switch tabs without re-pasting anything.
Is this generated YAML block ready to paste into my serverless.yml as-is?
It is a reasonable starting point. The <code>Action</code>/<code>Resource</code> values are copied through exactly from your pasted policy JSON, but you should still confirm the indentation matches the rest of your existing <code>serverless.yml</code> (YAML is indentation-sensitive) and that it merges cleanly if you already have a <code>provider.iam</code> or <code>iamRoleStatements</code> block.
Does it handle Condition blocks?
Yes — when a statement has a <code>Condition</code>, it is embedded on its own <code>Condition:</code> line as inline JSON, which YAML accepts directly. This preserves the condition exactly without needing a separate JSON-to-YAML re-encoding step.
What about NotAction, NotResource, or Principal?
These are not rendered — <code>provider.iam.role.statements</code> and <code>iamRoleStatements</code> are for the deployment role's own identity-based permissions, which use <code>Action</code>/<code>Resource</code>, not resource-based fields like <code>Principal</code> or the negated forms. If your statement uses <code>NotAction</code>/<code>NotResource</code>, its <code>Action</code>/<code>Resource</code> output here will be empty or a wildcard placeholder — edit it by hand.
Does it validate that my JSON is a well-formed IAM policy first?
It only requires valid JSON to generate the YAML. If the parsed JSON does not look like a complete IAM policy it still converts, but shows a structural warning above the output.
Is my policy JSON uploaded anywhere?
No — parsing and YAML generation both run entirely in your browser.