Swiftorial Logo
Home
Swift Lessons
Tutorials
Learn More
Career
Resources

AWS Cloud Native System Architecture Blueprint

Complete Architecture Overview

This AWS Cloud Native System Architecture Blueprint outlines a scalable, secure, and observable cloud-native platform built on AWS. It leverages microservices hosted on ECS/EKS with containers, orchestrated through App Mesh using Envoy sidecars for resilient service-to-service communication. CloudFront and API Gateway, protected by WAF, handle client access, while DynamoDB, RDS, and ElastiCache manage data persistence and caching. Observability is ensured via CloudWatch, X-Ray, and CloudTrail, and security is enforced with IAM, VPC, and KMS. The architecture is designed for high availability, agility, and global scalability, supporting modern applications like APIs, web platforms, or data pipelines.

The architecture is split into layered diagrams for clarity, ensuring a comprehensive view of a scalable cloud-native platform.
graph TD %% Direction: Top to Bottom %% Styling for nodes classDef client fill:#ffeb3b,stroke:#333; classDef edge fill:#ff9800,stroke:#333; classDef compute fill:#f44336,stroke:#333; classDef mesh fill:#2196f3,stroke:#333; classDef data fill:#4caf50,stroke:#333; classDef observability fill:#9c27b0,stroke:#333; classDef security fill:#673ab7,stroke:#333; classDef cache fill:#ff5722,stroke:#333; %% Main Components Client["Client Apps (Web/Mobile)"]:::client CDN["CloudFront + WAF"]:::edge API["API Gateway"]:::edge ALB["ALB"]:::edge Cluster["ECS/EKS Cluster"]:::compute Mesh["App Mesh (Envoy)"]:::mesh DB["DynamoDB + RDS"]:::data Cache["ElastiCache"]:::cache Observability["CloudWatch + X-Ray"]:::observability Security["IAM + KMS + VPC"]:::security Audit["CloudTrail"]:::observability %% Flow Client -->|HTTPS| CDN --> API --> ALB --> Cluster Cluster --> Mesh Cluster --> DB Cluster --> Cache Cluster --> Observability Cluster --> Security API --> Audit %% Annotations linkStyle 0 stroke:#ffeb3b,stroke-width:2.5px,stroke-dasharray:6,6 linkStyle 1,2,3 stroke:#ff9800,stroke-width:2.5px linkStyle 4 stroke:#f44336,stroke-width:2.5px linkStyle 5 stroke:#2196f3,stroke-width:2.5px linkStyle 6,7 stroke:#4caf50,stroke-width:2.5px linkStyle 8 stroke:#9c27b0,stroke-width:2.5px linkStyle 9 stroke:#673ab7,stroke-width:2.5px,stroke-dasharray:4,4
This overview diagram illustrates the high-level flow from client access to service interactions, data persistence, and observability.

Architecture Principles

1. Layered Isolation

  • Presentation: CloudFront, Web/Mobile Apps
  • Edge: WAF, API Gateway, ALB
  • Compute: ECS/EKS microservices
  • Data: DynamoDB, RDS, ElastiCache
  • Observability: CloudWatch, X-Ray, CloudTrail

2. Service Communication

  • App Mesh for service routing
  • Envoy sidecars for mTLS
  • Retries and circuit breaking
  • Service discovery integration

3. Security & Compliance

  • IAM least-privilege policies
  • VPC with private subnets
  • KMS for encryption at rest
  • WAF for web protection

Key Performance Metrics

Component Target SLA Latency Throughput
API Gateway 99.95% <50ms 10,000 RPS
ECS/EKS Cluster 99.9% <100ms 5,000 RPS
ElastiCache 99.99% <5ms 20,000 QPS
DynamoDB 99.99% <10ms 10,000 WCU/RCU

1. Client Access Architecture

This diagram illustrates the client-side architecture, where Web Apps (React) and Mobile Apps (iOS/SwiftUI, Android/Kotlin) interact with the platform via CloudFront and API Gateway. CloudFront serves as a global CDN, caching static assets in S3 and executing edge logic with Lambda@Edge for request normalization. Web apps leverage CloudFront for low-latency delivery, while mobile apps connect directly to API Gateway for dynamic APIs. This layer connects to the API Gateway Architecture (Diagram 2) for secure backend interactions.

