AWS Compute and Networking Questions

Covers design and operational knowledge of Amazon Web Services compute and network components. Candidates should understand Amazon Elastic Compute Cloud instances including instance families, sizing considerations, and pricing models such as on demand, reserved, and spot instances. Knowledge of Amazon Machine Images and launch templates, network interfaces, security groups, route tables, and Virtual Private Cloud architecture including public and private subnets, NAT gateways, and peering is expected. Expect questions on load balancing options including Application Load Balancer and Network Load Balancer, autoscaling groups and policies for availability and cost optimization, and hybrid connectivity patterns such as VPN and Direct Connect. Candidates should also be able to reason about high level multi tier application architectures on AWS, security and networking trade offs, and common infrastructure as code and automation approaches used to provision and manage these resources.

MediumSystem Design

79 practiced

Design a hybrid connectivity solution for a client that needs low-latency, high-throughput access to AWS from their on-prem datacenter. They want Direct Connect with VPN fallback, BGP routing, and per-prefix path preference. Explain private vs public virtual interfaces, BGP community usage, redundancy across DX locations, and failover behavior with VPN.

Sample Answer

Requirements & constraints:- Low-latency, high-throughput connectivity from on-prem to AWS- Primary: AWS Direct Connect (DX); secondary: IPsec VPN over Internet- Dynamic routing via BGP and per-prefix path preference- High availability across DX locations and predictable failover

High-level design:- Provision two or more DX connections at distinct DX locations (colocation sites) for resilience. Each connection terminates to the same AWS Direct Connect gateway (DXGW) or to Regional VGW depending on design.- Create private virtual interfaces (private VIFs) to connect to VPCs via a DX Gateway (for multi-region or many VPCs) or Virtual Private Gateway (VGW) for single-region VPC access. Use public VIFs only if accessing AWS public endpoints (S3, API) over DX.- Configure an IPsec VPN overlay to the VGW/DXGW as active-passive fallback over the Internet (two tunnels for redundancy).

BGP & per-prefix path preference:- Establish eBGP sessions from on-prem routers to AWS (DX VIF uses BGP). Advertise on-prem prefixes; accept AWS prefixes (VPC routes, Transit Gateway/NAT).- Use BGP attributes for per-prefix preference: - Local-preference on on-prem routers to prefer a specific DX location for certain prefixes. - MED from AWS is limited; instead use BGP communities that AWS supports (e.g., prepend AS-path on the on-prem side or tag routes with communities propagated to Transit Gateway). - For fine-grained control, use AS-path prepending on the less-preferred DX link or set higher local-pref on the preferred path. - Tag routes with community values (if using Transit/Route Tables that honor them) to control propagation to specific VPCs/regions.

Redundancy & failover behavior:- Multi-DX locations: active-active for bandwidth aggregation (if downstream supports ECMP) or active-primary with backup DX for deterministic routing.- BGP timers: tune hold/timers for fast detection; consider BFD between on-prem and router pairs to detect link failure sub-second and withdraw routes quickly.- Failover to VPN: Configure BGP over VPN with higher local-preference on DX paths so they are preferred. On DX loss (link down or BGP withdraw), VPN-learned routes take precedence automatically. Ensure split-horizon/security: route filters to prevent route leaks.- Testing: run failover drills, validate ECMP behavior, and measure latency/throughput.

Operational considerations:- Monitor DX/ VPN with CloudWatch, SNMP, and routing telemetry.- Use encryption requirements: DX private VIF is not encrypted—VPN adds encryption.- Capacity planning: order DX link(s) with sufficient bandwidth and enable link aggregation (LAG) if needed.- Security: enforce ACLs and NACLs on VPCs; limit CIDR propagation where needed.

This approach provides low-latency, high-throughput primary paths via Direct Connect, deterministic per-prefix traffic steering via BGP attributes/communities and controlled, automatic failover to VPN.

HardTechnical

121 practiced

Design a governance and CI/CD strategy for Infrastructure as Code (Terraform) used by 100+ engineers. Include module versioning, remote state management, policy-as-code (Sentinel/OPA), secrets handling, automated plan/review pipelines, drift detection and rollback procedures.

Sample Answer

