AWS Deep Dive Part 1: Compute & Networking — EC2, Lambda, ECS, EKS, Fargate, VPC, Route 53

byAlex R. •
AWS Deep Dive Part 1: Compute and Networking

Amazon Web Services offers more than 200 services, but in practice the vast majority of real-world workloads are built on roughly twenty of them. This four-part series walks through the 20 most-used AWS services, explaining what each one does, when to reach for it, and how the pieces fit together. We start with the foundation everything else sits on: compute and networking. By the end of this post you will have a clear mental model of how EC2, Lambda, ECS/EKS/Fargate, VPC, and Route 53 work and how to combine them.

How Compute and Networking Fit Together

Every AWS workload ultimately runs on compute resources that live inside a network. The compute side gives you a CPU to execute your code; the networking side controls who can reach that code and how packets get there. Get these two layers right and the rest of the platform — storage, databases, queues, observability — just plugs in.

AWS Compute and Networking stack

1. Amazon EC2 — Elastic Compute Cloud

Amazon EC2 is the oldest and still the most flexible compute service on AWS. It gives you virtual machines (called instances) that you can boot from a machine image (AMI), attach storage to, and place inside your own network. You get root or Administrator access and can install anything that runs on the chosen OS.

The key concepts you need to understand are instance families, purchase options, and placement. Instance families are letter-coded by workload: M for general purpose, C for compute-optimized, R for memory-optimized, I for storage-optimized, G/P for GPU. Within each family you pick a generation and size (m7g.large, c7i.4xlarge, etc.). Purchase options let you trade flexibility for price: On-Demand is the default, Reserved Instances or Savings Plans give big discounts in exchange for a 1- or 3-year commitment, and Spot Instances offer up to 90% off in exchange for the right of AWS to reclaim them with a 2-minute notice.

EC2 purchase options compared

EC2 instances live inside a VPC subnet and have one or more ENIs (elastic network interfaces). You can attach EBS volumes for persistent block storage, place the instance behind an Application Load Balancer or Network Load Balancer, and put a group of them under an Auto Scaling Group that adjusts capacity based on metrics. Instances can have a Public IP, an Elastic IP, or only private addresses depending on whether they should be reachable from the internet.

2. AWS Lambda — Serverless Functions

AWS Lambda sits at the other end of the compute spectrum from EC2. You upload a function, configure memory (which also scales CPU), pick a runtime such as Node.js, Python, Java, .NET, Go or a custom container image, and Lambda runs it whenever an event triggers it. You never see the underlying server, and you pay only for the milliseconds you execute and the number of requests.

Lambda is event-driven. Triggers include API Gateway calls, S3 object uploads, DynamoDB streams, SQS and SNS messages, EventBridge rules, CloudFront viewer requests (Lambda@Edge), and scheduled invocations. Each invocation runs in an isolated micro-VM (Firecracker), with a maximum execution time of 15 minutes, up to 10 GB of memory, and an ephemeral /tmp of up to 10 GB. A new execution environment causes a cold start; subsequent invocations reuse a warm environment until it is recycled. SnapStart and provisioned concurrency mitigate cold starts for latency-sensitive workloads.

Lambda invocation flow

The mental model is simple: EC2 is a machine you operate; Lambda is a function the platform operates. EC2 wins on long-running, stateful, or specialized workloads (databases on instances, GPU training jobs, anything needing OS-level access). Lambda wins on bursty event-driven work — APIs, glue code between AWS services, scheduled jobs, file processing pipelines, and chat / webhook handlers.

3. Containers on AWS — ECS, EKS, and Fargate

Between a full VM and a single function lies the container. AWS offers three closely related services to run them: ECS, EKS, and Fargate. The distinction confuses many people, so it helps to remember that ECS and EKS are orchestrators while Fargate is a capacity provider.

ECS (Elastic Container Service) is the AWS-native orchestrator. You define task definitions describing your container images, CPU and memory needs, IAM role, networking mode, and logging. A service keeps a desired number of tasks running on a cluster and registers them with a load balancer. ECS is simple to learn, integrates deeply with the rest of AWS, and has no control-plane fee.

EKS (Elastic Kubernetes Service) is managed upstream Kubernetes. You get the standard kubectl experience, Helm charts, CRDs, operators, and a vast open-source ecosystem. AWS runs the control plane (with a monthly fee per cluster) and you supply the worker nodes (EC2) or use Fargate for them. Choose EKS if you want portability across clouds, already invested in K8s tooling, or need features only Kubernetes provides.

