DEV Community: Lokesh Vangari

Creating Multiple AWS EventBridge Rules Using CDKTF and a Config File from S3

Lokesh Vangari — Fri, 23 Jan 2026 15:07:03 +0000

When working with AWS EventBridge, it’s common to create multiple rules with different schedules, targets, and configurations.

Initially, I was creating a separate CDKTF function or resource block for each EventBridge rule. This worked, but the code quickly became repetitive and hard to maintain.

So I moved to a config-driven approach, where EventBridge rules are created dynamically based on a JSON configuration file stored in S3.

This blog explains the idea, the approach, and why it worked well for my use case.

The Problem

As the number of EventBridge rules increased, I faced a few issues:

Repeating the same CDKTF code for every rule
Small changes required code updates and redeployments
Hard to manage different schedules and targets cleanly
Code readability reduced as more rules were added

I wanted a way to define EventBridge rules without writing new infrastructure code every time.

The Idea

Instead of defining each EventBridge rule in CDKTF, I decided to:

Store EventBridge configurations in a JSON file
Upload that file to Amazon S3
Download and read the config file during CDKTF deployment
Loop through the config and create EventBridge rules dynamically

With this approach:

Adding a new EventBridge rule only requires updating the JSON file and re-run the deployment steps
No new CDKTF code is needed for each rule
Infrastructure logic remains clean and reusable

High-Level Architecture

Flow:

CDKTF deployment starts
ConfigJSON config file is downloaded from S3
Config file is parsed
For each entry in the config:
- An EventBridge rule is created
- Target resources are attached

Configuration File Structure (S3)

The JSON file stored in S3 contains all EventBridge definitions.

Each entry defines:

Rule name
Schedule expression
Input
Optional metadata

[
    {
        "name": "default2",
        "description": "The default configuration set",
        "values": {
            "cron_schedule": "0 0 1 1 ? 2000",
            "cron_enabled": false,
            "input": {
                "job_id": "2"
            }
        }
    },
    {
        "name": "default2",
        "description": "The default configuration set",
        "values": {
            "cron_schedule": "0 0 1 1 ? 2000",
            "cron_enabled": false,
            "input": {
                "job_id": "2"
            }
        }
    }
]

Sample code cdktf code snippet

type configJSON = {
    name: string;
    description: string;
    values: {
        cron_schedule: string,
        cron_enabled: boolean,
        input: object
    }
};

for (let i = 0; i < eventConfigs.length; i++) {

    const config: configJSON = eventConfigs[i];

    // Skip if cron is disabled
    if (!config.values.cron_enabled) {
        continue;
    }

    const rule = new cloudwatchEventRule.CloudwatchEventRule(
        this,
        `event-rule-${i}`,
        {
            name: config.name,
            description: config.description,
            scheduleExpression: `cron(${config.values.cron_schedule})`,
            isEnabled: true
        }
    );

    new cloudwatchEventTarget.CloudwatchEventTarget(
        this,
        `event-target-${i}`,
        {
            rule: rule.name,
            arn: "<TARGET_ARN_HERE>", // Lambda / Step Function / Batch
            input: JSON.stringify(config.values.input)
        }
    );
}

Benefits of This Approach

This approach gave me several benefits:

✅ Less CDKTF code
✅ Easier to scale (add 10 or 100 rules easily)
✅ Configuration changes without code changes
✅ Better separation of config and infra logic
✅ Cleaner and more readable CDKTF stack

Things to Keep in Mind

While this works well, a few things are important:

Validate the config file before using it
Handle missing or invalid fields safely
Control access to the S3 config file
Keep versioning enabled on the S3 bucket

Conclusion

Using a config file from S3 to create multiple EventBridge rules dynamically helped me reduce code duplication and made the infrastructure more flexible.

This pattern works well when:

You expect frequent changes in scheduling
Multiple similar resources need to be managed
You want infra to be configuration-driven

This approach can also be extended to other AWS resources like Lambda, SQS, or Step Functions.

Thanks for reading! If you found this helpful, let’s connect on LinkedIn and continue sharing knowledge and experiences:Lokesh Vangari

Lokesh Vangari

☁️ AWS GameDay: From Breach to Fix

