AWS Continuum Pricing for a Startup Pilot and When to Wait

AWS Continuum pricing for code vulnerabilities has two parts: protected-code context and inference usage. Penetration testing is a separately priced capability. Its trial terms do not apply to AWS Continuum code vulnerabilities.

The protected-code fee, billed as ContinuumContext-Code, pays for maintaining context about your codebase. It is not a per-fix fee: you pay for that context, not for a guaranteed number of remediations.

AWS’s official pricing table and monthly example set out these progressive monthly rates. Each rate applies only to protected lines within that band, rather than repricing the whole codebase.

Inference is billed separately as ContinuumInference, at $10 per Continuum inference unit (CIU). Model selection is blended behind that unit; this is not a published per-model token tariff.

AWS’s monthly example breaks down as follows:

• One million protected lines: $200.
• 100 processed vulnerabilities × an assumed one CIU each × $10: $1,000.
• Total monthly charge: $1,200.

The one-CIU average is AWS’s illustrative assumption, not a guaranteed tariff per vulnerability. Do not turn that example into a fixed $10-per-vulnerability budget.

Keep the estimate in USD; use a buyer-entered planning rate for GBP conversion. As with reducing LLM API costs without buying more failures, cost useful outcomes rather than activity. A processed vulnerability is not automatically a validated, merged fix.

Use Context, Compute, Review, Outcome to model AWS Continuum pricing. Context sets the baseline; compute scales with processing; review consumes engineering time. Outcome means independently validated issues resolved by merged changes—not PRs opened.

Copyable pilot worksheet

Context
Protected LOC: ____
Monthly context charge C (USD): ____

Compute
Processed vulnerability count V: ____
Average Continuum inference units per vulnerability u: ____

Review
All-in reviewer hours H: ____
Loaded hourly rate R (USD/hour): ____
Onboarding hours: ____
Onboarding cost O (USD): ____
Incremental supporting-service cost A (USD): ____

Outcome
Independently validated issues fixed by merged changes M: ____

Currency
Buyer-entered GBP per USD g: ____

AWS = C + 10Vu
Operating cost = AWS + HR + O + A
Cost per validated, merged fix = operating cost / M
GBP amount = USD amount × g

Enter monetary inputs in USD; divide GBP inputs by g first. Apply g consistently to every monetary input and output when displaying pounds. Include investigation and rejected patches in H; avoid double-counting onboarding booked under O.

Hypothetical monthly-equivalent sensitivity

Hold protected code at one million LOC, C=$200, V=100, H=20, R=$100/hour and M=20. Only this table assumes O=A=$0.

At u=1, doubling review to 40 hours raises operating cost to $5,200: $260 per fix. These are arithmetic scenarios, not observed AWS benchmarks. Pricing inputs come from AWS; calculations and reviewer assumptions are this article’s model.

Count deduplicated issues resolved, not PRs. With M=0, report “no demonstrated fix yield”, never zero cost.

For two-week reporting, use actual charges and hours. Show onboarding separately from steady-state projections; do not halve the monthly context fee without evidence of proration.

Compare against the same cohort’s current triage-and-fix cost. For wider cloud-cost allocation, see Lack of Visibility into Costs.

AWS Continuum vs Inspector is an overlap test, not a scanner replacement. AWS describes Continuum as combining code and AWS context, assessing exploitability and proposing patches. The GA walkthrough includes static-proof evidence: not every issue has sandbox reproduction.

Keep four things separate: a raw finding, a contextual issue, supporting evidence and a reviewed fix. A proposed patch is not a reviewed fix; tests and normal approval still apply.

Inspector already covers workload scanning and repository SAST, SCA and IaC. Billing varies by workload: EC2 and Lambda use time-based measures; ECR uses image scans. Repository charging is scan-based; repositories above 10MB count as multiple repositories. For AWS Continuum pricing, do not equate an Inspector scan with Continuum inference units: they buy different work.

Use this scanner-overlap checklist. Evidence cells name what to inspect, not proven coverage. Continuum coverage remains untested for every row until demonstrated; confirm existing triggers, owners and costs.

Compare a matched backlog sample using stable identifiers: repository, commit, path, rule or CVE, and resource ARN or image digest. Deduplicate manually where necessary; do not assume a universal third-party findings connector.

Keep existing controls enabled. Count a new evidence-backed prioritisation decision or faster safe fix as value—not another copy of yesterday’s finding.

Approve the data path before onboarding. AWS Continuum UK availability is not the same as UK-Region availability. The 22 October 2026 GA announcement lists US East (N. Virginia), us-east-1, and US West (Oregon), us-west-2, for code vulnerabilities. It does not list London. A UK company can evaluate the service without UK-Region availability; selecting a Region does not guarantee all processing stays there.

Get recorded sign-off covering:

• Content: repository intellectual property, secrets and personal data in code or documents.
• Authority: permission to scan each repository, including customer code and contractual restrictions.
• Handling: permitted processing locations, retention, deletion, model handling and service-improvement use.
• Accountability: named security and privacy owners who approve the pilot’s scope.

