DEV Community: JASON WOOD

AWS DevOps Agent: Worth It?

JASON WOOD — Thu, 07 May 2026 09:00:42 +0000

AWS DevOps Agent: Worth It?

AWS DevOps Agent is now GA — and it’s in Sydney!

At AWS re:Invent 2025, AWS introduced DevOps Agent as a service designed to be “your always-available operations teammate that resolves and proactively prevents incidents, optimizes application reliability and performance, and handles on-demand SRE tasks.” With general availability, AWS has expanded beyond the initial preview, adding support for more real-world scenarios including hybrid, on-premises, and multi-cloud environments.

Once enabled, DevOps Agent begins by learning your environment: your resources, configurations, and telemetry. From there, it can detect issues, investigate what’s happening, and suggest likely root causes. By the time a human operator steps in, a large portion of the initial triage may already be done.

That sounds pretty awesome… but also a little bit scary.

So, what’s it actually like to use in practice — and what does it cost?

What is AWS DevOps Agent?

AWS DevOps Agent isn’t just a simple AI tool. It’s what AWS refers to as a frontier agent: an autonomous system designed to operate independently, scale as needed, and run with minimal human oversight.

It is designed to help teams investigate incidents, identify root causes, and prevent recurrence by analysing signals across your environment. To do this, it pulls together data from services like Amazon CloudWatch, AWS Systems Manager, and resource APIs to build a picture of what’s happening when something goes wrong.

According to AWS, DevOps Agent works by:

Learning your resources and their relationships
Integrating with your observability tools, code repositories, and CI/CD pipelines
Correlating telemetry, code, and deployment data to understand how your application behaves
Supporting applications across multi-cloud and hybrid environments

Core capabilities

There are three key areas that DevOps Agent focuses on:

Incident investigation

DevOps Agent can take a natural language prompt and begin investigating issues immediately. Instead of manually jumping between metrics, logs, and dashboards, it gathers relevant data and presents a summary of what it believes is happening.

In practice, this means pulling:

Metrics from CloudWatch
Logs from CloudWatch Logs
Recent changes or events
Resource configuration details

All of this gets stitched together into a single story.

Root cause analysis

Once it has the data, the agent attempts to correlate signals and identify likely root causes. This is where things get interesting — it’s effectively doing the “join the dots” work that operators normally do manually.

Rather than just showing symptoms, it aims to answer a much more useful question:

What actually caused this?

Recommendations and remediation guidance

Finally, DevOps Agent suggests possible next steps. These might include configuration changes, scaling actions, or further investigation paths.

It’s important to note that, at least in its current form, this is primarily advisory. It helps you understand and decide. DevOps Agent isn’t making changes for you. A human still needs to do that side.

What’s it actually like?

My colleague Tony and his customer both attended AWS re:Invent 2025 and drank the DevOps Agent cool-aid. While I’ve only played with it in my own environment, he was able to put the preview through its paces in a real-world setting.

When you configure DevOps Agent, you start with an Agent Space. This defines the boundary of what the agent can see and interact with, and it’s not restricted to a single account within your Organisation.

Tony tested this in a development environment that spanned multiple accounts and included hundreds of services, Lambda functions, and supporting resources. Quite impressively, the agent was able to map out the services and their interconnectivity across the environment. With that many components, this process took some time, and the resulting view was understandably complex.

AWS recommends using Agent Spaces to represent smaller, application-focused environments. In practice, that makes a lot of sense. Smaller, more targeted spaces provide clearer visibility and allow the agent to focus more effectively. Or more accurately, they make it easier for the human operator to interpret what’s going on.

Tony has pointed out that having too many Agent Spaces isn't ideal, either. If you have similarly architected environments, grouping them into a single Agent Space may make management easier.

One thing that stood out was the agent’s ability to infer workload structure based on naming conventions. Tony’s team follows consistent, well-structured naming practices for Lambda functions and other resources, which helped the agent quickly establish relationships and understand how components were expected to interact.

It’s a good reminder of the old rule: garbage in, garbage out. The better your environment is structured, the better the results you’ll get from tools like this.

While DevOps Agent can integrate with tools like Slack and ServiceNow, it currently doesn’t make changes within your AWS environment. It operates in a read-only, advisory capacity.

