AWS App Mesh Complete Guide

Service Mesh Architecture, Traffic Flow, and Implementation

Table of Contents

1. AWS App Mesh Overview

AWS App Mesh is a service mesh that provides application-level networking to make it easy for your services to communicate with each other across multiple types of compute infrastructure. It gives end-to-end visibility and ensures high availability for your applications.

graph TD A[Client Application] --> B[Application Load Balancer] B --> C[App Mesh Service Discovery] C --> D[Virtual Service] D --> E[Virtual Router] E --> F[Route 1 - 80% Traffic] E --> G[Route 2 - 20% Traffic] F --> H[Virtual Node v1] G --> I[Virtual Node v2] H --> J[ECS Service v1] I --> K[ECS Service v2] J --> L[Envoy Proxy] K --> M[Envoy Proxy] L --> N[Application Container v1] M --> O[Application Container v2]

App Mesh Overview Diagram Explanation

This diagram shows the complete flow of traffic through AWS App Mesh:

  • Client Application: External or internal clients making requests
  • Application Load Balancer: Entry point distributing traffic
  • Virtual Service: Abstract representation of a service
  • Virtual Router: Handles routing logic and traffic splitting
  • Routes: Define how traffic is distributed (e.g., 80/20 split for blue-green deployment)
  • Virtual Nodes: Represent actual compute resources
  • Envoy Proxy: Sidecar proxy handling all network communication
  • Application Containers: Your actual application code

2. Understanding Envoy Proxy

Envoy proxy is the backbone of AWS App Mesh's data plane. It's a high-performance, Layer 7 proxy written in C++ that handles all network communication between your services. Understanding Envoy is crucial for effectively using App Mesh.

graph TD subgraph "Service A Container" A1[Application A] A2[Envoy Sidecar A] end subgraph "Service B Container" B1[Application B] B2[Envoy Sidecar B] end subgraph "App Mesh Control Plane" C1[Configuration Management] C2[Service Discovery] C3[Certificate Management] end A1 -.-> A2 A2 --> B2 B2 -.-> B1 C1 --> A2 C1 --> B2 C2 --> A2 C2 --> B2 C3 --> A2 C3 --> B2 A2 --> D[CloudWatch Metrics] A2 --> E[X-Ray Traces] B2 --> D B2 --> E style A2 fill:#ff6b6b,color:#fff style B2 fill:#ff6b6b,color:#fff style C1 fill:#4ecdc4,color:#fff style C2 fill:#4ecdc4,color:#fff style C3 fill:#4ecdc4,color:#fff

Envoy Proxy Sidecar Pattern

This diagram illustrates how Envoy operates as a sidecar proxy:

  • Sidecar Deployment: Each service gets its own Envoy proxy instance
  • Traffic Interception: All network calls go through Envoy (dotted lines)
  • Control Plane Integration: App Mesh configures Envoy automatically
  • Observability: Envoy sends metrics and traces to AWS services
  • Transparent Operation: Applications don't need code changes

Traffic Interception Mechanism

sequenceDiagram participant App as Application participant Envoy as Envoy Proxy participant Mesh as App Mesh Control Plane participant Target as Target Service Note over App,Target: Outbound Traffic Flow App->>Envoy: 1. Call service-b:8080 Envoy->>Mesh: 2. Query service discovery Mesh->>Envoy: 3. Return endpoint list Envoy->>Envoy: 4. Apply load balancing Envoy->>Target: 5. Route to selected endpoint Target->>Envoy: 6. Response Envoy->>App: 7. Forward response Note over App,Target: Observability Side Effects Envoy->>CloudWatch: Metrics (latency, errors) Envoy->>X-Ray: Distributed traces Envoy->>CloudWatch: Access logs

Traffic Interception Flow

This sequence shows how Envoy handles service-to-service communication:

  1. Service Call: Application makes normal HTTP/gRPC call
  2. Interception: Envoy intercepts before it leaves the container
  3. Service Discovery: Envoy queries App Mesh for current endpoints
  4. Load Balancing: Envoy selects the best target instance
  5. Routing: Traffic is routed to the selected endpoint
  6. Response Handling: Response is processed and forwarded
  7. Observability: Metrics, traces, and logs are automatically generated

