DEV Community: Jay Sheth

🚀 Hello, Kubernetes! A Hands-On Guide to Deploying Your First App on GKE description

Jay Sheth — Sun, 02 Nov 2025 10:47:13 +0000

Google Kubernetes Engine (GKE) offers a powerful, managed environment for running containerized applications at scale.

In this guide, we'll walk through the essential commands to provision a GKE cluster, deploy a simple web application, expose it to the internet, and clean up; all in less than an hour!

🛠️ Prerequisites and Setup

We'll be using Cloud Shell for all our commands, as it comes pre-installed with the necessary tools: gcloud for managing Google Cloud resources and kubectl for interacting with the Kubernetes cluster.

Task 1: Set a Default Compute Zone

To make subsequent commands shorter, we'll configure a default region and zone.

# Set the default compute region
gcloud config set compute/region us-east4

# Set the default compute zone (this will be where the cluster nodes live)
gcloud config set compute/zone us-east4-a

Task 2: Create a GKE Cluster

A GKE cluster is made up of a Master (control plane) and multiple Nodes (worker machines). We'll create a cluster named lab-cluster with e2-medium nodes.

gcloud container clusters create /
--machine-type=e2-medium /
--zone=us-east4-a lab-cluster

Note: This command can take several minutes to complete as Google Cloud provisions the necessary Compute Engine instances and sets up the Kubernetes control plane.

Once complete, you can view the cluster in the Google Cloud Console:

Task 3: Get Authentication Credentials

Before using kubectl, we need to get the credentials to connect to our new cluster securely. This command updates your kubeconfig file.

gcloud container clusters get-credentials lab-cluster

Expected Output: kubeconfig entry generated for lab-cluster.

🚀 Deploying and Exposing the Application

With the cluster running and authenticated, we can now deploy our containerized application. We'll use the sample hello-app image provided by Google.

Task 4.1: Deploy the Container (Deployment)

A Kubernetes Deployment manages stateless applications, ensuring the specified number of replicas are running.

kubectl create deployment hello-server /
--image=gcr.io/google-samples/hello-app:1.0

Expected Output: deployment.apps/hello-server created

After a moment, you can confirm the Deployment status in the GUI:

Task 4.2: Create a Kubernetes Service (Load Balancer)

To access the application from the public internet, we need to create a Kubernetes Service. By setting the type to LoadBalancer, GKE automatically provisions a Google Cloud Load Balancer for us.

kubectl expose deployment hello-server --type=LoadBalancer --port 8080

Expected Output: service/hello-server exposed

4.3: Get the External IP and View the App

The LoadBalancer takes a minute or two to provision an external IP. Run the following command until the EXTERNAL-IP field is no longer <pending>.

kubectl get service

In the Deployment details screen, you can see the service exposing the endpoint:

Once the IP is visible (e.g., 35.245.47.76), open your web browser and navigate to: http://[EXTERNAL-IP]:8080

You should see the successful output:

🧹 Task 5: Delete the Cluster

A key part of cloud computing is cleanup to avoid unnecessary costs. Deleting the cluster removes all associated resources, including the nodes, Pods, Deployments, and the Load Balancer Service.

gcloud container clusters delete lab-cluster

When prompted, type Y to confirm.

The console will show that the cluster is being deleted:

Congratulations! You've successfully created, deployed to, and cleaned up a Google Kubernetes Engine cluster.

Checkout my new post!

Jay Sheth — Sat, 01 Nov 2025 18:06:17 +0000

🌍 How to Set Up a Global HTTP Load Balancer on Google Cloud (Step-by-Step with Screenshots)

Jay Sheth ・ Nov 1

🌍 How to Set Up a Global HTTP Load Balancer on Google Cloud (Step-by-Step with Screenshots)

Jay Sheth — Sat, 01 Nov 2025 18:04:49 +0000

Load balancing is an essential part of modern cloud architectures --- it helps distribute traffic across multiple backend instances, ensuring reliability, scalability, and performance.

In this tutorial, we'll set up a Global HTTP Load Balancer on Google Cloud Platform (GCP) using both the Cloud Shell (gcloud) and the Google Cloud Console (GUI).

🧱 Prerequisites

Before starting, make sure you have:

A GCP project (like Qwiklabs or your own)
Billing enabled
Cloud Shell or gcloud CLI access

🖥️ Step 1: Create Initial Compute Engine Instances

We'll start by creating 3 individual virtual machines. For a full tutorial, it's helpful to see how basic VMs are set up before moving to managed groups.

You can create them using the following gcloud commands, each setting up a simple Apache web server that displays its own name.

Bash

gcloud compute instances create www1\
  --zone=us-west1-c\
  --tags=network-lb-tag\
  --machine-type=e2-small\
  --image-family=debian-11\
  --image-project=debian-cloud\
  --metadata=startup-script='#!/bin/bash
    apt-get update
    apt-get install apache2 -y
    service apache2 restart
    echo "<h3>Web Server: www1</h3>" | tee /var/www/html/index.html'

