AWS Deployment

AWS Deployment Options

For most teams deploying OpenClaw as an always-on service, ECS Fargate offers the best balance of simplicity, cost control, and production readiness.

ECS Fargate Setup

1. Push Image to ECR

# Create ECR repository
aws ecr create-repository --repository-name openclaw

# Authenticate Docker to ECR
aws ecr get-login-password --region us-east-1 |   docker login --username AWS --password-stdin   123456789012.dkr.ecr.us-east-1.amazonaws.com

# Tag and push
docker tag openclaw:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/openclaw:latest
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/openclaw:latest

2. Store Secrets in AWS Secrets Manager

# Store your API key
aws secretsmanager create-secret   --name openclaw/openai-api-key   --secret-string "sk-your-key"

# OpenClaw reads secrets at startup via the AWS SDK
# Set in config.yaml:
secrets:
  provider: aws_secrets_manager
  region: us-east-1

3. Create ECS Task Definition

{
  "family": "openclaw",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [{
    "name": "openclaw",
    "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/openclaw:latest",
    "portMappings": [{"containerPort": 8080}],
    "environment": [
      {"name": "OPENCLAW_ENV", "value": "production"},
      {"name": "REDIS_URL", "value": "redis://your-elasticache:6379"}
    ],
    "secrets": [{
      "name": "OPENAI_API_KEY",
      "valueFrom": "arn:aws:secretsmanager:us-east-1:123456789012:secret:openclaw/openai-api-key"
    }],
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "/ecs/openclaw",
        "awslogs-region": "us-east-1",
        "awslogs-stream-prefix": "ecs"
      }
    },
    "healthCheck": {
      "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
      "interval": 30, "timeout": 10, "retries": 3
    }
  }]
}

AWS-Native Service Integrations

Auto Scaling

# Register auto scaling target
aws application-autoscaling register-scalable-target   --service-namespace ecs   --resource-id service/openclaw-cluster/openclaw-service   --scalable-dimension ecs:service:DesiredCount   --min-capacity 1   --max-capacity 10

# Scale on CPU utilization > 70%
aws application-autoscaling put-scaling-policy   --policy-name cpu-scale-out   --service-namespace ecs   --resource-id service/openclaw-cluster/openclaw-service   --scalable-dimension ecs:service:DesiredCount   --policy-type TargetTrackingScaling   --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    }
  }'

Infrastructure Setup

For a production OpenClaw deployment on AWS, start with the right service for your workload. ECS Fargate is the recommended choice for most deployments — it's fully managed, scales automatically, and requires no EC2 instance management. Lambda works for short-running tasks (under 15 minutes) with low frequency. EC2 is appropriate if you need GPU acceleration for local LLM inference, fine-grained instance control, or very high sustained throughput where Fargate costs become significant. Match your service choice to your operational constraints rather than defaulting to EC2 out of familiarity.

Use the following IAM policy structure for the ECS task execution role: one role for infrastructure access (ECR pull, CloudWatch Logs write) and a separate application role for what the agent process itself can access (Secrets Manager get, S3 read/write for your allowed buckets, and nothing else). Keep the application role's permissions as narrow as possible — if the agent container is compromised, a minimal application role limits what an attacker can do within your AWS account.

Secrets Management on AWS

Store all credentials (LLM API keys, webhook tokens, database passwords) in AWS Secrets Manager, not in environment variables or container image layers. Reference secrets in your ECS task definition using the secrets section, which injects them as environment variables at container startup without them appearing in task definition history or container metadata. Enable automatic rotation for secrets Secrets Manager supports natively (RDS passwords, for example). For LLM API keys that require manual rotation, set a reminder in your operational calendar and document the rotation procedure in your runbook.

Logging and Observability

Configure the awslogs log driver in your ECS task definition to stream all container stdout/stderr to CloudWatch Logs. Create a log group per agent with an appropriate retention period (30-90 days for most use cases). Set up CloudWatch Metric Filters to extract key metrics from your log output — errors per minute, tasks per minute, average task latency — and create CloudWatch Alarms for thresholds that indicate problems. This gives you operational visibility without requiring a separate observability stack, keeping infrastructure complexity low for most deployments.

Cost Optimization

Use Fargate Spot for batch and background processing tasks to reduce compute costs by up to 70%. Configure automatic scaling to scale to zero during off-hours for workloads with predictable usage patterns. Use Application Auto Scaling with scheduled scaling for known traffic patterns (scale up at 8am, down at 8pm) supplemented by target tracking for unexpected surges. Review your costs monthly — LLM API costs typically dominate total cost, but compute costs can grow unexpectedly if autoscaling configuration is incorrect. Set billing alarms in AWS Cost Explorer to alert on unexpected cost spikes.

Quick Start with ECS Fargate

Create a task definition with your OpenClaw container image, configure the execution role and task role, define the container CPU/memory (256 CPU, 512MB RAM is sufficient for a single API-based agent), then create an ECS service in your VPC's private subnet. Add a NAT Gateway for outbound internet access to LLM provider APIs. Use the AWS CLI or CDK to define this infrastructure as code from the start — manually configured AWS resources accumulate configuration drift over time and are difficult to reproduce consistently across multiple environments.