5 Things Nobody Tells You About Deploying to AWS for the First Time

Aditi — Sun, 12 Jul 2026 14:36:47 +0000

Lessons from Week 4 of the AWS Summer Builder Cohort 2026
Everyone tells you AWS is powerful. Everyone tells you it's the industry standard. Nobody tells you about the 45 minutes you'll spend staring at an AccessDeniedException wondering why your Lambda can't talk to your own DynamoDB table.
This week, my team deployed our Intelligent Polling System to AWS for the first time — and we learned more from the things that went wrong than from the things that went right. Here are 5 honest lessons from our first real AWS deployment.

IAM Will Humble You Immediately
Before this week, IAM was that thing we knew was important but hadn't really needed to deal with. After this week, we understand why the entire cloud security session was dedicated to it.
Every AWS service operates in its own permission bubble. Your Lambda function cannot read from S3 or write to DynamoDB just because you created them in the same account. You have to explicitly tell AWS: "this function is allowed to do this thing."
The error message when you get it wrong:
User: arn:aws:sts::123456789:assumed-role/my-lambda-role
is not authorized to perform: dynamodb:PutItem
on resource: arn:aws:dynamodb:ap-south-1:table/polling-results
What to do: Before writing deployment code, map out every service-to-service interaction in your architecture. For each one, ask: "does this service have permission to talk to that service?" Create a checklist and tick them off as you set up IAM roles.
The principle of least privilege — only give each service exactly the permissions it needs and nothing more — is not just a security best practice. It's also what keeps you from creating a mess that's impossible to debug later.
Environment Variables Are Not Optional
This one caught us off guard. We had been developing locally with a .env file that stored API keys, database connection strings, and configuration values. We had .env in our .gitignore so it never went to GitHub. Smart, right?
What we didn't think about: Lambda has no idea your .env file exists. It's not running on your machine. It's running in AWS's infrastructure. So every process.env.MY_API_KEY in your code returns undefined in production.
The fix is straightforward — Lambda has a built-in Environment Variables section under Configuration. Set your variables there. But finding this out after deployment, when your function is silently failing, is not a fun debugging experience.
What to do: Before deploying any function, write down every environment variable your code uses. Set them all in Lambda's configuration before running a single test. Make this a checklist item for every deployment.
For sensitive secrets, go one step further — use AWS Secrets Manager or AWS Systems Manager Parameter Store instead of plain Lambda environment variables. Your future self will thank you.
S3 is Not Just Storage — But Its Permissions Are Confusing
We knew S3 was an object storage service. What we didn't fully appreciate was that S3 could also host an entire frontend application — static HTML, CSS, JavaScript, images — all served directly from a bucket.
What confused us: there are two separate ways to control access to S3 objects — Bucket Policies and ACLs (Access Control Lists). They overlap, they can conflict, and if you get either one wrong your site is either completely inaccessible or completely open to the world.
We initially enabled static website hosting but forgot to make the objects publicly readable. Our site loaded a blank page with no errors — because S3 was returning 403 Forbidden silently for every asset request.
What to do: When hosting a static site on S3, set the bucket policy explicitly:
json{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket-name/"
}
]
}
And always put CloudFront in front of S3 — it handles HTTPS automatically, caches your assets globally, and hides your S3 bucket URL so it can't be accessed directly.
Lambda's Default Timeout Will Break Your App
Lambda functions have a default execution timeout of 3 seconds. For a simple function that does a quick calculation or database lookup, that's fine. For a function that makes HTTP requests to external URLs — like ours does — 3 seconds is dangerously short.
Our polling function checks whether websites are up. Some websites take 5, 8, even 12 seconds to respond. Lambda was killing our function mid-execution and returning a timeout error with no useful debugging information.
The fix is one click — Lambda → Configuration → General Configuration → Timeout. We set ours to 30 seconds. But we only found the problem after scratching our heads over why some URLs were always showing as "down" when they clearly weren't.
What to do: Think about the slowest possible execution of your function and set your timeout to at least 2x that. Also set up CloudWatch Logs from day one — every Lambda invocation logs to CloudWatch automatically, and those logs are invaluable when something goes wrong.
javascript// Always log at the start and end of your handler
exports.handler = async (event) => {
console.log('Event received:', JSON.stringify(event));

// your code

console.log('Result:', JSON.stringify(result));
return result;
};