gcloud compute instances create www2\
  --zone=us-west1-c\
  --tags=network-lb-tag\
  --machine-type=e2-small\
  --image-family=debian-11\
  --image-project=debian-cloud\
  --metadata=startup-script='#!/bin/bash
    apt-get update
    apt-get install apache2 -y
    service apache2 restart
    echo "<h3>Web Server: www2</h3>" | tee /var/www/html/index.html'

gcloud compute instances create www3\
  --zone=us-west1-c\
  --tags=network-lb-tag\
  --machine-type=e2-small\
  --image-family=debian-11\
  --image-project=debian-cloud\
  --metadata=startup-script='#!/bin/bash
    apt-get update
    apt-get install apache2 -y
    service apache2 restart
    echo "<h3>Web Server: www3</h3>" | tee /var/www/html/index.html'

The VM Instances appear in the Console like this:

🧩 Step 2: Create an Instance Template

Instance templates define the configuration for VM instances that will be part of the managed instance group, ensuring they are identical and run the startup script.

Bash

gcloud compute instance-templates create lb-backend-template\
  --region=us-west1\
  --network=default\
  --subnet=default\
  --tags=network-lb-tag\
  --image-family=debian-11\
  --image-project=debian-cloud\
  --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install -y apache2
    echo "<h1>Hello from $(hostname)</h1>" | tee /var/www/html/index.html
    systemctl restart apache2'

The Instance Group Template appear in the Console like this:

⚙️ Step 3: Create a Managed Instance Group (MIG)

This group will manage the identical backend instances using the template we just created. We'll start with a size of 2.

Bash

gcloud compute instance-groups managed create lb-backend-group\
  --template=lb-backend-template\
  --size=2\
  --zone=us-west1-c

Bash

gcloud compute instance-groups managed set-named-ports lb-backend-group\
    --named-ports http:80\
    --zone=us-west1-c

The Instance Group appear in the Console like this:

🌐 Step 4: Reserve a Global Static IP Address

This IP address will be the public, permanent address for your load balancer.

Bash

gcloud compute addresses create lb-ipv4-1\
  --ip-version=IPV4\
  --global

The Static IP appear in the Console like this:

🔥 Step 5: Configure Firewall Rules

We need a firewall rule to allow HTTP traffic (port 80) and a separate rule to allow the Google Cloud Health Check probes to reach your backend instances.

Bash

gcloud compute firewall-rules create fw-allow-health-check\
  --network=default\
  --action=ALLOW\
  --direction=INGRESS\
  --source-ranges=130.211.0.0/22,35.191.0.0/16\
  --target-tags=network-lb-tag\
  --rules=tcp:80

The Firewall appear in the Console like this:

❤️ Step 6: Create a Health Check

This checks your instances to ensure they are healthy before sending user traffic to them.

Bash

gcloud compute health-checks create http http-basic-check\
  --port 80

The Health Check appear in the Console like this:

🧠 Step 7: Create a Backend Service

The Backend Service links your health check to your instance group and defines the protocol for traffic to the backends.

Bash

gcloud compute backend-services create web-backend-service\
  --protocol=HTTP\
  --port-name=http\
  --health-checks=http-basic-check\
  --global

The Backend service appear in the Console like this:

🧩 Step 8: Add the Instance Group to the Backend Service

Now, connect your Managed Instance Group to the Backend Service.

Bash

gcloud compute backend-services add-backend web-backend-service\
  --instance-group=lb-backend-group\
  --instance-group-zone=us-west1-c\
  --global

The Instance Group added to the Backend Service appear in the Console like this:

🌍 Step 9: Create a URL Map

The URL map defines which backend service handles incoming requests. For this simple setup, all requests go to our single backend service.

Bash

gcloud compute url-maps create web-map-http\
  --default-service web-backend-service

The URL Map appear in the Console like this:

🧭 Step 10: Create a Target HTTP Proxy

The Target HTTP Proxy receives the request from the forwarding rule and consults the URL map to determine where to send the traffic.

Bash

gcloud compute target-http-proxies create http-lb-proxy\
  --url-map web-map-http

🚀 Step 11: Create a Global Forwarding Rule

This is the final step, linking your static external IP to the proxy and listening on port 80 (HTTP).

Bash

gcloud compute forwarding-rules create http-content-rule\
  --address=lb-ipv4-1\
  --global\
  --target-http-proxy=http-lb-proxy\
  --ports=80

The Proxy appear in the Console like this:

✅ Step 12: Test Your Load Balancer

It may take a few minutes for the Load Balancer to provision and for the health checks to pass.

Go to Load Balancing > Frontends and copy the IP address (in this example: 34.54.232.204).
Now open your browser and visit: http://34.54.232.204

You should see output similar to this:

Each time you refresh the page, the VM name (e.g., lb-backend-group-c151) may change, confirming that the load balancer is successfully distributing traffic between the healthy instances in your Managed Instance Group.

The Final Result:

💡 Summary