In a world where AI is still finding its place in production environments, that’s a reassuring design choice. The agent can investigate, analyse, and recommend — but the final decision, and the execution, still sits firmly with a human.

What does it cost?

For you? I’ll give you a couple of months free! (Well, AWS will.)

At the time of writing, AWS provides a free tier for the first two months:

“Each trial month includes up to 10 agent spaces, 20 hours of investigations (incident response), 15 hours of evaluations (incident prevention), and 20 hours of on-demand SRE tasks (chat). Standard pay-as-you-go pricing applies for usage beyond these limits and after your trial ends.”

The included amounts give you a great opportunity to try out AWS DevOps Agent. You can then review what your spend would have been and decide if it works for you.

One of the more interesting aspects — and something I haven’t really seen before — is a discount for those on AWS Support contracts. The What’s New post states:

AWS Support customers receive monthly DevOps Agent credits based on the prior month's gross AWS Support spend: 100% for Unified Operations, 75% for Enterprise Support, or 30% for Business Support+.

Outside of the free tier or support discounts, the costs for DevOps Agent are:

$0.0083 per agent-second for investigations (incident response)
$0.0083 per agent-second for evaluations (incident prevention)
$0.0083 per agent-second for on-demand SRE tasks (chat)

This “agent-second” model reflects the time the agent spends analysing, correlating, and generating responses. It’s a slightly different way of thinking about cost compared to typical request-based pricing.

You’ll also want to consider any underlying costs from services like Amazon CloudWatch, especially if large volumes of logs or metrics are queried as part of the investigation.

What’s next?

What now? Well, you’ve got two free months, so give it a go!

I’d recommend keeping your Agent Space targeted. Focus on a single application, ideally one that’s well structured. When you’re trialling the service, you want to see what it can do at its best.

Then try a second Agent Space with something a bit messier. I don't want you to be discouraged by results that aren't great due to the environment. It's sort of like doing a Well Architected review of your entire environment rather than the workload it's designed for. You'll likely get something useful, but not optimal.

This service doesn’t replace your ops team — it enhances them. It reduces the time spent gathering and correlating data, but the judgment, context, and decision-making still sit with your engineer.

AWS EventBridge Transforms: Making Alerts Readable

JASON WOOD — Mon, 10 Mar 2025 01:06:17 +0000

Introduction

AWS EventBridge is a powerful event bus that allows seamless integration between AWS services and external systems. However, one common challenge is that EventBridge events are typically JSON payloads that, while structured, can be difficult to read at a glance—especially when sent to destinations like Amazon SNS for alerting. This can be a pain point for teams, particularly in Managed Services, where help desk staff need to interpret alerts and take action quickly.

Fortunately, EventBridge Transforms offers a solution by allowing us to modify event payloads into a more human-readable format before they reach their destination. In this post, I'll walk through how EventBridge transforms work, provide a hands-on guide to implementing them, and share best practices from real-world use cases.

Understanding EventBridge Transforms

EventBridge transforms allow you to modify event payloads before sending them to targets. Instead of passing raw JSON, you can extract and format key details, making the message easier to read.

Example Problem: Raw JSON payload

Consider an EventBridge event triggered by an AWS resource:

{"version":"0","id":"c8c4daa7-a20c-2f03-0070-b7393dd542ad","detail-type":"GuardDuty Finding","source":"aws.guardduty","account":"123456789012","time":"1970-01-01T00:00:00Z","region":"us-east-1","resources":[],"detail":{"schemaVersion":"2.0","accountId":"123456789012","region":"us-east-1","partition":"aws","id":"16afba5c5c43e07c9e3e5e2e544e95df","arn":"arn:aws:guardduty:us-east-1:123456789012:detector/123456789012/finding/16afba5c5c43e07c9e3e5e2e544e95df","type":"Canary:EC2/Stateless.IntegTest","resource":{"resourceType":"Instance","instanceDetails":{"instanceId":"i-05746eb48123455e0","instanceType":"t2.micro","launchTime":1492735675000,"productCodes":[],"networkInterfaces":[{"ipv6Addresses":[],"privateDnsName":"ip-0-0-0-0.us-east-1.compute.internal","privateIpAddress":"0.0.0.0","privateIpAddresses":[{"privateDnsName":"ip-0-0-0-0.us-east-1.compute.internal","privateIpAddress":"0.0.0.0"}],"subnetId":"subnet-d58b7123","vpcId":"vpc-34865123","securityGroups":[{"groupName":"launch-wizard-1","groupId":"sg-9918a123"}],"publicDnsName":"ec2-11-111-111-1.us-east-1.compute.amazonaws.com","publicIp":"11.111.111.1"}],"tags":[{"key":"Name","value":"ssh-22-open"}],"instanceState":"running","availabilityZone":"us-east-1b","imageId":"ami-4836a123","imageDescription":"Amazon Linux AMI 2017.03.0.20170417 x86_64 HVM GP2"}},"service":{"serviceName":"guardduty","detectorId":"3caf4e0aaa46ce4ccbcef949a8785353","action":{"actionType":"NETWORK_CONNECTION","networkConnectionAction":{"connectionDirection":"OUTBOUND","remoteIpDetails":{"ipAddressV4":"0.0.0.0","organization":{"asn":-1,"isp":"GeneratedFindingISP","org":"GeneratedFindingORG"},"country":{"countryName":"United States"},"city":{"cityName":"GeneratedFindingCityName"},"geoLocation":{"lat":0,"lon":0}},"remotePortDetails":{"port":22,"portName":"SSH"},"localPortDetails":{"port":2000,"portName":"Unknown"},"protocol":"TCP","blocked":false}},"resourceRole":"TARGET","additionalInfo":{"unusualProtocol":"UDP","threatListName":"GeneratedFindingCustomerListName","unusual":22},"eventFirstSeen":"2017-10-31T23:16:23Z","eventLastSeen":"2017-10-31T23:16:23Z","archived":false,"count":1},"severity":5,"createdAt":"2017-10-31T23:16:23.824Z","updatedAt":"2017-10-31T23:16:23.824Z","title":"Canary:EC2/Stateless.IntegTest","description":"Canary:EC2/Stateless.IntegTest"}}

This is not very intuitive for a help desk operator. They may not be very familiar with AWS, and it isn't easy to work out what fields are meaningful, especially when the JSON is presented as a single line.

Using a Transform to Improve Readability

By applying an EventBridge transform, we can extract only the relevant details and format them into a readable message:

"A Guard Duty finding on severity 5 has been raised for source account 123456789012.”
"The finding was generated at 2025-01-25T06:07:04Z and is DefenseEvasion:EC2/UnusualDNSResolver."
"The affected resource type is Instance."
"Description: The EC2 instance i-045678abc09 is communicating with an unusual DNS resolver 172.123.45.6.”

This makes it immediately clear what the affected account is and what happened, reducing the time needed for triage and response.

Implementing an EventBridge Transform

Let's walk through how to set up an EventBridge rule with a transform using AWS CloudFormation.

CloudFormation Example

Below is an example CloudFormation snippet to create an EventBridge rule with a transform that simplifies GuardDuty finding notifications:

  GuardDutyEventRule:
    Type: "AWS::Events::Rule"
    Properties:
      Name: "detect-guardduty-finding"
      Description: "A CloudWatch Event Rule that triggers on Amazon GuardDuty findings."
      State: "ENABLED"
      Targets:
        - Arn: !Ref GuardDutySnsTopic
          Id: "target-id1"
          InputTransformer:
            InputPathsMap:
              "account": "$.account"
              "time": "$.time"
              "source-account": "$.detail.accountId"
              "finding-type": "$.detail.type"
              "resource-type": "$.detail.resource.resourceType"
              "severity": "$.detail.severity"
              "description": "$.detail.description"
            InputTemplate: |
              "A Guard Duty finding on severity <severity> has been raised for source account <source-account>."
              "The finding was generated at <time> and is <finding-type>."
              "The affected resource type is <resource-type>."
              "Description: <description>"
      EventPattern:
        detail-type:
          - "GuardDuty Finding"
        source:
          - "aws.guardduty"
        detail:
          severity:
            - 5
            - 6
            - 7
            - 8

This rule listens for GuardDuty finding notifications, extracts relevant details, and reformats the message into a simple, readable sentence before sending it to an SNS topic.

Testing the Transform in the AWS Console

Jumping straight into CloudFormation is fine if you're comfortable with JSON payload, but most of the time, you don't know exactly what you want to do. AWS provides a way to test and view event transforms directly in the EventBridge console. Here’s how you can do it:

Go to Rules

Go to the EventBridge Console – Navigate to Amazon EventBridge > Rules.

Choose the Rule

Select or Create a Rule – Choose an existing rule or create a new one.

Create the Transformer

Either click on Edit for the rule, or go to the Targets tab and select Edit there.

Expand the Additional settings section and click the dropdown.

Selecting Input transformer brings up a Configure input transformer button.

Create and test your transform

Now we come to the fun part. Creating and testing the rules!
You can either generate a sample event or paste in one of your own.
This is an optional step, but seeing the JSON that you're dealing with is very helpful.

You can expand the Example section to get some ideas for your Input and Template. This is handy if you've not done this much, after a few times, you'll get the hang of it.

Then, fill in the Input path and Input template. The Input path in a JSON construct with the variables you will use in the human-readable text. These variables are taken from the JSON payload. I don't know why you need this additional step, but you do.

Finally, the Input template section is where you enter the message you want to have sent using the variables from the Input path section.

To see what all that will look like, there is an Output section. For this to work, you need either the sample output or to have Entered your own JSON. This is where having a sample of the non-transformed code can really help. You will see what the result will actually be.

Save and Deploy

Once you're satisfied with the output, save and deploy the rule.
Alternatively, you can use it to update your CloudFormation template. I have included a sample above for you to use as a guide.
There is a third option. Scrolling back to my first image, you'll see a button for CloudFormation Template. Clicking that and selecting YAML (for the love of God, don't choose JSON) will generate a CloudFormation template for you. This is great if you are trying this in a dev account. You can use clickops to create your rule and transform, then have your IaC generated for you.

Why This Matters

In Managed Services, we often route AWS alerts to an SNS topic that integrates with our ticketing system. Initially, we sent raw JSON payloads, which made it difficult for help desk staff to understand incidents quickly.

By implementing EventBridge transforms, we significantly improved the clarity of alerts, reducing response times and improving efficiency. For example, instead of:

{"detail": {"instance-id": "i-12345", "state": "terminated"}}

We now see:

EC2 Instance i-12345 has changed state to terminated.

This small change has a big impact on triaging and response.

Best Practices for Using EventBridge Transforms

Keep It Concise – Extract only the necessary details to avoid clutter. The affected resource should be providing the detailed information, not the alert.

Use Human-Readable Formatting – Avoid technical jargon where possible. This is especially important if the first destination is a help desk.

Test Before Deploying – Use the AWS console to verify transformations.

Consider Multiple Destinations – Tailor transformations based on where the alert goes (e.g., SNS, Lambda, or third-party tools like Slack or PagerDuty). Note: You can only have one transform per target.

Monitor and Iterate – Regularly review and adjust transforms to ensure they remain effective. You use transforms to make it easy for people to read the notifications. What may be obvious to you may not be clear to the target audience.

Conclusion

EventBridge transforms are a simple yet powerful way to make AWS notifications more user-friendly. Whether sending events to a ticketing system or a chat app, formatting alerts into a clear and concise format can greatly enhance usability and response times.

If you haven’t yet explored EventBridge transforms, I highly recommend giving them a try. Your help desk team (and your future self) will thank you!

Next Steps

Try setting up an EventBridge transform in your AWS account.
Experiment with different input templates.
Share your experiences and best practices in the comments!

Do you have questions or feedback? Drop them below or connect with me on LinkedIn!

SIMPLIFY ACCESS: A STEP-BY-STEP GUIDE TO USING MULTIPLE AWS ACCOUNTS

JASON WOOD — Mon, 27 Jan 2025 04:03:12 +0000

On January 16, AWS made a game-changing announcement: native support for signing into multiple AWS accounts simultaneously. Previously, trying to log in to another account in a new tab would log you out of the first. This was a pain point for many of us juggling multiple AWS environments. Workarounds like Chrome profiles or the Firefox Multi-Account Containers plugin helped, but they had limitations.

In this blog, I’ll guide you through AWS’ new multi-session support, explore how Firefox Containers work, and share my thoughts on which solution works best.

AWS MULTI-SESSION SUPPORT

