Interview Questions: Compute & Networking

Compute and networking are the bread and butter of almost every AWS interview. Interviewers want to see that you understand not just what a service does, but when to reach for it and why the obvious answer is sometimes wrong. This page walks through the most common questions on EC2, Auto Scaling, load balancers, and VPC networking, with model answers and the subtle “gotchas” that separate someone who memorized a cheat sheet from someone who actually understands the platform.

EC2 pricing models

Question: What are the EC2 pricing models, and when would you choose each?

EC2 (Elastic Compute Cloud, AWS’s virtual servers) has four main ways to pay. The right choice depends on how predictable and how interruptible your workload is.

Model	What it is	When to use it	When NOT to use it
On-Demand	Pay per second, no commitment	Short-lived, unpredictable, or first-time workloads	Steady 24/7 workloads (you overpay)
Reserved Instances / Savings Plans	1- or 3-year commitment for up to ~72% off	Predictable, always-on baseline capacity	Workloads you might turn off soon
Spot Instances	Spare capacity at up to ~90% off, can be reclaimed with a 2-minute warning	Fault-tolerant, stateless, or batch work	Anything that can’t tolerate sudden termination
Dedicated Hosts	A physical server reserved for you	Licensing tied to physical cores, compliance	General workloads (expensive)

Model answer for the Spot gotcha: Spot is appropriate when your work is interruptible, like rendering frames, CI builds, or stateless web workers behind a load balancer. It is a bad fit for a stateful database or a job that loses progress if killed. A strong answer mentions that AWS gives a two-minute interruption notice and that you can mix Spot with On-Demand in an Auto Scaling group so you keep a reliable baseline.

Tip: Reserved Instances and Savings Plans give the same discount, but a Compute Savings Plan is more flexible — it applies across instance families, sizes, and even Regions, so you don’t get locked into one instance type.

Instance types

Question: How do you pick an instance type?

Instance families are named by purpose. Define each one the first time:

• General purpose (t, m): balanced CPU and memory. t types are burstable (cheap, good for low-traffic apps).
• Compute optimized (c): high CPU, for batch processing or game servers.
• Memory optimized (r, x): lots of RAM, for in-memory caches and large databases.
• Storage optimized (i, d): fast local disks, for big data and NoSQL.
• Accelerated (p, g): GPUs, for machine learning and graphics.

The model answer: start with general purpose, measure the real bottleneck (CPU, memory, network, or disk), then move to a specialized family only when data shows you need it.

Auto Scaling groups and load balancers

Question: How do an Auto Scaling group and an Application Load Balancer work together?

An Auto Scaling group (ASG) keeps a desired number of EC2 instances running, replacing unhealthy ones and adding or removing instances as demand changes. An Application Load Balancer (ALB) spreads incoming HTTP/HTTPS traffic across those instances. Together they give you both elasticity and even traffic distribution.

The flow: the ALB has a target group, the ASG registers its instances into that target group automatically, and the ALB sends traffic only to instances that pass health checks.

Console steps to create an ASG:

1. Open the EC2 console and choose Auto Scaling Groups > Create Auto Scaling group.
2. Pick a launch template (this defines the AMI, instance type, and security group).
3. Select your VPC and two or more subnets in different Availability Zones.
4. Attach to an existing load balancer target group.
5. Set min, desired, and max capacity, then add a target tracking scaling policy (e.g. keep average CPU at 50%).

CLI equivalent:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template "LaunchTemplateId=lt-0a1b2c3d4e5f,Version=1" \
  --min-size 2 --max-size 6 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-0a1b2c3d,subnet-0e4f5a6b" \
  --target-group-arns "arn:aws:elasticloadbalancing:us-east-1:111122223333:targetgroup/web-tg/0a1b2c3d4e5f"

Output:

(no output on success; verify with describe-auto-scaling-groups)

Gotcha interviewers love: always spread an ASG across multiple AZs. If all instances live in one AZ and that AZ fails, scaling can’t save you — there’s no healthy zone to launch into.