The AWS Service Terms matter here. Section 50.3 includes Continuum, excluding penetration testing, and describes service-improvement use and possible out-of-Region storage. It provides an AWS Organizations opt-out mechanism. Section 84.3 applies Bedrock abuse detection, including retention and potential human review for certain models. An improvement opt-out does not disable abuse detection.

These are technical and contractual diligence inputs, not a declaration of GDPR compliance or non-compliance. Wait if mandatory handling requirements cannot be met; a cheap pilot does not justify an unapproved data path.

Keep the August 5 preview-era Claude Code, Codex and Kiro plans separate from the documented GitHub/S3 onboarding path. That announcement said integrations were “coming soon”, not that they were usable. For the related permissions boundary, see How to secure AI agent access to AWS without permanent keys.

1. GitHub: open Integrations → Add integration → GitHub. Install the app, obtaining organisation-owner approval where required, then authorise it. Select the owner and repository in your Continuum environment.
2. S3: upload ZIP source to a bucket in Continuum’s account and Region. Use code/ for source and context/ for supporting context.

Follow the onboarding documentation for the accompanying trust and bucket policies. The role must use path /continuum/integrations/. Its trust policy must allow continuum.amazonaws.com to assume it, with a matching sts:ExternalId.

aws iam create-role --role-name ContinuumPilotRole --path /continuum/integrations/ --assume-role-policy-document file://trust-policy.json

Grant bucket listing, prefix-scoped s3:GetObject/s3:GetObjectVersion reads, and patch read/write access under continuum-patches/. Scope the configuring principal’s iam:PassRole permission to this integration role, not every role.

Select Manual for subsequent scans; environment creation still starts the first build and scan. Automatic patch delivery creates PRs or S3 patch objects. It does not mean automatic merging.

Review path: GitHub/S3 plus optional AWS collector → context and analysis → evidence and proposed patch → human review → required CI → merge.

The collector belongs in the account and Region where the workload runs, as the GA walkthrough explains.

Keep branch protection in charge

Example GitHub branch-protection API payload — protection.json:

{"required_status_checks":{"strict":true,"contexts":["unit-tests","security-regression"]},"enforce_admins":true,"required_pull_request_reviews":{"dismiss_stale_reviews":true,"require_code_owner_reviews":true,"required_approving_review_count":1,"require_last_push_approval":true},"restrictions":null}

These are example existing CI job names, not Continuum-native checks. A matching CODEOWNERS file and repository support for these protection settings are required.

gh api --method PUT repos/OWNER/REPO/branches/main/protection --input protection.json

Apply this only on a pilot repository: PUT replaces its protection configuration. Inspect the current settings first.

Require a human owner to inspect evidence, add a regression test and approve. Allow no bot bypass; this is reviewed patch delivery, not autonomous remediation. After merge, handle release safety separately: Kubernetes zero downtime deployment before canary tooling.

AWS Continuum pricing only matters if fixes survive production review. Run a bounded pilot, not a PR-generation contest.

1. Days 1–2: Approve data handling; nominate an application owner and reviewer. Establish matched baseline findings and current time-to-fix. Configure one or two approved repositories and agree a cash ceiling.
2. Days 3–5: Run the initial scan. Reconcile evidence and duplicates; record actual Continuum inference units (CIUs) and reviewer minutes.
3. Days 6–10: Review, test and merge suitable fixes. Record rejection reasons and regressions.
4. Days 11–14: Recheck fix persistence and complete the scorecard.

Calculate two cost-per-validated-merged-fix figures: fully loaded pilot cost, including setup, and recurring run-rate, excluding setup. Include service charges, CI and engineering time; compare recurring costs against the matched baseline.

Hypothetical failures include plentiful PRs saturating reviewers, a patch passing unit tests but failing an authorisation regression, or cheap scans using an unacceptable data path.

Cloudline’s proposed expansion scorecard

For each gate, record metric, baseline, target, observed result, owner and decision. These are Cloudline’s decision rules, not AWS performance claims. Adjust numeric thresholds before the pilot; they are not industry benchmarks.

• Data path: approved.
• Source/build/patch workflow: working end to end.
• Merged patches: every change human-approved, with required checks passed.
• Critical regressions: none.
• Deduplicated, validated issues fixed by merged changes: at least 10.
• Median issue-to-merge time: at least 25% below matched baseline.
• Operating cost per validated merged fix: no higher than baseline.
• Spend: within the agreed cash ceiling.

A small sample is inconclusive, not success. Expand only when every hard gate passes; otherwise wait, narrow scope or retain current tooling. Select Manual only to stop new scheduled work—not as a guaranteed billing cutoff.

For help assessing overlap, IAM, review capacity and operating costs, ask Cloudline for a DevSecOps tooling and cost assessment.

Start with the decision, not the integration. A worthwhile pilot needs an approved data path, a supported workflow, protected merges and a cost per validated fix your team can defend. Keep existing scanner coverage while you measure the difference, and wait if a hard gate fails or the sample proves too small. Cloudline Consulting can help assess DevSecOps tooling, reviewer capacity and cloud costs, so the next step is a bounded engineering experiment rather than another open-ended security subscription.