Forem: Grit Coding

Hosting a Static Website on S3 Bucket with CloudFront and a Custom Domain Using Terraform

Grit Coding — Mon, 15 Jul 2024 17:22:16 +0000

In this post, I will guide you on how to host a static website on an S3 Bucket with CloudFront and a custom domain using Terraform.

Before we start, I recommend watching this video to see how it's done in the AWS console:

The above diagram illustrates the architecture we will create.

Now, let's create the same setup using Terraform.

This diagram is similar to the one we created in the AWS console, but the resources with the Terraform sticker will be created and configured using Terraform.

Prerequisites

Ensure you have the following installed and configured:

The Terraform CLI (1.2.0+).
The AWS CLI.
An AWS account and credentials with sufficient permissions

Start by setting up your AWS credentials. Export the following environment variables with your actual AWS credentials:

export AWS_ACCESS_KEY_ID=yourAccessKeyID
export AWS_SECRET_ACCESS_KEY=yourSecretAccessKey
export AWS_DEFAULT_REGION=yourAWSRegion

In the root directory, we will create two files:

- custom.tfvars
- main.tf

Since we are using a custom domain, we need the hosted zone ID from Route 53. You can expand the hosted zone details and copy the zone ID.

In the custom.tfvars, add your Route 53 zone ID and domain name as shown below:

# Deployment environment, e.g., dev, qa, or prod
environment = "dev"

# Landing page domain
domain = "example.com"

# Route 53 Hosted Zone ID
route53_zone_id = "Z123ABCDEF01234567"

Next, create the main.tf file. Ensure you change the bucket name to something globally unique. I'll add comments to explain the code.

provider "aws" {
  region = "us-east-1"
}

// Variable values from custom.tfvars
variable "environment" {
  description = "The deployment environment (e.g., dev, qa, prod)"
  type        = string
}

variable "domain" {
    description = "Landing page domain"
    type = string
}

variable "route53_zone_id" {
    description = " Hosted Zone ID for the domain"
    type = string
}

variable "region" {
  description = "AWS region for the resources"
  default     = "us-east-1"
}

// Create static-site hosting bucket
resource "aws_s3_bucket" "landing_page_bucket" {
  bucket = "landing-page-hosint-example-04-may-2024-${var.environment}"

  tags = {
    Name        = "landing-page"
    Environment = var.environment
  }
}

// allow public access
resource "aws_s3_bucket_public_access_block" "landing_page_public_access" {
  bucket = aws_s3_bucket.landing_page_bucket.id

  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

//enable static-site hosting
resource "aws_s3_bucket_website_configuration" "static_site" {
  bucket = aws_s3_bucket.landing_page_bucket.id

  index_document {
    suffix = "index.html"
  }

  error_document {
    key = "error.html"
  }
}

//add bucket policy
resource "aws_s3_bucket_policy" "landing_page_bucket_policy" {
  bucket = aws_s3_bucket.landing_page_bucket.id

  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowGetObj",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::${aws_s3_bucket.landing_page_bucket.id}/*"
    }
  ]
}
POLICY
}




// Create SSL certificate
resource "aws_acm_certificate" "ssl_cert" {
  domain_name       = var.domain
  validation_method = "DNS"

  tags = {
    Name        = "landing-page"
    Environment = var.environment
  }

  lifecycle {
    create_before_destroy = true
  }
}

//create route53 record
resource "aws_route53_record" "ssl_cert_validation_records" {
  for_each = {
    for dvo in aws_acm_certificate.ssl_cert.domain_validation_options : dvo.domain_name => {
      name   = dvo.resource_record_name
      record = dvo.resource_record_value
      type   = dvo.resource_record_type
    }
  }

  allow_overwrite = true
  name            = each.value.name
  records         = [each.value.record]
  ttl             = 60
  type            = each.value.type
  zone_id         = var.route53_zone_id
}

locals {
  s3_origin_id = "landing-page-access"
}

