What Is Serverless
Upload your code and the cloud automatically provides the execution environment. When there are no requests, the cost is zero. Servers still exist—developers just don't manage them.
Practical Lambda Example: Auto-Generating Image Thumbnails
import boto3
from PIL import Image
import io
def handler(event, context):
s3 = boto3.client('s3')
bucket = event['Records'][0]['s3']['bucket']['name']
key = event['Records'][0]['s3']['object']['key']
#
response = s3.get_object(Bucket=bucket, Key=key)
image = Image.open(io.BytesIO(response['Body'].read()))
# (200x200)
image.thumbnail((200, 200), Image.LANCZOS)
buffer = io.BytesIO()
image.save(buffer, format='JPEG', quality=85)
buffer.seek(0)
s3.put_object(
Bucket=bucket,
Key=f"thumbnails/{key}",
Body=buffer.getvalue(),
ContentType='image/jpeg'
)
return {'statusCode': 200}Lambda Deployment Configuration
# serverless.yml
provider:
name: aws
runtime: python3.12
architecture: arm64 # Graviton: 20%
memorySize: 512
timeout: 30
functions:
thumbnail:
handler: handler.handler
events:
- s3:
bucket: my-bucket
event: s3:ObjectCreated:*
rules:
- prefix: uploads/
- suffix: .jpgCold Start Optimization
Cold Start when:
- Python 3.12: ~300ms
- Node.js 20: ~200ms
- Go 1.21: ~50ms#
s3 = boto3.client('s3') # 1
def handler(event, context):
response = s3.get_object(...) ## Provisioned Concurrency Cold Start
functions:
api:
provisionedConcurrency: 5 # 5Assessing Serverless Fit
Suitable workloads:
- Event-driven processing (file uploads, message queues)
- Irregular traffic (APIs with peaks)
- Batch/scheduled jobs (cron)
Unsuitable workloads:
- Long-running work over 15 minutes
- Extremely low latency (<10ms)
- GPU-intensive compute
Cost Comparison
| Approach | Cost for 1M requests/month |
|---|---|
| Lambda | ~$10 |
| ECS Fargate (always-on) | ~$45 |
| EC2 t3.micro (always-on) | ~$9 (fixed) |
When traffic is irregular, Lambda is dramatically cheaper. Under 24/7 high load, EC2/ECS is more cost-effective.
Serverless aims for "infrastructure management time = 0." Start small and expand gradually.
Diagnosing Serverless Timeouts and Throttling
Many serverless incidents in production are limits and connection management, not code bugs.
Causes
- The function timeout is shorter than the response time of external APIs or DBs it calls
- Account- or function-level concurrency limits are hit, causing throttles
- Every invocation opens a new DB connection, exhausting the DB's max connections
Verification (AWS Lambda example)
# account concurrency limit and function settings
aws lambda get-account-settings --query 'AccountLimit.ConcurrentExecutions'
aws lambda get-function-configuration --function-name thumb --query '{timeout:Timeout,mem:MemorySize}'
# throttles over the last hour
aws cloudwatch get-metric-statistics --namespace AWS/Lambda --metric-name Throttles \
--dimensions Name=FunctionName,Value=thumb --statistics Sum --period 300 \
--start-time $(date -u -d '-1 hour' +%FT%TZ) --end-time $(date -u +%FT%TZ)
# timeout log lines
aws logs filter-log-events --log-group-name /aws/lambda/thumb --filter-pattern '"Task timed out"'(On macOS the date option differs: date -u -v-1H +%FT%TZ.)
Fix
- Set the function timeout longer than downstream timeouts, and give downstream calls explicit timeouts and retry caps.
- Protect critical functions with reserved concurrency, and put a queue (SQS) in front of async invocations to absorb spikes.
- Reuse DB connections outside the handler or use a pool such as RDS Proxy.
Prevention
- Alert on Throttles, Errors, and Duration p99, and request a limit increase early when concurrency usage approaches the limit.
Sources and checks vary by article. Only articles with a recorded check date, scope and sources below were checked, and only within that scope. For other articles, verify against the current docs for your version before applying anything, and email us about errors. Editorial policy · email us
This article has no recorded human check (date and scope) yet.
Comments
Be the first to comment.