ECS Task Execution role

In my setup, my container needs to access ECR for pulling Docker images and needs to send logs to CloudWatch. My container needs to retrieve the DB password from AWS Secrets Manager. If I didn't define this execution role, my container couldn't pull images from ECR, send logs to CloudWatch, or retrieve the password from AWS Secrets Manager. This task execution role is performed before your container enters the running state.

Who use it?

The ECS agent uses it, not your application code.

When is it used?

Before container even starts running.

What is it for?

1. Pull images from Amazon Elastic Container Registry (ECR)

2. Send container logs to Amazon CloudWatch

3. Retrieve secrets from AWS Secrets Manager

4. Retrieve parameters from AWS Systems Manager

ECS Task role

My application code (business logic) needs to upload PDF files to AWS S3, store tracking info in Amazon DynamoDB, and push notifications from Amazon SNS. The ECS task role is not used by the ECS agent, this role is only used by your application code inside the container. If the task role is miss your application is run but can't access AWS API calls.

Who use it?

My application code inside the container.

When is it used?

After the container start running.

What is it for?

To allow my application to access AWS services.

Examples:

1. Read/write to Amazon S3

2. Send messages to Amazon Simple Queue Service

3. Publish to Amazon Simple Notification Service

4. Access Amazon DynamoDB

5. Call other AWS APIs

I hope you understand the difference between a task role and an execution role in AWS ECS.

Lab Purpose

I want to share my past Kubernetes experience in this lab. Disclaimer: In this lab, I created a simple backend CRUD API using Gemini AI. To be honest, I'm not a developer, so my backend code is not perfect.

The primary objective of this lab is to architect and deploy a production-ready SMS API on a bare-metal Kubernetes environment. This exercise demonstrates how to bridge the gap between internal cluster resources and external network accessibility without relying on managed cloud services.

If you don’t know how to setup Kubernetes Cluster. You can use below link for install and setup.

Here is the Kubernetes Cluster Installation

Here is my Code Repo

1. Multistage docker file

Why we need to do multistage docker file?

Multistage Docker builds are a game-changer for anyone tired of bloated, heavy container images. In a nutshell, they allow you to use multiple FROM statements in a single Dockerfile, effectively separating the build environment from the runtime environment.

Here is why they are considered a best practice.

1. Significant Size Reduction

   In a standard Dockerfile, everything you use to compile your app (compilers, build tools, header files) remains in the final image. With multistage builds, you "leave the trash behind." You compile your app in the first stage and then copy only the final executable into a tiny, production-ready image.

2. Enhanced Security

   A smaller image has a smaller attack surface. By removing package managers (like apt or npm), source code, and shell utilities from your final production image, you give hackers fewer tools to work with if they manage to gain access to your container.

3. Simplified CI/CD Pipelines

   Before multistage builds, developers often had to maintain two separate Dockerfiles (e.g., Dockerfile.build and Dockerfile.production) and use shell scripts to move artifacts between them. Multistage builds allow you to keep all that logic in one file, making your CI/CD pipeline much cleaner.

Here is my Dockerfile using multistage.

# Builder stage
FROM node:22-alpine AS builder
WORKDIR /app

RUN apk add --no-cache openssl libc6-compat curl
COPY package*.json ./
COPY prisma ./prisma/

RUN npm install
RUN npx prisma generate

# Runner stage
FROM node:22-alpine AS runner
WORKDIR /app
RUN apk add --no-cache openssl libc6-compat curl

COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/prisma ./prisma

# Copy application source
COPY package*.json ./
COPY server.js ./
COPY entrypoint.sh ./

RUN chmod +x entrypoint.sh

EXPOSE 3000

ENTRYPOINT ["/bin/sh", "./entrypoint.sh"]

Clone github repo to my local computer.

git clone https://github.com/frandi-devops-learn/demo-sms-api.git

cd demo-sms-api/

git branch -a

git checkout -b devops

git pull origin devops

2. Docker image push to DockerHub

After cloning the repo, we need to build this Docker image and push it to Docker Hub. In my lab, I use the public Docker Hub to store my container image. In this lab, I build Docker images for two types of architecture, so you can run either arm64 or amd64.

docker buildx build --platform Linux/arm64,Linux/amd64 -t zinlinhtetdevops/demo-sms-api:latest . --push

