DEV Community: Sanish Chirayath

Deploying a static website with AWS CDK: A Lazy Engineer's Guide

Sanish Chirayath — Sat, 16 Mar 2024 04:45:00 +0000

In this article,we will discuss, how to build the infrastructure on AWS to host a static website with the help of AWS Cloud Development Kit aka AWS-CDK. Previously, I have written a blog post on step by step process to do it with AWS console, If you haven't read it yet, I would highly recommend you read it, check out the blog post .

we will be building the same infrastructure with code now. It would be great if you try to build it first through the console, It will help you understand aws-cdk better. As you know, people forget things, and clicking on 1000s of buttons, and making the website live is a tedious process, and like all "Dev Gods" profess

As a lazy engineer myself, I would rather die automating a mouse click, than clicking the mouse myself or the keyboard, I am on the waiting list of Neuralink, waiting for the GOD ELON to allocate one for me, so that i can code even when i am sleeping! Boosting the productivity 100x for the pennies i get paid. Now, let's get into the meat of the matter.

Setup

Before proceeding to code, we will have to setup our local environment with necessary things.

Setting up AWS CLI - https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html#getting-started-install-instructions
Setting up CDK - https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html

I ain't gonna explain it, Do it yourself, Hit you head sometimes on the table, It will work! , I recommend you use access tokens from AWS to authenticate. you can do it with aws configure commad, I would urge you to leave the region as ''us-east-1" unless you want to debug with super "helpful" error messages from AWS.

Getting started

You are expected to have a website project code on Github, some boilerplate code will do, scaffold any template from here .

Let's start creating the aws-cdk stack.

create a folder and change directory to it.

mkdir cdk-app && cd cdk-app

let's initiate the cdk stack by following command.

cdk init app --language typescript

Let's wait for it to finish, In the mean time

Open your code editor, Let's try to create an SQS Queue and let ourself into the wonderland of aws-cdk. Go to bin/cdk-app.ts and uncomment the following line

  env: { account: process.env.CDK_DEFAULT_ACCOUNT, region: process.env.CDK_DEFAULT_REGION },

Go to lib/cdk-app-stack and uncomment the code related to SQS queue.

As we are trying to build a cdk-stack for the the first time, we need to bootstrapp it, you need to do it for each new region where you want to deploy a stack.

run cdk bootstrap and wait for it to finish.

now run cdk synth command, this will create a cloudformation template corresponding to our cdk code. you find the info regarding the sqs queue within that gibberish, Good luck finding it.

Now run cdk deploy , this command will run cdk synth command and try to push the cloudformation template to our aws account. go to cloudformation section on your console, and you'll see the stack is getting created, also check the sqs queue.

Now you can run cdk destroy , to destroy already create the stack. (It is highly unlikely that we will ever do this on a production application, we will mostly update the existing stack)

Now remove the sqs related code from our stack, let's build the stack for hosting our static website.

you will add following lines to the stack, which we will use to configure our website, we are aiming to deploy sites with subdomains with this aws-cdk code.

    const githubOwner = "your-github-username";
    const githubRepo = "your-github-repo";
    const githubBranch = "your-github-main-branch";
    const mainDomain = "example.com";
    const subDomain = "subdomain";

Creating the S3 buckets

If you have read my previous blog post, you'll know that we need two buckets, one to host our website related files and will get pointed by www domain, and another bucket the for redirecting the requests coming from non www version of our website domain.

Creating the main bucket

within the stack class add the following code.

