Serverless and containers

Key points

• Memory and CPU: 128 MB to 10,240 MB in 1 MB steps. CPU is allocated in proportion to memory, and 1,769 MB equals 1 vCPU. More memory is the main lever for CPU-bound or network-bound functions.
• Timeout: up to 900 seconds (15 minutes) per invocation.
• Payloads: 6 MB for synchronous request and response, 1 MB for asynchronous events. Environment variables total 4 KB.
• Packaging: .zip up to 50 MB zipped and 250 MB unzipped with layers, or a container image up to 10 GB. /tmp from 512 MB to 10,240 MB.
• Layers: up to 5 per function, extracted to /opt, to share libraries across functions. Only for .zip functions, not container images.
• Tuning: AWS Lambda Power Tuning and AWS Compute Optimizer help pick the memory setting.

Key points

• Reserved concurrency: a slice of the pool that is both the guaranteed minimum and the maximum for the function. Protects critical functions or caps one that would overload a downstream resource. No charge.
• Provisioned concurrency: pre-initialized execution environments that answer without cold starts. Extra charge, and it can follow a schedule or utilization through Application Auto Scaling.
• Limits: each function scales by up to 1,000 execution environments every 10 seconds. Lambda keeps 100 units unreserved, so 900 of the default 1,000 can be reserved. Requests per second are capped at 10 times the concurrency.
• SnapStart: snapshots the initialized environment when a version is published and resumes from it, with startup as low as sub-second. Java 11+, Python 3.12+ and .NET 8+. Free on Java, caching and restore charges on the others.
• SnapStart limits: published versions only, and no combination with provisioned concurrency, EFS or /tmp above 512 MB.

Key points

• Triggers (push): S3, SNS, API Gateway and others invoke the function as soon as the event happens. The trigger is configured and stored on the source service.
• Event source mappings (poll): Lambda pollers read SQS, Kinesis, DynamoDB, Amazon MSK, self-managed Kafka, Amazon MQ and DocumentDB and invoke the function with batches of records.
• Batching: a batch closes at the batch size, at the batching window (0 to 300 seconds) or at 6 MB of payload. Larger batches spread the invoke overhead and raise throughput.
• At least once: mappings can process a record more than once, so make the handler idempotent. On error, stream batches are retried and the shard pauses to keep order.
• Provisioned mode: dedicated pollers with a minimum and maximum for SQS, Amazon MSK and Kafka mappings, when latency must stay consistent. Extra charge.

Key points

• Amazon ECS: AWS-native orchestrator with no control plane to run. A task definition is the blueprint, a task runs it, and a service keeps the desired number of tasks running.
• Amazon EKS: managed, certified Kubernetes-conformant control plane. Reuses Kubernetes manifests, tools and skills, and keeps workloads portable.
• EKS Auto Mode: AWS also manages the nodes, including provisioning, instance selection, scaling and OS patching.
• Scaling: ECS Service Auto Scaling changes the number of tasks, and Cluster Auto Scaling changes the EC2 instances registered to the cluster.
• Cost: ECS orchestration has no additional charge. EKS adds a per-cluster charge on top of the compute.

Key points

• Fargate: you set CPU and memory per task, and each task has its own isolation boundary with no shared kernel, CPU, memory or network interface. Billed per second for vCPU, memory and storage, with a 1-minute minimum on Linux.
• Task sizes: from 0.25 vCPU with 512 MiB up to 32 vCPU with 244 GB on Linux. 20 GB of ephemeral storage is included.
• Networking: always awsvpc mode with one network interface per task, so load balancer target groups use the ip target type.
• Fargate Spot: up to 70% off for interruption-tolerant ECS tasks, with a 2-minute warning. Linux only.
• EC2 launch type: you manage instances, AMIs and cluster capacity, and in return get GPUs, privileged containers and any instance type, none of which Fargate supports.

Key points

• Registry: private repositories with IAM resource-based permissions, plus ECR Public. Docker images, OCI images and OCI artifacts.
• Image scanning: scan on push to find software vulnerabilities in each new image.
• Lifecycle policies: rules that clean up unused images, testable before they apply.
• Replication and cache: cross-Region and cross-account replication, and pull through cache rules that keep upstream images in your private registry.
• Containerizing: package the app and its dependencies in an image, push it to ECR, describe it in a task definition or pod spec, and run it on Fargate or EC2. The same image runs the same way in every environment.
• Private pulls: tasks in private subnets pull from ECR through an interface VPC endpoint instead of a NAT gateway.

Key points

• ECS Anywhere: registers on-premises servers or VMs as external instances of an ECS cluster (EXTERNAL launch type) through the SSM Agent. Charged per registered instance per hour.
• ECS Anywhere limits: no load balancing, no service discovery, no awsvpc mode and no EFS volumes. Best for workloads that generate outbound traffic or process data.
• EKS Anywhere: creates and operates Kubernetes clusters on your own infrastructure (VMware vSphere, bare metal, Nutanix, AWS Snow), even air-gapped. Open source and free, with optional Enterprise Subscriptions.
• EKS Distro: the Kubernetes distribution used by Amazon EKS and the base of EKS Anywhere.
• EKS Hybrid Nodes: on-premises and edge servers joined as nodes of an Amazon EKS cluster.

Key points

• Lambda: event-driven or unpredictable traffic, tasks under 15 minutes, pay per request and duration, no OS or runtime to manage.
• Fargate: long-running services or jobs in containers with no servers to manage, any language or binary inside the image.
• ECS or EKS on EC2: GPUs, specific instance types, privileged access or full control of the hosts.
• Decoupling: put SQS, SNS or EventBridge between components so each tier scales independently on its own metric.
• AWS Serverless Application Repository: publish and deploy reusable serverless applications defined with AWS SAM templates, shared publicly or with specific accounts. No charge beyond the deployed resources.