You can pull my ready to use container image.

docker pull zinlinhtetdevops/demo-sms-api:latest

docker images

3 . Installation of Helm

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4

chmod 700 get_helm.sh

sudo ./get_helm.sh

4. Installation of MetalLB

I use helm for install MetalLB on my kubernetes node. I create namespace for MetalLB.

helm repo list

helm repo add metallb https://metallb.github.io/metallb

helm install metallb metallb/metallb --create-namespace --namespace metallb-system

Now you can see MetalLB pod is successfully run.

Here is a breakdown of what this configuration does and a small missing piece you might need.

4.1. IPAddressPool

This is the "bucket" of IP addresses that MetalLB is allowed to hand out.

1. Range: 192.168.1.200 - 192.168.1.205.

2. Purpose: When you create a Service with type: LoadBalancer, MetalLB will grab one of these 6 IPs and assign it to that service.

3. Crucial Requirement: These IPs must not be in use by your router's DHCP server. If your router hands out .200 to your phone, and MetalLB hands it to your API, you'll have an IP conflict.

4.2. L2Advertisement

This tells MetalLB how to announce those IPs to your local network.

• Layer 2 (L2): This is the simplest mode. It uses standard ARP (Address Resolution Protocol).

• How it works: One of your nodes will basically shout to your router: "Hey, I am now the owner of 192.168.1.200!" The router then sends all traffic for that IP to that node.

kubectl create -f metallb.yml

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.1.200-192.168.1.205
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: advertisement
  namespace: metallb-system
spec:
  ipAddressPools:
  - first-pool

5. Installation of Rancher Local path provisioner

In a local Kubernetes environment (like K3s, Minikube, or Kind), managing storage can be frustrating. By default, Kubernetes doesn't automatically "give" you storage just because you ask for a Persistent Volume Claim (PVC). You usually have to manually create a Persistent Volume (PV) first.

The Rancher Local Path Provisioner solves this by providing Dynamic Provisioning for local storage.

Without this provisioner, if you want to deploy a database like MySQL or PostgreSQL, you have to:

1. Manually create a directory on your laptop/server.

2. Manually write a YAML for a Persistent Volume pointing to that path.

3. Then create your Persistent Volume Claim.

With the Local Path Provisioner, you skip steps 1 and 2. You just ask for a PVC, and the provisioner automatically creates a unique folder on your host machine and handles the PV creation for you.

Install the rancher local path provisioner using kubectl command.

kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

kubectl get namespace

kubectl get all -n local-path-storage

6. Create Namespace

In Kubernetes, a Namespace is essentially a "virtual cluster" within your physical cluster. If you only have one small app, you might not notice the need for them, but as soon as your project grows, namespaces become your best friend for organization and security. And then I chage the default namespace to demo-sms namespace.

kubectl create namespace dmeo-sms

kubectl get namespace

kubectl config set-context --current --namespace demo-sms

kubectl config get-contexts

7. Deploy PostgreSQL database on Kubernetes

It’s time to deploy the PostgreSQL database. In this lab, you need to deploy a StatefulSet for the database. Even if the database pod restarts, your data needs to exist and be persistent.

In Kubernetes, a Deployment is great for "stateless" things like your web app or an API where it doesn't matter which pod is which. But a database like PostgreSQL is "stateful"—it cares deeply about its identity and its data. Using a StatefulSet provides the specific "guardrails" that a database needs to run safely without corrupting data.

The first step I need to create a Persistent Volume Claim to attach a vloume in PostgreSQL database container. So let’s create a pvc. Here is the pvc.yml file.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-pvc
  namespace: demo-sms
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
  storageClassName: local-path

kubectl get pvc

Before creating the database, we need to create a secret for the database password. I don't want to use a hardcoded value in the PostgreSQL StatefulSet. So how to encode you database password. I will show you.

echo -n "yourpassword" | base64

kubectl create -f sec.yml

kubectl get secrets

apiVersion: v1
data:
  postgres-password: ZGJhZG1pbjEyMw== ( Put your base64 encoded database password )
kind: Secret
metadata:
  name: postgres-secret
  namespace: demo-sms

So let’s deploy PostgreSQL database StatfulSet container.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: demo-sms-db
  namespace: demo-sms
