EC2, S3 Storage and IAM Security

1EC2 instance families

An EC2 instance is a resizable virtual server. AWS groups instance types into families whose letter codes map to a workload shape: T for burstable general use, M for balanced general purpose, C for compute-optimised, R and X for memory-optimised, and I or D for storage-optimised. The exam choice is driven by the vCPU-to-memory ratio the workload actually needs, not by a brand name on the instance.

Figure. Family letter encodes the bottleneck: compute, memory, storage, or balanced general purpose.

How to pick a family

1. Name the bottleneckIs the job CPU-bound, memory-bound, disk-bound, or mostly idle with occasional spikes?
2. Match the letterC for heavy compute, R/X for large in-memory working sets, I/D for high local I/O, T when the load is spiky and average utilisation is low.
3. Ignore the marketing nameAn in-memory database wants a memory-optimised family even if a cheaper burstable type could boot the OS.

2On-Demand, Reserved and Spot

How you pay for an EC2 instance is a separate choice from which family you run. On-Demand is the flexible default: start and stop at any time, pay by the second with no commitment. Standard Reserved Instances and Savings Plans trade a 1- or 3-year commitment for up to about 72% off On-Demand for steady baseline load. Spot Instances bid on spare capacity and can save up to about 90%, but AWS can reclaim the instance with short notice — so they fit only interruptible work such as batch jobs and CI.

Figure. On-Demand flexibility, commitment discounts, Spot interruption risk — pick by interrupt tolerance and steady load.

How the exam sorts purchase options

1. Can it die mid-run?If interruption is unacceptable, Spot is out — stay on On-Demand or a commitment discount.
2. Is the load steady for years?A 24/7 baseline that will still be there in a year earns Reserved Instances or Savings Plans.
3. Is cost the dominant constraint?Unpredictable, killable, cost-sensitive work — batch, CI, render farms — is the Spot cue.

3S3 as object storage

S3 is object storage, not a file system and not a block disk. You put objects into buckets; each object is addressed by a key. S3 Standard advertises 99.999999999% (eleven nines) durability and a 99.99% availability SLA, because objects are stored redundantly across multiple facilities. New buckets are private by default, and Block Public Access settings can override a permissive bucket policy — so "I added a public-read policy" is not enough if public access is still blocked. S3 now provides strong read-after-write consistency for PUT, GET, LIST and DELETE on all objects in all buckets.

Figure. S3 is object storage: bucket + key address opaque bytes with metadata — not a POSIX disk.

How S3 access actually opens

1. Private by defaultA new bucket denies public reads until you deliberately change identity or resource policies.
2. Policy alone may failBlock Public Access is an account/bucket safety net that can still deny even when a bucket policy allows.
3. Consistency is strongAfter a successful write, subsequent reads and listings see that write — you do not plan around eventual consistency for ordinary GET/PUT/LIST/DELETE.

4S3 storage classes and lifecycle

Storage classes trade cost against how often you read an object and how long retrieval may take. S3 Standard suits frequent access. S3 Standard-IA and One Zone-IA suit infrequent access with immediate retrieval, and they carry a 30-day minimum storage charge. Glacier Instant Retrieval, Glacier Flexible Retrieval and Glacier Deep Archive cover colder archives, with retrieval latency ranging from milliseconds to up to about twelve hours. Lifecycle rules transition objects one way toward colder tiers as access drops — you design the path when you create the rule, not by hoping objects warm themselves back to Standard.

Figure. Cheaper classes trade retrieval time and fees — match access frequency, not just $/GB.

How a cost-optimal log path is built

1. Hot windowKeep frequently read logs in S3 Standard for the first stretch of heavy access.
2. Warm, instantWhen reads become rare but must still be immediate, transition to Standard-IA (respecting the 30-day minimum).
3. Cold archiveWhen hours of retrieval are acceptable for compliance retention, transition to Glacier Flexible Retrieval, then expire at the retention limit.

5Object size and request-rate limits

A single S3 object can be up to 5 TB, but one PUT operation is capped at 5 GB — above roughly 100 MB you are expected to use multipart upload, and above 5 GB you must. Per partitioned prefix, S3 supports at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second. High request-rate designs spread keys across prefixes rather than hammering one hot key prefix.

Scalar service ceilings: single PUT object up to 5 TB (multipart), 3500 PUT/COPY/POST/DELETE and 5500 GET/HEAD per prefix per second as a performance guide. Bars inventing a continuous scale would fake a lesson the exam treats as memorised limits.

6IAM users, groups, roles and policies

IAM answers who can do what in an account. Users are long-lived identities for people (or occasionally applications that still use access keys). Groups bundle users so you attach policies once. Roles are identities meant to be assumed: they hand out temporary credentials from STS and are what EC2, Lambda and federated users should use. Policies are JSON documents that Allow or Deny actions on resources. The standing design rule is least privilege — grant only the actions and resources the task needs, never AdministratorAccess because it is convenient.

Figure. Identities (user/group/role) receive permissions only through policies — roles are assumed, not long-lived passwords.

How the four pieces fit

1. IdentityPick a user for a person with long-lived sign-in, or a role for anything that should only ever hold temporary credentials.
2. BundlePut users in groups and attach shared policies to the group rather than copying the same policy onto each user.
3. AuthoriseWrite a policy that names the actions and the resource ARNs; attach it to the user, group or role that needs them.

7IAM policy evaluation

Access is denied by default. An explicit Allow in an applicable identity-based or resource-based policy is what opens a path, and the effective permissions are the union of those policies — but any explicit Deny wins over every Allow. When a question shows both an Allow and a Deny that match the same action and resource, the answer is denied; options that claim the Allow still grants access are traps.

Figure. Explicit Deny wins; otherwise an Allow must appear or the default is Deny.

How a request is decided

1. Start at denyIf nothing Allow-matches the action and resource, the request is denied.
2. Collect AllowsIdentity-based and resource-based Allows combine — either source can grant.
3. Apply Deny lastA single matching explicit Deny cancels every Allow for that request.

8EC2 access to S3 via a role

When an application on EC2 must read an S3 bucket, the exam-correct pattern is never to embed access keys on the instance. Create an IAM role whose policy allows only the needed actions — typically s3:GetObject on that bucket ARN — attach the role to the instance through an instance profile, and let the SDK fetch temporary credentials from the instance metadata service. Scope the resource ARN to the exact bucket or prefix; a wildcard "*" fails least privilege even when the call would work.

Figure. The instance never holds long-lived keys. It assumes a role; the role is what S3 authorises for GetObject on the scoped bucket ARN.

How the secure path works

1. Role and policyCreate a role trusted by ec2.amazonaws.com with a policy that Allows only the required S3 actions on the specific bucket ARN.
2. Instance profileAttach that role to the EC2 instance so the instance identity is the role.
3. Temporary credentialsThe SDK reads rotating credentials from the instance metadata service — no long-lived keys on disk.

Least-privilege GetObject policy

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::logs-bucket/*"
  }]
}