DEV Community: Shivanshu Sharma

Building an Enterprise-Grade AWS CI/CD Pipeline with Terraform

Shivanshu Sharma — Sun, 11 May 2025 12:57:01 +0000

How I automated AWS deployments with CodePipeline, CodeCommit, and CodeBuild for under $5/month

The DevOps Challenge

Let me take you on a technical adventure that recently consumed my weekends and late nights. While I’ve mastered the arts of Jenkins, GitHub Actions, and Azure DevOps over the years, AWS’s native CI/CD services remained unexplored territory in my professional journey. When tasked with implementing a fully AWS-native DevOps pipeline for a crucial enterprise SSO project, I knew I was in for both a challenge and a revelation.

Truth be told, I approached this mission with equal parts excitement and skepticism. Would AWS’s homegrown CI/CD solutions match the maturity of the standalone counterparts I’ve grown to love? Spoiler alert: they don’t — at least not yet — but they certainly bring their own flavor of magic to the table.

The goal seemed straightforward at first: automate the deployment of AWS SSO configurations through a fully managed CI/CD pipeline. But as with most interesting DevOps problems, the devil was in the details. I would need to navigate the peculiarities of AWS’s native services, overcome their integration quirks, and piece together a solution that was both robust and maintainable. The journey took me through CodeCommit’s sparse interface, CodeBuild’s container idiosyncrasies, and CodePipeline’s rather opinionated workflow design — all while maintaining Terraform as my infrastructure orchestration tool of choice.

The Mission: Infrastructure as Code Automation

Before diving into code snippets and configuration files, let’s understand what I was building. My task centered around AWS Single Sign-On (SSO) automation for a large enterprise with dozens of AWS accounts and multiple teams requiring different levels of access:

Create a system to provision Permission Sets (essentially IAM roles on steroids) into AWS SSO
Establish automated linking between these Permission Sets, user Groups, and AWS accounts
Set up a CI/CD pipeline to deploy changes automatically whenever configurations are updated
Package everything neatly as infrastructure-as-code using Terraform
Ensure the entire process was auditable, reproducible, and compliant with security best practices

In essence, I needed to build a self-service platform where different teams could access their assigned AWS accounts with appropriate permission levels, all managed through a central AWS SSO portal. This would replace our existing manual process where identity and access management changes required tickets, manual approvals, and direct console work — a process that typically took days and was prone to human error.

The catch? Making this process as automated and hands-off as possible while maintaining appropriate security controls. As AWS SSO lacks certain API capabilities for user and group provisioning (as of this writing), this part would remain a console operation performed by our security team. However, everything else was fair game for automation.

The challenge was further complicated by our organization’s strict security requirements:

All infrastructure changes must be tracked and auditable
Deployments must require explicit approvals
The entire solution must be version-controlled
No permanent admin credentials should be used in the pipeline

This is precisely the type of complex, multi-faceted DevOps problem I live for.

Assembling My AWS DevOps Arsenal

For this operation, I enlisted four core AWS services to create a seamless CI/CD experience:

CodeCommit: My code repository (AWS’s equivalent of GitHub)
CodeBuild: My execution environment for running Terraform commands
CodePipeline: The orchestrator connecting all the pieces
S3: My artifact storage system

Each of these services has its own strengths and limitations that influenced my architectural decisions:

CodeCommit offers tight integration with other AWS services but lacks many developer-friendly features found in GitHub or GitLab. While it supports branch policies and approval rules, its web interface for code reviews is quite basic. However, it does provide IAM-based access control, which aligns perfectly with our security requirements and eliminates the need for SSH keys or personal access tokens.

CodeBuild runs your build commands in isolated Docker containers, which is excellent for consistency but introduces challenges with filesystem operations like symbolic links (which I’ll discuss later). It supports various compute types ranging from 3GB to 64GB of memory, though I found the smallest tier more than sufficient for our Terraform operations.

CodePipeline orchestrates the entire process but follows a linear execution model with limited branching capabilities. It allows for manual approval steps, which was crucial for our compliance requirements, but lacks some advanced features like parallel execution paths or conditional stages.

