Simulado AWS Data Analytics Specialty DAS-C01

Partitioning the table by the exact columns used in WHERE filters (event_date and country) lets Athena prune to only the matching S3 prefixes, so a query touching one day and one country scans a tiny fraction of the 60 TB instead of all of it — this directly cuts both latency and scanned-bytes cost, and partition projection eliminates the operational overhead of catalog maintenance. Loading 60 TB into Redshift adds a cluster to provision and manage for what is an ad-hoc S3 query workload, and DISTKEY governs node distribution, not the scan reduction the question needs — it is heavier operationally, not lighter. OpenSearch is built for full-text search and log analytics with high ingest/storage cost; ingesting 60 TP of historical Parquet just to apply equality filters is an expensive, wrong-engine choice. Converting Parquet to CSV makes things worse — CSV is row-based and uncompressed relative to columnar Parquet, so Athena would scan far MORE data; result reuse only helps identical repeated queries, not the varied date/country filters described.

Shard sizing must satisfy the most restrictive (binding) limit across all dimensions. Writes need ceil(4 MB/s ÷ 1 MB/s) = 4 shards and ceil(3,000 rec/s ÷ 1,000 rec/s) = 3 shards; shared reads of 4 MB/s need ceil(4 ÷ 2) = 2 shards. The maximum of these is 4, so 4 shards is the minimum to avoid throttling — the data-volume write limit dominates. The 3-shard answer is wrong because it only satisfies the records-per-second constraint (3 shards) and ignores that 4 shards are needed for the 4 MB/s write volume, so producers would still be throttled. The 2-shard answer is wrong because it sizes only for read throughput and ignores the larger write requirement. The 1-shard answer is wrong because standard (provisioned) Kinesis Data Streams does not auto-scale shards to match load; you must provision shards (or use the separate on-demand mode), and a single shard caps at 1 MB/s, far below the 4 MB/s ingest.

Enhanced fan-out is the Kinesis Data Streams feature designed exactly for multiple consumers needing isolation: each registered consumer gets its own dedicated 2 MB/s-per-shard pipe pushed via SubscribeToShard (HTTP/2), so adding consumers does not reduce throughput or raise latency for the others. The shared-GetRecords option is wrong because the standard read limit of 2 MB/s per shard is shared across all consumers; five consumers on shared reads contend for that bandwidth, and merely multiplying shards is costly and still does not give each consumer guaranteed isolated throughput the way enhanced fan-out does. The Firehose-in-between option is wrong because Firehose is a delivery service to fixed destinations, not a mechanism to give five independent real-time consumers their own isolated read streams. The on-demand mode option is wrong because on-demand only changes how shard capacity for writes is provisioned and billed; it does not, by itself, grant each consumer dedicated read throughput — you still register enhanced fan-out consumers to get per-consumer isolation.