Component	Description
VM Instances	Backend servers running Apache.
Instance Template & Group	Automates VM creation and management (MIG).
Firewall Rules	Allows HTTP and health check traffic.
Health Check	Monitors backend VM health.
Backend Service	Connects instances to the LB, uses the named port.
URL Map	Routes incoming traffic to the correct backend service.
Frontend Rule	Assigns the static IP and listens on port 80.

You've successfully built a global HTTP load balancer in GCP, distributing traffic between healthy backends using gcloud commands and GUI verification.

If you're looking for more details on the setup and configuration of different load balancer types, this video is a helpful resource: How to set up a Global HTTP Load Balancer with Compute Engine.

Deploy Flask App on Google Cloud Run with Terraform

Jay Sheth — Mon, 15 Jul 2024 18:39:41 +0000

Prerequisite:

GCP Account
Install Google Cloud SDK
Terraform Installed on Developer Desktop
Python on Developer Desktop

In GCP Console:

Create new Project named my-first-project on GCP console
We will enable the following APIs for our project to work, run the below mentioned commands in Google Cloud CLI

Cloud Run
Artifact Registry
Cloud Build

On Developer Desktop:

Create a simple Flask Application

Create an app.py file
Create a Dockerfile

In GCP Console:

Go to Artifact Registry
Click on Create Repository

Give name to repository ($REPO_NAME)
Select Docker in Format
Select Standard in Mode
Select Regional in Location Type
Select us-west1 in Region
Click on Create

On Developer Desktop

In the folder where we created the Dockerfile; run the following commands
We will create Terraform project

Create terraform.tf for configuring the providers
Create main.tf containing the cloud run configuration
Create variable.tf containing the variables
Create data.tf containing the data
Create output.tf containing the output
Create terraform.tfvars containing the variable values
Now run the following commands in your terminal

Output

Destroy Infrastructure

To destroy the infrastructure, run the following commands in your terminal

👋👋BYE👋👋

Deploy React App using GitLab CICD and Docker

Jay Sheth — Thu, 09 May 2024 18:06:16 +0000

Prerequisites:

Ubuntu Machine
GitLab account
Node, NPM, Docker installed on Ubuntu Machine & Local Machine

Steps:

1. Project Folder

Create a react app on your local machine using npx create-react-app react-app
Create nginx.conf file with below content



http {

  include mime.types;

  set_real_ip_from        0.0.0.0/0;
  real_ip_recursive       on;
  real_ip_header          X-Forward-For;
  limit_req_zone          $binary_remote_addr zone=mylimit:10m rate=10r/s;

  server {
    listen 80;
    server_name localhost;
    root /proxy;
    limit_req zone=mylimit burst=70 nodelay;

    location / {
            root   /usr/share/nginx/html;
            index  index.html index.htm;
            try_files $uri /index.html;   
    }
  }
}

events {}

Create a Dockerfile with below content



FROM nginx:latest

COPY ./build /usr/share/nginx/html

COPY nginx.conf /etc/nginx/nginx.conf  

EXPOSE 80/tcp 

CMD ["/usr/sbin/nginx", "-g", "daemon off;"]

Create a deploy.sh file



#!/bin/bash

# Pull the latest Docker image
docker pull <image-name>

# Stop and remove any existing container with the same name
docker stop <container-name> || true
docker rm <container-name> || true

# Run the Docker container
docker run -d --name <container-name> -p <host-port>:<container-port> <image-name>

Add the .pem file, which will be require to SSH into our Ubuntu machine in same folder.

2. GitLab

Create a GitLab account if you don't have
Push code to GitLab
Goto Setting -> CICD -> Variables
Create a new variable with DNS of your ubuntu machine, Docker Image Name, Docker Hub Token(configure later on), Docker Hub username
Create a cicd file in gitlab pipeline editor with below content



stages:
  - build
  - build image
  - deploy

Build:
  stage: build
  image: node:20-alpine

  script:
    - npm install
    - npm run build

  artifacts:
      paths:
        - build/

Push To DockerHub:
  stage: build image
  image: docker:stable

  services:
    - docker:dind
  script:
    - docker build -t $DH_IMAGE_NAME .
    - docker login -u $DH_USER_NAME -p $DH_TOKEN
    - docker push $DH_IMAGE_NAME

  dependencies:
    - Build

Deploy to EC2:
  stage: deploy
  image: alpine:3.19

  before_script:
    - apk update
    - apk add openssh-client
    - chmod 600 "Ubuntu1Key.pem" 

  script:
    - ssh -o StrictHostKeyChecking=no -i "Ubuntu1Key.pem" ubuntu@"$U1_EC2_DNS" 'bash -s' < deploy.sh

Explantion:
This CI/CD file in GitLab has three stages:

Build: Uses Node.js to install dependencies and build the project. The resulting artifacts are stored in the build/ directory.

Push To DockerHub: Builds a Docker image using Docker's stable version, then pushes it to DockerHub after logging in with credentials.

Deploy to EC2: Utilizes Alpine Linux to update packages and install SSH client. It sets permissions for SSH key usage, then deploys to an EC2 instance by executing a deployment script via SSH.

3. Docker Hub