Envoy Core Capabilities

mindmap root((Envoy Proxy)) Traffic Management Load Balancing Round Robin Least Request Random Ring Hash Circuit Breaking Failure Detection Fast Failure Recovery Testing Retries Exponential Backoff Retry Budget Condition-based Timeouts Request Timeout Idle Timeout Connection Timeout Security mTLS Certificate Management Automatic Rotation Verification Access Control Service-to-Service Path-based Header-based Rate Limiting Per Service Per User Per Endpoint Observability Metrics Request Count Latency Percentiles Error Rates Connection Stats Tracing Span Generation Trace Correlation Sampling Logging Access Logs Error Logs Debug Logs Protocol Support HTTP/1.1 HTTP/2 gRPC TCP WebSocket

Envoy Capabilities Overview

This mind map shows Envoy's comprehensive feature set:

  • Traffic Management: Intelligent routing, load balancing, and resilience patterns
  • Security: Automatic TLS, access control, and rate limiting
  • Observability: Built-in metrics, tracing, and logging
  • Protocol Support: Works with modern and legacy protocols

Envoy vs Traditional Approaches

graph TD subgraph "Traditional Library Approach" A1[Java Service] --> A2[Hystrix Library] A3[Python Service] --> A4[Requests + Retry Logic] A5[Go Service] --> A6[Custom HTTP Client] A2 --> A7[Inconsistent Behavior] A4 --> A7 A6 --> A7 A7 --> A8[Multiple Implementations] A8 --> A9[Maintenance Overhead] end subgraph "Envoy Sidecar Approach" B1[Java Service] --> B2[Envoy Proxy] B3[Python Service] --> B4[Envoy Proxy] B5[Go Service] --> B6[Envoy Proxy] B2 --> B7[Consistent Behavior] B4 --> B7 B6 --> B7 B7 --> B8[Single Implementation] B8 --> B9[Centralized Management] end style A7 fill:#ff6b6b,color:#fff style A8 fill:#ff6b6b,color:#fff style A9 fill:#ff6b6b,color:#fff style B7 fill:#4ecdc4,color:#fff style B8 fill:#4ecdc4,color:#fff style B9 fill:#4ecdc4,color:#fff

Traditional vs Envoy Approach

This comparison highlights why service mesh with Envoy is superior:

  • Traditional: Each language needs its own networking libraries
  • Envoy: Language-agnostic solution with consistent behavior
  • Benefits: Reduced maintenance, consistent policies, centralized updates

Envoy Configuration in App Mesh

In AWS App Mesh, you don't configure Envoy directly. Instead, App Mesh acts as the control plane and automatically configures Envoy based on your mesh resources.

# You define App Mesh resources
aws appmesh create-virtual-node \
    --mesh-name my-mesh \
    --virtual-node-name user-service \
    --spec '{
        "listeners": [
            {
                "portMapping": {"port": 8080, "protocol": "http"},
                "healthCheck": {
                    "protocol": "http",
                    "path": "/health",
                    "healthyThreshold": 2,
                    "unhealthyThreshold": 3
                }
            }
        ]
    }'

Automatic Envoy Configuration

When you create this virtual node, App Mesh automatically configures Envoy with:

  • Listener Configuration: Port 8080 HTTP listener
  • Health Check Setup: HTTP health checks every 30 seconds
  • Service Discovery: Endpoints from Cloud Map or DNS
  • Load Balancing: Default round-robin algorithm
  • Observability: Metrics, tracing, and logging enabled

Envoy Performance Characteristics

graph LR A[Incoming Request] --> B[Connection Pool] B --> C[HTTP/2 Multiplexing] C --> D[Request Processing] D --> E[Upstream Connection] E --> F[Response Processing] F --> G[Response to Client] B -.-> H[Connection Reuse] C -.-> I[Stream Multiplexing] D -.-> J[Non-blocking I/O] E -.-> K[Circuit Breaking] F -.-> L[Response Buffering] style H fill:#e8f5e8 style I fill:#e8f5e8 style J fill:#e8f5e8 style K fill:#e8f5e8 style L fill:#e8f5e8

