Every AWS resource in Terraform. A CI/CD pipeline ran clean, tests gated every deploy, and zero credentials were stored. By most measures, this project was done.

Except it had a real, honest gap: if my Lambda started failing, or DynamoDB got throttled, or my AWS bill quietly climbed past what I expected — I would have no way of knowing. Not until a visitor told me something was broken, or a bill arrived. That's not really "done." So today I added monitoring.

The Cost Worry, Resolved

My first instinct was to worry about cost — my account is past its 12-month free tier window, and this whole project has been built around staying near $0. Before adding anything, I checked properly instead of assuming: CloudWatch's alarm free tier — 10 alarms, default AWS metrics — isn't part of the 12-month window at all. It's classified as "Always Free," permanently, regardless of account age. Same for SNS — 1,000 free email notifications a month, forever. Good thing to actually verify instead of skipping monitoring out of a cost fear that turned out not to apply here.

Two Permission Gaps I Expected, Just Not Yet

Tried to apply the new alarms and SNS topics, and got hit with an authorisation error immediately — my terraform-project IAM user wasn't allowed to touch either service. Made sense once I thought about it: this user's permissions were scoped months ago to exactly the services the project touched at the time. SNS and CloudWatch were never on that list, because nothing in this project had ever needed them before today. Attached the two missing policies and moved on.

The Setting That Had Been Renamed

The billing alarm needed one more thing — enabling billing alerts in my account settings, so AWS would actually start publishing cost data to CloudWatch in the first place. Went looking for the setting everyone's guides call "Receive Billing Alerts" and couldn't find it anywhere. Turns out it's been renamed—it now lives under a section called "Alert preferences," with the checkbox labelled "Receive CloudWatch Billing Alerts." Small thing, but a good reminder that documentation and tutorials go stale, and the real console is the only source of truth.

What's Actually Watching Now

Three alarms, wired to two SNS topics — one for application issues in my main region, one specifically in us-east-1, since billing metrics only exist there globally, no matter where the rest of the infrastructure lives. Lambda errors, DynamoDB throttling, and a billing threshold, all routed to email, all confirmed and working.

Where This Actually Leaves Me

The project is genuinely complete now, in a way it wasn't yesterday. Not just "the resources exist," but "I'll actually know if something stops working." That's the difference between a demo and something built the way real production systems are supposed to work.

#AWSCloudResumeChallengeCompleted #AWS #Terraform #CloudWatch #SNS #GitHubActions #BuildInPublic

Yesterday I designed the pipeline. Today was about actually getting it to run — which turned out to be its own separate challenge, full of small, precise details that had nothing to do with the architecture itself.

Wrong Folder, First Try

GitHub Actions only looks for workflow files in one exact, non-negotiable path: .github/workflows/, plural. I put mine directly in .github/ instead. No error, no warning — GitHub just silently never recognised them as workflows at all. Moving them to the right path fixed it, but not before I also managed to create a stray file literally named workflows with no extension, which then blocked me from creating the real folder with that same name. Small mistake, layered on a small mistake.

YAML Doesn't Forgive Indentation

Hit a syntax error next — one line of my deploy job had drifted to the wrong indentation level, which made YAML read it as a brand new top-level key instead of a second job nested under jobs:. A single space, in the wrong place, and the whole file becomes invalid.

A Security Boundary I Didn't Know Existed

Pushing the fix got rejected outright: my GitHub token didn't have permission to touch workflow files at all. Turns out this is deliberate — files inside .github/workflows/ can execute real code automatically, so GitHub requires a separate, explicit scope before any token can create or modify them. My token was created weeks ago, before I ever needed that permission. Added the scope, fixed.

One Typo, Three Layers Deep

Then a credentials error — Could not assume role with OIDC: Request ARN is invalid. Took a moment to find: github-actons-deploy-role instead of github-actions-deploy-role, missing an "i", sitting inside a YAML file I'd been editing directly through GitHub's web interface across several rounds of fixes already. Fixed the spelling, and both my test job and my deploy job finally ran clean, end to end, for the first time.

The Warning That Wasn't Actually About My Code

One more thing surfaced right after — a Node.js version deprecation warning on three of the actions I'm using. Nothing I wrote caused it; it's a platform-wide runtime migration GitHub is rolling out. The real fix was bumping the major version of each action to the release their maintainers had already updated for the new runtime. I was tempted to stay a version behind out of general caution, but thought it through properly — a patch version bump is low-risk by definition, but staying on an old major version here meant staying on something scheduled for removal entirely. Pinned to the current major versions instead, understanding the actual reasoning rather than just picking a number.

Where This Leaves Me

Test gate working. Deploy following only if tests pass. Authentication with zero stored credentials. No warnings, no silent failures. The pipeline isn't just designed anymore — it's real, and I understand every piece of why it broke on the way there, not just that it eventually worked.

Up next: deciding on a monitoring approach so I actually know if something breaks in production, instead of finding out from a user.

#AWSCloudResume #CI/CDPipeline #GitHubAction #Workflows #Tests #Deployment #AWS #OICD #Day24BuildInPublic

Keeping Terraform and Deployment Separate

The first thing I had to be clear on: my Lambda function's infrastructure — its role, its permissions, its existence — already lives fully in Terraform. That was the whole point of the last several weeks. CI/CD isn't supposed to redefine any of that. Its only job is updating the code inside a function that already exists, using a direct call like aws lambda update-function-code. Nothing here touches Terraform's job, and Terraform never touches this pipeline's job. Two tools, two clearly separate responsibilities.

Tests Have Actually to Gate the Deployment

I didn't want a pipeline that pushes whatever's in the folder. The whole point of calling this "CI" — Continuous Integration — is that it verifies the code is actually correct before anything ships. So my backend pipeline runs my real test suite first, in its own separate job, and the deploy job only runs if that job succeeds. If a test fails, nothing gets pushed to my live function. That's not a nice-to-have; that's the actual reason this is worth automating at all.

Why OIDC, Not Stored Keys

