Building a Cloud-Native Continuous Deployment (CD) Platform Using AWS and EKS

One of the most impactful milestones we achieved during our cloud migration initiative was the development and rollout of a Cloud-Native Continuous Deployment (CD) Platform. Designed to support our application teams across Development, UAT, and Production environments, this solution enables fast, reliable, and automated deployments—built entirely using AWS-native services.

In this blog, I’ll walk through the architecture, key components, and how this CD pipeline has streamlined our application delivery process.

The Challenge

As we began migrating applications to Amazon EKS, it became clear that manual deployment processes would not scale. We needed an automated, secure, and flexible deployment solution that could:

• Work across multiple EKS clusters and environments
• Allow teams to deploy with minimal DevOps dependency
• Use standardized, reusable deployment patterns
• Integrate seamlessly with GitOps practices

The Solution: Cloud-Native CD on AWS

We built the platform entirely using AWS-native tools, which provided the scalability, security, and service integration required to support a modern DevOps workflow.

At the core of the solution is Amazon S3, which serves as the artifact store where development teams upload their packaged applications. Amazon EventBridge is used to detect events such as file uploads and orchestrate the build and deployment process. Once triggered, AWS CodeBuild handles tasks like unzipping the uploaded package, building Docker images, and performing GitOps-related updates.

The resulting container images are pushed to Amazon Elastic Container Registry (ECR), which acts as a centralized and secure image repository. To implement GitOps, we integrated with GitLab (or GitHub, depending on the team), where the application manifests are version-controlled.

For continuous delivery, ArgoCD monitors the Git repositories and automatically syncs any changes to the respective Amazon EKS clusters, ensuring consistent and automated deployments across environments.

This end-to-end pipeline leverages fully managed AWS services while embracing GitOps best practices, allowing us to automate the entire build-and-deploy cycle in a secure, scalable, and developer-friendly way.

Architecture Diagram

Here’s a high-level view of the end-to-end continuous deployment pipeline architecture:

Architecture and Workflow

Step 1: Application Package and Metadata

Teams are provided a standardized template to package their applications and define deployment metadata. Here's a sample:

yaml

# ================= Application Team Variables =================

# --- Image and Application Info ---
IMAGE_TAG: "v1.2.3"
APP_GROUP: "payments"
APP_NAME: "order-service"

# --- AWS Environment Details ---
AWS_DEFAULT_REGION: "ap-southeast-1"
AWS_ACCOUNT_ECR: "123456789012"
APP_IMAGE_REPO: "order-service"

# --- Git Metadata ---
TARGET_ENV: "stg"
GIT_PATH: "apps/stg/order-service"
GIT_AUTHOR: "John Doe"
GIT_EMAIL: "john.doe@example.com"
COMMIT_MSG: "Deploying version v1.2.3 to staging"

# --- Notification Settings ---
EMAIL_DISTRO: "payments-dev@example.com"
        

Teams zip the application binaries and variable file and upload them to a designated S3 path.

Step 2: EventBridge Trigger to Unpack

When a file is uploaded to the Amazon S3 bucket, EventBridge triggers a CodeBuild project that:

• Unzips the uploaded package
• Prepares and copies the contents to a structured location (e.g., Git or artifact path)

Step 3: Docker Build and GitOps Update

Another EventBridge rule triggers a second CodeBuild job. It:

1. Builds a Docker image from the uploaded artifacts
2. Pushes the image to Amazon ECR
3. Updates deployment manifests in Git with the new image tag (e.g., config.yaml, deployment.yaml)

These Git changes are automatically picked up by ArgoCD.

Step 4: ArgoCD Sync and Deployment

ArgoCD continuously watches the Git repository. Once it detects the updated image tag:

• It syncs the Kubernetes manifests
• Deploys the application to the corresponding EKS cluster
• Uses standard Kubernetes rollout strategies (e.g., RollingUpdate)

Step 5: Promotion from UAT to Production

Once a version is approved in UAT, the same image tag is used in production:

• If the image already exists in ECR, the build step is skipped
• ArgoCD performs the deployment by syncing the production Git path

This ensures consistency, prevents rebuilds, and speeds up production releases.

Results and Impact

This CD platform delivered significant benefits:

• Faster deployments across all environments
• Consistency in application versions using image promotion
• Improved governance with Git as the single source of truth
• Developer autonomy with minimal DevOps involvement

Conclusion

By embracing cloud-native architecture and GitOps practices, we built a scalable and reliable CD platform using only AWS-managed services. This solution empowers developers, increases release velocity, and enforces best practices for application lifecycle management.

If you are exploring similar modernization efforts, we hope this experience serves as a useful reference.