AWS appears to be taking a fresh look at how to get developers started. Its documentation now describes a new sign-up experience called Sign up for AWS (new) – which I’ll simply refer to as AWS (new) in this post.
Over the last 20 years, AWS has gained a lot of capabilities (over 200+ products as of today), and a fair amount of complexity along with them. That flexibility is useful when you know what you are doing. For a new developer who just wants to deploy an application, there is quite a lot to understand before getting to the actual work.
AWS (new) seems to be an attempt to reduce that initial complexity through preconfigured defaults, easier collaboration and built-in cost controls. Of these, the spending limit is probably the most important.
New Sign Up
The traditional AWS sign-up process creates an AWS account with its own sign-in and access-management arrangements. AWS Builder ID is a separate identity, which has contributed to some confusion about which account to use for which purpose.
With the new sign-up experience, you can use an existing Google, Apple, GitHub or Amazon login. AWS also creates an AWS Builder ID as part of the process.
You can start from the sign-up page, or choose the new experience when signing up through the AWS website. After completing your details, AWS provisions your first project. You manage projects, collaborators and billing through AWS Settings. At the time of writing, AWS says this experience is being released to a limited number of customers, so it may not be available to everyone yet.
Project
AWS (new) introduces the concept of a project. At first glance, this might sound like an AWS resource group. However, a project contains an AWS account together with settings for sharing access with collaborators.
This makes collaboration part of the initial experience. You can invite team members through AWS Settings without bothering with IAM roles and policies – which is very hard to get right.
Having said that, simpler permissions also mean less flexibility. According to the collaboration documentation, invited team members receive admin access to the services and resources in the project. They cannot change the owner’s spend limit or perform certain billing and project-management actions.
That seems convenient for a small team building together, but for teams that need different permissions for developers, testers etc, the advanced experience is likely to be more suitable.
Spend limit
For years, developers have been asking for a way to limit AWS bills. It is very easy to leave resources running, misconfigure an application or underestimate how quickly usage can grow.
Budget alerts help but someone still has to act on them. You might be asleep when an alert arrives and wake up to an unexpectedly huge bill. Too many alerts can also lead to alert fatigue – that happens to me. Some developers resort to custom scripts and budget-triggered automation, but it is not easy to cover every service and test that it works.
AWS (new) provides a more direct solution. On the Paid Plan, you can set a monthly spend limit for each project. When usage reaches the limit, AWS pauses the project and stops its resources to contain costs.
The limit applies to pre-tax charges and excludes credits. Its minimum is the greater of US$20 or AWS’s conservative estimate of your likely spending. To reactivate a paused project, you increase the limit; some resources may need a manual restart. AWS also states that project data is permanently deleted if no action is taken within 90 days of the pause.
For experimentation and learning, this could remove a significant source of anxiety – I know some developers who refuse to use AWS for this reason. For production, you need to be comfortable with the possibility of an interruption.
It remains to be seen how smoothly pausing and restarting works in practice. I would want to try this with a few different services before relying on it for an application that other people depend on.
Trade-offs
AWS (new) supports a limited set of services and features. The supported-services list list the services supported, and it is worth checking this against your application’s requirements. There are also limits on particular capabilities, including some cross-Region operations. AWS’s comparison of sign-up options points users towards the advanced experience when they need full control over account configuration, fine-grained permissions or specific regulatory requirements.
I feel that AWS is developing two entry points for different needs:
- A simpler developer experience, for individuals and small teams that want to start building with less setup and more predictable spending.
- An advanced experience, for users and organisations that need the full range of services, configuration options and governance controls.
AWS says users can activate advanced features when needed. But it could ease the initial onboarding and make the transition to the full experience more gradual, as they become more familiar with AWS and expand their requirements.
Conclusion
AWS (new) looks like a useful step towards making AWS more approachable. Easier sign-in and collaboration should help developers get started, but the spend limit could be the killer feature. If it works reliably in practice, experimenting on AWS may finally feel a little less like leaving the meter running.







