AWS Architecture Guide

How to Create an AWS Data Platform Diagram

A well-designed architecture diagram is the difference between a data platform that scales smoothly and one that becomes a maintenance nightmare. This guide shows you how to design and document AWS data platforms that teams can actually understand and operate.

18 min readFor Data Engineers & ArchitectsAWS-specific examples

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

94/20003 credits left
Try:

No account needed · Editable canvas, not a picture

1. Why AWS Data Platform Diagrams Matter

Your AWS data platform is invisible. Services run in the cloud, data flows through APIs, and failures happen silently. A good architecture diagram is the map that makes the invisible visible—showing how data moves, where it's stored, and who can access it.

The Cost of Poor Documentation

Without clear diagrams, teams spend 40% of their time hunting through CloudFormation stacks, checking S3 bucket policies, and trying to figure out which Glue job writes to which table. That's 16 hours per week of a senior engineer's time wasted on archeology.

A good AWS diagram delivers three outcomes:

Faster Debugging

When data is missing, the diagram shows exactly which S3 bucket, Glue job, and Redshift table to check. No more guessing.

Onboarding

New engineers understand the entire platform in 30 minutes instead of 3 months. Show them the diagram, not CloudFormation YAML.

Security Review

Auditors and security teams can see IAM boundaries, encryption zones, and network isolation at a glance.

From experience

I've joined teams where the only documentation was "check the console." It took weeks to understand what was running. The teams with clear diagrams? I was productive on day one. Documentation isn't overhead—it's velocity.

2. Core AWS Data Services

AWS has 200+ services, but modern data platforms are built on a core set of 10-15. Here's what each service does and when to use it in your diagram.

Amazon S3

Storage

Object storage for your data lake. Stores raw, processed, and curated data at scale.

Use when: Storing any data at scale. Organize with prefixes: s3://bucket/raw/, s3://bucket/processed/, s3://bucket/curated/

AWS Glue

ETL + Catalog

Serverless ETL for transforming data. Glue Data Catalog provides metadata for tables.

Use when: Building ETL pipelines that don't require real-time processing. Glue crawlers auto-discover schemas in S3.

Amazon Athena

Query

Serverless SQL queries on S3 data. Pay per query, no cluster management.

Use when: Ad-hoc analysis, data exploration, cost-sensitive workloads. Works with Glue Data Catalog.

Amazon Redshift

Warehouse

Columnar data warehouse for BI and analytics. Optimized for complex queries and dashboards.

Use when: High-performance dashboards, predictable workloads, complex multi-table joins.

Amazon Kinesis

Streaming

Real-time data streaming. Kinesis Data Streams for custom apps, Firehose for direct S3/Redshift delivery.

Use when: Real-time ingestion from clickstreams, IoT, logs. Use Firehose for simple S3 delivery.

AWS Lambda

Compute

Serverless functions triggered by events (S3 uploads, Kinesis streams, schedules).

Use when: Lightweight transformations, file processing, API calls. Cheaper than Glue for small workloads.

ServiceCategoryPricing ModelWhen to Use
S3StoragePer GB storedAlways (data lake foundation)
GlueETLPer DPU-hourBatch transformations >5 min
LambdaComputePer invocationEvent-driven, <15 min tasks
AthenaQueryPer TB scannedAd-hoc queries, exploration
RedshiftWarehousePer node-hourHigh-perf BI dashboards
KinesisStreamingPer shard-hourReal-time ingestion

3. Common AWS Data Architecture Patterns

Don't start from scratch. These proven patterns solve 90% of use cases. Pick one, customize it for your needs, then diagram it.

Pattern 1: Medallion Data Lake

The most common pattern. Data progresses through three quality zones: Bronze (raw), Silver (cleaned), Gold (aggregated).

Architecture flow:

Bronze: S3 raw bucket → Glue crawler → Athena queries
Silver: Glue ETL jobs → S3 processed bucket → Partitioned Parquet
Gold: Aggregations → Redshift Spectrum or Athena → BI dashboards

Best for: Teams wanting clear data quality boundaries and flexible consumption (both Athena and Redshift can read Gold layer).

Pattern 2: Streaming + Batch Hybrid

Real-time ingestion with batch processing. Combines the speed of streaming with the reliability of batch.