Clarify requirements & constraints:- Multi-team (100+ engineers), multi-account/cloud, need strong security, low friction for developers, auditability, and safe automated changes.

High-level strategy:- Centralized module registry + strict semantic versioning (MAJOR.MINOR.PATCH). Modules live in their own repos; releases are git-tagged and published to a private registry (Terraform Cloud/Registry or Artifactory). Consumers reference fixed versions; CI enforces no usage of unapproved "latest".- Remote state: backend per-environment using Terraform Cloud/Enterprise or S3 + DynamoDB locking (AWS) with encryption (KMS). One workspace per environment/infrastructure boundary; state stored per workspace, with automated state backups/versioning and lifecycle retention.- Policy-as-code: Gate changes with Sentinel (TFC) or OPA/Conftest in CI. Implement policies for naming/tagging, cost guardrails, network/security constraints, and least-privilege IAM. Policies run at plan time and block apply if critical violations exist; non-blocking warnings for soft rules.- Secrets: No secrets in TF code. Use HashiCorp Vault (or cloud KMS+Secret Manager). Provide a secrets-data-source pattern where TF fetches secrets at runtime via a secure, short-lived credential broker (e.g., Vault Agent with approle or OIDC). CI runners use ephemeral credentials; logs scrubbed.- CI/CD pipelines: - PR workflow: Developer opens PR → CI runs terraform fmt, validate, init (with module proxy), plan in an isolated ephemeral workspace using the PR branch + remote state read-only snapshot. Plan artifact uploaded to PR. - Review: Plan must be reviewed/approved by peers and a designated approver (based on RBAC). Policy/OPA results attached. - Apply: Only a hardened pipeline (or TFC run with RBAC) can apply to production. Enforce multi-approver for prod (2-person rule). Use Atlantis or Terraform Cloud to coordinate applies if desired. - Automation: For non-prod, allow auto-apply for trusted teams with audit logging.- Drift detection & remediation: - Periodic runs (scheduled TFC runs or cron pipelines) to terraform plan and detect drift; generate alerts to Slack/Incident system and create tickets automatically. - For acceptable drift, pipeline can auto-apply in lower environments after approval. For prod, require manual approval after triage.- Rollback & recovery: - Maintain state versioning + automated state snapshot retention. If an apply causes failures, procedures: - Immediate: Trigger automated rollback by re-applying last-known-good configuration (pin module + root module versions) from a tagged commit; this is an automated job w/ two approvers. - If state corrupted, restore state from the most recent snapshot and re-run apply in a sandbox first. - Maintain runbooks and playbooks, and enable quick feature-flagging/traffic-shifting (blue/green or canary infra) when applicable.- Governance & org controls: - RBAC integrated with SSO (OIDC/SSP), least privilege for pipelines and service principals, audit logs shipped to central SIEM, and cost/time quota enforcement per team. - Module ownership model with a central platform team that reviewers modules, plus on-call for infra incidents.- Observability & metrics: - Track mean time to detect/repair drift, number of blocked plans by policy, failed applies, and change lead time. Use these for continuous improvement.

Why this works:- Balances developer velocity (self-service modules, PR plans) with safety (policy-as-code, locked state, multi-approver applies). Uses proven tools (Terraform Cloud/Enterprise, Vault, OPA/Sentinel, Atlantis) and operational practices (state backups, runbooks, RBAC) to scale governance across 100+ engineers.

HardTechnical

69 practiced

Design an autoscaling strategy for stateful services that require up to 10 minutes to gracefully shutdown (drain connections and persist state). Explain how to use Auto Scaling lifecycle hooks, warm pools, SQS buffering, connection draining and health checks to safely scale in without dropping requests while balancing cost.

Sample Answer

Requirements & constraints:- Stateful service with up to 10min graceful shutdown (drain + persist).- No dropped requests during scale-in.- Cost-sensitive: minimize idle capacity.- Use AWS ASG features, SQS buffering, warm pools, lifecycle hooks, health checks.

High-level design:- Fronting layer: ALB/NLB + target group with health checks.- Message buffer: SQS (FIFO if ordering required) between clients and stateful workers.- Auto Scaling Group (ASG) with warm pools and lifecycle hooks.- Sidecar or agent on instances to coordinate draining and state persistence.- DynamoDB/RDS for persisted state, or shared storage as needed.