spec:
  serviceName: "demo-sms-db"
  replicas: 1
  selector:
    matchLabels:
      app: demo-sms-db
  template:
    metadata:
      labels:
        app: demo-sms-db
    spec:
      containers:
        - name: demo-sms-db
          image: postgres:16-alpine
          env:
           - name: POSTGRES_DB
             value: "uatdb"
           - name: POSTGRES_USER
             value: "dbadmin"
           - name: POSTGRES_PASSWORD
             valueFrom: 
               secretKeyRef:
                 name: postgres-secret
                 key: postgres-password
          ports:
          - containerPort: 5432
          resources:
            requests:
              cpu: "250m"
              memory: "512Mi"
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: db-storage
              subPath: postgres-data
      volumes:
        - name: db-storage
          persistentVolumeClaim:
            claimName: db-pvc

kubectl create -f stateful-set.yml

kubectl get pods

kubectl get pvc

kubectl get statefulset

Once the StatefulSet is running properly, I expose my PostgreSQL service using the ClusterIP type since we only need to access this database within the cluster. However, I also want to connect to my database from outside the cluster, so I expose it again using the NodePort type. I will show you how to expose a service with both ClusterIP and NodePort types.

This is the ClusterIP type.

apiVersion: v1
kind: Service
metadata:
  labels:
    app: demo-sms-db
  name: demo-sms-db-svc
  namespace: demo-sms
spec:
  ports:
  - port: 5432
    protocol: TCP
    targetPort: 5432
  selector:
    app: demo-sms-db
  type: ClusterIP
status:
  loadBalancer: {}

kubectl get svc

kubectl create -f cluster-svc.yml

kubectl get svc

This is the NodePort type. I use the node port number 32110.

apiVersion: v1
kind: Service
metadata:
  labels:
    app: demo-sms-db
  name: demo-sms-db-extenal
  namespace: demo-sms
spec:
  ports:
  - port: 5432
    protocol: TCP
    targetPort: 5432
    nodePort: 32110
  selector:
    app: demo-sms-db
  type: NodePort
status:
  loadBalancer: {}

kubectl create -f node-svc.yml

kubectl get svc

I use pgAdmin4 to connect my Database. 192.168.1.108 is my Kubernetes IP. You need to use the NodePort number, not the actual PostgreSQL port. Then you can connect your database from pgAdmin.

You can see there are no tables because the Prisma database migration has not been applied. But after the backend API container is deployed, you will see the tables.

8. Deploy Backend API on Kubernetes

After the database is successfully deployed, we will deploy the backend API on Kubernetes. In this deployment, I set the replica count to 2 and specify resource requests and limits. I also use an init container to make sure the database is ready before the web app tries to connect.

Explanation of the deployment file

1. namespace: demo-sms : isolating this app into its own virtual cluster.

2. strategy: RollingUpdate : This ensures zero downtime.

   • maxSurge : 1 : Kubernetes will start 1 new Pod before killing an old one.

   • maxUnavailable: 0 : Kubernetes will never have fewer than 2 Pods running during an update.

3. Requests : What the Pod is guaranteed to get (0.25 CPU and 128MB RAM).

4. Limits : The maximum it can consume. If it tries to use more than 256MB RAM, Kubernetes will kill it (OOMKilled) to protect the rest of the cluster.

This is the deploy.yml file.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: demo-sms-api
  name: demo-sms-api
  namespace: demo-sms
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-sms-api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: demo-sms-api
    spec:
      initContainers:
        - name: wait-for-db-up
          image: busybox:1.28
          command: ['sh', '-c', "until nc -zv demo-sms-db-svc 5432; do echo 'Waiting for database...'; sleep 2; done"]
      containers:
      - image: zinlinhtetdevops/demo-sms-api:latest
        name: demo-sms-api
        ports:
        - containerPort: 3000
        env:
          - name: DB_HOST
            value: "demo-sms-db-svc"
          - name: DB_USER
            value: "dbadmin"
          - name: DB_NAME
            value: "uatdb"
          - name: DB_PASSWORD
            valueFrom:
              secretKeyRef:
                name: postgres-secret
                key: postgres-password
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 15
          periodSeconds: 20

kubectl get pods

kubectl create -f deploy.yml

kubectl get deployments

kubectl get pods

