Networking, Operations, and Pricing

VPC is a service that lets you launch AWS resources inside a logically isolated virtual network that you define yourself, letting you build a configuration on AWS that closely resembles a traditional network in your own data center. Delivering content from edge locations is CloudFront's job, providing domain registration, DNS routing, and health checks is Route 53's job, and running a dedicated connection that bypasses ISPs along the route is Direct Connect's job.

A subnet is an IP address range within a VPC that always belongs to a single Availability Zone. So a subnet cannot span AZs, and distributing across multiple AZs means creating one subnet per AZ. Deciding where traffic is directed is the route table's job, and the gateway to the internet is the internet gateway — both are separate components from a subnet.

A route table is a table that decides where traffic from a subnet or gateway is directed. Carving out the IP address range is the subnet's job, providing the connection to the internet is the internet gateway's job, and proxying outbound traffic for resources with private IPs is the NAT gateway's job. The four components do not overlap in their roles.

A NAT gateway is a mechanism that lets a resource with a private IP address access the internet while remaining private. Because it only proxies traffic from inside going out, an inbound connection from outside cannot be established through it. An internet gateway connects the VPC itself to the internet and is not a component placed inside a subnet. Direct Connect is a dedicated connection to an on-premises network, and CloudFront is a content delivery service — neither is used for this purpose.

Route 53 is a highly available, scalable DNS web service with three functions — domain registration, DNS routing, and health checking — which can be combined in any way you need. Content delivery is CloudFront's job, and distributing incoming traffic is Elastic Load Balancing's job; neither is a function of Route 53.

CloudFront is a CDN that speeds up the delivery of both static and dynamic web content. It is often assumed to deliver only static files, but the official description includes dynamic content as well. Delivery happens through a worldwide network of data centers called edge locations, from whichever location has the lowest latency. Handling a dedicated connection to an on-premises network is Direct Connect's job, not CloudFront's.

Direct Connect is a service that connects an on-premises network to a Direct Connect location using standard Ethernet fiber-optic cable, bypassing the ISPs along the network path, and creates a virtual interface directly to AWS services. The key point is that it is a dedicated connection that does not go over the internet, which is where it differs from an approach that builds an encrypted tunnel over the internet.

A route table is a table that decides where traffic from a subnet or gateway is directed. A subnet whose route table has a route to an internet gateway is conventionally called a public subnet, and one without such a route is called a private subnet. A subnet always belongs to a single AZ, so the number of AZs does not distinguish them. When a resource in a private subnet goes outbound, it goes through a NAT gateway.

An origin is the location that holds the source of the content CloudFront delivers, such as an S3 bucket or an HTTP server. When the content requested is not at the edge location, CloudFront fetches it from the origin and delivers it. Returning content from the location closest to the user is the edge location's job, the intermediate caching layer between an edge location and the origin is the Regional Edge Cache, and directing a destination in response to a name lookup is Route 53's DNS routing.

Route 53 is a DNS web service whose three functions — domain registration, DNS routing, and health checking — can be combined in any way you need. It is not a system where all three must be present to function, so you can leave the domain registered elsewhere while entrusting only DNS routing to Route 53, or use only health checking. Transferring the domain is not a prerequisite for using it.

ALB operates at Layer 7, the application layer, handling HTTP, HTTPS, and gRPC. Because it looks this deep, it can use the contents of HTTP as a basis for decisions, enabling flexible routing such as content-based routing. NLB operates at Layer 4 (TCP, UDP, TLS), and Gateway Load Balancer operates at Layers 3 and 4 (IP).

NLB is a Layer 4 load balancer that handles TCP, UDP, and TLS. It is the choice when you need extremely high performance and a static IP address. Handling HTTP, HTTPS, and gRPC is the Layer 7 ALB's job, and passing IP traffic through transparently without terminating flows is Gateway Load Balancer's job. gRPC is not on NLB's list of supported protocols.

GWLB operates at Layers 3 and 4, handling the IP protocol. It is a mechanism for placing appliance-based security or network functions in the traffic path, and the decisive difference from the other two is that it passes flows through transparently without terminating them. Routing by looking at HTTP contents is the Layer 7 ALB's forte, and a static IP with UDP is the Layer 4 NLB's forte.

When a static IP address is required, choose NLB. NLB operates at Layer 4 and is officially positioned as suited to scenarios requiring extremely high performance and a static IP. ALB operates at Layer 7, handling HTTP, HTTPS, and gRPC, with content-based routing as its forte. GWLB is for inserting an appliance transparently. Classic Load Balancer is an older generation that supports TCP, SSL/TLS, HTTP, and HTTPS.