Envoy Performance Features

Envoy is optimized for high-performance networking:

  • Connection Pooling: Reuses connections to reduce overhead
  • HTTP/2 Support: Multiplexes multiple requests over single connections
  • Non-blocking I/O: Handles thousands of concurrent connections
  • Circuit Breaking: Prevents cascade failures with fast failure detection
  • Smart Buffering: Optimizes memory usage and response handling

Envoy Deployment in ECS

Here's how Envoy is deployed as a sidecar in ECS with App Mesh:

{
    "containerDefinitions": [
        {
            "name": "app",
            "image": "my-app:latest",
            "dependsOn": [
                {
                    "containerName": "envoy",
                    "condition": "HEALTHY"
                }
            ],
            "environment": [
                {
                    "name": "APPMESH_VIRTUAL_NODE_NAME",
                    "value": "mesh/my-mesh/virtualNode/user-service"
                }
            ]
        },
        {
            "name": "envoy",
            "image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.22.2.1-prod",
            "user": "1337",
            "healthCheck": {
                "command": [
                    "CMD-SHELL",
                    "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
                ]
            },
            "environment": [
                {
                    "name": "APPMESH_VIRTUAL_NODE_NAME", 
                    "value": "mesh/my-mesh/virtualNode/user-service"
                }
            ]
        }
    ],
    "proxyConfiguration": {
        "type": "APPMESH",
        "containerName": "envoy",
        "properties": [
            {"name": "IgnoredUID", "value": "1337"},
            {"name": "ProxyIngressPort", "value": "15000"},
            {"name": "ProxyEgressPort", "value": "15001"},
            {"name": "AppPorts", "value": "8080"},
            {"name": "EgressIgnoredIPs", "value": "169.254.170.2,169.254.169.254"}
        ]
    }
}

