How to Create SOC 2 Architecture Diagrams

If you're preparing for a SOC 2 audit, one of the first things your auditor will request is an architecture diagram. This isn't a formality. Architecture diagrams are how auditors understand the boundaries of your system, trace how data flows through your infrastructure, and verify that the security controls you describe in your policies actually exist in practice. A missing or inaccurate diagram doesn't just slow down the audit — it raises questions about whether you truly understand your own environment.

For companies running on AWS, the challenge is particularly acute. Cloud environments are dynamic. Resources get created, modified, and removed constantly. The diagram you drew six months ago may bear little resemblance to what's actually running today. This guide walks through what auditors expect, the components your diagram must include, and practical approaches to keeping your architecture documentation accurate and audit-ready.

What Auditors Look For in Architecture Diagrams

SOC 2 audits are organized around Trust Services Criteria (TSC), and architecture diagrams are relevant to several of them. Two criteria come up most frequently during diagram reviews.

CC6.1 (Logical and Physical Access Controls) requires that you demonstrate how your system restricts access to authorized users and services. Your architecture diagram needs to show network boundaries — which resources sit in public subnets versus private subnets, where firewalls and security groups enforce access rules, and how administrative access is controlled. Auditors want to see that your database isn't publicly accessible, that your application tier is isolated behind a load balancer, and that there are clear boundaries between different trust zones.

CC7.1 (System Monitoring) addresses how you detect and respond to anomalies. While monitoring is primarily demonstrated through log configurations and alerting policies, the architecture diagram provides context. Auditors need to understand where logging occurs in the data flow, which services produce audit trails, and how monitoring data is aggregated. If you claim you monitor all API access, the diagram should show where that monitoring sits in relation to the rest of your system.

Beyond specific criteria, auditors use architecture diagrams to verify data flow integrity. They trace a request from the end user through your system — hitting the CDN, passing through the load balancer, reaching the application, querying the database, and returning a response. At each hop, they check: is the connection encrypted? Is the service authenticated? Are there controls preventing lateral movement if one component is compromised?

An architecture diagram that only shows boxes with service names isn't sufficient. Auditors need to see security boundaries, encryption indicators, data flow direction, and access control points. The diagram is evidence, not decoration.

Key Components of a SOC 2 Architecture Diagram

A compliant architecture diagram needs to cover several layers of your infrastructure. Here are the components that auditors consistently expect to see.

Network Boundaries and Segmentation

Start with your VPC structure. Show each VPC, its CIDR range, and how it's segmented into subnets. Public subnets (those with internet gateway routes) should be visually distinct from private subnets. If you use multiple availability zones — which you should for production workloads — show that redundancy. Auditors want to confirm that your database and application tiers aren't exposed to the public internet.

Compute and Application Services

Document every compute resource that handles customer data: EC2 instances, ECS clusters, Lambda functions, EKS nodes. Include the load balancers that front them — ALBs, NLBs, or API Gateways — and show which listeners and target groups route traffic. Auditors care about how traffic enters your system and which services can communicate with each other.

Data Stores and Encryption

Every data store must be represented: RDS instances, DynamoDB tables, S3 buckets, ElastiCache clusters, Elasticsearch domains. For each, indicate whether encryption at rest is enabled and which KMS key manages it. Draw the connections between application services and data stores, and label whether those connections use TLS. If you use S3 for backups or log storage, show that too — auditors will ask about backup encryption.

IAM and Access Boundaries

Show how IAM roles and policies control which services can access which resources. If your Lambda functions assume specific roles to access DynamoDB, represent that relationship. If you use AWS Organizations with Service Control Policies, indicate those boundaries. Cross-account access patterns — such as a deployment pipeline in one account accessing production resources in another — should be clearly documented.

External Integrations and Data Flows

Any third-party service that sends or receives customer data needs to appear on the diagram. Payment processors, email providers, analytics services, identity providers — if data leaves your AWS environment to reach them, the diagram should show that path and how it's secured. Auditors use these external connections to assess your vendor risk surface.

Monitoring and Logging

Include your logging and monitoring infrastructure: CloudWatch, CloudTrail, GuardDuty, VPC Flow Logs, and any SIEM integrations. Show where logs are stored, how long they're retained, and whether they're encrypted. This ties directly back to CC7.1 and demonstrates that you have visibility into system activity.

The Manual Approach (And Why It Fails)

Most teams start with the same approach: someone opens Visio, Draw.io, or Lucidchart and begins manually placing AWS icons on a canvas. They reference the AWS console, check Terraform state files, ask colleagues about services they don't recognize, and after several days — sometimes weeks — produce a diagram that represents the infrastructure as it existed when they started.

This approach has fundamental problems that go beyond the initial time investment.

Diagrams Go Stale Immediately

The moment a developer deploys a new service, adds a database, or modifies a security group, the diagram is out of date. In a typical engineering team shipping changes daily, a manually-created diagram has a useful lifespan measured in days, not months. By the time your auditor reviews it, the diagram may describe an infrastructure that no longer exists.

Incomplete Discovery