kubectl logs -f pods/demo-sms-api-7bb5bc6c97-dtdh9 -c wait-for-db-up

kubectl logs -f pods/demo-sms-api-7bb5bc6c97-dtdh9

Now that we have successfully deployed the backend API, it's time to expose the backend service using the ClusterIP type. However, I want to use a domain name, like api.demo-sms.local, so I will configure the Nginx Ingress Controller.

Why do we need to use the Nginx Ingress Controller?

With MetalLB alone, each service you want to expose (API, Frontend, Admin Dashboard) needs its own unique IP from your 192.168.1.200-205 range. You will run out of IPs very quickly. With Ingress, you use one LoadBalancer IP (e.g., 192.168.1.200) for the NGINX Controller, and it routes traffic to many different services based on the URL.

How it works with MetalLB

In my local setup, the relationship looks like this:

1. MetalLB provides a stable IP (e.g., 192.168.1.200) to the NGINX Ingress Service.

2. My Domain Name (or /etc/hosts file) points to that IP.

3. NGINX Ingress looks at the incoming request and sends it to my demo-sms-api Pod.

So, install and set up the Nginx Ingress Controller on Kubernetes. First we need to expose our backed api service. API service should now be a ClusterIP (internal only), because the Ingress will handle the external traffic.

Here is the svc-cluster.yml file.

apiVersion: v1
kind: Service
metadata:
  labels:
    app: demo-sms-api
  name: demo-sms-api-cluster
  namespace: demo-sms
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 3000
  selector:
    app: demo-sms-api
  type: ClusterIP

kubectl create -f svc-cluster.yml

kubectl get svc

Let’s start to install Nginx Ingress Controller.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml

kubectl get namespace

kubectl get all -n ingress-nginx

kubectl get svc -n ingress-nginx

Now you can see that MetalLB has assigned an IP (192.168.1.200) to the Nginx Ingress Controller load balancer.

Now create the Ingress resource. This is the routing rule that tells NGINX to send traffic to API. Here is the ingress.yml file.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-sms-ingress
  namespace: demo-sms
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: api.demo-sms.local
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: demo-sms-api-cluster
            port:
              number: 80

kubectl create -f ingress.yml

kubectl get ingress -n demo-sms

It's time to access our backend API through the Nginx Ingress Controller. However, you need to map the IP address to the domain name in the /etc/hosts file. Without this, you won't be able to access it using the domain name in local.

sudo vi /etc/hosts

192.168.1.200 api.demo-sms.local

9. Testing with Postman

Now open your browser and enter the domain name. You should see the backend API working properly.

I use Postman to test the basic CRUD operations on my backend API.

By completing this lab, you will have established a robust, scalable, and externally accessible API infrastructure that adheres to Kubernetes best practices for stateful applications and on-premise networking.

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in next articles. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

Imagine you put your AWS key in a GitHub repo, and your GitHub repo gets compromised. Attackers could find and steal your key. Attackers can use your key to create many AWS services, which will increase your cloud bill significantly. If you're using an AWS key in GitHub Actions, you need to regularly rotate the key every month. But, storing or using AWS access and secret keys (long-lived tokens) directly in CI/CD pipelines is considered insecure and not a recommended approach.

If you’re using OIDC instead of an AWS key, you don't need to rotate your OIDC. So what is OIDC? OIDC mean ( OpenID Connect ). OpenID Connect (OIDC) allows your GitHub Actions workflows to access resources in AWS without needing to store AWS credentials as long-lived GitHub secrets. Instead of using password, you just need to setup a Trust Relationship. This means that a GitHub Actions workflow can request a short‑lived OIDC token from GitHub, present it to AWS IAM, and get a temporary role. There is no need to store access keys in secrets.

The main difference is that AWS Access Keys are like a physical key to your house that never expires, while OIDC is like a high-tech "digital badge" that is only valid for a single entry and expires immediately after you leave. In modern CI/CD, OIDC is the industry standard because it eliminates the need to manage, store, or rotate secrets manually.

So let's get started with creating OIDC for our GitHub Actions CI/CD pipeline.

Provider type : OpenID Connect

Provider URL : https://token.actions.githubusercontent.com

Audience : sts.amazonaws.com

name: List VPC

on:
  push:
    branches:
      - main

permissions:
  id-token: write
  contents: read