Architecture flow:

Streaming: Kinesis Data Streams → Lambda/Kinesis Analytics → S3
Batch: Scheduled Glue jobs → Transform and aggregate → Redshift
Serving: Redshift for dashboards + Athena for exploration

Best for: Real-time dashboards (streaming) + historical analysis (batch). Common in e-commerce and SaaS.

Pattern 3: Serverless Analytics

Pure serverless with no cluster management. Cost-effective for unpredictable or low-volume workloads.

Architecture flow:

Ingestion: API Gateway + Lambda → S3 raw bucket
Transform: S3 event → Lambda functions → Parquet in S3
Query: Athena + QuickSight (no Redshift cluster)

Best for: Startups, cost-conscious teams, or workloads with unpredictable query patterns.

Pro Tip

Start with Medallion, Add Complexity Later

The medallion pattern gives you clear zones for debugging and quality gates. You can always add real-time streams later. Teams that start with complex architectures often regret it when debugging gets hard.

4. Step-by-Step Design Process

Follow these steps to design a diagram that's both accurate and readable. Start simple, then add detail.

1

Map data sources and consumers

Start at the boundaries. What data comes in? Where does it go out? List: databases, APIs, files, SaaS tools. List: dashboards, ML models, operational apps.

Action: Draw boxes for sources (left) and consumers (right).

2

Define your storage layers

Decide on your S3 bucket structure. Most teams use: raw/, processed/, curated/ or bronze/, silver/, gold/.

Action: Add S3 buckets in the middle. Label them clearly with prefixes.

3

Add ingestion paths

How does data get from sources to S3? Options: AWS Database Migration Service, Lambda, Glue, Kinesis Firehose, third-party tools (Airbyte, Fivetran).

Action: Draw arrows from sources to raw S3. Label with service names.

4

Map transformation flows

Show how raw data becomes clean data. Usually Glue jobs or Lambda functions. Include: job names, triggers (schedule/event), output format (Parquet/CSV).

Action: Draw Glue/Lambda boxes between S3 layers. Show progression.

5

Add serving layer

How do consumers query data? Athena for ad-hoc, Redshift for dashboards, Redshift Spectrum for hybrid. Show which tables/views are exposed.

Action: Add Athena/Redshift boxes. Draw arrows to consumers.

6

Include governance and security

Show IAM roles (who can access what), encryption (S3 SSE, Redshift), VPC boundaries, CloudTrail logging. This is critical for compliance.

Action: Add security annotations: KMS keys, IAM role names, VPC ID.

7

Add metadata and monitoring

Document: Glue Data Catalog tables, CloudWatch alarms, Step Functions workflows, data quality checks (Lambda or Glue).

Action: Annotate with catalog table names, alarm thresholds, SNS topics.

From experience

I always start by sketching on a whiteboard with the team. Get everyone to agree on the flow before you make it pretty in a tool. 30 minutes of whiteboarding saves hours of rework.

5. Diagram Best Practices

The difference between a useful diagram and shelf-ware is these details. Make diagrams that teams actually use.

Do This

  • Use real resource names: "s3://prod-raw-data" not "Raw Bucket"
  • Show data formats: Parquet, JSON, CSV, Avro
  • Include IAM role names for security review
  • Label partition keys: year/month/day, user_id, region
  • Add data volume estimates: 10 GB/day, 1M rows/hour
  • Show SLA/schedule: Hourly, Daily 3 AM UTC, Event-driven
  • Link to code repos: GitHub links for Glue jobs

Avoid This

  • • Generic labels like "Database" or "ETL Process"
  • • Showing every single table (group related tables)
  • • Missing arrows (which direction does data flow?)
  • • Outdated diagrams (sync with reality or delete)
  • • PDFs in Confluence that can't be edited
  • • Missing security zones (VPC, encryption, IAM)
  • • No contact/owner information

Layering Strategy for Complex Diagrams

🌐

Layer 1: High-Level

10,000 ft view showing: sources → data lake → serving → consumers. For executives and new hires.

🔧

Layer 2: Logical

Service-level detail: specific S3 buckets, Glue jobs, Redshift clusters. For data engineers.

⚙️

Layer 3: Physical