graph LR %% Client Architecture classDef web fill:#4285f4,stroke:#333; classDef mobile fill:#34a853,stroke:#333; classDef cdn fill:#ff6d01,stroke:#333; Web["Web App (React)"]:::web iOS["iOS (SwiftUI)"]:::mobile Android["Android (Kotlin)"]:::mobile CDN["CloudFront"]:::cdn API["API Gateway"] Web --> CDN --> API iOS --> API Android --> API CDN --> S3["S3 (Web Assets)"] CDN --> LambdaEdge["Lambda@Edge"] %% Annotations linkStyle 0,1,2 stroke:#ffeb3b,stroke-width:2.5px,stroke-dasharray:6,6 linkStyle 3,4 stroke:#ff6d01,stroke-width:2.5px
The Client Access Architecture ensures low-latency and secure access for web and mobile users.

Key Features

Performance Optimization

  • CloudFront caching (TTL 1yr)
  • Stale-while-revalidate for dynamic content
  • Code splitting in React
  • Progressive Web App support

Security

  • CSP headers for XSS protection
  • JWT in HttpOnly cookies
  • Certificate pinning (mobile)
  • WAF rules for bot protection
// Sample React API Client
const apiClient = axios.create({
  baseURL: process.env.API_URL,
  timeout: 5000,
  headers: {
    'Content-Type': 'application/json'
  }
});

apiClient.interceptors.response.use(null, (error) => {
  if (error.config && error.response && error.response.status >= 500) {
    return new Promise((resolve) => {
      setTimeout(() => resolve(apiClient(error.config)), 1000);
    });
  }
  return Promise.reject(error);
});

export const fetchData = (endpoint) =>
  apiClient.get(`/${endpoint}`, {
    headers: {
      'Cache-Control': 'max-age=60, stale-while-revalidate=3600'
    }
  });
                

2. API Gateway Architecture

This diagram details the API Gateway layer, which serves as the secure entry point for client requests from the Client Access Architecture (Diagram 1). It integrates with a Lambda Authorizer for JWT validation using Cognito User Pool and KMS for secure key management. The gateway routes requests to the Compute Layer (Diagram 3) and is protected by WAF rules to block malicious traffic, such as SQL injection and DDoS attacks.

graph TB %% API Gateway Flow classDef gateway fill:#ff9800,stroke:#333; classDef auth fill:#673ab7,stroke:#333; classDef service fill:#2196f3,stroke:#333; Client --> APIGW["API Gateway"]:::gateway APIGW --> Authorizer["Lambda Authorizer"]:::auth Authorizer --> Cognito["Cognito User Pool"] Authorizer --> KMS["KMS JWT Validation"] APIGW -->|/services| Compute["ECS/EKS Cluster"]:::service APIGW --> WAF["AWS WAF Rules"] WAF -->|Block| BadActors["SQLi/DDoS/Bad Bots"] %% Annotations linkStyle 0 stroke:#ffeb3b,stroke-width:2.5px,stroke-dasharray:6,6 linkStyle 1,2,3 stroke:#ff9800,stroke-width:2.5px linkStyle 4 stroke:#2196f3,stroke-width:2.5px linkStyle 5 stroke:#ff9800,stroke-width:2.5px
The API Gateway Architecture provides secure and scalable API management with robust authentication.

Gateway Configuration

Endpoint Throttling Cache TTL Auth
/api/v1/data 1000 RPS 60s Optional
/api/v1/secure 500 RPS 0s Required
# Terraform for API Gateway
resource "aws_api_gateway_rest_api" "cloud_native" {
  name        = "cloud-native-api"
  description = "API Gateway for Cloud Native Platform"
  endpoint_configuration {
    types = ["REGIONAL"]
  }
}

resource "aws_api_gateway_authorizer" "jwt" {
  name          = "jwt-authorizer"
  rest_api_id   = aws_api_gateway_rest_api.cloud_native.id
  authorizer_uri = aws_lambda_function.authorizer.invoke_arn
  type          = "TOKEN"
  identity_source = "method.request.header.Authorization"
}

resource "aws_wafv2_web_acl_association" "api" {
  resource_arn = aws_api_gateway_stage.prod.arn
  web_acl_arn  = aws_wafv2_web_acl.api.arn
}
                

3. Compute Layer Architecture

This diagram focuses on the Compute Layer, which hosts microservices on ECS/EKS clusters with containers. Requests are routed from the API Gateway (Diagram 2) via ALB to the cluster. Microservices are auto-scaled based on demand, and App Mesh (Diagram 4) manages service-to-service communication. This layer interacts with the Data Storage (Diagram 5) and Observability/Security (Diagram 6) layers.

