EC2 Lambda and Managed Services Questions

Comprehensive understanding of cloud compute options and how to choose between Amazon EC2, AWS Lambda, and managed deployment services such as Elastic Beanstalk. Candidates should be able to compare tradeoffs between control and operational overhead. Amazon EC2 provides full operating system level control, support for long running and stateful processes, custom machine images, fine grain instance sizing, placement groups for network and latency requirements, and suitability for legacy or specialized workloads. AWS Lambda provides a serverless event driven execution model with automatic scaling, per invocation billing, and minimal infrastructure management but introduces cold start latency, concurrency limits, execution duration limits, and resource constraints. Managed deployment services such as Elastic Beanstalk simplify application deployment and lifecycle management by abstracting infrastructure while still allowing configuration of underlying resources. Candidates should also know instance family characteristics for sizing such as burstable T series, general purpose M series, and compute optimized C series; pricing models including on demand, reserved capacity, savings plans, and spot instances; cost optimization techniques such as right sizing and spot use; and scaling and deployment patterns including auto scaling groups, function concurrency management, scheduled scaling, placement groups, and deployment strategies. Key design considerations include stateless versus stateful architecture, startup time impact, observability and monitoring, testing and deployment complexity, security and compliance, and how each option affects reliability, latency and cost.

EasyTechnical

88 practiced

Given a small two-tier web application (React frontend, Node.js backend) with low traffic and minimal operational team capacity, which compute service would you recommend (EC2, Elastic Beanstalk, Lambda) and why? Include deployment and maintenance considerations.

EasyTechnical

80 practiced

Compare the security responsibilities and boundaries when running workloads on EC2 instances versus AWS Lambda. Discuss patching, IAM roles, network placement (VPC), secrets management, and attack surface differences.

Sample Answer

**Overview (role view)**As a Cloud Architect I separate responsibilities into "customer-managed" vs "provider-managed" and design controls accordingly. Below I compare EC2 vs Lambda across the requested domains and give recommended guardrails.

**Patching**- EC2: Customer responsibility — OS, runtime, agent updates. Use AMI baking, SSM Patch Manager, automated image pipelines, and scheduled maintenance windows.- Lambda: Provider-managed for the underlying OS and Lambda service. You must patch your function dependencies (libraries/layers) and rebuild/deploy. Enforce SBOM and dependency scanning.

**IAM roles**- EC2: Use instance profiles with least privilege, assume-role patterns, and avoid long-lived credentials. Consider session boundaries and instance metadata service v2 (IMDSv2).- Lambda: Use execution roles per function with narrow permissions and resource-level constraints. Prefer separate roles per environment/function and use permission boundaries for service control.

**Network placement (VPC)**- EC2: Full control over subnets, security groups, NACLs, route tables — design for segmentation (public/private), bastion host, and NAT/egress controls.- Lambda: Can run in VPC (ENIs managed by AWS) — beware of cold-start and ENI scaling; prefer using VPC only when accessing private resources, and place functions in private subnets with proper security groups.

**Secrets management**- EC2: Use IAM + instance profile to access Secrets Manager or SSM Parameter Store; avoid embedding credentials. Use ECS/SSM agents to fetch secrets at runtime securely.- Lambda: Use IAM permissions to access Secrets Manager or environment variables encrypted with KMS. Prefer Secrets Manager with rotation and use least-privilege KMS keys.

**Attack surface**- EC2: Larger attack surface — SSH, open ports, OS vulnerabilities, installed agents. Requires host hardening, monitoring (OS-level logs, EDR), and patching lifecycle.- Lambda: Smaller infrastructure surface; focus shifts to application logic, dependencies, IAM misconfigurations, and event source protections. Protect against excessive permissions and supply-chain attacks.

**Architectural recommendations**- Standardize least privilege IAM, centralized secrets in Secrets Manager with rotation, automated dependency scanning, enforce IMDSv2 and SSM for EC2, and use VPC segmentation. Choose Lambda for reduced infrastructure burden when stateless workloads fit; choose EC2 when you need full control or specialized OS-level controls.