ECS Sidecar Configuration

  • dependsOn: Ensures Envoy starts before application
  • APPMESH_VIRTUAL_NODE_NAME: Links container to mesh configuration
  • proxyConfiguration: Configures traffic interception
  • IgnoredUID: User ID that bypasses proxy (Envoy's UID)
  • AppPorts: Ports your application listens on
  • EgressIgnoredIPs: AWS metadata endpoints bypassed by proxy

3. Architecture Components

graph LR subgraph "App Mesh Control Plane" A[Mesh Configuration] B[Virtual Services] C[Virtual Nodes] D[Virtual Routers] E[Routes] end subgraph "Data Plane" F[Envoy Proxy 1] G[Envoy Proxy 2] H[Envoy Proxy 3] end subgraph "Compute Infrastructure" I[ECS Tasks] J[EKS Pods] K[EC2 Instances] end A --> F A --> G A --> H F --> I G --> J H --> K

Architecture Components Explanation

App Mesh separates control plane from data plane:

  • Control Plane: Manages configuration and policies
  • Data Plane: Envoy proxies handle actual traffic
  • Compute Infrastructure: Your applications run on ECS, EKS, or EC2

3. Traffic Flow Diagrams

Service-to-Service Communication

sequenceDiagram participant C as Client participant EP1 as Envoy Proxy (Service A) participant SA as Service A participant EP2 as Envoy Proxy (Service B) participant SB as Service B participant AM as App Mesh Control Plane C->>EP1: HTTP Request EP1->>AM: Query Service Discovery AM->>EP1: Return Service B Endpoint EP1->>SA: Forward Request SA->>EP1: Response to call Service B EP1->>EP2: HTTP Request to Service B EP2->>SB: Forward Request SB->>EP2: Response EP2->>EP1: HTTP Response EP1->>SA: Forward Response SA->>EP1: Final Response EP1->>C: HTTP Response

Service-to-Service Communication Flow

This sequence diagram shows how services communicate through App Mesh:

  • Service Discovery: Envoy queries App Mesh for service endpoints
  • Proxy Intercept: All traffic goes through Envoy sidecars
  • Routing Decisions: Made based on App Mesh configuration
  • Load Balancing: Envoy handles load balancing to multiple instances

Traffic Splitting (Canary Deployment)

graph TD A[Incoming Traffic] --> B[Virtual Service: user-service] B --> C[Virtual Router: user-router] C --> D[Route: 90% Weight] C --> E[Route: 10% Weight] D --> F[Virtual Node: user-v1] E --> G[Virtual Node: user-v2] F --> H[ECS Service v1.0] G --> I[ECS Service v2.0] H --> J[Task 1] H --> K[Task 2] I --> L[Task 3] I --> M[Task 4] style D fill:#e1f5fe style E fill:#fff3e0 style F fill:#e8f5e8 style G fill:#fff8e1

Traffic Splitting Explanation

This diagram demonstrates canary deployment using App Mesh:

  • 90% Traffic: Routes to stable version (v1.0)
  • 10% Traffic: Routes to canary version (v2.0)
  • Gradual Migration: Weights can be adjusted gradually
  • Rollback Capability: Can quickly redirect traffic if issues occur

4. Setup Command Sequence

graph TD A[1Create Mesh] --> B[2Create Virtual Services] B --> C[3Create Virtual Nodes] C --> D[4Create Virtual Routers] D --> E[5Create Routes] E --> F[6Deploy Applications] F --> G[7Configure Service Discovery] G --> H[8Update Task Definitions] H --> I[9Deploy Services] I --> J[10Verify Configuration] style A fill:#ff6b6b,color:#fff style B fill:#4ecdc4,color:#fff style C fill:#45b7d1,color:#fff style D fill:#96ceb4,color:#fff style E fill:#ffeaa7,color:#000 style F fill:#dda0dd,color:#fff style G fill:#98d8c8,color:#fff style H fill:#f7dc6f,color:#000 style I fill:#bb8fce,color:#fff style J fill:#82e0aa,color:#000

Setup Command Sequence Explanation

This diagram shows the proper order for setting up App Mesh components:

  1. Create Mesh: The foundation container for all resources
  2. Create Virtual Services: Abstract service definitions
  3. Create Virtual Nodes: Represent actual compute resources
  4. Create Virtual Routers: Handle routing logic
  5. Create Routes: Define traffic distribution rules
  6. Deploy Applications: Set up your containerized applications
  7. Configure Service Discovery: Set up service registration
  8. Update Task Definitions: Add Envoy sidecar configuration
  9. Deploy Services: Launch services with mesh integration
  10. Verify Configuration: Test and validate the setup

5. Mesh Configuration

Step 1: Create the Mesh

The mesh is the top-level container for all App Mesh resources.

aws appmesh create-mesh \
    --mesh-name my-mesh \
    --spec egressFilter='{allowAll=true}' \
    --tags 'key=Environment,value=Production' \
    --region us-west-2

Mesh Creation Parameters

  • --mesh-name: Unique identifier for your mesh
  • --spec egressFilter: Controls outbound traffic (allowAll=true allows all egress)
  • --tags: Resource tags for organization and billing
  • --region: AWS region where mesh will be created

Other egressFilter options:

  • allowAll=false - Only allow traffic to services in the mesh
  • dropAll=true - Block all egress traffic

Mesh with Advanced Configuration

aws appmesh create-mesh \
    --mesh-name production-mesh \
    --spec '{
        "egressFilter": {
            "type": "DROP_ALL"
        },
        "serviceDiscovery": {
            "ipPreference": "IPv4_ONLY"
        }
    }' \
    --tags '[
        {
            "key": "Environment",
            "value": "Production"
        },
        {
            "key": "Team",
            "value": "Platform"
        }
    ]'

Advanced Mesh Configuration

  • egressFilter.type: DROP_ALL blocks external traffic
  • serviceDiscovery.ipPreference: IPv4_ONLY or IPv6_PREFERRED
  • Multiple tags: Better resource organization

6. Virtual Services

Step 2: Create Virtual Services

Virtual services provide an abstraction layer over your actual services.

aws appmesh create-virtual-service \
    --mesh-name my-mesh \
    --virtual-service-name user-service.local \
    --spec '{
        "provider": {
            "virtualRouter": {
                "virtualRouterName": "user-router"
            }
        }
    }'

