Advanced Architecture Patterns

Building enterprise-grade data platforms on AWS requires understanding sophisticated architectural patterns that go beyond single-account, single-region deployments. Advanced architecture encompasses multi-account governance, global distribution, decentralized data ownership, and platform engineering principles that enable organizations to scale their data operations while maintaining security, compliance, and operational excellence.

Why Advanced Architecture Matters

As organizations mature in their data journey, they encounter limitations with monolithic architectures:

• Security isolation: Production workloads need separation from development and testing
• Cost allocation: Different business units require separate billing and chargeback
• Compliance requirements: Regulated industries need strict access controls and audit trails
• Operational complexity: Global teams need autonomy while maintaining governance
• Scalability limits: Single-account resource limits become bottlenecks
• Failure isolation: Preventing cascading failures across environments

Core Architectural Principles

1. Defense in Depth Layer multiple security controls across accounts, regions, and services. No single point of failure in security posture.

2. Least Privilege Access Grant minimum necessary permissions through SCPs, IAM policies, and resource-based policies at every layer.

3. Infrastructure as Code All resources deployed through templates (CloudFormation, CDK, Terraform) ensuring reproducibility and auditability.

4. Automated Governance Policy enforcement through Service Control Policies, Config Rules, and automated remediation rather than manual processes.

5. Domain-Driven Design Organize teams and resources around business domains, enabling autonomous ownership with federated governance.

Multi-Account Strategy Components

1. Account Structure Patterns

Workload-Based Separation:

• Management Account: Billing, IAM, and organization controls only
• Security Account: Centralized security tooling and alerting
• Log Archive Account: Immutable storage for compliance and auditing
• Sandbox Account: experimentation and learning without risk
• Prod Accounts: Isolated production workloads per business domain

Environment-Based Separation:

• Development accounts per team or application
• Staging accounts for pre-production testing
• Production accounts with strict change controls

2. Service Control Policies (SCPs)

SCPs act as guardrails applied at the organizational unit (OU) or account level:

// Prevent leaving organization
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "??????",
      "Effect": "Deny",
      "Action": [
        "organizations:LeaveOrganization"
      ],
      "Resource": "*"
    }
  ]
}