jobs:
  list_vpc:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_OIDC_ROLE }}
          aws-region: ap-southeast-1

      - name: List VPC
        run: |
          aws ec2 describe-vpcs \
          --query 'Vpcs[*].{VpcID:VpcId, Name:Tags[?Key==`Name`].Value | [0]}' \
          --output table

sudo lsblk

sudo df -hT

sudo growpart /dev/xvda 1

sudo xfs_growfs -d /

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in next articles. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 50. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

What is AWS CloudFormation?

AWS CloudFormation is an Infrastructure as Code (IaC) service that allows you to model, provision, and manage your AWS resources by writing a declarative template.

Instead of manually clicking through the AWS Console to create servers, databases, or networking components, you define your entire infrastructure in a JSON or YAML file. CloudFormation then acts as the "architect," reading your plan and building the resources in the correct order.

Core Concepts

• Template: A text file (YAML or JSON) that serves as the blueprint for your infrastructure. It defines what resources you want (e.g., an EC2 instance or an S3 bucket) and their configurations.

• Stack: When CloudFormation processes a template, it creates a "Stack." This is a single unit of managed resources. If you delete the stack, all resources defined in the template are deleted together.

• Change Sets: Before updating a live environment, you can generate a Change Set. This allows you to see a preview of how proposed changes will impact your running resources before you apply them.

AWSTemplateFormatVersion: '2010-09-09'
Description: CloudFormation template to create a Lambda function and IAM role.

Resources:
  # IAM Role for Lambda Execution
  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: lambda_execution_role
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - lambda.amazonaws.com
            Action:
              - sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

  # Lambda Function
  XfusionLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: xfusion-lambda
      Handler: index.lambda_handler
      Runtime: python3.9
      Role: !GetAtt LambdaExecutionRole.Arn
      Code:
        ZipFile: |
          import json

          def lambda_handler(event, context):
              message = "Welcome to KKE AWS Labs!"
              print(message)
              return {
                  'statusCode': 200,
                  'body': json.dumps(message)
              }

Outputs:
  LambdaArn:
    Description: ARN of the created Lambda function.
    Value: !GetAtt XfusionLambdaFunction.Arn

aws cloudformation validate-template --template-body file:///root/xfusion-lambda.yml

aws cloudformation create-stack --stack-name xfusion-lambda-app --template-body file:///root/xfusion-lambda.yml --capabilities CAPABILITY_NAMED_IAM

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 49. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Nautilus DevOps Priority Queuing System'

Resources:
  HighPriorityQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: datacenter-High-Priority-Queue

  LowPriorityQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: datacenter-Low-Priority-Queue

  PriorityTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: datacenter-Priority-Queues-Topic

  HighPrioritySubscription:
    Type: AWS::SNS::Subscription
    Properties:
      TopicArn: !Ref PriorityTopic
      Endpoint: !GetAtt HighPriorityQueue.Arn
      Protocol: sqs
      FilterPolicy:
        priority:
          - high

  LowPrioritySubscription:
    Type: AWS::SNS::Subscription
    Properties:
      TopicArn: !Ref PriorityTopic
      Endpoint: !GetAtt LowPriorityQueue.Arn
      Protocol: sqs
      FilterPolicy:
        priority:
          - low

  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: lambda_execution_role
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      # Using Managed Policies to avoid PutRolePolicy permission errors in labs
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
        - arn:aws:iam::aws:policy/AmazonSQSFullAccess

  PriorityLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: datacenter-priorities-queue-function
      Handler: index.lambda_handler
      Role: !GetAtt LambdaExecutionRole.Arn
      Runtime: python3.9
      Timeout: 10
      Environment:
        Variables:
          high_priority_queue: !Ref HighPriorityQueue
          low_priority_queue: !Ref LowPriorityQueue
      Code:
        ZipFile: |
          import boto3
          import os
          sqs = boto3.client('sqs')
          def delete_message(queue_url, receipt_handle, message):
              response = sqs.delete_message(QueueUrl=queue_url, ReceiptHandle=receipt_handle)
              return "Message " + "'" + message + "'" + " deleted"
          def poll_messages(queue_url):
              response = sqs.receive_message(
                  QueueUrl=queue_url,
                  MaxNumberOfMessages=1,
                  MessageAttributeNames=['All'],
                  WaitTimeSeconds=3
              )
              if "Messages" in response:
                  receipt_handle=response['Messages'][0]['ReceiptHandle']
                  message = response['Messages'][0]['Body']
                  return delete_message(queue_url, receipt_handle, message)
              else:
                  return "No more messages to poll"
          def lambda_handler(event, context):
              response = poll_messages(os.environ['high_priority_queue'])
              if response == "No more messages to poll":
                  response = poll_messages(os.environ['low_priority_queue'])
              return response

  SqsQueuePolicy:
    Type: AWS::SQS::QueuePolicy
    Properties:
      Queues:
        - !Ref HighPriorityQueue
        - !Ref LowPriorityQueue
      PolicyDocument:
        Statement:
          - Effect: Allow
            Principal:
              Service: sns.amazonaws.com
            Action: sqs:SendMessage
            Resource: "*"
            Condition:
              ArnEquals:
                aws:SourceArn: !Ref PriorityTopic