resource "aws_cloudfront_distribution" "static_site_distribution" {
  origin {
    domain_name = "${aws_s3_bucket.landing_page_bucket.bucket}.s3-website-${var.region}.amazonaws.com" // static site domain name
    origin_id   = local.s3_origin_id

    // The custom_origin_config is for the website endpoint settings configured via the AWS Console.
    // https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomOriginConfig.html
    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "http-only"
      origin_ssl_protocols   = ["SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2"]
      origin_read_timeout = 30
      origin_keepalive_timeout = 5
    }
    connection_attempts = 3
    connection_timeout = 10
  }

  enabled             = true
  comment             = var.domain
  default_root_object = "index.html"

  aliases = [var.domain]

  default_cache_behavior {
    allowed_methods  = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = local.s3_origin_id

    forwarded_values {
      query_string = false

      cookies {
        forward = "none"
      }
    }

    viewer_protocol_policy = "redirect-to-https"
    min_ttl                = 0
    default_ttl            = 3600
    max_ttl                = 86400
    compress = true
  }

  price_class = "PriceClass_All"

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  tags = {
    Environment = var.environment
  }

  // The viewer_certificate is for ssl certificate settings configured via the AWS Console.
  viewer_certificate {
    cloudfront_default_certificate = false
    ssl_support_method  = "sni-only"
    acm_certificate_arn = aws_acm_certificate.ssl_cert.arn
    minimum_protocol_version = "TLSv1.2_2021"
  }
}

resource "aws_route53_record" "landing_page_A_record" {
  zone_id = var.route53_zone_id
  name    = var.domain
  type    = "A"

  alias {
    name                   = aws_cloudfront_distribution.static_site_distribution.domain_name
    zone_id                = "Z2FDTNDATAQYW2" // cloudfront distribution ID https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-route53-recordset-aliastarget.html
    evaluate_target_health = false
  }
}

Deploy and Test

Execute the following commands in your project directory to deploy your Terraform configuration:

terraform init
terraform plan
terraform apply -var-file="custom.tfvars"

⭐️ Go to the AWS console and upload the index.html file. If you access the URL you specified, you will see your static site hosted.

For the cleanup process, check the README for this repository.

Thanks for reading! :)

Authored by Narae Souttar

Customising Content Delivery with AWS CloudFront: Routing with Origin Request Policies and CloudFront Functions

Grit Coding — Thu, 18 Apr 2024 19:33:37 +0000

While studying for the AWS SysOps Administrator certification exam, I discovered an interesting feature in AWS CloudFront that allows serving different objects based on cookies or HTTP request headers specified through the origin request policy. This concept intrigued me, but it didn’t truly resonate until I began experimenting with it myself. In today’s blog post, I will share a step-by-step guide on how to set this up by forwarding the value of request headers. To enhance clarity, I'll conclude with a visual demonstration directly from the AWS console.

This post is intended for readers with existing knowledge of AWS.

Prerequisites

Knowledge of S3 Buckets & Policies
Understanding of how to set up a CloudFront Distribution with S3

By creating a CloudFront distribution as shown above, you can access https://d3h4a6v5efbkjq.cloud.net/index.html directly, leads you to index.html without any prefix.

We will forward the Accept-Language header, and the CloudFront function will then redirect based on this value. For example, if the Accept-Language value is English, the user will be redirected to /en/index.html.

Create S3 Bucket and Upload Files

Navigate to S3 from the AWS console and create a new bucket.
Set up your project files as follows:
Root directory: index.html
Korean version: /kr/index.html
English version: /en/index.html

<!-- Root index.html -->
<!DOCTYPE html>
<html>
<head>
    <title>gritcoding</title>
    <meta charset="UTF-8">
</head>
<body>
    <h1>gritcoding</h1>
</body>
</html>

<!-- /kr/index.html -->
<!DOCTYPE html>
<html>
<head>
    <title>한국어</title>
    <meta charset="UTF-8">
</head>
<body>
    <h1>안녕</h1>
</body>
</html>

<!-- /en/index.html -->
<!DOCTYPE html>
<html>
<head>
    <title>English</title>
    <meta charset="UTF-8">
</head>
<body>
    <h1>hi</h1>
</body>
</html>

Once uploaded, you will be able see index.html, /en/index.html, /kr/index.html objects in the bucket.

Create CloudFront Function and Deploy

Navigate to CloudFront and crate a new function.

Update the function using the code below.

