For MeDo Hackathon, i built CloudSentinel AI, an infrastructure incident investigation platform that analyzes cloud and system logs to help developers find failures faster.

I haven’t personally been paged at 3 AM for a production outage. The idea came from thinking about where developers lose the most time during debugging, and log analysis kept coming up. Logs rarely explain what broke, they show you what reacted to what broke. Finding the actual cause of a deployment failure means reading through thousands of lines and manually connecting events. That takes a long time, and it doesn’t have to.

What It Does

You paste in your logs from Kubernetes pod output, Docker container logs, CI/CD failures, API gateway logs, whatever and the platform runs an investigation. The output is organized into six sections.

1. Severity classification. The platform reads error density and signal patterns to triage the incident. Not every failure is a P0.
2. Infrastructure signals. Which services and components were involved. Memory pressure, misconfigured readiness probes, cert expiry. This surfaces automatically from the logs.
3. Correlated failure detection. A database connection pool maxing out triggers API failures, which trigger pod restarts, which trigger health check failures. The platform traces those connections instead of treating each error in isolation. This is the part i spent the most time on.
4. Investigation timeline. A chronological reconstruction of how the incident unfolded, so you can see the cascade rather than a flat list of unrelated log lines.
5. Root cause analysis. A structured assessment with a confidence score and a readable explanation of the reasoning. You can push back on it if it’s wrong.
6. Recommended fixes. Next steps grounded in what the logs actually showed.

The result is a structured hypothesis with evidence attached. You still make the call. But you start from somewhere instead of from nothing.

How It Works

The analysis runs on Gemini 2.5 Flash, called through a Supabase Edge Function on Deno. The hard part was the prompting.

Getting a model to return grounded analysis on messy infrastructure logs, without inventing explanations the data doesn’t support, took a lot of iteration. I structured the prompt to force layered reasoning: identify signals, find correlations, form a root cause hypothesis, then suggest fixes. Each stage feeds the next.

Production logs are also massive. One incident can produce tens of thousands of lines. I built a chunking layer that extracts the most signal-dense portions before sending anything to the model. Critical errors in, routine INFO noise out.

The UI took several passes. Investigation tools carry a lot of information, and the challenge is organizing it for someone who is already stressed about an outage. I landed on a card-based layout styled after the dark observability dashboards engineers use during incidents.

What Went Wrong During the Build

Getting the model to return consistent, valid JSON with nested arrays and confidence scores was harder than i expected. I had to build a fallback layer for malformed responses, and the prompt went through many revisions before the output was reliable.

The database schema also needed a mid-hackathon migration. The initial design couldn’t represent correlated failures or investigation timelines, so i added six columns and updated the edge functions, types, and four UI pages. Lesson: think harder about data shape before writing the first query.

Edge cases in real log formats are also messy. Truncated output from crashed containers, mixed log formats, unusual environments . Those still produce imperfect results sometimes.

What I Took Away

The most reliable AI features i’ve seen are attached to a specific workflow and solve one repetitive problem well. CloudSentinel works better than a general chatbot for this task because the output is structured for the workflow, not for conversation.

Prompting is also a design problem. The difference between a flaky AI feature and a dependable one usually comes down to how well you’ve constrained the model’s reasoning. It’s not about clever wording.

What’s Next

Live log streaming is the main thing missing. Right now the platform is batch-based. You submit logs and get a report. A streaming version could surface investigation drafts in real time as an incident develops.

After that: infrastructure topology mapping (so the platform understands how your services connect, not just what they log), team collaboration features for shared investigations, and eventually historical pattern matching so past incidents can inform new ones.

If you’ve spent two hours reading logs to find a 30-second fix, you know the problem. That’s what I built this for.

CloudSentinel AI is live here

#BuiltWithMeDo

If you’re comfortable building React applications but haven’t worked with AWS before, the implementation tutorial that follows this article will introduce several technologies at once: Lambda, API Gateway, DynamoDB, Cognito, and CDK. Without some grounding, each of those can feel like an unfamiliar piece in a puzzle you haven’t seen the box for.

This article is that box. It explains what each technology is, why it exists, and exactly where it appears in the Vendor Management App you’re about to build. No implementation yet . This is just the mental model.

1. Why Full-Stack Architecture?

When you build a React app that uses a managed backend like Firebase or Supabase, the infrastructure layer is hidden from you. Someone else designed the database, the API, the authentication, and the hosting. That’s fine for many projects. But when you move to AWS, you’re given the raw components and asked to wire them together yourself.

It’s the difference between using a framework and understanding what the framework is doing. Once you can define your own infrastructure, you understand what every layer of your application is actually responsible for and you can change, scale, or debug any part of it.

A full-stack application, at its most basic, has four distinct concerns:

Frontend — what the user sees and interacts with. In our case, a React application built with Next.js. The frontend has no direct access to the database. It can only ask the backend for data.

Backend — the logic layer that handles requests, enforces rules, and talks to the database. In our app, this is a set of Lambda functions. They receive a request, process it, and return a response.

Infrastructure — the underlying AWS services that host and connect everything: the database, the API endpoint, the CDN, the storage bucket. These exist whether your app is running or not.

Authentication — the system that verifies who a user is and whether they’re allowed to do what they’re trying to do. In our app, this is Amazon Cognito. It sits outside the request flow but influences every protected request that passes through it.

Separating these concerns is what makes the system maintainable. Your frontend doesn’t need to know how the database stores data. Your Lambda doesn’t need to know how the user logged in. Each layer has one responsibility, and they communicate through defined contracts.

2. Understanding the Request Flow

Before writing any code, you need a clear picture of what happens when a user clicks “Add Vendor” in the app. Here is the full flow:

Browser → CloudFront → API Gateway → Lambda → DynamoDB

Let’s walk through each step.

Browser

The user’s browser is running your compiled React application. When the user fills in a form and submits it, the browser constructs an HTTP request, a POST request with the vendor data as JSON in the body. That request needs somewhere to go. It goes to a URL, and that URL points to CloudFront.

The browser doesn’t know anything about Lambda or DynamoDB. It sends a standard HTTP request, the same as it would to any other API.

CloudFront

CloudFront is AWS’s Content Delivery Network (CDN). It has two jobs in this application.