EasyTechnical

76 practiced

Explain stateless versus stateful application architectures. How do these models influence your decision to run on Lambda, EC2, or Elastic Beanstalk? Include examples for session handling, file storage, and connection pooling.

Sample Answer

**Definition — Stateless vs Stateful**

Stateless: each request contains all info to process it; instances are interchangeable. Good for scale-out, fast recovery, and ephemeral compute. Stateful: application or runtime maintains session/connection state across requests (in-memory sessions, long-lived sockets).

**How this drives platform choice**

- Lambda (serverless): optimized for stateless workloads — short-lived, horizontally scalable, event-driven. Use when you can externalize state (databases, object stores, caches). Cold-starts and execution limits make Lambda poor for long-lived connections or in-memory session reliance.- EC2: flexible for stateful services requiring local state, custom OS-level control, persistent connections, or specialized networking. Use for legacy apps, in-memory caches, or heavy connection pooling.- Elastic Beanstalk: Platform-managed for web apps; supports both models but best when app is made stateless or uses shared state stores. Faster deployment than raw EC2, with more control than Lambda.

**Examples**

- Session handling: store sessions in DynamoDB/ElastiCache/Redis (stateless app on Lambda or Beanstalk). For stateful EC2 apps that maintain in-process sessions, use sticky load balancer — but less resilient and harder to scale.- File storage: put files in S3 (stateless) so any Lambda/Beanstalk/EC2 instance can access them. Local disk on EC2 only for ephemeral caches or high-performance temp storage; replicate or back up as needed.- Connection pooling: serverless: use RDS Proxy or managed pooling to avoid exhausting DB connections. On EC2/Beanstalk: maintain local pools per instance; size pools by instance count and autoscaling policies.

**Architectural trade-offs**

- Favor stateless architectures for scalability, simpler autoscaling, and using Lambda/Beanstalk. - Use stateful EC2 when low-latency local state, specialized hardware, or long-lived connections are required. As a Cloud Architect I default to externalizing state (S3, managed caches, DB proxies) to maximize portability and operational simplicity.

MediumTechnical

81 practiced

As an architect, propose a multi-layer cost optimization checklist for compute across EC2, Lambda, and managed services. Include short-term tactics (rightsizing, spot), medium-term policies (savings plans, reserved instances), and long-term architectural changes (refactor to serverless or containers).

Sample Answer

**Overview**As a cloud architect I’d present a multi-layer checklist that groups immediate tactics, policy-level commitments, and strategic architectural shifts. Each item includes owner, metric, and rollback/trade-off.

**Short-term (0–3 months) — tactical**- Inventory & tagging: enforce CostCenter, Env, App tags; owner + alert on untagged.- Rightsizing: run CloudWatch/Cost Explorer and CPU/RAM/IO analysis; downsize or change family; owner: infra team; metric: 7–14 day utilization.- Spot/Preemptible: move non-critical batch, analytics, CI agents to spot with graceful checkpointing.- Lambda tuning: set memory to match CPU needs, minimize cold starts via provisioned concurrency only where SLA requires.- Stop unused resources: auto-stop dev/test EC2, RDS during off-hours.

**Medium-term (3–12 months) — policy & purchasing**- Savings Plans / RIs: analyze stable baseline workloads and buy Compute Savings Plans for EC2/Lambda where predictable.- Commitments for managed services: reserved instances / sustained-use discounts for RDS/ElastiCache where steady.- Automated governance: implement policies (AWS Config/Policy) to enforce instance families, prevent oversized SKUs, require termination protection review.- Chargeback/showback: enable per-team dashboards and monthly reviews.

**Long-term (12+ months) — architecture**- Refactor candidates: move predictable, stateless services to containers (ECS/EKS Fargate) or serverless (Lambda) to convert fixed cost to variable.- Data & service partitioning: adopt microservice boundaries to scale only hot paths.- Platformization: create internal self-service PaaS with autoscaling, spot fleets, and pre-approved savings-plan allocations.- Evaluate trade-offs: e.g., serverless reduces ops but may increase per-invocation cost and vendor lock-in; containers require orchestration effort but provide density and control.