Scale-out flow:1. ASG adds new instance (or reuses warm pool entry). Warm pool ensures instance is booted, app container pre-warmed, registered but marked UNHEALTHY to avoid traffic.2. Health checks (application-level) validate readiness (dependencies warmed, state loaded). Once ready, mark healthy so ALB/NLB starts sending traffic.3. Use SQS visibility to buffer spikes; workers poll from SQS, preventing client-side timeouts.

Scale-in flow (safe, no drops):1. ASG identifies instance to terminate. Lifecycle hook (EC2_INSTANCE_TERMINATING) triggers and pauses termination for up to hook timeout (set >10min, e.g., 15min).2. Lambda or lifecycle-action coordinator calls instance agent API to: - Mark instance UNHEALTHY in ASG target group (deregister target), so ALB stops new connections. - Stop fetching new messages from SQS (or let agent stop long-polling immediately). - Let existing connections drain (up to 10min). Agent persists in-memory state to DB. - For long-lived TCP, use connection-draining via NLB/target deregistration timeout and graceful shutdown of acceptors.3. After drain and persist complete, agent notifies lifecycle hook to continue (CompleteLifecycleAction), allowing instance termination.4. If drain not complete when lifecycle hook times out, use fallback: extend lifecycle hook (if supported) or move in-flight work to another node by re-enqueueing unprocessed messages (use visibility timeout) and ensure idempotency.

Supporting mechanisms:- SQS: use visibility timeout and dead-letter queues. Workers must be idempotent so re-delivery is safe.- Warm pools: reduces scale-out latency and avoids over-provisioning. Keep small pool sized to expected surge profile vs. cost.- Health checks: application-level readiness probe that ensures the node is fully ready before receiving traffic.- Observable metrics: track inflight connections, queue length, worker utilization; use these for scaling policies.

Scaling policy suggestions:- Scale on combined signals: SQS queue depth per active worker, CPU/memory, and inflight connections metric.- For scale-in, prefer step policies that only remove instances when queue depth < threshold and average connection count per instance < safe level.- Use predictive or scheduled scaling for known traffic patterns to reduce churn.

Trade-offs and cost balance:- Longer lifecycle hook time increases termination safety but ties resources during scale-in; keep lifecycle hook just above max drain time.- Warm pools cost vs. latency: smaller warm pool plus predictive scaling reduces cost while meeting SLAs.- Buffering with SQS shifts cost to storage/latency but prevents request loss and allows safe scaling.

Edge cases:- Sudden zero-downtime requirement: keep small overprovision buffer or use cross-AZ draining to avoid coordinated losses.- Non-idempotent operations: ensure durable state persistence before acknowledging work; employ two-phase commit patterns or transaction logs.

This strategy ensures instances never receive new work during drain, in-flight work is safely persisted or re-queued, scale-out latency is minimized with warm pools, and costs are managed by tuning warm pool size, lifecycle hook timeout, and scaling thresholds.

MediumTechnical

87 practiced

Compare using Transit Gateway versus building a hub-and-spoke network with EC2-based routers or third-party firewall appliances. Discuss scalability, operational overhead, cost model, features (transitive routing, route tables, attachments), and scenarios where a vendor appliance is still appropriate.

Sample Answer

Situation: When designing AWS network topologies, you often choose between AWS Transit Gateway (TGW) and a hub-and-spoke using EC2-based routers or third‑party firewall appliances. Below is a concise, role-appropriate comparison covering scalability, operations, cost, features, and when appliance-based hubs remain appropriate.

Scalability- Transit Gateway: Managed, massively scalable — supports thousands of VPCs/VPNs/VPC attachments with built‑in bandwidth scaling and simplified transitive routing. AWS handles high-throughput and HA.- EC2/router appliances: Scaling requires provisioning more instances (autoscaling, clustering), load balancers, and careful capacity planning; horizontal scale is achievable but operationally complex.

Operational overhead- Transit Gateway: Low ops — AWS manages control plane, patching, high availability; you manage route tables and attachments.- EC2/appliances: High ops — patching, OS upgrades, HA config (VRRP, clustering), licensing, backup/restore, monitoring.

