Skip to main content
INS // Insights

FedRAMP Readiness in Cloud Architecture

Updated March 2026 · 11 min read

FedRAMP authorization isn't something you bolt onto a system after it's built. It's an architectural discipline that shapes every design decision from the first commit. Organizations that treat FedRAMP as a checklist to complete after development discover — painfully — that retrofitting 300+ security controls into an existing system costs three to five times more than building them in from the start.

At Rutagon, we design cloud systems with FedRAMP controls embedded in the architecture itself. Our approach draws from the same principles behind our CMMC security architecture and security-first CI/CD pipelines — security isn't a feature, it's a foundation. Security Is Architecture.

This article describes our approach to FedRAMP-ready cloud design: how we define authorization boundaries, implement continuous monitoring, enforce encryption, and build the audit infrastructure that satisfies assessors.

Understanding Authorization Boundaries

The authorization boundary is the most consequential decision in a FedRAMP engagement. It defines what's in scope — and everything inside that boundary must meet every applicable control. Draw the boundary too wide, and the compliance surface becomes unmanageable. Draw it too narrow, and you exclude components that assessors will flag as connected systems.

Boundary Definition Principles

We apply three principles to boundary definition:

1. Minimize the boundary surface area. Every component inside the boundary adds compliance overhead. Use managed services where possible — AWS services that are themselves FedRAMP authorized (S3, RDS, Lambda in GovCloud) inherit their authorization and reduce the number of customer-responsible controls.

2. Clear data flow documentation. Assessors need to trace every data path from ingestion to storage to egress. Undocumented data flows are findings. We generate data flow diagrams from infrastructure-as-code, not from manual documentation that drifts from reality.

3. Explicit interconnection agreements. Any system that connects to the FedRAMP boundary — even read-only — requires an Interconnection Security Agreement (ISA). Architect the system so that interconnections are minimal, well-defined, and mediated through controlled interfaces.

Multi-Account Boundary Implementation

AWS multi-account architecture maps cleanly to FedRAMP boundaries. We use AWS Organizations with dedicated accounts for each trust zone: 

┌─ FedRAMP Authorization Boundary ─────────────────────────┐
│                                                           │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐   │
│  │  Production   │  │   Staging    │  │   Security   │   │
│  │   Account     │  │   Account    │  │   Account    │   │
│  │  (Workloads)  │  │  (Testing)   │  │ (Logging &   │   │
│  │              │  │              │  │  Monitoring)  │   │
│  └──────────────┘  └──────────────┘  └──────────────┘   │
│                                                           │
│  ┌──────────────┐  ┌──────────────┐                      │
│  │  Management   │  │   Shared     │                      │
│  │   Account     │  │  Services    │                      │
│  │  (Org Root)   │  │  (Network,   │                      │
│  │              │  │   DNS, etc)  │                      │
│  └──────────────┘  └──────────────┘                      │
│                                                           │
└───────────────────────────────────────────────────────────┘

Each account has its own IAM boundary, VPC isolation, and CloudTrail logging. The security account is the aggregation point for all audit data — CloudTrail logs, VPC Flow Logs, Config rules, GuardDuty findings, and Security Hub results all flow to the security account and cannot be modified by workload accounts.

Continuous Monitoring Architecture

FedRAMP Continuous Monitoring (ConMon) requires ongoing assessment of security controls — not just at authorization time, but every month thereafter. We automate ConMon with AWS-native services configured as a cohesive monitoring stack.

AWS Config Rules

AWS Config continuously evaluates resource configurations against compliance rules. We deploy a baseline of Config rules that map directly to FedRAMP controls: 

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Description: "AC-3, SC-28: EBS volumes must be encrypted"
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
      Scope:
        ComplianceResourceTypes:
          - "AWS::EC2::Volume"

  RestrictedSSHRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: restricted-ssh
      Description: "AC-17, SC-7: SSH must not be open to 0.0.0.0/0"
      Source:
        Owner: AWS
        SourceIdentifier: INCOMING_SSH_DISABLED
      Scope:
        ComplianceResourceTypes:
          - "AWS::EC2::SecurityGroup"

  RDSEncryptionRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: rds-encryption-enabled
      Description: "SC-28: RDS instances must be encrypted at rest"
      Source:
        Owner: AWS
        SourceIdentifier: RDS_STORAGE_ENCRYPTED
      Scope:
        ComplianceResourceTypes:
          - "AWS::RDS::DBInstance"

  MFAEnabledRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: iam-user-mfa-enabled
      Description: "IA-2: IAM users must have MFA enabled"
      Source:
        Owner: AWS
        SourceIdentifier: IAM_USER_MFA_ENABLED