function handler(event) {
    const request = event.request;
    const headers = request.headers;

    // Check for English language in Accept-Language header
    const langHeader = headers['accept-language'];
    if (langHeader && langHeader.value.indexOf('en') !== -1) {
        // Route to English version of the content
        request.uri = '/en' + request.uri;
    } else {
        // Route to Korean version of the content
        request.uri = '/kr' + request.uri;
    }

    return request;
}

Now, you can test this function in the test tab. Use the following steps to simulate a request.

Scroll down to the Add header button and click it.
Enter accept-language as the header key.
Add en-GB as the header value.
Click the Test function button located above. If the test is successful, you should see that it returns /en/index.html as shown in the screenshot below.

Create CloudFront Origin Request Policy

Navigate to CloudFront/Policies/Origin request as shown in the screenshot below.

Name the policy, select include the following headers in the Headers dropdown, and choose the Accept-Language header.

Once the origin request policy is created, proceed to create a distribution.

Create CloudFront Distribution

Navigate to CloudFront and click the create distribution button. Select the bucket you created as the Origin domain.
Then, scroll down to the Cache key and origin requests section, select the origin request policy you created, and set the viewer request function type to CloudFront functions to select the function we created.

Update S3 Bucket Policy

Navigate back to your S3 bucket and update the bucket policy.
Use the following JSON code to update it, ensuring you replace S3 bucket name, Your AWS Account Number, and CloudFront distribution ID with the actual values specific to your setup.

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "AllowCloudFrontServicePrincipalReadWrite",
        "Effect": "Allow",
        "Principal": {
            "Service": "cloudfront.amazonaws.com"
        },
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::<S3 bucket name>/*",
        "Condition": {
            "StringEquals": {
                "AWS:SourceArn": "arn:aws:cloudfront::<Your AWS Account Number>:distribution/<CloudFront distribution ID>"
            }
        }
    }
}

After updating the policy, copy the CloudFront distribution domain name and paste it into your web browser followed by /index.html. Depending on the Accept-Language header in your request, this setup will either direct you to /en/index.html if English is detected, or /kr/index.html for all other languages.

In this setup, direct access to the index.html with the gritcoding message is not available, as the CloudFront distribution has been configured to redirect based on language settings.

Learn more:

Watch the step-by-step video guide on setting up and testing this configuration on our YouTube channel linked below.

Thanks for reading. :)

Authored by Narae Souttar

Building Infrastructure from Scratch: Creating Public Subnets in AWS

Grit Coding — Tue, 26 Mar 2024 18:01:14 +0000

In our previous guide, we explored how to create a VPC using Terraform. Now, let's dive deeper into AWS by creating public subnets using Terraform. Our focus will be on understanding the function of individual AWS resources rather than the syntax of Terraform.

By the end of this tutorial, you will have set up the following components in your AWS account:

VPC
Internet Gateway (IGW)
Route Tables
Subnets
IAM Role
Security Groups (SG)
EC2 Instances

Prerequisites

Make sure you have the following installed and configured:

The Terraform CLI (1.2.0+).
The AWS CLI.
An AWS account and credentials with sufficient permissions

Begin by setting up your AWS credentials. Export the following environment variables with your actual AWS credentials:

export AWS_ACCESS_KEY_ID=yourAccessKeyID
export AWS_SECRET_ACCESS_KEY=yourSecretAccessKey
export AWS_DEFAULT_REGION=yourAWSRegion

Next, create a variables.tf file in your project directory and add the following:

variable "aws_region" {
  type    = string
  default = "us-east-1"
}

variable "vpc_name" {
  type    = string
  default = "my_vpc"
}

variable "environment" {
  description = "The deployment environment (e.g., dev, qa, prod)"
  type        = string

  validation {
    condition     = contains(["dev", "qa", "prod"], var.environment)
    error_message = "The environment must be one of: dev, qa, or prod."
  }
}

variable "env_cidr_map" {
  description = "Map of environment names to CIDR block second octet"
  type        = map(string)
  default = {
    "dev"     = "0"
    "qa"      = "10"
    "prod"    = "20"
  }
}

variable "public_subnets" {
  default = {
    "public_subnet_1" = 1
    "public_subnet_2" = 2
    "public_subnet_3" = 3
  }
}

Also, create a main.tf file in the same directory with this initial content:

provider "aws" {
  region = "us-east-1"
}

data "aws_availability_zones" "available" {}
data "aws_region" "current" {}

Create Public Subnets

Now, let's create the infrastructure as depicted in the above chart. Make sure to add the code examples to your main.tf file.

VPC Creation

Configure the VPC with a specific IPv4 CIDR block based on the environment variable. For example, if you choose dev as the environment, the IPv4 CIDR block will be 10.0.0.0/16.
Refer to our previous post for more details on VPC creation.

resource "aws_vpc" "vpc" {
  cidr_block = "10.${lookup(var.env_cidr_map, var.environment, "0")}.0.0/16"
  assign_generated_ipv6_cidr_block = true

  tags = {
    Name        = var.vpc_name
    Environment = var.environment
    Terraform   = "true"
  }
}

Default NACL

A Network Access Control List (NACL) is automatically created with the VPC.

Internet Gateway

Establish an Internet Gateway to allow internet access to the VPC.

resource "aws_internet_gateway" "internet_gateway" {
  vpc_id = aws_vpc.vpc.id
  tags = {
    Name = "grit_coding_igw"
  }
}

Subnets

Create a subnet in each of the three Availability Zones (AZs). Subnets will use the default NACL automatically. For custom NACL applications, you can modify NACL associations.

resource "aws_subnet" "public_subnets" {
  for_each                = var.public_subnets
  vpc_id                  = aws_vpc.vpc.id
  cidr_block              = cidrsubnet(aws_vpc.vpc.cidr_block, 8, each.value)
  availability_zone       = tolist(data.aws_availability_zones.available.names)[each.value]
  map_public_ip_on_launch = true
  assign_ipv6_address_on_creation = true
  ipv6_cidr_block               = cidrsubnet(aws_vpc.vpc.ipv6_cidr_block, 8, each.value)

  tags = {
    Name      = each.key
    Terraform = "true"
  }
}

Route Table

After creating the route table, add a route to the Internet Gateway. Subnets linked to this route table with the IGW route are defined as public subnets, facilitating access to and from the internet.

resource "aws_route_table" "public_route_table" {
  vpc_id = aws_vpc.vpc.id

  route {
    cidr_block     = "0.0.0.0/0"
    gateway_id     = aws_internet_gateway.internet_gateway.id
  }

  route {
    ipv6_cidr_block = "::/0"
    gateway_id      = aws_internet_gateway.internet_gateway.id
  }

  tags = {
    Name      = "grit_coding_public_rtb"
    Terraform = "true"
  }
}


resource "aws_route_table_association" "public" {
  depends_on     = [aws_subnet.public_subnets]
  route_table_id = aws_route_table.public_route_table.id
  for_each       = aws_subnet.public_subnets
  subnet_id      = each.value.id
}

With the public subnets in place, let’s add a few more resources to test the public subnet connection. We will need IAM Role, a Security Group, and EC2 instances.

IAM Role with AmazonSSMManagedInstanceCore

This role, when attached to an EC2 instance, provides the specified permissions. The AmazonSSMManagedInstanceCore policy is necessary for access via the session manager, which is part of the AWS Systems Manager.

resource "aws_iam_role" "ec2_ssm_role" {
  name = "ec2-ssm-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = "sts:AssumeRole",
        Effect = "Allow",
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })

  tags = {
    Terraform = "true"
  }
}
resource "aws_iam_role_policy_attachment" "ssm_managed_instance_core" {
  role       = aws_iam_role.ec2_ssm_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

resource "aws_iam_instance_profile" "ec2_ssm_instance_profile" {
  name = "ec2-ssm-instance-profile"
  role = aws_iam_role.ec2_ssm_role.name
}

Alternative Option: If you prefer using a key pair for EC2 access, create one in the AWS console, then specify its ID when creating the EC2 instance. Make sure to add an ingress rule for SSH (port 22) to the security group if you choose this method.

Security Group

We'll set up a security group with only egress rules. Ingress rules are not required since we are using the Systems Manager.

resource "aws_security_group" "ec2_sg" {
  name        = "EC2_Instance_SG"
  description = "Security group for EC2 instances with default outbound rules"
  vpc_id      = aws_vpc.vpc.id
}

resource "aws_security_group_rule" "ec2_sg_egress_rule" {
  type              = "egress"
  to_port           = 0
  protocol          = "-1"
  from_port         = 0
  cidr_blocks       = ["0.0.0.0/0"]
  ipv6_cidr_blocks  = ["::/0"]
  security_group_id = aws_security_group.ec2_sg.id
}

EC2 Instance Creation

Create EC2 instances in each public subnet, attaching the security group and IAM role.

resource "aws_instance" "public_instance" {
  for_each                    = aws_subnet.public_subnets
  ami                         = "ami-0c101f26f147fa7fd"
  instance_type               = "t2.micro"
  subnet_id                   = each.value.id
  associate_public_ip_address = true
  vpc_security_group_ids      = [aws_security_group.ec2_sg.id]
  iam_instance_profile        = aws_iam_instance_profile.ec2_ssm_instance_profile.name

  tags = {
    Name      = "Public_Instance_${each.key}"
    Terraform = "true"
  }
}

Deploy and Test

Execute the following commands in your project directory to deploy your Terraform configuration.

terraform init
terraform apply -auto-approve

Enter dev as the environment value.

Connect to the EC2 instance using Session Manager. Run the following commands to retrieve the ID of the connected EC2 instance. You can find more information about the Session Manager in this post.

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id

Wrap-up

Today, we successfully set up public subnets and an EC2 instance, demonstrating how Infrastructure as Code (IaC) can make infrastructure deployment efficient, repeatable, and scalable.

For those new to cloud technology, these concepts can initially seem complex. However, I've found that hands-on experience, such as replicating these setups in the AWS console, makes learning more intuitive.

For further guidance, please watch the below demo video, which provides a manual walkthrough of the same setup in the AWS console.

You can find the source code from today's session in my GitHub Repository.

Note
If you're just beginning or not yet familiar with AWS terminology and concepts, consider looking into the AWS Cloud Practitioner certification. It provides comprehensive and clear insights into cloud concepts, making it an excellent starting point for beginners.

Authored by Narae Souttar

Building Infrastructure from Scratch: Creating a VPC with Terraform

Grit Coding — Wed, 13 Mar 2024 22:37:15 +0000

Embarking on a journey to build cloud infrastructure from scratch can be both exciting and daunting. In this series, we focus on leveraging Infrastructure as Code (IaC) tools like Terraform to set up essential components in the cloud. To start, let's set up a Virtual Private Cloud (VPC) in AWS using Terraform.

Prerequisites

Before we start, you'll need to have a few tools and access ready:

The Terraform CLI (1.2.0+).
The AWS CLI.
AWS account and associated credentials with permissions to create resources.

Step1: Crafting the `main.tf` File

Our first step is to create a main.tf file. This file will serve as the foundation of our Terraform configuration. Here’s a breakdown of each section in the script:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"  // Specifies the provider source, here it's AWS provided by HashiCorp.
      version = "~> 4.16"        
    }
  }

  required_version = ">= 1.2.0"   // Ensures that Terraform version 1.2.0 or higher is used.
}

provider "aws" {
  region  = "us-east-1"            // Sets the AWS region where the resources will be created. This can be changed as needed.
}

variable "environment" {
  description = "The deployment environment (e.g., dev, qa, prod)"
  type        = string             // Defines a string variable for the deployment environment.

  validation {
    condition     = contains(["dev", "qa", "prod"], var.environment)
    error_message = "The environment must be one of: dev, qa, or prod."  // Validates the environment variable value.
  }
}

variable "env_cidr_map" {
  description = "Map of environment names to CIDR block second octet"
  type        = map(string)        // Defines a map variable, mapping environment names to parts of the CIDR block.
  default = {
    "dev"     = "0"
    "qa"      = "10"
    "prod"    = "20"
  }
}

resource "aws_vpc" "main" {
  cidr_block = "10.${lookup(var.env_cidr_map, var.environment, "0")}.0.0/16" // Sets the VPC CIDR block dynamically based on the environment. 
  // check the 'Learn More' section for details.
  assign_generated_ipv6_cidr_block = true  // Enables the assignment of an IPv6 CIDR block to the VPC.
}

Step 2: Deploying AWS VPC

In this section, we'll walk through the steps to deploy your AWS VPC using Terraform.

Initialise Terraform

terraform init

Apply the Terraform Configuration

terraform apply

We have set a custom condition for the environment variable. If you provide a value that is not specified in the contains function, an error message will be triggered.

Let's enter dev, and then confirm the action by typing yes.

Verify VPC Creation

Once you receive the completion message, refresh the VPC section in the AWS console to check if a new VPC has been created.

As you can see, the CIDR block for IPv4 is 10.0.0.0/16 which is mapped correctly with the environment value dev in the lookup function.

Clean Up Resources

terraform destroy

Learn More

For those who prefer hands-on learning, you can fork and explore the source code from this repository: GitHub.

If you found this guide or the repository useful, a star or a reaction would be much appreciated.😄

For further reading on AWS & Terraform documentation, refer to:

Authored by Narae Souttar

Creating S3 Buckets using CloudFormation via AWS CLI

Grit Coding — Fri, 01 Mar 2024 23:21:21 +0000

Whether you're setting up a new stack using CloudFormation or trying to decipher an existing stack, understanding CloudFormation syntax is crucial for building, updating, and maintaining AWS resources effectively. In this tutorial, we'll learn by doing. We're going to create two S3 buckets using CloudFormation through the AWS-CLI.

Prerequisites

Before diving into this tutorial, ensure you have the following prerequisites in place:

AWS CLI installed on your machine.
AWS credentials configured with the necessary permissions.

Understanding the Process Flow

The flow chart above outlines our process:

We start by creating an S3 bucket to store our CloudFormation templates.
Next, we create an aggregated CloudFormation template.
Finally, we deploy a stack with two nested stacks, each creating an S3 bucket.

Step 1: Create an S3 Bucket and Prepare the Template

First, we'll create an S3 bucket that will store our CloudFormation templates. Execute the following command, replacing and with your unique bucket name and desired AWS region, respectively. Remember, S3 bucket names must be globally unique.

aws s3 mb s3://<your-bucket-name> --region <your-region>

After creating the S3 bucket, set up your project directory with main.json and S3Template.json files.

S3Template.json (Nested Stack Template)

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "S3 bucket template", // Description of what this template does
    "Parameters": {
        "Environment": { "Type": "String" }, // Parameter for environment (e.g., dev, prod)
        "ProjectName": { "Type": "String" }, // Parameter for project name
        "Application": { "Type": "String" }, // Parameter for application name
        "ExpirationInDays": { "Type": "Number" } // Parameter for setting lifecycle expiration in days
    },
    "Conditions": {
        "LifeCycleCondition": { // Condition to check if lifecycle rule is needed
            "Fn::Not": [
                { "Fn::Equals": [{ "Ref": "ExpirationInDays" }, 0] }
            ]
        }
    },
    "Resources": {
        "CFS3Bucket": { // Defines an S3 bucket resource
            "Type": "AWS::S3::Bucket",
            "Properties": {
                "BucketName": { // Bucket name created from a combination of parameters
                    "Fn::Join": ["-", [{ "Ref": "ProjectName" }, { "Ref": "Environment" }, { "Ref": "Application" }]]
                },
                "LifecycleConfiguration": { // Sets lifecycle configuration based on the condition
                    "Fn::If": [
                        "LifeCycleCondition",
                        { "Rules": [{ "ExpirationInDays": { "Ref": "ExpirationInDays" }, "Status": "Enabled" }] },
                        { "Ref": "AWS::NoValue" }
                    ]
                },
                "PublicAccessBlockConfiguration": { // Blocks public access to the bucket
                    "BlockPublicAcls": "true",
                    "BlockPublicPolicy": "true",
                    "IgnorePublicAcls": "true",
                    "RestrictPublicBuckets": "true"
                }
            }
        }
    },
    "Outputs": {
        "CFS3Bucket": { "Value": { "Ref": "CFS3Bucket" } }, // Outputs the name of the created bucket
        "CFS3BucketArn": { "Value": { "Fn::GetAtt": ["CFS3Bucket", "Arn"] } } // Outputs the ARN of the created bucket
    }
}

main.json (Main Stack Template)

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "CF template to demonstrate nested stack creation", // Description of what this template does
    "Parameters": {
        "Environment": { "Type": "String", "Default": "dev" }, // Default parameter for environment
        "ProjectName": { "Type": "String", "Default": "gritcoding" } // Default parameter for project name
    },
    "Resources": {
        "S3CatStack": { // Defines a nested stack for 'cat' application
            "Type": "AWS::CloudFormation::Stack",
            "Properties": {
                "Parameters": { // Parameters passed to the nested stack
                    "ProjectName": { "Ref": "ProjectName" },
                    "Environment": { "Ref": "Environment" },
                    "Application": "cat",
                    "ExpirationInDays": 0
                },
                "TemplateURL": "S3Template.json" // URL of the template for the nested stack. Initially, this points to the local S3Template.json file.
            }
        },
        "S3DogStack": { // Defines a nested stack for 'dog' application
            "Type": "AWS::CloudFormation::Stack",
            "Properties": {
                "Parameters": { // Parameters passed to the nested stack
                    "ProjectName": { "Ref": "ProjectName" },
                    "Environment": { "Ref": "Environment" },
                    "Application": "dog",
                    "ExpirationInDays": 0
                },
                "TemplateURL": "S3Template.json" // URL of the template for the nested stack. Initially, this points to the local S3Template.json file.
            }
        }
    }
}

Important Note on Parameters

When using nested stacks in CloudFormation, it's crucial to ensure that all required parameters in the nested stack (in this case, S3Template.json) are provided by the main stack (main.json). If the main stack doesn't pass these parameters, the CloudFormation deployment will fail.

Step 2: Package the CloudFormation Template

In your project's root directory, package the main.json and S3Template.json files into a single template using the following command:

aws --region <your-region> cloudformation package --s3-bucket <your-bucket-name> --template-file ./main.json --output-template-file ./packaged-template.json --use-json

Check your directory for the newly created packaged-template.json file.

Step 3: Deploy the Packaged Template

Now, deploy the stack to AWS CloudFormation using the command below:

aws cloudformation deploy --template-file ./packaged-template.json --stack-name <your-stack-name>

Visit your AWS console, check the CloudFormation and S3 sections, and you should see the newly created stacks and S3 buckets.

To delete the stack, use:

aws cloudformation delete-stack --stack-name <your stack name>

Confirm the stack's removal in the AWS console.

Learn More

This tutorial aimed to shed light on CloudFormation syntax. For those who prefer hands-on learning, you can fork and explore the source code from this repository: GitHub. And if you found this guide or the repository useful, a star or a reaction would be much appreciated—it's a simple way to show support and keeps me inspired to share more content like this.😄

For further reading and official AWS documentation, refer to:

How to Register a GitLab Runner in an EC2 Instance

Grit Coding — Fri, 26 Jan 2024 11:25:18 +0000

Setting up a GitLab runner on an Amazon EC2 instance is a key step for anyone looking to streamline their CI/CD pipeline. This guide will walk you through the process. Whether you're new to this or looking to refine your current setup, you'll find the necessary steps and insights here.

Prerequisites
Before you begin, make sure you can launch and access an EC2 instance. If you prefer to use AWS Session Manager for access, find detailed instructions here.
Alternatively, you can access your EC2 instance using a key pair from your local machine.

Installing GitLab Runner on an EC2 Instance
First, access your EC2 instance. The installation commands for the GitLab runner vary based on your operating system. For an Amazon Linux AMI, follow these steps:

# Linux x86-64
sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64"

sudo chmod +x /usr/local/bin/gitlab-runner

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

For installation instructions on other operating systems, refer to:
Installation GitLab Runner
Linux Manual Install

Creating a Project Runner
To set up your project runner,

Go to your GitLab project's settings and select CI/CD.
In the Runners section, find the button to add a new project runner.

Assign relevant tag names for job execution.
If you wish to restrict the runner to the current project, enable the Lock to current projects option.

With these steps completed, we now have the GitLab Runner URL and token ready for registration!

Registering the GitLab Runner
Back on your EC2 instance, execute the following command to register the GitLab runner:

sudo gitlab-runner register

During the registration process, as shown in the screenshot below, you will be prompted to enter the runner's URL and token.

For my setup, I named the runner EC2 and selected shell as the executor, which you can learn more about here.

After registering the runner, you can verify its configuration by checking the config.toml file. This file will contain all the details about your runner, as shown in the screenshot below.

With the runner registered, start it using the following command:

sudo gitlab-runner run

Upon successful registration and execution, you should see a green indicator next to your runner in the GitLab project, confirming that it is active and ready to process jobs.

Testing the Setup

Now that your GitLab Runner is up and running, it's important to test it to ensure it's functioning as expected.

Create a .gitlab-ci.yml file in your project's root directory, ensuring that the tags match those assigned to your runner.

The .gitlab-ci.yml file dictates the behaviour of the runner. When you push changes to your repository, it triggers the jobs specified in this file, based on the rules you set.

After pushing a commit to your repository, check the EC2 instance to see if the job is triggered correctly. Initially, you might encounter a scenario where the job is triggered but fails.

For instance, in my case, the job failed initially because the git command was missing.

Troubleshoot the issue based on the error logs. In this example, after identifying the missing git command, install the necessary components on your EC2 instance. In my scenario, I installed git, Node.js, and npm, which resolved the issue.

Once the necessary tools are installed on the EC2 instance, re-trigger the job. You should now see a successful execution, as indicated in the screenshot below.

A successful run demonstrates that your GitLab Runner is correctly set up and able to handle CI/CD tasks.

Simplified Access: Using AWS Session Manager for EC2 without a PEM File

Grit Coding — Thu, 25 Jan 2024 22:16:16 +0000

In this post, we'll explore how to utilise AWS Session Manager to access an EC2 instance without the need for a PEM file.

Create IAM Role

Before diving into the creation of an EC2 instance, it's essential to set up an IAM (Identity and Access Management) role. IAM roles help in securely granting permissions that your EC2 instance will need.

Navigate to the IAM dashboard in your AWS console.
Create a new role and attach the AWSSSMManagedInstanceCore policy to it.

Important: Select the correct service use case. Choosing the wrong service will prevent this role from appearing when setting up your EC2 instance.

Create EC2 Instance
Now, let's create our EC2 instance

Head over to the EC2 dashboard and click the Launch instance button.

In the network settings, ensure Auto-assign Public IP is enabled. Select your desired security group.

Under Advanced Details, choose the IAM role you created earlier.

Review your settings in the Summary section and then launch the instance.

A popup will appear since we haven't created a new key pair (PEM file). As we're using Session Manager, click on the Proceed without key pair option.

Access an EC2 Instance via AWS Console
Once your EC2 instance is up and running,

Click on the instance ID in the EC2 dashboard.

Hit the Connect button.

You can now access the EC2 instance through AWS Session Manager.

Note: In this tutorial, we've created an EC2 instance within the default VPC and assigned a public IP to it. Depending on your VPC settings, the 'Connect' button might be disabled. Make sure to verify your VPC settings if you encounter this issue.

You've successfully accessed an EC2 instance without a PEM file using AWS Session Manager!
Don't forget to terminate your EC2 instance once you're done.😉

Forem: Grit Coding

Hosting a Static Website on S3 Bucket with CloudFront and a Custom Domain Using Terraform

Prerequisites

Deploy and Test

Customising Content Delivery with AWS CloudFront: Routing with Origin Request Policies and CloudFront Functions

Prerequisites

Create S3 Bucket and Upload Files

Create CloudFront Function and Deploy

Create CloudFront Origin Request Policy

Create CloudFront Distribution

Update S3 Bucket Policy

Building Infrastructure from Scratch: Creating Public Subnets in AWS

Prerequisites

Create Public Subnets

VPC Creation

Default NACL

Internet Gateway

Subnets

Route Table

IAM Role with AmazonSSMManagedInstanceCore

Security Group

EC2 Instance Creation

Deploy and Test

Wrap-up

Building Infrastructure from Scratch: Creating a VPC with Terraform

Prerequisites

Step1: Crafting the main.tf File

Step 2: Deploying AWS VPC

Initialise Terraform

Apply the Terraform Configuration

Verify VPC Creation

Clean Up Resources

Learn More

Creating S3 Buckets using CloudFormation via AWS CLI

Prerequisites

Understanding the Process Flow

Step 1: Create an S3 Bucket and Prepare the Template

S3Template.json (Nested Stack Template)

main.json (Main Stack Template)

Important Note on Parameters

Step 2: Package the CloudFormation Template

Step 3: Deploy the Packaged Template

Learn More

How to Register a GitLab Runner in an EC2 Instance

Simplified Access: Using AWS Session Manager for EC2 without a PEM File

Step1: Crafting the `main.tf` File