AWS’s service catalog is genuinely overwhelming if you try to learn it exhaustively, but the reality of day-to-day DevOps work is that a fairly small, stable set of services accounts for the overwhelming majority of real usage: compute, storage, networking, identity, databases, and monitoring. This guide focuses specifically on that working set, how each service fits into a real production architecture, and the identity and access management practices that matter more for security than almost anything else on this list.

Beyond the individual services, this guide also covers the patterns that separate a toy setup from something resembling real production architecture: load balancing and auto scaling for handling variable traffic reliably, structuring multiple accounts to isolate environments from each other, provisioning everything as version-controlled infrastructure as code rather than manual console clicks, and the cost-control habits that prevent the unpleasant surprise of an unexpectedly large monthly bill.

The Core Services You’ll Use Constantly

IAM: Get This Right Before Anything Else

IAM controls every permission boundary in your AWS account, and getting it wrong is the single most common source of real security incidents in cloud environments, not exotic zero-day exploits. The core principle is least privilege: every user, role, and service should have exactly the permissions it needs to do its job, and nothing more.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-uploads/*"
    }
  ]
}

This policy grants read and write access to objects in one specific S3 bucket, nothing more, no access to other buckets, no ability to delete the bucket itself, no access to any other AWS service. Scoping every policy this tightly, rather than reaching for broad managed policies like AdministratorAccess out of convenience, is the practical foundation of AWS security.

Just as important: use IAM roles, not long-lived access keys, wherever possible. An EC2 instance or Lambda function should assume a role granting it exactly the permissions it needs, with temporary credentials AWS rotates automatically, rather than having a permanent access key embedded in configuration somewhere it could leak. This is the cloud equivalent of the credential-handling discipline covered in our Git and GitHub guide: never a long-lived secret where a short-lived, automatically rotated one will do.

Compute Options: Choosing the Right One

EC2 gives you full virtual machines, maximum control, but you’re responsible for patching, scaling, and managing the underlying servers yourself. ECS and EKS run containers, covered in depth in our Docker and Kubernetes guides, with AWS managing more of the underlying infrastructure. Lambda runs individual functions in response to events with no server to manage at all, ideal for short-lived, event-driven workloads but a poor fit for long-running processes.

aws ec2 run-instances --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro --key-name my-key \
  --security-group-ids sg-0123456789

aws ec2 describe-instances --filters "Name=tag:Environment,Values=production"

The general pattern for choosing: reach for Lambda first for short, event-driven tasks; ECS or EKS for containerized applications that need to run continuously; and EC2 directly only when you need something neither of those provides, like specific OS-level control or software that doesn’t containerize cleanly.

Networking With VPC

A VPC is your isolated network within AWS, subdivided into subnets, typically public (reachable from the internet) and private (not directly reachable, for databases and internal services). Security groups act as a virtual firewall controlling exactly what traffic can reach a given resource, and getting this configuration right is central to keeping a production environment secure.

aws ec2 create-security-group --group-name web-sg \
  --description "Allow HTTP/HTTPS" --vpc-id vpc-0123456789

aws ec2 authorize-security-group-ingress --group-id sg-0123456789 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

A common, sound architecture pattern: public subnets host only load balancers and NAT gateways, while application servers and databases live in private subnets, reachable only from inside the VPC. This means even a misconfigured security group on an internal service doesn’t directly expose it to the public internet, since it’s not routable from outside in the first place.

Storage: S3 and EBS

S3 stores objects, files, backups, static website assets, and famously, Terraform remote state, at effectively unlimited scale with very high durability. EBS provides block storage attached to a specific EC2 instance, more like a traditional hard drive, used for a running server’s own filesystem rather than object storage. Choosing the right one matters: application code and database data typically live on EBS attached to a running instance, while backups, logs, and static assets belong in S3.

aws s3 cp ./build s3://my-app-static/ --recursive
aws s3api put-bucket-versioning --bucket my-app-static \
  --versioning-configuration Status=Enabled

Enabling versioning on any S3 bucket holding important data is a cheap, high-value safety net: it protects against accidental deletion or overwrite by keeping every previous version recoverable, at a modest additional storage cost.

Managed Databases With RDS

RDS runs a real Postgres, MySQL, or other relational database engine, but handles the operational burden, automated backups, patching, failover, that you’d otherwise manage yourself on a self-hosted database server. For most production workloads, RDS (or an equivalent managed database) is the sensible default over self-managing a database on EC2, since the operational savings outweigh the modest cost premium in almost every realistic scenario.

Monitoring With CloudWatch

CloudWatch collects metrics and logs from nearly every AWS service automatically, and lets you set alarms that trigger notifications, or even automated actions, when a metric crosses a threshold.

aws cloudwatch put-metric-alarm \
  --alarm-name high-cpu \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2

This alarm fires when average CPU utilization exceeds 80% for two consecutive 5-minute periods, which could trigger an SNS notification, an autoscaling action, or feed into the broader monitoring practices covered in our monitoring and observability guide.

Load Balancing and Auto Scaling

Real production traffic rarely fits on a single instance reliably, and a single instance is also a single point of failure. An Application Load Balancer (ALB) distributes incoming traffic across multiple targets, health-checking each one and automatically routing around any that stop responding. Paired with an Auto Scaling Group, AWS can automatically add or remove EC2 instances based on demand, the same conceptual pattern as the Horizontal Pod Autoscaler covered in our Kubernetes guide, applied at the EC2 layer instead of inside a cluster.

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template LaunchTemplateName=web-template \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --target-group-arns arn:aws:elasticloadbalancing:...:targetgroup/web-tg

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name scale-on-cpu \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{"TargetValue":70,"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"}}'

This configuration keeps between 2 and 10 instances running behind the load balancer, automatically launching new instances when average CPU crosses 70% and terminating them again once demand drops, so the application scales with real traffic instead of running permanently provisioned for peak load (which wastes money) or permanently provisioned for average load (which fails under a spike).

Structuring Multiple AWS Accounts

A single AWS account holding everything, personal experiments, staging, and production, together is a common early setup but a real liability as an organization grows. Most mature AWS setups use AWS Organizations to run separate accounts per environment (or per team), with centralized billing and identity, but strict isolation between them. This means a misconfigured staging resource, or a compromised staging credential, has no path to touch production at all, since the accounts are fully separate AWS environments rather than logically separated resources within one account.

Cross-account access, when genuinely needed, goes through IAM roles with explicit trust relationships rather than shared credentials, meaning access can be granted narrowly and audited clearly through CloudTrail, rather than relying on broadly shared account-level credentials that are much harder to reason about or revoke selectively.

Provisioning AWS as Code

While the CLI commands above work for quick tasks and learning, production AWS infrastructure is almost always provisioned through infrastructure as code rather than manual CLI commands or clicking through the console. Terraform, covered in depth on our Terraform page, is the most widely used tool for this, letting you declare your entire AWS architecture, VPCs, EC2 instances, IAM roles, RDS databases, as version-controlled configuration that’s reviewed, applied consistently, and fully auditable.

Keeping Costs Under Control

Unmanaged AWS costs are one of the most common operational surprises for teams new to cloud infrastructure. A handful of habits prevent most cost overruns: tag every resource with an owner and environment so spend is attributable, set up AWS Budgets with alert thresholds so unexpected spend surfaces immediately rather than at the end of the month, right-size EC2 instances based on actual utilization rather than guessing generously, and clean up unattached EBS volumes and unused Elastic IPs, both of which quietly accrue charges even when not actively used.

How This Connects to the Rest of DevOps

AWS is where most of the other topics in this curriculum actually run in production: Docker images deploy to ECS or EKS, Kubernetes clusters run on EKS, CI/CD pipelines deploy to EC2 or Lambda, and Terraform is how nearly all of it gets provisioned and version-controlled. Comfort with the core services covered here is close to a prerequisite for putting the rest of this curriculum into practice on real infrastructure.

Frequently Asked Questions

If you’re building toward a DevOps role specifically, the highest-value use of study time is standing up a real, small production-like architecture yourself: a VPC with public and private subnets, an EC2 instance or two behind a load balancer, an RDS database in a private subnet, and IAM roles scoped correctly rather than using your root account credentials for everything. Getting that working end to end, and understanding why each piece is configured the way it is, builds far more real interview-ready knowledge than reading service documentation without ever provisioning anything yourself.

Related reading: continue to DevSecOps fundamentals, review the full AWS certifications guide, or explore Terraform for provisioning AWS infrastructure as code.