ELB automatically distributes incoming application traffic across multiple targets in one or more Availability Zones. It is not confined to a single AZ, and being able to distribute across targets split among multiple AZs is the foundation of availability design. Domain name registration is Route 53's job, and delivery from edge locations is CloudFront's job.

The protocols ALB handles are HTTP, HTTPS, and gRPC, and it operates at Layer 7. Of these options, ALB is the only one that can directly handle gRPC. NLB is a Layer 4 load balancer handling TCP, UDP, and TLS, and GWLB is a Layer 3/4 load balancer handling IP. Classic Load Balancer supports TCP, SSL/TLS, HTTP, and HTTPS.

NLB is a Layer 4 load balancer that handles TCP, UDP, and TLS, so it can distribute UDP traffic. What ALB handles is HTTP, HTTPS, and gRPC, which does not include UDP. GWLB handles IP, but it is meant for passing traffic transparently to an appliance, not for general-purpose load balancing. Classic Load Balancer supports TCP, SSL/TLS, HTTP, and HTTPS.

ALB handles HTTP, HTTPS, and gRPC at Layer 7; NLB handles TCP, UDP, and TLS at Layer 4; and GWLB handles IP at Layers 3 and 4. It helps to remember the lineup by thinking that the higher the layer number, the more high-level information is visible for routing decisions. GWLB alone spans two layers because of its nature of passing IP packets through transparently as is.

Routing based on the contents of HTTP, such as the path or hostname, is called content-based routing and is the forte of ALB, which operates at Layer 7. NLB operates at Layer 4, so it does not see the contents of HTTP. GWLB passes flows through without terminating them, so the only thing available for routing decisions is IP. Classic Load Balancer is also an older-generation design; ALB is the choice for this purpose.

GWLB operates at Layers 3 and 4, handling the IP protocol, and is a load balancer designed for appliance-based security or network functions. Because it passes flows through transparently without terminating them, inserting an inspection appliance in the middle does not change how the traffic looks. ALB and NLB are designed to receive traffic themselves and distribute it, not to pass it through transparently. CloudFront is a content delivery service.

IAM is a service that securely controls access to AWS resources, managing who is authenticated (signed in) and who is authorized (holds permissions). Creating and controlling keys is KMS's job, monitoring and controlling HTTP requests is WAF's job, and storing and rotating credentials and API keys is Secrets Manager's job. The roles do not overlap.

IAM is a service that manages "who is authenticated (signed in) and who is authorized (holds permissions)." Authentication is the step of confirming you are who you say you are, and authorization is the subsequent step that decides what you are allowed to do — they differ both in order and in role. Even if you can sign in, you cannot perform an operation not permitted by policy. Swapping the two when memorizing them leads to misreading permission design.

KMS is a managed service that makes it easy to create and control keys used for encryption and signing, and a KMS key is protected by an HSM certified to FIPS 140-3 Security Level 3. The key never leaves KMS in an unencrypted state. So exporting or distributing it in plaintext is not something that can be done; instead, encryption and decryption operations are requested from KMS.

WAF monitors HTTP and HTTPS requests forwarded to a protected web application resource and controls access using actions such as allow, block, count, and CAPTCHA or challenge. Because there is a count action, you can measure the impact before turning a rule into a full block, rather than blocking immediately. Encryption and signing belong to KMS, logging and visualization to CloudWatch, and domain registration and name resolution to Route 53.

Shield provides protection against DDoS attacks. Standard is basic protection automatically included at no extra cost with things like AWS WAF, and Advanced is extended protection available for an additional fee. Advanced provides automatic mitigation of Layer 7 DDoS attacks, detailed visibility, and dedicated support from the Shield Response Team (SRT). Watch out for an answer choice that reverses which one costs extra.

Shield Advanced is extended protection for an extra fee, providing automatic mitigation of Layer 7 DDoS attacks, detailed visibility, and dedicated support from the Shield Response Team (SRT). Rotation is Secrets Manager's job, centrally managing protection across multiple accounts is AWS Firewall Manager's job, and a user directory with token issuance is Amazon Cognito's user pools.

Secrets Manager is a service that manages, retrieves, and rotates secrets — such as database credentials, application credentials, OAuth tokens, and API keys — across their entire lifecycle. Sign-in and token issuance is Cognito's job, recording configuration and evaluating compliance is AWS Config's job, and creating and protecting the keys themselves is KMS's job. It helps to remember Secrets Manager as the one that carries values around.