Create an account for Docker Hub
Goto My Account -> Security -> Create A new Token (With Read and Write)
Copy the token & paste it in the variable create earlier in GitLab name DH_TOKEN

4. Run the CICD Pipeline

Commit once on the main branch, so our CICD will be triggered automatically.
Goto the Build -> Pipelines
After successful completion of CICD, it will look like this

Now open the Public IP of EC2 with host-port which you specified in the deploy.sh.

BYE 👋👋

Deploy Web Application using Nginx and Docker on Ubuntu

Jay Sheth — Tue, 09 Apr 2024 16:18:15 +0000

Prerequisites:

Ubuntu Machine
Basic Docker knowledge
Node and NPM on Local Device and Ubuntu
Docker on Ubuntu machine

Flow:

On local machine create a React App if you don't already have 1 by following command

npx create-react-app react-app
cd react-app
npm start

NOTE: You can name your project anything, I have kept it react-app in this demo

Create a Dockerfileon root level of react-app directory with below content.

FROM node:lts-alpine as build  # Use Node.js LTS Alpine image as build environment

WORKDIR /app  # Set working directory inside the container to /app

COPY package*.json ./  # Copy package.json and package-lock.json files to /app directory

RUN npm ci  # Install dependencies using npm's CI mode for faster and consistent builds

COPY . .  # Copy the rest of the application files to /app directory

RUN npm run build  # Build the application using npm script

FROM nginx:latest as prod  # Use the latest Nginx image as production environment

COPY --from=build /app/build /usr/share/nginx/html  # Copy built files from the previous stage to Nginx HTML directory

COPY nginx.conf /etc/nginx/nginx.conf  # Copy custom Nginx configuration file to override default configuration

EXPOSE 80/tcp  # Expose port 80 for incoming HTTP traffic

CMD ["/usr/sbin/nginx", "-g", "daemon off;"]  # Start Nginx server with daemon off for foreground execution

We will also need to create a Nginx configuration file to listen for any connection at port 80. Create a new file name nginx.confat root level of project directory.

http {

  include mime.types;

  set_real_ip_from        0.0.0.0/0;
  real_ip_recursive       on;
  real_ip_header          X-Forward-For;
  limit_req_zone          $binary_remote_addr zone=mylimit:10m rate=10r/s;

  server {
    listen 80;
    server_name localhost;
    root /proxy;
    limit_req zone=mylimit burst=70 nodelay;

    location / {
            root   /usr/share/nginx/html;
            index  index.html index.htm;
            try_files $uri /index.html;   
    }
  }
}

events {}

Push this code on GitHub Repo
Deploy Ubuntu machine on any cloud provider if you don't have setup on local device
On Ubuntu machine we need to node, npm, docker installed, if it is not configured then do so.
After installing node, npm, docker, pull the code from GitHub Repo & run these commands to run our application on server.
This command will create an image for the above mentioned dockerfile. docker build -t react-app-image:1.0.0 .
Now we will create a container for the image we created, by running the following command. docker run -d -p 80:80 --name react-server with-docker Now our application should running on the PORT 80. If you are using cloud for ubuntu machine then search in browser public_ip_of_machine:80, if you are deploying it on local device then open localhost:80 in browser.

BYE 👋👋

Deploy & Host a React Application on NGINX with Ubuntu

Jay Sheth — Sun, 07 Apr 2024 08:47:59 +0000

Prerequisites

Ubuntu Machine
Nginx on Ubuntu
Node and NPM on local device and ubuntu
Template React App
GitHub

Flow

Deploy Ubuntu machine on any cloud provider if you dont have setup on local device
On Ubuntu, run following cmd to install nginx
Update package index: Before installing any new software, it's a good practice to update the package index to ensure you're getting the latest versions.
sudo apt update
Install Nginx: Use apt to install Nginx.
sudo apt install nginx
Start Nginx: Once installed, Nginx should start automatically. If not, you can start it manually.
sudo systemctl start nginx
Enable Nginx to start on boot: If you want Nginx to start automatically whenever your instance is rebooted, you can enable it.
sudo systemctl enable nginx
On local device, run this cmd
npx create-react-app react-app
NOTE: I have use react-app as a name of my react-app, you can keep whatever name you want
Push this code on github
On Ubuntu, run this cmd
git clone https://github.com/exampleuser/example-repository.git
Note: Above URL is example, you need to provide you repo URL
npm run build
cd /etc/nginx/sites-available
sudo vim react-app

Paste below code in vim editor

server { 

        listen 80; 

        listen [::]:80;  

        root /var/www/react-app; 

        index index.html; 

}