I've been thinking about credential exposure since early in this project — the same reason I didn't want long-lived AWS keys sitting around on my own laptop indefinitely. Storing a raw AWS access key as a GitHub secret works, but it's a permanent, static credential sitting somewhere, and if it ever leaked, it would keep working until someone manually noticed and rotated it.

OIDC solves this differently. Instead of a stored secret, GitHub Actions proves its identity to AWS fresh, every single run, using a short-lived signed token — and I get to define exactly which repo and which branch are allowed to use it. No permanent key exists anywhere to leak in the first place. I set this up as new Terraform code — an IAM identity provider trusting GitHub specifically, and a role that only my exact repo, on my exact branch, can ever assume. Same shape of thinking as the source-ARN conditions I added to my S3 policy and my Lambda permission earlier in this project — scope trust to exactly what should have it, nothing broader.

Verifying Real Values Instead of Assuming Defaults

By now this is just a habit from this whole project: check the real region, the real runtime version, the real folder names, rather than trusting a default or an assumption. My actual resources run inus-east-2, not us-east-1. My real Lambda runtime is Python 3.14. My real folders are capitalised — Frontend and Backend — and GitHub's runners are case-sensitive, so getting that wrong would mean a workflow that silently never triggers at all, no error, just permanent silence. Every one of these got checked against the real thing before going into the workflow file.

The One Risk That Was Specific to My Own Project

My deploy step syncs my Frontend folder to S3 using --delete, which removes anything in the bucket that isn't in that local folder. I'd uploaded my resume PDF straight to S3 a while back, outside of git entirely. If I hadn't caught that, the very first real run of this pipeline would have quietly deleted it. Not a generic risk — a risk that only existed because of a specific choice I'd made earlier in this exact project, which is exactly why checking your own setup, not just the pipeline logic, matters.

Where This Leaves Me

Frontend workflow is done. Backend workflow — with the test gate, the OIDC auth, and the direct Lambda code update — is next.

Up next: finishing the backend workflow, then watching this pipeline actually run for the first time.

#AWSCloudResume #CI/CD #GithubAction #OICD #Day23BuildInPublic

This one closes out something that started back on Day 14 — turning every piece of infrastructure I'd clicked together by hand into real, working Terraform code. It took longer than I expected, and today the last two open items finally got closed.

The Two Things I Deliberately Left Open

For weeks, two things sat unfinished on purpose, rather than rushed through: my S3 bucket's public access settings were still unlocked, even though CloudFront and OAC had been the only real path in for a while. And my Lambda's IAM permissions still had full access to every DynamoDB table in my account, not just the one it actually uses.

Both got closed today. The DynamoDB policy is now scoped to exactly one action — UpdateItem — after actually reading my own Lambda code and confirming that's the only DynamoDB call it makes. Not a guess, not "probably fine" — checked against the real file. And the S3 bucket's public access block flipped from fully open to fully restricted, all four settings. Reloaded the site immediately after both changes. Still worked, exactly as expected, since nothing was ever actually relying on that open access to begin with.

One More Thing I Found Along the Way — Two Systems, Same Job

While reviewing my Lambda code, I noticed it had its own hardcoded CORS header — Access-Control-Allow-Origin: '*' — sitting right next to an API Gateway CORS configuration I'd already scoped down to my real domain a while back. Two different systems both claiming authority over the same header, with two different values. Removed it from Lambda entirely, since API Gateway's HTTP API type is supposed to handle this on its own. Tested it live, checked the browser console specifically for CORS errors — clean.

And My Tests Got Honest Too

Went back through my test file and found my most important assertion — actually checking the response body contained the right data — was commented out this whole time. The test only ever confirmed the function didn't crash, never that it returned the correct number. Fixed that, removed a mock for a DynamoDB call my function never actually makes, and added a check that verifies the exact parameters sent to DynamoDB, not just that something happened.

What "Done" Actually Means Now

Every single resource this project uses — DynamoDB, S3, IAM, Lambda, API Gateway, Route 53, ACM, CloudFront — is genuinely under Terraform, imported carefully, matching what's actually live. Not "mostly," not "except for two things." Actually all of it.

Looking back at the whole stretch to get here: the S3/CloudFront saga that ate two full days, the IAM policy attachment confusion, more typos than I want to count, a WAF I didn't know I had until Terraform told me. None of it was fast. All of it was real.

Up next: CI/CD. Starting with the safest, smallest piece first — getting my tests to run automatically on every push, before touching anything that actually deploys to AWS.

#AWSCloudResumeChallenge #Terraform #IaaC #AWS #DynamoDB #ACM #Route53 #CloudFront #Lambda #S3 #APIGateway

Today was supposed to be the last resource in this whole Terraform project — the CloudFront distribution itself. It was, but not before one wrong command and one real surprise sitting inside my own infrastructure.

The Wrong ID

First attempt at importing failed with almost no useful information:

Error: couldn't find resource

No detail, no request ID, nothing like the errors I'd gotten used to reading. Took a moment to realise why: I had used my Origin Access Control's ID by mistake, not my distribution's ID. Two completely different resource types, and the value I passed in was a real, valid-looking ID — just for the wrong thing entirely. That's likely why the error was so bare; the API wasn't confused about permissions or formatting, it just genuinely had nothing to return for a distribution that didn't exist under that ID.

Fixed it with the correct distribution ID, and the import went through cleanly.

The Plan That Actually Mattered

terraform plan came back with three differences. Two were things I expected by now — a missing tag, and is_ipv6_enabled quietly defaulting to false in my code when the real distribution actually had it turned on. Small, but a real setting, not just cosmetic.

The third one stopped me.

- web_acl_id = "arn:aws:wafv2:us-east-1:...:global/webacl/CreatedByCloudFront-0db22b05/..." -> null

My distribution has an actual AWS WAF — a Web Application Firewall — attached to it. Filtering traffic at the edge, before it ever reaches my S3 bucket. I didn't know this existed until Terraform's plan surfaced it. The name suggests CloudFront created it automatically at some point, probably from a console prompt I clicked through without fully realising what it did.