aws cloudformation create-stack --stack-name datacenter-priority-stack --template-body file:///root/datacenter-priority-stack.yml --capabilities CAPABILITY_NAMED_IAM

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 48. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

What is Amazon Lambda?

In AWS, a Lambda function is a piece of code that runs in a "serverless" environment. "Serverless" means AWS manages all the infrastructure for you. You don't need to set up, update, or scale virtual machines. You just upload your code, and Lambda runs it whenever it's needed.

What is DynamoDB?

Amazon DynamoDB is a serverless, fully managed NoSQL database service from AWS. It delivers high performance with single-digit millisecond latency at any scale, making it ideal for modern web and mobile apps.

Unlike traditional relational databases (like MySQL or PostgreSQL) that use fixed tables and columns, DynamoDB is a key-value and document database. This means it is very flexible and can store semi-structured data without needing a pre-defined schema.

aws s3 ls s3://xfusion-private-19833/

aws s3 cp /root/sample.zip s3://xfusion-public-8757/

aws s3 ls s3://xfusion-private-19833/

aws dynamodb scan --table-name xfusion-S3CopyLogs

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 47. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 46. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

#!/bin/bash
sudo yum update -y

sudo amazon-linux-extras install nginx1 -y

sudo systemctl start nginx

sudo systemctl enable nginx

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 45. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

What is AWS EKS?

AWS EKS (Amazon Elastic Kubernetes Service) is a managed Kubernetes service provided by Amazon Web Services that makes it easy to run, manage, and scale Kubernetes clusters on AWS.

What does AWS EKS do?

AWS EKS runs the Kubernetes control plane for you, so you don’t need to install or maintain:

• Kubernetes master nodes

• etcd database

• Control plane security patches

• Kubernetes version upgrades

You focus only on deploying and managing your applications.

Key Components of AWS EKS

1️⃣ Control Plane (Managed by AWS)

AWS manages:

• API Server

• Scheduler

• Controller Manager

• etcd (cluster state)

✔ Highly available
✔ Secure
✔ Automatically patched

2️⃣ Worker Nodes (Managed by You or AWS)

These run your applications (pods).

You can choose:

• EC2 worker nodes (full control)

• Managed Node Groups (AWS-managed EC2)

• AWS Fargate (serverless, no EC2 to manage)

Why use AWS EKS?

✅ High Availability

• Control plane runs across multiple Availability Zones

✅ Security

• Integrated with IAM

• Supports private cluster endpoints

• Works with VPC security groups

✅ Scalability

• Auto scaling for nodes and pods

• Handles large production workloads

✅ Kubernetes Compatible

• Fully CNCF-certified Kubernetes

• Use standard Kubernetes tools and manifests

When should you use EKS?

Use EKS when:

• You want Kubernetes in production

• You need high security and availability

• You already use AWS services (ALB, IAM, VPC, RDS, S3, etc.)

• You want less operational overhead

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 44. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

What is DynamoDB?

Amazon DynamoDB is a fully managed NoSQL database service provided by AWS (Amazon Web Services). It is designed to store and retrieve large amounts of data very fast, with high availability and automatic scaling, without you needing to manage servers.

🔹 Key Characteristics of DynamoDB

1️⃣ NoSQL Database

• Stores data as items (similar to rows)

• Items are grouped into tables