Each rule references the NIST 800-53 control it satisfies. When a Config rule detects a non-compliant resource, it triggers an SNS notification, creates a Security Hub finding, and optionally triggers automated remediation through Lambda.

Security Hub Integration

AWS Security Hub aggregates findings from Config, GuardDuty, Inspector, Macie, and third-party tools into a single dashboard. We enable the NIST 800-53 Rev 5 security standard in Security Hub, which automatically maps findings to FedRAMP controls: 

import boto3

securityhub = boto3.client('securityhub')

securityhub.batch_enable_standards(
    StandardsSubscriptionRequests=[
        {
            'StandardsArn': 'arn:aws:securityhub:::standards/nist-800-53/v/5.0.0'
        }
    ]
)

Security Hub's compliance score provides a real-time view of FedRAMP control implementation. A score below 90% triggers escalation. A score below 80% blocks deployments until findings are remediated.

Encryption Architecture

FedRAMP requires encryption at rest (SC-28) and in transit (SC-8) for all federal data. We implement encryption as a default — not an option — across every data store and communication channel.

Encryption at Rest

Every data store uses AWS KMS customer-managed keys (CMKs) with automatic key rotation: 

resource "aws_kms_key" "data_encryption" {
  description             = "FedRAMP data encryption key"
  deletion_window_in_days = 30
  enable_key_rotation     = true
  multi_region            = false

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "EnableRootAccountAccess"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::root"
        }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "AllowKeyUsage"
        Effect = "Allow"
        Principal = {
          AWS = var.authorized_role_arns
        }
        Action = [
          "kms:Decrypt",
          "kms:DescribeKey",
          "kms:Encrypt",
          "kms:GenerateDataKey",
          "kms:ReEncrypt*"
        ]
        Resource = "*"
      }
    ]
  })

  tags = {
    FedRAMP_Control = "SC-28"
    Environment     = var.environment
  }
}

resource "aws_kms_alias" "data_encryption" {
  name          = "alias/${var.environment}-data-encryption"
  target_key_id = aws_kms_key.data_encryption.key_id
}

S3 buckets, RDS instances, EBS volumes, DynamoDB tables, SQS queues, SNS topics — every service that stores data references this KMS key. Service Control Policies (SCPs) at the organization level prevent creating unencrypted resources: 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedS3",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyUnencryptedEBS",
      "Effect": "Deny",
      "Action": "ec2:CreateVolume",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "ec2:Encrypted": "false"
        }
      }
    }
  ]
}

These SCPs make unencrypted resources impossible to create — not just against policy, but architecturally impossible. An engineer who forgets to specify encryption gets an access denied error, not a compliance finding discovered weeks later.

Encryption in Transit

All network communication uses TLS 1.2 or higher. Application Load Balancers terminate TLS with ACM-managed certificates. Internal service-to-service communication uses mutual TLS (mTLS) through service mesh or certificate-based authentication.

VPC endpoints keep AWS API traffic within the AWS network, preventing data from traversing the public internet even for S3 or DynamoDB API calls.

Audit Logging Infrastructure

FedRAMP's audit controls (AU family) require comprehensive, tamper-evident logging of all system events. We build a centralized logging infrastructure that satisfies AU-2 through AU-12:

CloudTrail Configuration

CloudTrail captures every API call across all accounts in the organization: 

resource "aws_cloudtrail" "organization_trail" {
  name                          = "fedramp-org-trail"
  s3_bucket_name                = aws_s3_bucket.audit_logs.id
  include_global_service_events = true
  is_multi_region_trail         = true
  is_organization_trail         = true
  enable_log_file_validation    = true
  kms_key_id                    = aws_kms_key.audit_encryption.arn

  cloud_watch_logs_group_arn    = "${aws_cloudwatch_log_group.cloudtrail.arn}:*"
  cloud_watch_logs_role_arn     = aws_iam_role.cloudtrail_cloudwatch.arn

  event_selector {
    read_write_type           = "All"
    include_management_events = true

    data_resource {
      type   = "AWS::S3::Object"
      values = ["arn:aws:s3"]
    }

    data_resource {
      type   = "AWS::Lambda::Function"
      values = ["arn:aws:lambda"]
    }
  }

  tags = {
    FedRAMP_Control = "AU-2,AU-3,AU-6,AU-8,AU-9,AU-12"
  }
}