If you’re using a single AWS account for all your workloads, it’s time to rethink your approach! Managing multiple accounts is critical for security and organisation. Splitting environments (Dev, Test, Prod) into separate accounts reduces your blast radius—meaning if one account is compromised, the others remain safe. Now that you have a nice multi-account environment, how do you compare things between accounts or environments? Is something in Dev not talking to a bucket in Shared Services? How can you open the console in both accounts?

AWS now offers a native option to open multiple accounts. This works with AWS Identity Centre-configured roles, IAM User access, and cross-account roles. It is both simple and initially confusing.

When you log in to an account, you will be given an option to turn on multi-session support. This is something within your browser and doesn’t directly impact the AWS account you are connecting to. As such, it doesn’t matter what IAM permissions you have.

To enable this feature, go to the account dropdown and click the button to “Turn on multi-session support.”

Ensure you have pop-ups enabled because after clicking the button, you’ll get a pop-up with more information on what AWS multi-session support does and a final confirmation button.

After this, you now see a button to “Add session”.

Here’s where it might get confusing: when you click “Add session,” AWS directs you to the IAM user login screen.

If you’re using AWS Identity Center (formerly AWS SSO), don’t worry—you don’t need to use the “Add session” button. Connect to your next account as you usually would, and AWS will populate the session list automatically.

You keep connecting to accounts, and the active session list will keep getting populated.

Well, that is until you hit the five active session limit.

Similar to when you used to populate “Switch Role”, there is a limit to the number of sessions you can have. You also can’t opt out of removing a session once you hit the limit. That is a bit of an annoyance, but this is the early days for the feature, so AWS may do something about it.

HOW DO YOU SWAP SESSIONS?

Swapping sessions is straightforward. You go to the Account dropdown in the top right and choose one of the active sessions listed. AWS will then open a new tab with you logged into the AWS console for that account with the specified role. Simple!

There is no visual indicator for the different accounts, though. You need to look in the top right corner to see what account and role you are logged in to.

HOW DO YOU LOG IN TO A ROLE?

Cross-account roles are also supported in the new session window. If you click the dropdown on the “Add session” button, you can see any previously configured cross-account roles or add a new one.

Adding a new role is the same as always; you specify the account you want to connect to, the role to assume, and an optional name and colour. If you have an existing role, you can select it. Either option will open a new tab for you. That role will now show in the active sessions window.

FIREFOX MULT-ACCOUNT CONTAINERS

Firefox Multi-Account Containers is an extension designed to isolate browser activity across tabs. Each container acts as its own environment, meaning you can log in to different AWS accounts without interference. A container can have multiple associated tabs. Let me show you how to set it up and why it’s my go-to solution.

Start by installing the extension. Click the extensions icon in your toolbar or search for “Firefox Multi-Account Containers” in the Firefox Add-ons store. There are multiple container extensions, so make sure to choose the official version authored by Firefox.

When enabled, it comes with some pre-configured containers. You can delete or rename them as you desire.

To edit, delete, or reorder, select the Manage Containers button.
In the following window, the “hamburgers” allow you to reorder the containers. You can also click on a container name to modify or delete a container (not shown).

Creating a new container is as simple as giving it a name, choosing a colour, and selecting an icon. There aren’t a lot of options. This is a fairly simple extension, but it does what we need.

The color-coded borders and icons make it easy to identify which account or environment each tab belongs to. For instance, you can set “Prod” to red and “Dev” to green for quick visual differentiation.

WHICH IS BEST?

So, which option is right for you? It depends on your needs.
• For occasional multi-session access: AWS’ built-in support is simple to configure and works seamlessly within your preferred browser.
• For heavy multi-account users: Firefox Multi-Account Containers is a powerful tool, especially if you manage accounts for multiple customers.

For me, working at a consultancy, I deal with multiple customers. Having the Firefox Mult-Account Containers is a godsend. I often connect to multiple AWS accounts, and the coloured tabs help me track who I’m connected to. I will likely make use of the AWS multi-session feature, though. Apart from containers for each customer, I also have a “Misc” container. I use that when I want multiple accounts open for one customer. Using a mix of Firefox Multi-Account Containers, and AWS multi-session support will give me the best of both worlds.

WRAP UP

The new AWS multi-session feature is a fantastic first step, and I’m sure it will improve over time. Meanwhile, Firefox Multi-Account Containers continues to be my go-to for more complex workflows. Try them out and see what works best for your needs. Let me know in the comments how you manage multiple AWS accounts!