// Restrict regions
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "????",
      "Effect": "Deny",
      "NotAction": [
        "organizations:*",
        "account:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

3. Cross-Account Access Patterns

AWS RAM (Resource Access Manager): Share VPCs, Transit Gateways, Route53 Resolver Rules, and other resources across accounts without peer-to-peer connections.

Cross-Account IAM Roles: Establish trust relationships between accounts with temporary credentials and session policies limiting permissions.

AWS SSO / IAM Identity Center: Centralized identity management with attribute-based access control (ABAC) mapping users to accounts and permissions.

Multi-Region Architecture

Multi-region architectures enable organizations to serve global users with low latency, meet data residency requirements, and achieve disaster recovery objectives. For data engineering, this presents unique challenges around data replication, consistency models, and cost optimization.

Key Considerations

Data Residency Requirements:

• GDPR mandates data storage within EU boundaries for EU citizens
• China requires data localization through AWS China regions
• Financial regulations often specify data processing locations
• Healthcare regulations (HIPAA) may restrict cross-border data transfer

Performance Requirements:

• Sub-100ms latency for real-time applications
• Read replicas in distant regions for analytics workloads
• Edge processing for IoT data collection
• Regional data processing for compliance

Disaster Recovery Objectives:

• RPO (Recovery Point Objective): Maximum acceptable data loss
• RTO (Recovery Time Objective): Maximum acceptable downtime
• Active-active vs. active-passive configurations
• Pilot light and warm standby patterns

Multi-Region Data Replication Strategies

1. S3 Cross-Region Replication (CRR)

Automatic, asynchronous replication of objects between S3 buckets in different regions:

# S3 Replication Configuration
{
  "Rules": [
    {
      "Status": "Enabled",
      "Prefix": "",
      "Destination": {
        "Bucket": "arn:aws:s3:::backup-us-west-2",
        "StorageClass": "STANDARD_IA"
      },
      "ReplicationTime": {
        "Status": "Enabled",
        "Time": {
          "Minutes": 15
        }
      },
      "Metrics": {
        "Status": "Enabled",
        "EventThreshold": {
          "Minutes": 15
        }
      }
    }
  ]
}

2. Aurora Global Database

Low-latency global reads with 1-second or less replication lag:

• Primary cluster in one region
• Up to 15 read-only secondary clusters globally
• Automatic replication using physical storage-level replication
• Cross-region managed failover in under 1 minute

3. DynamoDB Global Tables

Fully managed, multi-region, multi-active database:

• Replication latency typically under 1 second
• Conflict resolution with last-writer-wins
• Automatic handling of deletes across regions
• Point-in-time recovery within each region

4. Amazon MSK Replicator

Mirror topics across MSK clusters in different regions:

• Topic-level configuration for selective replication
• Consumer group offset tracking per region
• Exactly-once semantics within a cluster
• Built-in monitoring and alerting

Multi-Region Patterns for Data Engineering

Pattern 1: Regional Data Collection

IoT Devices ? Regional Kinesis ? Regional Lambda ? Regional S3 ? Cross-Region Replication ? Central Lake

Pattern 2: Global Analytics with Local Processing

Regional ETL ? Regional Data Warehouse ? Federated Query via Athena ? Global Dashboard

Pattern 3: Disaster Recovery with Pilot Light

Primary: Full data platform
Secondary: Minimal infrastructure (S3 + Lambda) ? On failover: Scale up Redshift, EMR

Pattern 4: Data Residency Compliance

EU Data ? EU Region Only (never leaves EU)
US Data ? US Region Only
APAC Data ? APAC Region Only
Global aggregates ? Anonymized cross-region analytics

Data Mesh Architecture

Data mesh is an architectural paradigm that decentralizes data ownership to domain teams, treating data as a product rather than a centralized IT asset. This approach aligns with organizational structures and enables scale without creating bottlenecks in a central data team.

Four Core Principles

1. Domain Ownership Each business domain (e.g., Marketing, Finance, Operations) owns and manages their data end-to-end. They are responsible for:

• Data quality and freshness
• Schema management and evolution
• Access control and compliance
• Documentation and discoverability

2. Data as a Product Treat data assets with the same rigor as customer-facing products:

• Clear SLAs for availability and freshness
• Versioning and changelogs
• Self-describing metadata
• Consumer feedback mechanisms

3. Self-Serve Data Platform A centralized platform team provides infrastructure and tooling that enables domain teams to:

• Publish and discover data products
• Apply governance policies automatically
• Monitor quality and usage metrics
• Integrate with analytics tools

4. Federated Computational Governance Global policies applied automatically through the platform:

• Schema standards and validation
• Security and access policies
• Data classification and tagging
• Compliance and audit requirements

Implementing Data Mesh on AWS

Domain Data Products Architecture

Each domain team creates data products using a standardized pattern:

# Domain Team Structure
+-- data-products/
�   +-- campaigns/
�   �   +-- schema.yaml          # Schema definition
�   �   +-- quality-rules.yaml   # Data quality checks
�   �   +-- sla.yaml             # Availability & freshness SLAs
�   �   +-- glue-jobs/           # ETL code
�   �   +-- tests/               # Data validation tests
�   +-- leads/
�   +-- attribution/
+-- infrastructure/
�   +-- s3-buckets.tf            # Domain S3 buckets
�   +-- glue-crawlers.tf         # Crawlers for discovery
�   +-- iam-policies.tf          # Access controls
+-- documentation/
    +-- README.md                # Domain overview
    +-- data-products.md         # Available products

Data Product Contract

# schema.yaml
apiVersion: datamesh/v1
kind: DataProduct
metadata:
  name: campaigns
  domain: marketing
  owner: marketing-data-team@company.com
  version: "2.1.0"
spec:
  description: "Marketing campaign performance metrics"
  freshness:
    sla: "1 hour"
    maxLatency: "15 minutes"
  quality:
    completeness: 0.99
    accuracy: 0.98
    uniqueness: 1.0
  schema:
    type: parquet
    location: "s3://marketing-data-lake/campaigns/"
    partitioning:
      - column: year
      - column: month
      - column: day
    columns:
      - name: campaign_id
        type: string
        description: "Unique campaign identifier"
        nullable: false
      - name: impressions
        type: bigint
        description: "Number of impressions"
        nullable: false
      - name: clicks
        type: bigint
        description: "Number of clicks"
        nullable: false
      - name: conversions
        type: integer
        description: "Number of conversions"
        nullable: true
      - name: spend
        type: decimal(10,2)
        description: "Total spend in USD"
        nullable: false

Platform Team Responsibilities

The platform team provides self-service tooling:

Data Discovery Portal:

• Search across all domains and data products
• View schema documentation and lineage
• Request access to data products
• Monitor SLA compliance

Quality Framework:

• Automated validation during ETL
• Quality score dashboards
• Alerting on SLA violations
• Root cause analysis tools

Governance Automation:

• Schema validation in CI/CD
• Automatic data classification
• Access request workflows
• Compliance reporting

Platform Engineering

Platform engineering extends data mesh principles by providing a comprehensive internal developer platform (IDP) that abstracts infrastructure complexity and enables data teams to focus on business logic rather than operational concerns.

Platform Engineering vs. Data Mesh

Core Platform Components

1. Golden Paths Pre-approved patterns and templates that teams can adopt:

• Standard project structure
• CI/CD pipeline templates
• Infrastructure modules
• Testing frameworks

2. Developer Portal Internal portal providing:

• Service catalog of available tools
• Documentation and tutorials
• Request management
• Cost visibility

3. Automation Engine Self-service automation for:

• Environment provisioning
• Data pipeline creation
• Access management
• Incident response

4. Observability Stack Unified monitoring across:

• Infrastructure metrics
• Application logs
• Data quality metrics
• Cost and usage

Building a Data Platform on AWS

Infrastructure as Code with CDK

from aws_cdk import (
    Stack,
    aws_s3 as s3,
    aws_glue as glue,
    aws_iam as iam,
    aws_kms as kms,
)
from constructs import Construct

class DataLakeStack(Stack):
    def __init__(self, scope: Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        
        # KMS Key for encryption
        data_key = kms.Key(self, "DataLakeKey",
            alias="data-lake-key",
            enable_key_rotation=True
        )
        
        # Raw data bucket
        raw_bucket = s3.Bucket(self, "RawDataBucket",
            bucket_name="company-raw-data",
            encryption=s3.BucketEncryption.KMS,
            encryption_key=data_key,
            versioned=True,
            lifecycle_rules=[
                s3.LifecycleRule(
                    transitions=[
                        s3.Transition(
                            storage_class=s3.StorageClass.INFREQUENT_ACCESS,
                            transition_after=Duration.days(30)
                        ),
                        s3.Transition(
                            storage_class=s3.StorageClass.GLACIER,
                            transition_after=Duration.days(90)
                        )
                    ]
                )
            ]
        )
        
        # Processed data bucket
        processed_bucket = s3.Bucket(self, "ProcessedDataBucket",
            bucket_name="company-processed-data",
            encryption=s3.BucketEncryption.KMS,
            encryption_key=data_key
        )
        
        # Glue crawler for raw data
        raw_crawler = glue.CfnCrawler(self, "RawDataCrawler",
            name="raw-data-crawler",
            role=data_role.role_arn,
            database_name="raw_db",
            targets=glue.CfnCrawler.CrawlerTargetsProperty(
                s3_targets=[
                    glCfnCrawler.S3TargetProperty(
                        path=f"s3://{raw_bucket.bucket_name}/"
                    )
                ]
            ),
            schema_change_policy=glue.CfnCrawler.SchemaChangePolicyProperty(
                update_behavior="UPDATE_IN_DATABASE",
                delete_behavior="LOG"
            )
        )
        
        # Glue ETL job
        etl_job = glue.CfnJob(self, "ETLJob",
            name="transform-raw-to-processed",
            role=data_role.role_arn,
            glue_version="3.0",
            worker_type="G.2X",
            number_of_workers=10,
            command=glue.CfnJob.JobCommandProperty(
                name="glueetl",
                python_version="3",
                script_location=f"s3://{scripts_bucket.bucket_name}/etl/transform.py"
            ),
            default_arguments={
                "--job-language": "python",
                "--TempDir": f"s3://{temp_bucket.bucket_name}/temp/",
                "--output_path": processed_bucket.bucket_name
            }
        )

Self-Service Pipeline Creation

# pipeline-request.yaml - Submitted by domain teams
apiVersion: dataplatform/v1
kind: DataPipeline
metadata:
  name: marketing-campaigns-pipeline
  domain: marketing
  team: acquisition-team
spec:
  source:
    type: kinesis
    stream: marketing-events-stream
    format: json
  transformation:
    type: glue
    script: s3://scripts/marketing/campaigns-transform.py
    schedule: "rate(1 hour)"
  destination:
    type: s3
    bucket: marketing-data-lake
    prefix: campaigns/
    format: parquet
    partitioning:
      - column: event_date
        type: date
  quality:
    rules:
      - column: campaign_id
        type: not_null
      - column: spend
        type: range
        min: 0
        max: 1000000
  monitoring:
    alerts:
      - type: freshness
        threshold: "2 hours"
      - type: quality_score
        threshold: 0.95

Platform Engineering Best Practices

1. Start with Developer Pain Points

• Survey teams about their biggest challenges
• Identify common patterns that could be templated
• Measure time-to-production for new pipelines
• Track operational burden on teams

2. Build Incrementally

• Start with one golden path (e.g., batch ETL)
• Gather feedback and iterate
• Expand to streaming, ML, analytics
• Avoid building everything at once

3. Invest in Documentation

• Clear onboarding guides for new teams
• Architecture Decision Records (ADRs)
• Runbooks for common operations
• API reference documentation

4. Measure Platform Success

• Developer satisfaction scores
• Time from idea to production
• Pipeline reliability metrics
• Cost per data product
• Onboarding time for new teams

5. Enable Don't Enforce

• Provide excellent defaults
• Allow teams to opt-in gradually
• Create feedback loops
• Celebrate adoption wins

Architecture Flow

Interview Q&A

Advanced Architecture Questions

Q: How would you design a multi-account AWS strategy for a large data engineering organization with 50+ teams?

A: I would implement a hub-and-spoke model with the following structure:

• Management Account: Billing and IAM Identity Center only, no workloads
• Security Account: GuardDuty, Security Hub, centralized CloudTrail
• Log Archive Account: Immutable S3 storage for all logs
• Shared Services Account: Shared VPCs, Transit Gateways via AWS RAM
• Data Lake Account: Central S3 data lake with Lake Formation
• Per-domain Accounts: Marketing, Finance, Operations each with their own accounts
• Sandbox Accounts: Development and experimentation per team

SCPs would prevent leaving the organization, restrict regions, and block certain high-risk services. Cross-account access would use IAM roles with session policies limiting permissions to minimum required.

Q: Explain the differences between active-active and active-passive multi-region architectures for data workloads.

A: Active-Active:

• Both regions serve read and write traffic simultaneously
• Uses conflict resolution (last-writer-wins or application-level merging)
• Provides automatic failover with no manual intervention
• Higher complexity and cost (double infrastructure)
• Use cases: Global applications requiring low latency, high availability requirements

Active-Passive:

• Primary region handles all traffic, secondary is standby
• Data replicates asynchronously to secondary
• Failover requires manual or automated switching
• Lower cost, simpler to implement
• Use cases: Disaster recovery, data residency compliance

For data engineering specifically, active-active works well with DynamoDB Global Tables and Aurora Global Databases. For batch workloads, active-passive with S3 CRR and scheduled pipeline runs in secondary region is often sufficient.

Q: How would you implement a data mesh on AWS for an organization with 10 business domains?

A: I would structure the implementation as follows:

1. Platform Team: 5-8 engineers providing self-service tooling

   • Backstage portal for data product discovery
   • CDK/CloudFormation templates for standard infrastructure
   • Automated quality validation framework
   • Access management workflows

2. Domain Teams: Each domain has a data product owner and 2-3 engineers

   • Own their data products end-to-end
   • Create schema contracts and SLAs
   • Implement data quality checks
   • Publish to platform catalog

3. Infrastructure:

   • Central Lake Formation for governance
   • Per-domain S3 buckets with lifecycle policies
   • AWS Glue for ETL with standardized job templates
   • Athena for federated querying across domains
   • QuickSight for BI with domain-level workspaces

4. Governance:

   • Federated model with automated policy enforcement
   • Schema registry with validation in CI/CD
   • Data classification tags applied automatically
   • Quality scores tracked and surfaced in portal

Q: Describe how you would handle schema evolution in a data mesh without breaking downstream consumers.

A: I would implement a multi-layered approach:

1. Schema Registry: Central registry (AWS Glue Schema Registry or custom) tracking all schemas with versioning

2. Backward Compatibility Rules:

   • New fields must have defaults or be nullable
   • Field types cannot change
   • Renames must be additive (new field + deprecation notice)

3. Contract Testing: Automated tests in domain team CI/CD that validate:

   • New schema version is backward compatible
   • Sample data passes quality rules
   • Documentation is updated

4. Consumer Protection:

   • Schema validation at data product boundaries
   • Query-time schema enforcement (Athena, Spark)
   • Graceful handling of missing fields via defaults

5. Deprecation Process:

   • Mark fields as deprecated with sunset date
   • Notify consumers via data catalog
   • Monitor usage of deprecated fields
   • Remove after adoption drops below threshold

Q: How do you optimize costs in a multi-region data architecture?

A: Cost optimization strategies include:

1. Data Tiering:

   • Hot data: S3 Standard for <30 days
   • Warm data: S3 Intelligent-Tiering for 30-90 days
   • Cold data: S3 Glacier for 90+ days
   • Archive: S3 Glacier Deep Archive for compliance data

2. Compute Optimization:

   • Spot instances for non-critical ETL jobs
   • Reserved instances for baseline capacity
   • Auto-scaling for variable workloads
   • Graviton instances (30% cost savings)

3. Replication Optimization:

   • Selective CRR rules (not all data needs replication)
   • Compression before replication
   • Batch replication during off-peak hours

4. Query Optimization:

   • Partition pruning in Athena
   • Columnar formats (Parquet/ORC) reducing scanned data
   • Materialized views for common queries
   • Redshift spectrum for rarely accessed data

5. Monitoring and Governance:

   • Cost allocation tags by domain and project
   • Budget alerts at team level
   • Unused resource detection and cleanup
   • Regular architecture reviews

Q: Explain how you would implement disaster recovery for a data lake with RPO of 1 hour and RTO of 4 hours.

A: For RPO=1h, RTO=4h, I would implement a warm standby pattern:

1. Primary Region (us-east-1):

   • Full data platform with all services
   • S3 Cross-Region Replication with 15-minute replication time
   • Aurora Global Database with <1s replication lag
   • Daily Glue crawlers updating data catalog

2. DR Region (us-west-2):

   • S3 buckets receiving replicated data
   • Aurora read replica (promoted on failover)
   • Pre-provisioned EMR cluster (stopped, started on failover)
   • Redshift cluster in pause/resume mode
   • Lambda functions deployed but not invoked

3. Failover Process:

   • Automated: Route53 health checks trigger DNS failover
   • Data: Aurora Global promotes to primary (<1 minute)
   • Compute: Start EMR cluster, warm Redshift (~10-15 minutes)
   • Validation: Run data quality checks, verify catalog sync

4. Testing:

   • Quarterly DR drills with full failover simulation
   • Automated runbooks tested monthly
   • Data integrity validation between regions
   • Communication protocols documented

Q: How would you handle data governance in a federated data mesh model?

A: Federated governance combines central policy enforcement with domain autonomy:

1. Policy Definition (Central Team):

   • Data classification standards (Public, Internal, Confidential, Restricted)
   • Access control patterns (RBAC, ABAC)
   • Retention and deletion requirements
   • Encryption standards (at-rest, in-transit)
   • Quality standards (completeness, accuracy, timeliness)

2. Policy Enforcement (Automated):

   • AWS Lake Formation for fine-grained access control
   • SCPs at organizational level for guardrails
   • Config rules for compliance monitoring
   • CloudFormation hooks for resource validation

3. Domain Responsibilities:

   • Implement policies within their data products
   • Document compliance in schema contracts
   • Report quality metrics to central dashboard
   • Respond to audit requests within SLA

4. Audit and Compliance:

   • CloudTrail for API-level auditing
   • Lake Formation for data access auditing
   • Automated compliance reports
   • Regular access reviews

Q: Describe the tradeoffs between using AWS Glue, EMR, and Athena for data processing.

A:

When to use each:

• Glue: Standard ETL jobs, data catalog integration, serverless requirement
• EMR: Large datasets (>1TB), complex ML pipelines, custom libraries needed
• Athena: Ad-hoc analysis, SQL-focused teams, pay-per-query model preferred

Q: How would you design a real-time fraud detection system using AWS data services?

A: Real-time fraud detection requires low-latency ingestion, processing, and decisioning:

1. Ingestion Layer:

   • Kinesis Data Streams for transaction events
   • EventBridge for non-transactional events
   • Direct Connect for banking network integration

2. Processing Layer:

   • Kinesis Data Analytics (Flink) for real-time feature computation
   • Sliding windows for velocity calculations (transactions per minute)
   • Pattern matching for known fraud signatures

3. ML Inference:

   • SageMaker Endpoints for fraud scoring models
   • Feature Store for consistent feature serving
   • A/B testing for model comparison

4. Decision Engine:

   • Lambda for synchronous fraud checks (<100ms latency)
   • Step Functions for complex decision workflows
   • SQS for async decisions requiring review

5. Storage Layer:

   • DynamoDB for real-time feature lookups
   • S3 for transaction history (Parquet format)
   • ElastiCache Redis for session/velocity tracking

6. Monitoring:

   • CloudWatch for latency metrics
   • Custom dashboards for fraud rates
   • Alerts on model drift and accuracy degradation

7. Feedback Loop:

   • Analysts label transactions as fraud/legitimate
   • Retraining pipeline updates models daily
   • Model registry tracks version performance

Q: Explain how you would implement data quality at scale in a data mesh architecture.

A: Data quality at scale requires automation, standardization, and domain ownership:

1. Quality Framework (Central Platform):

   • Great Expectations or Deequ library for validation
   • Standard rule library (null checks, range checks, uniqueness)
   • Custom rule templates for domain-specific validations
   • Quality score calculation and aggregation

2. Quality at Ingestion:

   • Glue jobs validate data before landing in data lake
   • Reject malformed records to dead letter queue
   • Alert on quality drops below threshold
   • Track ingestion metrics per source

3. Quality in Processing:

   • Transformation jobs include validation steps
   • Schema validation against contract
   • Business rule validation (e.g., revenue = quantity * price)
   • Lineage tracking through processing steps

4. Quality at Serving:

   • Pre-computed quality dashboards per domain
   • Quality badges in data catalog (Gold, Silver, Bronze)
   • SLA monitoring for freshness and availability
   • Consumer feedback mechanism

5. Quality Governance:

   • Domain teams own quality metrics for their products
   • Central team monitors aggregate quality trends
   • Quality gates in CI/CD pipelines
   • Monthly quality reviews with stakeholders

Q: How would you migrate a monolithic data warehouse to a data mesh on AWS?

A: Migration to data mesh is an organizational and technical transformation:

1. Assessment Phase (1-2 months):

   • Map current data domains and ownership
   • Identify data products and consumers
   • Document existing pipelines and dependencies
   • Assess team capabilities and readiness

2. Foundation Phase (2-3 months):

   • Deploy self-service platform (Backstage, CDK templates)
   • Establish data catalog and governance framework
   • Create golden paths for common patterns
   • Train platform team on new tools

3. Pilot Phase (2-3 months):

   • Select 2-3 domains with willing teams
   • Create initial data products per domain
   • Implement quality and monitoring
   • Gather feedback and iterate

4. Scaling Phase (6-12 months):

   • Onboard remaining domains gradually
   • Migrate shared datasets to domain ownership
   • Implement cross-domain data products
   • Retire legacy data warehouse components

5. Operational Excellence (Ongoing):

   • Continuous improvement of platform
   • Regular architecture reviews
   • Community of practice for knowledge sharing
   • Metrics tracking and optimization

Key success factors: Executive sponsorship, dedicated platform team, domain team training, incremental migration, and clear success metrics.

Summary

This topic covered the key concepts of AWS data engineering. Review the architecture diagrams, practice the interview questions, and understand the trade-offs between different service options.

Next Steps

Continue to the next topic to build on your AWS data engineering knowledge.

Knowledge Check

See Also

• AWS Architecture
• AWS Data Lake
• AWS Data Warehouse