Data Ingestion & Transformation: Kinesis, Glue, Athena, and Lake Formation

Amazon Kinesis Data Streams is the ingestion backbone when your application needs to process streaming records in real time with its own code. Producers put records onto the stream; one or more consumer applications — AWS Lambda functions, containers running the Kinesis Client Library, Amazon Managed Service for Apache Flink — read and act on them within moments of arrival. That word consumers is the decision hinge: Data Streams gives you a durable, ordered buffer, and you bring the compute that reads it.

Three properties define it on the exam. First, retention and replay: records persist for 24 hours by default, extendable up to 365 days, and consumers can rewind and re-read — multiple independent applications can process the same stream, each tracking its own position and moving at its own pace. Retention is what makes replay possible: a consumer can only re-read records the stream still holds, so "reprocess the last two weeks" needs the retention period raised to cover two weeks before it is needed. A queue is different — Amazon SQS deletes a message once a consumer processes it, and consumers polling one queue compete for messages rather than each seeing every one. Second, ordering: a stream is divided into shards, and every record carries a partition key that determines its shard. Records sharing a partition key land in the same shard and are read in the exact order written — so "events for each device must be processed in order" resolves to Data Streams with the device ID as partition key. A random key per record spreads load perfectly but scatters one device's events across shards and loses that order. Third, capacity: a stream runs in provisioned or on-demand mode, and every shard has fixed write and read limits — the next section covers how to size it.

The cost of this power is that you own the consumer fleet: writing, deploying, scaling, and monitoring the code that reads the stream. When a scenario needs none of that — the data just has to land somewhere — Data Streams is over-engineering, which is where Firehose comes in.

The exam tests Data Streams by requirement keywords: "real-time processing," "multiple applications consume the same data," "replay events," or "strict per-key ordering" all point here, and an option that swaps in Firehose fails the moment custom consumers or replay are required.

A Kinesis data stream is sized in shards, and each shard has fixed limits: it accepts up to 1 MB per second or 1,000 records per second of writes, and it serves 2 MB per second of reads. Those per-shard numbers are the "sizes and speeds" the exam guide expects you to reason with — not to compute exact shard counts, but to recognize which limit a symptom points at.

Provisioned vs on-demand. In provisioned mode you choose the shard count and change it yourself (UpdateShardCount, or splitting and merging shards); stated throughput translates into shards, and you pay per shard-hour. In on-demand mode Kinesis adds and removes shards automatically from the observed write traffic, which makes it the low-overhead choice for spiky or unpredictable producers. Neither mode changes the per-shard limits — on-demand simply manages how many shards there are.

Hot partition keys. Every record with the same partition key is hashed to the same shard, always. So if one key carries more than a single shard can take — one large customer sending 3 MB/s under a customer-ID key — that shard throttles with ProvisionedThroughputExceededException even while the stream's total traffic is far below its aggregate capacity. Adding shards does not help: resharding divides the hash-key range, but one key is a single point in that range and still lands on one shard. On-demand mode cannot split a single key either. The fix is a finer-grained partition key that still preserves the ordering the application actually needs — for example the device ID instead of the account ID when order matters per device, not across a customer's devices. A random key would remove the hot shard but break per-entity ordering.

Consumer read models. By default consumers use shared throughput: every consumer polls each shard (GetRecords) and all of them split that shard's 2 MB/s and its limited read-call rate. Each extra consumer leaves less for the others, so adding applications produces ReadProvisionedThroughputExceeded errors, a rising iterator age, and higher latency. Enhanced fan-out registers a consumer for its own 2 MB/s per shard, pushed to it over HTTP/2 with SubscribeToShard at typically around 70 ms latency, so one consumer's reads never slow another. Adding shards or switching to on-demand only enlarges the shared pool — the next consumer added still eats into everyone else's share — and raising retention only stops lagging consumers losing data; it does nothing for the contention itself.

On the exam, read the symptom before the options: throttling despite low aggregate use is a key problem, contention between readers is a consumer-model problem, and only steady aggregate growth is a shard-count problem.

Amazon Data Firehose (long known as Kinesis Data Firehose) answers a different question: not "how do I process a stream" but "how do I get streaming data into a destination with no code and no infrastructure." Firehose is a fully managed delivery service — you point it at Amazon S3, Amazon Redshift, Amazon OpenSearch Service, or supported third-party and HTTP endpoints, and it handles batching, retries, scaling, and delivery entirely on its own. There are no shards to size, no consumers to write, nothing to administer.

