Automating Dynamic Environments with AWS Lambda, JIRA, and Terraform

One thing I like to do to automate many of my workflows—without having to create a dockerized application—is use AWS Lambda functions. In this post, I’m going to talk about how I spin up customer environments using Lambda functions, with Atlassian JIRA serving as a queuing system.

Background

We have isolated customer environments that are provisioned using Terraform. Each customer is assigned a unique internal PID and a distinct customer name. All associated architecture follows consistent naming conventions. Typically, the process begins with an account representative requesting engineers to spin up a new environment for a proof of concept (POC). The engineer then downloads the appropriate customer templates from our GitLab repository, updates a few specified fields, and runs Terraform through our CI/CD merge request pipeline. However, this was arduous and always involved many back and forths with engineers/account executives. So we automated….

---

Architecture

So we’ll break this down in 3 pieces

• Using JIRA as a Queueing system

  • Custom issue types and issue fields serve as work items in a queue

• AWS Lambda

  • Processes queue items and executes automation tasks

• AWS Eventbridge

  • Schedules regular execution of the Lambda function

The way it works is:

AWS Eventbridge (cron) → Triggers AWS Lambda function ←→ Queries JIRA and runs a set of commands.

---

How I set up JIRA

I created a custom JIRA issue type called "Customer Management" with the following custom fields:

• Account Actions: Dropdown field with values like "Account Creation", "Account Removal"

• Account Name: Text field for the customer identifier

• Account Type: Dropdown with values like "development", "demo(poc)", "production"

• Account UUID: (this is prepopulated)

---

Lambda Function Implementation

The statuses set would be “To do”, “In Progress” and “Done”. The lambda function will do the following:

• looking up all tickets of the type Customer Management and status “To Do”

• Parsing the individual custom fields (and move ticket to In Progress)

• Running the code to download the gitlab repo with the templates and fill the templates

• Create a branch to our customer code repository and create a merge request

• Move original ticket to “Done” after the code is merged

---

Here are some of the code snippets in case you want to play with it yourself.

Core structure

import os
import time
import shutil
from jira import JIRA
import gitlab
from git import Repo

def lambda_handler(event, context):
    # Initialize connections
    jira_client = setup_jira_connection()
    gitlab_client = setup_gitlab_connection()
    
    # Query for pending work items
    pending_issues = get_pending_customer_requests(jira_client)
    
    if not pending_issues:
        print("No pending customer requests found")
        return
    
    # Process each work item
    for issue in pending_issues:
        process_customer_request(issue, jira_client, gitlab_client)
        mark_issue_in_progress(issue, jira_client)
        
    cleanup_temp_resources()

Setup Connection to Jira/Gitlab

def setup_jira_connection():
    jira_options = {'server': os.getenv("JIRA_SERVER_URL")}
    return JIRA(
        options=jira_options, 
        basic_auth=(os.getenv("JIRA_USER"), os.getenv("JIRA_TOKEN"))
    )

def setup_gitlab_connection():
    return gitlab.Gitlab(private_token=os.getenv("GITLAB_TOKEN"))

Queue Processing Logic (using JQL)

def get_pending_customer_requests(jira_client):
    """Fetch all pending customer management requests"""
    jql_query = 'issuetype = "Customer Management" and status = "To Do"'
    return jira_client.search_issues(jql_str=jql_query)

def process_customer_request(issue, jira_client, gitlab_client):
    """Process individual customer request based on action type"""
    
    # Extract issue details
    action = get_custom_field_value(issue, "Account Actions")
    account_name = get_custom_field_value(issue, "Account Name")
    account_type = get_custom_field_value(issue, "Account Type")
    account_uuid = get_custom_field_value(issue, "Account UUID")
    
    # Route to appropriate handler
    if action == "Account Creation":
        handle_account_creation(issue, account_name, account_type, account_uuid, gitlab_client)
    elif action == "Account Removal":
        handle_account_removal(issue, account_name, account_type, gitlab_client)

If you want to see the rest of the code! please comment below and I can send the Github link!!

---

AWS Eventbridge

You can create an Eventbridge rule to trigger the lambda function

{
  "Rules": [
    {
      "Name": "customer-provisioning-schedule",
      "ScheduleExpression": "rate(5 minutes)",
      "State": "ENABLED",
      "Targets": [
        {
          "Id": "1",
          "Arn": "arn:aws:lambda:us-west-2:123456789012:function:customer-provisioning",
          "Input": "{}"
        }
      ]
    }
  ]
}

Using JIRA as a queue system provides a powerful way to manage infrastructure automation requests. Combined with AWS Lambda and EventBridge, this creates a robust, scalable, and auditable system for customer provisioning workflows.