If I had applied that plan without reading it closely, I would have silently detached my own firewall. Not because I decided to — because my code simply didn't know it was there, and Terraform assumes anything undeclared should be removed.

This is the same shape of thing my iptables setup does in my EC2 project — filtering unwanted traffic before it reaches the real server — except this one's automatic, running at AWS's edge, and I'd apparently had it running this whole time without knowing.

The Fix

Added all three missing pieces back into my code — the tag is_ipv6_enabled = trueand the WAF's ARN — and ran the plan again.

No changes. Your infrastructure matches the configuration.

Where This Leaves Me

Every resource type in this project — DynamoDB, S3, IAM, Lambda, API Gateway, Route 53, ACM, and now CloudFront — is genuinely under Terraform, matching what's actually live.

I almost called this "the whole project done" today. It isn't, quite. Two things are still deliberately left open: the S3 bucket's public access settings are still unlocked, since I wanted OAC fully proven working first, and my Lambda's DynamoDB permissions are still broader than they need to be. Both get fixed tomorrow, on purpose, not rushed tonight.

Up next: locking those two down, then moving into the next real phase of this project — a CI/CD pipeline, since Terraform was never meant to redeploy my code every time I fix a bug.

#AWSCloudResumeChallenge #CloudFront #Terraform #Day21BuildInPublic

Two sessions' worth of work today — Route 53 from last night, which I was unable to post until too late, but better to have it, and the start of ACM and CloudFront today. Smaller wins than the S3 saga, but each one taught me something I hadn't touched before.

Route 53 — The Easy One I Needed

I imported my hosted zone first. Clean, no surprises — a hosted zone barely has any settings to begin with.

terraform plan Did flag one thing: force_destroy = false. At first I wasn't sure if this described something real happening in AWS. It doesn't. This setting only exists on Terraform's side — it decides whether Terraform is allowed to delete this zone later if it still has real DNS records inside it. Set to falseTerraform refuses to destroy it by accident. I applied it, and nothing about my actual live DNS changed — it was pure safety bookkeeping, not an infrastructure change.

Then the A record points my domain at CloudFront. One detail worth remembering: the alias.zone_id value for a CloudFront target isn't something you look up per-distribution — it's a fixed constant (Z2FDTNDATAQYW2) that's the same for every CloudFront distribution on every AWS account. I double-checked my actual distribution's domain name against the CLI output before trusting it, rather than assuming an old value was still correct.

Today — My First Resource That Needed a Second Provider

ACM certificates for CloudFront have to live inus-east-1, no matter what region everything else runs in. This meant writing my first second provider block:

provider "aws" {
  alias   = "us_east_1"
  region  = "us-east-1"
  profile = "terraform-project"
}

What I had to understand first: this doesn't touch or replace my original provider block at all. My existing block has no which makes it the default — every resource I've written so far uses it automatically without ever naming it. This new block only applies to a resource that explicitly writes provider = aws.us_east_1 inside itself, which is exactly the one line I added to my ACM certificate resource. Everything else in the project keeps working exactly as before.

I also skipped terraform init by accident after adding this and got worried — but it still worked fine. Turns out that matters less than I thought here, because this wasn't a new provider, just the same AWS plugin I already had downloaded, configured a second way. Different from the archive provider mistake earlier in this project, where Terraform genuinely needed to fetch something it had never seen before.

The Resource I Expected to Write, But Didn't Need To

I assumed aws_acm_certificate_validation would be next. It isn't needed here at all—and understanding why was the real lesson. That resource doesn't represent a real object in AWS with its own ID. It exists purely to make Terraform wait for a brand-new certificate's DNS validation to finish before anything else uses it. My certificate is already validated — my HTTPS has been working this whole time — so there's nothing to wait for. I can just reference the certificate directly wherever it's needed later.

Last Piece Today — The OAC From The S3 Saga

Imported the Origin Access Control I created manually weeks ago during the S3 debugging saga. Clean import, one small diff — a missing description field — which I added and applied.

Where This Leaves Me And Up Next

Route 53's zone and record, done. The ACM certificate, imported and correctly routed through a second provider. The OAC, done. The only piece left in this group is the big one — the CloudFront distribution itself, the most complex single resource block in this whole project. That gets its own full session, not a tired late-night tail end.

#AWSCloudResumeChallenge #AWS #Terraform #CloudFront #Route53 #Day20BuildInPublic

What The Plan Said

The very first line read: aws_apigatewayv2_api.visitor_api will be created. Not updated. Created — as in, a brand new one.

Right under it, four more resources — my integration, my route, my stage, and my Lambda permission — all said must be replaced. Destroy, then recreate, all four.

If I had run apply without reading closely, this would have built a second, empty API Gateway, and destroyed the real one my actual live website depends on. My visitor counter would have broken.

What Actually Went Wrong

I had imported the integration, the route, the stage, and the permission — but never the API resource itself. Terraform genuinely had no idea it existed.

Here's the part that actually explains the whole cascade: every one of those four resources references the API's ID inside my code. But since Terraform's records didn't have that API in them, it treated the ID as unknown — not as the real value it actually was. And since an API ID can't just be swapped on an existing resource, Terraform's only option was to destroy and recreate everything attached to it.

One missing import caused five different lines to look broken.

The Fix

One command:

terraform import aws_apigatewayv2_api.visitor_api opgaqw2eqqh

Ran plan again right after, and every single forced replacement disappeared at once — not because I fixed five things, but because I fixed the one real cause underneath all of them.

What Was Left After That

Two real, intentional changes remained. First, my CORS settings updated from wide open (*) to my actual domain only — something I'd deliberately meant to fix. Second, my integration's URI format changed to match the format Terraform expects for this kind of Lambda connection — a cosmetic difference from how the console originally set it up, not a functional break.

I applied both, reloaded my site immediately, and the visitor counter still worked exactly as it should.

The Actual Lesson

This is the second time in this project that a plan looking scary turned out to have one small, findable root cause underneath it — not five separate problems, one problem wearing five different symptoms. Reading why something says "destroy" instead of just reacting to the word "destroy" is turning into a real skill, not just a rule I follow because I was told to.

