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
Top comments (0)