What’s New in AWS Sign-In Experience? A Builder’s Perspective!

As an AWS Community Builder, I spend a lot of time exploring AWS services, building hands-on projects, and sharing what I learn with the community.

AWS has started rolling out a new sign-in experience, beginning September 16, 2026. As an AWS Community Builder, I had the opportunity to try out this new experience firsthand.

In this article, I’ll take a quick look at what’s new, the different sign-in options, AWS Projects, and how this experience can help individual builders accelerate their AWS learning.

A New Way to Sign In

The first thing you'll notice is that the AWS sign-in experience looks different.

The new experience is designed to make it easier for builders to get started with AWS. Instead of requiring you to make a lot of configuration decisions before you can start building, AWS provides a more streamlined experience with preconfigured defaults.

You can sign up using a login you already have, including:

• Google
• GitHub
• Apple
• Amazon

AWS then creates a preconfigured environment where your AWS resources are organized into Projects.

This immediately made me curious about how this differs from the traditional AWS sign-in experience.

Which Sign-In Option Is Right for You?

One of the first questions I had when I saw the new experience was:

How is signing in with Google, GitHub, Apple, or Amazon different from using an IAM user?

The important thing to understand is that these are different approaches to identity and AWS access.

Google, GitHub, Apple, or Amazon

With the new AWS experience, individual builders can use an existing identity from supported providers such as Google, GitHub, Apple, or Amazon.

This can make getting started much simpler because you can use a login you already have rather than setting up another username and password specifically for AWS.

This approach is particularly relevant for:

• Individual developers
• Students and learners
• Personal projects
• Prototypes
• AWS experimentation

IAM and enterprise SSO options are still relevant for the enterprise users

What Are AWS Projects?

This is where the new experience gets particularly interesting for individual builders.

A Project contains an AWS account where you create your AWS resources, along with settings for sharing the project with collaborators. AWS recommends thinking of the resources in a project as representing an application or a related set of use cases.

You can think of it as:

Idea → Project → Build → Learn

For example, I could create a project called:

Customer Address Lookup

The project could contain:

• Amazon API Gateway — REST API
• AWS Lambda — application logic
• Amazon DynamoDB — customer data

The goal is to make it easier to go from an idea to something you can actually build and experiment with.

AWS Settings provides a central place to access your projects, create new projects, invite collaborators, manage billing, and manage project spend limits.

Let's Build a Simple Project

Let's say I'm learning serverless development and want to build a simple Address Lookup API.

The requirement is straightforward:

Given a customer_id, return the customer's address.

The architecture could look like this:

The API could expose an endpoint such as:

GET /customers/{customer_id}/address

For example:

GET /customers/12345/address

Lambda receives the customer_id, looks up the customer record in DynamoDB, and returns the address.

The response might look like:

{
"customer_id": "12345",
"address": {
"street": "123 Main Street",
"city": "Columbus",
"state": "OH",
"zip": "43215"
}
}

It's a simple example, but it introduces several important AWS concepts:

REST API → Compute → Database

And because we're using managed, serverless services, we don't need to provision or manage servers.

From Idea to Implementation

This is where I think the new experience becomes especially interesting.

AWS provides a setup prompt that you can give to your AI coding agent. The prompt can configure the AWS CLI and Agent Toolkit for AWS so that your coding agent can work with your AWS Project.

Once connected, you can give your coding agent a natural-language requirement.

For example:

Build a REST API that accepts a customer ID and returns the customer's address from DynamoDB using AWS Lambda and API Gateway.

Instead of spending your first hour figuring out how to configure every piece of the environment, you can focus on the application you want to build.

That's a significant shift in the learning experience:

Idea → Describe it → Build it → Run it → Learn from it

Since I use Kiro for my learning projects, I used this function to configure the agent toolkit in Kiro IDE.

I then passed the prompt to build and deploy the Customer Address Lookup API in my project account. Once Kiro confirmed the deployment, I validated it using the AWS Console as shown below:

Kiro created the code for AWS Lambda, DynamoDB, API, IAM role, and CloudWatch log. It also created an IaC script to deploy the API solution.