Cost model- Transit Gateway: Predictable per‑hour + per‑GB attachments/processing (can be cheaper at scale for many VPCs). Cost benefits if many attachments and you want simplified management.- EC2/appliances: Costs include instance hours, EBS, NAT/ENI data charges, and often expensive vendor licenses (per‑hour or throughput). May be cheaper for very low-throughput single-use cases or if you already have perpetual licenses.

Features (transitive routing, route tables, attachments)- Transit Gateway: Native transitive routing via TGW route tables and implicit hub model; supports multiple route tables for segmentation, attachments (VPCs, AWS Direct Connect, VPN, peering) and multicast. Centralized route propagation.- EC2/appliances: Transitivity only if you implement routing/forwarding on instances; full control of packet inspection, DPI, custom routing policies. Route complexity increases with scale.

When a vendor appliance is appropriate- Advanced security requirements (IDS/IPS, advanced DPI, TLS inspection) or regulatory mandates requiring specific certified controls.- Complex, application‑aware traffic steering, granular session-level policies, or existing vendor contracts/licensing that deliver required features.- Protocols or features not supported by TGW (very specialized routing, legacy overlays, custom encapsulation).- When you need in‑line processing with deep packet modifications or third‑party management integrations.

Recommendation- Use Transit Gateway for most enterprise hub-and-spoke needs: scalable, lower ops, simpler cost predictability, and native integrations (Direct Connect, AWS Firewall Manager).- Deploy vendor appliances in-line or as inspection hops where required: combine TGW for connectivity and attach appliance VPCs for inspection (inspection VPC pattern) to get best of both worlds — TGW for scale/management, appliances for advanced security.

EasyTechnical

88 practiced

What is an Elastic Network Interface (ENI) in AWS? Describe common use cases (secondary private IPs, multiple IPs per instance, failover patterns, and container networking), attachment constraints (AZ affinity), and limits to be aware of when designing multi-NIC architectures.

Sample Answer

An Elastic Network Interface (ENI) is a virtual network card that you attach to an EC2 instance: it has a primary private IPv4, optional secondary private IPv4s, an associated public IP (optional/NAT), MAC address, and security group associations. ENIs are first-class AWS resources you can create, attach/detach, and persist independent of instance lifecycle.

Common use cases- Secondary private IPs: host multiple IP addresses on one NIC to serve multiple services, VIPs, or for transition/migration without changing instance.- Multiple IPs per instance (multi-NIC): attach several ENIs to an instance to separate traffic planes (management, data, storage) or provide multiple MACs for licensing/firewalling.- Failover patterns: move an ENI (and its IPs/security groups) between instances in the same AZ for stateful failover/HA; used with scripts or AWS services (Lambda, SSM) to perform quick cutover.- Container networking: assign ENIs or secondary IPs to containers (awsvpc CNI for EKS/ECS) so each pod/task gets its own IP and security group isolation.

Attachment constraints & important behaviors- AZ affinity: an ENI lives in a subnet and is AZ-scoped; you can only attach it to instances in the same AZ. To fail over across AZs you must provision ENIs in each AZ and manage IP routing/DR.- Attachment lifecycle: ENIs can be detached and reattached while preserving IPs/security groups, but some instance types limit hot-plugging.

Design limits & considerations- ENI / IP limits: each instance type has max ENIs and max IPv4 addresses per ENI (e.g., t3.medium fewer than c5n.18xlarge). Check AWS docs for exact per-instance quotas. Exhausting IPs/ENIs restricts pod density with awsvpc CNI.- Security groups: there’s a limit to security groups per ENI and total rules; design for manageable rule sets.- Throughput and performance: network bandwidth often tied to instance size and number of ENIs — adding ENIs doesn’t increase vCPU or underlying NIC capacity beyond instance limits.- Elastic IPs: limited per-region quotas and per-account.- Operational complexity: multi-NIC architectures increase routing, monitoring, and failover orchestration complexity; plan IAM, automation (CloudFormation/Infra-as-Code), and testing.

When designing, consult the instance-type ENI/IP table, prefer AZ-aware HA patterns, and weigh isolation vs. management overhead.

Unlock Full Question Bank

Get access to hundreds of AWS Compute and Networking interview questions and detailed answers.

Join thousands of developers preparing for their dream job.