AWS core services

In short

Amazon Web Services (AWS) is a public cloud platform that rents compute, storage, networking, databases and managed services on demand, billed by the second or by usage. A handful of "core" services — EC2, S3, VPC, IAM, RDS/DynamoDB, Lambda, ELB with Auto Scaling, CloudWatch and Route 53 — account for most real architectures and almost all interview questions. In India it is examined in cloud computing electives (AICTE/CBCS, usually with a lab on launching EC2 and hosting on S3) and is asked in placement rounds at Infosys, TCS, Wipro, Accenture, Cognizant, Amazon, Flipkart, Zomato, Paytm, Razorpay, Zoho and almost every startup. AWS runs two Indian regions — Mumbai (ap-south-1) and Hyderabad (ap-south-2) — which matter because RBI, SEBI, IRDAI and the DPDP Act, 2023 constrain where Indian data may sit. Prices quoted below are indicative; AWS rates change, so always confirm on the current pricing page.

Explained

Global infrastructure, the shared responsibility model and account basics

• Region: a geographic cluster of data centres with its own API endpoint, e.g. ap-south-1 (Mumbai, since 2016) and ap-south-2 (Hyderabad, since Nov 2022). Regions are isolated — data does not leave a region unless you move it.
• Availability Zone (AZ): one or more physically separate data centres inside a region, with independent power and cooling but low-latency links (single-digit milliseconds). Mumbai and Hyderabad each have three AZs. Spreading across AZs survives a data-centre failure; spreading across regions survives a regional failure.
• Edge locations / Local Zones: CloudFront points of presence in several Indian cities (Mumbai, Delhi, Chennai, Bengaluru, Hyderabad, Kolkata) for content delivery; an AWS Local Zone in Delhi puts compute closer to users.
• Service scope: global (IAM, Route 53, CloudFront, S3 bucket namespace), regional (S3 data, DynamoDB, Lambda, VPC), or zonal (EC2 instance, EBS volume, subnet).
• Shared responsibility model: AWS is responsible for security of the cloud (hardware, hypervisor, physical access, managed service patching); the customer is responsible for security in the cloud (IAM policies, OS patching on EC2, security groups, encryption choices, application code, data classification).
• Well-Architected Framework — six pillars: operational excellence, security, reliability, performance efficiency, cost optimisation, sustainability. Quoted constantly in design interviews.
• Account structure: AWS Organizations for multiple accounts (separate prod/dev/test), Service Control Policies as guardrails, consolidated billing, tags for cost allocation, Budgets and Cost Explorer for control.

IAM, encryption and security services

• IAM principals: *users* (long-term credentials — avoid for workloads), *groups* (collections of users), *roles* (temporary credentials assumed by services, EC2 instances via an instance profile, or federated users), *policies* (JSON documents).
• Policy evaluation: an explicit Deny always wins; otherwise an explicit Allow is needed; anything not allowed is implicitly denied. Identity-based policies attach to users/roles; resource-based policies (S3 bucket policy, KMS key policy) attach to the resource.
• Root user: used only for account setup — enable MFA, create an admin IAM identity, then lock it away. Least privilege is the governing principle; IAM Access Analyzer and Access Advisor help trim permissions.
• AWS STS issues short-lived credentials (AssumeRole); IAM Identity Center federates corporate logins (SAML/Entra ID).
• KMS manages encryption keys (AWS-managed, customer-managed, envelope encryption); Secrets Manager and SSM Parameter Store hold DB passwords and API keys instead of hardcoding them; Certificate Manager (ACM) issues free TLS certificates for ALB/CloudFront.
• Detective and preventive services: CloudTrail (API audit log), AWS Config (configuration compliance), GuardDuty (threat detection), WAF and Shield (web exploits and DDoS), Inspector (vulnerability scanning), Security Hub (aggregation).

Compute: EC2, Auto Scaling, load balancing, serverless and containers

