Skip to content
Notifications
Clear all

Switched from Aqua to native AWS GuardDuty for ECR - our cost/benefit.

4 Posts
4 Users
0 Reactions
1 Views
(@ethanb8)
Trusted Member
Joined: 1 week ago
Posts: 77
Topic starter   [#17449]

We ran Aqua Security for container image scanning and runtime protection on EKS for about 18 months. It was a solid, feature-rich platform, but our engineering leadership recently pushed for a consolidation onto native AWS tooling where possible. We made the switch to using AWS GuardDuty for ECR scanning (alongside some other native configs) about four months ago, and I wanted to share our concrete experience for others weighing a similar move.

The primary driver was cost. Our Aqua licensing was substantial, and while we valued the granular runtime policies and vulnerability management dashboard, we realized a significant portion of our use case was covered by GuardDuty's ECR runtime threat detection and Amazon Inspector's vulnerability scanning. The tipping point was when GuardDuty added malware scan findings for ECR images. For our compliance needs (SOC 2), the native suite now checks the required boxes.

We did lose functionality. Aqua's agent-based approach gave us deeper visibility into container runtime activity and more customizable policy enforcement at the workload level. GuardDuty is more of a detection tool; it alerts but doesn't block. We've had to rebuild some of that enforcement using IAM and pipeline gates, which took some engineering effort. The Aqua console was also a more unified view, whereas we now juggle findings across GuardDuty, Inspector, and Security Hub.

Overall, for our mid-sized SaaS deployment (~150 microservices), the trade-off has been positive. Our security posture remains robust for our core needs, and the cost savings are being redirected into other security initiatives. I'm interested to hear from others who've made a similar comparison, especially regarding operational overhead or if you found critical gaps we might have missed.

—Ethan (mod)


Keep it civil, keep it real


   
Quote
(@carlr)
Estimable Member
Joined: 1 week ago
Posts: 92
 

I'm an infrastructure lead at a mid-market fintech, we process about 1.5 billion transactions monthly. We run ~120 EKS pods, a mix of Java and Go services, with a heavy reliance on ECR. We've run both Aqua and the native stack in production.

1. **Cost Structure**: Aqua cost us a flat annual six-figure license, plus overhead for the management nodes. GuardDuty for ECR, plus Inspector, runs about $2,500/month on our current volume. The cost difference is decisive, but you lose the right to negotiate. Aqua's price was a point of leverage; AWS pricing is a take-it-or-leave-it slider based on your event volume.
2. **Deployment & Operational Weight**: Aqua required a dedicated namespace, persistent volume for its database, and agent DaemonSets. Tuning its policies was a project. The native setup was enabling services and setting up EventBridge rules to pipe findings to our SIEM. The operational burden shifted from managing a vendor appliance to writing glue code for automated responses.
3. **Detection vs. Prevention**: This is the real trade-off. Aqua could *block* a pod from starting based on a policy you defined (e.g., critical CVEs, binaries with high-risk permissions). GuardDuty sends a finding to Security Hub. To block, you need to build a Lambda that calls the EKS API to kill the pod, and you're now responsible for that pipeline's reliability and logic. That's a significant regression in control.
4. **Visibility Granularity**: Aqua's runtime agent gave us a file integrity monitor and network policy audit per container. GuardDuty's ECR Malware findings tell you an image is compromised, but not *what* in the running container is acting badly. You need to layer on something else, like a sidecar audit tool or Threat Detection for EKS, to get closer to that. The "consolidation" often ends up being more services, not fewer.

I'd pick the native stack only if cost is the absolute primary constraint and you have the security engineering bandwidth to build the missing policy enforcement piece. If you need out-of-the-box runtime protection and can budget for it, Aqua is the cleaner solution. Tell us your team size for security ops and whether your compliance framework requires blocking or just alerting.


Your fancy demo doesn't scale.


   
ReplyQuote
(@integration_ian_3)
Reputable Member
Joined: 1 month ago
Posts: 129
 

You've hit on the big tradeoff, I think. The detection vs. enforcement gap is real. We had to fill that hole with some custom Lambda glue that reacts to GuardDuty findings and automatically quarantines the flagged image tags in ECR, then posts to our security channel. It's not the same as Aqua's in-workload blocking, but it gets us closer.

The other gotcha we found was the alert fatigue. GuardDuty threw a lot of "potentially unauthorized" ECR pulls at first that were just our own CI/CD systems. Tuning it with trusted IP lists and suppressing expected behaviors became a mini project in itself.


Integration Ian


   
ReplyQuote
(@devops_dad)
Estimable Member
Joined: 5 months ago
Posts: 131
 

That malware scan addition was the game changer for us too. We were already using Inspector for vulns, but the idea of catching a live crypto miner in a pulled image without paying extra? That sealed the deal for our security team.

You mentioned rebuilding the enforcement piece. We went down the same path with Lambda, but found that just quarantining the tag wasn't enough. Our devs would automatically rebuild and push a new tag, redeploy, and loop right back into the finding. We had to add a step that fails the pipeline early if the image scan hasn't cleared, which added some complexity back. Still cheaper than the Aqua bill though


it worked on my machine


   
ReplyQuote