Why AWS-Native Security Operations Is the Only Architecture That Works for FedRAMP 20x, Rev. 5 and DoD Customers

The case for building your security operations stack on the same infrastructure your customers must authorize against.

This is Part 1 of the AWS-Native Security Operations Series. If you're starting here, we recommend reading the series introduction first: 'Defending the Mission Isn't a Feature. It's an Operating Model.' That post makes the case for why continuous defense matters and what it looks like in practice. This series goes inside the architecture that makes it possible.

When InfusionPoints built the Continuous Trust Platform (CTP), we made a foundational architecture decision: everything runs on AWS-native services, in the regions our customers operate in, on infrastructure that carries the same compliance inheritance their authorization requires.

That wasn't a vendor preference. It was a mission requirement.

The CTP is organized around a continuous engine: Build, Operate, Prove, Defend. VNSOC360 is the Defend layer. Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) run through Operate and Prove. Command Center and AuditShield surface the evidence. XBU40 is the pre-authorized foundation everything runs on. AWS-native services are the instrumentation layer connecting all of it.

Federal security environments have constraints that eliminate most commercial security tooling before a conversation starts. U.S.-citizen-only operations. FedRAMP-authorized tooling. GovCloud deployment for IL4 and IL5 workloads. Data residency controls. Audit trail requirements that most commercial SaaS platforms weren't designed to meet.

A security operations provider that runs its own platform on infrastructure that doesn't meet those requirements creates a compliance gap inside the very service meant to close compliance gaps. We weren't willing to do that. So we built on AWS.

Why this matters for FedRAMP 20x and DoD/DOW customers

For FedRAMP 20x and DoD/DOW customers, the issue is no longer whether security and compliance can be documented at review time. The real question is whether trust can be operated, monitored, validated, reported, and defended continuously across the environment where the mission actually runs.

FedRAMP 20x is moving the market toward faster, evidence-driven authorization through Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER). DoD and DOW customers need that same speed, but with additional mission constraints: IL4 and IL5 boundaries, U.S.-person operations, controlled data flows, inheritance discipline, continuous risk reporting, and defensible audit trails. If the security operations layer is disconnected from those requirements, it adds friction instead of reducing risk.

This is especially important in light of CISA Binding Operational Directive 26-04, which shifts federal vulnerability response away from generic severity scoring and toward risk-based prioritization based on public exposure, Known Exploited Vulnerability status, exploit automation, and technical impact. FedRAMP has aligned VDR and VER with that model, making vulnerability detection, evaluation, prioritization, reporting, and response part of the continuous authorization expectation.

An AWS-native operating model helps close that gap. It keeps the technical architecture, compliance evidence, vulnerability telemetry, detection pipeline, and mission environment aligned from day one. That means customers can move toward authorization faster, prove continuously, reduce audit burden, respond to real exposure faster, and defend the environment without bolting on a separate trust model after the fact.

What AWS-native actually means in practice

AWS-native means the services doing the work are AWS services, deployed in the customer's AWS environment or in AWS GovCloud, not third-party tools running on AWS infrastructure. The distinction matters because AWS-native services inherit the compliance posture of the underlying platform.

GuardDuty, Security Hub, Inspector, Config, CloudTrail, Kinesis, and OpenSearch all have FedRAMP authorizations. When we deploy them in a customer's GovCloud environment, we're not asking that customer to extend trust to a new vendor. We're using services they've already accepted as part of their authorization baseline.

That's a significant difference. Every additional third-party tool in a federal security stack is a new authorization scope item, a new data flow to document, a new vendor to assess, and a new attack surface to monitor. AWS-native minimizes that overhead without sacrificing capability.

GovCloud and commercial: two environments, one operating model

InfusionPoints delivers VNSOC360 and VER/VDR-aligned services across both AWS GovCloud (US) and commercial AWS regions. That's not a toggle we flip. The two environments have different service availability, different compliance inheritances, different API endpoints, and different operational requirements.

GovCloud is an isolated AWS region operated exclusively by U.S. persons, physically and logically separate from standard AWS regions. It's designed specifically for sensitive government workloads. Our GovCloud deployments serve customers with IL4, IL5, and FedRAMP High requirements. Every service in the pipeline must be available in GovCloud, every data flow must stay within the region boundary, and every access control must meet the citizenship and access restriction requirements GovCloud enforces by design.