Key configurations for FedRAMP:

  • enable_log_file_validation — Creates digest files that allow verification that log files haven't been modified or deleted (AU-9)
  • is_organization_trail — Captures events from all accounts in the organization (AU-12)
  • kms_key_id — Encrypts log files at rest (SC-28)
  • Data event logging — Captures object-level S3 operations and Lambda invocations, not just management events

Log Retention and Protection

Audit logs must be retained for the period specified in the System Security Plan (typically 1-3 years for FedRAMP Moderate). S3 Object Lock prevents deletion: 

resource "aws_s3_bucket" "audit_logs" {
  bucket = "fedramp-audit-logs-${var.account_id}"

  object_lock_configuration {
    object_lock_enabled = "Enabled"
  }
}

resource "aws_s3_bucket_object_lock_configuration" "audit_logs" {
  bucket = aws_s3_bucket.audit_logs.id

  rule {
    default_retention {
      mode = "COMPLIANCE"
      years = 3
    }
  }
}

COMPLIANCE mode Object Lock is immutable — not even the root account can delete logs before the retention period expires. This satisfies AU-9 (Protection of Audit Information) definitively.

Vulnerability Scanning

FedRAMP requires regular vulnerability scanning (RA-5) with specific remediation timelines: 30 days for high vulnerabilities, 90 days for moderate. We automate scanning with Amazon Inspector and integrate findings into the deployment pipeline:

  • Infrastructure scanning — Inspector evaluates EC2 instances, Lambda functions, and container images against CVE databases
  • Application scanning — DAST and SAST tools run as pipeline stages
  • Configuration scanning — Config rules detect misconfigurations continuously
  • Container scanning — Image vulnerability scanning is embedded in CI/CD

Findings that exceed remediation SLAs trigger deployment blocks. A high-severity vulnerability older than 30 days prevents new deployments to the affected system until remediated. This isn't punitive — it's architectural enforcement of the Plan of Action and Milestones (POA&M) process.

Our Approach

We don't help organizations get FedRAMP authorized — we build systems that are FedRAMP ready. The distinction matters. Authorization is a point-in-time assessment. Readiness is an ongoing architectural property.

Every design decision — from account structure to encryption defaults to logging configuration — is made with FedRAMP controls in mind. Not because we're checking boxes, but because these controls represent genuine security best practices. A system that satisfies FedRAMP Moderate is a well-architected system, period.

This aligns with Earn the Next Contract — the best way to demonstrate capability isn't documentation or presentations. It's building systems that pass assessment on the first try.

What is the difference between FedRAMP authorization and FedRAMP readiness?

FedRAMP authorization is the formal approval from the Joint Authorization Board (JAB) or an agency Authorizing Official (AO) to operate a cloud system for federal use. FedRAMP readiness means the system's architecture already implements the required controls — so when the assessment happens, the system passes. We focus on readiness because it's an architectural property, not a point-in-time event.

How many controls does FedRAMP Moderate require?

FedRAMP Moderate baseline includes 325 controls from NIST 800-53 Rev 5. However, many of these are satisfied by the cloud service provider (AWS, in most cases) through inherited controls. The customer-responsible controls — the ones you must implement — typically number between 150-200, depending on your architecture and use of managed services.

Can FedRAMP controls be automated?

A significant portion of FedRAMP controls can be automated through infrastructure-as-code, AWS Config rules, Security Hub standards, and CI/CD pipeline enforcement. We estimate that 60-70% of customer-responsible technical controls can be continuously monitored and enforced through automation. The remaining controls are procedural or organizational and require documented processes.

How long does FedRAMP authorization typically take?

The timeline varies significantly based on system complexity and organizational readiness. A well-architected system with controls baked in from the start can achieve authorization in 6-12 months. A system that requires significant remediation often takes 18-24 months. The biggest variable is the authorization boundary — a tightly scoped boundary with managed services reduces both the control count and the assessment timeline.

What AWS region should FedRAMP systems use?

FedRAMP Moderate workloads can run in standard AWS commercial regions. FedRAMP High workloads require AWS GovCloud (US) regions. We recommend GovCloud for all new federal workloads regardless of impact level — it eliminates the re-architecture cost if the system's impact level increases, and GovCloud services are designed specifically for regulated workloads.

Discuss your project with Rutagon

Contact Us →

Ready to discuss your project?

We deliver production-grade software for government, defense, and commercial clients. Let's talk about what you need.

Initiate Contact