Three behaviors matter for exam decisions. First, Firehose buffers: it accumulates records until a size or time threshold is reached, then delivers the batch. That makes it near-real-time, not real-time — even with the buffer interval turned down, data reaches a destination as delivered batches seconds later, which is fine for loading a data lake and wrong for a fraud check that a custom application must make within a fraction of a second. Second, Firehose transforms in flight: it can invoke an inline AWS Lambda function to clean, enrich, or reshape records, and it offers built-in record format conversion that turns incoming JSON into Apache Parquet or ORC before writing to S3 — columnar output with zero ETL jobs. It can also write into date-based S3 prefixes (and partition dynamically on record fields), and it can back up failed records to S3 for destinations such as OpenSearch Service. Third, Firehose is write-only from your point of view: it has no consumer interface. No application can read records out of a Firehose stream, it keeps no retained log, and it cannot be replayed — it is a pipe to a destination, not a buffer for readers.

That third point explains the classic composite. Firehose can take a Kinesis data stream as its source (as well as direct writes, or an Amazon MSK topic). So when one feed must drive a real-time consumer and be archived, you ingest once into Data Streams, let the real-time application (Lambda, KCL, or Managed Service for Apache Flink) consume it, and attach a Firehose stream that reads the same data stream and delivers raw records to S3. Ingesting into Firehose first fails, because the real-time application would have nothing to read; a second stream for the archive duplicates the ingestion path.

Amazon MSK (Managed Streaming for Apache Kafka) exists for one exam signal: the scenario names Kafka — existing producers and consumers written against Kafka client APIs, a self-managed Kafka cluster to retire, or Kafka ecosystem tooling — and the answer is MSK, where applications move by pointing at the new cluster's bootstrap brokers instead of being rewritten for another API.

On the exam, "no consumer code," "deliver to S3/Redshift/OpenSearch," "near-real-time," and "least operational overhead" are the four fingerprints of Firehose; "real-time with custom processing" or "replay" pulls you back to Data Streams, and "Kafka" pulls you to MSK.

Not all ingestion is streaming — a large share of Task 3.5 questions move files into AWS, and each transfer service owns one requirement shape. The deciding clues are frequency (one time, scheduled, continuous), who initiates (your own storage vs external partners), and what happens afterwards (data used in AWS vs still accessed on premises).

