The first time I used AWS, it was because I had built something locally and wanted to deploy it so my friends could see what I was already seeing on localhost. But that whole journey, from the moment I first landed on the AWS login screen, created my account, all the way to finally watching my app run, took me weeks.
What do I need? What are Regions, and which one do I pick? What is IAM, and why is it asking me for so many permissions? How do I know how much one specific app is costing me? And why is everything so scattered?
AWS is rolling out a new experience built exactly for folks who are just getting started, because I wasn't the only one who ran into these questions and AWS listened. The new experience smooths out a lot of the friction that existed for people using AWS for the first time. In this post I'll walk you through what those changes are and what they mean if you're just starting out.
How do you create an AWS account?
To kick things off, you can now create your account with Google, GitHub, or an AWS Builder ID. That makes life easier, because you no longer have to waste time filling out a huge form, and you can start building in just a few clicks. And what excites me the most is that for most new users a credit card won't be required anymore, which I think is awesome for students.
Projects
Something that always bugged me was that if you didn't have much experience, or if you hadn't put in a good time studying governance, getting a clear picture of the resources you were using for one specific app turned into a real challenge.
Now in the new AWS experience, there's something called Projects. A project is a separate AWS account where you create resources. The difference is that you can create several projects, and the resources you create in one project won't show up in the others.
Inviting team members
This is something I would have loved back when I was in school, being able to invite my classmates into the same space to build together without fighting with IAM and explaining to them how to use credentials.
In the new experience you can invite team members to your projects just by sending them an email invite from AWS Settings. They create their own AWS Builder ID to get in and that's it, they're already collaborating with you, and there's no cost for inviting collaborators. They share the same project and only pay for the resources they use, just like if you were on your own. That makes it perfect for studying in a group, for a hackathon, or for your final university project. If you want the exact steps, they're in the official docs for inviting team members.
Start building without fighting the permissions
When I started, IAM was one of the most confusing things. Why do I have to create users, roles, and policies just to try something out? It felt like a giant wall standing between me and building anything.
To understand what changes, it helps me to think of permissions as three separate layers.
The first layer is who gets into your project, meaning which people can log in and work. Before, you set this up by hand, creating users, credentials, and policies for each person. In the new experience, AWS handles it. You don't create users anymore, you invite people by email and they get in with their AWS Builder ID as team members.
The second layer is the project's rules, the limits that apply to the whole project and define what can be done in general, like working in a single Region or which services are available. In the new experience AWS takes care of this one too, so you don't configure it. If you want to take a look at the details, it's in the docs on policies for projects.
The third layer is access between your resources and the outside world. Here's the nice surprise, inside your project your resources can already talk to each other by default, so your Lambda can read your DynamoDB without you wiring up any IAM policies. What stays in your hands is deciding what to expose publicly, because by default nothing in your project is reachable from the internet until you configure it, like a public S3 bucket, an API Gateway, or a Lambda function URL.
No surprise bills while you learn
When you're starting out, the scariest part usually isn't the code, it's the bill. The new experience handles that in a way that genuinely calmed me down.
It starts with the Free Tier. As a new user you get up to $200 in credits, $100 the moment you create your account and up to $100 more as you complete activities such as creating a lambda function or an EC2 instance which is great to start learning and building. You can use those credits over your first six months. On the Free plan you build with free services and those credits, and you don't get charged unless you choose to upgrade, so there are no surprise overages while you're learning.
On top of that, because your resources live inside projects, you can see exactly how much each project is spending instead of digging through one big pile. That clarity per project was something I really wished when I started.
And when your free credits run out and you move to the Paid plan to keep building, that's where spend limits come in. A spend limit is a monthly cap on a project, and if you reach it, AWS pauses the project so your bill never grows past what you set. Spend limits are a Paid plan feature, so think of them as your safety net for when you grow beyond the free credits. Here are the details on how to create a spend limit.
A single Region, and why that helps you at the start
Another question that kept nagging at me was the one about Regions. Which one do I pick? What if I get it wrong?
In the new experience each project works in a single Region, so that's one less decision to make when you're starting. All your regional resources live there and if you want to confirm which one is yours, you'll find it in AWS Settings, in your project's additional info.
Frequently asked questions
What happens if I hit my spend limit?
Your project pauses so you don't keep spending. To bring it back, the project owner raises the limit from AWS Settings.
Can I use any AWS service?
Not all of them are available right out of the gate. If a service doesn't show up, you can check the list of supported services and, if you need it, turn on advanced features, which is AWS the way we knew it before.
Where do I see what I'm spending?
In AWS Settings, under Billing. Your billing is shared across all your projects, so you pay in one place instead of juggling a separate bill for each. Even so, you can still see how much each project is spending on its own, so nothing feels scattered.
Wrapping up
What would have helped me most when I started wasn't another tutorial, it was clearing away the roadblocks that kept me from even getting going. And that's exactly what the new AWS experience solves.
- You sign in with a social login and work inside a project, without so much upfront setup.
- You invite your friends to collaborate at no extra cost for adding them.
- You start with free credits and clear costs per project, and spend limits cap your bill once you move to the Paid plan.
- AWS manages human access, so IAM stops being the first pebble in your shoe.
- You work in a single Region, with fewer decisions to make at the start.
If any of this sparked your curiosity, the best next step is to create your project and build something small. Theory really clicks when you put it into practice, and now the path to doing that is a whole lot shorter.
If you like this kind of content and you're more of a video person, follow us on our YouTube channel AWS Developers, we'll be waiting for you there.