First, it serves the static frontend. When you build your Next.js app and export it as static files, those files — HTML, CSS, JavaScript — are stored in an S3 bucket. CloudFront sits in front of that bucket and delivers those files to users through a network of edge locations distributed globally. A user in Tokyo gets the files from a server near Tokyo, not from a data center in Virginia.

Second, CloudFront provides the HTTPS URL that your frontend uses to talk to the backend. Rather than exposing your API Gateway URL directly to the public, you route API requests through CloudFront. This gives you a single domain for both static content and API traffic.

Think of CloudFront as the front desk. It receives every incoming request, delivers static content directly, and forwards API requests inward to the appropriate destination.

In the Vendor Management App: CloudFront hosts the React frontend and forwards API requests to API Gateway.

API Gateway

API Gateway is the entry point to your backend logic. It’s a managed AWS service that receives HTTP requests and routes them to the appropriate handler — in our case, a Lambda function.

You define routes on API Gateway: POST /vendors goes to the create Lambda, GET /vendors goes to the read Lambda, DELETE /vendors goes to the delete Lambda. API Gateway handles the routing, the protocol, and critically, authentication. Before it sends a request to Lambda, it can check whether the request carries a valid identity token. If it doesn't, the request is rejected at this layer. Lambda never sees it.

Think of API Gateway as a reception desk with a security checkpoint. It checks your ID (the Cognito token), then directs you to the right room (the Lambda function).

In the Vendor Management App: API Gateway exposes the /vendors endpoint, validates JWT tokens using Cognito, and routes each HTTP method to the correct Lambda function.

Lambda

Lambda is where your application logic lives. A Lambda function is a piece of code that runs in response to an event, in this case, an HTTP request from API Gateway. It runs, does its job, and stops. There is no server running continuously, waiting for requests.

When a user POSTs a new vendor, API Gateway triggers the createVendor Lambda. That function receives the request, extracts the vendor data from the body, generates an ID, and writes the record to DynamoDB. It then returns a response, a status code and a message, back through API Gateway to the browser.

Lambda functions are isolated. Each function does one thing. createVendor creates. getVendors retrieves. They share the same database but operate independently.

In the Vendor Management App: Two Lambda functions handle the vendor data, one writes to DynamoDB, one reads from it. A third handles deletion.

DynamoDB

DynamoDB is AWS’s NoSQL database service. Every vendor record the user creates is stored here. Lambda reads from and writes to this table. The frontend never touches DynamoDB directly , it goes through Lambda every time.

DynamoDB is a managed service. You don’t provision a database server. You define a table, set the key structure, and AWS handles storage, replication, and availability.

In the Vendor Management App: A single DynamoDB table named VendorTable stores all vendor records. Lambda accesses it using the AWS SDK.

3. What is AWS CDK and Why Use It?

Infrastructure as Code

Traditional AWS usage involves logging into the AWS Console and clicking through forms to create resources: Create table, Create function, Create API. This works, but it has real problems. It’s not repeatable, if you need to recreate the infrastructure in a new environment, you click through every form again. It’s not auditable, there’s no record of what was created or why and it’s error-prone.

Infrastructure as Code (IaC) solves this by letting you define your infrastructure in a file, the same way you define a React component. The file is the source of truth. You commit it to version control. You deploy from it. You can tear everything down and rebuild it identically with a single command.

What CDK Is

AWS CDK (Cloud Development Kit) is a framework for writing Infrastructure as Code using real programming languages — TypeScript, Python, Java, and others. In our tutorial, we use TypeScript.

CDK lets you write something like this:

const vendorTable = new Table(this, 'VendorTable', {
  partitionKey: { name: 'vendorId', type: AttributeType.STRING },
});

That TypeScript code describes a DynamoDB table. It’s not creating the table yet but describing what the table should look like.

How CDK Works Under the Hood

When you run cdk deploy, CDK takes your TypeScript definitions and synthesizes them into a CloudFormation template, a JSON or YAML file that describes every AWS resource in precise detail. AWS CloudFormation then reads that template and creates or updates the actual resources in your account.

As a developer, you don’t write the CloudFormation template directly. CDK generates it for you from your TypeScript code.

Your TypeScript (CDK) → CloudFormation Template → Real AWS Resources

Why is this important for the tutorial?

In the implementation guide, you’ll write your entire backend, the database, the Lambda functions, the API, the authentication, in a single TypeScript file called backend-stack.ts. When you run cdk deploy, all of it appears in AWS. When you run cdk destroy, all of it is removed. No manual cleanup or orphaned resources.

In the Vendor Management App: CDK defines the DynamoDB table, both Lambda functions, the API Gateway, the Cognito User Pool, the S3 bucket, and the CloudFront distribution. One file, one deployment command.

4. Serverless Explained

What “Serverless” Actually Means

Serverless doesn’t mean there are no servers. It means you don’t manage them. AWS runs your code on its own infrastructure, scales it automatically, and bills you only for the time your code is actually executing.

In a traditional backend, you’d provision a server, an EC2 instance, a container, a VPS, and it runs 24 hours a day regardless of whether anyone is using your app. You pay for uptime. You’re responsible for patching, scaling, and monitoring the machine.

With Lambda, you deploy a function. AWS runs it when it’s triggered, for as long as it takes to complete, and then stops. A Lambda function handling ten requests per day costs almost nothing. A Lambda function handling ten million requests scales automatically without any configuration change on your part.

Event-Driven Execution

Lambda functions don’t run continuously. They wait for events. An event can be many things: an HTTP request from API Gateway, a file upload to S3, a message in a queue, a scheduled timer. In our app, the event is always an HTTP request arriving at API Gateway.

When API Gateway receives a POST /vendors request, it packages the request data into a structured event object and passes it to the createVendor Lambda. The function receives that object as its event parameter, processes it, and returns a response. The entire execution might take 50 milliseconds.

export const handler = async (event: any) => {
  const body = JSON.parse(event.body);
  // ... process the request
  return { statusCode: 201, body: JSON.stringify({ message: "Vendor Created" }) };
};

Why This Architecture Scales

Because each Lambda invocation is independent, the system handles concurrent requests naturally. If 500 users submit a vendor form at the same time, AWS runs 500 instances of your Lambda function in parallel. You didn’t configure that nor provision extra capacity. It just works.

For a learning project, this also means you have no idle infrastructure costs. The database exists and incurs a small storage cost, but the Lambda functions only cost money when someone uses them.