graph LR %% Compute Layer classDef edge fill:#ff9800,stroke:#333; classDef compute fill:#f44336,stroke:#333; classDef mesh fill:#2196f3,stroke:#333; API["API Gateway"]:::edge --> ALB["ALB"]:::edge ALB --> Cluster["ECS/EKS Cluster"]:::compute Cluster --> MicroA["Microservice A"]:::compute Cluster --> MicroB["Microservice B"]:::compute MicroA --> Mesh["App Mesh (Envoy)"]:::mesh MicroB --> Mesh %% Annotations linkStyle 0 stroke:#ff9800,stroke-width:2.5px linkStyle 1 stroke:#f44336,stroke-width:2.5px linkStyle 2,3 stroke:#f44336,stroke-width:2.5px linkStyle 4,5 stroke:#2196f3,stroke-width:2.5px
The Compute Layer ensures scalable and resilient microservice execution with container orchestration.

ECS Task Definition

{
  "family": "microservice-a",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "my-app:1.0",
      "portMappings": [
        {
          "containerPort": 8080,
          "protocol": "tcp"
        }
      ],
      "essential": true,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/microservice-a",
          "awslogs-region": "us-west-2",
          "awslogs-stream-prefix": "app"
        }
      }
    },
    {
      "name": "envoy",
      "image": "aws-appmesh-envoy:v1.22.2.0-prod",
      "essential": true,
      "environment": [
        {
          "name": "APPMESH_RESOURCE_NAME",
          "value": "microservice-a"
        }
      ],
      "user": "1337",
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/microservice-a",
          "awslogs-region": "us-west-2",
          "awslogs-stream-prefix": "envoy"
        }
      }
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskRole"
}
                

4. Service Mesh Architecture

This diagram details the Service Mesh layer, which uses App Mesh with Envoy sidecars to manage service-to-service communication within the Compute Layer (Diagram 3). It supports mTLS, retries, and circuit breaking for resilience and connects to the Data Storage (Diagram 5) and Observability/Security (Diagram 6) layers.

graph LR %% Service Mesh classDef compute fill:#f44336,stroke:#333; classDef mesh fill:#2196f3,stroke:#333; MicroA["Microservice A"]:::compute --> EnvoyA["Envoy Sidecar"]:::mesh MicroB["Microservice B"]:::compute --> EnvoyB["Envoy Sidecar"]:::mesh EnvoyA --> Mesh["App Mesh"]:::mesh EnvoyB --> Mesh %% Annotations linkStyle 0,1 stroke:#f44336,stroke-width:2.5px linkStyle 2,3 stroke:#2196f3,stroke-width:2.5px
The Service Mesh Architecture ensures resilient and secure microservice communication.

App Mesh Configuration

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  Mesh:
    Type: AWS::AppMesh::Mesh
    Properties:
      MeshName: cloud-native-mesh
      Spec:
        EgressFilter:
          Type: ALLOW_ALL
  VirtualNodeA:
    Type: AWS::AppMesh::VirtualNode
    Properties:
      MeshName: !Ref Mesh
      VirtualNodeName: microservice-a
      Spec:
        ServiceDiscovery:
          DNS:
            Hostname: microservice-a.default.svc.cluster.local
        Listeners:
          - PortMapping:
              Port: 8080
              Protocol: http
        Backends:
          - VirtualService:
              VirtualServiceName: microservice-b.default.svc.cluster.local
  VirtualNodeB:
    Type: AWS::AppMesh::VirtualNode
    Properties:
      MeshName: !Ref Mesh
      VirtualNodeName: microservice-b
      Spec:
        ServiceDiscovery:
          DNS:
            Hostname: microservice-b.default.svc.cluster.local
        Listeners:
          - PortMapping:
              Port: 8080
              Protocol: http
  VirtualRouter:
    Type: AWS::AppMesh::VirtualRouter
    Properties:
      MeshName: !Ref Mesh
      VirtualRouterName: microservice-b-router
      Spec:
        Listeners:
          - PortMapping:
              Port: 8080
              Protocol: http
  Route:
    Type: AWS::AppMesh::Route
    Properties:
      MeshName: !Ref Mesh
      VirtualRouterName: !Ref VirtualRouter
      RouteName: microservice-b-route
      Spec:
        HttpRoute:
          Match:
            Prefix: /
          Action:
            WeightedTargets:
              - VirtualNode: !Ref VirtualNodeB
                Weight: 100
          RetryPolicy:
            MaxRetries: 3
            PerRetryTimeout:
              Unit: ms
              Value: 2000
            HttpRetryEvents:
              - server-error
                