const websiteBucket = new cdk.aws_s3.Bucket(this, "WebsiteBucket", {
      // we are not adding a bucket name to prevent conflicts in future
      blockPublicAccess: {
        blockPublicAcls: false,
        blockPublicPolicy: false,
        ignorePublicAcls: false,
        restrictPublicBuckets: false,
      },
      autoDeleteObjects: true,
      websiteIndexDocument: "index.html",
      websiteErrorDocument: "index.html",
      publicReadAccess: true,
      /** Make sure you set each field in blockPublicAccess to false or some of it,
      before allowing publicReadAccess, else the deployment will get error,both are
      mutually dependent and the error message is not at all helpful  */
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

As we need our objects to be public we will disable blockPublicAccess, we also need to add a policy for publicReadAccess , we need to mention index document for our website, and we have defined index.html the error document too, so when ever any error occurs, it will just return index.html. If you try to reach any route example.com/about directly, it will end up in error, in order to avoid that i would prefer if you add index.html to be your errorDocument.

we will also set autoDeleteObjects : true , if the stack has to delete the s3 bucket when we destroy that stack, it will have to empty the bucket first. Unless we add these, the cdk destroy , command will throw an error mentioning that the s3 bucket is not empty

Then comes the removal policy, if we try to rename the bucket, a new bucket will get created and the older one will not get deleted. As s3 can store valuable data, you may need to copy that data some where, so it is ideal to not have this option at all. As we are using bucket host a website, and the files are available on git, we can add a removal policy. we don't need to retain the bucket.

Run cdk deploy and create the bucket, It will ask you permission to create resources, policies needed, type y and press enter, you know the drill

Creating the redirect bucket

Add the following code to our stack

const websiteRedirectBucket = new cdk.aws_s3.Bucket(
      this,
      "WebsiteRedirectBucket",
      {
        blockPublicAccess: {
          blockPublicAcls: false,
          blockPublicPolicy: false,
          ignorePublicAcls: false,
          restrictPublicBuckets: false,
        },
        // redirect buckets will have conflict if you set publicReadAccess to true
        websiteRedirect: {
          // add your subdomain and main domain
          // host names should read www.subdomain.example.com
          hostName: `www.${subDomain}.${mainDomain}`,
          protocol: cdk.aws_s3.RedirectProtocol.HTTPS,
        },
        removalPolicy: cdk.RemovalPolicy.DESTROY,
      }
    );

we can define the redirect object, and we specify the address for redirection, we will select HTTPS protocol, If you specify redirect buckets with publicReadAccess : true , It will cause errors while creating the buckets, as both of them have conflicting interests

run cdk deploy to apply the changes

Creating the cloudfront distribution

We cannot let everybody access our s3 directly, as out s3 buckets are sitting in a particular region, the latency will be high for those who access from the other part of the world.

So we will create a cloudfront cdn to distribute our website across the globe. I assume you already have a domain at this point and it is available on Route53 as hosted zone. Make sure to create a public hosted zone.

If you don't have one, create one with the help of internet! once you have hosted zone ready (It might take over 12 hrs to reflect name server changes) . we have 3 things to do.

Get the required hosted zone
create SSL certificates for our www, non-www domains.
add those SSL certificates to the cloudfront

Defining the hosted zone

As our hosted zone is public, we can get the hosted zone with just a lookup, add following code to get the zone details

const hostedZone = cdk.aws_route53.HostedZone.fromLookup(
      this,
      "WebsiteHostedZone",
      {
        domainName: mainDomain,
      }
    );

create SSL certificate for both domains

As we have hosted zone details from lookup, let's create ssl certificate for www and non-www versions of our website, we can define both addresses in a single certificate

const certificate = new cdk.aws_certificatemanager.Certificate(
      this,
      "WebsiteCertificate",
      {
        domainName: `www.${subDomain}.${mainDomain}`,
        subjectAlternativeNames: [`${subDomain}.${mainDomain}`],
        //  validation: CertificateValidation.fromDns(zone),
        validation:
          cdk.aws_certificatemanager.CertificateValidation.fromDnsMultiZone({
            [`${subDomain}.${mainDomain}`]: hostedZone,
            [`www.${subDomain}.${mainDomain}`]: hostedZone,
          }),
      }
    );

we could have used validation: CertificateValidation.fromDns(zone) , but this methods doesn't automatically create dns validations records on route53, we will be forced to do it manually. fromDnsMultiZone method automatically creates the validation records, thus we don't need to do it manually.

Now run cdk deploy , It might take some time, be patient!

Creating the distributions

we need to create distributions to both of our buckets, add the code below to your stack

    // main website distribution
    const distributionForWebsite = new cdk.aws_cloudfront.Distribution(
      this,
      "WebsiteDistribution",
      {
        defaultBehavior: {
          origin: new cdk.aws_cloudfront_origins.S3Origin(websiteBucket),
          viewerProtocolPolicy:
            cdk.aws_cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
        },
        httpVersion: cdk.aws_cloudfront.HttpVersion.HTTP2, // default
        domainNames: [`www.${subDomain}.${mainDomain}`],
        certificate: certificate,
      }
    );

    // redirect distribution
    const distributionForRedirect = new cdk.aws_cloudfront.Distribution(
      this,
      "WebsiteRedirectDistribution",
      {
        defaultBehavior: {
          origin: new cdk.aws_cloudfront_origins.S3Origin(
            websiteRedirectBucket
          ),
          viewerProtocolPolicy:
            cdk.aws_cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
        },
        httpVersion: cdk.aws_cloudfront.HttpVersion.HTTP2, // default
        domainNames: [`${subDomain}.${mainDomain}`],
        certificate: certificate,
      }
    );

We will add s3 origins to both of the buckets, with protocol set to redirect to https , the main distribution will use www address and and will point to main website bucket. and similarly the redirect distribution will use non-www address and will point to redirect bucket.

Users will end up in www version of website, no matter which address they type in the browser, that is why we are keeping both the buckets as well as distributions/

we will also add previously created ssl certificate to both of the distributions.

Now run cdk deploy , It can take several minutes to create the distribution, so please be patient.

Configuring route53 records

we will need to point our www and non-www subdomain to its corresponding distributions, here's how we can do it.

 new cdk.aws_route53.ARecord(this, "WebsiteARecord", {
  zone: hostedZone,
  target: cdk.aws_route53.RecordTarget.fromAlias(
    new cdk.aws_route53_targets.CloudFrontTarget(distributionForWebsite)
  ),
  recordName: `www.${subDomain}`,
});

new cdk.aws_route53.ARecord(this, "WebsiteRedirectARecord", {
  zone: hostedZone,
  target: cdk.aws_route53.RecordTarget.fromAlias(
    new cdk.aws_route53_targets.CloudFrontTarget(distributionForRedirect)
  ),
  recordName: `${subDomain}`,
});

run cdk deploy

Adding Codebuild to the stack

We have to follow 2 steps here

creating a buildspec file
create a codebuild project using that buildspec file

creating a build spec file

I have talked about the build spec file in earlier blog post, so i won't be repeating it here. it is just the replica of the same but with cdk code

add following line to create a buildspec file

 const buildSpecFile = cdk.aws_codebuild.BuildSpec.fromObject({
      version: "0.2",
      phases: {
        install: {
          "runtime-versions": {
            nodejs: 18,
          },
        },
        pre_build: {
          commands: ["npm install"],
        },
        build: {
          commands: [
            "npm run build",
            "aws s3 sync ./dist/ s3://$S3_BUCKET --delete",
          ],
        },
        post_build: {
          commands: [
            "echo 'Build completed successfully'",
            "aws cloudfront create-invalidation --distribution-id $DISTRIBUTION_ID --paths '/*'",
          ],
        },
      },
      artifacts: {
        files: ["**/*"],
      },
    });

Creating the code build project.

Add the following code to the stack

const codeBuild = new cdk.aws_codebuild.Project(this, "codeBuildProject", {
  buildSpec: buildSpecFile,
  environment: {
    buildImage: cdk.aws_codebuild.LinuxBuildImage.STANDARD_7_0,
    environmentVariables: {
      S3_BUCKET: { value: websiteBucket.bucketName },
      DISTRIBUTION_ID: { value: distributionForWebsite.distributionId },
    },
  },

  source: cdk.aws_codebuild.Source.gitHub({
    owner: githubOwner,
    repo: githubRepo,
    webhook: true,
    webhookFilters: [
      cdk.aws_codebuild.FilterGroup.inEventOf(
        cdk.aws_codebuild.EventAction.PUSH
      ).andBranchIs(githubBranch),
    ],
  }),
});

we will add the buildSpecFile we created earlier, now we will choose preferred build image, as our buildspec file is expecting some environment variablesm we will define them, as we already have references to our bucket and distribution in our cdk-code, we can easily pass them, how cool is that!

we will also define the source for our codebuild, we will pass owner, repo, web hook filters is nothing but looking for a push event on the specifiec branch, if the event received matches the criteria, it will trigger a build.

run cdk deploy , you can try running a build from console, it will fail, as we don't have some permissions setup for the codebuild, let's add those.

add following lines to the stack code

    // add put object, delete object permissions to codebuild
    websiteBucket.grantReadWrite(codeBuild);
    websiteBucket.grantDelete(codeBuild);
    // add create invalidation permissions to codebuild
    distributionForWebsite.grantCreateInvalidation(codeBuild);
    distributionForWebsite.grantCreateInvalidation(codeBuild);

as we are deleting the objects from the s3 bucket in the buildspec file, we need to give those permission to code build.

as the post build process we are invalidating the distribution cache, we also need to add permissions for that to the codeBuild resource

run cdk deploy to update the stack with new changes, confirm changes.

Setting up the code pipeline

Add the following code to the website stack. There is twi stages we have to consider. source stage as well as the build stage.

// Code pipeline
const sourceOutput = new cdk.aws_codepipeline.Artifact();
const buildOutput = new cdk.aws_codepipeline.Artifact();

const pipeline = new cdk.aws_codepipeline.Pipeline(
  this,
  "PortfolioPipeline",
  {
    pipelineType: cdk.aws_codepipeline.PipelineType.V2,
    stages: [
      {
        stageName: "Source",
        actions: [
          new cdk.aws_codepipeline_actions.GitHubSourceAction({
            actionName: "GitHub_Source",
            owner: githubOwner,
            repo: githubRepo,
            branch: githubBranch,
            // oauthToken: cdk.SecretValue.unsafePlainText("your-github-token"),
            oauthToken: cdk.SecretValue.secretsManager("my-secrets", {
              jsonField: "github_token",
            }),
            output: sourceOutput,
          }),
        ],
      },
      {
        stageName: "Build",
        actions: [
          new cdk.aws_codepipeline_actions.CodeBuildAction({
            actionName: "CodeBuild",
            project: codeBuild,
            input: sourceOutput,
            outputs: [buildOutput],
          }),
        ],
      },
    ],
  }
);

we will have to define artifacts, each of our stages outputs some data, so that it can pass the data to the next stage. we will create two artifacts for now sourceOutput and buildOutput, it will depend on our application how many artifacts we may need.

then we will create two stages , source stage to fetch data from the repo on changes happens to the mentioned branch, we add necessary parameters. we will authenticate the codepipeline workflow with our personal access token with following permissions

we will add this token to our AWS Secrets manager, we will create a secret called "my-secrets", and add github token as a key, value pair , key github_token and you will add generated token to the value files, you can add many number of key value pairs to this secrets, and you can access it like the following code

cdk.SecretValue.secretsManager("my-secrets", {
              jsonField: "github_token",
        }),

AWS Secret manager is a costly considering it's high availability, encryption, rotation and several other features that make it secure.

It costs around 0.4$ per secret per month, lso it costs 0.05$ per 10,000 requests

It is unsafe to store it as a plain text, anybody who has access to your cloudformation template can see your secrets, that being said if you want to test, you can temporarily use plaintext.

oauthToken: cdk.SecretValue.unsafePlainText("your-github-token")

Under the build stage we will pass the buildOutput artifact, and we will also pass the codeBuild project we created earlier to make code-pipeline know which codebuild project should run.

Let's run cdk deploy , once and for all!

Yay, Our website is now hosted with add the bells and whistles 🥳.

Wrapping up

It has been and interesting project to me. Now i no longer have to click on 1000s of buttons to deploy a new website, just change some variables and host a website in no time. Lot's of time saved.

If you want to destroy the infrastructure you can easily do it with cdk destroy . Life saver! The productivity boost is insane!

We are still deploying things manually, we can setup github actions to run cdk deploy . If you are working in a team, it will be a best practice to create a github workflow for the cdk deploy , so that your peers can review your code before you make any changes to the infrastructure, cause you can break the production if you are not careful! More on it later.

I can't wait to see projects you guys build with this template, You can access the entire cdk code here . If you guys are having any issues do drop them in the comments, i will try my best to answer them.

Do drop your feedbacks and suggestions on blog!

Happy building folks 🛠️

Hosting a static website on AWS S3 with CI/CD

Sanish Chirayath — Mon, 11 Mar 2024 18:26:44 +0000

Getting Started

You are expected to have a AWS account to continue with this tutorial, If you don't have one, create one! It is ideal to create a AdminRole and create projects within that instead of your ROOT account. This playlist from Tiny Technical Tutorials will help you in that.

I believe you have basic understanding git, web technologies!

Now Grab your popcorns and let's start.

Let's Create a Github Repo

If you already have a github repository where you store your website files, you can go ahead with that, else take a spoon and start feeding 😅

run npm create vite@latest aws-app -- --template vanilla-ts on your terminal
now type to terminal cd aws-app and go to the project directory ,now install dependencies npm install , start dev server npm run dev
You web-app should be available at http://localhost:5173/
Now let's push this to Github, Now we are ready to move on to next steps

Uploading files to S3

If you are unfamilar with s3 please go through tutorial series and develop some basic understanding. Simple Storage Service (Amazon S3) is an object storage service that can store almost all types of files. we will be using Amazon S3 to host our static website.

Navigate to the project folder and run npm run build on your terminal.
You should see dist folder getting generated. we will be using these build files for our website.
Navigate to S3 and create the bucket with the domain of your website, we will be using webapp.hstart.in as our domain so we will create a bucket named webapp.hstart.in to differentiate it better, you are free to name it the way you want, go with default options and create bucket
now navigate to S3 bucket and upload your files
Now navigate to properties tab and scroll to bottom to find static website hosting, click on edit, and let's enable it, and save changes

Although we have enabled, static website hosting, because we have blocked all public access during creating a bucket (default option), it cannot be accessed from outside, let's enable all public access.
click on Permissions tab and click on edit to the right of Block public access (bucket settings), uncheck the box, and save changes, confirm the dialog.
Although we have enabled public access, if try to access the object from a browser using objectURL because we haven't attached a public access policy, website will show access denied error,Don't worry we will fix that soon.

Navigate to permissions tab again and click on edit beside the bucket policy and add the following policy, make sure to change the bucket name on your policy, this will allow all the public to get the object/file from s3 bucket you defined.

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

Now you shouldn't be getting Access Denied error that show above, you should be able to access the objects/files from the objectURL of each file, this is what showed up when i tried the objectURL of js file within the dist/assets folder, we can see all the contents inside the js file.

Everything seems to be configured correctly, still, why isn't it showing up as a website, this seems to be of no use. Don't worry, it will get fixed as we add cloudfront, SSL certificate to the mix.

Setting Up the Cloudfront

Cloudfront is the CDN that we are going to distribute out website content across the globe, It will reduce the latency for our users by storing a replica of our website content closer to the users who frequently access our website. Let's navigate to cloudfront, start configuring it.

click on create distribution
In the origin domain input select your s3 Bucket, once you select the bucket it will give the below warning, as we are intend to use it for static website hosting, click on use website endpoint , otherwise hosting will not work properly.
select redirect http to https
Disable Website Application firewall for now
As I intend to use it with a subdomain of my own, I will be adding an SSL certificate, As we do not have a certificate for the subdomain , we will have to create it. Under Settings section, click on Request Certificate link , just below the Custom SSL Certificate Input
It will open AWS CERTIFICATE MANAGER on another window

Make sure the location were you create certificate is US EAST (N. Virginia) Region (us-east-1), The Location will get automatically selected when you naviagte to AWS certificate manager, for some reason it doesn't, select us-east-1 region from the navbar and create the certificate

select request a public certificate and click on next
Add both www and non-www version of your subdomain, leave everything else on default, and click on request certificate
now click on the certificate that is being issued, then click on create records in route 53 , then confirm it, if you do not have a hosted zone in route53, you may need to create it first. Hosted zone is a paid service, it will cost around 0.6$ including tax per month to have one. this is where you set up the domain you have purchased. If you need a tutorial on how to set it up, let me know in the comments.
- Now comeback to our cloudfront tab (remember new tab got opened when we clicked on request certificate), click on refresh button beside the input, then select the certificate you just created.
Additionally you can add Alternate domain name , which is optional, settings section should look like this after you have done with all, keep everything else default, and click on create distribution
Now you'll be able to see your new created distribution
Setup invalidations, we need to invalidate cloudfront cache once changes happen inside our S3 bucket, Navigate to your distribution and click on invalidations tab. click on create invalidation, then add /**/* to the input field, this will trigger invalidations for changes inside the subfolders too. then click on create invalidation.
Now copy the domain name from the distribution and try to access the address from your browser, Viola! your app is live on cloudfront

Setup subdomain

Although we have created certificate for our subdomain an all, route53 still doesn't know where to route the DNS queries coming to http://webapp.hstart.in/ so we need to set it up.

Go to route 53 then navigate to your hosted zone.then click on create record
Add your subdomain, select Record type A as shown in the image, toggle on Alias , Select Alias to cloudfront distribution, then select newly created distribution from the dropdown, then create records
It might take few minutes, our website is now live on webapp.hstart.in , Yay 🎉.

Re-routing www domain request to non www version.

People tend to add www before a web address, if we haven't set up this up, they might get DNS error, as we already have non-www version of our website up, now we will try to route www requests to non-www version of our website.

As we already have a bucket with non-www version we will create a bucket with www version and route the requests to non-www, It is also possible to do it vice versa, it is your choice how to set it up.
let's create a bucket with www.webapp.hstart.in name , as we did the last time
As we did last time navigate to newly created bucket and go to permissions and deselect Block public access (bucket settings) and save changes
we will use this bucket to redirect queries to our main bucket, so we don't need to add any public access policy, nor we need to add any files to this bucket.
Go to properties tab, navigate to static web hosting and click on edit, click on enable, then select Redirect requests for an object, add host name (the domain where we want to redirect requests) then choose https , save the changes
Now go to cloudfront and create a new distribution that points to our newly created S3 Bucket, you can use the SSL certificate that we have created early, as we have added both www and non-www domain name versions of our website to the certificate
once the coludfront distribution is created, go to route 53 and point www.webapp.hstart.in requests to the newly created distribution. same as we did before.

now https://www.webapp.hstart.in/ as well as https://webapp.hstart.in/ will resolve to https://webapp.hstart.in/ , Great! Our website is live and well

CI / CD

How did we start? uploading files to S3, this is definitely not the ideal way to do things, manually building project, uploading files manually to S3 is not a sustainable solution. now we will introduce codebuild, code pipeline to make our deployment process fluid.

Our goal is to use codebuild to build our app and replace the files inside s3 with newly built files whenever we push new changes to our main/master branch. Let's integrate it.

Go to codebuild and click on create project
choose project name of your choice, i chose "webapp"
Select your source provider, I use GitHub to host my code so i select Github, if you haven't connected to github before you may need to connect and authenticate your Github using a personal access token, once you have connected to github you'll be able to select your project repository from the dropdown
add the name of your main/master branch to source version input
when we create this codebuild, a new role will get created for this project. we will attach necessary permissions/policies this particular role. policies gives resources permissions to make changes on other resources. As i already mentioned, codebuild need to modify objects(files) inside our s3 bucket each time a new build happens so that whenever code changes, it will get reflected on our website.

we will be using a buildspec.yml file to handle the build process, so select use a buildspec file. we will add buildspec.yml file to the root of our project

This is how out buildspec.yml file looks like, let's add this to root of our project and push it to github, make sure you change s3 bucket name to your s3 bucket name.

version: 0.2

phases:
  install:
    runtime-versions:
      nodejs: 18 # Change this to match the version of Node.js you're using
  pre_build:
    commands:
      - npm install # Or any other command to install dependencies
  build:
    commands:
      - npm run build # Or any other command to build your static site assets
      - aws s3 sync ./dist/ s3://webapp.hstart.in --delete # Sync static site files to S3 bucket
  post_build:
    commands:
      - echo "Build completed successfully"

artifacts:
  files:
    - '**/*'

keep everything to default and create project

Now go to your codebuild project and create a build. The build will get failed as codebuild don't have necessary permissions to work with. You can read the issues within the build log, we need to proceed accordingly. Don't worry, we will fix it soon.
Navigate to IAM --> roles and find the role that just created by codebuild, you'll see a policy under the role in the permissions tab, click on it.
You'll see code build already created some policies automatically for s3, but some permissions are missing, we also need to specify the s3 object where we stored our website files. It is always be better to specify buckets considering security, give permissions that are needed, nothing more, nothing less
click on s3, then click on Edit , I added Delete Object Put object
Delete Object , List Bucket permissions additionally to the policy, you can use visual editor to make those changes.

add Delete Object , List Bucket permissions they can be found under Write, List sections respectively,

Also under Resources section you need to add the arn of your S3 bucket, also same arn with /* to select all the objects inside. it is better to select JSON editor and add these lines inside the resources object

arn:aws:s3:::webapp.hstart.in
arn:aws:s3:::webapp.hstart.in/*

The final policy should look similar to this, we only added 2 extra permissions in the Action array , 2 lines under resources array, everything else is created by codebuild.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketAcl",
                "logs:CreateLogGroup",
                "logs:PutLogEvents",
                "codebuild:CreateReportGroup",
                "codebuild:CreateReport",
                "s3:PutObject",
                "s3:GetObject",
                "logs:CreateLogStream",
                "codebuild:UpdateReport",
                "codebuild:BatchPutCodeCoverages",
                "s3:DeleteObject",
                "codebuild:BatchPutTestCases",
                "s3:GetBucketLocation",
                "s3:GetObjectVersion"
            ],
            "Resource": [
                "arn:aws:codebuild:ap-south-1:343391345253:report-group/webapp-*",
                "arn:aws:logs:ap-south-1:343391345253:log-group:/aws/codebuild/webapp",
                "arn:aws:logs:ap-south-1:343391345253:log-group:/aws/codebuild/webapp:*",
                "arn:aws:s3:::codepipeline-ap-south-1-*",
                "arn:aws:s3:::webapp.hstart.in",
                "arn:aws:s3:::webapp.hstart.in/*"
            ]
        }
    ]
}

Once we are satisfied with policy, click on next , then click on save changes , make sure that the policies are saved properly.

Now navigate to codebuild and retry build, it should be successful now

Now we can create build, with a click on a button, we still need to login to AWS, navigate to codebuild, and click on start build to release a new version of our website, we are too lazy for that. Let integrate codepipeline, and automate the codebuild process whenever we push to our main/master branch.

Setting up code pipeline

Navigate to code pipeline, click on create pipeline , we will choose v2 as we can create as many pipeline as we need without incuring additional cost. Also it will automatically create a new role so that we can add permissions later if needed. Once everything good click on next

Here you will need to connect to github, click on connect to github, give it a name, click on install github app, allow permissions from github, it is pretty straight forward, you should be able to do it. If you are stuck at this, do let me know. once the connection is successfully established you should see following screen
Now specify a trigger to start a build pipeline, we will set it to on push to our main branch, now click on next
Now we need to connect our code pipeline to the codebuild project we set up earlier, select AWS codebuild as our build provider, then select the project we created. If you have any Environment variables, that are being used in the project, you can add them at this step, you can add add them later too as you need. Once everything is good, click on next.
We can skip the deploy stage by clicking on the skip deploy stage button as we don't need it for our project.
Then click on create pipeline to finish creating the pipeline
If everything went well, you should see succeeded message, you can click on release change to release a new change.

Now our CI/CD pipeline is finally ready, if you push changes to your main branch and the changes will get reflected on the website. Try making changes.

Extras

While I was working on this, I noticed the cloudfront cache is not getting invalidated somehow, So I decided to force the invalidation in the post build process, new buildspec.yml file is as follows

version: 0.2

phases:
  install:
    runtime-versions:
      nodejs: 18 # Change this to match the version of Node.js you're using
  pre_build:
    commands:
      - npm install # Or any other command to install dependencies
  build:
    commands:
      - npm run build # Or any other command to build your static site assets
      - aws s3 sync ./dist/ s3://webapp.hstart.in --delete # Sync static site files to S3 bucket
  post_build:
    commands:
      - echo "Build completed successfully"
      - aws cloudfront create-invalidation --distribution-id ET5XFZER5THY --paths '/*' #invalidate the given cloudfront distribution

artifacts:
  files:
    - "**/*"

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketAcl",
                "logs:CreateLogGroup",
                "logs:PutLogEvents",
                "cloudfront:CreateInvalidation",
                "codebuild:CreateReportGroup",
                "codebuild:CreateReport",
                "s3:PutObject",
                "s3:GetObject",
                "logs:CreateLogStream",
                "codebuild:UpdateReport",
                "codebuild:BatchPutCodeCoverages",
                "s3:DeleteObject",
                "codebuild:BatchPutTestCases",
                "s3:GetBucketLocation",
                "s3:GetObjectVersion"
            ],
            "Resource": [
                "arn:aws:codebuild:ap-south-1:343391345253:report-group/webapp-*",
                "arn:aws:logs:ap-south-1:343391345253:log-group:/aws/codebuild/webapp",
                "arn:aws:logs:ap-south-1:343391345253:log-group:/aws/codebuild/webapp:*",
                "arn:aws:cloudfront::343391345253:distribution/ET5XFZER5THY",
                "arn:aws:s3:::webapp.hstart.in/*",
                "arn:aws:s3:::codepipeline-ap-south-1-*",
                "arn:aws:s3:::webapp.hstart.in"
            ]
        }
    ]
}