Virtual Service Parameters

  • --virtual-service-name: DNS name for the service
  • provider.virtualRouter: Routes traffic through a virtual router
  • Alternative providers: virtualNode (direct routing)

Virtual Service with Direct Node Provider

aws appmesh create-virtual-service \
    --mesh-name my-mesh \
    --virtual-service-name database-service.local \
    --spec '{
        "provider": {
            "virtualNode": {
                "virtualNodeName": "database-node"
            }
        }
    }'

Direct Node Provider

  • virtualNode provider: Direct routing to a specific virtual node
  • Use case: Services that don't need traffic splitting or routing logic
  • Simpler configuration: Bypasses virtual router complexity

7. Virtual Nodes

Step 3: Create Virtual Nodes

Virtual nodes represent your actual compute resources and service instances.

aws appmesh create-virtual-node \
    --mesh-name my-mesh \
    --virtual-node-name user-service-v1 \
    --spec '{
        "listeners": [
            {
                "portMapping": {
                    "port": 8080,
                    "protocol": "http"
                }
            }
        ],
        "serviceDiscovery": {
            "awsCloudMap": {
                "namespaceName": "my-namespace",
                "serviceName": "user-service"
            }
        }
    }'

Virtual Node Parameters

  • listeners.portMapping: Port and protocol the service listens on
  • serviceDiscovery.awsCloudMap: AWS Cloud Map service discovery
  • namespaceName: Cloud Map namespace
  • serviceName: Service name in Cloud Map

Virtual Node with Health Check

aws appmesh create-virtual-node \
    --mesh-name my-mesh \
    --virtual-node-name user-service-v2 \
    --spec '{
        "listeners": [
            {
                "portMapping": {
                    "port": 8080,
                    "protocol": "http"
                },
                "healthCheck": {
                    "protocol": "http",
                    "path": "/health",
                    "healthyThreshold": 2,
                    "unhealthyThreshold": 3,
                    "timeoutMillis": 5000,
                    "intervalMillis": 30000
                }
            }
        ],
        "serviceDiscovery": {
            "awsCloudMap": {
                "namespaceName": "my-namespace",
                "serviceName": "user-service-v2",
                "attributes": [
                    {
                        "key": "version",
                        "value": "v2"
                    }
                ]
            }
        }
    }'

Health Check Configuration

  • protocol: Health check protocol (http, tcp, http2, grpc)
  • path: Health check endpoint path
  • healthyThreshold: Consecutive successful checks to mark healthy
  • unhealthyThreshold: Consecutive failed checks to mark unhealthy
  • timeoutMillis: Request timeout in milliseconds
  • intervalMillis: Time between health checks

Virtual Node with Backend Services

aws appmesh create-virtual-node \
    --mesh-name my-mesh \
    --virtual-node-name frontend-service \
    --spec '{
        "listeners": [
            {
                "portMapping": {
                    "port": 3000,
                    "protocol": "http"
                }
            }
        ],
        "backends": [
            {
                "virtualService": {
                    "virtualServiceName": "user-service.local"
                }
            },
            {
                "virtualService": {
                    "virtualServiceName": "database-service.local"
                }
            }
        ],
        "serviceDiscovery": {
            "dns": {
                "hostname": "frontend.example.com"
            }
        }
    }'

Backend Services Configuration

  • backends: Services this node can communicate with
  • virtualService: Reference to virtual service names
  • serviceDiscovery.dns: DNS-based service discovery
  • Security: Only listed backends are accessible

8. Virtual Routers

Step 4: Create Virtual Routers

Virtual routers handle traffic routing logic and load balancing.

aws appmesh create-virtual-router \
    --mesh-name my-mesh \
    --virtual-router-name user-router \
    --spec '{
        "listeners": [
            {
                "portMapping": {
                    "port": 8080,
                    "protocol": "http"
                }
            }
        ]
    }'

Virtual Router Parameters

  • listeners.portMapping: Port and protocol for routing
  • Multiple listeners: Can handle multiple ports/protocols
  • Protocol options: http, http2, tcp, grpc

Virtual Router with Multiple Listeners