Resource IDs, IAM ARNs, VPC details, CloudWatch alarm names. For debugging and operations.

Pro Tip

Keep One Source of Truth

Store diagrams where your code lives (GitHub, GitLab) or use a tool with version history (Lucidchart, Miro). Never store diagrams as static PDFs in Confluence—they get out of sync immediately.

6. Tools for AWS Diagrams

ToolBest ForAWS IconsCollaborationPricing
DatadefAI-generated diagrams✅ Full libraryReal-timeFree tier + Pro
LucidchartProfessional diagrams✅ Official iconsGood$8-30/mo
draw.ioFree and flexible✅ Import libraryBasicFree
MiroBrainstorming⚠️ Manual importExcellentFree tier + paid
CloudCraftAWS-specific 3D✅ NativeBasicFree tier + Pro
Terraform GraphIaC auto-generated✅ From codeGit-basedFree

Manual Diagramming

You design the diagram from scratch using drag-and-drop tools.

Best for: Custom diagrams, presentations, precise control over layout and styling.

AI-Generated

Describe your architecture in text, AI generates the diagram.

Best for: Quick drafts, onboarding docs, iterating fast on architecture options.

7. AWS Diagram Design Checklist

Clear data flow direction

Arrows show left-to-right or top-to-bottom flow. No circular dependencies unless intentional (feedback loops).

Real resource names

Use actual S3 bucket names, Glue job names, Redshift cluster IDs. Makes the diagram operational, not just conceptual.

Security boundaries marked

Show VPC boundaries, IAM roles, encryption (KMS keys), and network isolation. Critical for audits.

Data formats specified

Label file formats (Parquet, JSON, CSV), compression (Snappy, Gzip), and partitioning schemes.

Processing schedules noted

Indicate: event-driven, hourly, daily 3 AM UTC. Helps with debugging &quot;why is data late?&quot;

Volume and scale estimates

Add data volume (GB/day, rows/sec) and query concurrency. Helps with capacity planning.

Monitoring and alerting

Show CloudWatch alarms, SNS topics, and what triggers alerts (job failures, data quality, latency).

Version and owner

Date the diagram, add contact info, link to runbook. Prevents &quot;is this still accurate?&quot; confusion.

Pro Tip

Test Your Diagram with New Hires

If a new engineer can't understand your data flow from the diagram in 15 minutes, it's too complex or too vague. Simplify or add layers. The best diagrams are self-explanatory.

8. Frequently Asked Questions

What are the core AWS services for a data platform?

The core services are: S3 (data lake storage), AWS Glue (ETL and data catalog), Athena (serverless SQL queries), Redshift (data warehouse), Kinesis (streaming data), Lambda (serverless compute), and Step Functions (workflow orchestration).

What is the medallion architecture in AWS?

The medallion architecture organizes data into three layers in S3: Bronze (raw ingested data), Silver (cleaned and conformed data), and Gold (aggregated business-level data). This pattern provides clear data quality progression and separates concerns across the pipeline.

Should I use Redshift or Athena for analytics?

Use Athena for ad-hoc queries, exploration, and cost-sensitive workloads (pay per query). Use Redshift for high-performance dashboards, complex joins, and predictable high-volume workloads. Many teams use both: Athena for data scientists, Redshift for production BI.

How do I document data flow in AWS?

Document data flow by showing: source systems → ingestion layer (Kinesis/Lambda/Glue) → storage (S3 buckets by zone) → transformation (Glue/EMR) → serving layer (Redshift/Athena) → consumers (dashboards/ML). Include S3 bucket names, IAM roles, and Glue job names for operability.

How often should I update my AWS architecture diagram?

Update diagrams when you: add new data sources, change storage structure, modify ETL logic, or add security controls. Treat diagrams as living documentation—review quarterly and update immediately after major changes. Outdated diagrams are worse than no diagrams.

Should I include cost estimates in my diagram?

Yes, especially for budget reviews. Annotate: S3 storage costs, Glue DPU-hours, Redshift node-hours, Athena scan costs. This helps stakeholders understand where money is being spent and justify optimization work.

Generate Your AWS Data Platform Diagram

Describe your AWS architecture in plain English and get a professional diagram in seconds. No manual drawing required.