In the Vendor Management App: Each Lambda function is a focused, stateless handler. It receives a request, interacts with DynamoDB, and returns a response. It has no memory of previous requests.

5. API Gateway and REST APIs

How Frontend and Backend Communicate

A REST API is a convention for structuring communication between a frontend and a backend over HTTP. It uses HTTP methods — GET, POST, PUT, DELETE — to indicate what the client wants to do, and URL paths to indicate what resource it wants to do it to.

GET    /vendors        → Retrieve all vendors
POST   /vendors        → Create a new vendor
DELETE /vendors        → Delete a vendor by ID

In our app, API Gateway implements this REST API. You define the routes in CDK, and API Gateway handles receiving the HTTP requests and dispatching them to the right Lambda function.

Your frontend doesn’t call Lambda directly. It can’t. Lambda functions don’t have public URLs by default. API Gateway is what provides the public-facing URL and the routing logic.

Authentication Integration

API Gateway has a built-in concept called an Authorizer. An Authorizer is a component that runs before your Lambda handler and decides whether to allow the request through.

In our app, we use a Cognito User Pool Authorizer. When a request arrives at API Gateway, the Authorizer extracts the token from the Authorization header and sends it to Cognito for validation. Cognito checks whether the token is genuine and unexpired. If it is, the request proceeds to Lambda. If it isn't, API Gateway returns a 401 Unauthorized response immediately.

This means your Lambda functions never have to handle authentication themselves. That concern is fully handled at the API Gateway layer, before your code runs.

In the Vendor Management App: The POST /vendors and DELETE /vendors routes have a Cognito Authorizer attached. The Lambda functions behind them can assume that any request they receive comes from a verified, logged-in user.

6. DynamoDB Fundamentals

NoSQL Basics

DynamoDB is a NoSQL database, which means it doesn’t store data in tables with fixed schemas the way a relational database like PostgreSQL does. Instead, it stores items, you can think of them as JSON objects, in a table. Each item can have different fields. The only requirement is that every item has a partition key: a unique identifier.

This flexibility is well-suited to applications where the data structure evolves or where you don’t need complex relational queries across multiple tables. A vendor record in our app is a straightforward object: an ID, a name, a category, and an email. DynamoDB stores it cleanly without requiring you to define a rigid schema upfront.

Partition Keys

The partition key is what makes each item in a DynamoDB table unique. When you write an item, you must provide a value for the partition key. When you read an item directly, you look it up by that key.

In our app, the partition key is vendorId. Each new vendor gets a unique ID, in our Lambda, we generate one using Date.now().toString(). That ID becomes the partition key for that vendor's record.

const vendorTable = new Table(this, 'VendorTable', {
  partitionKey: { name: 'vendorId', type: AttributeType.STRING },
});

This CDK code tells AWS: “Create a DynamoDB table where every item is uniquely identified by a string field called vendorId."

Why DynamoDB Fits This App

DynamoDB is a natural fit here for three reasons. First, it’s a managed service, you define a table and AWS handles everything else. Second, it pairs cleanly with Lambda: both are serverless, both scale automatically, and the AWS SDK makes calling DynamoDB from a Lambda function straightforward. Third, for a list of vendor records with no complex relational requirements, a simple key-value store is the right tool. You don’t need joins, foreign keys, or transactions.

In the Vendor Management App: A single VendorTable stores all vendor records. Lambda writes to it using PutCommand and reads from it using ScanCommand.

7. Authentication with Cognito

What the Problem Is

Without authentication, your API is open to anyone who discovers the URL. Anyone can create, read, or delete vendors with no identity required. For a real application, this is unacceptable.

Authentication answers two questions: Who are you? (identity) and Are you allowed to do this? (authorization). Cognito handles the identity part. API Gateway’s Authorizer handles the authorization check on each request.

User Pools

A Cognito User Pool is a managed directory of users. When someone signs up for your app, their email and password are stored in the User Pool. Cognito handles password hashing, account verification, password reset flows, and token issuance. You don’t build any of that.

In CDK, you define the User Pool with a few configuration options:

const userPool = new cognito.UserPool(this, 'VendorUserPool', {
  selfSignUpEnabled: true,
  signInAliases: { email: true },
  autoVerify: { email: true },
});

This tells AWS: create a User Pool where users can sign themselves up, use their email as their login, and have their email automatically verified during development.

JWT Tokens

When a user logs in successfully, Cognito issues a JWT (JSON Web Token). A JWT is a compact, cryptographically signed string that encodes information about the user with their ID, email, when the token was issued, and when it expires.

The token is signed by Cognito using a private key. This means that any service with access to Cognito’s public key, including API Gateway, can verify that the token is genuine without making a network call back to Cognito on every request.

The token looks like three base64-encoded strings joined by dots:

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyLWlkIn0.signature

The frontend stores this token after login and attaches it to every API request in the Authorization header.

How API Gateway Validates Tokens

When a request arrives at a protected route, the Cognito Authorizer extracts the token from the Authorization header and validates its signature and expiry against the User Pool. This check happens entirely within AWS, before your Lambda function is invoked.

If the token is valid: the request proceeds to Lambda. If the token is missing, malformed, or expired: API Gateway returns 401 Unauthorized. Lambda is never called.

In the Vendor Management App: The frontend uses the AWS Amplify library to manage the login flow and token storage. After login, fetchAuthSession() retrieves the current token, which is then attached to every protected API request.

8. How All These Pieces Fit Together

Here is the full architecture, reconstructed as a single coherent flow.

┌─────────────────────────────────────────────────────────────────────────┐
│  AUTH LAYER                                                             │
│                    [ Cognito User Pool ]                                │
│                            |                                            │
│                     JWT Validation                                      │
│                            ↓                                            │
├─────────────────────────────────────────────────────────────────────────┤
│  FRONTEND / DELIVERY LAYER                                              │
│  [ Browser ] → [ CloudFront ] → [ API Gateway ]                        │
├─────────────────────────────────────────────────────────────────────────┤
│  BACKEND LAYER                                                          │
│  [ Lambda: createVendor ]  ──→  [ DynamoDB: VendorTable ]              │
│  [ Lambda: getVendors    ]  ←─  [ DynamoDB: VendorTable ]              │
└─────────────────────────────────────────────────────────────────────────┘

Walk through it from the perspective of a user clicking “Add Vendor”:

1. The user fills in the form and clicks submit. The React app calls fetchAuthSession() from Amplify and attaches the JWT token to the request header.
2. The browser sends a POST /vendors request with the vendor data in the body and the JWT in the Authorization header.
3. CloudFront receives the request and forwards it inward to API Gateway.
4. API Gateway’s Cognito Authorizer intercepts the request, extracts the JWT, and validates it against the User Pool. The token is valid. The request is allowed through.
5. API Gateway routes the POST /vendors request to the createVendor Lambda function.
6. The Lambda function executes. It parses the request body, generates a vendorId, and calls DynamoDB's PutCommand to write the new vendor record.
7. DynamoDB confirms the write. The Lambda function returns { statusCode: 201, body: '{"message": "Vendor Created"}' }.
8. API Gateway receives the Lambda’s response and forwards it back to CloudFront.
9. CloudFront delivers the response to the browser.
10. The React app receives the 201 response, calls getVendors() to refresh the list, and re-renders the vendor cards with the new entry.

The entire round trip, from click to updated UI, typically completes in under a second.

What CDK’s Role Was in All of This

Every component in that flow, the Cognito User Pool, the API Gateway, the Lambda functions, the DynamoDB table, the S3 bucket, the CloudFront distribution, was defined in a single TypeScript file and created in your AWS account with one command: cdk deploy.

CDK is not part of the runtime flow. It’s the tool that built the infrastructure before any user request was ever made. Once deployed, CDK’s job is done. The infrastructure runs independently.

9. Moving to the Implementation Guide

You now have a working mental model of every layer in the stack. You know what CloudFront does and why it’s in front of API Gateway. You know why Lambda functions are stateless and why that matters. You know what a JWT is and where it’s checked. You know that CDK is the tool that builds all of it from TypeScript.

When you follow the implementation tutorial and write this line:

const vendorTable = new Table(this, 'VendorTable', {
  partitionKey: { name: 'vendorId', type: AttributeType.STRING },
  billingMode: BillingMode.PAY_PER_REQUEST,
});

You’ll know exactly what that creates, why the partition key is structured that way, and where it sits in the broader architecture.

When you see event.body inside a Lambda function, you'll know that event is the structured object API Gateway built from the original HTTP request. When you see fetchAuthSession() in the frontend API service, you'll know that it's retrieving the Cognito JWT that API Gateway will check on the other end.

The implementation guide that follows builds the complete Vendor Management App from scratch: AWS account setup, CDK infrastructure, Lambda functions, Next.js frontend, Cognito authentication, and CloudFront hosting.

Continue to the implementation guide: Build a Full-Stack Vendor Management App Using React, AWS, and CDK

The concepts in this article apply beyond the Vendor Management App. The pattern, CDK-defined infrastructure, Lambda handlers, API Gateway routing, Cognito authentication, is a reusable foundation for any serverless application you build on AWS.

I was building a small backend with AWS CDK. A DynamoDB table, a Lambda function, and an API Gateway endpoint. Everything compiled until i tried to deploy and got this error:

Unable to resolve AWS account to use. It must be either configured when you define your CDK Stack, or through the environment.

Here is exactly what caused it and what fixed it.

The Setup

My stack looked like this:

• DynamoDB table for vendors
• Lambda function to create a vendor
• API Gateway REST API

The Lambda environment originally looked like this:

environment: {
  TABLE_NAME: vendorTable.tableName,
  account: process.env.CDK_DEFAULT_ACCOUNT_ID || cdk.Aws.ACCOUNT_ID,
  region: process.env.CDK_DEFAULT_REGION || cdk.Aws.REGION,
},

My bin/backend.ts file had:

import * as cdk from 'aws-cdk-lib/core';

And I was using CDK v2.

Why this error happens

AWS CDK needs three things to deploy:

1. An authenticated AWS identity
2. A resolved account and region
3. A bootstrapped environment

If any of those are missing, stale, or misconfigured, CDK cannot determine where to deploy your stack. The frustrating part is that the error message makes it sound like your stack definition is wrong. In most beginner cases, it is not.

Step 1: Verify and configure your AWS CLI

Before touching your code, you must ensure your local machine actually knows who you are in the AWS ecosystem.

aws sts get-caller-identity

If it’s working, you’ll see your Account ID and IAM ARN. If it fails or returns nothing, your credentials are stale or missing.

How to configure (or reconfigure) AWS

If the command above failed, run the configuration wizard:

aws configure

You will be prompted for four pieces of information:

• AWS Access Key ID: Your IAM user identifier.
• AWS Secret Access Key: Your IAM secret.
• Default region name: e.g., us-east-1 or eu-west-1.
• Default output format: (Press Enter for json).

Pro Tip: If you use multiple AWS accounts, ensure your AWS_PROFILE environment variable is set correctly before running CDK commands.

Step 2: Fix the CDK v2 imports

If you are using CDK v2, using v1-style imports can cause internal conflicts in how the library resolves the environment.

The Mistake:

import * as cdk from 'aws-cdk-lib/core'; // This is CDK v1 style!

The Fix:

In CDK v2, everything is bundled into the main library. Update your bin/backend.ts and stack files to:

import * as cdk from 'aws-cdk-lib';

Step 3: Stop manual account injection

I noticed iwas trying to help the Lambda function by manually passing account and region IDs into the environment variables. This was unnecessary and actually introduced more surface area for errors.

What I removed:

// Delete these lines from your Lambda props
environment: {
  TABLE_NAME: vendorTable.tableName,
  account: process.env.CDK_DEFAULT_ACCOUNT_ID || cdk.Aws.ACCOUNT_ID, // Unnecessary
  region: process.env.CDK_DEFAULT_REGION || cdk.Aws.REGION,         // Unnecessary
},

Why? Lambda functions automatically have access to process.env.AWS_REGION and process.env.AWS_ACCOUNT_ID at runtime. Hardcoding or injecting them via CDK creates a circular dependency logic that can confuse the synthesizer.

Step 4: Clear stale artifacts

This is what finally solved it for me. CDK synthesizes your TypeScript code into CloudFormation templates inside a folder called cdk.out. If you changed your AWS configuration or updated your code, the old templates in cdk.out might be conflicting with your new settings.

Run this sequence to start fresh:

# 1. Delete the cached metadata
rm -rf cdk.out
# 2. Recompile your TypeScript
npm run build
# 3. Generate a fresh CloudFormation template
cdk synth
# 4. Deploy
cdk deploy