aws appmesh create-virtual-router \
    --mesh-name my-mesh \
    --virtual-router-name api-router \
    --spec '{
        "listeners": [
            {
                "portMapping": {
                    "port": 8080,
                    "protocol": "http"
                }
            },
            {
                "portMapping": {
                    "port": 8443,
                    "protocol": "http"
                }
            }
        ]
    }'

Multiple Listeners

  • Port 8080: HTTP traffic
  • Port 8443: HTTPS traffic
  • Separate routing: Different routes can be configured per port

9. Routes Configuration

Step 5: Create Routes

Routes define how traffic is distributed to different virtual nodes.

aws appmesh create-route \
    --mesh-name my-mesh \
    --virtual-router-name user-router \
    --route-name user-route \
    --spec '{
        "httpRoute": {
            "match": {
                "prefix": "/"
            },
            "action": {
                "weightedTargets": [
                    {
                        "virtualNode": "user-service-v1",
                        "weight": 80
                    },
                    {
                        "virtualNode": "user-service-v2",
                        "weight": 20
                    }
                ]
            }
        }
    }'

Route Parameters

  • httpRoute.match.prefix: URL path prefix to match
  • weightedTargets: Traffic distribution weights
  • weight: Percentage of traffic (must sum to 100)
  • virtualNode: Target virtual node name

Route with Header Matching

aws appmesh create-route \
    --mesh-name my-mesh \
    --virtual-router-name user-router \
    --route-name beta-route \
    --spec '{
        "httpRoute": {
            "match": {
                "prefix": "/",
                "headers": [
                    {
                        "name": "x-beta-user",
                        "match": {
                            "exact": "true"
                        }
                    }
                ]
            },
            "action": {
                "weightedTargets": [
                    {
                        "virtualNode": "user-service-v2",
                        "weight": 100
                    }
                ]
            }
        },
        "priority": 10
    }'

Header Matching Configuration

  • headers: HTTP headers to match
  • match.exact: Exact header value match
  • priority: Route priority (lower number = higher priority)
  • Other match types: prefix, suffix, regex

Route with Retry Policy

aws appmesh create-route \
    --mesh-name my-mesh \
    --virtual-router-name user-router \
    --route-name resilient-route \
    --spec '{
        "httpRoute": {
            "match": {
                "prefix": "/api"
            },
            "action": {
                "weightedTargets": [
                    {
                        "virtualNode": "user-service-v1",
                        "weight": 100
                    }
                ]
            },
            "retryPolicy": {
                "maxRetries": 3,
                "perRetryTimeout": {
                    "value": 5,
                    "unit": "s"
                },
                "httpRetryEvents": [
                    "server-error",
                    "gateway-error"
                ]
            }
        }
    }'

Retry Policy Configuration

  • maxRetries: Maximum number of retry attempts
  • perRetryTimeout: Timeout for each retry attempt
  • httpRetryEvents: HTTP conditions that trigger retries
  • Available events: server-error, gateway-error, client-error, stream-error

10. Advanced Features

Circuit Breaker Configuration

stateDiagram-v2 [*] --> Closed Closed --> Open : Failure threshold reached Open --> HalfOpen : Timeout period expires HalfOpen --> Closed : Success threshold reached HalfOpen --> Open : Any failure occurs state Closed { [*] --> Normal_Traffic Normal_Traffic --> Monitoring_Failures } state Open { [*] --> Failing_Fast Failing_Fast --> Waiting_Timeout } state HalfOpen { [*] --> Limited_Traffic Limited_Traffic --> Testing_Recovery }

Circuit Breaker State Diagram

The circuit breaker pattern prevents cascading failures:

  • Closed: Normal operation, monitoring for failures
  • Open: Failing fast, not attempting calls
  • Half-Open: Testing if service has recovered
aws appmesh create-virtual-node \
    --mesh-name my-mesh \
    --virtual-node-name resilient-service \
    --spec '{
        "listeners": [
            {
                "portMapping": {
                    "port": 8080,
                    "protocol": "http"
                },
                "outlierDetection": {
                    "maxServerErrors": 5,
                    "interval": {
                        "value": 30,
                        "unit": "s"
                    },
                    "baseEjectionDuration": {
                        "value": 30,
                        "unit": "s"
                    },
                    "maxEjectionPercent": 50
                }
            }
        ]
    }'

