High-Performing Networking and Data Pipelines

Two services optimize network paths for global users, and picking between them comes down to what kind of traffic you're sending. Amazon CloudFront is a content delivery network: it caches HTTP and HTTPS content at edge locations close to users, so a repeat request for the same object never has to reach your origin at all. It's the right fit for cacheable content — static assets, video, API responses that don't change per request.

AWS Global Accelerator operates at the network layer instead, for TCP and UDP traffic generally, including traffic CloudFront can't cache — a gaming server, a VoIP application, a non-HTTP protocol. It gives you two static anycast IP addresses as a fixed entry point, routes each connection onto the AWS global network at the nearest edge location, and continuously steers traffic toward the healthiest, best-performing regional endpoint — without caching anything. The two aren't competitors: a web application often puts CloudFront in front of its cacheable HTTP surface and Global Accelerator in front of a non-HTTP or non-cacheable TCP/UDP surface behind the same architecture.

aws globalaccelerator create-accelerator \
  --name my-accelerator \
  --ip-address-type IPV4 \
  --enabled

Connecting a data center or office to AWS has two well-known paths. AWS Direct Connect is a dedicated, private physical connection from your premises to an AWS Direct Connect location — it bypasses the public internet entirely, giving consistent, predictable latency and bandwidth (1 Gbps, 10 Gbps, or higher), which matters for large, steady data transfers or latency-sensitive hybrid workloads. Setting it up takes real lead time: physical cross-connects, a partner, weeks to months.

A site-to-site VPN is the faster alternative: an encrypted tunnel over the public internet between your network and a virtual private gateway, set up in minutes rather than weeks, at a fraction of the cost — but subject to the public internet's variable latency and throughput. The two aren't mutually exclusive: a common pattern pairs a Direct Connect connection for steady-state traffic with a VPN as an automatic failover path if the dedicated connection goes down.

Inside the VPC itself, a multi-tier design places each layer in the subnet tier that matches its exposure: a public subnet for internet-facing load balancers, a private subnet for application servers, and often an isolated subnet with no route to the internet at all for databases. Load balancer choice follows the traffic: an Application Load Balancer operates at layer 7 for HTTP/HTTPS, making routing decisions on path or host; a Network Load Balancer operates at layer 4, for extreme throughput and a static IP per Availability Zone, for protocols beyond HTTP.

For resources that need to reach AWS services without touching the internet at all, a VPC interface endpoint (built on AWS PrivateLink) gives a private IP inside the VPC for the service — the same tool covered when securing workloads, now viewed through a performance lens: fewer hops, no NAT gateway bottleneck.

Streaming ingestion splits into two AWS services with different jobs. Amazon Kinesis Data Streams is the raw, real-time pipe: producers write records into shards, and you write custom consumer applications (on EC2, Lambda, or Kinesis Data Analytics) that read and process them, with records staying available for a retention period — 24 hours by default, extendable up to 365 days — so more than one consumer can replay the same data independently. Amazon Data Firehose takes the opposite tradeoff: it's a fully managed delivery pipe with no persistent storage of its own, automatically scaling to load streaming data directly into a destination like Amazon S3, Amazon Redshift, or OpenSearch, in near real time — and it can convert incoming JSON records into Parquet or ORC on the way in, using the schema from an AWS Glue Data Catalog table.

Reach for Data Streams when you need custom, low-latency processing logic and possibly more than one independent consumer of the same data. Reach for Firehose when the job is "get this stream of records into a destination, reliably and with minimal setup."

aws kinesis create-stream \
  --stream-name clickstream \
  --stream-mode-details StreamMode=ON_DEMAND

Once raw data lands in S3, three services turn it into something queryable. AWS Glue is serverless ETL: a crawler connects to a data source, infers its schema, and populates the Glue Data Catalog — a central metadata store of databases and tables that other services read from. A Glue job then runs the actual transformation (commonly on Apache Spark) — for example, converting a folder of CSV files into compressed, columnar Parquet, which is both cheaper to store and faster to query.

Amazon Athena is a serverless SQL query engine that reads directly from S3, using table definitions from the Glue Data Catalog, and bills per query rather than per running server — there's no cluster to provision or manage, which makes it the natural choice for ad hoc analysis over data already sitting in a data lake.

AWS Lake Formation sits above both: it centralizes fine-grained permissions (down to the table, column, or row) across everyone and everything that touches the data lake — Athena queries, Glue jobs, and more — instead of managing a separate access policy per service.

Getting data into that lake in the first place is a separate question from streaming: sometimes it's a one-time or scheduled bulk transfer, not a continuous stream. AWS DataSync automates exactly that: an online transfer service that moves large datasets between on-premises NFS or SMB storage and Amazon S3, EFS, or FSx (or between AWS storage services), with built-in scheduling, retries, and data-integrity verification.

AWS Storage Gateway solves a different problem: ongoing, hybrid access rather than a one-time move. A File Gateway lets on-premises applications read and write S3 objects using NFS or SMB; a Volume Gateway presents cloud-backed iSCSI block storage; a Tape Gateway presents a virtual tape library for backup software that still expects one. The distinction to hold onto: DataSync moves data; Storage Gateway gives ongoing local access to data that lives in AWS.

Domain 3's five task statements all ask the same underlying question in different clothes: given a workload's numbers — IOPS, latency, RAM, requests per second, records per second — which AWS service removes the bottleneck those numbers describe? Storage answers with volume type or file system; compute answers with instance family or serverless option; databases answer with engine and capacity mode; networking answers with edge service and connection type; ingestion answers with streaming or batch service. The skill this domain tests isn't memorizing every service — it's reading a scenario's specific numbers and constraints and matching them to the one service built for that shape of problem.

Real architectures rarely solve a performance requirement with a single service. A product page that needs to survive a launch-day spike might combine a memory-optimized ElastiCache layer in front of Aurora, an Auto Scaling group of compute-optimized instances behind an Application Load Balancer, and CloudFront caching the static assets — four services from three different task statements, each solving one piece of the same requirement.

Work a composite scenario the way the exam will: a photo-sharing app needs to (1) store and serve millions of images cheaply and durably, (2) resize images on upload without running servers around the clock, (3) look up a user's photo feed by user ID at unpredictable, spiky scale, and (4) serve images to a global audience with low latency. Four requirements, four services, each chosen by naming the bottleneck: image storage is discrete objects with no need for a file system, so that's Amazon S3. Resizing on upload is short, event-driven, bursty work with no idle cost wanted, so that's AWS Lambda triggered by an S3 event. Looking up a feed by user ID at unpredictable scale is a key-based access pattern, so that's DynamoDB in on-demand mode. Serving images globally with low latency is cacheable HTTP content, so that's CloudFront in front of the S3 bucket.

Notice what's absent: no EC2 instance, no relational database, no Kinesis stream. The framework doesn't reach for a service because it's familiar — it reaches for the one service whose defining strength matches the requirement actually stated.