Forem: nithish rodrigo

Automated Jira Ticket Creation for AWS EC2 Scheduled Events

nithish rodrigo — Mon, 05 Jan 2026 06:12:07 +0000

This post describes the architecture and configuration required to automatically generate Jira Service Management (JSM) tickets in response to AWS Health notifications about scheduled EC2 instance events (e.g., reboots, instance retirements).

The aim is to eliminate the manual process of reviewing and forwarding AWS notification emails to a service desk email address. With this automation, you can proactively track and resolve AWS‑initiated maintenance activities and also we can do this maintenace under our control.

Architecture Overview

AWS Health Events → EventBridge → SQS → Jira Service Management Connector

At a high level:

AWS Health generates events for EC2 scheduled maintenance.
Amazon EventBridge captures and filters those events.
An Amazon SQS queue receives the events.
The Jira Service Management Connector consumes messages from SQS and creates issues in a JSM project.

AWS Health Setup

Using AWS Organizations, you can centralize scheduled AWS Health maintenance notifications for all EC2 instances across all member accounts into a single “central operations” account. From this account, events are visible in the AWS Health Dashboard and can be routed to other AWS services.

To delegate AWS Health Dashboard organization view to a central account, run the following command from your AWS Organizations management (root) account:
aws organizations register-delegated-administrator \ --account-id <CENTRAL_OPERATIONS_ACCOUNT_ID> \ --service-principal health.amazonaws.com

Replace <CENTRAL_OPERATIONS_ACCOUNT_ID> with the ID of the account where you want to centralize AWS Health events.

AWS EventBridge

EventBridge is used to capture EC2‑related AWS Health events and route them to an SQS queue.

Setup Steps
In your central operations account, create an EventBridge rule, for example: aws_schedule_maintenance_event.
Set the target of this EventBridge rule to an Amazon SQS queue that will buffer health events for downstream processing.

Delivering Events to Jira Service Management via SQS
The SQS queue receives the AWS Health event payloads from EventBridge. These messages are then delivered into a Jira Service Management project using the AWS Service Management Connector for Jira Service Management (often referred to as the “AWS JSM Connector”).

You can install the connector from the Atlassian Marketplace and configure it to read from the SQS queue and create issues in a chosen JSM project (for example, an infrastructure or operations service desk).

High‑Level Configuration in Jira
Once the AWS JSM Connector is installed:

Navigate to the AWS Service Management Connector configuration in Jira.
Configure an AWS account connection that has permissions to read from the SQS queue and interact with the necessary AWS services.
On the connector settings page, ensure the AWS Health integration is enabled.
Enable the desired Jira Service Management project and configure:

For details on accessing Forge‑based Jira app logs for troubleshooting, see Atlassian’s documentation: Access app logs

Outcome
With the above workflow implemented correctly (and with appropriate AWS and Jira configuration), AWS Health events for EC2 maintenance automatically generate Jira tickets in your chosen JSM project.

This gives operations teams:

Proactive visibility into upcoming instance retirements and maintenance.
A consistent ticketing trail for AWS‑initiated changes.
The ability to track remediation work through normal incident or request workflows.

Troubleshooting
Occasionally, the connection between the SQS queue and the JSM connector can fall out of sync (for example, due to transient network or authentication issues). When that happens, EC2 Health events may accumulate in the SQS queue without being turned into Jira tickets.

A typical temporary fix looks like this:

Check the SQS queue
Reset / re‑sync the connector in Jira

After the connection is re‑established and the sync completes, the SQS messages should start being processed, and Jira tickets should appear for any pending EC2 instance retirement or maintenance events.

Future Improvements

To make the automation more effective and user‑friendly, you can enrich the Jira tickets with additional context:

Include instance names in the ticket summary or description, not just the instance ID.
Add environment tags (e.g., prod, staging) and application identifiers to help teams quickly understand impact.
Use a Lambda function or similar service to:

Enriching tickets in this way makes automated notifications more actionable and reduces the time needed for responders to identify and remediate affected resources.

Further this project is complete open source, we can create jira tickets for AWS scheduled maintenance for any AWS services using AWS health.

Automated Jira Ticket Creation for AWS EC2 Scheduled Events

