Build on AWS Without Worrying About Permissions
The new AWS sign-up experience sets up AWS Organizations, IAM Identity Center, guardrail policies, and workload roles for you. I create a project, invite a teammate, let IAM Role Manager build a Lambda execution role, and connect a coding agent to AWS without an access key.
When you sign up for AWS, permissions normally come up almost immediately. Most of that setup happens in AWS Identity and Access Management (IAM) , and the first time you open it, it can feel intimidating. You want to give someone access to what you're building, and suddenly you're reading about users, groups, and federation. You want a second environment, so now you're thinking about account structure. Then you create a Lambda function and it asks you for an execution role before you've written a single line of code.
It can be a lot.
The new AWS sign-up experience handles most of that setup for you. You create a project, invite somebody, and start building right away. IAM is still there. You just don't have to design the whole identity and organization layer before you can try anything.
In this post I'll create a project, add a team member, walk through the guardrails AWS puts around each project, let IAM Role Manager build a Lambda execution role, and connect a coding agent to AWS with temporary credentials. Full disclosure, I'm a Developer Advocate at AWS. I'll point out the trade-offs as I hit them.
Let's jump in!
Prerequisites
- An AWS account created with Sign up for AWS (new). This should be out for everyone now. The sign-up comparison page explains the differences between the new and advanced options.
- The AWS CLI version 2.32.0 or later if you want to follow the local development section. That's the minimum version for
aws login. - An AI coding tool such as Kiro if you want to connect an agent.
One more thing to know up front. The new experience is aimed at people starting out and at non-regulated workloads. If you need HIPAA or FedRAMP, the full set of AWS services, or fine-grained roles for your users, AWS recommends the advanced sign-up instead.
Sign up for a free AWS account
If you don't have an account yet, head to the Sign up for AWS page . You can sign up with an email address or a login you already have, like Google, GitHub, Apple, or Amazon. Along the way AWS creates an AWS Builder ID for you, and it sets up your first project automatically.
You won't be charged unless you upgrade to the Paid Plan. AWS might ask for a payment method during sign-up and place a temporary $1 hold to verify the account. The Sign up for AWS (new) docs walk through each screen.
Once you're in the AWS Management Console, choose Manage projects to open AWS Settings.
Create a project
Everything starts in AWS Settings . Instead of opening AWS Organizations and designing an account structure, you create a project .
- Open AWS Settings and go to Projects.
- Choose Create project.
- Give it a name and choose Create.
And you're done. Each project you create contains its own AWS account. All the projects you own sit under the same AWS Organization , which AWS manages on your behalf. AWS also uses IAM Identity Center to manage how people sign in and reach those projects, so you don't configure Identity Center or build the access roles yourself.
Create another project later and it gets its own AWS account inside that same organization.
If Identity Center and Organizations are new to you, don't worry. You can focus on building for now. If you turn on advanced features later, that's when you'll start managing more of this yourself.
Invite a team member
Adding somebody takes about as long as creating the project.
- In AWS Settings, open Team.
- Choose Invite new team member.
- Enter their email address.
- Select the projects you want to share, then choose Send invitation.
You don't create an IAM user for them, send over a long-lived access key, or configure federation. They accept the invitation, sign in with an AWS Builder ID , and AWS handles the access. They have 14 days to accept, so give them a nudge if it lands in spam.
Know the trade-off before you invite anyone. A team member added to a project can work with all the AWS resources available in it. They can't touch billing or delete the project, but you can't give one person read-only access and another person full control. If you need different permission levels for different people, you'll need to activate advanced features and manage that access yourself. The team member docs list exactly what a team member can and can't do.
The guardrails
AWS also manages the baseline organization policies for your projects.
Service control policies (SCPs) limit what users in a project can do. Resource control policies (RCPs) limit how supported resources can be accessed. Neither one grants permissions on its own. They set the outer edge of what's allowed, and an explicit deny in either policy wins even when an IAM policy allows the action.
You can think of them as guardrails. They help prevent accidental changes, like deleting the AWS-managed roles that give your team access, and they block access from outside the project's boundaries. If you want to see the actual policy JSON, AWS publishes the managed SCPs and RCPs for projects . You can't edit them in the new experience. Writing your own requires advanced features.
Let IAM Role Manager create your roles
This is the part I like most. The new sign-up experience turns on IAM Role Manager by default.
Say you create an AWS Lambda function. Role Manager creates an execution role, builds its trust and permissions policies, and attaches it to the function automatically. You never leave the Lambda console to go build a role in IAM.
To try it yourself:
- Open the Lambda console and choose Create function.
- Give the function a name and pick a runtime. Leave the execution role on its default so Role Manager provides it.
- Choose Create function.
- Open Configuration, then Permissions, and choose the role name to see what Role Manager built.
Lambda can run code that calls just about any AWS service, and AWS can't predict which APIs your function will use. So the current Lambda role template starts broad. That means you don't have to work out every fine-grained permission before you start building.
Role Manager currently works in select service consoles. As of this writing, AWS lists AWS Backup, AWS CloudFormation, Amazon CloudWatch, Amazon EKS, AWS Elastic Beanstalk, Amazon EventBridge, AWS Lambda, Amazon RDS, Amazon SageMaker Unified Studio, AWS Secrets Manager, and AWS Step Functions, and says more are coming. In each of those you get a useful starting role for the supported workflow instead of building every IAM role from scratch.
A broad role is fine while you're prototyping. Once you know exactly what your application calls, refine it toward least privilege . Roles that Role Manager creates are regular IAM roles, so you can view, edit, or delete them like any other role. Each one also records the template it came from, and AWS CloudTrail logs the creation as an
AcquireRole event if you ever need to audit where a role came from.For a first project on AWS, I'd much rather start with a working role than a blank policy editor.
Connect your coding agent with temporary credentials
We've made local development easier too. Agent Toolkit for AWS connects your coding agent to the AWS MCP Server and adds curated skills plus a rules file tuned for the new experience.
- From the AWS Console home page, choose Connect your AI coding agent to AWS.
- Copy the setup prompt.
- Paste it into your coding tool and let it run.
The prompt walks the agent through the local AWS setup for you. The rules file also has a help level setting. On Low, the agent only flags security risks. Medium adds clarifying questions when it spots a potential issue, and High will suggest improvements or alternatives to your architecture. The connect an AI coding tool docs cover each level.
Once it's connected, the agent can use current AWS guidance and curated skills, including tested procedures for creating least-privilege IAM policies. That's handy when it's time to tighten up that broad Lambda role. I still review its work, of course. But it starts from guidance grounded in AWS best practices instead of whatever it picked up in training. The Agent Toolkit user guide has the full list of what gets installed.
The setup uses
aws login . You sign in through the browser, and the AWS CLI and SDKs get temporary credentials for up to 12 hours. That means no long-lived access key sitting on your laptop.When your session expires, log in again with the profile name you picked during setup:
1
aws login --profile YOUR_PROFILE_NAMEYour browser opens, you choose your project, and you're back in. AWS can keep renewing these credentials for 90 days before you have to grant access in the browser again. To check which project your terminal is pointed at:
1
aws sts get-caller-identity --profile YOUR_PROFILE_NAMEHeads up: Each project has its own credentials, so create one profile per project and pick the matching session when you log in. Your agent creates resources in whichever project that session belongs to.
Paid Plan and advanced features
Two more options live in AWS Settings, and they're easy to mix up.
You can add a payment method and upgrade to the Paid Plan . Separately, you can activate advanced features if you need more control over identity and governance, such as custom SCPs or different permission levels for team members. Those are separate choices. One doesn't require the other.
Activating advanced features can't be reversed. Make sure you need that control before you turn it on.
Cleanup
If you created a test Lambda function, delete it from the Lambda console by choosing Actions, then Delete. The execution role Role Manager created stays behind as a regular IAM role, so delete it in the IAM console too if you don't plan to reuse it.
When you're done working locally, sign out of your CLI session:
1
aws logout --profile YOUR_PROFILE_NAMEWrapping up
With the new sign-up experience, you get to IAM once your app actually needs it, instead of before you've built anything. AWS manages the organization around your projects along with its baseline policies. Role Manager gives supported services a working role, and
aws login keeps access keys off your machine. Least privilege is still your job as the app grows, and advanced features are there when you want full control.So create your first project and let me know in the comments how it goes. Until next time.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article