Outlier Detection (Circuit Breaker)

  • maxServerErrors: Errors before ejection
  • interval: Analysis window duration
  • baseEjectionDuration: Minimum ejection time
  • maxEjectionPercent: Maximum percentage of hosts to eject

TLS Configuration

aws appmesh create-virtual-node \
    --mesh-name my-mesh \
    --virtual-node-name secure-service \
    --spec '{
        "listeners": [
            {
                "portMapping": {
                    "port": 8443,
                    "protocol": "http"
                },
                "tls": {
                    "mode": "STRICT",
                    "certificate": {
                        "acm": {
                            "certificateArn": "arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
                        }
                    }
                }
            }
        ]
    }'

TLS Configuration

  • mode: STRICT (enforce TLS) or PERMISSIVE (allow both)
  • certificate.acm: AWS Certificate Manager certificate
  • Alternative: file-based certificates

Service Mesh Monitoring

graph TD A[App Mesh Services] --> B[Envoy Proxy Metrics] B --> C[CloudWatch Metrics] B --> D[X-Ray Tracing] B --> E[Access Logs] C --> F[CloudWatch Dashboards] D --> G[X-Ray Service Map] E --> H[CloudWatch Logs] F --> I[Alerts & Notifications] G --> J[Performance Analysis] H --> K[Log Analysis]

Monitoring and Observability

App Mesh provides comprehensive observability:

  • Metrics: Automatically sent to CloudWatch
  • Tracing: X-Ray integration for request tracing
  • Access Logs: Detailed request/response logging
  • Dashboards: Visual monitoring interfaces

Complete Application Deployment

Final Steps: Deploy with ECS

Update your ECS task definition to include the Envoy proxy sidecar.

{
    "family": "user-service-task",
    "networkMode": "awsvpc",
    "requiresCompatibilities": ["FARGATE"],
    "cpu": "512",
    "memory": "1024",
    "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
    "taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskRole",
    "proxyConfiguration": {
        "type": "APPMESH",
        "containerName": "envoy",
        "properties": [
            {
                "name": "IgnoredUID",
                "value": "1337"
            },
            {
                "name": "ProxyIngressPort",
                "value": "15000"
            },
            {
                "name": "ProxyEgressPort",
                "value": "15001"
            },
            {
                "name": "AppPorts",
                "value": "8080"
            },
            {
                "name": "EgressIgnoredIPs",
                "value": "169.254.170.2,169.254.169.254"
            }
        ]
    },
    "containerDefinitions": [
        {
            "name": "user-service",
            "image": "my-account.dkr.ecr.us-west-2.amazonaws.com/user-service:latest",
            "portMappings": [
                {
                    "containerPort": 8080,
                    "protocol": "tcp"
                }
            ],
            "environment": [
                {
                    "name": "APPMESH_VIRTUAL_NODE_NAME",
                    "value": "mesh/my-mesh/virtualNode/user-service-v1"
                }
            ],
            "dependsOn": [
                {
                    "containerName": "envoy",
                    "condition": "HEALTHY"
                }
            ]
        },
        {
            "name": "envoy",
            "image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.22.2.1-prod",
            "user": "1337",
            "healthCheck": {
                "command": [
                    "CMD-SHELL",
                    "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
                ],
                "interval": 5,
                "timeout": 2,
                "retries": 3,
                "startPeriod": 10
            },
            "environment": [
                {
                    "name": "APPMESH_VIRTUAL_NODE_NAME",
                    "value": "mesh/my-mesh/virtualNode/user-service-v1"
                }
            ]
        }
    ]
}

ECS Task Definition for App Mesh

  • proxyConfiguration: Configures Envoy sidecar
  • AppPorts: Ports your application listens on
  • APPMESH_VIRTUAL_NODE_NAME: Links to your virtual node
  • dependsOn: Ensures Envoy starts before your app
  • Envoy image: AWS-provided Envoy proxy image