cd /var/www/
sudo mkdir react-app
sudo chmod –R 755 /var/www/react-app
sudo chown –R www-data:www-data /var/www/react-app
cd $HOME
sudo cp -r react-app/build/* /var/www/react-app/
sudo unlink /etc/nginx/sites-enabled/default
sudo ln –s /etc/nginx/sites-available/react-app /etc/nginx/sites-enabled/
sudo systemctl restart nginx
sudo nginx –t (check the output on cmd – it should be successfull)

Now open the Public Ip of Ubuntu machine if deployed on cloud, if launch on local open localhost:80

Bye!! 👋

Account Management with Account Factory for Terraform [Demo]

Jay Sheth — Fri, 10 Nov 2023 09:47:22 +0000

What is Account Factory For Terraform?

It is simple to generate and modify new accounts that adhere to your organization's security policies using the AWS Control Tower Account Factory for Terraform (AFT) Terraform module. You may take use of Terraform's workflow and Control Tower's governance capabilities by using AFT, which establishes a pipeline for the automatic and reliable generation of AWS Control Tower accounts. This module is maintained by AWS.
This tutorial walks you through the one-time procedures needed to deploy AFT in order to establish the account creation pipeline. Your Control Tower accounts will then be created and customized using AFT. You will deploy the AFT module, go through the customization choices for support accounts, and discover the elements of AFT and its workflow in this lesson.

Implementation

PREREQUISITES:
Before we start our walkthrough, there are some prerequisites which are require, they are:

You should have AWS Control Tower environment deployed and active.
An AWS Account with credential for non-root user with AdminstratorAccess.
A new root email address for a new vended AWS account that you’ll submit through AFT.
A new or existing Organizational Units (OU) governed by AWS Control Tower, which is needed as part of new account request parameter in AFT.
Integrated development environment (IDE) with Git, Terraform, and AWS Command Line Interface (AWS CLI) installed. Your IDE environment must be configured with AWS credentials to your AFT Management account.
Make sure to specify the AWS Control Tower home region in the commands where applicable

STEP 1: Create AWS AFT Organizational Unit and Account
From now on we will be referencing 2 Account:

Control Tower management account: Account in which in which we have launched AWS Control Tower.
Account Factory management account: This account will be provisioned in this section.

In your Control Tower management account navigate to AWS Control Tower and open Organization from the left pane. Select Create Resources and select Create Organization Unit.

Name the OU, we have kept it as Learn AFT and then select Root OU as the parent OU.

Now navigate to Account Factory and select Create Account.

In Account Email field, enter an email which is not associated with any AWS Account, this will account’s root email address. In IAM Identity Center user email enter an email id you have access to. And select Learn AFT as your Organization Unit. Fill in all other fields as per your preference.

Account provisioning can take up to 30 minutes.

Step 2: Clone and Fork Examples with configurations
We will be working around 5 repositories, one with the AFT module deployment and 4 that the module requires you to define your account specifications in. The first repository learn-terraform-aws-control-tower-aft, which is one time setup will create the required infrastructure across Control Tower management account & in AFT management account. It will create 327 resources in these accounts and these resources will help us to create an account in our Control Tower and all the Customizations.
AFT supports multiple VCS providers like AWS CodeCommit, GitHub, Bitbucket, and GitHub Enterprise Server. By default, it uses AWS CodeCommit for repositories. In our case, we will use GitHub as VCS.
First Clone the learn-terraform-aws-control-tower-aft containing the AFT module configuration in AFT Management Account.
And for the next 4 repositories into your GitHub account.

The learn-terraform-aft-account-request repository: provides an example setup for starting AFT-based new account provisioning.
The learn-terraform-aft-global-customizations repository: provides boilerplate setup for adjustments that will be applied to each account that AFT creates.
The learn-terraform-aft-account-customizations repository: includes default settings for account-specific adjustments.
The learn-terraform-aft-account-provisioning-customizations repository: provides default settings that can be applied to accounts at provisioning time. Clone your copies of repositories to your computer.

Step 3: Deploy AFT module
The AFT module is maintained by AWS Team, it will deploy multiple services which will help you to provision and customize account in Control Tower.
In your terminal, navigate to the learn-terraform-aws-control-tower-aft repository you cloned earlier.
1. Update AFT module configuration
Open main.tf file in your IDE, review and configure it according to your requirement. This module provisions resources across the Log, Audit, Control Tower Management, and AFT management accounts in your Landing Zone.
In terraform.tfvars provide your AWS account IDs for ct_management_account_id, log_archive_account_id, audit_account_id, aft_management_account_id. For ct_home_region, use the same region as the one Control Tower is enabled in. And provide your GitHub username in github_username variable.
By setting feature flags, you may disable the default VPC in accounts or enable CloudTrail recording at the organizational level.
2. Apply configuration
After AFT management account is provisioned, we will start deploying AFT module. Configure your terminal with the AWS credentials for a user with AdminstratorAccess in your Control Tower management account.
Initialize the configuration to install the AWS provider and download the AFT module by running terraform init command. Now apply your configuration by running terraform apply to provision all the services. Respond yes to confirm the operation. This will take 15 to 20 mins for deployment.

NOTE: There are lot of Resources which are created and you might not know why they are beneficial like Private Link Interface endpoints and NAT Gateways which incur highest cost. The need of these are because of Private communication to AWS Services privately without using Public endpoints which gives enhanced data protection and security. NAT Gateway is required for AWS CodeBuild to communicate.

Review AFT components and workflow One of the many advantages AFT has over manual provisioning of accounts is the abilty to queue multiple account requests with your configuration. AWS Control Tower currently allows you to create only one account at a time, but AFT uses DynamoDB and SQS to queue your account requests, making batched account creation more efficient.

First, you must create an account request file with the required attributes for the account to be provisioned. You must also apply for the customization you wish to apply to the account.

Once you push your files to GitHub repositories, AFT triggers a workflow that will provision and customize your account.

CodePipeline launches CodeBuild projects to populate a DynamoDB table item with your new account information. The new item initializes a Lambda that records your account requests in SQS, allowing you to create many new accounts at the same time.
The new SQS messages trigger Lambda functions, which process your account request and begin the account vending process in Control Tower. AFT also created an account-specific pipeline to manage the customization of your new account, as well as an execution role in your new account that it may utilize to customize it.
When AFT creates a new account, it triggers Lambda functions, which then activate your account-specific pipeline, which applies global and account-specific customizations. If you use Terraform configuration to generate resources in your account, the state of such resources is stored in S3. AFT applies account changes within your new account using the execution role it generated.

Enable CodeStar Connection
We are using GitHub as VCS, we will require CodeStar connection. AFT module sets up a CodeStar Connection, which will watch for the changes to repositories.
Once AFT module sets up AFT management account, login to it and navigate to CodeStar connections in AWSaanagement console and look for ct-aft-github-connection and click on it and select Update pending connection. Follow the workflow to Install a new app and connect it to your personal GitHub account. After configuring it, click Connect to enable the AWS Connector for GitHub.

Grant AFT access to Service Catalog portfolio
Log into the Control Tower management account in the AWS console, navigate to Portfolios in the Service Catalog page and click on the AWS Control Tower Account Factory Portfolio_. Select the _Groups, roles, and users tab, then click Add groups, roles, users. Select the Roles tab, then search for AWSAFTExecution. Check the box next to it and click Add access.

Navigate to your CodePipeline page in your AFT management account. Click Release change after selecting the ct-aft-account-provisioning-customizations pipeline. Then, click the Release button to restart the process.

Deploy an account with AFT
Now we will use AFT to provision a new account in Control Tower. Navigate to your cloned learn-terraform-aft-account-request repository. Open terraform/main.tf, this will contain an instance of aft-account-request. Configure control_tower_parameters, account_tags, change_management_parameters, custom_fields, account_customizations_name attributes according to the requirement. Now push this code to GitHub repository.
AFT CodePipeline AFT created listens for the changes to your account requests and customization repositories.

Global customizations
Global customizations apply to all AFT accounts. This enables you to automatically enforce security standards or provision standardised resources and infrastructure in each new account, making compliance with your organization's standards easier.
Navigate to cloned learn-terraform-aft-global-customizations repository. Move into terraform _folder and create a folder named _main.tf and write a terraform configuration file which will have a customization of your requirement. By default, this configuration does not define any global customizations for your account.

Account customizations
Account customizations are applied to a specific account or set of accounts by AFT. It uses the customizations defined in the repository whose name you specify in the account_customizations_name input variable.
That input variable's value must correspond to a subfolder in your account customizations repository. Account customizations let you to make specific changes to groups of accounts, such as imposing tougher access guardrails on accounts that manage production resources.
Navigate to the cloned repository named learn-terraform-aft-account-customizations and access the appropriate subfolder based on the specified account_customizations_name. Once you're in the correct subfolder, navigate to the terraform directory and open the file named s3.tf. Please note that s3.tf is just an example file, and you can modify it according to your specific customization needs.

Inspect new account
Verify that AFT created your new account by finding the AFT managment account in the list of accounts in your Control Tower Accounts dashboard.

Conclusion

In conclusion, leveraging the AWS Control Tower Account Factory for Terraform (AFT) brings powerful automation to account creation and customization processes. AFT's ability to queue multiple account requests and apply global and account-specific customizations & Seamlessly integrating Terraform and Control Tower's governance, AFT ensures security policy adherence, efficient workflows, and scalable provisioning. With support for multiple VCS providers like GitHub, businesses can maintain standardized security standards and enhance operational efficiency across their AWS environment.

Useful Links

CO FIRST AUTHOR

Rajdeep Jadeja

Introduction to Amazon Detective

Jay Sheth — Wed, 14 Jun 2023 21:10:54 +0000

What is Amazon Detective?

Amazon Detective simplifies the analysis and investigative process across your AWS Accounts enabling your team to quickly and easily determine the root cause of a potential security issue.

In AWS security is extremely important, you will be able to find multiple AWS services that can send you an alert when an issue arises, but Amazon Detective helps you to dig deeper and get the granular level detail.

How does Amazon Detective work?

When you enable Detective in your AWS account, the service automatically collects and analyzes millions of data from multiple data sources and provides us with easy-to-understand visual insight to interact with the analysis. So instead of manually inspecting the raw logs, you can visualize the details relating to an issue in one place and answer your security question.

It will collect logs from CloudTrail management events, VPC network traffic, GuardDuty findings and then use Machine Learning, statistical analysis, and graph theory to generate a visualization.

Use cases of Amazon Detective are:
1.Finding/Alert Triage: Suppose you have received a GuardDuty finding, and you are uncertain about whether you should be concerned. Detective can provide answers to your questions, which means it can assist you in accelerating triage and avoiding unnecessary escalation.

2.Incident Investigation: If the finding is of concern, then the finding triage process becomes an incident investigation and allows you to see analysis going back ck up to 1 year and help you answer questions like how long the security issue has been going on for and how many resources have been affected by it.

3.Threat Hunting: Suppose you want to know what kind of interactions an IP address had in your environment.

Amazon Detective is Multi Account service

Customers with multiple accounts who want to centralize the security investigation can use Amazon Detective. You must enable Detective in one of our account let's call it master account. Detective will make Security Behavior Graph from the logs collected from CloudTrail, VPC Network Traffic, GaurdDuty Finding.

Master account can send invitations to other accounts, and their CloudTrail Logs, VPC Network Traffic, and GaurdDuty findings will be shared with master account. Therefore, it's essential to follow best practices for managing data access and security to ensure that only authorized users have access to sensitive information.

Enabling AWS Security Findings in the Amazon Detective Console

When you enable Detective for the first time, it identifies findings from both GuardDuty and Security Hub and begins ingesting them alongside other data sources.

Detective begins analysing all relevant data in order to identify links between disparate events and activities. You can get a visualisation of these connections, including resource behaviour and activities, to start your investigation process. After two weeks, historical baselines are established, which can be used to provide comparisons to recent activity.

Demo

The Amazon Detective search interface serves as a common place for new users. Within this interface, you have the ability to search using various criteria, including GuardDuty Finding, AWS account, AWS Role, EC2 Instance, IP address, Role Session, User, and User agent.

To search specifically for an AWS Role, select it from the dropdown list and enter the desired role in the search bar.

Upon performing the search, you will be redirected to the profile page for the respective AWS Role. It is worth noting that Detective provides a similar profile page for every resource. To begin, adjust the Scope Time to the desired time frame.

The profile page is divided into multiple tabs: Overview, New Behavior, and Resource Interaction.

The Overview tab provides high-level information, including:

Information related to the Role.
Findings associated with the resource.
The "Overall API call volume" panel displays all successful and failed API calls made using this Role.

On the Resource Interaction tab, you can observe:

Who has assumed this Role
The Role assumed by our Role.

The New Behavior tab highlights any behavior exhibited by the Role that had not been observed before the selected scope time.

Pricing Model

Amazon Detective has a tiered pricing model that is based upon the volume of data that the service ingests, and the analytics and summaries of ingested data are kept for 1 year.

Useful Links

Why Containers are more popular than Virtual Machine?

Jay Sheth — Wed, 31 May 2023 18:53:17 +0000

Virtualization

Virtualization is quite an old concept. It began in the 1960s to logically divide the system resources provided by mainframe computers into individual applications. Being an old technology, it is still a relevant part of cloud computing.

Virtualization uses software to create an abstract layer over hardware allowing hardware elements such as storage, computing, and memory to get distributed among multiple virtual machines (VM). Each VM has its separate operating system (OS), acting like an individual machine even though it shares the underlying hardware with multiple other VMs.

The abstraction layer is a piece of software known as a Hypervisor. It is a crucial component in the virtualization process which serves as an interface between the VM and the underlying physical hardware. It ensures that VMs do not interrupt each other. It stands on top of a host or a physical server. The main task of a _hypervisor _is to pool resources from the physical server and allocate them to different virtual environments.

There are two types of hypervisors:
Type 1 or "bare metal" hypervisors: A Type 1 hypervisor runs directly on the physical hardware of the underlying machine, interacting with its CPU, memory, and physical storage.
Type 2 hypervisors: A Type 2 hypervisor does not run directly on the underlying hardware. Instead, it runs as an application in an OS.

Virtual Machine

A _virtual machine _(VM) is a virtual environment that behaves like a virtual computer system, complete with its CPU, memory, network interface, and storage.

AWS refers to them as EC2 instances; EC2 instances are virtual machines that emulate physical hardware components. An EC2 instance can do anything that a physical computer can do. You choose your compute options based on: CPU, memory, and storage. You choose the OS and maintain all security and patching of the instance. You can scale up or down the resources as needed.

Containers

Containers are software components that package application code, along with required executables such as libraries, dependencies, binary codes, and configuration files, using operating system virtualization in a standardized manner. Containers can run on various platforms, including desktops, traditional IT environments, and cloud infrastructures.

Containers are lightweight, portable, and swift because they do not include operating system images, like virtual machines. As a result, they have less overhead and can leverage the features and resources of the host operating system, making them highly portable and easy to deploy.

AWS provides two services for container management:
**1. Amazon Elastic Container Service (Amazon ECS)

Amazon Elastic Kubernetes Service (Amazon EKS)**

Amazon Elastic Container Service (Amazon ECS)

Elastic Container Service (ECS) is a fully managed container orchestration service provided by AWS. _ECS _simplifies the d*eployment, management, and scaling of Docker containers on AWS, and enables customers to build highly scalable and resilient microservices-based applications.*

_ECS _has two main components: the ECS service and the ECS agent. The ECS service is responsible for managing the container instances, tasks, and services, and provides APIs and a console for customers to interact with. The ECS agent is a lightweight daemon that runs on each EC2 instance or Fargate instance and communicates with the ECS service to register the instance and start, stop, and monitor containers.

There are two ways to set up an Amazon ECS cluster:

EC2: With EC2 instances, customers can choose their own instances and scale the cluster as needed.
Fargate: With Fargate, AWS manages the instances for customers, and they only pay for the resources their containers use.

_ECS _supports both Linux and Windows containers, and provides features such as load balancing, auto scaling, service discovery, and integration with other AWS services.

_ECS _integrates with other AWS services such as Amazon CloudWatch for monitoring, AWS Identity and Access Management (IAM) for access control, and Amazon Elastic Container Registry (ECR) for storing and managing Docker images. ECS also supports integration with third-party tools such as Jenkins.

Amazon Elastic Kubernetes Service (Amazon EKS)

Elastic Kubernetes Service (EKS) is a fully managed Kubernetes service provided by AWS. EKS simplifies the deployment, management, and scaling of containerized applications using Kubernetes on AWS, and enables customers to build highly scalable and resilient microservices-based applications.

Kubernetes is an open-source container orchestration system that automates containerized applications' deployment, scaling, and management. EKS allows customers to run Kubernetes clusters on a managed cluster of EC2 instances or Fargate instances same as ECS.

EKS has two main components: the EKS control plane and the worker nodes. The EKS control plane is responsible for managing the Kubernetes control plane, including the API server, etcd, and other components. The control plane is highly available, automatically scales, and is managed by AWS. The worker nodes are the EC2 or Fargate instances running the containerized applications. EKS automatically provisions, scales, and manages these nodes, and customers can use Amazon EC2 Auto Scaling groups to scale the nodes based on demand.

_EKS _integrates with other AWS services such as Amazon CloudWatch for monitoring, AWS Identity and Access Management (IAM) for access control, and Amazon Elastic Container Registry (ECR) for storing and managing container images. EKS also supports integration with third-party tools such as Jenkins.

Difference between containers and virtual machines (VMs)

Containers and virtual machines are two distinct approaches to virtualizing computing resources. Virtual machines virtualize all components down to the hardware level, generating multiple instances of operating systems on a single physical server. In contrast, containers virtualize solely the software layers above the operating system, forming lightweight packages that incorporate all the dependencies required for a software application. Containers can operate more workloads on a single operating system instance than virtual machines, making them faster, more flexible, and more portable.

Advantages

Containerized applications are portable and can be used in other cloud environments or returned to an on-premises datacenter, which helps businesses avoid vendor lock-in.
A container is more lightweight. They start up faster, nearly instantly. This difference in starting time is important when designing applications that are required to scale quickly during I/O bursts.
Containers offer the flexibility and portability that is ideal for the multi-cloud world. When developers design new applications, they may not be aware of all of the locations where they will need to be deployed. Today, a corporation may run a program on its private cloud, but tomorrow it may need to deploy it on a public cloud. Containerizing applications gives teams the flexibility they need to deal with today's diverse software environments.

Use cases of Containers

Increased developer's productivity

While testing an early version of an application, a developer can run it from their PC without hosting it on the primary operating system or creating a testing environment. Furthermore, containers eliminate problems with environment settings, handle scalability challenges, and simplify operations. Because containers solve numerous challenges, developers can concentrate on development rather than dealing with operations.

In these Configuration files, the code of the application, dependencies, and the runtime engine are packaged all together in a robust manner known as a container that can run on any environment independently.

Great for CI/CD

Containers also make it easier to develop a CI/CD pipeline, provide more frequent updates, and create repeatable deployment processes. Because containers are lightweight and agile, each container contains much less code than updating an entire VM, and containers run in the same environment at every stage of development, there is little risk that a containerized application will work perfectly in development and then fail in production.

Containers can run on IoT devices

Using containers suit installing and updating applications on IoT devices. That is because containers encompass all the required software for the applications to function, making them easily transportable and lightweight, which is particularly beneficial for devices having restricted resources.

Great for Micro-service architecture

Containers support microservice architectures, allowing for more precise deployment and scaling of application components. They are preferred over scaling up an entire monolithic application simply because a particular component faces difficulty.

Hybrid and multi-cloud compatible

Containers provide flexibility in app deployment, allowing for the creation of a unified environment that can run on-premises and across multiple cloud platforms. This makes it possible to optimize costs and enhance operational efficiency by leveraging existing infrastructure and utilizing the benefits of different cloud providers with the workload.

Conclusion

Containers have surpassed virtual machines in popularity due to their lightweight design, shorter deployment times, and efficient resource utilization, particularly for current, cloud-native apps. However, both technologies will coexist and evolve, and organizations should select the best tool for the job based on their specific needs and goals.