S3 serves as a simple yet effective artifact repository, with versioning capabilities that create an audit trail of all our infrastructure changes.

Let’s see how I assembled these pieces into a coherent infrastructure automation puzzle.

First Steps: Setting Up CodeCommit

While my organization already uses GitHub for most projects, this particular project needed to live within our AWS ecosystem for security and compliance reasons. Setting up a CodeCommit repository is straightforward through the AWS console — much simpler than configuring a full-featured GitHub organization with proper permissions.

After creating a new repository (I named mine sso-permission-sets), the critical step is capturing the Clone URL for local development:

Click on the repository name in the CodeCommit console
Open the “Clone URL” dropdown in the upper right
Select “Clone HTTPS (GRC)” — this is important as it uses the git-remote-codecommit helper

The resulting URL contains your region and repository name, looking something like https://git-codecommit.eu-west-2.amazonaws.com/v1/repos/sso-permission-sets. This format threw me off initially - it's not the standard Git URL format you might be used to. Later, you'll notice we use a different format altogether with the git-remote-codecommit helper.

One nice aspect of CodeCommit is that it leverages your existing AWS authentication mechanisms rather than requiring separate SSH keys or personal access tokens. This simplifies credential management, especially in enterprise environments where key rotation policies are strictly enforced.

Creating My Local Development Environment

To effectively work with this setup, I needed a well-configured local development environment with several tools properly installed and configured. Here’s my detailed setup process:

Installing and Configuring Required Tools

First, I made sure I had AWS CLI v2 installed, as v1 lacks some of the SSO functionality needed:

aws --version

If you’re on macOS, you can install it with:

brew install awscli

Next came the most crucial part — configuring SSO access for seamless authentication. This was essential as my organization had moved away from long-lived IAM access keys to temporary credentials via SSO:

aws configure sso --profile terraform-deployer

This interactive command prompted me for:

The SSO start URL (our company portal)
AWS region for SSO (ap-south-1 in our case)
Default output format (json)
Default AWS account and permission set (I selected our infrastructure account and PowerUser role)

Once completed, a browser window opened for SSO authentication. With this configuration saved, I could now authenticate simply by running:

aws sso login --profile terraform-deployer

This generates temporary credentials valid for 8 hours — perfect for a development session without compromising security.

Setting Up Terraform and Version Management

For Terraform, I needed version 0.15 or higher to leverage newer features like improved plan file handling:

terraform --version
# Should return: Terraform v0.15.5 or higher

Since I juggle multiple client projects with different Terraform version requirements, I use tfenv, which is essentially nvm but for Terraform:

brew install tfenv

# Install specific Terraform version
tfenv install 0.15.5# Set as default
tfenv use 0.15.5# Verify installed versions
tfenv list
# Shows: * 0.15.5 (set by /Users/shivanshu.sharma/.tfenv/version)
#        0.14.11
#        0.13.7

Connecting to CodeCommit

Finally, to work with CodeCommit, I needed Git and the specialized CodeCommit helper that integrates with AWS authentication:

# Verify Git version
git --version
# Should be 1.7.9 or higher

# Install the CodeCommit helper
python3 -m pip install git-remote-codecommit

The git-remote-codecommit package is critical — it enables Git to understand and use the special codecommit:// URL scheme that integrates with AWS authentication. Without it, connecting to CodeCommit repositories becomes much more complicated.

With VS Code (plus the HashiCorp Terraform extension) as my IDE, I cloned the empty repository using the special codecommit format:

git clone codecommit::ap-south-1://terraform-deployer@sso-permission-sets
cd sso-permission-sets && code .

Notice the URL format: codecommit::<region>://<profile>@<repository>. This leverages the AWS credentials associated with the specified profile, eliminating the need for separate Git credentials.

Validating My Setup

To ensure everything was working correctly, I created a simple README.md file and pushed it to the repository:

echo "# AWS SSO Permission Sets" > README.md
git add README.md
git commit -m "Initial commit"
git push

After refreshing the CodeCommit console, I could see my README appeared correctly — confirmation that my local development environment was properly configured and ready for the real work ahead.

Repository Structure and Organization

Let me share how I organized my code:

sso-permission-sets/
├── configurations/
│   ├── permission_sets_pipeline/
│   │   ├── codepipeline.tf
│   │   ├── iam.tf
│   │   ├── codebuild.tf
│   │   ├── s3.tf
│   │   ├── buildspec-plan.yml
│   │   └── buildspec-apply.yml
│   ├── global.tf
│   ├── output.tf
│   ├── provider.tf
│   ├── version.tf
│   └── state.tf

I placed common configuration files at the root level and linked them into specific configuration directories. One quirk I discovered: AWS CodeBuild doesn’t handle symbolic links well, so I ultimately copied these files directly instead of linking them.

Orchestrating the CI/CD Pipeline

The heart of my solution lives in codepipeline.tf, where I defined a four-stage pipeline:

resource "aws_codepipeline" "codepipeline" {
  name     = var.pipeline_name
  role_arn = aws_iam_role.codepipeline_role.arn

  artifact_store {
    location = aws_s3_bucket.codepipeline_bucket.bucket
    type     = "S3"
  }  # Stage 1: Clone the repository
  stage {
    name = "Clone"    action {
      name             = "Source"
      category         = "Source"
      owner            = "AWS"
      provider         = "CodeCommit"
      version          = "1"
      output_artifacts = ["CodeWorkspace"]      configuration = {
        RepositoryName       = var.repository_name
        BranchName           = var.branch_name
        PollForSourceChanges = "true"
      }
    }
  }  # Stage 2: Run terraform plan
  stage {
    name = "Plan"    action {
      name             = "Plan"
      category         = "Build"
      owner            = "AWS"
      provider         = "CodeBuild"
      input_artifacts  = ["CodeWorkspace"]
      output_artifacts = ["TerraformPlanFile"]
      version          = "1"      configuration = {
        ProjectName = aws_codebuild_project.plan_project.name
        EnvironmentVariables = jsonencode([
          {
            name  = "PIPELINE_EXECUTION_ID"
            value = "#{codepipeline.PipelineExecutionId}"
            type  = "PLAINTEXT"
          }
        ])
      }
    }
  }  # Stage 3: Require manual approval
  stage {
    name = "Manual-Approval"    action {
      name     = "Approval"
      category = "Approval"
      owner    = "AWS"
      provider = "Manual"
      version  = "1"
    }
  }  # Stage 4: Apply the terraform changes
  stage {
    name = "Apply"    action {
      name            = "Deploy"
      category        = "Build"
      owner           = "AWS"
      provider        = "CodeBuild"
      input_artifacts = ["CodeWorkspace", "TerraformPlanFile"]
      version         = "1"      configuration = {
        ProjectName     = aws_codebuild_project.apply_project.name
        PrimarySource   = "CodeWorkspace"
        EnvironmentVariables = jsonencode([
          {
            name  = "PIPELINE_EXECUTION_ID"
            value = "#{codepipeline.PipelineExecutionId}"
            type  = "PLAINTEXT"
          }
        ])
      }
    }
  }
}

The pipeline flow is elegantly simple:

Clone: Fetch the latest code from CodeCommit
Plan: Run terraform plan and save the output as an S3 artifact
Manual-Approval: Allow human verification of proposed changes
Apply: Run terraform apply using the saved plan file

A few implementation insights I discovered along the way:

Artifact names should avoid hyphens to prevent ambiguous Terraform errors (use camelCase or snake_case instead)
CodePipeline variables can be accessed using the #{codepipeline.VariableName} syntax
For the Apply stage, since it uses multiple input artifacts, I had to specify which one should be the primary source

Setting Up CodeBuild Projects

For each CodeBuild stage (Plan and Apply), I needed to define a build project:

resource "aws_codebuild_project" "plan_project" {
  name          = "${var.pipeline_name}-plan"
  description   = "Plan stage for ${var.pipeline_name}"
  build_timeout = "5"
  service_role  = aws_iam_role.codebuild_role.arn

  artifacts {
    type = "CODEPIPELINE"
  }  environment {
    compute_type                = var.build_compute_type
    image                       = var.build_image
    type                        = var.build_container_type
    image_pull_credentials_type = "CODEBUILD"
  }  source {
    type      = "CODEPIPELINE"
    buildspec = file("${path.module}/buildspec-plan.yml")
  }
}resource "aws_codebuild_project" "apply_project" {
  name          = "${var.pipeline_name}-apply"
  description   = "Apply stage for ${var.pipeline_name}"
  build_timeout = "5"
  service_role  = aws_iam_role.codebuild_role.arn  artifacts {
    type = "CODEPIPELINE"
  }  environment {
    compute_type                = var.build_compute_type
    image                       = var.build_image
    type                        = var.build_container_type
    image_pull_credentials_type = "CODEBUILD"
  }  source {
    type      = "CODEPIPELINE"
    buildspec = file("${path.module}/buildspec-apply.yml")
  }
}

The environment variables in my global.tf defined the compute specifications:

variable "build_compute_type" {
  description = "CodeBuild compute type"
  type        = string
  default     = "BUILD_GENERAL1_SMALL"
}

variable "build_image" {
  description = "CodeBuild container image"
  type        = string
  default     = "aws/codebuild/amazonlinux2-x86_64-standard:3.0"
}variable "build_container_type" {
  description = "CodeBuild container type"
  type        = string
  default     = "LINUX_CONTAINER"
}

Crafting the BuildSpec Files

The real magic happens in the buildspec files that tell CodeBuild what to do. Here’s my plan buildspec:

version: 0.2

env:
  variables:
    TF_VERSION: "0.15.5"
    PERMISSION_SETS_DIR: "configurations/permission_sets_pipeline"phases:
  install:
    runtime-versions:
      python: 3.8
    commands:
      - echo "Installing terraform version ${TF_VERSION}"
      - curl -s -qL -o terraform.zip "https://releases.hashicorp.com/terraform/${TF_VERSION}/terraform_${TF_VERSION}_linux_amd64.zip"
      - unzip terraform.zip
      - mv terraform /usr/bin/terraform
      - rm terraform.zip  build:
    commands:
      - echo "Starting build phase"
      - cd ${CODEBUILD_SRC_DIR}

      # Copy linked files to make sure they're available
      - cp ${CODEBUILD_SRC_DIR}/configurations/global.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/
      - cp ${CODEBUILD_SRC_DIR}/configurations/provider.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/
      - cp ${CODEBUILD_SRC_DIR}/configurations/version.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/
      - cp ${CODEBUILD_SRC_DIR}/configurations/state.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/
      - cp ${CODEBUILD_SRC_DIR}/configurations/output.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/

      - cd ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}
      - terraform init
      - terraform validate
      - terraform plan -out=tfplan_commitid_${CODEBUILD_RESOLVED_SOURCE_VERSION}_pipelineid_${PIPELINE_EXECUTION_ID}

artifacts:
  files:
    - ${PERMISSION_SETS_DIR}/tfplan_commitid_${CODEBUILD_RESOLVED_SOURCE_VERSION}_pipelineid_${PIPELINE_EXECUTION_ID}
  name: TerraformPlanFile

And the apply buildspec:

version: 0.2

env:
  variables:
    TF_VERSION: "0.15.5"
    PERMISSION_SETS_DIR: "configurations/permission_sets_pipeline"phases:
  install:
    runtime-versions:
      python: 3.8
    commands:
      - echo "Installing terraform version ${TF_VERSION}"
      - curl -s -qL -o terraform.zip "https://releases.hashicorp.com/terraform/${TF_VERSION}/terraform_${TF_VERSION}_linux_amd64.zip"
      - unzip terraform.zip
      - mv terraform /usr/bin/terraform
      - rm terraform.zip  build:
    commands:
      - echo "Starting build phase"
      - cd ${CODEBUILD_SRC_DIR}

      # Copy linked files to make sure they're available
      - cp ${CODEBUILD_SRC_DIR}/configurations/global.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/
      - cp ${CODEBUILD_SRC_DIR}/configurations/provider.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/
      - cp ${CODEBUILD_SRC_DIR}/configurations/version.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/
      - cp ${CODEBUILD_SRC_DIR}/configurations/state.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/
      - cp ${CODEBUILD_SRC_DIR}/configurations/output.tf ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}/

      - cd ${CODEBUILD_SRC_DIR}/${PERMISSION_SETS_DIR}
      - terraform init
      - cp ${CODEBUILD_SRC_DIR_TerraformPlanFile}/configurations/permission_sets_pipeline/tfplan_commitid_${CODEBUILD_RESOLVED_SOURCE_VERSION}_pipelineid_${PIPELINE_EXECUTION_ID} .
      - terraform apply -auto-approve tfplan_commitid_${CODEBUILD_RESOLVED_SOURCE_VERSION}_pipelineid_${PIPELINE_EXECUTION_ID}