Once deployed, I validated it via terminal using curl command to validate the output being returned by this API.

A Built-In Safety Net for AWS Spending

This feature particularly caught my attention because when I first started using AWS, I was always concerned about accidentally spending more than I intended.

I set up safeguards such as Cost Explorer, AWS Budgets, spending alerts, and email notifications. I also regularly remind attendees about these practices in my Community Days and meetup presentations.

Those are still good practices. But the new Project spend limit adds another layer: a defined cost ceiling for the project.

With this feature, you can set a monthly spend limit. AWS provides alerts as you approach the limit, and when the limit is reached, the project is paused and its resources are stopped.

I like this distinction:

• Budget alerts → Tell me what's happening
• Spend limit → Defines where the project stops

For someone learning AWS, that provides an extra layer of confidence to experiment without constantly worrying about an unexpected bill.

For me, that's one of the most interesting aspects of the new AWS experience.

What About Enterprise SSO?

If you're wondering whether this new experience replaces the way enterprises access AWS, it doesn't.

Organizations using IAM Identity Center and enterprise federation continue to have their existing access model.

The new experience is primarily focused on making it easier for individual builders and smaller teams to get started with AWS using preconfigured defaults and Projects.

AWS's documentation also makes clear that the new experience isn't intended for every use case. Organizations that need things such as fine-grained permissions, regulated workloads, specific account configuration, or the full breadth of AWS account capabilities may need the advanced sign-up experience instead.

So I see these as complementary experiences rather than one replacing the other.

My Take as a Builder

What I find interesting about this new AWS experience isn't just the redesigned sign-in page, it's how AWS is making it easier to go from an idea to a hands-on project.

For individual builders, the journey can now look like:

Sign In → Create a Project → Build with AI → Set a Spend Limit → Learn

For me, that's the most interesting part of the experience. It lowers some of the initial friction around getting started while giving builders a safer environment to experiment.

It doesn't eliminate the need to understand AWS. It gives you a more approachable way to learn AWS by building.

And that's something I always enjoy:

Build something. Learn something. Keep Learning!

Thanks for reading, and I hope you found this article insightful.

Watch the video here:

Thanks,

𝒢𝒾𝓇𝒾𝓈𝒽 ℬ𝒽𝒶𝓉𝒾𝒶
𝘈𝘞𝘚 𝘊𝘰𝘮𝘮𝘶𝘯𝘪𝘵𝘺 𝘉𝘶𝘪𝘭𝘥𝘦𝘳 | 𝘈𝘐 𝘌𝘯𝘨𝘪𝘯𝘦𝘦𝘳𝘪𝘯𝘨
𝘈𝘞𝘚 𝘊𝘦𝘳𝘵𝘪𝘧𝘪𝘦𝘥 𝘚𝘰𝘭𝘶𝘵𝘪𝘰𝘯 𝘈𝘳𝘤𝘩𝘪𝘵𝘦𝘤𝘵
𝘈𝘞𝘚 𝘊𝘦𝘳𝘵𝘪𝘧𝘪𝘦𝘥 𝘋𝘦𝘷𝘦𝘭𝘰𝘱𝘦𝘳 𝘈𝘴𝘴𝘰𝘤𝘪𝘢𝘵𝘦
𝘈𝘞𝘚 𝘊𝘦𝘳𝘵𝘪𝘧𝘪𝘦𝘥 𝘎𝘦𝘯𝘈𝘐 𝘗𝘳𝘢𝘤𝘵𝘪𝘵𝘪𝘰𝘯𝘦𝘳
𝘈𝘞𝘚 𝘊𝘦𝘳𝘵𝘪𝘧𝘪𝘦𝘥 𝘊𝘭𝘰𝘶𝘥 𝘗𝘳𝘢𝘤𝘵𝘪𝘵𝘪𝘰𝘯𝘦𝘳
𝘈𝘞𝘚 𝘊𝘭𝘰𝘶𝘥 𝘛𝘦𝘤𝘩𝘯𝘰𝘭𝘰𝘨𝘺 𝘌𝘯𝘵𝘩𝘶𝘴𝘪𝘢𝘴𝘵