I just added "cloudfront:CreateInvalidation" permission to Action array, also added "arn:aws:cloudfront::343391345253:distribution/ET5XFZER5THY" to the resources object. Which is nothing but the resource arn for our cloudfront distribution.

Now every-time we release a change, codebuild will invalidate the cloudfront cache automatically, and we will be able to see latest website!

hardcoding your bucket name and distribution id isn't a good practice we can move those in to environment variables, new buildspec.yml file will look like this

version: 0.2

phases:
  install:
    runtime-versions:
      nodejs: 18 # Change this to match the version of Node.js you're using
  pre_build:
    commands:
      - npm install # Or any other command to install dependencies
  build:
    commands:
      - npm run build # Or any other command to build your static site assets
      - aws s3 sync ./dist/ s3://$S3_BUCKET --delete # Sync static site files to S3 bucket
  post_build:
    commands:
      - echo "Build completed successfully"
      - aws cloudfront create-invalidation --distribution-id $DISTRIBUTION_ID --paths '/*' #invalidate the given cloudfront distribution

artifacts:
  files:
    - "**/*"

we have two variables S3_BUCKET and DISTRIBUTION_ID let's define those in code build.

Navigate to codebuild, select our project "webapp" and click on edit, go to the section Environment and click on Additional configuration add your environment variables

click on update project, we are good to go!

End Notes

I hope this article has been helpful for you guys.

There are more things to add like building and testing the code when a pull request is raised. To reduce the amount bugs gets into production, that's for another day.

If you guys have any doubts, feedbacks feel free to drop in the comments. Happy building 😊