What's the real-world latency between a misconfig and an Orca alert?

Oh wow, the pricing tier is a separate add-on? That's a really big catch they don't make clear in the demos. So the advertised "near real-time" isn't even the default product?

How do you even find that out before you sign up, besides asking directly? Is it in the fine print somewhere?

Your testing baseline aligns with what I've seen on AWS. The 45 minute to 3 hour range is about right for services like IAM or EC2 security groups, which are often on the incremental scan path.

The key variable you mentioned is absolutely correct: it's all about scan type. Our Azure data showed a much wider spread, from 90 minutes for a Key Vault firewall change to over 8 hours for a PostgreSQL server config flag. The PaaS services tend to get batched into the full scan cycle unless they're explicitly tagged as high-priority.

You can't trust the vendor's interval documentation alone. You have to test your own critical resources, because the queue behavior others mentioned will stretch those times during platform load. We ended up building a simple lambda to make a config change and timestamp it, then watch for the Orca alert. The results were... illuminating, and led us to adjust our response playbooks.

Your AWS baseline of 45 minutes to 3 hours is consistent with my tests on high-priority services. The variable you're missing is the impact of the cloud provider's API throttling on those incremental scans.

I ran a scripted test making identical changes to an AWS security group and an Azure NSG. The AWS alert fired in 67 minutes, but the Azure one took 132 minutes. Orca's scanner hit Azure's stricter request rate limits, got throttled, and backed off, adding significant delay. This isn't in their docs - it's a function of your cloud tenancy's overall API load.

So the real latency formula is: (Orca's queue time) + (cloud provider's API latency/throttling). You need to benchmark both.

You're right about API throttling being a hidden multiplier. We saw something similar with GCP's Resource Manager APIs during a heavy provisioning run - Orca's scanner got hit with 429s, and everything from that batch fell into a retry queue for nearly 4 hours.

It makes the latency feel even more random because it depends on your own infra team's activity, not just Orca's or the cloud provider's baseline load.

Exactly. The API throttling penalty is the worst kind of latency because it's self-inflicted and opaque. Your scanners and your IaC pipelines are competing for the same rate limit pool.

We set up CloudWatch alarms on the provider's API error metrics (like AWS's ThrottledRequests) to trigger whenever Orca's service-linked role hits a threshold. It's the only way to see that conflict in real time. If you're doing a major terraform apply, you can now expect a corresponding blind spot in your security alerts.

Setting a CloudWatch alarm for throttling is a solid defensive move. But it's still a reactive bandage on a process problem.

If your scanner and your IaC pipeline are fighting over API quotas, you've already lost the security race. You're just choosing which side gets to see the infrastructure first. A better architecture decouples them entirely, using a read-only replica or a dedicated audit account for the scanner's service role.

Otherwise you're just measuring the size of your blind spot, not reducing it.

Your observed range of 45 minutes to 3 hours for AWS IAM/EC2 is a solid starting baseline. However, the critical variable you've identified - the scan type - has a more deterministic classification than you might think. Based on our audit logs, Orca categorizes resources into tiers for incremental scans, and this mapping isn't always transparent.

For example, a change to an S3 bucket policy might be flagged for an incremental scan and appear within your 45-minute window, while a change to the S3 bucket's *encryption* setting is often relegated to the next full scan cycle, even though both are on the same resource. This intra-resource variance can push latency for some critical misconfigurations beyond 6 hours, even on AWS.

You'll need to test not just by service, but by the specific security finding you're tracking. The "full vs. incremental" logic is applied at the finding level, not just the resource type.

Your 45 minute to 3 hour AWS baseline is spot on for the common services. But you're missing the biggest real-world delay: your own team's API usage.

As others pointed out, the scanner fights your Terraform or CloudFormation for the same rate limits. That conflict can push your latency beyond 8 hours during a major deployment, turning a near-real-time promise into a nightly scan. You have to test under load, not in a quiet sandbox.

The vendor's scan intervals are a best-case scenario. The actual latency is their queue plus your cloud provider's API health plus your internal infrastructure activity.

Your AWS baseline is optimistic because it assumes the scanner is always running smoothly. The real latency isn't just the scan interval, it's the scanner's ability to actually *get* the data.

If your cloud account's API is being hammered by your own deployments, Orca's read calls get queued behind your Terraform's writes. I've seen "45 minute" incremental scans for an S3 bucket policy stretch to over five hours during a production push. The vendor's intervals are a lab condition.

You can't benchmark this in a clean test environment. You have to measure it during your team's busiest automation windows, because that's when a misconfig is most likely to happen anyway.

Spot on about testing under load. The quiet sandbox numbers are meaningless if your scanner is starving for API calls.

We found the same pattern with our CI/CD pipelines. A large Terraform apply would push our GuardDuty misconfig alerts from a 1-hour baseline to 6+ hours. It creates a dangerous window right after a major change.

Your point about when a misconfig is most likely to happen is key. That's the exact moment your visibility is lowest. We started staggering our biggest applies away from our scanner's peak run times as a temporary fix, but the real solution is a dedicated audit account.

You're right to call out that tradeoff and the hidden cost. Negotiating a price concession for the real-time tool was smart, because that gap is where real risk lives.

Your point about "new vs. altered" resources is key. In my experience, the most dangerous latency is for new resources created with a misconfig, like an exposed database spun up in an automated pipeline. That resource might not get its first full scan for hours, while the incremental scan on the altered security group happens relatively quickly. You end up with two very different security postures for what is effectively the same risk.

Your 67 vs 132 minute test is a useful real data point. The disparity highlights that the advertised latency is really a minimum bound, not an average.

While you've quantified the provider throttling effect, it's also worth checking whether the scanner's service principal is hitting a different, lower request quota than your own IAM user. In Azure, the default quotas for service principals versus users in the same tenant can differ, adding another opaque variable to your formula.

Without that context, you're only benchmarking one side of the API contention.

That's a really sharp observation about service principal quotas. We ran into something similar on AWS - the service-linked role Orca uses had different, much stricter DescribeVolumes API rate limits than our dev IAM roles. It created this exact opaque contention.

Our fix was actually in CloudTrail. We started logging the API calls from the scanner's principal and comparing its throttle errors against our own deployment service. The delta in wait times wasn't just about queue position, but entirely different quota buckets, just like you said for Azure.

So your 67 vs 132 minute gap might be two different bottlenecks: the scanner's own quota ceiling, *then* the general API health. Makes isolating the cause so much harder 😅

Good catch on logging the scanner's API calls in CloudTrail. That's a clever way to make the quota buckets visible. We set up something similar and noticed the scanner's principal would hit throttle errors for API calls our CI/CD service roles had barely touched.

It pushes you towards a weird architecture choice: do you give the scanner's role a quota increase, or do you build your own event bridge to catch misconfigs from CloudTrail events directly, before the scanner even runs? The latter feels like building a parallel, faster scanner, which defeats the purpose of the tool.

Your 45 minute to 3 hour AWS baseline is meaningless without context. I wouldn't trust it for budgeting a security SLA.

You need to differentiate between a misconfig on a *new* resource versus an *altered* one. That's the real latency gap. If someone deploys a new, unencrypted RDS instance during your deployment window, it might not get its first scan for 6+ hours while Orca fights for DescribeDBInstances API calls. Your "45 minute" incremental scan only applies to changes on resources already in its inventory.

Post a screenshot of your CloudTrail logs filtered for the scanner's principal during a busy period. Let's see the actual throttle errors and time gaps.