Manual diagram creation depends on the author knowing about every resource in the account. In practice, teams accumulate forgotten resources — test databases that were never decommissioned, Lambda functions created for a one-time migration, S3 buckets from deprecated features. These orphaned resources are invisible on a manually-created diagram but fully visible to an auditor who requests a resource inventory. The discrepancy between your diagram and your actual environment is a finding waiting to happen.

Human Error and Inconsistency

Even diligent engineers make mistakes when translating infrastructure into a visual format. Security groups get simplified. Subnet associations get wrong. Encryption indicators get omitted because the author assumed they were obvious. When multiple people maintain the same diagram over time, inconsistencies compound. Different naming conventions, different levels of detail, different assumptions about what's important — the result is a diagram that's difficult to trust.

The Time Cost Is Significant

For a moderately complex AWS environment — say, 3 VPCs, 20 services, a few RDS instances, and some cross-account access — creating a thorough architecture diagram from scratch takes 40 to 80 hours of engineering time. That's one to two full weeks of a senior engineer's time, someone whose knowledge of the system makes them uniquely qualified for the task and uniquely expensive to pull off other work.

Automating Architecture Diagrams with Fegura

The core problem with manual diagrams is that they're a point-in-time snapshot created by a human interpreting a complex system. Automation solves this by reading the infrastructure directly and generating the diagram from the source of truth — your actual AWS environment.

Fegura connects to your AWS account through a read-only IAM role and discovers every resource across all regions. It maps the relationships between services — which EC2 instances sit behind which load balancer, which Lambda functions access which DynamoDB tables, which security groups allow traffic between which subnets — and generates an architecture diagram that reflects your live infrastructure.

How It Works

• Connect your AWS account. Deploy a read-only CloudFormation stack that creates an IAM role with the minimum permissions needed for resource discovery. No agents, no credentials stored — Fegura assumes the role on-demand.
• Automatic resource discovery. Fegura scans your account across all enabled regions, inventorying VPCs, subnets, compute resources, data stores, security groups, IAM roles, and their relationships. The scan covers services that auditors specifically look for: encryption configurations, public accessibility, logging status.
• Diagram generation. Resources are laid out in a structured diagram that groups services by VPC and subnet, shows data flow between components, marks encryption at rest and in transit, and highlights security boundaries. The output is designed to answer the questions auditors actually ask.
• Export and share. Diagrams can be exported as PDF or PNG for inclusion in audit evidence packages. Because the diagram is generated from live infrastructure, you can regenerate it at any time to get a current view — no manual updates required.

The key advantage is currency. When your auditor asks for an architecture diagram, you generate one that reflects the infrastructure as it exists right now, not as it existed when someone last had time to update a Visio file.

Best Practices

Whether you generate diagrams manually or automatically, these practices will help ensure your architecture documentation meets audit expectations.

Regenerate Before Every Audit Period

SOC 2 Type II audits cover a specific observation period, typically 6 to 12 months. At minimum, regenerate your architecture diagram at the start and end of each audit period. If your infrastructure changes frequently, monthly regeneration is better. Having a history of diagrams also helps auditors understand how your system has evolved and whether changes were controlled.

Cover All Regions and Accounts

It's common for teams to forget about resources in non-primary regions — a test environment in us-west-2, a disaster recovery setup in eu-west-1, or an S3 bucket replicated to ap-southeast-1. Your diagram must account for all regions where resources exist. Similarly, if you use multiple AWS accounts (and you should, for environment isolation), each account needs to be represented, along with any cross-account access patterns.

Label Security Controls Explicitly

Don't make auditors guess. If a connection uses TLS 1.2, label it. If a database uses AES-256 encryption at rest with a customer-managed KMS key, say so. If a security group restricts inbound traffic to a specific CIDR range, show that restriction. Explicit labels reduce back-and-forth with auditors and demonstrate that you've thought carefully about each control.

Version Your Diagrams

Treat architecture diagrams like code: version them, date them, and keep a history. When your auditor asks "what did the architecture look like in Q3?" you should be able to produce the diagram from that period. Versioning also creates an audit trail for infrastructure changes, which auditors view favorably as evidence of a mature change management process.

Include a Legend and Metadata

Every diagram should include a legend explaining the visual conventions used — what different line styles mean, how security boundaries are indicated, what color coding represents. Add metadata: the date generated, the AWS account ID, the regions covered, and who is responsible for maintaining the diagram. This context helps auditors quickly orient themselves and reduces questions during the review.

Closing Thoughts

SOC 2 architecture diagrams serve a straightforward purpose: they give auditors a verifiable map of your infrastructure so they can confirm that your security controls match your policies. The challenge has never been understanding what to include — it's keeping the diagram accurate as your infrastructure evolves.

For teams running on AWS, the most reliable approach is to generate diagrams directly from your live environment rather than maintaining them by hand. This eliminates the drift between documentation and reality that causes audit findings, and it frees your engineers to focus on building rather than drawing.

If you're preparing for a SOC 2 audit and want to see what an auto-generated architecture diagram looks like for your AWS environment, you can connect your account to Fegura and generate your first diagram in a few minutes. The read-only IAM role takes about two minutes to deploy, and you'll have a complete, audit-ready diagram before the CloudFormation stack finishes creating.