EventBridge Is the Most Underrated AWS Service for Student Projects We saved the best for last. EventBridge is AWS's event bus and scheduler — and it completely changed how our system works. Before EventBridge, our polling system required someone to manually trigger a check. Useful, but not really "intelligent." After EventBridge, our Lambda function triggers automatically every 5 minutes, checks all configured URLs, saves the results to DynamoDB, and sends an SNS alert if anything is down — all without a single human action. Setting it up takes about 10 minutes:

EventBridge → Rules → Create Rule
Schedule → Rate expression: rate(5 minutes)
Target → Lambda function → select yours
Done

Watching DynamoDB fill up with automated results for the first time — knowing that no one triggered it, that the system was just... working on its own — was genuinely one of the coolest moments of the entire cohort so far.
What to do: If your project does anything on a schedule — checking data, sending reminders, generating reports, cleaning up old records — EventBridge is your friend. It's free for the first few million events per month, which means for any student project, it's essentially free forever.

The Real Lesson from Week 4
Here's what nobody tells you about deploying to AWS for the first time: it will take three times longer than you expect, and you will learn more from the errors than from the successes.
The AccessDeniedException teaches you IAM. The blank S3 page teaches you bucket policies. The silent Lambda timeout teaches you CloudWatch. The missing environment variable teaches you production configuration.
Every error is the cloud teaching you something that no tutorial covers because tutorials show you the happy path. Real deployment shows you everything else — and that's where the actual learning happens.

What's Next
Week 5 is about polish, performance, and preparing for Demo Day. We're adding CloudWatch dashboards, improving our UI, and starting to think about how to present the Intelligent Polling System to judges.
If you're going through your first AWS deployment right now and hitting walls — keep going. The walls are the curriculum.

Built with ☁️ during AWS Summer Builder Cohort 2026 — AWS Student Builder Group, IGDTUW
Team: Aditi Shanker · Vaishnavi Verma · Naina Verma

AWS #Lambda #Serverless #DynamoDB #S3 #CloudFront #EventBridge #AWSSummerBuilderCohort2026 #IGDTUW #BuildInPublic #Deployment #StudentDeveloper #WebDev #CloudComputing

Lessons from MVP Week – More Than Just Coding

Aditi — Sun, 05 Jul 2026 17:38:57 +0000

One of the biggest lessons from Week 3 of the AWS Summer Builder Cohort is that building an application is much more than implementing features.

Creating an MVP means bringing together multiple concepts that work in harmony.

Here's what we're learning this week:

💡 Debugging
Writing code is only half the journey. Finding bugs, understanding why they occur, and improving code quality are skills that every developer develops over time.

🔗 API Integration
APIs are the bridge between the frontend and backend. Learning how to consume REST APIs helps transform static interfaces into dynamic applications.

🗄️ Databases
Whether SQL or NoSQL, databases are the backbone of modern applications. Understanding CRUD operations helps us manage and retrieve data efficiently.

🚀 Deployment
A project sitting on your local machine isn't enough. Deploying an application teaches us about hosting, environment variables, and preparing software for real users.

For our Intelligent Polling System, each of these pieces contributes to creating a functional MVP that users can interact with.

As we continue building, I'm excited to see our architecture evolve from diagrams into a fully working application.

Every week brings new challenges, but every challenge is another opportunity to learn.

Looking forward to sharing our deployed MVP soon! 🌟

AWS #CloudNative #DeveloperJourney #NextJS #Supabase #Docker #DevOps #FullStack #LearningInPublic #AWSSummerBuilderCohort

DEV Community: Aditi

5 Things Nobody Tells You About Deploying to AWS for the First Time

AWS #Lambda #Serverless #DynamoDB #S3 #CloudFront #EventBridge #AWSSummerBuilderCohort2026 #IGDTUW #BuildInPublic #Deployment #StudentDeveloper #WebDev #CloudComputing

Lessons from MVP Week – More Than Just Coding

AWS #CloudNative #DeveloperJourney #NextJS #Supabase #Docker #DevOps #FullStack #LearningInPublic #AWSSummerBuilderCohort