EC2 vs Lambda vs containers

Question: When would you choose EC2, Lambda, or containers?

Option	What it is	Best for	Watch out for
EC2	Full virtual servers you manage	Long-running apps, full OS control	You patch and scale the OS yourself
Lambda	Functions that run on demand, no servers	Event-driven, spiky, short tasks (<15 min)	Cold starts; 15-minute max runtime
Containers (ECS/EKS on Fargate)	Packaged apps run by a scheduler	Microservices, consistent environments	More moving parts to learn

Model answer: choose Lambda when work is short and event-driven and you want zero server management; choose containers when you have many services that need consistent packaging and finer control; choose EC2 when you need long-running processes, special OS settings, or GPU access.

A concrete cost note: Lambda charges per millisecond and is nearly free when idle, while an always-on EC2 instance bills 24/7 even at 1% utilization. For a quiet API hit a few hundred times a day, Lambda can cost cents a month; a small t3.micro runs roughly $7.50/month regardless.

VPC networking

Question: Explain subnets, route tables, and gateways.

A VPC (Virtual Private Cloud, your own isolated network in AWS) is divided into subnets (smaller IP ranges, each tied to one AZ). A route table decides where traffic goes. The gateway attached to that route makes the subnet public or private:

• A public subnet has a route to an internet gateway (IGW), which allows two-way internet access.
• A private subnet has no IGW route. For outbound-only internet (like downloading patches), it routes through a NAT gateway (Network Address Translation — lets private instances reach out without being reachable from outside).

Question: Internet gateway vs NAT gateway?

The internet gateway allows inbound and outbound traffic and is what makes a subnet public. The NAT gateway is outbound-only: private instances can start connections to the internet, but the internet cannot start connections to them.

Gotcha: a single NAT gateway lives in one AZ. If that AZ fails, every private subnet routing through it loses internet access. For high availability (HA), deploy one NAT gateway per AZ and point each AZ’s private subnet at its local NAT. This costs more but removes the single point of failure.

Security groups vs NACLs

Question: What’s the difference between a security group and a network ACL?

This is the classic discriminator. Both are firewalls, but they behave differently:

Feature	Security group	Network ACL (NACL)
Attaches to	An instance (ENI)	A subnet
State	Stateful — return traffic is automatically allowed	Stateless — you must allow return traffic explicitly
Rules	Allow only	Allow and deny
Evaluation	All rules evaluated together	Rules processed in numbered order, first match wins

Model answer: a security group is stateful, so if you allow inbound port 443, the response goes back out automatically — you don’t write a return rule. A NACL is stateless, so you must also open the ephemeral outbound ports (typically 1024–65535) for replies, or connections silently hang. NACLs are a coarse, subnet-wide backstop; security groups are the primary, fine-grained control.

Multi-AZ vs read replicas

Question: For RDS, what’s the difference between Multi-AZ and read replicas?

Even in a compute/networking interview this comes up because it tests HA understanding. Multi-AZ keeps a synchronous standby copy in another AZ purely for failover — you don’t read from it; it exists for availability. Read replicas are asynchronous copies you do read from, to scale read traffic. They are not a failover mechanism. The crisp answer: Multi-AZ is for availability, read replicas are for scaling reads. Many candidates conflate the two.

Best practices

• Spread ASGs and load balancers across at least two AZs so a single zone failure can’t take you down.
• Use one NAT gateway per AZ for production private subnets; a single shared NAT is a hidden single point of failure.
• Keep databases and app servers in private subnets; expose only the load balancer in public subnets.
• Lean on security groups for fine-grained, stateful rules; use NACLs only as a coarse subnet-level guardrail.
• Mix Spot with On-Demand in ASGs to cut cost while keeping a reliable baseline.
• Buy Savings Plans for your steady baseline and pay On-Demand only for the variable peak.

Related Topics

• Interview Questions: Fundamentals
• Interview Questions: Storage & Databases
• Interview Questions: Serverless & Security