FCJ Workshops for Performance: This section aligns with EC2 Workshop (000004) for compute optimization and VPC Workshop (000003) for network performance concepts.
This section covers the performance pillar of the AWS Well-Architected Framework, ensuring efficient use of computing resources to meet system requirements.
Performance Efficiency is the ability to use computing resources efficiently to meet system requirements and maintain efficiency as demand changes and technologies evolve.
Key Focus Areas:
This comprehensive section covers all aspects of designing high-performing architectures for the FCJ Midterm:
AWS Fargate is a serverless compute engine for containers that removes the need to manage EC2 instances.
ECS/EKS Cluster
├── Fargate Task 1 (0.5 vCPU, 1 GB RAM)
│ ├── Container 1: Web App
│ └── Container 2: Sidecar (logging)
├── Fargate Task 2 (1 vCPU, 2 GB RAM)
│ └── Container: API Service
└── Fargate Task 3 (4 vCPU, 8 GB RAM)
└── Container: Batch Processing
CPU Options (vCPU):
Memory (varies by CPU):
Networking:
Storage:
Performance:
Pricing (US East):
| Aspect | Fargate | EC2 |
|---|---|---|
| Management | Serverless, AWS manages | You manage EC2 instances |
| Pricing | Pay per task (vCPU + memory) | Pay for EC2 instances |
| Scaling | Automatic, instant | Manual or Auto Scaling Groups |
| Cost | Higher per task | Lower if fully utilized |
| Best For | Variable workloads, simplicity | Predictable, high utilization |
| Feature | AWS Fargate | AWS Lambda |
|---|---|---|
| Execution Time | No hard limit | 15 minutes maximum |
| Memory | Up to 120 GB | Up to 10 GB |
| CPU | Up to 16 vCPU | Up to 6 vCPU |
| Cold Start | 35s - 2 minutes | 100ms - 2 seconds |
| Warm Start | N/A (always running) | ~10ms |
| Default Storage | 20 GB (FREE) | 10 GB /tmp |
| Networking | Full VPC, ENI per task | VPC optional |
| Container Support | Full Docker support | Container images (10 GB max) |
| Pricing Model | Per second (vCPU + memory) | Per request + GB-second |
| Best For | Long-running containers | Event-driven, short tasks |
| Use Case | Microservices, APIs | Serverless functions |
✅ Use Fargate When:
❌ Don’t Use Fargate When:
AWS Lambda runs code without provisioning servers, automatically scaling based on demand.
Event Sources Lambda Functions Destinations
┌─────────────┐ ┌──────────────┐ ┌──────────────┐
│ API Gateway │──────────>│ Process HTTP │───────>│ RDS │
└─────────────┘ └──────────────┘ └──────────────┘
┌─────────────┐ ┌──────────────┐ ┌──────────────┐
│ S3 Events │──────────>│ Image Resize │───────>│ S3 │
└─────────────┘ └──────────────┘ └──────────────┘
┌─────────────┐ ┌──────────────┐ ┌──────────────┐
│ DynamoDB │──────────>│ Stream Proc │───────>│ SNS │
│ Streams │ └──────────────┘ └──────────────┘
└─────────────┘
┌─────────────┐ ┌──────────────┐ ┌──────────────┐
│ SQS Queue │──────────>│ Process Msgs │───────>│ DynamoDB │
└─────────────┘ └──────────────┘ └──────────────┘
┌─────────────┐ ┌──────────────┐ ┌──────────────┐
│ EventBridge │──────────>│ Scheduled │───────>│ CloudWatch │
│ (Cron) │ │ Backups │ │ Logs │
└─────────────┘ └──────────────┘ └──────────────┘
Hard Limits (cannot be changed):
Configurable:
Memory determines CPU allocation:
Lambda Power Tuning: Tool to find optimal memory/cost balance
Concurrency = Number of function instances running simultaneously
Types:
Cold Start vs Warm Start:
Reducing Cold Starts:
Free Tier (per month):
Pricing (US East):
Example Calculation:
Perfect For:
Not Ideal For:
┌─────────────────────────────────────────────────────────────┐
│ CloudWatch │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Metrics: │ │
│ │ • CPU Utilization: 85% ←─ Threshold: 70% │ │
│ │ • Request Count: 5000/min │ │
│ │ • Network In/Out │ │
│ └───────────────────────┬─────────────────────────────┘ │
└────────────────────────────┼───────────────────────────────┘
│ Alarm Triggered!
↓
┌─────────────────────────────────────────────────────────────┐
│ Auto Scaling Group │
│ Min: 2 │ Desired: 4 │ Max: 10 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Scaling Policy: Add 2 instances when CPU > 70% │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ EC2 │ │ EC2 │ │ EC2 │ │ EC2 │ │
│ │ Instance │ │ Instance │ │ Instance │ │ Instance │ │
│ │ #1 │ │ #2 │ │ #3 │ │ #4 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ ↑ ↑ ↑ NEW ↑ NEW │
└───────┼────────────┼─────────────┼─────────────┼───────────┘
│ │ │ │
└────────────┴─────────────┴─────────────┘
│
┌───────────▼────────────┐
│ Application Load │
│ Balancer │
└────────────────────────┘
Launch Template defines instance configuration for Auto Scaling:
{
"ImageId": "ami-0c55b159cbfafe1f0",
"InstanceType": "t3.medium",
"SecurityGroups": ["sg-0123456789abcdef0"],
"IamInstanceProfile": {
"Arn": "arn:aws:iam::123456789012:instance-profile/MyRole"
},
"UserData": "IyEvYmluL2Jhc2gKYXB0IHVwZGF0ZQo=",
"TagSpecifications": [{
"ResourceType": "instance",
"Tags": [{"Key": "Name", "Value": "AutoScaled"}]
}]
}
Components:
Example JSON:
{
"TargetValue": 70.0,
"PredefinedMetricType": "ASGAverageCPUUtilization",
"ScaleInCooldown": 300,
"ScaleOutCooldown": 60
}
How It Works:
Configuration:
Cooldown Period: 300 seconds (default) - prevent rapid scaling
Configuration:
Limitation: One adjustment at a time
EC2 Default Metrics (5-minute, free):
Detailed Monitoring (1-minute, $0.14/month per instance):
Custom Metrics:
Sending Custom Metrics:
aws cloudwatch put-metric-data \
--namespace "MyApp" \
--metric-name "ActiveUsers" \
--value 150
Lifecycle Hooks pause instance launch/termination for custom actions.
Use Cases:
Hook Types:
Timeout: Default 1 hour (configurable)
┌────────────────────────────────────────────────────────────┐
│ Data Sources │
├────────────────────────────────────────────────────────────┤
│ EC2: CPU, Network, Disk │
│ Lambda: Invocations, Duration, Errors │
│ RDS: Connections, CPU, IOPS │
│ ELB: Request Count, Latency, Errors │
│ Application Logs → CloudWatch Logs │
│ VPC Flow Logs → Network traffic analysis │
└──────────────────────────┬─────────────────────────────────┘
↓
┌────────────────────────────────────────────────────────────┐
│ CloudWatch │
├────────────────────────────────────────────────────────────┤
│ Metrics → Alarms → Actions │
│ ↓ ↓ ↓ │
│ Storage Threshold SNS, Auto Scaling, Lambda │
└──────────────────────────┬─────────────────────────────────┘
↓
┌────────────────────────────────────────────────────────────┐
│ Outputs & Actions │
├────────────────────────────────────────────────────────────┤
│ • Dashboards (visualize metrics) │
│ • Alarms (trigger actions) │
│ • Logs Insights (query logs) │
│ • EventBridge (event-driven automation) │
│ • S3 Export (long-term archival) │
└────────────────────────────────────────────────────────────┘
Standard Metrics (5-minute intervals, free):
Detailed Monitoring (1-minute intervals, paid):
Custom Metrics:
Log Groups: Container for log streams (e.g., /aws/lambda/my-function)
Log Streams: Sequence of log events from same source (e.g., instance ID)
Features:
Logs Insights Query Example:
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20
Alarm States:
Alarm Actions:
Composite Alarms: Combine multiple alarms (AND, OR)
Purpose: Visualize metrics in custom dashboards
Widget Types:
Sharing: Share dashboards publicly or within organization
Pricing: First 3 dashboards free, $3/month per dashboard after
| Service | Purpose | What It Monitors |
|---|---|---|
| CloudWatch | Performance monitoring | Metrics, logs, alarms |
| CloudTrail | Auditing API calls | Who did what, when |
| Config | Configuration compliance | Resource configs over time |
Use Together: CloudWatch (performance) + CloudTrail (security) + Config (compliance)