Fargate is the serverless data plane for both ECS and EKS. Instead of provisioning EC2 worker nodes, you tell Fargate the CPU and memory each task needs and AWS launches it on infrastructure you never see. You pay only for the resources tasks consume. The tradeoff is a higher per-vCPU price than equivalent EC2, no daemonsets that need a host, and no GPU support today.

ECS vs EKS vs Fargate

A useful decision rule: if your team already owns Kubernetes expertise, use EKS; if not, ECS will get you running in a day. For the data plane, pick Fargate unless you have specific needs (GPU, Windows containers, daemonsets, deep cost optimization with Spot, custom AMIs) that justify managing EC2 nodes.

4. Amazon VPC — Your Private Network in the Cloud

Amazon VPC is the virtual network that contains your EC2 instances, container tasks, RDS databases, and most other resources. A VPC is regional and gets a CIDR block (for example 10.0.0.0/16) that you carve into subnets, each of which lives in one Availability Zone. Subnets are public if their route table sends 0.0.0.0/0 to an Internet Gateway, or private if it does not. Private subnets reach out to the internet through a NAT Gateway, and reach AWS services privately through VPC Endpoints (Gateway endpoints for S3 and DynamoDB; Interface endpoints powered by PrivateLink for almost everything else).

VPC anatomy with public and private subnets

Inside the VPC you control access with two complementary mechanisms. Security Groups are stateful firewalls attached to network interfaces; they allow traffic by source IP or by another security group and automatically allow the return path. Network ACLs are stateless rules attached to subnets; they evaluate inbound and outbound separately and are useful as a coarse second layer. The widespread best practice is to do most of your filtering with security groups and reach for NACLs only for subnet-wide deny rules.

For connecting the VPC to other networks you have several options. VPC Peering creates a 1:1 link between two VPCs. Transit Gateway is a hub that connects many VPCs and on-premises networks (via Direct Connect or Site-to-Site VPN). PrivateLink exposes a service inside one VPC to another VPC without routing or peering, via an Interface Endpoint. Designing a multi-VPC network usually means picking one of these and sticking with it.

5. Amazon Route 53 — DNS and Traffic Management

Route 53 is the global DNS service that fronts almost every workload on AWS. Beyond authoritative DNS hosting it provides domain registration, health checks, and a rich set of routing policies that determine which IP is returned in response to a query. Knowing these policies is what separates basic DNS from real traffic engineering.

Route 53 routing policies

Route 53 is also where you wire up alias records to AWS resources (ALB, CloudFront, API Gateway, S3 website endpoints). Aliases are free at the query level and update automatically when the target IP changes, which is essential for services whose underlying IPs are not stable.

Putting the Five Together — A Reference Architecture

A typical production workload combines all five services. Route 53 resolves api.example.com to an Application Load Balancer sitting in two public subnets across two AZs. The ALB forwards to an ECS service on Fargate in private subnets. The tasks talk to RDS and S3 via VPC endpoints, and emit logs to CloudWatch. A separate stack of Lambda functions handles asynchronous workloads (image resizing, SQS consumers, scheduled report generation). EC2 only appears for the special-purpose pieces — a build runner, a self-hosted Bastion or, increasingly rare, a long-running stateful daemon.

Cost and Operations Heuristics

Compute is usually the largest line item in an AWS bill, so a few habits pay back quickly. Rightsize EC2 instances using Compute Optimizer recommendations, then layer Savings Plans on top of the steady baseline. Use Spot for stateless web tiers and batch jobs through capacity providers in ECS or Karpenter in EKS. For Lambda, profile memory: doubling memory often more than doubles CPU and can cut wall-clock cost. On the networking side, NAT Gateway data processing charges and inter-AZ traffic are the silent budget killers — use VPC endpoints for AWS API calls and keep chatty services in the same AZ when latency-tolerance allows.

What is Next

Compute and networking give you the runtime; the next layer is state. Part 2 of this series covers the six most-used storage and database services on AWS — S3, EBS, EFS, RDS, DynamoDB, and ElastiCache — including the consistency, durability, and performance tradeoffs that govern how to choose between them. Part 3 covers application integration (API Gateway, SQS, SNS, EventBridge, Step Functions) and Part 4 ties everything together with security, observability, and infrastructure as code (IAM, CloudWatch, CloudFormation, Secrets Manager).

☁️ CONTINUE THE AWS DEEP DIVE SERIES

Post a Comment

Previous Post Next Post
Share to other apps
Copy Post Link