**Metrics & Continuous Improvement**- KPIs: $/vCPU-hour, lambda $/invocation, cost per customer, waste % (idle spend).- Monthly review, quarterly RI/SavingsPlan re-evaluation, capture lessons in runbook.

This checklist balances quick wins, disciplined purchasing, and long-term design to sustainably lower compute costs while managing risk and performance.

MediumTechnical

68 practiced

Design network and IAM for a Lambda function that must access a private RDS instance in a VPC. Explain the implications for cold start, NAT use, security groups, and IAM role scoping; propose mitigations for increased latency and concurrency limits.

Sample Answer

**Clarify requirements**- Lambda must reach a private RDS (no public access). High availability and security required. Expected traffic pattern (burst vs steady) influences choices.

**High-level design**- Place RDS in private subnets of a VPC (multi-AZ).- Place Lambda in same VPC, with ENIs in one or more private subnets.- Provide outbound Internet (for updates, secrets, or other services) via NAT Gateway (or NAT instances) in public subnets or use VPC Endpoints for AWS services (Secrets Manager, S3, Systems Manager) to avoid NAT.

**Networking & cold-start implications**- When a Lambda is associated with a VPC it creates ENIs (now faster with Hyperplane ENIs but still adds cold-start latency). Expect additional 100–300 ms (or more) on cold start; first scale-up can be larger.- Mitigations: - Use Provisioned Concurrency to eliminate cold-starts for critical functions. - Reduce subnet count and keep warm pool in subnets with low AZ fragmentation. - Use lighter runtime/container images and optimize init code.

**NAT usage and alternatives**- NAT Gateway provides reliable outbound Internet but adds cost and single AZ egress unless architected multi-AZ.- Prefer VPC Endpoints (Gateway/Interface) for AWS services to avoid NAT egress and reduce latency and cost (e.g., Secrets Manager, S3, CloudWatch).- If third-party APIs must be reached, use highly available NAT Gateways (one per AZ) or centralized egress via a proxy fleet.

**Security groups & network controls**- Lambda gets security group A; RDS has security group B. Allow inbound on RDS SG from Lambda SG (reference by SG id). Principle: least privilege network access — open only necessary ports and source SGs.- Use separate SGs for different function tiers, and NACLs as defense-in-depth (stateless; be careful with port ranges).- Use subnet routing and flow logs for auditing.

**IAM role scoping**- Create a least-privilege IAM role for Lambda: only allow access to RDS connection metadata (if using Secrets Manager, grant secrets: GetSecretValue), CloudWatch logs, and VPC Describe actions if necessary. Avoid broad wildcards; use resource ARNs.- Separate roles for administrative actions vs runtime access. Use session policies and, where available, condition keys (e.g., aws:SourceVpc, aws:SourceIp) to tighten access.

**Concurrency & latency mitigations**- RDS connection limits: use connection pooling (RDS Proxy) to reduce DB connections and improve failover handling.- Use RDS Proxy (managed) to reduce DB connection storm and decrease cold-start impact on DB.- Provisioned Concurrency for Lambda to meet latency SLAs and avoid cold-start bursts; balance cost vs performance.- Warm-up strategies (scheduled pings) and compute sizing to handle baseline traffic.- Monitor and scale RDS (read replicas, connection scaling) and tune timeouts/retries in Lambda.

**Trade-offs**- Provisioned Concurrency + RDS Proxy increases cost but reduces latency and DB stress.- VPC Endpoints reduce cost and latency for AWS services but require design changes for third-party access.

This design balances security (VPC, SG, least-privilege IAM), performance (Provisioned Concurrency, RDS Proxy), and cost (NAT vs Endpoints), aligned to enterprise-grade cloud architecture.

Unlock Full Question Bank

Get access to hundreds of EC2 Lambda and Managed Services interview questions and detailed answers.

Join thousands of developers preparing for their dream job.