Summary Checklist

If you’re still stuck, run through this list in order:

1. ActionCommand / CheckCheck Identityaws sts get-caller-identity
2. Reset Credentialsaws configure
3. Bootstrapcdk bootstrap (Required for new accounts/regions)
4. Check Imports Ensure you use aws-cdk-lib, not /core
5. Purge Cacherm -rf cdk.out && cdk deploy

One of these will fix it.

I have been learning AWS IAM recently and I practice mostly using KodeKloud labs.

Every lab gives me a real AWS Console. I can launch EC2 instances, create S3 buckets, configure networking, attach policies. It feels like a real AWS account.

There are limits. I cannot access everything. I cannot escalate privileges, interfere with another student and after one hour, the entire environment disappears.

When I click “Start Lab”, I am automatically given:

• An AWS Console login URL
• A username
• A password
• A working CLI environment

So I started thinking. If I were running a platform like KodeKloud, how would I architect this?

Based on what I have learned so far, here is my technical hypothesis of how this likely works using a hybrid IAM and STS architecture.

This is not insider information. This is how I think it works as someone learning cloud and trying to reason through the design.

First, What Are IAM and STS?

Before I explain the architecture, let me clarify two important services.

IAM

AWS Identity and Access Management (IAM), is how AWS controls who can do what.

It allows you to create users, create groups, attach policies, define permissions and enforce least privilege.

IAM answers the question: Who is allowed to access which AWS resources and how?

If I create an IAM user and attach a restrictive policy, that user can only perform the actions explicitly allowed. That is the foundation of access control.

STS

AWS Security Token Service (STS), is about temporary credentials. Instead of giving someone permanent credentials, STS allows you to issue temporary access keys, temporary session tokens and time bound permissions.

These credentials automatically expire.

It answers a different question: How do I give short lived, controlled access without permanent risk?

This critical for lab environments.

Now let us apply these ideas to KodeKloud.

KodeKloud has to:

• Give thousands of students real AWS access
• Prevent cross access between students
• Enforce least privilege
• Prevent privilege escalation
• Automatically expire sessions
• Control cost
• Clean up reliably

This is a multi tenant IAM design problem layered with temporary credential control. IAM and STS together, solve the problem.

1. The Foundation: A Controlled AWS Account

At the core, they likely operate from one or multiple controlled AWS accounts. Inside those accounts, they probably maintain:

• Predefined VPC configurations
• Base EC2 AMIs
• S3 templates
• IAM policy templates

I do not think they create a brand new AWS account per student. That would be operationally heavy and expensive. Instead, they likely isolate students logically inside shared lab accounts.

2. When You Click “Start Lab”

When I click Start Lab, I believe backend automation does something like this:

• Generate a unique session ID
• Provision required AWS resources
• Create a new IAM user
• Attach a restrictive policy or add the user to a predefined group
• Generate a login profile with a password
• Possibly generate temporary credentials via STS
• Display credentials to me

Example: kk-user-947201

This IAM user probably does not exist before I start the lab. It is created dynamically. This is automated IAM lifecycle management.

3. IAM Groups and Policy Reuse

To scale this system, they likely predefine IAM groups per lab type:

• VPC Lab Group
• EC2 Lab Group
• S3 Lab Group

Each group has tightly scoped permissions.

When a session starts:

• A new IAM user is created
• That user is added to the appropriate group

This avoids recreating policies every time.

Alternatively, they could dynamically attach a session specific policy directly to the user. Either design works. The key principle is least privilege.

4. Where STS Comes In

Now it gets interesting. Even though I receive a username and password, I strongly suspect STS is involved behind the scenes.

There are two likely possibilities:

1. The IAM user exists only as a base identity and assumes a restricted role via STS to operate.
2. The platform issues temporary credentials through STS that power the CLI environment and possibly the console session.

Why would they do this? Because STS credentials:

• Automatically expire
• Reduce long term credential risk
• Enforce strict session boundaries

So the architecture is likely hybrid. IAM defines identity and permission boundaries and STS enforces temporary access and expiration.

5. Resource Isolation Using Tags

Now the most important question: How does one student avoid touching another student’s resources?

My hypothesis is tagging plus IAM condition policies. When resources are created, they are tagged with something like: Session-ID = 947201

Then IAM policies contain conditions such as: Allow access only if the resource tag Session-ID equals the user’s session ID. This means even inside the same AWS account:

• You only see your EC2 instances
• You only modify your S3 buckets
• You only manage your VPC

6. Why the CLI Works Too

The lab also provides a CLI environment. That means one of two things is happening:

Option A
The IAM user has temporary programmatic credentials generated for that session.

Option B
The CLI environment assumes a restricted role via STS internally.

Either way, the same permission boundary applies. Whether I use the visual AWS Console or the CLI, the same IAM policies control what I can do.

7. Session Expiration and Cleanup

After one hour, automation likely triggers:

• Deletion of the IAM user
• Removal of login profile
• Deletion of access keys
• Revocation of STS sessions
• Termination of EC2 instances
• Deletion of S3 buckets
• Cleanup of networking resources

The IAM user lifecycle becomes: Create > Use > Destroy

Learning cloud has changed how I see platforms.

What feels like a simple one hour AWS lab is clearly backed by serious engineering. The console login, the working CLI, the strict limits, and the automatic teardown all point to a tightly controlled identity system operating behind the scenes.

My hypothesis is that each session dynamically creates an IAM user, and temporary credentials issued through STS enforce time bound, least privilege access inside a shared AWS account. IAM defines what I am allowed to do. STS ensures that access expires. Together, they make the lab safe and scalable.

I am still learning, so this is not an insider explanation. It is just me training myself to see the systems behind the surface.

Public IPs on EC2

When you launch an EC2 instance, AWS can give it a public IP address. That public IP is what allows the instance to be reached from the internet. Without it, the instance can still exist and run, but it won’t be directly accessible from outside AWS unless you put other networking components in front of it.

Instance needs to be reachable, so it gets a public IP butthis public IP is not permanent.

By default, the public IP assigned to an EC2 instance is tied to the instance’s lifecycle. If the instance is stopped and then started again, AWS releases that IP back into its pool and assigns a new one. From AWS’s point of view, this makes sense. Public IPv4 addresses are limited, and AWS treats them as temporary resources unless you explicitly ask for stability.

