Introduction to AWS Serverless Development (Hands-On Course)

Course introduction.

What does "serverless" actually mean? We bust the "no servers" myth and use a simple real-life example (EC2 vs AWS Lambda) to show how it differs from running your own server.

course outline

Get your website live using AWS S3 and CloudFront CDN.

Amazon S3 is object storage, where your website's files will live. We create our first bucket and see how object storage works.

Meet CloudFront, AWS's global CDN. See how it serves your site from edge locations worldwide for a faster, cleaner, HTTPS URL and why it sits in front of everything we build.

Where to get free, official hands-on practice. We point you to AWS Skill Builder labs for S3 and CloudFront so you can reinforce each concept in a real AWS environment.

Host your website straight from S3 and get it online, then see the limitations (cost, security & performance) that make us reach for CloudFront in the next lecture.

Put it together: serve your S3 site through CloudFront for a fast, secure, global URL. By the end of this lecture, your website will be live on the internet. ?

A quick look at the feature we're adding next: a live visitor counter.

Meet API Gateway, the front door that turns your code into a real, callable HTTPS endpoint. See where it fits and why your website needs it to reach a backend.

Meet AWS Lambda, run backend code with no server to manage. This is where our counter logic lives: increments the count.

Meet DynamoDB, a fast, fully-managed database to store the view count.

Free, official hands-on practice. We point you to AWS Skill Builder labs for API Gateway, Lambda, and DynamoDB so you can drill these services in a real AWS environment.

How the pieces fit together. We trace the full request path, browser → API Gateway → Lambda → DynamoDB, so you can picture every hop before we wire it up.

What is the AWS SDK, why does it exist, and how does it simplify communication with AWS services like DynamoDB, S3, and Lambda?

Time to build. We create the Views API end-to-end using the Lambda, the DynamoDB table, the IAM permissions, and the API Gateway route.

Connect the API to your live site. We add a CloudFront behaviour that routes API to API Gateway. Your counter is live! ?

The problem: right now, anyone with the URL can see the resume. Here's what we'll build to fix it: a private link that only works for people you've actually let in.

Meet CloudFront signed cookies, how you keep a file private but still serve it fast over the CDN.

How the lock works end-to-end. We map the flow: auth page → signed-cookie Lambda → CloudFront → protected file, so every piece has a place before we build it.

Time to build the lock. We generate RSA keys, set up a trusted key group, write the Lambda that mints the signed cookies, and test it. Your resume is now private. ?

Right now, the counter only updates when you refresh. We'll make it live so that every viewer watches the number climb in real time, no refresh needed. Here's what powers it.

Meet the WebSocket API, an always-open, two-way connection between browser and backend. This is what lets the server push updates to viewers instead of waiting to be asked.

Meet DynamoDB Streams, a live feed of every change to your table. When the view count updates, a Stream fires an event we can react to. This is the trigger behind real-time.

More on DynamoDB Streams.

How it all fits together. We map the flow: viewer connects over WebSocket → count changes → Stream → broadcast Lambda → pushed to every client.

Build it, part 1. We set up the WebSocket API behind CloudFront.

Build it, part 2. We wire DynamoDB Streams to a broadcast Lambda that pushes the new count to every connected viewer, then watch the counter tick up live across browsers. ?

Secure WebSocket Connection.

The big upgrade: turn the single-user site into a multi-tenant app where anyone can sign up and get their own private resume.

AWS Cognito runs your entire login system, so you never store or handle passwords yourself.

How users log in without your app ever touching their password. We walk the OAuth 2.0 Authorization Code flow step by step, with Cognito as the identity provider.

OAuth in action. We log in through Cognito's hosted UI, receive JWT tokens, and crack one open to view the claims, including the sub that serves as each user's identity.

Workflow: Architecture Part 1.

CDN Behaviors: Architecture Part 2.

Build the resume owner's dashboard frontend.

Lock down the management API. We add a Cognito JWT authorizer so only a logged-in owner can manage their own resume.

Management dashboard backend setup.

Run the dashboard locally. We set up the frontend so you can develop and test against your real AWS backend before deploying.

More on CORS.

Finish the live counter for multi-tenancy. The WebSocket is now scoped per resume and guarded by the same authorizer. Every viewer gets live updates for the resume they're watching. ?

Resource cleanup.

What's next?

Congratulations!