Up next: Actually going back and understanding—properly— every resource I've written, from the IAM policy attachments through today's API Gateway work. I got through it, but I wasn't sure why. Fixing that before moving on to CloudFront and ACM.

#AWSCloudResumeChallenge #APIGateway #LambdaFunction #Day19BuildInPublic #Terraform

Making My Code Less Hardcoded

Before touching anything new, I cleaned up something small. My bucket policy had my AWS account ID and CloudFront distribution ID typed directly into the code. Not really a secret — account IDs and distribution IDs aren't sensitive information — but hardcoded values like that make code less reusable. If I ever rebuild this under a different AWS account, every hardcoded number would need to be found and changed by hand.

So I replaced the account ID with something that asks AWS directly:

data "aws_caller_identity" "current" {}

And moved the distribution ID into a variable instead of a fixed string. Small change, but it made the code more correct, not just neater.

Bringing My Lambda's IAM Role Into Terraform

Next was the IAM role my Lambda function actually runs as. I imported it, ran terraform plan, and got a scary-looking result: destroy and recreate.

The cause was one small attribute — path. IAM roles created automatically through the Lambda console get nested under /service-role/ by default. My code assumed the default path instead, and path is one of those IAM settings that can't just be updated — Terraform's only option is to delete the old one and make a new one. That would have broken my live function's permissions if I'd let it run.

The fix was adding the real path to my code:

resource "aws_iam_role" "lambda_exec" {
  name = "visit_counter_function-role-doxa8sz4"
  path = "/service-role/"
  ...
}

After that, the plan came back clean — an update, not a destroy.

Expecting One Thing, Finding Another

I planned to write an inline IAM policy next — the kind you define directly inside your own code. But when I went looking for it to import, there wasn't one. My role wasn't using an inline policy at all. It was using two separate managed policy attachments instead — a completely different thing in Terraform, needing a different resource (aws_iam_role_policy_attachment, not aws_iam_role_policy).

Looking at what was actually attached, I found something worth knowing: one of the two policies was AmazonDynamoDBFullAccess — meaning my Lambda function technically has permission to touch every DynamoDB table in my account, not just my one visitor-counter table. Far more access than it actually needs. I'm not fixing that today — I imported it as-is, to match reality first — but it's now a known, real thing to tighten later, the same way the S3 bucket policy started too open before I scoped it down properly.

My Lambda Function — Three Mistakes in One Sitting

Writing the actual aws_lambda_function resource is where most of the real trouble happened.

First, I added a new provider (archive, for zipping my code automatically) but hadn't told Terraform about it yet. One clean fix: terraform init -upgrade. I made a manual backup of my lock file first, out of caution — then realised I didn't need to, since that file's already tracked in git from an earlier fix. Git already was the backup.

Second, and this one actually scared me — I mixed up my output filename in the code that zips my Lambda function. I meant to save the zip aslambda_function.zip, but typed .py instead. Terraform took my actual Python file, zipped it, and saved the result on top of my original file, with the same name. My real code was gone, replaced by a zipped file wearing a .py extension.

git restore brought it back in one command — because I'd already committed that file before this happened. That's the exact payoff of a habit I built early in this project and almost didn't think twice about.

Third, terraform plan refused to recognise my function's actual runtime — Python 3.14 — even though that's genuinely what's running on AWS right now. Took a while to understand why: AWS added Python 3.14 support to Lambda back in November, but the Terraform tool I'm using to manage AWS didn't get support for that same version until a later update of its own. My provider was still pinned to an older version, set weeks ago, back when 3.14 didn't even exist as an option yet. Updating the version constraint and running init -upgrade again fixed it — the same command as mistake one, solving a completely different problem this time.

Where This Actually Leaves Me

Not where I predicted eight days ago, but further along in a different, useful direction. DynamoDB, S3 (including its policy), the IAM role and its permissions, and now the Lambda function itself are all real, working Terraform code — imported carefully, matching what's actually live, nothing guessed at.

Actually, up next this time: API Gateway, wiring it to this Lambda function, and confirming the whole visitor counter still works end to end. CloudFront and ACM are still coming — just later than I said last time.

#AWSCloudResumeChallenge #Debugging #Terraform #AWS #Lambda #IAM #Day18BuildInPublic

This one took longer than I thought — two days, not the quick "import and move on" I expected after Day 16. I want to write about it honestly, even though it wasn't a clean, quick fix.

What Started It

On Day 16, I found a problem in my S3 bucket policy. It said Principal: "*" — this means anyone on the internet could read my files. I had written this rule way back on Day 11, just to fix a 403 error. I wrote a better, safer rule this time — one that only lets CloudFront access my bucket, and only my specific CloudFront distribution.

I saved this new rule. My website immediately broke and showed a 403 error.

The Problems I Had To Find, One By One

It turns out my CloudFront setup was never actually using something called Origin Access Control (OAC) — even though I thought it was, this whole time. My origin was set to "Public." This means CloudFront was just quietly using my bucket's public policy to get in. When I removed that public policy and added the safer one, I accidentally removed the only thing that was letting CloudFront in, because CloudFront was never set up the right way to begin with.

To fix it, I had to do these things, one at a time:

1. Change my origin from the S3 website link to the S3 REST API link. OAC only works with the second one, not the website one I set up back on Day 11.

2. Actually create an OAC — it didn't exist before, even though I assumed it did.

3. Check that my bucket's real region matched what I typed into the new origin. In my case, it did match, but it was still worth checking, since a wrong region would also break things.

4. Fix my Default Root Object setting. This tells CloudFront "when someone visits my homepage with no file name, show them index.html." Without this set correctly, CloudFront didn't know which file to ask for.

That last one took the longest to figure out, and here's why: when this setting is wrong, S3 doesn't show a normal "file not found" error. Instead, it shows the same "Access Denied" error as a permissions problem. So a missing-file problem looked exactly like a permissions problem, the whole time, and I couldn't tell which one it actually was.

What Finally Fixed It