This behavior is fine for many use cases. If you’re testing, experimenting, or running short-lived workloads, the fact that the IP might change is not a problem. You can always look up the new address in the console. But the moment you imagine something external depending on that address, the problem becomes obvious.

If an application is hosted on that instance and users, services, or DNS records point to its public IP, a change breaks access. Nothing about the application itself changed. The server is still there. But the address people use to reach it is no longer valid.

Elastic IPs and Stable Access

An Elastic IP is a public IPv4 address that you explicitly allocate from AWS and keep under your control. Unlike the default public IP, it is not automatically tied to the lifecycle of an instance. You can associate it with an instance, disassociate it, and reattach it elsewhere. As long as you keep the Elastic IP allocated to your account, the address remains the same.

When you associate an Elastic IP with an EC2 instance, all incoming traffic to that IP is routed to the instance. If the instance is stopped and started, the Elastic IP does not change. If the instance fails and you launch a replacement, you can move the Elastic IP to the new instance and restore connectivity without changing anything outside AWS.

This is an important distinction. The Elastic IP is not a property of the instance. It is a separate networking resource that you attach to the instance. Thinking about it this way helped me understand why AWS treats Elastic IPs differently. You are essentially reserving a scarce public address and telling AWS that this address must remain stable, even if the compute behind it changes.

There are also cost implications. AWS charges for Elastic IPs that are allocated but not actively associated with a running instance. That pricing decision reinforces the idea that Elastic IPs are meant for intentional, long-lived access points, not something you casually allocate and forget.

From a practical standpoint, associating an Elastic IP is straightforward. You allocate the Elastic IP in the EC2 console, then associate it with an instance or a network interface. Once associated, the instance effectively stops using its auto-assigned public IP and uses the Elastic IP instead. Traffic coming in through that address reaches the instance, and outgoing traffic appears to originate from that same IP.

The server can be replaced. It can be stopped, started, resized, or rebuilt. The address is what the outside world knows. Elastic IPs allow you to keep that external reference stable while everything behind it remains flexible.

In real setups, Elastic IPs are often paired with DNS records, load balancers, or migration scenarios where you need continuity. They are also useful when you need to allowlist a fixed IP with a third-party service. Without a stable IP, you would constantly need to update external systems every time the instance restarts.

So the difference is not just that one IP changes and the other doesn’t. It’s about control and intent. A default public IP exists as a convenience. An Elastic IP exists because you deliberately asked for a permanent point of access.

While working through another KodeKloud IAM task, I was asked to create an IAM policy named iampolicy_ravi. The policy needed to allow read-only access to the EC2 console, meaning users could view instances, AMIs, and snapshots, but not change anything.

I initially thought of the policy as a set of vague rules controlling EC2. That framing wasn’t wrong, but it wasn’t precise either. An IAM policy isn’t just a rule list, it’s a permission contract. It defines exactly what AWS will allow or deny when a request is made.

In this case, the requirement was read-only access. No starting or stopping instances, no deleting snapshots and no modifying infrastructure. Just visibility. To meet the requirement, the policy used this JSON:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*"
      ],
      "Resource": "*"
    }
  ]
}

Describe* means you can see everything, but touch nothing. It allows listing and viewing EC2 resources such as instances, AMIs, snapshots, volumes, and security groups. It does not allow creating, modifying or deleting anything.

At one point, I got confused about the region requirement. The task mentioned us-east-1, but when I tried to change the IAM policy region from global, all regions were disabled. After some research, i found out that IAM policies are global by design. They are not tied to regions the way EC2 resources are. The policy defines what actions are allowed. The region only matters when the permission is used against a service like EC2.

So even though the EC2 instances live in us-east-1, the policy itself doesn’t live there. It lives at the account level and applies wherever EC2 exists.

In practice, a policy like this is given to people who need context like developers who are debugging issues, managers who need to understand what infrastructure exists, auditors reviewing configurations or support engineers investigating incidents. These roles need visibility to do their work, but giving them modification rights would introduce unnecessary risk.

What are the advantages of giving read-only access? It prevents drifts, it allows people to learn the system without being able to damage it and it also creates a clear line between observing and acting.

If I had to explain it simply, I’d say this: “You can look around the EC2 environment as much as you want, but your hands are tied.”

Creating the policy took minutes but understanding why it exists took longer. I am still learning, but tasks like this are changing how I think about cloud access and how better im getting at understanding the cloud operations.

Until the next task, ciao! :)

While working through a KodeKloud cloud migration task, i was asked to create an IAM group named iamgroup_jim. At first, i treated it like a setup step and rushed through it. I thought of it as something you do so you can get to the real work later but the task atually represents one of the most important ideas in cloud security.

Reframed properly, this task was about preparing a permission boundary for a set of users during a migration. In cloud environments, especially during migration, access control is where things either stay orderly or spiral. IAM groups exist to make sure that human change does not destabilize systems.

Initially, i understood the task as simply creating a group so that user accounts can be organized. That wasn’t entirely wrong, but it was shallow. It did not explain why groups exist, why permissions are not attached immediately, or why this matters real in cloud migrations.

I like to think of it like keys in a school. Every room has a lock. Classrooms, library, staff room, storage, cafetaria etc. Teachers get one key ring, cleaners get another, students and chefs get limited keys. Groups are key rings. If your role changes, your keys change. If you leave the school, your keys gets taken back. IAM simply decides who gets which keys and what doors they can open.

For this task, we were instructed not to create users or attach permissions, only the group. Permissions are not attached directly to user because you first need to define what the group represents before deciding what access that responsibility requires. With groups, you can update access in one place, and everyone in that group inherits the right permissions.

As a beginner like myself, there are several mistakes i could make with IAM. Attaching permissions directly to users, giving admin access because it just works, or avoiding roles and groups because they feel abstract. The problem is, these shortcuts turn into confusion, security gaps, and auditing nightmares. If someone with access leaves the company, you’d have to manually hunt down every single permission to revoke it. Groups and roles remove that headache.

In real companies, IAM groups exist to provide access control during cloud migration, organize humans (not services), prevent permission sprawl and provide readiness for audits and scaling. This is why experienced teams follow a few strict rules:

• Do not assign permissions directly to users
• Teams change, permissions should not
• Auditors care deeply about consistency and traceability

IAM groups enforce structure where human behavior is unpredictable.