Lokesh Vangari — Thu, 16 Oct 2025 09:10:56 +0000

Yesterday, I participated in AWS GameDay, a hands-on challenge designed to test real-world cloud problem-solving skills. The scenario was intense — our website, which was hosted on EC2 instances behind an Application Load Balancer (ALB), had been hacked and encrypted by ransomware! The task was to perform forensics on compromised instances, secure the infrastructure, and restore the application without losing valuable data or uptime.

The setup consisted of:

1 Application Load Balancer (ALB)
1 Auto Scaling Group (ASG) configured to always maintain two healthy EC2 instances
A website hosted on those EC2 instances, which was now showing an encrypted ransom message

Initially, our instinct was to detach and replace the EC2 instances behind the ALB. However, the new instances were also being compromised immediately — meaning the attack source was still active. It became clear we needed to isolate, protect, and then restore in a controlled way.

🧩 Step-by-Step Solution

1. Isolate the Compromised Instances

The first priority was to stop the spread of the attack.
We created a new Security Group with no inbound or outbound rules and then attached it to the compromised EC2 instances.

This effectively disconnected them from the network — keeping them intact for forensic analysis, while stopping any malicious activity from spreading to the new instances.

👉 After this step, the site naturally went down temporarily, as the instances were no longer reachable.

2. Enable AWS WAF for Protection and Monitoring

Next, we implemented AWS Web Application Firewall (WAF) to add an extra layer of protection.
WAF helps monitor and block suspicious traffic before it reaches your application.

We configured it with:

Managed rule groups (to protect against common web exploits)
Custom rules to block specific IPs and patterns we noticed in malicious traffic logs
This ensured that when new instances were launched, they wouldn’t be instantly compromised again.

3. Replace the Compromised Instances

With protection in place, it was safe to restore the website.
We navigated to the Auto Scaling Group (ASG) and used the “Detach and Replace” option.

This automatically:

Removed the compromised instances
Launched fresh, healthy EC2 instances
Registered them with the ALB

Once the new instances were up, the website came back online securely and began serving traffic normally.

✅ Final Outcome

By following this structured approach:

We preserved one compromised instance for forensic investigation.
We blocked the attack vector using AWS WAF.
We restored normal website operations using Auto Scaling automation.

It was a great learning experience in incident response, security hardening, and AWS operational best practices.

AWS GameDay not only tested our technical knowledge but also emphasized the importance of process, containment, and prevention in real-world security scenarios.

Making AWS Event-bridge Cron Expressions Configurable with Azure DevOps and CDKTF

Lokesh Vangari — Tue, 14 Oct 2025 05:09:19 +0000

I wanted to parameterize the AWS EventBridge cron expression in my Azure DevOps pipeline using a Library Variable Group. However, the deployments kept failing whenever we used that particular variable.

After checking the logs, I found that the cron expression value wasn’t being passed correctly to the deployment stage. It turned out that the issue was caused by special characters and spaces in the expression (such as parentheses, asterisks *, and question marks ?) that were being misinterpreted during YAML parsing.

Solution

To fix this, I changed the variable value in Azure DevOps from
cron(0 8 * * ? *) to cron(0-8-*-*-?-*)

Then, in my CDKTF (TypeScript) code, I wrote a small helper function to convert the hyphens (-) back to spaces before using it in the AWS EventBridge configuration.

function configureCronString(cron: string): string {
  return cron.replace(/-/g, " ");  // replaces all '-' with space
}

Later, I had to update the cron expression to a new value: cron(0 13 ? * 2-6 *)
This time, I realized that using - (hyphen) as a delimiter was not safe because it’s a valid character inside cron expressions (for specifying ranges like 2-6).

So, after a bit of testing, I found a better delimiter that doesn’t conflict with cron syntax — the pipe ('|') symbol.

I modified the variable value in the library to: cron(0|13|?|*|2-6|*) And updated the helper method accordingly:

function configureCronString(cron: string): string {
  return cron.replace(/\|/g, " ");
}

This approach resolved the issue completely and allowed me to deploy the AWS EventBridge rule successfully using CDKTF with dynamic cron expressions from Azure DevOps.

— Lokesh Vangari