5. Data Storage Architecture

This diagram focuses on the Data Storage layer, which includes DynamoDB for NoSQL data, RDS for relational data, and ElastiCache for caching. The Compute Layer (Diagram 3) interacts with this layer for data persistence and low-latency access, with encryption managed by KMS.

graph LR %% Data Storage classDef compute fill:#f44336,stroke:#333; classDef data fill:#4caf50,stroke:#333; classDef cache fill:#ff5722,stroke:#333; classDef security fill:#673ab7,stroke:#333; Cluster["ECS/EKS Cluster"]:::compute --> DynamoDB["DynamoDB"]:::data Cluster --> RDS["RDS"]:::data Cluster --> Cache["ElastiCache"]:::cache DynamoDB --> KMS["KMS"]:::security RDS --> KMS %% Annotations linkStyle 0,1,2 stroke:#f44336,stroke-width:2.5px linkStyle 3,4 stroke:#673ab7,stroke-width:2.5px
The Data Storage Architecture ensures scalable and secure data persistence with caching.

Data Model

-- RDS Schema (PostgreSQL)
CREATE TABLE entities (
  id UUID PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  attributes JSONB,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  updated_at TIMESTAMPTZ
);

-- DynamoDB Schema
{
  "TableName": "Entities",
  "KeySchema": [
    { "AttributeName": "pk", "KeyType": "HASH" },  // "ENTITY#123"
    { "AttributeName": "sk", "KeyType": "RANGE" }  // "METADATA"
  ],
  "GlobalSecondaryIndexes": [
    {
      "IndexName": "NameIndex",
      "KeySchema": [
        { "AttributeName": "name", "KeyType": "HASH" }
      ],
      "Projection": { "ProjectionType": "INCLUDE", "NonKeyAttributes": ["attributes"] }
    }
  ]
}
                

Cache Strategy

Read-Through Cache

  • Cache hit: 5ms response
  • Cache miss: 50ms (DB + warm cache)
  • TTL: 5 minutes (hot data)
  • TTL: 1 hour (static data)

Invalidation Triggers

  • Data updates
  • Attribute changes
  • Scheduled refreshes
  • Event-driven invalidation

6. Observability and Security Architecture

This diagram details the Observability and Security layer, which includes CloudWatch for metrics and logs, X-Ray for tracing, and CloudTrail for auditing. Security is enforced with IAM, VPC, and KMS. The Compute Layer (Diagram 3) integrates with this layer for monitoring and compliance.

graph LR %% Observability and Security classDef compute fill:#f44336,stroke:#333; classDef observability fill:#9c27b0,stroke:#333; classDef security fill:#673ab7,stroke:#333; Cluster["ECS/EKS Cluster"]:::compute --> CloudWatch["CloudWatch"]:::observability Cluster --> XRay["X-Ray"]:::observability Cluster --> CloudTrail["CloudTrail"]:::observability Cluster --> IAM["IAM"]:::security Cluster --> VPC["VPC"]:::security Cluster --> KMS["KMS"]:::security %% Annotations linkStyle 0,1,2 stroke:#9c27b0,stroke-width:2.5px linkStyle 3,4,5 stroke:#673ab7,stroke-width:2.5px
The Observability and Security Architecture ensures comprehensive monitoring and robust protection.

CloudWatch Alarm Configuration

Resources:
  HighCPUMetricAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: HighCPUUsage
      AlarmDescription: Triggers when ECS CPU usage exceeds 80%
      MetricName: CPUUtilization
      Namespace: AWS/ECS
      Statistic: Average
      Period: 300
      EvaluationPeriods: 2
      Threshold: 80
      ComparisonOperator: GreaterThanThreshold
      Dimensions:
        - Name: ClusterName
          Value: CloudNativeCluster
      AlarmActions:
        - !Ref SNSTopic
      TreatMissingData: notBreaching
  SNSTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: CloudNativeAlerts
                

Security Controls

Access Control

  • IAM least-privilege policies
  • Role-based access control
  • Service-linked roles
  • Session management

Network Security

  • VPC private subnets
  • Security groups
  • Network ACLs
  • WAF rules