A user pool is a user directory that authenticates and authorizes users for apps and APIs, functioning as an independent OIDC identity provider that issues OAuth 2.0 tokens and JWTs. An identity pool grants authenticated or unauthenticated users access to AWS resources, issuing temporary AWS credentials via AWS STS. Integrating the two is not mandatory for either; each can be used on its own.

An identity pool is a mechanism that grants authenticated or unauthenticated users access to AWS resources, issuing temporary AWS credentials via AWS STS. What a user pool issues is OAuth 2.0 tokens and JWTs, which are not credentials for calling AWS APIs directly. Distributing long-term credentials, or creating an IAM user per user, is not suited to this purpose.

Firewall Manager is a service that centrally manages protections — such as AWS WAF, Shield Advanced, VPC security groups and network ACLs, Network Firewall, and Route 53 Resolver DNS Firewall — across multiple accounts and resources. Inspecting individual requests is WAF's own job, creating keys is KMS's job, and handling sign-in information is Cognito's job.

CloudWatch monitors AWS resources and the applications running on them in real time, visualizing performance, operational status, and resource utilization through metrics, logs, alarms, and dashboards. Recording who performed which API operation is CloudTrail's job, recording configuration and its changes is AWS Config's job, and building resources from templates is CloudFormation's job.

CloudTrail records the actions taken by users, roles, and AWS services as events. It covers operations through the management console, CLI, and SDK or API, letting you trace afterward who performed which API operation. CloudWatch handles performance and status monitoring, CloudFormation handles building from templates, and Systems Manager handles operational tasks on nodes — none of them is aimed at tracing who performed an action.

Config provides a detailed view of resource configuration, recording relationships between resources and how they were configured in the past so configuration changes can be tracked. It also evaluates configuration with Config rules, flagging non-compliant resources that violate them. Monitoring thresholds is CloudWatch's job, building from templates is CloudFormation's job, and recording operations is CloudTrail's job.

It helps to memorize the three together: CloudWatch is real-time monitoring of performance and status, CloudTrail is a record of who performed which API operation, and Config is a record of resource configuration and an evaluation of compliance. They are not competing services — a CloudTrail trail is stored in an S3 bucket and can optionally also be delivered to CloudWatch Logs, making CloudTrail the sender and CloudWatch Logs a possible receiving end.

In CloudFormation, you create a template, a text file describing the resources you need, and CloudFormation provisions and configures the resources accordingly. The resources created can be managed together as a single unit called a stack, and can also be deleted together. So a template corresponds to a blueprint, and a stack corresponds to the resulting group of resources.

The group of resources CloudFormation creates can be managed as a single unit called a stack, and it can also be deleted all at once. It is not the case that resources can only be handled individually; deleting the stack deletes the resources it contains together with it. Recording configuration changes over time is AWS Config's role. Being able to build as a group and tear down as a group is a benefit of treating infrastructure as code.

Systems Manager is a unified interface for viewing, managing, and operating nodes across AWS, on-premises, and multi-cloud environments centrally at scale, including capabilities such as Run Command, Session Manager, Automation, Parameter Store, Patch Manager, and Fleet Manager. Recording configuration is Config's job, building from templates is CloudFormation's job, and distributing traffic is ELB's job.

Spot Instances are a purchasing option that uses unused EC2 capacity in the AWS Cloud, offering a substantial discount but with the possibility of interruption. They suit batch processing or test environments that can tolerate interruption. Committing to usage is Savings Plans, committing to instance attributes is a Reserved Instance, and having no upfront payment or commitment is On-Demand.

Savings Plans is a pricing model that gives a discount in exchange for committing to a set usage level, while a Reserved Instance is a pricing model that gives a discount in exchange for committing to attributes such as instance type, platform, and tenancy. Both have terms of 1 year or 3 years, and payment can be chosen as all upfront, partial upfront, or no upfront. It is Spot Instances that can be interrupted.

Compute Savings Plans are the most flexible, supporting changes in instance family, changes in Region, moving between EC2, Fargate, and Lambda, and changes of OS. EC2 Instance Savings Plans commit to a specific instance family in a specific Region, so while size changes within the family and OS changes are possible, changing family or Region is not. The term for both is 1 year or 3 years, and payment can be chosen as all upfront, partial upfront, or no upfront.