• EC2 (Elastic Compute Cloud): virtual machines. Launched from an AMI (machine image), sized by instance type — family letter + generation + size, e.g. t3.medium: t burstable, m general purpose, c compute-optimised, r/x memory-optimised, i/d storage-optimised, g/p GPU-accelerated, inf/trn purpose-built ML accelerators.
• Access and bootstrap: key pair for SSH (or Session Manager, which needs no open port), user data script to install software on first boot, security group as the instance firewall, Elastic IP for a fixed public address.
• Purchase options: On-Demand (per-second, no commitment); Reserved Instances / Savings Plans (1 or 3-year commitment, roughly 30–70% cheaper); Spot (spare capacity up to ~90% cheaper, reclaimed with a 2-minute warning — use for batch, CI, rendering, never for a stateful single server); Dedicated Hosts/Instances for licensing or isolation.
• Elastic Load Balancing: ALB (Layer 7 — HTTP/HTTPS, path and host routing, target groups, WebSockets), NLB (Layer 4 — TCP/UDP, static IP, very high throughput, low latency), GWLB (inline security appliances). Health checks remove unhealthy targets; cross-zone load balancing spreads traffic across AZs.
• Auto Scaling Group (ASG): maintains desired capacity between min and max across multiple AZs, replaces failed instances, uses a launch template. Policies: target tracking (keep average CPU at 50%), step scaling, simple scaling, scheduled scaling, predictive scaling. Warm-up and cooldown prevent thrashing.
• AWS Lambda (serverless): upload a function; AWS runs it on an event (API Gateway request, S3 object created, SQS message, EventBridge schedule) and bills per request and per GB-second. Limits: up to 15 minutes timeout, 128 MB–10 GB memory (vCPU scales with memory), 512 MB–10 GB /tmp, 50 MB zipped / 250 MB unzipped deployment package or a 10 GB container image. Cold start is the first-invocation latency; provisioned concurrency removes it.
• Containers: ECS (AWS's own orchestrator), EKS (managed Kubernetes), ECR (image registry), Fargate (serverless container runtime — no EC2 to manage). App Runner and Elastic Beanstalk are higher-level, opinionated deployment services.

Storage: S3, EBS, EFS and archival

• S3 (Simple Storage Service): object storage in buckets; globally unique bucket name, object key, up to 50 TB per object (raised from 5 TB in December 2025), 11 nines (99.999999999%) durability by replicating across at least three AZs. Not a filesystem — no partial in-place edit of an object.
• S3 storage classes: Standard; Intelligent-Tiering (auto-moves by access pattern); Standard-IA and One Zone-IA (cheaper storage, retrieval fee, 30-day minimum); Glacier Instant Retrieval, Glacier Flexible Retrieval (minutes to hours), Glacier Deep Archive (cheapest, ~12 h restore, 180-day minimum). Lifecycle rules transition and expire objects automatically.
• S3 features: versioning (protects against overwrite/delete), Object Lock (WORM, for audit retention), encryption (SSE-S3 default, SSE-KMS, SSE-C), Block Public Access (on by default), bucket policies, pre-signed URLs for temporary private access, static website hosting, event notifications, Cross-Region Replication, Transfer Acceleration, multipart upload for large files.
• EBS (Elastic Block Store): network-attached block volumes for a single EC2 instance in the same AZ (io1/io2 support multi-attach). Types: gp3 (SSD, baseline 3,000 IOPS and 125 MB/s, IOPS and throughput configurable independently — the modern default), gp2 (legacy, 3 IOPS/GB), io1/io2 (provisioned IOPS for databases), st1 (throughput HDD, big sequential files), sc1 (cold HDD). Snapshots are incremental and stored in S3; a volume can be resized live.
• Instance store: physically attached NVMe, very fast, ephemeral — data is lost on stop or termination. Use for cache and scratch only.
• EFS is an elastic NFS filesystem shared by many instances across AZs; FSx provides Windows (SMB) and Lustre (HPC) filesystems. S3 for objects, EBS for a boot/DB disk, EFS for shared POSIX files — the classic exam comparison.
• Backup and transfer: AWS Backup (central policy), Storage Gateway (hybrid), DataSync (bulk online transfer), Snowball (offline petabyte transfer).

Databases and data services

• RDS (Relational Database Service): managed MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and Aurora (AWS's MySQL/PostgreSQL-compatible engine, storage auto-grows, up to 15 low-lag read replicas). AWS handles patching, backups and failover; you still design the schema and indexes.
• Multi-AZ vs read replica: Multi-AZ is a synchronous standby in another AZ for high availability (automatic failover, same endpoint, not readable in the classic deployment); a read replica is asynchronous and exists to scale reads — mixing these up is the most common RDS interview error.
• Backups: automated backups with point-in-time recovery, retention 1–35 days; manual snapshots persist until deleted. Parameter groups tune engine settings; RDS Proxy pools connections for Lambda-heavy workloads.
• DynamoDB: managed key-value/document NoSQL. Partition key (hash) decides placement; optional sort key gives a composite primary key. Single-digit-millisecond latency at any scale. Capacity: on-demand (pay per request) or provisioned RCU/WCU with auto scaling. GSI (different partition key, eventually consistent) and LSI (same partition key, different sort key, created only at table creation). DynamoDB Streams for change capture; TTL for auto-expiry; DAX for microsecond caching.
• Other data services: ElastiCache (Redis/Memcached), Redshift (petabyte data warehouse, columnar), Athena (SQL directly on S3 with Glue Data Catalog), EMR (Spark/Hadoop), Kinesis and MSK (streaming), OpenSearch (search and log analytics), QuickSight (BI).

Networking: VPC, Route 53 and connectivity

• VPC (Virtual Private Cloud): your own logically isolated network with a CIDR block (e.g. 10.0.0.0/16). Divided into subnets, each pinned to one AZ. A public subnet has a route to an Internet Gateway; a private subnet reaches out through a NAT Gateway sitting in a public subnet. AWS reserves 5 IP addresses in every subnet.
• Security group vs NACL: a security group is stateful, attached to an ENI/instance, allow-rules only (no deny); a network ACL is stateless (return traffic needs its own rule), attached to a subnet, supports allow and deny, evaluated by rule number. Both are asked in nearly every cloud interview.
• VPC endpoints: Gateway endpoints (S3, DynamoDB — free, route-table based) and Interface endpoints / PrivateLink (ENI in your subnet, hourly + data charge) let private subnets reach AWS services without a NAT Gateway or internet.
• Connecting networks: VPC peering (non-transitive, no overlapping CIDRs), Transit Gateway (hub for many VPCs and on-premises), Site-to-Site VPN over the internet, Direct Connect for dedicated private bandwidth (used by Indian banks and large enterprises for RBI-grade connectivity).
• Route 53: DNS plus domain registration and health checks. Record types A, AAAA, CNAME, MX, TXT, NS and the AWS-specific Alias record (points at an ALB, CloudFront or S3 website at the zone apex, where CNAME is illegal, and is free to query). Routing policies: simple, weighted (canary/blue-green), latency-based, failover (DR), geolocation, geoproximity, multivalue answer.
• Delivery and edge: CloudFront caches content at edge locations with Origin Access Control to keep the S3 bucket private; Global Accelerator gives anycast IPs for TCP/UDP.

Monitoring, automation, cost and Indian compliance

• CloudWatch: metrics (EC2 basic monitoring every 5 minutes, detailed monitoring every 1 minute), Logs (via the CloudWatch agent — memory and disk usage are not collected by default), alarms (trigger ASG scaling or SNS notification), dashboards, Logs Insights for queries, synthetic canaries. CloudTrail records who called which API — audit; CloudWatch records how the system performed — telemetry.
• Automation: CloudFormation and CDK for infrastructure as code (Terraform is the common third-party alternative), Systems Manager (patching, Session Manager, Run Command), CodeBuild/CodeDeploy/CodePipeline for CI-CD, Step Functions for orchestration, EventBridge for event routing.
• Messaging: SQS (decoupling queue — standard at-least-once or FIFO exactly-once; visibility timeout and dead-letter queue) and SNS (pub-sub fan-out to email, SMS, Lambda, SQS).
• Cost levers: right-size instances, use Savings Plans for steady load and Spot for interruptible work, set lifecycle rules on S3, delete unattached EBS volumes and idle Elastic IPs, prefer gateway endpoints over NAT Gateways, keep traffic inside an AZ (cross-AZ transfer is charged), and remember data transfer out to the internet is charged while inbound is free. The always-free tier includes 1 million Lambda requests, 400,000 GB-seconds, 25 GB of DynamoDB storage with 25 RCU/25 WCU, and 100 GB/month outbound data; the 12-month trial (750 h of t2/t3.micro, 5 GB S3, 750 h of db.t3.micro RDS) applies only to accounts opened before 15 July 2025 — newer accounts instead get sign-up credits under the Free Plan.
• Indian regulation that drives design choices: the RBI directive of April 2018 requires payment system data to be stored only in India (Mumbai/Hyderabad regions); CERT-In directions of 2022 require reporting of specified cyber incidents within 6 hours and retention of ICT logs for 180 days within India; the SEBI cloud framework (2023) and IRDAI guidelines set exit, audit and data-residency conditions for regulated entities; the Digital Personal Data Protection Act, 2023 governs processing of personal data of individuals in India (rules were being notified in stages — check current status); MeitY maintains an empanelment of cloud service providers for government workloads, and GIGW applies to government sites. Many Indian BFSI projects therefore run multi-AZ in ap-south-1 with Direct Connect, KMS customer-managed keys and CloudTrail logs retained in India.

Key points

• Region vs AZ - a region is a geography with its own endpoint; an AZ is an isolated data-centre cluster inside it. Multi-AZ for HA, multi-region for DR.
• Shared responsibility - AWS secures the cloud, you secure what you put in it.
• IAM role over access key - EC2, Lambda and ECS should assume roles; long-lived keys in code are the classic audit failure.
• Explicit deny wins in IAM policy evaluation; everything else defaults to deny.
• EC2 purchase options - On-Demand (flexible), Reserved/Savings Plans (committed, 30–70% off), Spot (cheapest, interruptible with a 2-minute notice).
• Security group = stateful, allow-only, instance level; NACL = stateless, allow+deny, subnet level.
• S3 - object storage, 11 nines durability, lifecycle rules to Glacier, Block Public Access on by default.
• EBS is AZ-bound and single-instance; EFS is shared and multi-AZ; instance store is ephemeral.
• gp3 is the default EBS SSD - 3,000 IOPS and 125 MB/s baseline, IOPS and throughput priced separately from size.
• RDS Multi-AZ is availability; a read replica is read scaling - they solve different problems.
• DynamoDB - choose a high-cardinality partition key to avoid hot partitions; GSI any time, LSI only at table creation.
• ALB is Layer 7, NLB is Layer 4 with a static IP and higher throughput.
• Auto Scaling + ELB + multi-AZ is the standard answer to "make this web app highly available".
• Lambda - event-driven, 15-minute maximum, billed per GB-second, cheapest for spiky or low-duty workloads.
• VPC endpoints keep private subnets off the internet and cut NAT Gateway cost (gateway endpoints for S3/DynamoDB are free).
• CloudTrail = who did what (API audit); CloudWatch = how it is performing (metrics, logs, alarms).
• Data transfer in is free, out is billed, and cross-AZ traffic is billed in both directions.
• Indian data residency - RBI payment data in India, CERT-In 6-hour incident reporting and 180-day Indian log retention, DPDP Act 2023.

Formulas and examples

Example 1 — monthly bill for a three-tier web app in Mumbai (indicative rates). Assume t3.medium On-Demand at \$0.0448/h, gp3 at \$0.0912/GB-month, ALB at \$0.0243/h, ₹84 per USD.

• Compute: 3 × 730 × 0.0448 = \$98.11
• Storage: 3 × 100 GB × 0.0912 = \$27.36
• Load balancer: 730 × 0.0243 = \$17.74 (plus LCU charges)
• Total ≈ \$143.21 ≈ ₹12,030/month
• With a 1-year no-upfront Compute Savings Plan at ~28% off compute: 98.11 × 0.72 = \$70.64, saving \$27.47 ≈ ₹2,307/month.

Example 2 — S3 cost for a college result-download portal. 500 GB stored, 1,000,000 GET, 50,000 PUT, 200 GB downloaded in a month. Rates: \$0.025/GB-month, \$0.0004 per 1,000 GET, \$0.005 per 1,000 PUT, \$0.1093/GB out after the 100 GB free allowance.

• Storage: 500 × 0.025 = \$12.50
• GET: 1,000 × 0.0004 = \$0.40; PUT: 50 × 0.005 = \$0.25
• Transfer out: (200 − 100) × 0.1093 = \$10.93
• Total = \$24.08 ≈ ₹2,023. Note that transfer, not storage, is 45% of the bill — which is why CloudFront or a cache in front of S3 pays for itself.

Example 3 — Lambda versus an always-on EC2 instance. 5,000,000 invocations/month, 512 MB memory, average duration 300 ms. Rates \$0.20 per 1M requests, \$0.0000166667 per GB-s, free tier 1M requests + 400,000 GB-s.

• GB-s per invocation = 0.5 × 0.3 = 0.15 → total 5,000,000 × 0.15 = 750,000 GB-s
• Billable compute = (750,000 − 400,000) × 0.0000166667 = \$5.83
• Billable requests = 4 × 0.20 = \$0.80 → total \$6.63 ≈ ₹557
• A t3.small (\$0.0224/h) running continuously costs 730 × 0.0224 = \$16.35 ≈ ₹1,374. Lambda wins here; at this memory and duration the two costs cross at about 8.6 million invocations/month, so above roughly 8–9 million the comparison flips.

Example 4 — availability arithmetic.

• Serial path ALB (99.99%) → EC2 (99.99%) → RDS (99.95%): A = 0.9999 × 0.9999 × 0.9995 = 0.99930 (99.93%) → downtime = 0.00070 × 8,760 = 6.1 h/year. A chain is always weaker than its weakest link.
• Redundancy: one instance at 99.5% has 0.005 × 730 = 3.65 h downtime per month. Two independent instances behind an ELB: A = 1 − 0.005² = 99.9975% → 0.000025 × 730 = 0.01825 h = about 1.1 minutes/month.

Example 5 — capacity and DynamoDB sizing.

• Peak 12,000 requests/s, each instance safely serves 800 rps → ceil(12,000/800) = 15; add one spare for an instance failure = 16; round up to a multiple of 3 AZs = 18 instances (6 per AZ). That does not survive a whole-AZ loss (12 left × 800 = 9,600 rps); for that the 2 surviving AZs must carry 15 → ceil(15/2) = 8 per AZ = 24 instances.
• Target tracking: 4 instances averaging 80% CPU with a 40% target → desired = ceil(4 × 80/40) = 8 instances.
• DynamoDB: 100 strongly consistent reads/s of 10 KB items → ceil(10/4) = 3 units × 100 = 300 RCU (only 150 RCU if eventually consistent). 50 writes/s of 3.5 KB → ceil(3.5/1) = 4 × 50 = 200 WCU.
• Durability: 10 million S3 objects at 99.999999999% → expected loss = 10⁷ × 10⁻¹¹ = 0.0001 objects/year, i.e. one object every 10,000 years.
• EBS binding limit: gp3 at 3,000 IOPS with 16 KiB blocks ≈ 3,000 × 0.016 = 48 MB/s (IOPS-bound); with 256 KiB blocks the 125 MB/s baseline allows only 125 ÷ 0.256 ≈ 488 IOPS (throughput-bound).

Where it is used

• Indian startups and consumer apps: Zomato, Swiggy, Dream11, Ola, Zerodha-style platforms and most SaaS companies run EC2/EKS + RDS/Aurora + S3 + CloudFront, scaling with ASGs for IPL or festival traffic spikes.
• BFSI and fintech: payment gateways and NBFCs run multi-AZ in ap-south-1 with Direct Connect, KMS, VPC endpoints and CloudTrail retained in India to satisfy RBI, SEBI and CERT-In requirements.
• IT services delivery: Infosys, TCS, Wipro, HCLTech, Accenture and LTIMindtree staff large AWS migration and FinOps practices; AWS Solutions Architect Associate / SysOps / Developer certifications are explicitly listed in their fresher and lateral job descriptions.
• Job roles: cloud engineer, DevOps/SRE, platform engineer, data engineer (S3 + Glue + Athena + Redshift), backend developer (Lambda + API Gateway + DynamoDB), cloud security engineer, FinOps analyst.
• Government, education and research: MeitY-empanelled cloud for e-governance workloads, university portals and MOOC platforms on S3 + CloudFront, HPC and ML training on GPU instances and SageMaker.
• Media, gaming and IoT: transcoding pipelines on Spot fleets, game backends on NLB + DynamoDB, device telemetry via IoT Core into Kinesis and Timestream.

Interview questions

• Q: What is the difference between a region and an availability zone? A: A region is a geographic location with its own isolated set of services and endpoints; an availability zone is one or more physically separate data centres within that region, so deploying across AZs protects against a data-centre failure while staying low-latency.
• Q: Difference between a security group and a network ACL? A: A security group is stateful, attaches to an instance/ENI and only has allow rules; a NACL is stateless, attaches to a subnet, is evaluated in rule-number order and supports both allow and deny.
• Q: When would you use S3 instead of EBS? A: S3 for durable, internet-accessible objects such as images, backups and logs accessed over an API; EBS when an operating system or database needs a low-latency block device attached to one instance in one AZ.
• Q: RDS Multi-AZ or a read replica — which one for high availability? A: Multi-AZ; it keeps a synchronous standby in another AZ and fails over automatically behind the same endpoint. A read replica is asynchronous and exists to offload read traffic.
• Q: How does an EC2 instance get permission to read an S3 bucket? A: Attach an IAM role to the instance through an instance profile; the SDK picks up temporary STS credentials from instance metadata — no access keys on disk.
• Q: How do instances in a private subnet download OS updates? A: Through a NAT Gateway in a public subnet with a route from the private subnet; for S3 and DynamoDB a free gateway VPC endpoint avoids the NAT charge entirely.
• Q: What are Spot Instances and when must you not use them? A: Spare capacity at a steep discount that AWS can reclaim with a two-minute warning; never use them for a single stateful server, a primary database or anything that cannot be interrupted or replaced.
• Q: Why does CPU utilisation sometimes not trigger your scaling alarm even though the server is slow? A: The bottleneck may be memory, disk or database connections — CloudWatch does not collect memory or disk-space metrics without the agent, so scale on request count or latency instead.
• Q: Explain the shared responsibility model with an unpatched EC2 server. A: AWS secures the hypervisor, network and physical facility; patching the guest OS is the customer's job, so an unpatched instance that is breached is the customer's responsibility.
• Q: How do you choose a DynamoDB partition key? A: Pick a high-cardinality, evenly accessed attribute such as user ID or order ID; a low-cardinality key like status or a date creates a hot partition and throttles.
• Q: What happens if an availability zone fails and your ASG spans three AZs? A: The ELB health checks stop routing to that AZ, the ASG launches replacement instances in the surviving AZs up to the maximum, and a Multi-AZ RDS fails over — so the service stays up with reduced headroom.
• Q: Your AWS bill doubled with no new instances. Where do you look first? A: Cost Explorer grouped by service and usage type — usually data transfer out, NAT Gateway processing, cross-AZ traffic, forgotten EBS snapshots/volumes, or S3 requests rather than compute.

Common mistakes

• Treating S3 as a filesystem — expecting in-place appends or mounting it as a disk; S3 replaces whole objects.
• Confusing RDS Multi-AZ with read replicas, or assuming the Multi-AZ standby can serve reads.
• Hardcoding IAM access keys in code or pushing them to GitHub instead of using IAM roles and Secrets Manager.
• Giving AdministratorAccess or s3:* with Resource: "*" in labs and leaving it in production — least privilege is the examined principle.
• Forgetting that a subnet reserves 5 IPs and that an EBS volume cannot cross AZs, then designing a /28 subnet or a cross-AZ attach that fails.
• Ignoring data-transfer and NAT Gateway charges in cost questions, and quoting the 12-month free tier as if it were permanent.
• Leaving student accounts running — an idle Elastic IP, unattached EBS volume, running NAT Gateway or RDS instance bills every hour; terminate and check Billing, and keep a Budget alert on.

Related topics

Cloud computing basics · Containers: Docker and Kubernetes · Caching, queues and CDNs · System design basics for freshers · REST APIs · Authentication and authorisation: sessions, OAuth and JWT