Fixing the Default Root Object setting was the last piece. Everything else — OAC, the origin type, the bucket policy, the region — was already correct by that point. I just couldn't tell, because every different problem showed me the same error message.

What I Actually Learned

Two days is longer than I wanted this to take. But looking back, each of those four things — origin type, OAC, region, root object — was a real, separate reason my site could have been broken. I checked each one calmly, one at a time, instead of guessing randomly or undoing everything out of panic. That's a different skill than just writing a correct policy the first time.

Real systems usually don't break because of one obvious thing. They break because two or three small things are wrong at the same time, and the error message doesn't tell you which one is the real cause.

My site is working again. My bucket policy finally does what I thought it was already doing since Day 11. And now I have real Terraform code that matches what's actually running — not just a guess.

Next up: going back to Terraform — locking down public access on my bucket completely now that OAC is set up properly, and then finally moving on to CloudFront and ACM.

#AWSCloudResumeChallenge #Day17BuildInPublic #BucketPolicy #CloudFront #OAC #403ForbiddenError #AccessDeniedError #RealWorldProblemDebugging

Picking up from yesterday's teaser — today was S3's turn to get imported into Terraform. It went smoother than DynamoDB in some ways, and revealed something much bigger in others.

The Quick One First

Same category of mistake as my my_table vs visit_counter mix-up from Day 14 — except this time it wasn't my naming, it was AWS being inconsistent with itself. I wrote an output referencing aws_s3_bucket.resume_site.name, and Terraform threw:

Error: Unsupported attribute
This object has no argument, nested block, or exported attribute named "name".

Turns out aws_s3_bucket doesn't expose a .name attribute at all — it's .bucket, matching the argument I originally set. Different AWS resource types just don't agree on what to call the same concept. Quick fix, moving on.

The Import Went Clean — Then I Looked Closer

terraform import aws_s3_bucket.resumesite alfiyajaved.in

Ran it, got a success message, ran terraform plan right after — "No changes." Felt like another win, same as DynamoDB.

But this time I stopped myself before moving on. Unlike DynamoDB, which is one single resource block covering everything, S3 in modern Terraform is split — the bucket itself, public access settings, versioning, and the bucket policy are all separate resource blocks. My main.tf only had the bare bucket declared. "No changes" didn't mean my whole S3 setup was under control — it meant the one narrow thing I'd written matched. Everything else was just invisible to Terraform, not confirmed safe.

So before writing more code, I went and actually read my bucket's real settings in the console. And that's where today got interesting.

The Bucket Policy I'd Completely Forgotten About

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:....",
            "Resource": "arn:aws:s3:...."
        }
    ]
}

"Principal": "*" means anyone on the internet, no authentication, no questions asked, can read any object in this bucket. I recognised this policy immediately — it's the exact fix from my Day 11 post, when I hit a 403 error right after enabling static website hosting. Opening it up to everyone solved the problem at that moment.

The problem is that it was before CloudFront and Origin Access Control existed in my setup. Once I added CloudFront specifically to keep this bucket private and route everything through a proper CDN, I never went back and tightened this policy. It just sat there, quietly making the whole CloudFront/OAC setup partially pointless — my bucket name is literally my domain, so anyone could hit it directly, bypass caching, bypass HTTPS enforcement, and rack up direct S3 requests that CloudFront was supposed to be absorbing.

Nothing sensitive lives in this bucket — it's a static portfolio — but it defeated the actual architecture I built.

The Real Fix

Instead of "Principal": "*", the correct policy scopes access to the CloudFront service itself, plus a Condition that ties it to my specific distribution — not just any CloudFront distribution from any AWS account:

{
    "Effect": "Allow",
    "Principal": { "Service": "cloudfront.amazonaws.com" },
    "Action": "s3:...",
    "Resource": "arn:aws:s3:....",
    "Condition": {
        "StringEquals": {
            "AWS:SourceArn": "arn:aws:cloudfront::MY_ACCOUNT_ID:distribution/MY_DISTRIBUTION_ID"
        }
    }
}

That Condition block matters more than it looks — without it, in theory any CloudFront distribution, even someone else's, could be pointed at my bucket and read from it. Locking it to my exact distribution's ARN closes that gap.

Up next: writing this corrected policy as a aws_s3_bucket_policy resource in Terraform, watching the plan diff show the exact change from open to locked-down, and applying it to my actual live site — carefully, with a browser reload check after.

#AWSCloudResumeChallenge #S3Bucket #Debugging #Terraform #BuildInPublic #AWS #S3BucketPolicy

After yesterday's win with the DynamoDB import, I could've jumped straight into the S3 bucket next. Instead, I spent today thinking about something less exciting but more important: who's actually allowed to touch my infrastructure, and what happens if those credentials leak.

Why I Didn't Just Keep Using Root

I mentioned in my last post that I created a separate IAM user instead of running Terraform as root. Today I actually sat down and thought through why that matters, not just that it's "best practice."

Root has unrestricted access to everything in my AWS account — billing, every service, every region, no exceptions. If those credentials ever leaked — a misconfigured .gitignore, a careless commit, anything — whoever got them would own my entire account. A scoped-down IAM user limits the blast radius. Even in the worst case, a leaked key only exposes what that specific user was allowed to do.

