DEV Community: Hyelngtil Isaac

Automated End-to-End CI/CD Pipeline via AWS CodePipeline

Hyelngtil Isaac — Wed, 26 Aug 2026 10:24:06 +0000

Project Scope: A comprehensive implementation guide for building a fully automated continuous integration and continuous deployment (CI/CD) pipeline using AWS developer tools and GitHub: AWS CodeArtifact, AWS CodeBuild, and AWS CodeDeploy via AWS CodePipeline.

1. Executive Summary & Project Reflection

Overview:
This runbook details the end-to-end architecture and deployment of an automated CI/CD pipeline. The project is broken down into six distinct phases: provisioning a cloud-based development environment, integrating source control, securing package dependencies, configuring continuous integration, defining continuous deployment, and finally, orchestrating the entire workflow via an event-driven pipeline.

Key Tools and Concepts:
Services utilized include Amazon EC2, AWS IAM, GitHub, AWS CodeArtifact, Amazon S3, AWS CodeBuild, AWS CloudFormation, AWS CodeDeploy, and AWS CodePipeline. Key concepts mastered include Infrastructure as Code (IaC), event-driven triggers, immutable artifact transitions, least-privilege IAM enforcement, and disaster recovery via automated rollbacks.

Project Reflection:
This architecture requires approximately 3 hours to provision from scratch across all phases. The most challenging aspect was architecting fine-grained, cross-service IAM policies to enforce least-privilege access across pipeline stages. The most rewarding milestone was successfully troubleshooting permission errors, watching event-driven GitHub trigger automated runs, and seeing the entire end-to-end CI/CD workflow execute and deploy to the target EC2 fleet with zero manual intervention.

2. Prerequisites & Baseline Requirements

Before initializing the pipeline, the following baseline configurations must be established:

AWS Account: Active AWS account with IAM Admin privileges (avoid using the Root user).
Local IDE: Antigravity IDE or VS Code installed locally with the "Remote - SSH" extension enabled.
GitHub Account: Active GitHub account for source control integration.

Part 1: Set Up a Web App in the Cloud

To ensure a consistent and isolated development environment, the project begins by provisioning a cloud-based IDE host to write and compile the application code.

1.1 Development EC2 Instance Provisioning

The development environment is hosted on an Amazon EC2 instance.

Instance Setup: Provisioned an Amazon Linux 2023 EC2 instance (t2.micro or t3.micro) depending on the Region.
Security & Access: Generated a new RSA .pem key pair (keypair.pem) for secure SSH access.
Network Inbound Rules: Restricted the Security Group inbound rules to allow SSH (Port 22) traffic strictly from the developer's local IP address (appending /32 for CIDR notation).

1.2 Remote SSH & Environment Bootstrapping

To interact with the EC2 instance securely, we configure an SSH tunnel from the local Antigravity IDE environment.

Secure the Key Pair: Locally stored the .pem file in a dedicated DevOps directory and restricted file permissions to enforce read-only access for the current user. * Mac/Linux: chmod 400 keypair.pem * Windows (PowerShell): icacls "keypair.pem" /inheritance:r /grant:r "$($env:USERNAME):R"
SSH Tunneling: Utilized the Antigravity IDE Remote - SSH extension to connect to the instance using the command:
```
ssh -i keypair.pem ec2-user@<YOUR_EC2_PUBLIC_IPV4_DNS>
```

1.3 Toolchain Installation & Application Scaffolding

Once tunneled into the EC2 instance, the environment requires specific tools to build Java applications.

Install Java & Maven:
Bootstrapped the instance by installing Java 8 (Amazon Corretto) and Apache Maven 3.5.2 via the terminal. Export the $JAVA_HOME and $PATH environment variables within ~/.bashrc to ensure persistence across sessions.

# Maven
wget https://archive.apache.org/dist/maven/maven-3/3.5.2/binaries/apache-maven-3.5.2-bin.tar.gz
sudo tar xzf apache-maven-3.5.2-bin.tar.gz -C /opt
echo 'export PATH=/opt/apache-maven-3.5.2/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

#Java
sudo dnf install -y java-1.8.0-amazon-corretto-devel
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-amazon-corretto.x86_64
export PATH=$JAVA_HOME/jre/bin/:$PATH

# Verification Commands
java -version
mvn -v

Generate the Web App:
Utilized Maven's archetype:generate command to scaffold a standard Java web application directory structure.

mvn archetype:generate \
   -DgroupId=com.hye.app \
   -DartifactId=hye-web-app \
   -DarchetypeArtifactId=maven-archetype-webapp \
   -DinteractiveMode=false

Part 2: Connect a GitHub Repo with AWS

Version control is the foundation of any CI/CD pipeline. This phase establishes the upstream repository, ensuring the web application's codebase is securely tracked and centralized before being consumed by downstream CI/CD services.

2.1 Git Initialization & Upstream Connection

To bridge the local development environment on the EC2 instance with GitHub, we initialize a local repository and establish the remote origin.

Local Git Setup:
Within the Antigravity IDE terminal (connected to the EC2 instance via SSH), navigate to the root of the newly scaffolded Maven project (hye-web-app). Initialize the repository and stage the files:
```
cd hye-web-app
git init
git add .
git commit -m "Initial commit"
```
GitHub Repository Creation:
Navigate to GitHub and create a new private repository (e.g., hye-web-app). This acts as the central source of truth for the CI/CD pipeline.
Push to Upstream:
Link the local EC2 directory to the GitHub repository and push the master branch using your secure GitHub credentials (Personal Access Token):
```
git remote add origin [https://github.com/](https://github.com/)<your-username>/hye-web-app.git
git branch -M master
git push -u origin master
```

Part 3: Secure Packages with CodeArtifact

To maintain software supply chain security and ensure deterministic builds, external Maven dependencies must be proxied and cached through a secure, private repository rather than downloading them directly from the public internet during every build.

3.1 CodeArtifact Repository Setup

Provisioning: In the AWS Console, navigate to AWS CodeArtifact and create a new domain (e.g., hye-cicd-domain) and a repository (e.g., hye-cicd-codeartifact-repo).
Upstream Configuration: Ensure the repository is configured with maven-central-store as its upstream connection so it can successfully proxy public Java packages.

3.2 IAM Role & Policy Configuration

The EC2 instance requires explicit permissions to authenticate with CodeArtifact. We enforce least-privilege access using AWS IAM.

Create IAM Policy: Create a custom JSON policy (hye-codeartifact-access-policy) granting token retrieval and read access:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codeartifact:GetAuthorizationToken",
                "codeartifact:GetRepositoryEndpoint",
                "codeartifact:ReadFromRepository"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "sts:GetServiceBearerToken",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "sts:AWSServiceName": "codeartifact.amazonaws.com"
                }
            }
        }
    ]
}

Attach to EC2: Create an IAM Role (Hye-DevOps-Instance-CodeArtifact-Role) with EC2 as the trusted entity, attach the policy above, and map this role to the running development EC2 instance via the EC2 console (Actions > Security > Modify IAM role).

3.3 Maven Authentication & Configuration

With IAM permissions in place, Maven must be configured to route package requests through the CodeArtifact endpoint.

Generate Auth Token:
In the Antigravity IDE terminal (EC2 instance), use the AWS CLI to extract a temporary CodeArtifact authorization token and export it as an environment variable:

export CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token --domain hye-cicd-domain --domain-owner <YOUR_ACCOUNT_ID> --region <YOUR_REGION> --query authorizationToken --output text`

Configure settings.xml:
In the root of your project (hye-web-app), create a settings.xml file. Populate it with the CodeArtifact connection instructions (provided in the CodeArtifact console), ensuring the <password> tag references the environment variable: ${env.CODEARTIFACT_AUTH_TOKEN}.
Compile & Verify:
Execute a Maven compile command pointing to the custom settings file to force the application to download dependencies via the private CodeArtifact repository:
```
mvn compile -s settings.xml
```

Part 4: Continuous Integration with CodeBuild

This phase automates the compilation, testing, and packaging of the web application into an immutable artifact. By utilizing AWS CodeBuild, we provision an isolated, stateless Linux container that pulls the source code, resolves dependencies securely via CodeArtifact, and compiles a deployable target.

4.1 S3 Artifact Store Provisioning

Before creating the build project, we need a centralized staging area to store the compiled output.

Provision S3 Bucket: Navigate to the Amazon S3 console and create a new bucket (e.g., hye-codebuild-artifact-store).
Configuration: Leave all settings as default (Block all public access enabled). This bucket will serve as the secure artifact transition mechanism between the Build and Deploy stages of the pipeline.

4.2 CodeBuild Project Initialization

Create Project: Navigate to AWS CodeBuild and create a new build project named hye-cicd-codebuild-project.
Source Control Integration:
- Set the Source provider to GitHub.
- Connect CodeBuild to your GitHub account using the GitHub App connection.
- Select the private repository you created in Part 2 (hye-web-app).

Environment Settings:
- Environment image: Managed image
- Operating system: Amazon Linux
- Runtime: Standard
- Image: Select the latest aws/codebuild/amazonlinux2-x86_64-standard:corretto8 image.
- Service role: Select New service role (CodeBuild will automatically generate a least-privilege IAM role for this project).

4.3 IAM Role Modification (CodeArtifact Authorization)

The CodeBuild container must securely pull Maven dependencies from our private CodeArtifact repository. We must explicitly grant CodeBuild's newly created IAM service role access to CodeArtifact.

Locate Service Role: In the IAM Console, find the role automatically generated by CodeBuild (e.g., Hye-cicd-CodeBuild-Project-Role).
Attach Policy: Attach the hye-codeartifact-access-policy (created in Part 3) to this role. This ensures the build container has the exact same least-privilege token retrieval permissions as our development EC2 instance.

4.4 Define Build Directives (`buildspec.yml`)

AWS CodeBuild requires a declarative YAML file to execute build phases.

Create Buildspec: In your local Antigravity IDE terminal, create a buildspec.yml file in the root directory of your project.

Author Directives: Define the installation, pre-build (CodeArtifact authentication), build (Maven compile), and post-build (Artifact packaging) phases:

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto8
  pre_build:
    commands:
      - echo Logging in to AWS CodeArtifact...
      - CODEARTIFACT_AUTH_TOKEN=`aws codeartifact get-authorization-token --domain hye-cicd-domain --domain-owner <YOUR_ACCOUNT_ID> --region <YOUR_REGION> --query authorizationToken --output text`
      - export CODEARTIFACT_AUTH_TOKEN
  build:
    commands:
      - echo Build started on `date`
      - mvn clean install -s settings.xml
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Packaging artifacts...
      - mvn package -s settings.xml
      - chmod +x scripts/*.sh
artifacts:
  files:
    - target/*.war
    - scripts/**/*
    - appspec.yml
  discard-paths: no

Commit & Push: Add, commit, and push the buildspec.yml file to the GitHub master branch so CodeBuild can read the execution instructions.

4.5 Build Execution & Artifact Verification

Trigger Build: In the AWS CodeBuild console, manually click Start build to validate the configuration.
Monitor Logs: CodeBuild will provision the container, download the source from GitHub, authenticate with CodeArtifact, and execute the Maven build. Monitor the real-time Phase Details for success.
Artifact Output: Upon a successful build phase, CodeBuild extracts the compiled .war file (defined in the artifacts block of the buildspec) and prepares it for downstream deployment.

Part 5: Deploy a Web App with CodeDeploy

This phase provisions the live production infrastructure and automates the continuous delivery process. Instead of manually copying files and restarting services, AWS CodeDeploy will orchestrate the deployment of our compiled .war artifact directly to the target web servers with zero downtime.

5.1 Infrastructure as Code (CloudFormation)

To ensure our production environment is reproducible and isolated from our development environment, we will provision the target EC2 fleet using Infrastructure as Code (IaC).

Navigate to CloudFormation: Open the AWS CloudFormation console and click Create stack > With new resources (standard).
Upload Template: Select Upload a template file and upload your declarative YAML configuration file hye-web-app.yaml. This template is pre-configured to:
- Provision a production-ready Amazon Linux EC2 instance.
- Automatically install the AWS CodeDeploy Agent via user data scripts.
- Attach the necessary IAM Instance Profile allowing S3 read access (to fetch the artifact).
- Configure Security Groups to allow inbound HTTP (Port 80) and SSH (Port 22) traffic.
Configure Stack Details:
- Stack name: hye-cicd-ec2-server-stack
- MyIP: Enter your local IP address appended with /32 (e.g., 192.168.1.1/32) to secure SSH access.
Execute Deployment: Acknowledge the IAM resource creation capabilities and click Submit. Wait for the stack status to reach CREATE_COMPLETE.

5.2 CodeDeploy Orchestration Setup

With the infrastructure running, we must configure CodeDeploy to target the new instances.

Create Application:
- Navigate to AWS CodeDeploy > Applications > Create application.
- Application name: hye-cicd-codedeploy-application
- Compute platform: EC2/On-premises

Create Deployment Group:
- Inside the application, click Create deployment group.
- Deployment group name: hye-cicd-codedeploy-deployment-group
- Service role: Select the IAM role granting CodeDeploy access to read target instances (e.g., Hye-cicd-CodeDeploy-Role).

*   **Environment configuration:** Select **Amazon EC2 instances**. Use Tag keys to target the instance provisioned by CloudFormation (e.g., Key: `role`, Value: `webserver`).
*   **Agent configuration:** Select `Never` (the CloudFormation template already installed the CodeDeploy agent).
*   **Load balancer:** Uncheck 'Enable load balancing' (we are using a single instance for this architecture).

5.3 Define Deployment Directives (`appspec.yml`)

AWS CodeDeploy relies on an AppSpec file to understand exactly where to place files and which lifecycle scripts to run during the deployment.

Create appspec.yml: In your local Antigravity IDE terminal, create an appspec.yml file at the absolute root of your project directory.

Author Directives: Define the OS, files destination, and the lifecycle hooks.

version: 0.0
os: linux
files:
  - source: /target/hye-web-app.war
    destination: /usr/share/tomcat/webapps/
hooks:
  BeforeInstall:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 300
      runas: root

Create Lifecycle Scripts: Create a scripts folder and add the referenced bash files (stop_server.sh and start_server.sh). These scripts instruct the target instance to stop the Tomcat web server, clear the old cache, and start it back up once the new .war file is unpacked.
Commit & Push: Add, commit, and push the appspec.yml and scripts/ directory to the GitHub master branch.

5.4 Manual Deployment Verification

Before automating the workflow, we must verify that CodeDeploy can successfully execute the AppSpec directives using the latest S3 artifact.

Create Deployment: In the CodeDeploy console, navigate to your deployment group and click Create deployment.
Revision Type: Select My application is stored in Amazon S3.
Revision Location: Paste the S3 URI of the latest .zip artifact compiled by CodeBuild in Part 4.

Deploy: Click Create deployment.
Monitor Lifecycle Events: CodeDeploy will execute the AppSpec hooks. Monitor the stages (DownloadBundle, BeforeInstall, Install, ApplicationStart).
Verify Live App: Once successful, navigate to the production EC2 instance's Public IPv4 DNS in your browser. You should see the Java web application rendering live.

Part 6: Build a CI/CD Pipeline with AWS

The final phase unites all previously configured components (GitHub, CodeArtifact, CodeBuild, CodeDeploy) into a single, fully automated, event-driven orchestration engine using AWS CodePipeline.

6.1 Pipeline Initialization & State Management

When creating the pipeline, specific execution and authentication parameters must be set to ensure deployment consistency and security.

Create Pipeline: Navigate to AWS CodePipeline and select Create pipeline.
Pipeline Settings:
- Pipeline category: Buid custom pipeline

*   **Pipeline name:** `hye-cicd-codepipeline`
*   **Execution mode:** `Superseded`. This mode ensures that newer pipeline executions automatically cancel and override in-flight runs, guaranteeing only the absolute latest commit is deployed.
*   **Service role:** Select **New service role** to generate least-privilege IAM permissions.

6.2 Stage 1: Source Control Integration

The Source stage defines the trigger mechanism, monitoring the specified Git branch for commit events via webhooks.

Source Provider: Select GitHub (Version 2) and authorize the AWS Connector for GitHub.
Repository & Branch: Select the hye-web-app repository and the master branch.
Output Artifact: Set the output artifact format to CodePipeline default (SourceArtifact).
Webhook events: Enable the Start your pipeline on push and pull request events check-box.

6.3 Stage 2: Continuous Integration (Build)

The Build stage is responsible for transforming raw source code into a deployable package.

Build Provider: Select AWS CodeBuild.
Region & Project: Select your region and the hye-cicd-codebuild-project CodeBuild project created in Part 4.
Input & Output:
- Input artifacts: Map to SourceArtifact (the ZIP file generated by Stage 1).
- Output artifacts: Define a new namespace, BuildArtifact (this represents the compiled .war file).

6.4 Stage 3: Continuous Deployment (Deploy)

The final stage provisions the compiled application artifact to the live EC2 infrastructure.

Deploy Provider: Select AWS CodeDeploy.
Application & Group: Select the hye-cicd-codedeploy-application application and the hye-cicd-codedeploy-deployment-group deployment group created in Part 5.
Input Artifact: Map to BuildArtifact (the compiled package generated by Stage 2).

7. Execution, Testing, & Validation

To prove the pipeline's end-to-end automation, a live code change must be pushed to the upstream repository.

7.1 Triggering the Pipeline via Code Change

Open the application source code in your local Antigravity IDE terminal.
Navigate to the primary web page file: src/main/webapp/index.jsp.

Inject a visible UI change, for example:

<p>If you see this lines, that means your latest changes are automatically deployed into production by CodePipeline!</p>
<p>If you see this lines, that means your latest changes are automatically deployed into production by CodePipeline for the second time!</p>
<p>That's how easy it can get.</p>

Commit and push the code to the tracked branch:

git add .
git commit -m "Update index.jsp to verify automated CI/CD deployment."
git push

7.2 Monitoring Automated Orchestration

Immediately upon pushing the code, navigate to the AWS CodePipeline console.

The GitHub webhook will have dispatched a payload, initiating a new execution graph.
The commit message under the Source stage will reflect your recent git commit.
Monitor cross-stage transitions as CodeBuild compiles the WAR package and CodeDeploy initiates the in-place deployment to the EC2 fleet.

7.3 Live Production Verification

Locate the Public IPv4 DNS of your production EC2 instance.
Navigate to this address in a standard web browser.
The updated application revision (featuring the newly added HTML paragraph tag) will render live, validating zero-touch, zero-downtime release orchestration.

8. Disaster Recovery: Automated Rollback Validation

A critical component of a robust CI/CD pipeline is the ability to recover from bad deployments instantly. To validate disaster recovery protocols, a manual rollback is initiated to simulate an emergency reversion.

8.1 Executing the Rollback

In the CodePipeline console, locate the Deploy stage.
Click the options menu (three dots) on the Deploy stage card and select Start rollback.
Select the previous stable execution ID from the dropdown menu and confirm the rollback.

8.2 Validating State Isolation and Recovery

Result: CodeDeploy successfully restores the last known good deployment artifact to the EC2 instance. Navigating to the EC2 instance's Public IPv4 DNS confirms the web page displays the previous version (the test paragraph tag is removed).
State Isolation Proof: The Source and Build stages are entirely unaffected. They retain the latest Git commit SHA and message, while only the Deploy stage reverts its execution state to the previous stable revision. This proves that CodeDeploy rollback actions are isolated to the deployment environment and do not destructively invalidate S3 build artifacts or overwrite the upstream GitHub repository state.

Congratulations! You now have a fully functional end-to-end CI/CD pipeline for a Java web application hosted on AWS!

Deploy Backend with Kubernetes

Hyelngtil Isaac — Sun, 02 Aug 2026 14:32:05 +0000

Introducing Today's Project!

In this project, I will deploy a containerized backend application to an Amazon EKS cluster because it provides a highly scalable, managed orchestration environment. This involves building a Docker image, pushing it to Amazon ECR, and defining the infrastructure state using Kubernetes Deployment and Service manifests applied via kubectl.

Tools and concepts

Key tools utilized include eksctl for Amazon EKS cluster provisioning, Docker for containerization, Amazon ECR for secure image storage, and kubectl for resource management. Core concepts demonstrated are Kubernetes orchestration, declarative state management via YAML manifests (Deployments and Services), immutable container deployments, and internal cluster networking using NodePort configurations.

Project reflection

This project took me approximately 90 minutes to complete. My favourite part was executing the kubectl apply commands to orchestrate the immutable backend container and establish NodePort routing across the distributed EKS worker nodes.

Project Set Up

Kubernetes cluster

To set up today's project, I launched a Kubernetes cluster using the eksctl CLI on a provisioned EC2 instance. The cluster's role in this deployment is to serve as a managed orchestration control plane via Amazon EKS, automating the scheduling, scaling, and networking of the containerized backend across a 3-node t3.micro compute group.

Error above showing `eksctl` not installed.
To install it, I ran; 
`curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv -v /tmp/eksctl /usr/local/bin
`

Backend code

I retrieved backend code by executing a git clone command on the provisioned EC2 instance to pull the remote nextwork-flask-backend repository. Pulling code is essential to this deployment because the repository contains the Python application source files and the Dockerfile required to compile the standardized, immutable container image that Kubernetes will orchestrate.

Container image

Once I cloned the backend code, I built a container image because it creates a standardized, immutable package containing the application source and all necessary dependencies. Without an image, it would be difficult for Kubernetes to reliably provision identical, scalable container replicas across the cluster nodes, as the orchestrator requires a centralized, consistent artifact for deployment.

I also pushed the container image to a container registry, which is Amazon Elastic Container Registry (ECR), a fully managed, secure AWS repository for container artifacts. ECR facilitates scaling for my deployment because its native IAM integration with Amazon EKS enables the Kubernetes control plane to rapidly authenticate and pull immutable image replicas across distributed worker nodes on demand.

Manifest files

Kubernetes manifests are declarative YAML configuration files that define the desired state of cluster resources, specifying parameters such as container images, replica counts, and resource allocations. Manifests are helpful because they automate application orchestration, enabling reproducible, consistent deployments while eliminating the operational overhead and error-prone nature of manual container configuration.

A Deployment manifest manages the desired state of application replicas by automating the creation, scaling, and rolling updates of container groups across the cluster. The container image URL in my Deployment manifest tells Kubernetes the exact Amazon ECR registry location to authenticate against and pull the immutable Docker artifact from when provisioning new pods.

A Service resource exposes deployed applications to network traffic by establishing stable routing rules across dynamic pod replicas. My Service manifest sets up a NodePort configuration, instructing the Kubernetes control plane to map external node port requests to internal target port 8080 on pods bearing the app:nextwork-flask-backend label.

Backend Deployment!

To deploy my backend application, I updated the local kubeconfig using the AWS CLI to authenticate with the Amazon EKS control plane. Next, I executed the kubectl apply command on the Deployment and Service YAML manifests to schedule the container replicas and establish NodePort routing rules across the cluster.

kubectl

kubectl is the primary command-line interface for interacting with the Kubernetes control plane. I need this tool to authenticate with the EKS cluster and apply the declarative YAML manifests that orchestrate the application deployment. I can't use eksctl for the job because it is specifically designed for provisioning and managing the underlying EKS infrastructure, not for scheduling workloads or managing internal Kubernetes resources.

Verifying Deployment

My extension for this project is to use the EKS console to verify the deployment status, inspect the provisioned node groups, and confirm that the backend pods are running successfully. I had to set up IAM access policies because AWS IAM permissions do not automatically grant authorization within the internal Kubernetes RBAC system. I set up access by executing the eksctl create iamidentitymapping command to map my IAM User ARN to the Kubernetes system:masters group.

Once I gained access into my cluster's nodes, I discovered pods running inside each node. Pods are the smallest deployable units in Kubernetes, designed to bundle one or more containers together to function as a cohesive workload. Containers in a pod share the same network address space and underlying storage resources, which enables efficient inter-process communication and localized data synchronization.

The EKS console shows you the events for each pod, where I could see the control plane's sequence of operations, including internal IP assignment, image retrieval from Amazon ECR, and container initialization. This validated that the backend application was successfully provisioned, actively running, and accessible within the internal cluster network.

🤝 Thank you for reading thus far. Next project will be a DevOps Challenge.

Build a Three-Tier Web App

Hyelngtil Isaac — Fri, 24 Jul 2026 14:41:44 +0000

Introducing Today's Project!

In this project, I will demonstrate how to architect and deploy a serverless three-tier application by hosting static web assets in Amazon S3 delivered globally via Amazon CloudFront, executing business logic using AWS Lambda routed through Amazon API Gateway, and managing persistence with Amazon DynamoDB.

I'm doing this project to demonstrate end-to-end integration of serverless AWS components, cross-origin resource sharing (CORS) configurations, least-privilege IAM policies, and cloud troubleshooting practices.

Tools and concepts

Services I used were Amazon S3, Amazon CloudFront, AWS Lambda, Amazon API Gateway, and Amazon DynamoDB. Key concepts I learnt include Lambda functions, serverless three-tier architecture, API REST routing, Cross-Origin Resource Sharing (CORS) configurations, Origin Access Control (OAC), and NoSQL partition key database management.

Project reflection

This project took me approximately 150 minutes. The most challenging part was debugging the Cross-Origin Resource Sharing (CORS) restrictions between the CloudFront distribution and the API Gateway. It was most rewarding to successfully deploy a decoupled, serverless three-tier architecture while enforcing secure HTTP routing and least-privilege IAM policies.

I chose to do this project today because validating secure, decoupled serverless architectures and enforcing strict IAM policies perfectly aligns with my core focus on cloud engineering and cybersecurity.

Presentation tier

For the presentation tier, I will set up an Amazon S3 bucket to store static frontend assets (index.html, style.css, script.js) and an Amazon CloudFront CDN distribution configured with Origin Access Control (OAC) because this provides scalable, low-latency global web content delivery while securely restricting direct public access to the underlying storage bucket.

I accessed my delivered website by requesting the domain name assigned to the CloudFront distribution via HTTPS, which securely retrieved and served the cached static frontend files from edge locations using Origin Access Control permissions to query the origin S3 bucket.

Logic tier

For the logic tier, I will set up AWS Lambda functions and an Amazon API Gateway REST API because API Gateway acts as the secure entry point for HTTP requests from the frontend, routing them to Lambda to execute serverless backend business logic and process application data without managing underlying server infrastructure.

The Lambda function retrieves data by parsing the userId query parameter from the incoming HTTP request event and using the AWS SDK DynamoDB Document Client (GetCommand) to execute a read request against the target DynamoDB table (UserData).

Data tier

For the data tier, I will set up an Amazon DynamoDB NoSQL table named UserData with a primary partition key of userId because it provides a fully managed, high-performance, and schemaless storage layer for persistent application data that scales seamlessly without server management overhead.

The partition key for my DynamoDB table is userId, which means DynamoDB uses this unique attribute value to hash and route data items across underlying physical partitions, enabling efficient, single-digit millisecond key-value lookups and persistent storage for application user records.

Logic and Data tier

Once all three layers of my three-tier architecture are set up, the next step is to integrate the presentation layer with the logic tier by updating script.js to target the API Gateway Invoke URL because this establishes end-to-end communication, allowing the frontend to trigger Lambda functions and retrieve DynamoDB data.

To test my API, I appended the /users?userId=1 path and query string parameter directly to the API Gateway prod stage Invoke URL and executed the HTTP GET request in a web browser. The results were successful, returning a 200 OK HTTP response containing the JSON payload from the DynamoDB table.

Console Errors

The error in my distributed site was because the frontend script.js file contained an unresolved placeholder ([YOUR-PROD-API-URL]) instead of the active Amazon API Gateway Invoke URL, preventing the client browser from successfully routing HTTP requests to the backend logic tier.

To resolve the error, I updated script.js by replacing the [YOUR-PROD-API-URL] placeholder with the active API Gateway prod stage Invoke URL. I then reuploaded it into S3 because CloudFront caches and serves frontend assets from this origin bucket, and this update ensures client browsers receive the correct endpoint to properly route HTTP requests to the backend logic tier.

I ran into a second error after updating script.js. This was an error with Cross-Origin Resource Sharing (CORS) because the Amazon API Gateway was not configured to explicitly allow HTTP requests from the CloudFront distribution domain, causing the client browser to block the cross-origin request.

Resolving CORS Errors

To resolve the CORS error, I first enabled CORS on the Amazon API Gateway by selecting both GET and OPTIONS under Access-Control-Allow-Methods. Next, I set the Access-Control-Allow-Origin value to my specific CloudFront distribution domain name. Finally, I redeployed the REST API to the production stage to ensure the new security configuration took effect.

I also updated my Lambda function because the Amazon API Gateway uses Lambda Proxy Integration, requiring the backend function itself to explicitly construct and return the full HTTP response, including security headers. The changes I made were injecting the Access-Control-Allow-Origin header configured with the CloudFront distribution domain into the JSON response objects across all status codes to securely permit cross-origin browser requests.

Fixed Solution

I verified the fixed connection between API Gateway and CloudFront by reloading the CloudFront distribution domain in the client browser and validating that the frontend successfully executed the cross-origin HTTP GET request to retrieve and render the JSON payload from the DynamoDB table.

🤝This is the only project in the series on Three tier Web App.

Next series will be on Kubernetes

Build a Security Monitoring System

Hyelngtil Isaac — Thu, 11 Jun 2026 14:27:33 +0000

Introducing Today's Project!

In this project, I am building an AWS Security Monitoring System to demonstrate how cloud-native tools can be configured to detect, alert, and respond to threats. My goal is to show how services like CloudWatch, GuardDuty, and Security Hub can strengthen visibility and resilience in a cloud environment. I am also doing this project to demonstrate hands-on experience in cloud security, reflecting on my strengths and weaknesses, and investing in my personal growth.

Tools and concepts

Services I used were AWS Secrets Manager, CloudTrail, CloudWatch Logs, CloudWatch Metrics & Alarms, and SNS. Key concepts I learnt include how CloudTrail records API activity for auditing, how CloudWatch Logs and Metrics enable monitoring and alerting, the role of thresholds in alarms to trigger notifications, the importance of SNS topics and confirmed subscriptions for reliable message delivery, and how these services integrate to create a security monitoring pipeline that detects, logs, and alerts on secret access events.

Project reflection

This project took me approximately two hours. The most challenging part was tuning the CloudWatch alarm threshold setting it to 1 didn’t reliably detect a single secret access, so I adjusted it to 0.01 to trigger as expected. It was most rewarding to see the full pipeline work end‑to‑end: CloudTrail logged the access, CloudWatch recorded the metric and fired the alarm, and SNS delivered the email notification.

Create a Secret

Secrets Manager is an AWS cloud service that securely stores and manages sensitive data like passwords, API keys, and database credentials, enabling applications to access them safely at runtime with encryption, access control, and automatic rotation instead of hardcoding secrets in code.

To set up for my project, I created a secret called TopSecretInfo that contains the the key and value needed by my AWS security monitoring system.

Set Up CloudTrail

CloudTrail is an AWS service that records and monitors all API calls and account activity, providing visibility into actions taken by users, roles, and services for auditing and security purposes. I set up a trail to capture these events and deliver them to a designated S3 bucket, ensuring that logs are securely stored, easily accessible for analysis, and available for compliance or incident investigation.

CloudTrail events include management events that log control‑plane actions like creating users or modifying security groups, data events that capture resource‑level activity such as reading or writing S3 objects or invoking Lambda functions, network activity events that track API calls through VPC endpoints, and insights events that detect anomalies or unusual patterns, together providing full visibility into AWS account activity for auditing and security monitoring.

Read vs Write Activity

Read API activity involves retrieving or viewing information without making changes, such as listing users, describing resources, or getting object data, while Write API activity involves creating, modifying, or deleting resources, such as launching instances, updating configurations, or deleting objects. For this project, we need to capture both Read and Write activities to ensure complete visibility into account actions, since monitoring only one type would leave gaps in detecting potential security issues.

Verifying CloudTrail

I retrieved the secret in two ways: first through the AWS Management Console, where I opened the secret directly to view its stored values, and second using the AWS CLI, where I ran a command to programmatically fetch the secret, ensuring both manual and automated access methods were tested for logging and monitoring.

To analyze my CloudTrail events, I visited the CloudTrail console and reviewed the event history; I found entries showing both the retrieval of my secret from Secrets Manager and the corresponding API activity recorded with details like the user identity, time, and access method; this tells me that CloudTrail is successfully capturing and logging sensitive operations, providing the visibility and accountability needed for auditing and security monitoring.

CloudWatch Metrics

CloudWatch Logs is an AWS service that collects, stores, and manages log data from resources and applications, making it possible to monitor activity in real time. It’s important for monitoring because it centralizes logs, enables the creation of metrics and alarms, and provides visibility into system behavior, which helps detect issues, track security events, and ensure compliance.

CloudTrail’s Event History is useful for quickly viewing recent account activity and auditing specific API calls, while CloudWatch Logs are better for continuous monitoring and analysis because they store detailed log data, allow you to create metrics and alarms, and provide real‑time visibility into patterns or anomalies across your AWS environment.

A CloudWatch metric is a measurement that tracks specific activity or performance in your AWS environment. When setting up a metric, the metric value represents the actual data point being recorded, such as the number of times a secret was accessed. The default value is used when no data is reported for a given period, ensuring the metric still has a baseline reading so alerts or dashboards remain consistent even if no events occur.

CloudWatch Alarm

A CloudWatch alarm is a monitoring tool that watches a specific metric and triggers an action when the metric crosses a defined threshold. I set my CloudWatch alarm threshold to 1 on the SecretIsAccessed metric so the alarm will trigger whenever a secret is accessed at least once, ensuring I immediately receive a notification through SNS whenever sensitive data is retrieved.

I created an SNS topic along the way. An SNS topic is a communication channel that groups multiple subscribers together so messages can be delivered to all of them at once. My SNS topic is set up to send notifications whenever the CloudWatch alarm detects secret access, and since I subscribed my email address to it, I’ll immediately receive an alert in my inbox whenever the alarm is triggered.

AWS requires email confirmation for SNS subscriptions because it ensures that the recipient explicitly agrees to receive notifications, preventing accidental or unauthorized subscriptions. This helps prevent spam, protects users from unwanted messages, and guarantees that alerts only go to verified and consenting email addresses.

Troubleshooting Notification Errors

To test my monitoring system, I deliberately retrieved the secret value again to trigger the CloudWatch alarm. The results were mixed, while the event was successfully logged in CloudTrail, I didn’t receive the expected notification in my inbox. This showed that the alarm was firing but the SNS subscription or email delivery wasn’t configured correctly. The test highlighted the importance of end-to-end validation, ensuring not just that events are captured but also that alerts reach the intended recipients.

When troubleshooting the notification issues I checked five areas: first, I verified that the CloudWatch alarm was actually firing when the secret was retrieved. Second, I confirmed that the alarm was correctly linked to the SNS topic. Third, I checked that my email subscription to the SNS topic was active and confirmed. Fourth, I reviewed IAM permissions to ensure CloudWatch and SNS could publish and deliver messages. Finally, I inspected spam filters and delivery settings to rule out blocked or misrouted emails.

I initially didn't receive an email because the alarm used Average (and a long period), so a single 1 was diluted or treated as missing; metric/dimension mismatch or an unconfirmed SNS subscription can also block alerts.

Key solution: switch the alarm to Sum or Maximum, use a short period (e.g., 60s) with EvaluationPeriods=1, verify metric/dimensions, set missing‑data handling, and confirm the SNS email subscription.

Success!

To validate my monitoring system, I checked the CloudWatch alarm tied to the SecretIsAccessed metric after retrieving a secret, and I confirmed that the alarm was triggered. I then verified that the SNS topic delivered an email notification to my subscribed address. I received the alert exactly as expected, which tells me that the monitoring pipeline from CloudTrail logging to CloudWatch metrics and alarms, through to SNS notifications is working correctly and will reliably inform me of secret access events.

Comparing CloudWatch with CloudTrail Notifications

I updated my CloudTrail configurations because I needed to capture additional management events across all regions, ensure logs were encrypted with KMS keys, and integrate with CloudWatch for real-time alerts. This allowed me to enhance security monitoring, meet compliance standards, and reduce blind spots in activity tracking.

After enabling CloudTrail SNS notifications, my inbox quickly filled with hundreds of event emails per day. In terms of usefulness, I thought the notifications were initially helpful for confirming that logging was working, but the sheer volume made them impractical for daily monitoring. Instead, I realized it was better to route these events into CloudWatch or a centralized logging system, where I could filter, aggregate, and set alerts for only the truly critical activities.

Key Takeaways

End-to-End Validation is Crucial: Building a security pipeline isn't just about turning services on. Testing the flow from the initial event (accessing the secret) all the way to the final alert (receiving the email) is the only way to guarantee your system works when a real threat occurs.
Signal vs. Noise matters: Raw CloudTrail notifications can quickly overwhelm your inbox with hundreds of events. Routing these logs through CloudWatch allows you to filter, aggregate, and set alarms only for critical activity, saving you from alert fatigue.
Metrics Require Tuning: Default configurations don't always catch single events. Changing metric math from Average to Sum or Maximum, shortening the evaluation period, and properly handling missing data are essential steps to ensure single occurrences (like reading a secret) trigger an immediate alarm.
Complete Visibility Requires Both Read and Write Logging: Monitoring only "Write" activities leaves massive security gaps. Capturing "Read" events is equally critical, especially when protecting sensitive data like passwords and API keys stored in Secrets Manager.
Security is a Pipeline: No single AWS tool provides complete security on its own. It requires a layered integration: CloudTrail for auditing, CloudWatch for monitoring and alerting, and SNS for reliable delivery to the right people.

🤝This is the end of the series on Security.

Next series will be Three-Tier Architecture

Secure Secrets with Secrets Manager

Hyelngtil Isaac — Fri, 29 May 2026 07:46:07 +0000

Introducing Today's Project!

In this project, I will demonstrate how to identify and remove hard‑coded credentials from a configuration file, create and store those credentials in AWS Secrets Manager, update the application to fetch secrets at runtime, configure least‑privilege IAM access so the app can retrieve the secret, and rotate the secret while verifying the application continues to authenticate; I’m doing this project to show practical Secrets Manager workflows, secure secret handling that prevents committing credentials to source control, how to design minimal IAM policies, and how to test secret rotation and deployment changes so I can confidently deploy applications without exposing sensitive data.

Tools and concepts

Services I used were AWS Secrets Manager, AWS IAM, Amazon S3, the boto3 AWS SDK for Python, GitHub (with secret scanning), Git (interactive rebase and history rewrite), and Python tooling (virtualenv, FastAPI, uvicorn, requirements.txt); Key concepts demonstrated are: never hardcode secrets, use a managed secrets store to centralize and encrypt credentials, apply least‑privilege IAM policies, automating secret rotation, practice Git hygiene and removing secrets from history when leaks occur, fetch secrets at runtime instead of storing them in config files, and follow local‑dev best practices to isolate dependencies and keep sensitive data out of source control.

Project reflection

This project took me approximately an hour. The most challenging part was safely removing hardcoded credentials from the repository history and configuring Secrets Manager and IAM so the app could retrieve secrets at runtime. It was most rewarding to replace insecure config files with a managed secrets workflow and verify the app could access S3 using least‑privilege credentials.

I chose to do this project today because I wanted to demonstrate practical skills in securing application credentials and show I can move a demo app from insecure config files to a managed‑secrets workflow; something that would make learning with NextWork even better is more hands‑on, bite‑sized labs with step‑by‑step remediation (including sample IAM policies, Secrets Manager rotation examples, and CI/CD checks) plus instant feedback or badges to validate each completed task.

Hardcoding credentials

In this project, a sample web app is exposing AWS credentials and other secrets directly in source files config.py. Hardcoding credentials is unsafe because anyone with repo access or attackers who find the repo can steal keys to impersonate the app, access or delete data, run costly resources, or escalate privileges; secrets also persist in Git history. Use a managed secrets store, least‑privilege IAM, and rotate/revoke compromised keys.

I put placeholder credentials and config values into config.py to simulate an insecure app for the exercise: example AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, an AWS_REGION, a database connection string stub (e.g., DB_HOST, DB_USER, DB_PASS), and a DEBUG=True flag. These are fake/example values so you can reproduce the risk of hard‑coding without exposing real secrets; the goal is to demonstrate detection, removal, and replacement with a secure store (Secrets Manager), then rotate and revoke any real keys if they were used.

Using my own AWS credentials

As an extension for this project, I also decided to install fastapi==0.115.8 to build a lightweight and efficient web API, uvicorn==0.34.0 as the ASGI server to run FastAPI applications, boto3==1.36.20 to interact with AWS services like Secrets Manager, and python-multipart==0.0.5 to handle file uploads in API requests—all essential for securely managing secrets while building and deploying the application.

When I first ran the app, I ran into an error because the AWS Access Key ID I provided was invalid, meaning it didn’t match any credentials in AWS’s records. This happens when the key is mistyped, deleted, or not properly configured, and it prevents the app from authenticating to AWS to list the S3 buckets.

To resolve the InvalidAccessKeyId error, I updated the config.py file to include the correct AWS credentials. It now contains the proper AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION values, ensuring the app can authenticate with AWS and successfully list the S3 buckets.

Pushing Insecure Code to GitHub

Once I updated the web app code with credentials, I forked the repository because I wanted my own independent copy under my GitHub account where I could make changes without affecting the original project. A fork is different from a clone because a fork stays linked to the original repository on GitHub, allowing me to propose changes back through pull requests, while a clone is just a local copy on my machine with no direct connection to the original.

To connect my local repository to the forked one, I first realized git add was pointing to the original repo I didn’t have permission to write to because I initially cloned directly to my IDE. So I used git remote set-url origin https://github.com/hyelngtil/nextwork-security-secretsmanager.git to update the remote to my fork. Then I ran git remote -v to confirm the change, followed by git add and git commit to stage and save my updates locally. Finally, git push to upload those commits to my forked repository on GitHub.

GitHub blocked my push because there were hardcoded secrets in my config.py file, which triggered its secret scanning protection. This is a good security feature because it prevents sensitive credentials from being exposed publicly, protecting both my AWS account and anyone who might accidentally use those leaked keys.

Secrets Manager

Secrets Manager is an AWS service designed to securely store, manage, and automatically rotate sensitive information like credentials, API keys, and database passwords. I'm using it to store my AWS access keys so they aren’t hardcoded in my application files, which keeps them protected and retrievable only when needed. Other common use cases include managing database connection strings, third‑party API tokens, and encryption keys, all while ensuring secrets remain encrypted and access is tightly controlled.

Another feature in Secrets Manager is secret rotation, which means the service can automatically update and replace stored credentials (like AWS keys or database passwords) on a schedule without manual intervention. It's useful in situations where long‑lived credentials could become a security risk, such as database connections or API tokens, because rotation reduces exposure time and ensures that applications always use fresh, valid secrets.

Secrets Manager provides sample code in various languages, like Python, Java, and JavaScript, to show developers how to retrieve secrets directly from their applications. This is helpful because it makes integration straightforward, reduces the risk of exposing credentials in code, and ensures that applications can securely access secrets without manual handling.

Updating the web app code

I updated the config.py file to retrieve credentials directly from AWS Secrets Manager instead of hardcoding them. The get_secret() function will connect to Secrets Manager, fetch the stored secret containing my AWS access keys, and return those values securely at runtime. This way, the application uses credentials managed by AWS rather than exposing them in the source code.

I also added code to config.py to extract the individual values—like AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION from the JSON secret retrieved by get_secret(). This is important because the application needs those specific fields to authenticate with AWS services, and by parsing them out of the secret object, the app can use them securely at runtime without ever exposing the raw credentials in the source code.

Resetting the repository

Git reset is a Git command that lets you move your current branch pointer to a different commit and optionally change the state of your working directory and staging area. I used it to roll back the repository to a clean state before the commit that contained my hardcoded secrets. This was necessary because those secrets had already been staged and committed, and I needed to remove them from the commit history so they wouldn’t be pushed to GitHub or exposed publicly.

A merge conflict occurred during rebasing because rewriting the branch history left the working tree and the new base out of sync and both versions modified the same lines in config.py. I resolved it by checking git status and git diff, manually editing config.py to keep the Secrets Manager changes and remove the hardcoded keys, staging and committing the fix, and then updating the remote so the exposed credentials were removed.

Once the merge conflict was resolved, I verified that my hardcoded credentials were out of sight in the repository by checking the files with git status and git diff to confirm no sensitive lines remained, reviewing the commit history with git log to ensure the secrets were removed from past commits, and inspecting the remote repository on GitHub to confirm that only the updated config.py with Secrets Manager integration was present.

Key Takeaways

Zero-Trust Secret Handling: Refactored a FastAPI web application to remediate architectural vulnerabilities caused by hard-coded credentials in config.py. Implemented dynamic, runtime retrieval of AWS access keys and database strings via AWS Secrets Manager, mitigating the risk of source control credential leaks.
Git History Sanitization: Utilized git reset and interactive rebasing to purge compromised commits from the Git metadata. Successfully resolved merge conflicts to establish strict Git hygiene and bypass GitHub Secret Scanning blockers during remote pushes.
Least-Privilege & Automation: Designed minimal AWS IAM policies to grant the application restrictive access to secrets, while successfully configuring and validating automated secret rotation loops.

🤝Next in the series builds on this, which will be Build a Security Monitoring System

Threat Detection with GuardDuty

Hyelngtil Isaac — Thu, 02 Apr 2026 07:46:22 +0000

Introducing Today's Project!

I built a hands-on project where I wore two hats; attacker and defender, to demonstrate how SQL injection and command injection can escalate into a full cloud credential breach, and how AWS GuardDuty surfaces those behaviors in near real-time.

Tools & Concepts

Services used: Amazon GuardDuty, Amazon EC2, Amazon S3, AWS CloudFormation, AWS CloudShell, IAM Roles, Amazon CloudFront, VPC and networking components.

Key concepts: Threat detection with GuardDuty, SQL injection, command injection, Instance Metadata Service (IMDS) and credential exfiltration, simulating attacker behavior with CloudShell, S3 Malware Protection, and incident investigation workflows.

This project took approximately 1 hour. The most challenging part was tuning GuardDuty detections and IAM role permissions. The most rewarding moment was watching real threat findings surface during testing.

Project Setup

I deployed a CloudFormation template that provisions three functional pillars:

Web App Infrastructure — an Amazon EC2 instance inside a dedicated VPC (not the default), with its own Subnet, Internet Gateway, and Elastic Load Balancer for isolated networking.
S3 Storage — a bucket containing a protected important-information.txt file that the EC2 instance is authorized to access, simulating sensitive data.
GuardDuty Monitoring — automatically enabled as a security sentinel to monitor resources and detect threats.

The web app deployed is OWASP Juice Shop, a deliberately vulnerable application. My objective as the simulated attacker: gain access to the EC2 web server and read the sensitive file in S3.

What is GuardDuty?

GuardDuty is an intelligent threat detection service that continuously monitors AWS accounts and workloads for malicious activity. In this project, it analyzes:

VPC Flow Logs
CloudTrail management events
S3 data events

It uses machine learning and integrated threat intelligence to detect indicators of compromise — credential exfiltration, communication with known malicious IPs, and more. Findings trigger an automated remediation workflow via Amazon EventBridge.

Attack Phase 1: SQL Injection

SQL injection involves injecting malicious SQL code into an input field to manipulate backend database queries. It's dangerous because it allows attackers to bypass authentication and access sensitive data without authorization.

I entered the following into the email field of the Juice Shop login page:

' or 1=1;--

What this does:

1=1 is always true, so the database validates the login regardless of the password.
-- comments out the rest of the original query, neutralizing the intended security check.

Result: administrative access to the OWASP Juice Shop portal — no password required.

Attack Phase 2: Command Injection

Command injection is a vulnerability where an attacker executes arbitrary OS commands via a vulnerable application. Juice Shop is vulnerable because it fails to sanitize user input before passing it to a system shell.

I exploited the search field by injecting a Node.js payload that:

Queried the Instance Metadata Service (IMDSv2) to retrieve a session token.
Identified the IAM Role attached to the EC2 instance.
Fetched temporary security credentials — AccessKeyId, SecretAccessKey, and SessionToken.
Piped the JSON output to a publicly accessible path:

/frontend/dist/frontend/assets/public/credentials.json

A simple application flaw became a significant cloud infrastructure breach.

Attack Verification

I navigated to the public URL at /assets/public/credentials.json and confirmed the exfiltrated credentials — a structured JSON object containing the stolen IAM temporary credentials tied to the EC2 instance's role.

This proved the attacker now had everything needed to authenticate as a legitimate internal service and begin compromising additional AWS resources, including the S3 bucket.

Using CloudShell to Escalate the Attack

CloudShell provided a pre-authenticated environment with the AWS CLI pre-installed — perfect for simulating an attacker operating from an external machine using stolen credentials.

Steps taken:

# Download the exfiltrated credentials file
wget <public-url>/assets/public/credentials.json

# Extract the credential values
cat credentials.json | jq '.AccessKeyId, .SecretAccessKey, .SessionToken'

# Configure a new AWS CLI profile called "stolen"
aws configure --profile stolen

Using the stolen profile isolated the "hacker" identity from the default CloudShell credentials. I could now simulate unauthorized S3 access — the exact behavior GuardDuty would flag as anomalous.

GuardDuty's Findings

Within 15 minutes of executing the attack, GuardDuty generated a finding:

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS
Severity: HIGH

What this means: GuardDuty detected that IAM credentials were exfiltrated and then used inside the AWS environment — indicating a likely credential compromise and unauthorized lateral movement within the account.

How it detected it:
GuardDuty models normal AWS behavior and flags deviations. It correlates telemetry from CloudTrail, VPC Flow Logs, and DNS logs to spot unusual patterns — atypical API calls, credential use from unexpected sources, sudden internal data access, or reconnaissance activity.

The detailed finding reported that credentials for the EC2 instance role were used from a remote AWS account, confirming the simulated exfiltration scenario.

S3 Malware Protection

To test GuardDuty's Malware Protection for S3, I uploaded the standard EICAR anti-malware test file — a harmless string that antivirus products are configured to recognize as a test signature.

GuardDuty instantly triggered a security alert, confirming that Malware Protection detected the uploaded object and generated a finding indicating potential malware.

Key Takeaways

A single unsanitized input field can escalate from a login bypass to full cloud credential theft.
IMDS is a high-value target; restricting it with IMDSv2 and tight IAM policies is critical.
GuardDuty's anomaly detection is effective, it flagged the credential misuse within 15 minutes with no manual configuration beyond enabling the service.
Simulating attacks in a controlled lab environment is one of the best ways to build intuition for both offensive techniques and defensive tooling.

🤝Next in the series builds on this, which will be "Secure Secrets with Secrets Manager"

Encrypt Data with AWS KMS

Hyelngtil Isaac — Sun, 15 Mar 2026 11:17:31 +0000

Introducing Today's Project!

In this project, I will demonstrate how to create AWS KMS encryption keys, use them to encrypt a DynamoDB table, add and retrieve data to verify the encryption, observe how AWS blocks unauthorized access, and grant a user the necessary encryption permission. The goal is to show end‑to‑end data protection in AWS by provisioning keys, applying encryption to a live database, validating that only authorized principals can read or write the data, and confirming that key policies and IAM controls effectively prevent unauthorized access.

Tools and concepts

I used AWS KMS to create and manage a customer‑managed key, Amazon DynamoDB to store and encrypt table data, and IAM to create a test user and attach scoped policies. I worked in the AWS console to edit key policies, add key users, and verify access from an incognito session.

I learned about encryption at rest, that KMS key policies are the ultimate authority, and how to enforce least privilege by separating DynamoDB permissions from KMS decrypt permissions. I practiced using grants for temporary access, testing permissions, and documenting changes for auditability and rollback.

Project reflection

This project took me less an hour to complete, including setup, testing, and documentation. It was rewarding to see least‑privilege controls work in practice: the test user initially received access denied errors, then, after a narrowly scoped policy change, could decrypt the DynamoDB items, and I captured the steps and evidence for an auditable, repeatable workflow.

I chose to do this project today because I wanted hands‑on experience with real AWS security controls, creating a customer‑managed KMS key, attaching it to a DynamoDB table, and testing least‑privilege in practice. Working through the console and verifying access as a restricted test user helped me connect theory to operational tasks I’ll face as a junior cloud engineer and gave me confidence in key policy mechanics and auditable workflows.

Encryption and KMS

Encryption is the process of converting plaintext into an unreadable format (ciphertext) using mathematical algorithms so that unauthorized parties cannot understand the data.

Companies and developers do this to protect sensitive data at rest and in transit, prevent data breaches, satisfy legal and regulatory obligations, and preserve customer trust by ensuring confidentiality and integrity.

Encryption keys are secret values used by encryption algorithms to lock (encrypt) and unlock (decrypt) data; proper key management (storage, rotation, access control, and auditing) is essential because weak key handling defeats encryption.

AWS KMS is a fully managed AWS service that creates, stores, and controls cryptographic keys, enforces key policies, integrates with other AWS services, and logs key usage for auditing; key management systems are important because they protect the secrets that secure your data, enforce least‑privilege access, provide auditable trails for compliance, simplify key rotation and lifecycle operations, and reduce the operational risk and complexity of managing encryption securely.

Encryption keys are broadly categorized as symmetric (one secret used for both encryption and decryption) and asymmetric (a public/private key pair where the public key encrypts and the private key decrypts); I set up a symmetric key because symmetric keys are the recommended and most efficient choice for encrypting data at rest in AWS services like DynamoDB, they offer better performance for bulk data operations, integrate seamlessly with AWS KMS and service‑side encryption, simplify access control and key lifecycle management, and keep the sensitive key material protected inside KMS while still allowing authorized AWS principals to read and write encrypted table data.

Encrypting Data

My encryption key will safeguard data in DynamoDB, which is a fully managed, serverless NoSQL database that stores items as key‑value or document records, delivers single‑digit millisecond performance at scale, supports transactions and global replication, and integrates with AWS KMS for server‑side encryption; by attaching a customer‑managed symmetric KMS key to the table, storage and backups are encrypted at rest, access is controlled through key policies and IAM permissions, and every use of the key is logged for auditability so only authorized principals can decrypt and read the plaintext.

The different encryption options in DynamoDB include AWS owned keys (fully managed by AWS with no customer control), AWS managed KMS keys (service‑managed CMKs that AWS creates and rotates but still surface usage in CloudTrail), and customer‑managed KMS keys (CMKs you create and control in AWS KMS).
Their differences are based on who controls the key material and lifecycle, how much policy and access control you can enforce, the granularity of audit and rotation capabilities, and how quickly you can revoke or disable access.
I selected a customer‑managed symmetric KMS key because it gives me full policy control, immediate revocation and rotation options, detailed auditability, and the performance and seamless integration needed for encrypting DynamoDB table data.

Data Visibility

Rather than controlling who has access to the key, KMS manages user permissions by requiring explicit, key‑level authorization through a key policy (the primary control), and by evaluating IAM policies, grants, and any explicit denies before allowing cryptographic operations such as Encrypt, Decrypt, ReEncrypt, GenerateDataKey, or DescribeKey. This means no principal has any KMS key permissions unless the key policy or an allowed IAM policy/grant gives them those permissions.

Despite encrypting my DynamoDB table, I could still see the table’s items because DynamoDB’s server‑side encryption with KMS is transparent to authorized clients: AWS encrypts data at rest and stores ciphertext, but when an IAM principal or service with the necessary permissions reads an item, DynamoDB requests KMS to decrypt the data and returns plaintext to the caller, so applications and users who hold the right IAM/KMS permissions see normal, readable items; this protects storage, snapshots, and backups from anyone who cannot obtain KMS decrypt rights, while if you need ciphertext visible to clients you must use client‑side encryption (where the application holds the keys) rather than KMS server‑side encryption.

Denying Access

I configured a new IAM user named nextwork-kms-user to act as a test account for DynamoDB work; I attached the AmazonDynamoDBFullAccess managed policy so the user can fully interact with DynamoDB and saved the login credentials from the Retrieve password page, but I did not grant any permissions to my KMS key (no KMS actions or key policy access), ensuring the user cannot manage or decrypt encrypted data.

After accessing the DynamoDB table as the test user, I encountered an error when attempting to view the encrypted item attributes because the test user lacked permissions to use the KMS key (the console returned an access denied / missing kms:Decrypt message). This confirmed that attaching AmazonDynamoDBFullAccess alone does not permit reading encrypted data and that explicit KMS key permissions are required to decrypt and view those items, validating the principle of least privilege.

Granting Access

To let my test user use the encryption key, I added maven-kms-user as a key user in the KMS console so the principal can perform cryptographic operations; my key's policy was updated in the policy view to include a narrowly scoped statement granting that user Encrypt, Decrypt, ReEncrypt, GenerateDataKey, and DescribeKey on the key (targeted to the user’s ARN) while explicitly omitting any key‑management actions so the user can decrypt and encrypt data but cannot manage or change the key.
Using the test user, I retried accessing the DynamoDB table and refreshed the Items view; I observed the previously encrypted attributes now displayed in plaintext and successful GetItem/Scan operations without any KMS access‑denied errors, which confirmed that adding the user to the key policy (granting kms:Decrypt and related use actions) allowed the test user to decrypt and view the encrypted data while still not granting key management permissions.

Encryption protects data by making it unreadable without keys, while access control restricts who can request or retrieve that data; use encryption when you need protection against compromised storage or cross‑boundary exposure, and combine it with access controls, IAM, network controls, and logging to enforce defense in depth

🤝Next in the series builds on this, which will be "Threat Detection with Amazon GuardDuty"

Query Data with DynamoDB

Hyelngtil Isaac — Thu, 05 Mar 2026 17:02:13 +0000

Introducing Today's Project!

What is Amazon DynamoDB?

Amazon DynamoDB is a fully managed, serverless NoSQL database service from AWS that provides fast, predictable performance and scales automatically. It is useful because it eliminates the need to manage servers, supports both key‑value and document data models, and ensures single‑digit millisecond response times even at massive scale.

How I used Amazon DynamoDB in this project

In today’s project, I used Amazon DynamoDB to practice querying and updating data across tables in a way that keeps everything consistent. I started by running get-item commands to retrieve specific records using partition keys and projection expressions, which allowed me to pull back only the attributes I needed. Then I explored how related tables can be updated together by running a transaction with transact-write-items, which let me insert a new comment into one table while simultaneously updating a counter in another. This showed me how DynamoDB ensures atomicity, both operations succeed or fail together making it really useful for handling connected data across multiple tables without risking mismatched updates.

One thing I didn’t expect in this project is how seamlessly DynamoDB handled transactions across multiple tables. I thought working with related data in separate tables would require a lot of manual coordination, but using transact-write-items made it surprisingly straightforward to insert a new record in one table while simultaneously updating another. It was eye‑opening to see how DynamoDB guarantees atomicity, either both operations succeed or neither does which really simplifies keeping related data consistent. This step showed me that DynamoDB isn’t just about speed and scalability, but also about reliability when managing complex relationships.

This project took me through the full cycle of working with DynamoDB from retrieving specific items with "get-item" and "projection expressions", to exploring how tables can be related, and finally running a transaction that updated two tables at once. It wasn’t just about learning commands; it was about seeing how DynamoDB ensures consistency and reliability when handling connected data

Querying DynamoDB Tables

A partition key is the primary attribute DynamoDB uses to distribute and retrieve data across its storage partitions. Every item in a DynamoDB table must include a partition key, and items with the same partition key value are grouped together. This key determines where the data is stored internally and is essential for efficient queries, since DynamoDB can quickly locate items based on that key rather than scanning the entire table.
A sort key is the secondary attribute in a DynamoDB table’s primary key schema that works alongside the partition key to uniquely identify items. While the partition key determines which partition the data belongs to, the sort key organizes items within that partition. This means multiple items can share the same partition key but be distinguished by different sort key values. Sort keys also enable powerful query patterns, such as retrieving items in a range (e.g., all comments after a certain date) or ordering results by the sort key.

Limits of Using DynamoDB

I ran into an error when I queried for items in the Comment table without providing a value for the partition key Id. This was because DynamoDB requires the partition key filter to be specified in every query, without it, the system doesn’t know which partition to look in, so the console flagged the input as invalid. In other words, the query failed because the partition key field was left empty, and DynamoDB cannot execute a query unless the full key schema is respected.
Insights we could extract from our Comment table include the ability to see which posts attract the most engagement, track how often specific users contribute comments, and identify time-based activity patterns such as peak commenting hours or days. We can also observe relationships between posts and their associated comments, giving us a clear picture of community interaction at a structural level.

Insights we can’t easily extract from the Comment table include deeper qualitative analysis, such as the sentiment or tone of comments, trending topics across multiple posts, or demographic-based engagement patterns. DynamoDB stores structured attributes but doesn’t analyze meaning or allow complex joins across tables, so extracting these kinds of insights would require additional tools or data sources.

Running Queries with CLI

A query I ran in CloudShell was

aws dynamodb get-item \
--table-name ContentCatalog \
--key '{"Id":{"N":"202"}}' \
--projection-expression "Title, ContentType, Services" \
--return-consumed-capacity TOTAL

This query will fetch the item in the ContentCatalog table with the partition key Id equal to 202, but instead of returning the entire record, DynamoDB will only return the attributes I specified in the projection expression — Title, ContentType, and Services. Alongside those values, the response will also include a Consumed-Capacity block that shows how many read capacity units (RCUs) were used, giving me both the filtered item data and a usage report in one result.

Query options I could add to my query affect how DynamoDB returns the data and what additional information I get back. Specifically:

--consistent-read
Ensures I always get the most up-to-date version of the item, rather than a possibly stale copy from a replicated node.

--projection-expression
Lets me specify which attributes to return, so instead of the full record I only get the fields I care about (Title, ContentType, and Services).

--return-consumed-capacity TOTAL
Adds a usage report to the response, showing how many read capacity units were consumed by the query.

Transactions

A transaction is a coordinated set of operations in DynamoDB that are executed together so they either all succeed or all fail. Based on the surrounding page content, the idea is that when you need to update related data across multiple tables or items, you can group those changes into a single transaction. DynamoDB then guarantees atomicity: if one part of the transaction cannot be completed, none of the changes are applied. This ensures consistency and prevents situations where one table is updated but another is left behind, keeping your data reliable and synchronized across different parts of your application.

I ran a transaction using the aws dynamodb transact-write-items command with a client request token called TRANSACTION1. This transaction did two things: first, it added a new item into the "Comment" table with details such as the event name, the date and time of the comment, the comment text, and the user who posted it. Second, it updated the "Forum" table by incrementing the Comments attribute for the Events item. By grouping these two operations together in a single transaction, DynamoDB ensured that both changes either succeeded or failed as one unit, keeping the data consistent across the related tables.

🤝This is the end of this Series.
Next Series will be Security

Load Data into a DynamoDB Table

Hyelngtil Isaac — Mon, 02 Feb 2026 22:20:35 +0000

Introducing Today's Project!

What is Amazon DynamoDB?

DynamoDB is useful because it combines fast performance, flexible data modeling, and effortless scaling, making it a strong choice for modern applications that need to handle large amounts of varied data reliably.

How I used Amazon DynamoDB in this project

In today's project, I used Amazon DynamoDB to create tables, load diverse data like projects and videos into the ContentCatalog, and then view and update those items, because DynamoDB’s flexible schema allowed me to store different
types of content side by side while still retrieving them quickly with partition keys.

One thing I didn't expect in this project was...

One thing I didn't expect in this project is how straightforward it was to set up and run DynamoDB compared to relational databases like RDS or Aurora, because DynamoDB doesn’t require configuring servers, managing connections,
or defining rigid schemas, it just lets you create a table and start loading items right away.

This project took me about an hour, taking me through the full cycle of working with Amazon DynamoDB, creating tables, loading diverse data like projects and videos, and then viewing and updating items, because it was designed to show
how DynamoDB’s flexibility and speed make it easier to manage different types of content compared to traditional relational databases.

Create a DynamoDB table

DynamoDB tables organize data using items, which are records made up of attributes that describe details about each item; unlike relational databases, items don’t need to share the same attributes, giving DynamoDB a flexible way to store varied information in one table.

An attribute is a single piece of data that describes an item in DynamoDB, for example, if the item is a student record, attributes could include the student’s name, age, or number of projects completed. Unlike traditional relational databases where every row must share the same set of columns, DynamoDB
items can each have different attributes, giving you flexibility to store varied information within the same table.

Read and Write Capacity

Read Capacity Units (RCUs) and Write Capacity Units (WCUs) are DynamoDB’s measures of throughput, where RCUs define how many reads per second a table can handle and WCUs define how many writes per second it can handle.

Amazon DynamoDB’s Free Tier provides 25 GB of storage, along with 25 Read Capacity Units (RCUs) and 25 Write Capacity Units (WCUs), which together allow upto 200million of requests per month at no cost. I turned off auto scaling because while it can automatically increase capacity in production to handle
spikes in demand, it could push usage beyond the Free Tier limits and lead to unexpected charges, so disabling it ensures my table stays within the free allowance while I safely experiment.

Using CLI and CloudShell

AWS CloudShell is a browser‑based command line environment provided by Amazon Web Services that let's you securely manage, explore, and interact with your AWS resources without needing to install or configure tools locally. It comes pre‑authenticated with your AWS account and includes popular developer tools, making it easy to run commands, scripts, and manage services like DynamoDB directly from your web browser.

AWS CLI is a command-line interface tool that lets you manage and interact with AWS services by typing commands instead of using the web console. It provides a unified way to automate tasks, run scripts, and control resources like DynamoDB, S3, or EC2 directly from your terminal, making it especially useful for developers and administrators who want efficiency and repeatability in managing their cloud infrastructure.

I ran a CLI command in AWS CloudShell that created a new
DynamoDB table, because CloudShell provides a ready‑to‑use, browser‑based terminal that’s already authenticated with my AWS account, making it simple to execute AWS CLI commands without installing or configuring anything locally. This step is part of learning how to provision DynamoDB resources directly from the command line, reinforcing the idea that you can manage AWS services not only through the console but also programmatically

Loading Data with CLI

I ran a CLI command in AWS CloudShell that created new DynamoDB tables, because CloudShell comes pre‑installed with the AWS CLI and is already authenticated with my AWS account, making it easy to provision resources directly from the browser without needing any local setup. This step shows how DynamoDB tables can be defined programmatically, reinforcing the flexibility of managing cloud databases through commands instead of the console.

Observing Item Attributes

I checked a ContentCatalog item, which had the following attributes:
Id (partition key, number), Title (string), URL (string), Authors (list), Price (number), Difficulty (string), Published (boolean), ProjectCategory (string), and ContentType (string).
I checked another ContentCatalog item, which had a different set of attributes:
Id (partition key, number), Title (string), URL (string), VideoType (string), Price (number), Services (list, sometimes included), and ContentType (string).

Benefits of DynamoDB

A benefit of DynamoDB over relational databases is flexibility, because it doesn’t require a fixed schema, items in the same table can have different sets of attributes and data types. This means you can store diverse records (like projects and videos in your ContentCatalog) side by side without redesigning the table, whereas relational databases enforce rigid column structures that must be consistent across all rows. This flexibility makes DynamoDB especially useful for applications where data models evolve quickly or vary widely.

Another benefit over relational databases is speed, because DynamoDB is designed for high‑performance at scale, using SSD storage and a distributed architecture that allows single‑digit millisecond response times. Unlike relational databases, which often need complex joins and indexing across rigid schemas, DynamoDB retrieves items directly by their keys, making lookups and writes much faster. This speed is especially valuable for applications like gaming, e‑commerce, or real‑time analytics, where quick responses are critical.

🤝Next in the series builds on this, which is "Query Data with DynamoDB"

Connect a Web App to Amazon Aurora

Hyelngtil Isaac — Tue, 13 Jan 2026 11:51:33 +0000

Introducing Today's Project!

What is Amazon Aurora?

Amazon Aurora is a fully managed relational database service from AWS that is compatible with MySQL. It is useful because it combines the familiarity of MySQL with the scalability, speed, and reliability of a cloud‑native service. Aurora
automatically handles tasks like backups, replication, and failover, which makes it easier to build web apps that need secure, high‑performance data storage without managing complex infrastructure yourself.

How I used Amazon Aurora in this project

In today’s project, I used Amazon Aurora to store and manage the data from my web app. By connecting my EC2‑hosted application to Aurora, I was able to capture user input through the web interface and save it securely in a relational
database. Aurora’s compatibility with MySQL made it easy to query and verify the data using the MySQL CLI, while its scalability and reliability ensured that the app could handle future growth without me having to manage complex infrastructure.

One thing I didn’t expect in this project was how quickly Amazon Aurora connected with my EC2 instance once the configuration details were set. I thought it might take longer or require a more complex setup, but the compatibility with MySQL and the php‑mysqli extension made the process smoother than I anticipated.
This showed me that cloud services can simplify tasks that would normally be more complicated to manage on my own.

Creating a Web App

To connect to my EC2 instance, I used SSH with my .pem key file because this provides secure, authenticated access to the server. By running the "ssh -i MavenAuroraApp.pem ec2-user@" command, I was able to log in remotely, and I'm ready to begin installing and configuring my web application.

To help me create my web app, I first connected to my EC2 instance through SSH and installed the necessary software, Apache, PHP, and the php‑mysqli extension, because these tools turn the EC2 instance into a functioning web server capable of running a dynamic application and communicating with my Aurora database.

Connecting my Web App to Aurora

I set up my EC2 instance's connection details to my database.

My Web App Upgrade

Next, I upgraded my web app by adding a new PHP script that connects to my Aurora database and displays a more user‑friendly web page. This upgrade allowed the app to move beyond a simple static page and start handling dynamic data, capturing user input, sending queries to Aurora, and showing results directly in the browser.

Testing my Web App

To make sure my web app was working correctly, I tested it in the browser by submitting data through the web page and then used the MySQL CLI on my EC2 instance to query the Aurora database. By checking that the new entries appeared in the database, I confirmed that the app was successfully sending and storing data in Aurora.

🤝Next in the series builds on this, which is "Load Data into DynamoDB"

Aurora Database with EC2

Hyelngtil Isaac — Mon, 05 Jan 2026 10:18:09 +0000

Connect a Web App to Amazon Aurora

Introducing Today's Project!

What is Amazon Aurora?

Amazon Aurora is a high‑performance, fully managed database engine that combines the speed and reliability of commercial databases with the simplicity and cost‑effectiveness of open‑source ones. It’s useful because it scales automatically, stays highly available, and integrates smoothly with your AWS environment.

How I used Amazon Aurora in this project

In today’s project, I used Amazon Aurora to set up a highly available relational database that integrates seamlessly with my EC2 instance. Aurora provided the database endpoint I needed to connect my application, while automatically handling scalability, replication, and fault tolerance. This allowed me to focus on building and testing my app without worrying about manual database management.

One thing I didn't expect in this project

One thing I didn’t expect in this project was how straightforward the setup turned out to be. I thought it would be much of a hassle to configure the database and connect it to my EC2 instance, but the AWS steps made the process surprisingly simple.

I completed the Aurora Database with EC2 project in about an hour, which was faster than I expected. The guided AWS setup made connecting my EC2 instance to Aurora straightforward and efficient.

In the first part of my project

Creating an Aurora Cluster
A relational database is one in which data are organized into tables, which are collections of rows and columns. It's called "relational" because the rows relate to the columns and vice versa.
Aurora is a good choice when we need something large-scale, with peak performance and uptime. This is because Aurora databases use clusters. Ordinary relational databases, like MySQL and Oracle, are more generic and cost-effective. They suit smaller databases and less demanding workloads.

Halfway through I stopped!

I stopped creating my Aurora database because I am trying to connect a web app server to my Aurora database. That is why I needed to set up an EC2 instance to serve as the web app server.

Features of my EC2 instance

I created a new key pair for my EC2 instance, because I need keys to access my EC2 instance if I want to add, change, or update how my EC2 instance is running.
When I created my EC2 instance, I took particular note of the "Public IPv4 DNS" and the "Key pair name." The Public IPv4 DNS is essentially the address of my EC2 instance on the internet, while the Key pair is a set of cryptographic keys (public and private) used to securely access the instance. The Key pair name identifies which keys are associated with it.

Then I could finish setting up my database

Aurora Database uses clusters because they work together, so your data is always available. Aurora is really good for the big jobs because of these clusters.
Each cluster consists of a primary instance (where all write operations occur) and multiple read replicas as back-ups. If your database's primary instance fails, one of the replicas can be promoted to primary automatically.

🤝Next in the series builds on this, which is "Connect a Web App with Aurora"

AWS Databases!

Hyelngtil Isaac — Sat, 03 Jan 2026 09:54:53 +0000

I'm exploring AWS Databases!

I'm building database solutions on AWS
In this AWS Databases series, I'm learning about AWS databases (Relational and NoSQL databases). By the end of these projects, I will have known how to Connect an Aurora Database to EC2, connect a Web App to Amazon Aurora, Load Data into a DynamoDB Table, Visualize a Relational Database, and Query Data with DynamoDB. I'm learning about cloud databases because I want to know how it works and then use it create impactful solutions.

I am excited to share my progress - explore AWS databases with me!
I will set aside few hours daily to work on these database projects. I will keep myself accountable by tracking my daily progress and sharing updates to stay consistent. My reward for completing this AWS Databases series will be more ability to manage cloud databases effectively and confidently in real projects, and the satisfaction of mastering practical cloud database skills.

What are databases?
Databases are organized systems for storing and managing information digitally. They allow data such as customer records, product details, and transactions to be kept in one central place, making it easy to access, update, and share securely across teams. Cloud engineers use databases to store, organize, and manage application data securely in the cloud. They rely on databases to connect applications to data, run queries for insights, ensure scalability, and maintain high availability across different services.

What do database professionals do?
Database professionals are responsible for setting up databases, modelling data, writing queries, and ensuring database security. They also handle performance tuning, backups, and connecting databases to applications. The most interesting part of their job is using queries to turn raw data into meaningful insights that support decision‑making.

DEV Community: Hyelngtil Isaac

Automated End-to-End CI/CD Pipeline via AWS CodePipeline

1. Executive Summary & Project Reflection

2. Prerequisites & Baseline Requirements

Part 1: Set Up a Web App in the Cloud

1.1 Development EC2 Instance Provisioning

1.2 Remote SSH & Environment Bootstrapping

1.3 Toolchain Installation & Application Scaffolding

Part 2: Connect a GitHub Repo with AWS

2.1 Git Initialization & Upstream Connection

Part 3: Secure Packages with CodeArtifact

3.1 CodeArtifact Repository Setup

3.2 IAM Role & Policy Configuration

3.3 Maven Authentication & Configuration

Part 4: Continuous Integration with CodeBuild

4.1 S3 Artifact Store Provisioning

4.2 CodeBuild Project Initialization

4.3 IAM Role Modification (CodeArtifact Authorization)

4.4 Define Build Directives (buildspec.yml)

4.5 Build Execution & Artifact Verification

Part 5: Deploy a Web App with CodeDeploy

5.1 Infrastructure as Code (CloudFormation)

5.2 CodeDeploy Orchestration Setup

5.3 Define Deployment Directives (appspec.yml)

5.4 Manual Deployment Verification

Part 6: Build a CI/CD Pipeline with AWS

6.1 Pipeline Initialization & State Management

6.2 Stage 1: Source Control Integration

6.3 Stage 2: Continuous Integration (Build)

6.4 Stage 3: Continuous Deployment (Deploy)

7. Execution, Testing, & Validation

7.1 Triggering the Pipeline via Code Change

7.2 Monitoring Automated Orchestration

7.3 Live Production Verification

8. Disaster Recovery: Automated Rollback Validation

8.1 Executing the Rollback

8.2 Validating State Isolation and Recovery

Congratulations! You now have a fully functional end-to-end CI/CD pipeline for a Java web application hosted on AWS!

Deploy Backend with Kubernetes

Introducing Today's Project!

Tools and concepts

Project reflection

Project Set Up

Kubernetes cluster

Backend code

Container image

Manifest files

Backend Deployment!

kubectl

Verifying Deployment

🤝 Thank you for reading thus far. Next project will be a DevOps Challenge.

Build a Three-Tier Web App

Introducing Today's Project!

Tools and concepts

Project reflection

Presentation tier

Logic tier

Data tier

Logic and Data tier

Console Errors

Resolving CORS Errors

Fixed Solution

Build a Security Monitoring System

Introducing Today's Project!

Tools and concepts

Project reflection

Create a Secret

Set Up CloudTrail

Read vs Write Activity

Verifying CloudTrail

CloudWatch Metrics

CloudWatch Alarm

Troubleshooting Notification Errors

Success!

Comparing CloudWatch with CloudTrail Notifications

Key Takeaways

Secure Secrets with Secrets Manager

Introducing Today's Project!

Tools and concepts

Project reflection

4.4 Define Build Directives (`buildspec.yml`)

5.3 Define Deployment Directives (`appspec.yml`)