The foundational compute service is EC2, whose instance types are grouped by workload into families such as General Purpose (M, T), Compute Optimized (C), Memory Optimized (R, X), Storage Optimized (I, D), Accelerated Computing (P, G, F), and HPC Optimized (H). To launch an EC2 instance you need an AMI, an instance type, a VPC with a subnet, a security group, an IAM role or credentials, and optionally a key pair and an EBS volume. Where instances are placed is controlled by placement groups: cluster placement groups give the lowest latency in a single AZ, spread groups place instances on distinct hardware (up to 7 per AZ), and partition groups separate instances by rack (up to 7 partitions per AZ), useful for Hadoop and Kafka workloads.
A few lifecycle features help with EC2 operations. EC2 user data lets you pass a bootstrap script that runs on first boot (limited to 16 KB), and is useful for installing software and registering with services. Instance metadata, accessible at the IMDS endpoint 169.254.169.254, exposes instance-specific data including IAM role credentials, and IMDSv2 tightens security by requiring a session-token PUT before any metadata request, mitigating SSRF attacks. Hibernation persists RAM contents to the EBS root volume and lets you skip cold starts when re-launching.
EC2 instances are auto-managed through Auto Scaling groups that define min, max, and desired capacity. Target tracking scaling, the recommended policy type, adjusts capacity to keep a chosen CloudWatch metric such as CPUUtilization near a target value. Configuration is captured in an EC2 launch template, which holds AMI, instance type, key pair, security groups, IAM instance profile, user data, tags, and market options, can have multiple versions, and is the source of truth for Auto Scaling groups and Spot Fleets.
For containers, AWS provides ECS, EKS, and Fargate. ECS is a fully managed Docker orchestrator with EC2 (you manage the instances) and Fargate (serverless) launch types. EKS is managed Kubernetes where AWS runs the control plane across AZs and you supply EC2 or Fargate worker nodes. Fargate itself is the serverless compute engine for both ECS and EKS, charging per vCPU and GB-hour and removing infrastructure management entirely. A typical CI/CD pipeline on AWS is built from CodeCommit for source control, CodeBuild for build and test, CodeDeploy for release, and CodePipeline for orchestration, each swappable with third-party tools like GitHub, Jenkins, GitLab, or Spinnaker. CodeDeploy automates application deployments to EC2, ECS, Lambda, and on-premises servers via an appspec.yml file, supporting both in-place and blue/green deployments. A blue/green strategy runs two identical environments side by side, with blue holding the current version and green holding the new, then shifts traffic from blue to green via the ALB, Route 53 weighted records, or DNS, allowing instant rollback. CodePipeline models the release itself: each stage contains actions such as source, build, test, or deploy, can include manual approval steps, and triggers Lambda functions on state changes.