New to AWS: Learn AWS without a surprise bill, start free, build your first app
AWS's new signup explained: no credit card for most users, up to $200 in credits, spend limits, and a first project idea you can build with AWS Agent toolkit as a first time AWS user to learn the most fundamental concepts in cloud engineering.
Series: New To AWS Beginners Guide (9 articles)
- 1New to AWS: Learn AWS without a surprise bill, start free, build your first app This article
Details checked September 30, 2026. AWS is rolling out the new experience gradually, so eligibility, features, and screens can vary. The app below is a proposed learning project, not a deployed application. AWS signup documentation
You want to learn AWS by building something. Then a thought interrupts:
"What if I leave something running and wake up to a bill I can't afford?"
So you open another tutorial. Your bookmarks look very cloud-certified, and your app still doesn't exist.
AWS announced a new signup experience on September 16, 2026. It has simpler registration, a preconfigured project, and a setup prompt for connecting your coding agent. Most new customers can start without a credit card. AWS launch announcement
For a beginner, the bigger change is a clearer path from "I'm afraid to try" to "I built a feature and I understand how it works." This post covers the signup, the cost protections, and a project you can build with your agent in your own AWS account.
Can you sign up for AWS without a credit card?
Yes, for most new customers. Eligible accounts start on the AWS Free Tier free plan with no card required. If you later move a project to the paid plan, you can set an optional spend limit. These are two separate protections. AWS launch walkthrough
Starting on the free plan is different from setting a spend limit after you choose the paid plan.
1. Sign up with an identity you already use
You can sign up with email or with Google, GitHub, Apple, or Amazon. AWS then creates your first project: an AWS account for resources, plus settings for sharing access. Your AWS Builder ID represents you as a person, and it is separate from the account that holds your resources. AWS signup documentation
Capture from the signup experience. You may see a different screen during the rollout.
The no-card path has exceptions. AWS may ask for payment information to verify you, and customers who aren't Free Tier eligible may need the paid plan. Check which plan AWS shows you before you continue. AWS signup documentation
2. How much free credit do new AWS accounts get?
Eligible new Free Tier accounts get $100 in credits at signup and can earn up to $100 more through qualifying activities. That's up to $200 total. AWS Free Tier
Watch your own remaining credits and time on the dashboard. The balance, dates, and activities in a demo capture aren't a personalized offer.
The free plan lasts up to six months or until you use your credits, whichever comes first. AWS says it won't charge you unless you move to a paid plan, and it closes the account when the free plan ends. Don't accept a paid upgrade or turn on paid-only services until you understand the change. AWS Free Tier
Treat the credits as a practice allowance. Your resources still consume usage when credits cover the cost.
Your first goal doesn't need to be "try every service." Try this instead:
"Send one request from my app, save something in the cloud, and explain where the data went."
3. How does the AWS project spend limit work?
On the paid plan, you can set a monthly project spend limit. You pay for what you use, not a flat fee equal to the limit, and AWS pauses the project when spending hits the limit. AWS launch walkthrough
The limit applies per project, to pre-tax charges, excluding credits. The minimum is $20 or AWS's conservative estimate of your likely spending, whichever is greater, so a $20 cap won't be available for every workload. AWS doesn't attach a limit automatically; you have to set it. Spend-limit documentation
Optional early controls can stop new resource launches, pause supported idle resources, or pause major cost drivers. Any of these can interrupt your app, and blocking launches can prevent scaling. A paused project keeps its data at first, but AWS says it permanently deletes that data after 90 days if you take no action. Raising the limit reactivates the project, though you may need to restart some resources. Spend-limit documentation
You're trading uptime for a protected budget: the experiment goes offline before it overspends. A spend limit won't back up your data or keep your app available.
What is Agent Toolkit for AWS?
Agent Toolkit for AWS connects your coding assistant to your AWS project. It works with compatible agents such as Kiro, Claude Code, Cursor, and Codex. The toolkit gives the agent current AWS information, task-specific skills, and tools for authenticated AWS actions. Toolkit overview
With the toolkit connected, you can ask for more than code to copy. The agent can check documentation, propose resources, deploy changes you approve, and inspect the result.
How to connect your coding agent to your AWS project
In AWS Settings, open the project and find the coding-tool access workflow. Copy its agent prompt into your assistant, complete the setup and browser sign-in, and pick a recognizable profile name such as
learning-dev. Choose the session for that project, not an unrelated account. Connect an AI coding tool I've also provided a step by step setup guide on how connect Kiro, Codex, Claude, etc to your AWS account this blog .
You can also copy the official setup instruction from the AWS console page:
1
2
Set up Agent Toolkit for AWS by following these instructions:
https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.mdIf your project shows a live prompt, start there. AWS console setup instructions
After setup, ask the agent to confirm its target. This read-only command returns the AWS identity it's using:
1
aws sts get-caller-identity --profile learning-devCheck that the account matches your selected project, and confirm the project's allowed Region separately. A friendly profile name doesn't prove which account or Region a command will hit. AWS CLI identity command Project-session guidance
The toolkit's AWS MCP Server connects compatible agents to AWS tools. Its skills give the agent procedures for specific tasks, and rules files hold your project guidance. The toolkit costs nothing extra, but AWS resources still use credits or incur charges under your plan, and your assistant may have its own pricing. Toolkit overview
In this project, AI helps you build the app. The finished app has no chatbot, and the agent stays out of the requests your app serves.
Don't stop at "build this for me." Ask:
"Explain what you are about to create, why it is needed, and how I can verify it worked."
You're the one learning AWS here. The agent does the typing.
Keep convenience and permissions separate
An agent that promises "I'll ask first" hasn't given you a security boundary. AWS permissions decide what it can do. Use temporary credentials, review access, and grant only the permissions the agent needs. IAM best practices
The new experience turns on IAM role manager for supported workflows. Some generated roles start broad; AWS documents a Lambda example with
PowerUserAccess. Inspect the role attached to your function instead of assuming the defaults are least privilege, and refine it before production, as AWS recommends. IAM role manager Can you share an AWS project with a collaborator?
Yes. You can invite a collaborator by email and choose which projects to share. They get developer access, which lets them create, change, and delete resources. They can't change owner-only financial settings such as the spend limit. Project collaboration
Invite someone you trust. The invite grants developer access to your resources.
Keep two kinds of access apart. A collaborator helps operate your AWS project, and an app user signs in to use your application. The project below keeps those identities separate.
Beginner AWS project: build a Cloud Learning Tracker
Build an app that records the AWS skills you're practicing.
The first version does one thing: sign in, add a goal, see your goals, and mark one complete. Example goals: "Deploy a protected API" and "Find a request in the logs." Use fictional data while you develop.
Proposed interface, not a screenshot of a built or tested app.
Run the frontend on your laptop at first. A small React interface is enough. Focus on the backend before you add hosting, a custom domain, or notifications.
You'll know it works when you create a goal, refresh the page, and see it still there. The same feature teaches the boundaries you'll reason about in larger applications.
Architecture: API Gateway, Lambda, and DynamoDB
The core request path is Amazon API Gateway → AWS Lambda → Amazon DynamoDB, a serverless API pattern AWS documents with this official diagram:
Official AWS artwork from the API Gateway CRUD tutorial . The figure shows the core request path, not the full security design, and loads from AWS instead of the local asset folder.
The tracker adds Amazon Cognito for app sign-in, CloudWatch Logs for troubleshooting, and a restricted IAM execution role for Lambda. API Gateway can validate Cognito-issued JSON Web Tokens (JWTs) before it invokes the backend. HTTP API JWT authorizers Lambda logging
The complete proposed design has app sign-in, a protected API, user-owned records, runtime permissions, and logs. The coding agent helps build these resources and stays out of the runtime request path.
Before deploying: AWS lists API Gateway, Lambda, DynamoDB, Cognito, CloudWatch, and CloudFormation as supported Free Tier services for this experience. Service support doesn't guarantee every feature qualifies, so have your agent check the specific features and allowed Region for your project. Supported services
What happens when you click "Add goal"?
You sign in through Cognito first. The browser gets tokens and sends an access token with each API request. API Gateway validates the token, and the backend uses the authenticated identity to decide which records the caller can access. Cognito sign-in JWT validation
In the proposed implementation, an add request looks like this:
1
2
3
4
5
POST /goals
Authorization: Bearer <access-token>
Content-Type: application/json
{"title":"Deploy my first protected API"}Lambda validates the title and takes the owner from the verified identity, never from a
userId the caller supplies. It writes the goal to DynamoDB and returns it through API Gateway, and the browser updates the list.The first version uses three routes:
| Route | Behavior we want |
|---|---|
POST /goals | Create a goal owned by the signed-in user. |
GET /goals | Return only that user's goals. |
PATCH /goals/{goalId} | Set completion status on a goal the user owns. |
The proposed DynamoDB key is
userId plus goalId. The first groups a user's goals, and the second identifies one goal in that group. That follows DynamoDB's composite-key model and lets the app query one user's partition instead of scanning every record. DynamoDB keys DynamoDB Query Local doesn't mean private. Your frontend runs on your laptop, but the deployed API is reachable from the internet. Require authorization before you deploy the goal routes. CORS settings let the browser call the API, but they don't authenticate anyone or enforce per-user access. API authorization HTTP API CORS
8 AWS concepts this project teaches
1. APIs and request/response communication
An API is the contract between your interface and your backend. A button click sends an HTTPS request with a method, path, headers, and body, and the backend returns a status and a result. API Gateway routes those requests to Lambda. API Gateway tutorial
Practice: Open the browser's Network panel and inspect
POST /goals. Compare a successful save with a rejected empty title.Why it matters: APIs are the boundary between web interfaces, mobile apps, and backend services. "The button is broken" turns into a better question: did the request leave the browser, reach the API, or fail inside the backend?
2. Serverless compute and scaling
Lambda runs your code without you provisioning or managing servers. It runs on each invocation and scales with demand, within service and account limits. Serverless still has servers and costs; AWS runs the servers for you. AWS Lambda overview
Practice: Find an invocation in the function's metrics and explain what caused it. Start with one small handler; splitting routes into separate functions can wait.
Why it matters: You learn to separate business logic from infrastructure work, and you see that scaling still needs limits, monitoring, and cost awareness.
3. Persistent data and access patterns
DynamoDB stores items in tables and identifies them by keys. Your goals live in the database, outside the browser and outside any single function invocation. DynamoDB components
Practice: Add a goal, refresh, and retrieve it again. Explain why
GET /goals should query the signed-in user's records instead of reading the whole table. Querying tables Why it matters: Data outlives individual requests. If you choose keys around the questions your app asks, you can reason about correctness, performance, and who can see which records.
4. Authentication, authorization, and least privilege
Authentication asks "Who are you?" Authorization asks "What may you do?" Cognito and the API's token checks establish app identity, and your backend still has to enforce ownership. Lambda's IAM role separately controls its access to AWS resources. JWT authorizers IAM practices
Practice: Use two test users. Prove the second user can't list or update the first user's goals. Inspect Lambda's role and name the table operations it allows.
Why it matters: A successful login doesn't authorize every action. Keeping the two apart prevents a classic mistake: protecting a screen while leaving the data behind it exposed.
5. Observability: knowing what happened
With the right permissions, Lambda sends logs to CloudWatch Logs. Log request identifiers and outcomes, and leave out passwords, tokens, and unnecessary personal data. Lambda logging
Practice: Submit an invalid title, then find that request in the logs. Explain whether the failure came from authentication, validation, or storage.
Why it matters: Staring harder at a button won't tell you why a remote app failed. Logs and metrics give you evidence.
6. Infrastructure as code with AWS SAM
AWS SAM lets you describe serverless resources in a template that builds on CloudFormation. Keep the template next to your app code so you can review and repeat deployment changes. AWS SAM overview
Practice: Find the definitions for the API, function, table, and permissions. Ask the agent to explain any infrastructure change before it applies it.
Why it matters: You can review, share, and rebuild a templated environment, which you can't do with a string of undocumented console clicks. The template also gives you a starting inventory for cleanup.
7. Accounts, Regions, and environments
Your new project contains an AWS account. AWS provisions it with a selected Region and limits available features until you activate advanced options. Check your project configuration instead of copying a Region from someone else's tutorial. AWS signup documentation
Practice: Record the account, Region, profile, and stack name in your project README. Confirm them before each deployment.
Why it matters: A correct command in the wrong environment can still do damage. Explicit targets keep your learning work away from unrelated resources.
8. Costs, limits, and the resource lifecycle
Credits pay for eligible usage but don't stop it. When the free plan ends or a paid project hits its limit, AWS changes your access or availability, and you still need to know what you created. AWS Free Tier Spend limits
Practice: Estimate a small test workload, compare it with observed usage, and inventory resources after cleanup. Request modest API throttles to limit accidental request bursts, but don't treat throttling as a billing cap. HTTP API throttling
Why it matters: Cost is part of design. If you can explain what runs, what persists, and what's left after a test, you'll use that skill on the next app too.
Copy-and-paste prompts to build it in your AWS account
Use these after you connect Agent Toolkit. Start with planning, and check the target and the design before you let the assistant create anything.
Prompt 1: confirm the target and propose a plan
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
I am new to AWS. Help me build a Cloud Learning Tracker
and teach me the cloud concepts as we go.
Use Agent Toolkit for AWS to check current documentation,
service availability, and the selected project's restrictions.
First confirm my authenticated AWS account, project, profile,
and allowed Region. Use the project associated with learning-dev
only after confirming its actual identity.
Do not deploy or change AWS resources yet.
Propose a small architecture with:
- A React frontend running locally on localhost:5173.
- An API Gateway HTTP API, Lambda, and DynamoDB backend.
- Cognito app sign-in and JWT authorization for every goal route.
- Lambda logs in CloudWatch and restricted execution permissions.
- Infrastructure as code using AWS SAM/CloudFormation.
Users should sign in, add goals, list their own goals,
and mark their own goals complete.
Explain the request flow, authentication, per-user authorization,
and each service's purpose in beginner-friendly language.
Estimate the AWS usage for two test users, 20 small goals,
and 500 API requests over one week. Include authentication,
logs, storage, deployment artifacts, and data transfer where
applicable. State assumptions, sources, and anything uncertain.
Do not promise the project is permanently free.
Stay on my current account plan. Do not activate advanced
features, add payment information, change spending limits,
or modify unrelated resources. Stop and explain any blocker.
Show the proposed resources and permissions. Wait for approval.The first exchange should end with a plan you can explain and no deployment yet.
Prompt 2: build in small, reviewable steps
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
Implement the approved Cloud Learning Tracker design.
Create local code and infrastructure files first; ask before
the first AWS deployment and before destructive changes.
Use supported runtimes and verify current AWS instructions
through Agent Toolkit. Keep the frontend local for this version.
Use one small Lambda handler for the three goal routes.
App behavior:
- POST /goals creates a goal with a non-empty, bounded title.
- GET /goals lists only the authenticated user's goals.
- PATCH /goals/{goalId} sets completed to true or false.
- Derive userId from the validated token's sub claim.
Never trust a userId supplied in the request body or path.
- Use userId and goalId as the DynamoDB composite key.
Query by userId, handle pagination, and do not Scan all users.
- Updates must target an existing goal owned by that user.
Do not silently create records during an update.
Security:
- Use a Cognito public app client without a client secret,
authorization code flow with PKCE, and exact local callbacks.
- Choose sign-in features supported by this account's plan.
- Require a validated access token and appropriate read/write
scopes on the goal routes. Configure issuer and client checks.
- Configure CORS for the exact local frontend origin.
- Do not put AWS access keys or long-lived secrets in the browser.
- Give Lambda only its required table operations and log access.
Inspect the actual role, including any role-manager policies.
- Do not log tokens, passwords, or unnecessary personal data.
Operational simplicity:
- Use modest request throttles and seven-day log retention.
- Do not add EC2, a NAT gateway, an RDS database, paid-only
features, a custom domain, or frontend hosting for this version.
- Tag supported resources with Project=CloudLearningTracker.
- Track deployment artifact buckets and any retained resources.
After each step, explain what changed, the cloud concept it
teaches, and a test I can run. Return deployment outputs,
a README, tests, and a cleanup plan. Never invent test results.The browser sign-in above uses Cognito's authorization code flow with PKCE, which protects the code exchange when a public client can't hold a secret. Ask the agent to explain it as it builds. Cognito OAuth flows
Prompt 3: prove it works and access is restricted
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Test the deployed tracker with two test users and fictional data.
Verify that a goal survives a refresh, that completion changes
persist, and that an empty title is rejected with a useful error.
Verify that requests without a valid token are denied, and that
one user cannot read or update another user's goals.
Find a request in CloudWatch Logs. Show me the actual deployed
resources, effective Lambda role permissions, and observed usage.
Do not treat delayed billing data as proof of zero consumption.
Report each check as PASS, FAIL, or NOT RUN with evidence.
Then ask me to explain the request path in my own words.
Do not add new features yet.These prompts guide the workflow; they don't enforce permissions. Review the assistant's actions and use IAM controls and plan settings to limit access. As the account owner, you're responsible for the resources and actions of any agent you connect. IAM practices Coding-tool responsibilities
Your take-home challenge
Complete one path:
Sign in → add a goal → save it → refresh → see it again.
Then explain where the goal lives, what stops another user from reading it, and where you'd look if saving failed. Keep a screenshot of the app and a short README on one error you investigated.
When you're done, ask:
1
2
3
4
5
6
Inventory the resources created for CloudLearningTracker.
Explain what deleting the stack will remove, what it will retain,
and what data will be lost. Include log groups, database data,
Cognito users, and deployment artifact buckets. Identify anything
shared with other projects. Wait for my approval before deleting.
After approved cleanup, verify what remains and explain why.Don't delete a shared deployment bucket because it showed up during the exercise. Check who owns it and what it's for first. AWS's reference tutorial also treats cleanup as part of finishing the project. API tutorial cleanup
Once the backend works, a good next step is AWS Amplify Hosting for the frontend, which adds hosting and deployment from source control. Update the app's allowed origins and sign-in callbacks for the hosted address, and review costs and permissions before you share it. Amplify Hosting
You don't need to understand every AWS service before you start. You need one small app you can build, inspect, protect, and explain.
Close a tutorial tab and build something. Then make sure you know how it works.
Series: New To AWS Beginners Guide (9 articles)
- 1New to AWS: Learn AWS without a surprise bill, start free, build your first app This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article