{"id":381,"date":"2026-10-09T18:19:47","date_gmt":"2026-10-09T22:19:47","guid":{"rendered":"https:\/\/securebydefault.io\/blog\/?p=381"},"modified":"2026-10-09T19:15:57","modified_gmt":"2026-10-09T23:15:57","slug":"import-existing-aws-infrastructure-terraform","status":"publish","type":"post","link":"https:\/\/securebydefault.io\/blog\/import-existing-aws-infrastructure-terraform\/","title":{"rendered":"Importing My Cloud Resume into Terraform Without Taking the Site Down"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

What broke, what I found, and the three things I deleted<\/em><\/p>\n\n\n\n

My portfolio site has been running on AWS for a while now: S3, CloudFront, Route 53, plus a small serverless backend (Lambda, API Gateway, DynamoDB) that counts visitors. The backend was built with SAM. The rest was a mix of console clicking and good intentions. It works, but if you asked me to rebuild it from scratch tomorrow, I would be doing a lot of remembering and a lot of squinting at the console.<\/p>\n\n\n\n

So I put the whole thing into Terraform. Not a fresh copy sitting next to the old one, but the actual live infrastructure, imported into state, with no downtime. This post covers how that went, the errors I hit (several were my own fault), and the part I did not expect: I found things in my own AWS account that I never put there on purpose.<\/p>\n\n\n\n

Who this is for<\/strong><\/p>\n\n\n\n

\n\n\n\n

This is not<\/strong> <\/mark>a from-scratch Cloud Resume Challenge tutorial. It is about bringing existing, live AWS infrastructure under Terraform management without rebuilding it.<\/p>\n\n\n\n

You will get the most out of it if you have:<\/p>\n\n\n\n

    \n
  • Basic AWS familiarity (you know what S3, Lambda and IAM are)<\/li>\n\n\n\n
  • The AWS CLI installed and configured<\/li>\n\n\n\n
  • Terraform installed<\/li>\n\n\n\n
  • Some existing AWS infrastructure you would like to manage with Terraform<\/li>\n\n\n\n
  • Git<\/li>\n\n\n\n
  • Enough comfort reading a terraform plan to spot the word “destroy”<\/li>\n<\/ul>\n\n\n\n

    Project repositories<\/p>\n\n\n\n

    \n \n \n \n \n \n \n \n
    \n Repo\n <\/th>\n \n What it holds\n <\/th>\n <\/tr>\n <\/thead>\n\n
    \n \n terraform-cloud-resume\n <\/a>\n <\/td>\n \n The main repo for this post: Terraform for the infrastructure configuration\n <\/td>\n <\/tr>\n\n
    \n \n cloud-resume-backend\n <\/a>\n <\/td>\n \n Lambda code, SAM template and the backend GitHub Actions pipeline\n <\/td>\n <\/tr>\n\n
    \n \n AWS-S3-Static-Website\n <\/a>\n <\/td>\n \n The website files and the frontend GitHub Actions pipeline\n <\/td>\n <\/tr>\n <\/tbody>\n <\/table>\n<\/div>\n\n\n\n

    <\/p>\n\n\n\n

    What is actually deployed<\/strong><\/p>\n\n\n\n

    \"architecture<\/figure>\n\n\n\n

    Visitors reach the site through Route 53 and CloudFront, which pulls from S3. The browser then calls API Gateway, which invokes Lambda, which reads and writes DynamoDB.<\/p>\n\n\n\n

    One thing I want to be clear about, because it is easy to get wrong: Terraform does not own everything here.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n
      \n
    • Terraform<\/strong> <\/mark>owns the infrastructure configuration: the DynamoDB table, IAM role, Lambda function settings, API Gateway, S3 bucket settings, CloudFront and the Route 53 records.<\/li>\n\n\n\n
    • SAM and GitHub Actions<\/mark><\/strong> (backend repo) own the Lambda application code.<\/li>\n\n\n\n
    • GitHub Actions<\/mark><\/strong> (frontend repo) owns the website files in the bucket.<\/li>\n<\/ul>\n\n\n\n

      The SAM-created CloudFormation stack (portfolio-app) still exists and still tracks some of these resources. I come back to that at the end, because it is an open item and not a solved one.<\/p>\n\n\n\n

      The rule: import first, improve second<\/strong><\/p>\n\n\n\n

      Importing live infrastructure is a bit like changing a tire on a moving car, except the car is your resume. So I stuck to one workflow for every single resource:<\/p>\n\n\n\n

        \n
      1. Look at the real thing with the AWS CLI (describe-table, get-function, and friends).<\/li>\n\n\n\n
      2. Write Terraform that matches it.<\/li>\n\n\n\n
      3. Run terraform import.<\/li>\n\n\n\n
      4. Run terraform plan, and touch nothing until it says “No changes” or shows a difference I fully understand.<\/li>\n<\/ol>\n\n\n\n

        Only after a resource is clean do I change anything on purpose. That way every improvement shows up as its own small, readable diff instead of being buried inside the import.<\/p>\n\n\n\n

        What terraform import actually does<\/strong><\/p>\n\n\n\n

        If you have not used it before, here is the part that trips people up: terraform import does not<\/strong> write any configuration for you. It does not change the AWS resource either. All it does is record in Terraform’s state that “this resource address in my code is that real thing in AWS.” You still write the configuration yourself.<\/p>\n\n\n\n

        \"\"<\/figure>\n\n\n\n

        That is why the plan afterward matters so much. The plan compares the configuration you wrote against the real resource. If they match, you get “No changes” and a clean baseline. If they do not, Terraform tells you exactly where.<\/p>\n\n\n\n

        During the import phase, if the first plan shows an unexpected difference, make the Terraform configuration match the existing live resource until you have a clean baseline. Make intentional infrastructure changes only after that.<\/p>\n\n\n\n

        Walkthrough 1: the DynamoDB table (the warm-up)<\/strong><\/p>\n\n\n\n

        Find the real thing:<\/mark><\/strong><\/p>\n\n\n\n