When responsibilities change, if five people are in a group and one person’s responsibilities change, you don’t modify the original group. hanging it could affect the other members and create confusion or accidental access. Instead, you move that person to a new group that has the permissions they now need, or you assign them a separate role with the appropriate access. This way, the rest of the group keeps their existing permissions, and only the person with new responsibilities gets updated access.

IAM groups protect you from:

• Inconsistent access
• Human error
• Over-permissioning
• Security gaps that grow over time

They make access changes predictable. When someone joins, moves, or leaves, you update structure, not individuals.

The worst misuse of IAM is giving everyone full access just to make things work. This removes isolation, accountability, and safety. One compromised account or careless action can delete systems or expose sensitive data. Admin access for daily work defeats the purpose of IAM entirely and turns the cloud into a single point of failure and unsafe.

Why does this matter in cloud migration? During a migration, IAM ensures people only access what they’re supposed to. It links job roles to permissions so no one gets accidental access to sensitive resources. Without IAM, access gets messy fast. With IAM, access stays organized, safe, and easy to manage.

So yeah, the task itself was trivial but the insight behind it is anything but. It’s a small step that teaches a lesson about thoughtfuly designing access control, thinking in terms of roles instead of people, and preparing for scale before you need it. I may have just created a group, but I also learned why groups exist in the first place and that is a far more valuable takeaway than just checking a box.

I’m still learning, but breaking down these small tasks has already changed how I think about cloud security and access control. I’m looking forward to the next steps in this journey :)

