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.
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.
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.
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.
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.
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.
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.
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
