AWS for Developers: Understanding EC2, S3, RDS and IAM

AWS has hundreds of services, but most backend applications start with four: EC2 for compute, S3 for file storage, RDS for relational databases and IAM for permissions. Understanding these well gives you a mental model that transfers to the rest of the platform — and to other cloud providers, which offer close equivalents.

EC2: virtual machines you control

EC2 (Elastic Compute Cloud) gives you virtual servers, called instances. You choose an operating system image (an AMI), an instance type (CPU and memory), storage and networking, and you are responsible for everything that runs on it.

Key ideas:

• Instance types are grouped into families. General-purpose types suit most web applications; compute-optimised and memory-optimised types exist for specialised workloads.
• Security groups act as a virtual firewall. Open only the ports you need — typically 443 (and 80 to redirect to 443) from the internet, and SSH only from your own IP or, better, not at all by using a session manager.
• Auto Scaling groups start and stop identical instances based on load, behind a load balancer that spreads traffic across them.

EC2 is flexible, but you also own patching, monitoring and scaling. Many teams move to containers (ECS, EKS) or serverless (Lambda) later to hand some of that work to AWS.

S3: durable object storage

S3 (Simple Storage Service) stores files — called objects — in buckets. It is designed for very high durability and scales without you provisioning capacity. Typical uses include user uploads, static assets, backups, logs and data exports.

A few things developers should know:

• S3 is not a filesystem. You put and get whole objects by key, for example avatars/42.webp.
• Buckets should be private by default. Block Public Access is enabled on new buckets; keep it that way unless you deliberately host public content, ideally behind a CDN.
• Give users temporary access to private files with pre-signed URLs instead of making objects public.

import boto3

s3 = boto3.client("s3")
url = s3.generate_presigned_url(
    "get_object",
    Params={"Bucket": "my-app-uploads", "Key": "invoices/2026/0001.pdf"},
    ExpiresIn=300,  # seconds
)

• Lifecycle rules can move old objects to cheaper storage classes or delete them automatically.

RDS: managed relational databases

RDS (Relational Database Service) runs databases such as PostgreSQL and MySQL for you. AWS handles provisioning, automated backups, minor version patching and optional replication. You still design the schema, write efficient queries and choose the right instance size.

Production-minded settings:

1. Put the database in private subnets — it should not be reachable from the internet.
2. Allow connections only from your application’s security group.
3. Enable automated backups and test restoring one before you need it.
4. Consider Multi-AZ for failover in production workloads.
5. Store credentials in a secrets manager and rotate them.

IAM: who can do what

IAM (Identity and Access Management) controls permissions for people and software. It is the service beginners skip — and the one that matters most for security.

The core pieces:

• Users and groups for people (prefer single sign-on for teams).
• Roles for software. An EC2 instance, a Lambda function or a CI pipeline assumes a role and receives short-lived credentials automatically.
• Policies are JSON documents that allow or deny actions on resources.

Here is a least-privilege policy that lets an application read and write only one prefix in one bucket:

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

• Never use the root account for daily work; protect it with MFA.
• Never put long-lived access keys in code or commit them to Git.
• Attach roles to compute resources instead of copying keys onto servers.
• Grant the minimum actions and resources, then widen only when needed.

How they fit together

A typical small application looks like this: users reach a load balancer, which forwards traffic to EC2 instances (or containers) in an auto-scaling group. The application reads and writes data in RDS in private subnets, stores uploads in a private S3 bucket and serves them through pre-signed URLs. Every component gets its permissions through IAM roles, not stored keys.

Service	You manage	AWS manages
EC2	OS, runtime, app, patches, scaling rules	Hardware, virtualisation
S3	Bucket policies, object keys, lifecycle	Storage, durability, scaling
RDS	Schema, queries, sizing, access	Provisioning, backups, patching
IAM	Policies and roles	The permission engine

Learn these four properly and the rest of AWS becomes a matter of looking up which managed service replaces a piece of this picture.