Until next time, ciao (￣︶￣）

The first task I was given was to create an EC2 key pair. It sounded simple at first, but once I started, I realized there were many words and commands that weren’t explained anywhere. So I decided to break everything down, step by step, in a way that even i could understand.

This tutorial explains:

• What a key pair is
• Why AWS needs it
• What RSA means
• Why we use AWS CLI commands like STS
• How to create a key pair using the terminal

If you’re learning cloud from scratch, this is for you.

First, What Is an EC2 Key Pair and Why Do We Need It?

When you create an EC2 instance, you’re basically creating a virtual server in AWS. Just like a real server, you don’t want random people logging into it.

AWS uses key pairs instead of passwords to make server access more secure.

A key pair has two parts:

• Public key: Stored by AWS
• Private key: Downloaded and kept by you

AWS uses the public key to lock the server. You use the private key to unlock it. If you lose the private key, AWS cannot recover it for you. That’s why this step is taken very seriously.

What Does RSA Mean?

RSA is a type of encryption algorithm. At a very simple level, encryption is how data is locked so only the right person can read it and RSA is one of the most common and trusted encryption methods.

When AWS asks for a key pair type: RSA, it means: I want my server access keys to use strong, industry-standard encryption.

You don’t need to know the math behind RSA to use AWS, but you should know that RSA keeps your server access secure, it’s widely supported and it’s safe for beginners to use

Task Requirements (What We Were Asked to Do)

We were asked to create a key pair with:

• Name: xfusion-kp
• Key type: RSA
• Region: us-east-1 (N. Virginia)

Everything must be created in that region.

Creating the Key Pair Using the AWS CLI

This method uses the command line. I’ll explain why each command is needed.

Step 1: Get AWS Credentials

Before you can talk to AWS, AWS needs to know who you are and what you’re allowed to do.

That’s what credentials are for.

I ran:

showcreds

This command shows temporary credentials provided for the task:

• Access Key ID
• Secret Access Key
• Session Token

Think of credentials like a temporary ID card that lets you enter AWS.

Step 2: What Is AWS STS and Why Are We Using It?

STS stands for Security Token Service. AWS STS is used to:

• Verify identity
• Confirm that AWS recognizes your credentials
• Show which account and user you’re logged in as

I ran:

aws sts get-caller-identity

This answers the question of who i am according to AWS at that time. If AWS responds with your account and user details, it means your credentials are valid, you’re authenticated and you can proceed safely

{
“UserId”: “BENEDIO8C21TAONYEBUCHI”,
“Account”: “123456789101”,
“Arn”: “arn:aws:iam::123456789101:user/bb_labs_user_123456”

Step 3: Setting the AWS Region (Why This Matters)

AWS has data centers all over the world. If you don’t specify a region, AWS might create resources in the wrong place.

Since the task explicitly says us-east-1, I set it manually:

aws configure set region us-east-1

This tells AWS: that any resource I create from now on should live in this region.

Step 4: Creating the Key Pair (The Actual Task)

Now that authentication and region are set, we can create the key pair.

aws ec2 create-key-pair \
  --key-name xfusion-kp \
  --key-type rsa \
  --query "KeyMaterial" \
  --output text > xfusion-kp.pem

Let’s break this down slowly.

• aws ec2 create-key-pairtells AWS to create a new EC2 key pair.
• --key-name xfusion-kpis simply the name of the key.
• --key-type rsaspecifies the encryption type.
• --query "KeyMaterial"extracts only the private key from the response.
• --output textformats the output as plain text.
• > xfusion-kp.pemsaves the private key into a file on your machine.

This .pem file is extremely important. It’s the only way you’ll ever access your EC2 instance.

Step 5: Why Do We Change File Permissions?

Linux systems are strict about file permissions for security reasons.

AWS will refuse to use your key if it’s too open. So we run:

chmod 400 xfusion-kp.pem

This means only the file owner can read the key and no one else can access it

Final Thoughts

Creating a key pair touches security, identity, encryption, and regions all at once.

By breaking it down, we saw why AWS needs to know who is making a request, why RSA is used, and why regions are not just labels.

This was just one task, but it made the cloud feel practical and intentional rather than abstract. If you are starting out, understanding this foundation makes everything that comes next easier to reason about.

On to the next lesson.

I didn’t post anything last week because I was buried in a client project that needed quick delivery. I had to pause my learning for a bit, but I picked things up again this week and decided to continue documenting my cloud journey.

This week, I spent time understanding how applications handle traffic in AWS and why decoupling systems makes them more stable. I’m still very new to cloud, so I write these notes the same way I try to understand the concepts myself.

Directing Traffic with Elastic Load Balancing

To understand load balancers, I pictured a small pharmacy during evening rush hour. There are three workers, but fifty customers are all crowded in front of one counter. That one worker would be overwhelmed while the other two stand almost idle.

A load balancer is the person who steps in and starts directing customers evenly to all three workers so no one gets overloaded.

That’s exactly what AWS Elastic Load Balancing (ELB) does. It takes incoming requests and spreads them across your EC2 instances. Without a load balancer, users connect directly to individual instances, and you would have to handle routing, scaling, patching, failover, and maintenance yourself.

With ELB, AWS manages the routing and the behind-the-scenes work for you.

The elastic part means the load balancer scales automatically with traffic. It can increase or decrease capacity without adding extra hourly cost. ELB works with internal and external traffic and supports different routing strategies to keep everything efficient.

How Load Balancers Route Traffic

Here are the routing methods I learned, still using the pharmacy example:

1. Round-robin
   This rotates customers evenly across workers. Customer 1 goes to Worker A, customer 2 to Worker B, customer 3 to Worker C, then back to A. It keeps the flow balanced with a simple cycle.
2. Least connections
   New customers go to the worker with the fewest people currently in front of them. If Worker A has seven customers, B has three, and C has one, the next customer goes straight to C. This helps when tasks take different amounts of time.
3. IP hash
   This always sends a customer to the same worker based on their ID. In real terms, your IP address decides which server you consistently connect to. It’s useful when a server needs to hold your session information.
4. Least response time
   This sends traffic to the worker responding the fastest at that moment. If Worker A is moving quicker than B and C, the next customer goes to A. It reduces waiting time.

Load balancers act as a single point of contact for all incoming requests. When paired with Auto Scaling Groups (from Week 3), they keep the application balanced as instances scale in or out, that is, as new instances are added or removed.

Messaging and Queuing: Why Decoupling Matters

Another concept I learned this week is decoupling systems so one failing component doesn’t break the entire application.

When components talk directly, the system is tightly coupled. If one slows down or fails, everything connected to it is affected.

Using the pharmacy example again: Imagine two pharmacists standing side by side, passing handwritten notes to each other for every customer request. If one suddenly steps away or gets overwhelmed, the whole process stops because the other depends on immediate responses. Any small issue spreads through the system instantly.

A loosely coupled system fixes this by placing a buffer in the middle. Messages go into a queue and stay there until the receiving service is ready.

Picture a box between the two pharmacists. Worker A drops messages into the box whenever they are ready. Worker B checks the box whenever they have capacity. Even if B slows down or steps away for a bit, A can keep dropping messages without interruption.

That box is the message queue.

It absorbs traffic, protects each component from the other’s delay, and keeps failures from spreading. The sender and receiver no longer need to work at the same speed or even at the same time.

AWS supports this with:

Amazon SQS. Lets components send, store, and receive messages at any volume. Messages sit in a queue (the payload) until the receiving service processes them.

Amazon SNS. Sends messages immediately. Instead of storing them, it pushes them out in real time through email, SMS, mobile push, or other delivery methods.

A simple way that helped me understand:

• SQS places your order on a list. It waits until someone is ready to pick it up.
• SNS is a shout-out. Once it’s made, it goes out immediately.

Monolithic vs Microservices Architecture

This is part of decoupling as well.

A monolithic application means one large codebase where everything is connected. If one part has issues, you feel it everywhere.

A microservices architecture breaks the system into separate, independent services. They communicate through SQS or SNS and can scale individually. This makes the entire system more resilient and easier to maintain.

Closing Thoughts

Missing last week stressed me out a bit, but picking up again and learning ELB and decoupling made it worth it. These are concepts I used to see everywhere but never fully understood. Writing them down helps me learn better, and hopefully it helps anyone else who’s starting cloud development from scratch.

On to the next lesson.

Understanding Scalability

I learned that scalability describes the system’s ability to support increased workload by adding more resources. It sounds simple, but there are specific ways AWS approaches this.

There are two methods:

1. Scale up (vertical scaling)
   This means increasing the power of an individual machine. Instead of running an application on a small instance, you move it to a larger instance with more CPU or memory.
2. Scale out (horizontal scaling)
   This involves adding more instances. Instead of upgrading one machine, you run your application across multiple machines that share the workload.

Scalability is mostly about long-term growth. It ensures that as the user base increases, the system can expand with it without becoming unstable.

Understanding Elasticity

Elasticity took the scalability idea a bit further. While scalability focuses on growth over time, elasticity focuses on adjusting resources automatically based on real-time demand.

Traffic goes up, resources go up. Traffic goes down, resources go down. This adjustment happens without manual intervention. It protects performance during high demand and reduces unnecessary cost during low demand.

Elasticity in AWS is powered by EC2 Auto Scaling.

How EC2 Auto Scaling Works

EC2 Auto Scaling automatically adds or removes EC2 instances depending on what the system needs at any moment. It does this using metrics collected by Amazon CloudWatch.

CloudWatch monitors things like CPU usage and latency. Auto Scaling evaluates those metrics and decides whether the application needs more instances or fewer instances.

There are two main approaches:

1. Dynamic scaling
   This reacts in real time to changes in demand. When the workload increases, new instances launch immediately. When it decreases, the excess instances are terminated.
2. Predictive scaling
   This forecasts future demand based on historical patterns. Instead of waiting for traffic to increase, AWS tries to prepare the right amount of instances beforehand.

Both approaches help applications remain stable without overspending on resources.

Auto Scaling Groups (ASGs)

Everything I learned about scaling eventually led back to Auto Scaling Groups. These groups manage collections of EC2 instances that scale together as a unit.

An ASG depends on three key settings:

1. Minimum capacity
   This is the smallest number of instances the group should ever have. When the group is created, AWS launches this number immediately.
2. Desired capacity
   This is the ideal number of instances needed to handle the current workload. If you do not define this value, AWS uses the minimum capacity as the desired value.
3. Maximum capacity
   This defines the upper limit. Even if demand spikes, the group will never exceed this number, which helps control cost and prevent overscaling.

For example, if an ASG has a minimum of 4 instances, a desired capacity of 10, and a maximum of 10, the system will run 10 instances during normal operation and will not scale beyond that.

What I Took From This Week

Before this week, scaling feels more like a system of clear rules reacting to predictable patterns. Understanding how AWS balances performance and cost gave me a better picture of how real applications stay online when traffic fluctuates.

I am still very new to cloud development, but documenting what I learn each week is helping me understand the concepts in a more practical way. If you are also learning cloud for the first time, I hope this breakdown makes scaling easier to understand.

On to the next lesson.