AWS DevOps Agent at Wargaming: turning infrastructure context into decisions
Discover how Wargaming uses AWS DevOps Agent to map infrastructure, uncover unused resources, cut CloudFront traffic by more than 80%, troubleshoot OpenSearch, and turn AWS account context into faster, safer engineering decisions.
Siarhei Saurytski , Wargaming; Mikhal Ishenin , AWS
Wargaming's WOT:Heat team stumbled onto AWS DevOps Agent by accident. Siarhei was in the console, working out how to stand up a small Kafka cluster, and he opened the agent expecting a config he could copy. Instead of an answer, it came back with questions of its own: how much data, what load, which region, what budget, and had he weighed managed against serverless? Those are the things worth pinning down before you spin anything up, and the agent raised them first, instead of handing back a canned config.
That was enough to make him curious. He started putting everyday infrastructure questions to it, this time against a real account: several regions, hand-built wiring, managed services, and resources left behind by previous teams. The team had deep knowledge in specific areas, but the day-to-day work was Siarhei's to sort out on his own.
This is where the agent beat a plain documentation chatbot. It saw more than the question. It saw the account itself.
Siarhei puts it this way: "It doesn't just hand you data — you can dig down to what's actually going on, to a depth that's hard to reach just clicking around the console."
AWS DevOps Agent builds a model of a specific environment: it discovers resources, reconstructs how they connect, and, once you plug in more sources, lines them up with metrics, logs, code, and deployment history. The agent puts that model to work across everyday infrastructure questions, incident investigations, and checks on upcoming releases.
What the agent saw in the account
Once you connect your AWS accounts, the agent builds an application topology : a map of resources and the links between them. You can view it for the whole system, for a group of components, or for a single resource.
At Wargaming, infrastructure from several regions came together in one diagram. During the interview, Siarhei opened one of the detailed topology views for the first time and started tracing the connections between components.
"I honestly couldn't tell why it draws things the way it does, but it figures out on its own that this is our service. Cool how it laid it out."
No separate agent per region was needed. One agent could field questions about resources across the whole connected environment: what's linked to what, why a resource can't be deleted, what changed over the past week, or where the money goes.
Summarized Topology View
Raw Topology View
What it looked like in practice
Clearing out unused resources
One of Siarhei's first requests was blunt: find what was no longer needed in the account.
Over the years, the account had piled up security groups, Elastic IP addresses, keys, and other leftovers from old installs and clusters. Some were still costing money, some had fallen out of use, and leaving them unchecked didn't sit right either.
A list on its own solved nothing. Take a security group from 2019: it looked pointless right until you tried to delete it, and then the console would flag a dependency on another group or a network interface. In the past, that meant a trip into the documentation and rebuilding the dependency chain by hand. Now Siarhei could just ask up front: what's this resource tied to, what does it do, and why can't it be removed?
The team untangled those dependencies and cleared out the unused resources.
Siarhei recalls: "Like Levon likes to say: nice and tidy. And that's what we got, nice and tidy."
A while later, the same kind of check caught a fresh mistake. The team had updated the AMI for their TeamCity agents, and a week on, Siarhei dropped into the chat with a casual "so how are things?" The agent found orphaned EBS volumes and flagged what mattered: they'd started appearing right after the update. The cause was simple. The new configuration didn't set the volumes to delete on instance termination. They fixed it before it could pile up.
CloudFront: two hours of co-work with an agent
With CloudFront, it started with the bill. Siarhei looked at the cost and the traffic volume, then asked the agent what could be optimized.
The agent broke consumption down by region and explained how the different CloudFront Price Classes would change the cost and latency of content delivery. Then it looked at the files themselves and caught a detail: when an image was updated, its name changed too, so nothing was requesting the old object anymore. That meant the cache lifetime could safely go up to a year.
In about two hours the team reworked the configuration and, in Siarhei's words, cut both the load and the volume of traffic being served by more than 80%.
"One sentence, 'see what you can optimize,' turned into a strategy. Really about two hours of work, and the CDN was optimized."
OpenSearch, and where the customer's access ends
Amazon OpenSearch Service posed a different problem. A lot of the advice for a self-managed ELK cluster assumes an engineer can turn the knobs and watch what happens. In a managed service, some of those settings are off-limits to the customer.
The agent analyzed retention windows and index placement, sharding, node count, and the cluster capacity required. Later, the main recommendations from AWS specialists matched its conclusions. By Siarhei's estimate, the team rolled out some of the changes about a week and a half sooner than it would have otherwise.
Not everything could be settled on the customer's side, though. At one point the agent hit a parameter that can't be changed from within the managed service. It suggested going to AWS Support and helped put together a write-up of the problem and the possible fixes. Siarhei opened the support case himself, working from that analysis.
The team did not use it for this case, but AWS DevOps Agent has a built-in AWS Support integration : you can hand a Support engineer the investigation materials, the conclusions reached, and the actions proposed.
There were other tasks too. For a CIDR expansion, the agent handed over the commands step by step. For AWS Global Accelerator logging, it helped stitch together a working sequence across several services, since the docs had no one-line recipe for it.
The engineer still ran the commands
By default, AWS DevOps Agent gets read-only permissions. On top of that, the service enforces a permission guardrail : the effective privileges are the intersection of the customer's IAM role and the set of actions the service itself permits. Destructive operations stay out of the agent's reach, even if you add them to the IAM role.
At Wargaming, the agent analyzed resources, explained dependencies, and proposed a sequence of CLI commands. Siarhei ran them. Before any step, he could stop and ask again whether the action was safe, what it would touch, and how to verify the result.
Recommendations didn't apply themselves either. The agent suggested moving some workloads to AWS Graviton, for example, and trimming allocated memory where usage was low. The team passed: the migration needed testing time, and that memory headroom was there for spikes and future growth.
The agent could see current usage, but the team knew why the setup looked the way it did.
What Wargaming hasn't used yet
For now, the team mostly works with the topology and asks infrastructure questions through the chat. It has barely touched automated incident investigation: infrastructure incidents were rare, and the problems that did surface usually came from the game's own logic.
In production operations, AWS DevOps Agent can open an investigation after an alert or an incident ticket, line up metrics, logs, code changes, and deployment history, then propose a remediation plan. In release management, available in preview, that same context feeds a risk assessment of a change before it reaches production.
The next step the team is weighing is simpler and more concrete: gradually capture the hand-built CloudFront configurations in Terraform, then test how the agent can use them for analysis and audit. The team wants to see whether that could help check the real state of the infrastructure against a controlled change history.
Takeaway
Wargaming started with plain questions against a real account: no automated incident response, no full delivery pipeline wired in. That was already enough to surface old resources, catch a fresh mistake after an AMI update, optimize CloudFront, and get a faster handle on OpenSearch's limits.
The agent shrank the part of the job that usually eats the most time: digging details out of the account, piecing together the dependencies, running down the right documentation, then turning all of it into steps you can verify.
As of this writing, AWS DevOps Agent is billed by the second: investigations, prevention evaluations, and on-demand SRE tasks run
$0.0083 per second of the agent's active work, and idle time isn't charged. New AWS DevOps Agent customers receive a two-month free trial, subject to monthly usage limits. After that, customers on Business Support+, Enterprise Support, and Unified Operations receive monthly AWS DevOps Agent credits worth 30%, 75%, and 100% of their monthly AWS Support charge, respectively. Depending on how much you use it, those credits can cover the agent's cost in full, but they're issued as a percentage of Support spend, expire at month-end if unused, and don't add up to unlimited free access.Siarhei sums it up: "When you're a bit short on expertise here and there, it speeds up decisions and helps you find a way out."
Product references
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article