# AWS Continuum for Code Vulnerabilities: GA, Pricing and How It Works

AWS is connecting code findings to cloud context and reviewable fixes, with a pricing model that separates protected code from the work of investigating it.

By Paras Madan | 2026-10-23


AWS made Continuum for code vulnerabilities generally available on October 22, 2026. It uses AI to investigate findings in their application context and deliver proposed fixes. The launch is available in US East (N. Virginia) and US West (Oregon), and fixes still require human approval.

The useful question is how much investigation a security team can hand over without losing the evidence needed to approve a change. A longer list of findings would not solve that problem. A reviewable explanation of what matters could.

## How AWS Continuum connects code to cloud context

The [launch walkthrough](https://aws.amazon.com/blogs/aws/aws-continuum-for-code-vulnerabilities-is-now-generally-available/) describes a context graph built from code and AWS infrastructure. It connects resources, dependencies and business context so findings can be assessed against the environment where the code runs.

Evidence can come from static analysis. For findings it can reproduce, Continuum uses an isolated sandbox and supplies reproduction details. The resulting issue includes supporting analysis and a blast-radius assessment, rather than a severity label alone.

AWS says every fix currently needs human approval. Autonomous application of selected remediation classes is described as future functionality. **Automatic patch delivery does not mean automatic approval or deployment.**

This distinction matters when evaluating the service. The agent can prepare an investigation and a proposed change while the engineering team remains responsible for deciding whether that change belongs in production.

## AWS Continuum pricing

The [pricing page](https://aws.amazon.com/continuum/pricing/) separates code-vulnerability costs into a monthly context fee and a usage-based inference fee. The context fee is tiered by protected lines of code:

| Monthly protected code | Rate per million lines |
| --- | --- |
| First 10 million lines | $200 |
| Next 90 million | $180 |
| Above 100 million through 1 billion | $160 |
| Above 1 billion through 10 billion | $130 |
| Above 10 billion | $100 |

Inference costs $10 per Continuum inference unit, or CIU. AWS combines underlying model work into this billing unit rather than exposing separate model charges.

AWS's small-codebase example totals $1,200 monthly: $200 for one million protected lines and $1,000 for 100 findings at an assumed one CIU each. That assumption is illustrative. Actual inference usage depends on the work required, so $10 should not be read as a fixed price per vulnerability.

For budgeting, the variable to watch is investigation work. Two equally sized repositories need not generate equal bills if one produces findings that require more analysis. An evaluation should measure cost alongside the usefulness of the resulting evidence, not just count the issues processed.

## GitHub and S3 setup requirements

The [getting-started documentation](https://docs.aws.amazon.com/continuum/latest/userguide/cv-getting-started.html) supports GitHub integrations and code packages stored in Amazon S3. The default limit is 10 code repositories per environment, subject to the service's quotas.

GitHub setup requires permission to install and authorize its integration app. For S3, the bucket must be in the same account and Region where Continuum is enabled, with an IAM role granting the required access. Source code is uploaded as a ZIP package.

An environment defines its sources, scan schedule and patch-delivery settings. Scheduled scans can run daily, every two days or every seven days; manual-only operation is also available. Patch delivery opens GitHub pull requests or places patches in S3.

A sensible first deployment would use a bounded application with a clear owner and a known review process. That makes it easier to establish whether the findings are actionable before widening the scope.

## What a delivered patch actually proves

AWS's [patch documentation](https://docs.aws.amazon.com/continuum/latest/userguide/cv-viewing-patches.html) separates producing a patch from applying it. Review the generated change and its delivery destination rather than treating a completed agent run as a completed remediation.

The launch walkthrough does not establish an independently measured false-positive rate or a guaranteed reduction in review time. Those outcomes depend on the application and the work its reviewers still need to do.

**The practical benchmark is a useful fix that survives review.** If the investigation explains why an issue is reachable and the proposed change remains small enough to understand, the service can reduce the work between detection and a decision. The next thing to watch is how consistently it does that on ordinary repositories, not how many findings it can generate.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn complex enterprise AI launches into clear stories that developers, founders and buyers can understand and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).