nithish rodrigo — Mon, 05 Jan 2026 06:12:07 +0000

Architecture Overview

AWS Health Events → EventBridge → SQS → Jira Service Management Connector

At a high level:

AWS Health Setup

Replace <CENTRAL_OPERATIONS_ACCOUNT_ID> with the ID of the account where you want to centralize AWS Health events.

AWS EventBridge

EventBridge is used to capture EC2‑related AWS Health events and route them to an SQS queue.

High‑Level Configuration in Jira
Once the AWS JSM Connector is installed:

For details on accessing Forge‑based Jira app logs for troubleshooting, see Atlassian’s documentation: Access app logs

This gives operations teams:

A typical temporary fix looks like this:

Check the SQS queue
Reset / re‑sync the connector in Jira

Future Improvements

To make the automation more effective and user‑friendly, you can enrich the Jira tickets with additional context:

Enriching tickets in this way makes automated notifications more actionable and reduces the time needed for responders to identify and remediate affected resources.

Further this project is complete open source, we can create jira tickets for AWS scheduled maintenance for any AWS services using AWS health.

Automated Jira Ticket Creation for AWS EC2 Scheduled Events

nithish rodrigo — Mon, 05 Jan 2026 06:12:07 +0000

Architecture Overview

AWS Health Events → EventBridge → SQS → Jira Service Management Connector

At a high level:

AWS Health Setup

Replace <CENTRAL_OPERATIONS_ACCOUNT_ID> with the ID of the account where you want to centralize AWS Health events.

AWS EventBridge

EventBridge is used to capture EC2‑related AWS Health events and route them to an SQS queue.

High‑Level Configuration in Jira
Once the AWS JSM Connector is installed:

For details on accessing Forge‑based Jira app logs for troubleshooting, see Atlassian’s documentation: Access app logs

This gives operations teams:

A typical temporary fix looks like this:

Check the SQS queue
Reset / re‑sync the connector in Jira

Future Improvements

To make the automation more effective and user‑friendly, you can enrich the Jira tickets with additional context:

Enriching tickets in this way makes automated notifications more actionable and reduces the time needed for responders to identify and remediate affected resources.

Further this project is complete open source, we can create jira tickets for AWS scheduled maintenance for any AWS services using AWS health.

A Guide to AWS CloudFront Invalidations

nithish rodrigo — Sat, 03 Jan 2026 11:48:19 +0000

Static frontend website requires consistent update to the webpages as the website grows, so a classic cloud native static web content is served ususally by files uploaded to an Amazon S3 bucket which is accessed via cloudfront. A typical issue with static content is some might notice that the old version of webpage still appears when you visit your website though when there is new content is updated. This happens because of caching.

To fix this, you need to perform a CloudFront Invalidation. This guide will walk you through the process step-by-step, ensuring your audience always sees the most recent version of your content.

What is S3 Object Invalidation?
Before we dive into the "how," let's look at the "why."

When you use Amazon S3 to store files and Amazon CloudFront to deliver them, CloudFront stores copies of your files in "Edge Locations" around the world. This makes your website fast because the data is physically closer to your users.

However, CloudFront will keep that copy until it expires (often 24 hours or more). If you upload a new version of webpage to S3, CloudFront won't know it changed. So therefore Invalidation tells CloudFront to delete its cached copies and fetch the brand-new version from S3 immediately.

Step-by-Step: How to Invalidate a File
Follow these steps to refresh your content across the web.

Access the CloudFront Console Sign in to your AWS Management Console.

In the search bar at the top, type CloudFront and select it from the services list.

Select Your Distribution You will see a list of "Distributions" (these are the bridges between your S3 bucket and the web).

Locate and click on the Distribution ID associated with your website

Create the Invalidation Click on the Invalidations tab in the top menu.

Click the orange Create invalidation button.

Define the Object Path In the "Object paths" box, you need to tell AWS exactly which file to clear.

Important: Do not paste the full website URL. Only paste the path that comes after the domain name.

Example: If your file is at https://example.com/restaurant/dinner.pdf, you should enter:

/restaurant/dinner.pdf

Click Create invalidation at the bottom of the page.

Key Points to Remember
Leading Slash: Always start your path with a forward slash /.