AWS DataSync is the online migration and scheduled-copy tool: an agent next to your on-premises NFS, SMB, or HDFS storage (or another cloud's object store) copies data over the network into S3, EFS, or FSx — one time for a migration, or on a schedule for recurring transfers — with encryption in transit, integrity verification, and incremental copies of only what changed built in. The source can stay the primary storage; DataSync just copies from it. Two configuration details carry exam weight. The agent is activated against a service endpoint type — public, FIPS, or a VPC service endpoint (an interface endpoint in your VPC); only the VPC endpoint keeps the transfer on private IP addresses, which is what a Direct Connect private virtual interface carries (a public endpoint needs the internet or a public VIF). And each task can take a bandwidth limit, so a copy never takes more than an agreed share of the link.

AWS Storage Gateway solves ongoing hybrid access, not transfer: on-premises applications keep reading and writing through a local gateway (S3 File Gateway exposing NFS/SMB shares backed by S3 with a local cache of recently used data, Volume Gateway for block storage, Tape Gateway for backup software) while the authoritative data lives in AWS. If the scenario says on-premises systems must continue accessing the data — and the dataset is bigger than local disk — that continuing, cached access is what separates Storage Gateway from DataSync. It means the applications write through the gateway, so it is the wrong fit when an existing NFS server must stay primary.

AWS Transfer Family gives external partners what they already use: fully managed SFTP, FTPS, and FTP into S3 (or EFS). It has two directions. A Transfer Family server endpoint is inbound: partners run their existing clients and connect to you, and files land directly in S3 — the answer when partners "upload files over SFTP" and you want no FTP server to patch. An SFTP connector is outbound: AWS connects to a remote SFTP server to send files to it or retrieve files from it — the answer when the partner runs the server and you must pull or push. Pick the one whose direction matches who runs the server.

Offline transfer after Snowball Edge. AWS Snowball Edge devices used to be the answer for bulk data over a slow or absent link, but no Snow Family device can be ordered by new customers (effective 7 November 2025); existing customers can keep using theirs. AWS now splits the job by whether the network can carry the data. For online transfers it recommends DataSync — and when the link is too slow for the timeline, DataSync over a temporary AWS Direct Connect hosted connection bought from a Direct Connect Delivery Partner for the length of the project. For offline transfers it recommends AWS Data Transfer Terminal (you bring your own storage devices to a secure AWS facility and upload at high speed) or an AWS Partner offline transfer service from AWS Marketplace. So "petabytes over a slow link" is not automatically DataSync: estimate whether the available bandwidth meets the deadline, and choose a physical path when it cannot. Edge-compute uses of Snowball map to AWS Outposts.

The exam tests this as pattern-matching under a LEAST-overhead qualifier: each option is a real transfer mechanism (or a hand-built one — a cron job, a script, an EC2-hosted SFTP server), and the frequency, direction and access clues select exactly one.

Securing an ingestion access point means controlling two things: which network path a request can use and who can send it. IAM decides who; VPC endpoints, resource-policy conditions and endpoint types decide the path. The exam guide lists this as its own knowledge item, and the questions turn on where each control is enforced.

Private access to Kinesis and Firehose. Producers in private subnets with no internet gateway or NAT gateway reach Kinesis Data Streams and Amazon Data Firehose through an interface VPC endpoint (AWS PrivateLink) for each service. With private DNS enabled on the endpoint, the standard service hostname resolves to the endpoint's private IP addresses, so SDK code needs no change and traffic never leaves private addressing. DataSync agents use the same idea through a VPC service endpoint, and S3 is reached privately through a gateway or interface endpoint.

Making the resource reject other paths. An endpoint gives producers a private path; it does not stop someone else using a public one. To make the stream itself refuse requests that did not come through the approved endpoint, add a resource-based policy to the data stream (Kinesis Data Streams supports them) with a Deny on the write actions when aws:SourceVpce is not the approved endpoint ID. The S3 equivalent is a bucket policy with the same condition. Where the condition lives matters:

Transfer Family endpoint types. A Transfer Family server has one of three endpoint configurations, and partner network requirements select it:

The IAM role attached to a Transfer Family user controls what the service may do in S3 on that user's behalf; it is not a network control over which client IPs may connect. CloudFront and AWS WAF handle HTTP(S), so they cannot sit in front of SFTP. The remaining controls are the standard ones: KMS server-side encryption for streams, Firehose and S3 at rest, TLS in transit, and per-user credentials (service-managed keys or an identity provider) for Transfer Family instead of shared server logins.

On the exam, "reject requests that don't use the approved path, even from principals with valid IAM permissions" means a resource-policy Deny on aws:SourceVpce; "partners need fixed IPs and only their ranges may connect" means a VPC-hosted internet-facing Transfer Family endpoint with Elastic IPs and a security group.

A data lake on AWS is not a product — it is Amazon S3 holding raw and transformed data at any scale, plus a metadata catalog that makes the objects queryable as tables. S3 wins the storage role on every axis the exam cares about: effectively unlimited capacity, eleven-nines durability, lifecycle tiering for cost, and native integration with every analytics service. Data lands in the lake through the ingestion paths already covered — Firehose delivery, DataSync copies, Transfer Family uploads — typically organized into zones (raw, cleaned, curated) by prefix.

Securing the lake used to mean sprawl: bucket policies for S3, IAM policies per analytics service, and no single view of who can read which table. AWS Lake Formation exists to collapse that sprawl. It layers a centralized permissions model over the S3 data and the Glue Data Catalog: you grant users and roles access at the database, table, and column level in one place, and those grants are enforced consistently across Athena, Redshift Spectrum, Glue, and EMR. Instead of maintaining parallel bucket policies and per-service IAM statements, one Lake Formation grant answers "can this analyst see this column." Lake Formation also helps stand the lake up — registering S3 locations, crawling and cataloging data — but its exam identity is governance: fine-grained, centralized data-lake permissions.

Lake Formation governs the data once it is in the lake; the doors into the lake — streams, delivery streams, transfer endpoints and buckets — are secured with VPC endpoints, resource policies and endpoint configuration, covered in the access-point section above. Beyond database, table and column grants, Lake Formation also supports row-level data filters and tag-based access control, but the exam signature is centralized, fine-grained permissions in one place.

On the exam, "centrally manage fine-grained access to a data lake" or "grant column-level permissions across Athena and Redshift Spectrum" is Lake Formation by definition — options that hand-assemble the same result from bucket policies and per-service IAM are the operational-overhead distractors.

AWS Glue is the transformation layer of Task 3.5, and it earns two separate exam identities.

The first is the Glue Data Catalog: a central, persistent metadata store — table definitions, schemas, partition locations — describing data wherever it sits, most importantly in S3. Glue crawlers populate it automatically: point a crawler at an S3 prefix, and it samples the objects, infers the schema (even for undocumented JSON layouts), detects partitions, and writes table definitions into the catalog. When a scenario says analysts "cannot query the files in S3 because there is no schema," the crawler-plus-catalog pair is the answer, followed by Athena querying the objects in place; hand-writing CREATE EXTERNAL TABLE statements works but is exactly the effort a crawler removes, and converting to Parquet is an optimization, not a way to make data queryable.

The catalog is shared infrastructure. Athena uses it by default; Amazon EMR can be configured to use the Glue Data Catalog as its Apache Hive metastore for Spark, Hive and Presto/Trino; and Redshift Spectrum reads it through an external schema created FROM DATA CATALOG. One set of table definitions then serves all three engines. The alternative is an external Hive metastore (for example on Amazon RDS or Aurora), which EMR and Redshift Spectrum also support — but if Athena already uses the Glue catalog, a Hive metastore adds another catalog that must be operated and kept synchronized. Separate crawler-built databases per engine duplicate every definition in the same way.

The second identity is serverless ETL. Glue jobs run Apache Spark (or lightweight Python) transformations — cleaning records, joining datasets, and above all converting formats, such as CSV to Parquet — without any cluster for you to provision, size, or patch. Jobs run on a schedule, on demand, or from event triggers. Because it is serverless, Glue is the default ETL answer under a LEAST-operational-overhead qualifier; an EMR cluster, a cron script on EC2, or a load-and-UNLOAD round trip through Redshift can all do the conversion with more to operate.

Two job settings make recurring ETL efficient. Job bookmarks record what a job has already processed, so each run reads only the source data that arrived since the last successful run — the fix for a daily job whose runtime grows every day and which writes duplicate rows by reprocessing old files. Bigger workers only make the full reprocess faster, and a crawler's incremental crawl (crawling only new folders) affects what gets cataloged, not what the ETL job reads. And writing output with partition keys (for example partitionKeys on the order date) lays the Parquet out in column=value prefixes that the catalog can register as partitions, so Athena prunes on the date filter.

The exam tests Glue at decision level: recognize the crawler as the schema-inference mechanism, the catalog as the shared metastore that links S3 to every query engine, and Glue jobs — with bookmarks for incremental input and partitioned output — as the no-cluster way to transform data between formats.

Once data is cataloged, three services compete to query it, and SAA-C03 separates them by workload shape rather than feature lists.

Amazon Athena is serverless, interactive SQL directly against S3, using the Glue Data Catalog for schemas. There is no cluster and no data loading — you pay per data scanned by each query. That makes Athena the answer for ad hoc, occasional, or unpredictable querying of data that lives in S3: incident investigations a few times a month, one-off analyses, light reporting — nothing runs or bills between queries. Its economics also create its one design obligation — because you pay by bytes scanned, format and partitioning matter enormously, which the format section covers.

Amazon Redshift is a data warehouse: data is loaded into Redshift's own managed, columnar storage, where repeated, complex BI workloads — dashboards hit constantly, heavy joins and aggregations across billions of rows, hundreds of concurrent analysts — run with consistently high performance. The trade is overhead and commitment: you operate a warehouse (or use Redshift Serverless) and maintain load pipelines. Redshift Spectrum blurs the edge by letting Redshift query S3 data through the same Glue catalog, joining warehouse tables with lake data in one SQL statement. Neither OpenSearch Service (search and log analytics on an always-on domain) nor DynamoDB (key-value, no joins) is a substitute for either.

Amazon EMR is managed big-data processing — Spark, Hadoop, Hive, Presto/Trino — for when you need framework-level control: custom Spark applications, specific library versions, long-running distributed jobs that SQL cannot express. It is the most powerful and the most operationally expensive of the three, and it comes in more than one deployment model. The compute choice for Spark work is decided by how much control the workload needs:

Expect the exam to qualify these questions hard: "serverless" plus "infrequent" eliminates Redshift, "consistently fast dashboards for hundreds of analysts" eliminates Athena, and a named framework with custom code and node access eliminates both in favor of EMR on EC2 — unless Glue's serverless Spark covers the job with less overhead. Dashboards on top of any of these are the visualization layer, next.

Amazon QuickSight is AWS's serverless business-intelligence service: it builds interactive, shareable dashboards with filtering and drill-down over Athena, Redshift, S3 and many other sources, with no BI servers to run. AWS now offers it as Amazon Quick Sight, the BI capability within Amazon Quick; the exam guide still uses the name Amazon QuickSight, and both names mean the same dashboarding service. CloudWatch dashboards (operational metrics), OpenSearch Dashboards (search and log analytics on a domain you run) and a BI server on EC2 are the usual near-misses.

The design decision inside QuickSight is how a dataset gets its data:

When the underlying data loads once a night and hundreds of users filter dashboards all day, the low-overhead fix is to import the dataset into SPICE and schedule its refresh to run after the nightly load. Keeping direct query and adding tricks does not change the shape of the cost: Athena query result reuse only returns cached results for an identical query run again within the configured maximum age, so dashboards with many different filters still mostly scan; and a smaller summary table cuts bytes per query but still makes every click a live Athena query. Loading the data into a provisioned warehouse is faster but adds a cluster to run.

The single most repeatable optimization in this task statement is a format change. Row-based text formats like CSV and JSON force a query engine to read every byte of every record even when the query touches two columns. Columnar formats — Apache Parquet and ORC — store each column's values together, so Athena reads only the columns the query names; they also compress far better, because a column of similar values compresses more tightly than interleaved rows. Since Athena bills per data scanned, converting a lake from CSV to compressed Parquet routinely cuts both query cost and query time by large multiples — same data, same SQL, a fraction of the bytes touched. Storage-class changes such as S3 Intelligent-Tiering lower storage cost, not bytes scanned.

Partitioning is the second lever, and it has a trap: an S3 prefix is not a partition. Athena prunes only on partitions defined on the table. Writing objects under date prefixes and defining one unpartitioned table over them still scans everything; the date filter has no partition column to act on. A partitioned table gets its partitions in one of these ways:

Partition projection fits streaming lakes especially well. Firehose writes by default under UTC YYYY/MM/DD/HH prefixes, which are not Hive-style, so MSCK cannot discover them; a projection with a date type and a location template that maps those path segments lets Athena prune immediately, with no crawler to schedule. Partition on the columns queries actually filter by — usually date.

You already know the conversion paths. For data already in S3, a Glue ETL job reads the CSV and writes partitioned, compressed Parquet (with job bookmarks so daily runs handle only new files). For streaming data, Firehose format conversion writes Parquet from the start — no post-hoc ETL, which wins any LEAST-overhead comparison for new pipelines. Two Athena features are not layout fixes: query result reuse returns a stored result when the same query text is rerun inside its maximum-age window, so a new filter or date range still scans; and CTAS (CREATE TABLE AS SELECT) creates a new table and fails if its target S3 location already holds data, so it suits one-off conversions rather than a rerunnable daily incremental job (appends use INSERT INTO, and rewriting the whole prefix each run grows cost with total volume).

This is tested as a cost/performance scenario with a giveaway sentence: "queries scan the entire dataset," "Athena costs are growing," or "analysts only query recent data." The correct option combines columnar conversion with real partitions; distractors throw capacity at the problem — moving to Redshift, adding EMR nodes — or rely on prefixes, caching or storage tiers when the data layout was the actual defect.

Task 3.5 questions increasingly describe whole pipelines, and the strongest preparation is holding the reference chain in your head: ingest → transform → store → catalog → query → visualize, with two or three service candidates at each stage.

A representative streaming architecture: producers (applications, IoT devices, clickstream collectors) write to Kinesis Data Streams if real-time consumers, replay, or per-key ordering are required — otherwise straight into Amazon Data Firehose. Firehose applies an inline Lambda transform if records need cleaning, converts to Parquet, and delivers into partitioned prefixes in the S3 data lake. A Glue crawler keeps the Data Catalog current; Lake Formation governs who can query which tables and columns. Athena serves ad hoc SQL, heavy repeated BI loads into Redshift, custom Spark jobs run on EMR or serverless Glue, and QuickSight (Amazon Quick Sight) dashboards sit on top, usually from SPICE. Batch and file-based sources merge into the same lake through DataSync schedules or Transfer Family endpoints.

Reading a pipeline question, work stage by stage and eliminate per stage: does ingestion need consumers or just delivery? Does transformation need a cluster or does Glue/Firehose cover it? Does querying justify a warehouse or is pay-per-scan Athena enough? Each stage usually has exactly one qualifier word — "near-real-time," "no infrastructure to manage," "ad hoc" — that fixes the choice.

Frequency and volume clues size the ingestion stage. Continuous record-by-record arrival is streaming; hourly or nightly batches are transfer or scheduled ETL; a one-time bulk load is DataSync when the network can carry it in time (adding a temporary Direct Connect hosted connection if needed), or a physical path — AWS Data Transfer Terminal or a Partner offline service — when it cannot, since Snowball Edge is no longer offered to new customers. Where throughput numbers appear, they select capacity, not service internals: a Data Streams shard ingests up to 1 MB or 1,000 records per second and serves 2 MB per second of reads, so stated rates translate to a shard count — while a single hot partition key or too many shared-throughput readers are limits more shards cannot fix — and if the scenario calls the traffic spiky or unpredictable, on-demand mode (or Firehose, which scales invisibly) removes the sizing exercise altogether. You are never asked to compute precise capacity; you are asked to notice when a requirement outgrows a fixed configuration.

The exam tests this compositionally: four answer options each name a full chain, three of which contain one wrong link — Data Streams with no consumer, EMR for a trivial format conversion, Redshift for occasional queries. Verify every link, not just the first.

Scenario 1. A media company collects clickstream events from its web applications and must land them in an S3 data lake in Apache Parquet format for analysis with Athena. Near-real-time delivery (within minutes) is acceptable. The team wants a solution with the LEAST operational overhead and does not want to write or manage any consumer applications. What should the architect choose?

Reasoning: Strike the options stage by stage. Kinesis Data Streams with a Lambda consumer writing Parquet works, but it exists to serve custom real-time consumers — the scenario explicitly rules out consumer code, and the Lambda plus its error handling is precisely the overhead being minimized. MSK requires Kafka clients and cluster-adjacent management with no Kafka requirement in sight. A Glue batch job converting CSV drops on a schedule fails "near-real-time" and adds a second hop. The answer is Amazon Data Firehose with its built-in format conversion to Parquet, delivering directly into partitioned S3 prefixes: fully managed, no consumers, no shards, near-real-time by design — and its buffering delay is acceptable because the scenario said minutes are fine. Every requirement sentence maps to a Firehose property; that alignment is what a correct SAA-C03 answer looks like.

Scenario 2. An analytics team queries three years of CSV application logs in S3 using Athena. Queries have grown slow and expensive; the team reports that even queries filtered to a single week "scan the entire dataset." They want to reduce Athena cost and query time with the LEAST change to their workflow. What do you recommend?

Reasoning: The complaint names both defects. "CSV" means every query reads every byte of every row — the fix is a Glue ETL job converting the logs to compressed Parquet, so Athena scans only the referenced columns. "A single week scans everything" means the data is unpartitioned — the fix is writing the Parquet output partitioned by date and making sure the table actually defines those partitions (a crawler, or partition projection) — prefixes alone prune nothing; week-filtered queries then touch only seven days of partitions. Together the two changes cut billed bytes on both axes while the team keeps the same Athena SQL workflow. The distractors fail the qualifier: migrating to Redshift solves speed by adding a warehouse to load, operate, and pay for — a workflow change, not a data-layout fix; EMR with Presto swaps serverless for a cluster; and "increase Athena capacity" is not a lever that exists — Athena is serverless, and its cost dial is bytes scanned.

Scenario 3. Hundreds of retail partners currently upload nightly inventory files over SFTP to an on-premises server, which is being retired. Files must end up in S3 for a Glue pipeline, and partners cannot change their upload tooling. What replaces the server?

Reasoning: "Partners keep using SFTP" plus "files into S3" is the signature of AWS Transfer Family: a managed SFTP endpoint backed directly by S3, per-partner credentials, nothing to patch. DataSync is wrong-shaped — it is the company pulling data from its own storage, not partners pushing; Storage Gateway serves ongoing on-premises access to AWS-resident data, and an EC2-hosted SFTP server recreates the retired problem inside AWS; and Transfer Family SFTP connectors are the wrong direction — they connect out to servers the partners would have to run. When the protocol is fixed by an external party, pick the service that speaks it natively.