Commercial deployments serve FedRAMP Moderate customers, CMMC contractors, and commercial organizations handling sensitive data. The same AWS-native service architecture applies, the same pipeline runs, and the same VER/VDR-aligned detection, evaluation, reporting, and response workflows execute.

Most of our federal customers have workloads in both environments or have partners and contractors operating in commercial who need to meet the same security expectations as the prime. A vulnerability detection, evaluation, and response model that covers GovCloud but misses the commercial-side partner environment has a gap. We close it.

What our AWS partner designations actually required us to demonstrate

InfusionPoints is an AWS Premier Tier Partner with multiple AWS-validated designations that matter directly to federal, defense, and regulated customers. These include the AWS Managed Service Provider (MSP) designation, AWS Security Competency, AWS Government Competency, AWS Well-Architected designation, and AWS Level 1 MSSP Competency.

These are not marketing badges. AWS validates the operating model behind each designation, including technical architecture, customer delivery practices, operational maturity, security capabilities, and the ability to produce repeatable customer outcomes.

The Level 1 MSSP Competency is especially relevant to VNSOC360 and VER/VDR because it validates managed security operations, continuous detection, response, and customer security outcomes. Earning it required demonstrating that we deploy and actively operate defined AWS security services on behalf of customers, maintain documented detection and response procedures, operate a 24x7 SOC with U.S.-based coverage, and provide evidence of customer results. AWS reviewed the architecture, operational procedures, and supporting evidence. The designation reflects what we actually do, not what we say we do.

The AWS MSP designation reinforces the Operate side of the Continuous Trust Platform. It validates that InfusionPoints can manage customer AWS environments with disciplined cloud operations, governance, automation, monitoring, cost awareness, security practices, and lifecycle management. For customers, that matters because trust is not created only at deployment. It has to be operated every day.

The AWS Security Competency validates our depth in securing AWS environments, including the design, implementation, and operation of security capabilities that help customers reduce risk and maintain a stronger security posture. That competency aligns directly to the Defend layer of the CTP and the work VNSOC360 performs across customer environments.

The AWS Government Competency matters for FedRAMP, DoD, and DOW customers because it validates experience supporting public sector missions on AWS. It signals that InfusionPoints understands the additional expectations around regulated workloads, government procurement, compliance inheritance, mission assurance, and secure cloud operations in public sector environments.

The AWS Well-Architected designation complements those competencies by validating our ability to assess and improve cloud workloads against AWS best practices. That is important for customers using the CTP because architecture quality, operational excellence, security, reliability, performance, cost optimization, and sustainability all affect the strength of the trust picture.

For customers evaluating security operations, managed cloud operations, or continuous compliance providers, that external validation matters. It means AWS reviewed how we design, operate, secure, monitor, and support customer environments and confirmed that our practices meet the standard. For FedRAMP 20x and DoD/DOW customers, that helps reduce trust friction before the first architecture conversation even starts.

What this series covers

This is the first post in a six-part series on how InfusionPoints uses AWS to power the Continuous Trust Platform, delivering continuous threat detection, vulnerability detection and response, vulnerability evaluation and reporting, and the full Build, Operate, Prove, Defend lifecycle through VNSOC360, Command Center, and AuditShield.

Each post goes deep on a specific layer of the architecture:

• Part 2: How we detect threats across your AWS environment (GuardDuty, Security Hub, Inspector, Macie, IAM Access Analyzer, Detective)

• Part 3: The log pipeline that makes it all auditable (CloudTrail, CloudWatch, Kinesis, OpenSearch, S3)

• Part 4: VER/VDR in practice: vulnerability detection, evaluation, reporting, and response aligned to FedRAMP 20x and CISA BOD 26-04

• Part 5: Command Center, the platform that ties it together (the full lifecycle view, ALTO AI, FedRAMP 20x KSI)

• Part 6: AI in federal security operations (Bedrock, AgentCore, and what changes for analysts)

The architecture described across these posts isn't theoretical. It's what runs every day across our customer environments, in GovCloud and commercial AWS, 24 hours a day, staffed by U.S. citizens on U.S. soil.

Next in the series: Part 2: How We Detect Threats Across Your AWS Environment

Contact InfusionPoints at info@InfusionPoints.com or 336-990-0252.