A critical discovery I made: when dealing with multiple artifacts in CodeBuild, you need to use CODEBUILD_SRC_DIR_ArtifactName to access secondary artifacts. This was the trickiest part of the whole setup!

Creating the S3 Artifact Bucket

Finally, I needed a place to store my pipeline artifacts:

resource "aws_s3_bucket" "codepipeline_bucket" {
  bucket = var.artifact_bucket
}

resource "aws_s3_bucket_acl" "codepipeline_bucket_acl" {
  bucket = aws_s3_bucket.codepipeline_bucket.id
  acl    = "private"
}resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.codepipeline_bucket.id  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

Nothing fancy here — just a private, encrypted bucket for storing our Terraform plans and other artifacts.

Final Result and Cost Analysis

After applying all these configurations, I had a fully functional AWS-native CI/CD pipeline that would:

Detect changes to the repository
Plan the Terraform changes
Wait for human approval
Apply the changes automatically

The best part? The entire solution costs approximately $3.01 per month if you run it once daily. That’s less than a fancy coffee!

Overcoming Unexpected Challenges

While the solution appears straightforward now, I encountered several unexpected obstacles along the way:

Dynamic State Management

My first attempt used a local state file, which quickly proved problematic in a CI/CD environment. I pivoted to using S3 backend with DynamoDB locking to ensure state consistency:

terraform {
  backend "s3" {
    bucket         = "terraform-state-xxcloud-infra"
    key            = "sso-permission-sets/terraform.tfstate"
    region         = "ap-south-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

Handling Permission Boundaries

Our organization requires permission boundaries on all IAM roles. The IAM roles created by CodeBuild and CodePipeline needed these boundaries applied, which required some additional configurations:

resource "aws_iam_role" "codebuild_role" {
  name                 = "${var.pipeline_name}-codebuild-role"
  assume_role_policy   = data.aws_iam_policy_document.codebuild_assume_policy.json
  permissions_boundary = "arn:aws:iam::${local.account_id}:policy/StandardPermissionsBoundary"
}

Cross-Account Pipeline Considerations

While my initial implementation worked within a single account, we later expanded it to deploy permission sets across multiple accounts. This required adjusting the trust relationships and adding cross-account role assumptions to the pipeline.

Security Considerations

Security was paramount in this implementation:

Least Privilege Access: The IAM roles for CodeBuild and CodePipeline have tightly scoped permissions
Artifact Encryption: All pipeline artifacts are encrypted at rest in S3
Manual Approval Gates: Changes require explicit human approval before deployment
Auditable History: Every change is trackable through Git history and pipeline execution logs
Temporary Credentials: No long-lived access keys are used in the pipeline

Cost Analysis and Optimization

One pleasant surprise was the cost-effectiveness of this solution. The entire infrastructure costs approximately $4 to $5 per month with daily executions.

We could further optimize by using EventBridge to trigger the pipeline only on actual changes rather than polling for changes, but the cost savings would be minimal.

Conclusion and Key Takeaways

Building this AWS-native CI/CD pipeline was a fascinating journey that expanded my DevOps toolkit. While AWS’s CI/CD services don’t yet match the polish of dedicated solutions like Jenkins or GitHub Actions, they integrate beautifully with other AWS services and provide a cost-effective approach to automating infrastructure deployments.

The most valuable lessons I learned:

Filesystem Quirks: CodeBuild has peculiar behavior with symbolic links and secondary artifacts
Environment Variable Magic: Use pipeline execution IDs and commit hashes to create unique artifact names

This infrastructure-as-code approach to managing AWS SSO permission sets has dramatically improved our operational efficiency. What used to take days of manual work and coordination now happens automatically in minutes with full traceability and security controls.

Have you built similar pipelines with AWS’s native services? What challenges did you encounter?

I’d love to hear about your experiences and any optimization tips you might have!

Unlocking Event-Driven Architectures with Amazon EventBridge

Shivanshu Sharma — Thu, 17 Apr 2025 05:56:00 +0000

Introduction

As modern applications shift towards microservices and serverless architectures, decoupled systems and real-time event processing become critical. Enter Amazon EventBridge, AWS’s event bus service that connects application data from your services, integrated SaaS applications, and AWS services to enable real-time, event-driven workflows.

In this blog, we’ll take a technical deep dive into EventBridge, explore how it differs from SNS and SQS, examine its architecture, and build a simple event-driven pipeline to demonstrate its capabilities.

🧠 What is Amazon EventBridge?

Amazon EventBridge is a serverless event bus that makes it easy to connect applications using data from your own applications, integrated SaaS providers (like Auth0, Zendesk, Shopify), and AWS services.

It routes events based on rules to targets like Lambda, Step Functions, SQS, Kinesis, and more — without needing to write custom polling or filtering logic.

🔄 EventBridge vs SNS vs SQS

Feature	EventBridge	SNS	SQS
Event routing	Rule-based with content filtering	Fan-out pub/sub	Message queue
Message retention	24 hours	No retention	14 days
Dead-letter queue	✅	❌	✅
Custom Event Buses	✅	❌	❌
SaaS integration	✅	❌	❌

🏗️ Architecture: Under the Hood

An EventBridge setup consists of:

Event Sources: AWS services, your apps, or SaaS apps.
Event Bus: Default, Partner, or Custom.
Rules: JSON pattern-based filters.
Targets: AWS services like Lambda, SQS, Step Functions, or even HTTP APIs.

You send events to a bus, which evaluates them against rules and sends them to matched targets.

🛠️ Hands-On: Building an Event-Driven Workflow

Scenario

You have an e-commerce app. When a new order is placed (via a Lambda function), an event is published to EventBridge. Based on that event, EventBridge triggers:

A Lambda to update inventory.
A Step Function to initiate fulfillment.
Sends the event to an SQS queue for async analytics processing.

Step 1: Define the Event Schema

{
  "source": "custom.ecommerce",
  "detail-type": "OrderPlaced",
  "detail": {
    "orderId": "1234",
    "items": ["sku-1", "sku-2"],
    "total": 49.99
  }
}

Step 2: Create a Custom Event Bus

aws events create-event-bus --name ecommerce-bus

Step 3: Add a Rule to Route Events

event-rule.json

{
  "Source": ["custom.ecommerce"],
  "DetailType": ["OrderPlaced"]
}

aws events put-rule \
  --name OrderPlacedRule \
  --event-bus-name ecommerce-bus \
  --event-pattern file://event-rule.json

Step 4: Add Targets

aws events put-targets \
  --rule OrderPlacedRule \
  --event-bus-name ecommerce-bus \
  --targets file://targets.json

targets.json

[
  {
    "Id": "InventoryLambda",
    "Arn": "arn:aws:lambda:us-east-1:123456789012:function:UpdateInventory"
  },
  {
    "Id": "FulfillmentStepFunction",
    "Arn": "arn:aws:states:us-east-1:123456789012:stateMachine:FulfillOrder"
  },
  {
    "Id": "AnalyticsQueue",
    "Arn": "arn:aws:sqs:us-east-1:123456789012:analytics-queue"
  }
]

Step 5: Send a Test Event

aws events put-events --entries file://event.json

event.json

[
  {
    "Source": "custom.ecommerce",
    "DetailType": "OrderPlaced",
    "Detail": "{\"orderId\": \"1234\", \"items\": [\"sku-1\", \"sku-2\"], \"total\": 49.99}",
    "EventBusName": "ecommerce-bus"
  }
]

✅ Key Benefits

Loose coupling between producers and consumers
Schema Registry and schema discovery
Native support for SaaS and AWS integrations
Scalability and durability with at-least-once delivery

🔐 Best Practices

Use custom event buses to isolate domains
Implement dead-letter queues (DLQs) to handle failures
Leverage schema validation to prevent malformed events
Use event replay to reprocess past events (available via Archive & Replay)

Conclusion

Amazon EventBridge is a cornerstone for building resilient, scalable, event-driven applications in AWS. Whether you’re decoupling microservices, responding to external triggers, or handling complex workflows, EventBridge offers a clean, powerful, and highly integrative approach.

If you’re not already using it in your architecture, now’s the time to consider where EventBridge can help simplify your systems.

[Boost]

Shivanshu Sharma — Wed, 16 Apr 2025 08:26:59 +0000

Shivanshu Sharma for AWS Community Builders

Apr 13 '25

Implementing AWS SSO Integration with Jenkins

#aws #security #devops #cicd

Comments

4 min read

Implementing AWS SSO Integration with Jenkins

Shivanshu Sharma — Sun, 13 Apr 2025 10:14:05 +0000

Configuring SAML authentication to integrate AWS Single Sign-On with Jenkins, enhancing secure user access management and authentication processes.

Integration of tools and platforms is an absolute must nowadays in the fast-paced world of DevOps. A good example would be the integration of AWS SSO with Jenkins, an open-source automation server that’s world-famous. AWS SSO enhances login processes by providing a unique point of authentication for AWS services and Jenkins allows automation processes to build up CI/CD Pipelines. Pairing the two gives peace of mind.

This blog explains the process of integrating AWS SSO with Jenkins and emphasizes the steps and advantages while explaining the best practices.

Pre-requisites

A Running Jenkins Server (in any AWS account).
IAM Identity Center Enabled.

Let’s Begin

Start by searching AWS Identity Center in the search and open this service.

2. You will be redirected to the AWS Identity Center Dashboard. Here you can see the Organization ID, AWS access portal URL and Issue URL.

3. Click Applications under the Application assignments section.

4. Once on the Applications page, click on Add Application.

5. On the configurations page, start by selecting the Application type. Under the Setup preference select “I want to select an application from the catalog”.

6. Now in the Application Catalog, search “Jenkins” and select the application and click Next.

7. On the next page, make sure to note down the details under section IAM Identity Center metadata.

8. Now scroll down and under the Application metadata section, add below details and click submit.

NOTE: The URL mentioned corresponds to your Jenkins server's IP address, followed by /securityRealm/finishLogin in the path.

9. You will see that the Jenkins has been added to the Applications.

10. Now, select your Jenkins application and click on Action -> Edit Attribute Mappings.

11. Update the attributes and formats as below:

12. Now, login to you Jenkins using the Public IP of the Jenkins Server.

Click Manage Jenkins.

13. Now select the Plugins.

14. Under Plugins, select the Available Plugins, then search for SAML.

**Select the first SAML plugin and click **Install.

15. Once the Plugin is installed, go back to Manage Jenkins and select Security.

16. Now under Authentication, change the Security Realm type to SAML 2.0

17. Scroll down and under IdP Metadata URL add the IAM Identity Center metadata file URL from the data copied in Step 7. Once done click on Validate IdP Metadata URL. You will get a success response.

18. Scroll down, under Email attribute add as per below image and under Logout URL add the IAM Identity Center sign-out URL from Step 7.

19. Similarly to Email attribute, add group in the Group Attribute field and click Save.

20. Now, we have our AWS SSO setup for Jenkins. We just need to assign it our Users in the IAM Identity Center.

Select your Application in the IAM Identity Center and click Assign Users and Groups

21. Search and select the user and click Assign.

Now, your users can access this Application once they login via the SSO.

Conclusion

Integrating AWS SSO with Jenkins streamlines secure user access while simplifying authentication management. By leveraging SAML authentication, you can centralize identity management, enhance security with features like MFA, and reduce the overhead of managing multiple credentials. This setup ensures that your Jenkins workflows are not only secure but also aligned with best practices in modern DevOps environments.

With the power of AWS SSO and Jenkins combined, your teams can focus on building, deploying, and scaling applications with peace of mind.