Wildcards: If you want to clear an entire folder, you can use an asterisk, such as /restaurant/*.

Timing: Invalidations usually take 1–3 minutes to process globally. Once the status changes from "In Progress" to "Completed," your new file is live!

Additional Resources
For more technical details on how web caching works and advanced invalidation patterns, refer to the official AWS documentation:

AWS Documentation: Invalidating Files

📅 Understanding Application Log Timeframes: A Guide to Log Time Formats and Timezone Differences

nithish rodrigo — Thu, 24 Apr 2025 08:18:09 +0000

Understanding application log time frame is crucial troubleshooting task where application log time could be different from your local machine clock. In this post I will provide simple examples and terms on understanding the time frames.

P.S> attribution to ChatGPT for helping me write my very first dev.to blog

When you're debugging an issue or investigating an incident, logs are your best friends. But nothing is more frustrating than realizing the timestamp in your application logs doesn't match your local time. You might see a log line saying 2025-04-24T10:00:00Z, but you're pretty sure the event happened at 3 PM your time.

In this post, we’ll break down:

What are the time formats commonly used in application logs
What UTC time is
How to identify the time zone used in your logs
How to convert between log time and your local machine’s time
Simple examples to bring it all together

🕒 1. What Time Format Do Application Logs Use?
Most modern applications use UTC (Coordinated Universal Time) in logs. This is a global time standard not affected by daylight saving time or local time zones. It keeps things consistent when logs are aggregated across servers in different regions.

Here are some common log time formats you might see:

Format	Example	Description
ISO 8601 (UTC)	2025-04-24T10:00:00Z	The `Z` means "Zulu time" (another term for UTC).
UNIX Timestamp	1713952800	Number of seconds since Jan 1, 1970 (UTC).
Local Time Format	Apr 24 03:30:00 PM	Varies depending on the server’s time zone.
Custom Formats	24/Apr/2025:10:00:00 +0000	Often used in web server logs (like Apache/Nginx). The `+0000` means UTC offset.

🌍 2. What Is UTC and Why Is It Used?
UTC (Coordinated Universal Time) is the time standard used across the world. Servers, cloud platforms, and applications prefer UTC to:

Avoid confusion from local daylight saving time changes.

Easily correlate logs across distributed systems.

Think of it as the "common ground" for global systems.

If you're in Sri Lanka, your local time is UTC+5:30. So if an application logs a timestamp of 2025-04-24T10:00:00Z, that event happened at 3:30 PM Sri Lanka time.

🕵️ 3. How to Know What Time Zone a Log Uses?
Look for hints in the log format:

A Z at the end → UTC
A number like +0530 → UTC+5:30
No timezone at all? 😬 Then check your application/server settings. It might be in local time or UTC depending on configuration.

🔄 4. How to Convert Log Time to Your Local Time?
Example 1: ISO 8601 UTC to Local Time (Sri Lanka)
Log Time: 2025-04-24T10:00:00Z
Local Time: UTC+5:30 → Add 5 hours and 30 minutes
Result: 2025-04-24 03:30 PM

Example 2: Apache-style Timestamp
Log Time: 24/Apr/2025:10:00:00 +0000
Still UTC, so same conversion as above → 2025-04-24 03:30 PM

Example 3: UNIX Timestamp
Log Time: 1713952800
This needs to be converted using a tool or script (e.g., Python or an online converter):

# In Linux terminal
date -d @1713952800

🛠️ 5. Tips to Work with Different Timezones in Logs
Always check your local time zone offset (especially during daylight saving time).

Use tools like date, timedatectl, or tzutil (Windows) to confirm your current local time setting.

Many log aggregation tools (like Splunk, Datadog, CloudWatch, etc.) can automatically convert UTC to your local time in the UI.

If you’re writing logs yourself, prefer UTC + ISO 8601 format. It’s clean, unambiguous, and machine-friendly.

Conclusion
When reviewing logs from servers or applications, always ask yourself: "What time zone is this in?" Knowing how to read and convert log times accurately will help you:

Correlate issues faster
Understand when exactly something happened
Avoid confusion when comparing logs from multiple systems

Whether you're troubleshooting an incident or analyzing patterns, this understanding is a small step with big impact.