For now, I attached broad-but-scoped AWS-managed policies (S3, DynamoDB, Lambda, CloudFront, Route 53, ACM, and IAM, since Terraform needs to manage my Lambda's execution role). It's not perfect least-privilege — a fully locked-down setup would scope IAM permissions down to exact actions on exact resource ARNs — but it's a real, meaningful step up from "everything, always," and it's honest about being a stepping stone rather than the final answer.

Understanding What Actually Costs Money

Somewhere in all this, I also went down a small rabbit hole on DynamoDB billing modes, since I wanted to actually understand the PAY_PER_REQUEST setting I'd used rather than just copying it because a tutorial said so.

Here's what I landed on: with On-Demand (PAY_PER_REQUEST), you're charged per actual read/write request, with a decent free-tier allowance before anything gets billed — great for a low-traffic personal project like mine. With Provisioned billing, you commit to a fixed read/write capacity upfront and pay for it continuously whether you use it or not, and if your traffic goes over that committed capacity without auto-scaling turned on, requests just get throttled instead of silently overcharging you.

For a visitor counter that gets maybe a few dozen hits a day, On-Demand is clearly the right call. But the bigger habit I picked up from this: I went into AWS Budgets and set up a cost alert — a simple email trigger if my forecasted bill goes above a small threshold. Cheap insurance against any future mistake, Terraform-related or not.

What's Next

With the IAM setup feeling more solid and a better grip on what actually drives cost, I'm heading into the S3 bucket next — same import process as DynamoDB, but with its own quirks waiting, since modern Terraform splits things like public access blocking and website configuration into separate resource blocks instead of one big one. I already know from experience that I'll probably hit at least one dumb mistake along the way. Looking forward to writing about it.

#AWSCloudResumeChallenge #AWS #DynamoDB #IAM #Day15BuildInPublic

It's been a while since my last post here. Life happened — I got pulled into prepping an internship application for a few weeks, and my "post daily" streak took a hit. But I'm back, and today I finally started the part of the Cloud Resume Challenge I'd been putting off: Terraform.

Until now, every single resource in my project — S3, CloudFront, Lambda, DynamoDB, API Gateway — was clicked together manually in the AWS console. It works, but it's not really how real infrastructure gets managed. If I lost my laptop tomorrow, or wanted to recreate this whole setup for a second project, I'd have to click through every single step again from memory. That's the exact problem Terraform solves — you write your infrastructure as code, and it becomes repeatable, version-controlled, and reviewable, instead of living only inside your click history.

First Rule I Learned: Don't Touch It With Root

Before writing a single line of Terraform, I stopped myself on something. I'd built this entire project using my AWS root user — the account owner, with unrestricted access to everything. That's fine for clicking around and learning, but handing that same root-level power to a tool that's about to start creating and destroying real infrastructure on my behalf felt like a bad idea.

So the very first thing I did wasn't Terraform code at all — it was creating a dedicated IAM user just for this project, with only the permissions it actually needs (S3, DynamoDB, Lambda, CloudFront, Route 53, ACM, and IAM access so Terraform can manage its own Lambda execution role). No console password, no login capability — just programmatic access keys, since this user only ever needs to talk to AWS through the CLI and Terraform, never through a browser.

The "Ohio" Bug

Here's a mistake that's a little embarrassing to admit, but it's exactly the kind of thing I want this blog to be honest about.

When I set up my new AWS CLI profile for this IAM user, it asked for a region. I typed "Ohio" Not us-east-2 — the actual region code — just the word "Ohio," because that's the human-readable name AWS shows you in the console.

Running a simple test command afterwards gave me this:

Could not connect to the endpoint URL: "https://sts.ohio.amazonaws.com/"

Turns out AWS doesn't know what "Ohio" means as a region identifier — it only understands region codes. The console shows you friendly names, but under the hood, everything is us-east-1, us-east-2, ap-south-1, and so on. A two-minute fix once I understood it, but a good reminder that the AWS console hides a layer of naming that CLI tools don't translate for you automatically.

Writing My First Resource Block

With the profile finally working, I wrote my first real Terraform resource — my DynamoDB table, since it doesn't depend on anything else I hadn't built yet:

resource "aws_dynamodb_table" "my_table" {
  name         = "visit_counter"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "id"

  attribute {
    name = "id"
    type = "S"
  }
}

This is where I actually understood something I'd been fuzzy on — the difference between a partition key (hash_key) and a range key (sort key). My table only ever stores one item — a single running counter — so it only needs a partition key. A range key only matters when multiple items share the same partition key and need sorting or grouping, which isn't my situation here at all.

"1 to Add" — And a Small Moment of Panic

I ran:

terraform init
terraform plan

And got: "Plan: 1 to add."

My immediate thought was — wait, is this about to create a second, duplicate DynamoDB table next to my real one? Since my actual table already exists, created manually months ago, this felt like the wrong outcome.

Turns out, this is completely expected. Terraform's state file — the thing that tracks what it "knows" it manages — starts empty. As far as Terraform was concerned, my table didn't exist yet, because it never created it. The fix isn't apply — it's:

terraform import aws_dynamodb_table.my_table visit_counter

This tells Terraform "hey, this table already exists in AWS — go adopt it into your state instead of creating a new one." Running plan again afterwards showed a much smaller, safer diff instead of a full creation.

The Naming Mistake That Actually Taught Me Something

Right after the import, I hit an error trying to reference my table in outputs.tf:

Error: Reference to undeclared resource
A managed resource "aws_dynamodb_table" "visit_counter" has not been declared

This confused me at first, because my table's actual name in AWS is visit_counter — so why was Terraform saying it didn't exist?

Here's the thing that finally clicked: three separate names are floating around in Terraform, and I'd been treating them as one. There's the resource type (aws_dynamodb_table), there's my own internal label for referring to it in code (I'd called mine my_table), and there's the actual AWS-facing name ("visit_counter"). My outputs file was trying to reference aws_dynamodb_table.visit_counter — using the AWS name where Terraform expected my internal label. Once I pointed it at aws_dynamodb_table.my_table instead, it resolved immediately.

Small mistake, but it's the kind of thing that only really makes sense once you've been burned by it once.

One Tag Terraform Didn't Know About

After fixing the naming issue, terraform plan showed one more thing — a tag update:

~ tags = {
    - "Project" = "StaticWebsiteHosting" -> null
  }

My real table already had a Project tag attached from way back when I first built it — but my new Terraform code never declared it. Terraform's rule is simple: whatever's in AWS but not in your code gets flagged for removal, since your code is now treated as the source of truth. I added the tag back into my resource block so nothing would get silently stripped away, and ran plan one more time.

The Win

No changes. Your infrastructure matches the configuration.

That line felt genuinely satisfying. My real, already-running DynamoDB table is now fully described in code, safely imported, with nothing duplicated and nothing lost.

Up next: Doing the same thing for my S3 bucket — except this time, I already know what to watch out for.

#AWSCloudResumeChallenge #CloudComputing #DevOps #Debugging #Terraform #AWSDynamoDB #Day14BuildInPublic #InfrastructureAsCode

But when I sat down at my laptop today, my gut told me to hit the brakes.

Before I made the frontend look pretty or rushed into automating my code with a CI/CD pipeline, I had a realisation. If I just blindly update my code and push it to AWS, a single typo could take down my live Lambda function or corrupt my database. I was building a machine without a safety net.

So, I completely changed my mind. I threw my previous "Up Next" out the window, pivoted back to the backend, and decided to conquer local testing. Here is how I brought my Lambda function out of the cloud and tested it on my Ubuntu machine.

The Virtual Environment Battle

Since I had originally written my code directly in the AWS Lambda console ("ClickOps"), my first step was downloading it into a local VS Code folder. I quickly realised my laptop was not AWS.

When I tried to run a simple import boto3 to connect to my database, my Ubuntu machine threw a ModuleNotFoundError. I learned that Linux is incredibly protective of its global Python packages. I couldn't just install the AWS SDK; I had to build a soundproof room for it.

I spent the first chunk of my session installing Python3-venv and activating a virtual environment. It felt like an annoying extra step, but seeing that (venv) pop up in my terminal made me realise my laptop was finally configured like a real developer's workstation.

The Danger of the Real Internet

Once my environment was set up, I ran my test... and got blasted with a massive wall of red error text.

At the very bottom of the traceback, I found the culprit: botocore.exceptions.NoRegionError. Even worse, when I tried to fix it, I accidentally typed us-east-3 (which doesn't exist) and crashed it again!

But this led to a massive "Aha!" moment. Why was my test trying to connect to the internet at all?

I realised that if I ran my local code as it was, it would connect to my real DynamoDB table in AWS and artificially inflate my website's visitor count every single time I ran a test. I needed to cut the cord.

Faking the Cloud (Mocking Boto3)

To protect my live database, I had to learn how to "Mock" AWS.

Using Python's unittest and MagicMock libraries, I wrote a script to intercept Boto3 before my code even loaded. I fed my laptop dummy AWS credentials and a fake region, and then injected a fake database response directly into the system's brain.

Here is the exact code that safely disconnected my tests from the real world:

Python import os import sys import unittest from unittest.mock import MagicMock

os.environ['AWS_DEFAULT_REGION'] = 'us-east-1' os.environ['AWS_ACCESS_KEY_ID'] = 'testing' os.environ['AWS_SECRET_ACCESS_KEY'] = 'testing'

mock_boto3 = MagicMock() sys.modules['boto3'] = mock_boto3

import lambda_function

The Green Light

After hours of battling tracebacks, learning how system paths work, and fixing my us-east-3 typo, I ran my final command: python3 -m unittest test_lambda.py

My terminal returned a single. and OK.

It might not look like much, but that green success message means my code is finally testable, safe, and ready for automation. I am so glad I trusted my gut and pivoted to testing today.

Up Next:

Now that my safety net is firmly in place, I can finally jump into Git, push this to GitHub, and build that CI/CD pipeline. (And yes, I promise I will actually style the frontend soon!)

#AWSCloudResumeChallenge #CloudComputing #DevOps #Debugging #Boto3 #UnitTest #Day13BuildInPublic

The Frontend Fetch

I spent today working in JavaScript, using the fetch() API. It’s a relatively simple block of code, but it does a lot of heavy lifting. It reaches out to my API Gateway URL, waits for the response, and then tells my HTML: "Hey, take this number and put it in that specific spot on the page."

The Deployment "Gotcha"

After I updated my code and uploaded it to S3, I refreshed my site and... nothing changed.

This was a great lesson in CDN Caching. Because my site sits behind CloudFront, the old version of my JavaScript was still saved in the "edge" locations. I had to run a CloudFront Invalidation (/*) to force AWS to dump the old cache and grab my brand-new code from S3.

Proof of Life

Once the invalidation finished, I refreshed the page and saw it: "You are visitor number: 1".

It’s just a small number on a screen, but knowing that number travelled from my browser, through a secure API, triggered a Python script, updated a NoSQL database, and came all the way back is an incredible feeling.

Up Next

The backend is bulletproof, but the UI is currently just plain black text. Now that the logic is working, I’m going to focus on the "Design" phase—using CSS to make this counter look like a professional, integrated part of my resume rather than an afterthought.

#CloudResumeChallenge #FullStack #AWS #JavaScript #S3 #CloudFront #Serverless #Day12BuildInPublic

If Lambda is the "Chef" cooking up the data, API Gateway is the "Waiter" taking the order from the website and handing it to the kitchen.

I decided to go with an HTTP API instead of a traditional REST API for this project. Why? AWS introduced HTTP APIs as a newer, leaner alternative. They are specifically designed for serverless architectures, they are significantly faster, and they are up to 71% cheaper than REST APIs. Since I just need a simple way to trigger a Lambda function, HTTP API was the perfect, cost-effective tool for the job.

Because API Gateway can be notoriously confusing to navigate, I kept my setup process as streamlined as possible:

• Created the API: Spun up a standard HTTP API with auto-deploy enabled.

• Set the Route: Created a simple GET route at /count.

• The Handoff: Attached my Lambda function as the integration target so the API knows exactly what to trigger.

• The Security Guard (CORS): Configured Cross-Origin Resource Sharing (CORS) to allow GET requests. Without this crucial step, web browsers will automatically block the data for security reasons!

After saving the configuration, I took the live Invoke URL, pasted it into my browser, added /count to the end, and hit enter. Seeing my JSON visitor count pop up on a live webpage was incredibly satisfying!

Up Next:

Everything is fully functional. Tomorrow, I just need to plug this API URL into my frontend JavaScript, and the full-stack loop will be complete!

#AWS #APIGateway #Serverless #CloudComputing #DevOps #AWSCloudResumeChallenge #Day11BuildInPublic

Connecting a serverless function to a database sounds straightforward, but I ran into a couple of great real-world debugging scenarios along the way.

Security:

By default, an AWS Lambda function does not have permission to interact with other AWS services. Before running any code, I had to configure an IAM Execution Role and attach the AmazonDynamoDBFullAccess policy. This acts as an ID badge, legally giving my code permission to read and write to my new table.

The Reserved Keyword Trap:

When writing the Boto3 logic to add +1 to my visitor count, my first test threw an error. My table uses the column name count. As it turns out, COUNT is a reserved keyword in DynamoDB's internal system.

Instead of renaming my database setup, I learned a great workaround: using Expression Attribute Names. By setting a placeholder like #c in my update expression and defining it as count later in the code, I was able to safely bypass the reserved word restriction.

Debugging the Stack Trace

My second test failed with a massive wall of error text. Instead of panicking, I read the first line of the stack trace: Unknown parameter in input: "ExpressionAttributeName".

It was a classic syntax typo. Boto3 is incredibly strict, and I had missed the "s" at the end of ExpressionAttributeNames. One single letter was breaking the entire function!

The Result

After fixing the typo, I hit "Test" and finally saw that glorious green Execution result: succeeded box. I navigated over to my DynamoDB console, explored my table items, and saw my visitor count officially sitting at 1.

Up Next

My backend logic is fully working! Tomorrow, the goal is to set up API Gateway to act as the bridge between my frontend JavaScript and this new Lambda function.

#AWS #Lambda #Boto3 #Debugging #CloudResumeChallenge #DevOps #CloudComputing #Day10BuildInPublic

Okay, confession time: making numbers dynamically appear on the frontend using JavaScript was actually pretty fun. But today, I had to officially cross the bridge into the backend.

Instead of rushing straight into writing code, I spent today carefully clicking through the AWS Console to set up my infrastructure and make sure my foundation was solid.

Building the Database DynamoDB

My main task today was creating a place to actually store my visitor count. I navigated to DynamoDB and spun up a new table named visitor_count.

Setting it up was simpler than I thought:

Partition Key: I set this to id (String). DynamoDB requires a unique identifier, so this was mandatory.

Sort Key: I left this completely blank. Since I am literally just storing one simple number, adding a sort key would just overcomplicate the architecture!

Best Practices:

Resource Tagging Before logging off, I made sure to add a simple tag to my table: `Project: CloudResumeChallenge`.

When you are learning cloud computing, billing can be a bit intimidating. Adding Cost Allocation Tags is a great, simple habit to track exactly where your resources are, so you can keep an eye on things without any surprises.

Up Next:

My database is safely provisioned and properly tagged! Tomorrow, I will tackle the actual brain of the operation: writing an AWS Lambda function using Python to open this table, read the count, and add +1.

#AWS #DynamoDB #CloudComputing #DevOps #AWSCloudResumeChallenege #BuildInPublic

It was time to learn about APIs and JSON!

The Goal: Fetching Live Data

Since my AWS database isn't built yet, I used a free, public "dummy API" to test my code. I needed to write a script that could talk to this API and update my website's visitor counter with the fetched data.

What I Learned:

• APIs: The "waiter" that takes my request to the server and brings the data back. I used the fetch() function and async/await to make this happen.

• JSON: The universal text format that the data comes back in. My JavaScript translates this JSON so it can read the numbers inside.

The Roadblock: The Stubborn Zero

I wrote the code, linked the script, and refreshed my browser. But the counter stubbornly stayed at 0. It didn't work. Instead of panicking, I opened up the console, started debugging, and realised I had made a simple typo in my code!

The Big Win:

I corrected the typo, hit save, and refreshed the page. Instantly, the 0 vanished, and live data fetched straight from the dummy API populated my screen. It is an incredibly satisfying feeling to debug your own code and watch it finally execute perfectly.

Up Next:

My front-end code is officially ready to receive data! Tomorrow, the real fun begins: stepping back into the AWS console to build the actual backend (DynamoDB, Lambda, and API Gateway) to replace this dummy API.

#javaScript #API #JSON #AWSCloudResumeChallenge #Debugging #DevOps #BuildInPblic

Before I jump into connecting my front-end HTML to an AWS database for the visitor counter, I knew I needed to strengthen my JavaScript fundamentals. Yesterday was about basic math and the console; today was about understanding how JavaScript actually stores and manipulates data under the hood.

Upgrading My JavaScript Arsenal 🛠️

Here is my technical review of what I mastered today:

Variables, Memory, and Modern Syntax:

I learned that variables hold reusable data in a program and associate it with a specific name, storing it directly in memory. But how you declare them matters:

var: The old-school, pre-ES6 way to declare variables (which I'm avoiding in favour of modern syntax).

let: The preferred way to declare a variable when I know the value will change or be reassigned later (perfect for a visitor count that goes up!).

const: The go-to keyword for declaring a variable with a constant value that should never change.

undefined: The primitive data type that JavaScript assigns to a variable if I declare it but forget to initialise it with a value.

Math & Strings Mathematical Assignment Operators:

Instead of writing out long equations, these operators make it incredibly easy to calculate a new value and immediately assign it back to the same variable.

String Concatenation: Using the + operator to stitch strings together, including string values held inside variables.

Template Literals (ES6): This is an absolute game-changer! Instead of using clumsy + signs, ES6 allows you to use backticks ` and ${} to smoothly interpolate variables directly inside a string. It makes the code so much cleaner to read.

The typeof Keyword:

When data starts flying back and forth between my code and the AWS backend, I need to know exactly what kind of data I'm handling. The typeof keyword is the perfect tool for this—it returns the data type of a value (like telling me if something is a string or a number).

Up Next:

With variables, data types, and template literals locked in, I finally have the foundational vocabulary I need. Tomorrow, my goal is to learn how to write Functions, interact with the DOM to update my HTML, and start looking at the Fetch API so my code can actually talk to the cloud.

#javaScript #AWSCloudComputing #WebDevelopment #DevOps #Day6BuildInPublic