• Uses key–value and document data models

• Schema is flexible (attributes can vary per item)

2️⃣ Fully Managed by AWS

You don’t manage:

• Servers

• Operating systems

• Patching

• Backups

• Scaling

AWS handles all of this automatically.

3️⃣ Extremely Fast Performance

• Single-digit millisecond latency

• Designed for high-traffic applications

• Handles millions of requests per second

4️⃣ Highly Scalable

• Automatically scales read and write capacity

• Supports on-demand and provisioned capacity modes

5️⃣ High Availability & Durability

• Data is replicated across multiple Availability Zones

• Built-in fault tolerance

• Designed for 99.999% availability

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 43. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

What is AWS KMS?

AWS Key Management Service (KMS) is a managed service that makes it easy for you to create and control the cryptographic keys used to protect your data. It provides a highly available, secure, and centralized hub for managing encryption across your entire AWS environment.

Core Functions of AWS KMS

AWS KMS handles the "heavy lifting" of cryptography so you don't have to manage complex hardware or software.

• Key Lifecycle Management: You can create, rotate, disable, and delete keys.

• Centralized Control: Manage permissions for who can use or manage keys through IAM (Identity and Access Management) and Key Policies.

• Auditability: Every time a key is used, it is logged in AWS CloudTrail, allowing you to see exactly who used a key, when, and for what resource.

• High Security: Keys are protected by FIPS 140-2 validated Hardware Security Modules (HSMs). Plaintext master keys never leave these modules.

#Create the Key
aws kms create-key --description "Nautilus datacenter-KMS-Key"

#Create the alias
aws kms create-alias --alias-name alias/datacenter-KMS-Key --target-key-id <your-key-id>

#Encrypt and encode the file
aws kms encrypt \
    --key-id alias/datacenter-KMS-Key \
    --plaintext fileb:///root/SensitiveData.txt \
    --query CiphertextBlob \
    --output text | base64 --decode > /root/EncryptedData.bin

#Decrypt the file
aws kms decrypt \
    --ciphertext-blob fileb:///root/EncryptedData.bin \
    --query Plaintext \
    --output text | base64 --decode > /root/DecryptedData.txt

#Compare Results
diff /root/SensitiveData.txt /root/DecryptedData.txt

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 42. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 41. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

aws s3 cp index.html s3://devops-web-15019

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 40. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

What is AWS ECS?

Amazon Elastic Container Service (ECS) is a fully managed container orchestration service provided by AWS. It allows you to run, scale, and manage Docker containers without having to install or operate your own cluster management software.

Core Concepts

• Task Definition: A JSON file (the "blueprint") that describes one or more containers. It specifies parameters like the Docker image to use, how much CPU/Memory is needed, and which ports should be open.

• Task: An "instance" of a Task Definition. This is the actual running container (or group of containers) on your cluster.

• Service: Manages the "desired state" of your tasks. For example, if you tell a Service to run 3 copies of a task, it will automatically restart any that crash to ensure 3 are always running.

• Cluster: A logical grouping of your tasks and services.

cd /root/pyapp/

ls

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 198646816501.dkr.ecr.us-east-1.amazonaws.com

docker build -t xfusion-ecr .

docker tag xfusion-ecr:latest 198646816501.dkr.ecr.us-east-1.amazonaws.com/xfusion-ecr:latest

docker push 198646816501.dkr.ecr.us-east-1.amazonaws.com/xfusion-ecr:latest

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 39. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 38. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

sudo apt install nginx -y

sudo systemctl start nginx

sudo systemctl enable --now nginx

sudo systemctl status nginx

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 37. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 36. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.

vi lambda_function.py

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "body": "Welcome to KKE AWS Labs!"
    }

zip function.zip lambda_function.py

aws iam get-role --role-name lambda_execution_role

aws lambda create-function --function-name xfusion-lambda-cli --runtime python3.9 --role arn:aws:iam::123456789012:role/lambda_execution_role --handler lambda_function.lambda_handler --zip-file fileb://function.zip

aws lambda invoke --function-name xfusion-lambda-cli response.json

Congratulations you did it. It looks good. This lab was successfully completed without any errors. See you in day 35. If you have any issues please let me know I will be happy to assist you. Stay tuned and learn together. If you find my article useful, please kindly like and share it.