Analytics
Services for collecting, processing, querying, and visualizing data at scale — from streaming ingestion to data warehousing and BI dashboards.
Amazon Athena
Serverless SQL queries run directly against data sitting in S3 — no servers, no loading, pay per byte scanned.
- Point Athena at S3, define a table, run standard SQL — the data never moves and there is no ETL or load step
- Serverless: nothing to provision, nothing running and nothing billed between queries
- Table and schema metadata lives in the AWS Glue Data Catalog; Glue crawlers can infer it for you
- You are billed for bytes scanned, so partitioning, compression, and columnar formats (Parquet/ORC) are the cost lever — not query tuning
Exam triggers
Phrases and scenarios that point here.
- "Query data in S3", "ad hoc", "standard SQL", "no infrastructure to manage" → Athena
- Analyze logs already sitting in S3 (CloudTrail, VPC Flow Logs, ALB, CUR) → Athena
- "Least operational overhead" + infrequent or occasional queries → Athena, not Redshift or EMR
- "Reduce Athena cost" → scan less data: partition, compress, convert to Parquet
Not this service
- Frequent, complex BI reporting on loaded structured data → Redshift
- Custom Spark/Hadoop processing with cluster control → EMR
- Building the catalog or transforming the data itself → AWS Glue (Athena queries it, Glue prepares it)
Use cases
- Log forensics — "who deleted that bucket last Tuesday?" Point Athena at the CloudTrail bucket and answer it with a WHERE clause instead of a support ticket
- Investigating a slow or suspicious network path in VPC Flow Logs, without standing up a logging stack for a question you'll ask twice a year
- Billing archaeology — query the Cost and Usage Report in S3 to find which team actually owns a line item that jumped last month
- One-off analyst questions against a data lake, where nobody wants to build a warehouse for a number marketing needs once
- The SQL layer beneath a QuickSight dashboard, so BI users see raw S3 data without an ETL pipeline in front of it
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon EMR
Managed clusters for running open-source big data frameworks like Spark and Hadoop on AWS.
- Runs the open-source big data stack — Spark, Hive, Presto/Trino, HBase, Flink — with AWS provisioning and configuring the EC2 fleet
- Three node types: primary (coordinates), core (runs tasks and holds HDFS), task (compute only, optional)
- Storage: HDFS lives on core nodes and dies with the cluster; EMRFS reads and writes S3 directly, so data outlives the cluster
- Transient clusters run one job and self-terminate; long-running clusters stay up for interactive and ad hoc work
- Four deployment flavors: EMR on EC2 (the default), EMR Serverless (no cluster), EMR on EKS, EMR on Outposts
Exam triggers
Phrases and scenarios that point here.
- "Hadoop", "Spark", "Hive", "Presto", "HBase", "Flink" named in the question → EMR, almost always
- Migrate an on-premises Hadoop or Spark cluster to AWS without rewriting the jobs
- "Petabyte-scale", "massive log/clickstream processing", "big data analytics" with code that already exists
- Team needs control over the framework and its version → EMR, not a fully abstracted service
Not this service
- Serverless ETL with a built-in data catalog, nothing to size → AWS Glue
- Ad hoc SQL straight against S3, nothing to run or manage → Amazon Athena
- Data warehouse for BI dashboards and reporting → Amazon Redshift
Use cases
- Lifting a decade of on-prem Spark and Hive jobs into AWS — same frameworks, someone else's hardware
- Nightly data lake ETL: read raw CSV and JSON from S3, write partitioned Parquet back for Athena and Redshift to query
- Transient cluster for a monthly billing run — spins up at 2am, chews through the month's usage records, terminates itself before anyone wakes up
- Backfills and reprocessing: replaying two years of archived clickstream in an afternoon by throwing 200 Spot task nodes at it
- A long-running cluster as a shared analytics sandbox, with EMR Studio notebooks for data scientists poking at the lake in PySpark
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon Kinesis Data Streams
Managed service for ingesting real-time streaming data and keeping it available for multiple consumers to read and re-read.
- Reading doesn't delete — data stays for the full retention window, so many consumers can read the same stream independently
- Shard = the throughput unit: 1 MB/s or 1,000 records/s in, 2 MB/s out; records land in order within a shard
- Provisioned mode = you choose the shard count; On-demand mode = AWS scales shards for you
- Limits: 1 MB max record size, 24-hour default retention (extendable to 365 days), partition key decides the shard
Exam triggers
Phrases and scenarios that point here.
- "Real time", "streaming", "clickstream", "IoT telemetry", "within seconds"
- Multiple teams or applications need the same events for different purposes → Data Streams, not SQS
- Must be able to replay or reprocess data after a failure → Data Streams retention
- Order matters per device/user/session → partition key keeps those records on one shard
Not this service
- Just land the stream in S3, Redshift, or OpenSearch with no code → Amazon Data Firehose
- One message, one consumer, then it's gone → SQS
- Windowed aggregations or SQL over the stream → Amazon Managed Service for Apache Flink
Use cases
- Clickstream on a retail site where one consumer drives a live traffic dashboard and another archives to S3 — same stream, two readers, neither blocking the other
- Fleet telemetry from delivery bikes, using bike ID as the partition key so each bike's GPS pings stay in order even as the fleet grows
- Real-time fraud scoring on payment events, where a scoring consumer reacts in seconds and a nightly batch job re-reads the same records for reporting
- Log ingestion for an app too chatty for a single processor — fan out to a Lambda consumer for alerting and a Firehose consumer for the data lake
- Recovering from a bad consumer deploy: because records are retained, you rewind and reprocess the last few hours instead of losing them
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon OpenSearch Service
Managed search and analytics engine for log analytics, full-text search, and operational dashboards.
- A domain is a cluster — you pick instance types and node counts, AWS provisions, patches, and replaces failed nodes
- Two flavors: managed clusters (you size the nodes) and Serverless collections (capacity scales for you in OCUs)
- OpenSearch Dashboards is the built-in visualization UI — the successor to Kibana, included with every domain
- Storage tiers step down in cost and speed: hot (EBS) → UltraWarm → cold (both S3-backed)
- Reality check: this was Amazon Elasticsearch Service until 2021 — older question banks and blog posts still say "Elasticsearch"
Exam triggers
Phrases and scenarios that point here.
- "Full-text search", "relevance ranking", "search across large volumes of text" → OpenSearch
- "Centralized log analytics", "SIEM", "security analytics", "operational dashboards" → OpenSearch
- The word "Kibana" or "Elasticsearch" appears anywhere → the AWS answer is OpenSearch Service
- Streaming logs that must be searchable and visualized in near real time → Firehose or OpenSearch Ingestion into OpenSearch
Not this service
- Simple log storage with occasional queries and metric alarms → CloudWatch Logs
- Ad hoc SQL over files already sitting in S3 → Athena
- Business dashboards and charts for non-technical users → Amazon Quick (the service formerly called QuickSight)
Use cases
- Central log search across a whole fleet — app logs, VPC flow logs, and ALB logs in one index, so you trace a failed request without SSH-ing into a single box
- Product search on a storefront — typo tolerance, faceted filters (brand, size, price), and relevance tuning that a SQL LIKE query will never give you
- Security analytics — CloudTrail, WAF, and firewall logs indexed together so an analyst can follow one attacker's session across services
- Live operations dashboards — error rate, p99 latency, and order counts on a wall screen refreshing every few seconds
- Vector search for RAG chatbots — store embeddings next to your text and ask "find me things similar to this" instead of matching keywords
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon QuickSight
Serverless business intelligence service for building and sharing interactive dashboards.
- Two user roles: Authors connect to data and build dashboards, Readers just view and filter them
- SPICE = in-memory engine; import a snapshot for fast repeat queries, or Direct Query to hit the live source
- Connects to S3, Athena, Redshift, RDS/Aurora, on-prem databases, SaaS apps, and uploaded CSV/Excel
- Built-in ML with no ML skills: forecasting, anomaly detection, and plain-English Q&A via Amazon Q
- Reality check: AWS renamed it "Amazon Quick Sight" under the Amazon Quick suite — exams and APIs still say QuickSight
Exam triggers
Phrases and scenarios that point here.
- "Dashboard", "visualize", "business intelligence", "charts for business users" → QuickSight
- Non-technical staff need to explore data without writing SQL → QuickSight
- Embed interactive dashboards inside your own app or customer portal → QuickSight embedded analytics
- Data already sits in S3 → Athena queries it, QuickSight draws it
Not this service
- Running SQL against data in S3 → Athena (QuickSight sits on top of it)
- CPU, latency, error-rate graphs for engineers → CloudWatch dashboards
- Storing and warehousing the data itself → Redshift
Use cases
- Weekly revenue dashboard on Redshift so leadership self-serves instead of asking an analyst for a fresh CSV every Monday
- Customer-facing analytics embedded in a SaaS product — "your store's traffic this month" — without building a charting stack in-house
- FinOps dashboards over Cost and Usage Report data in S3, so each engineering team sees its own spend without opening Cost Explorer
- Retail chain with hundreds of store managers on cheap Reader seats, all hitting one nightly SPICE snapshot instead of hammering the production database
- Anomaly alerts on business metrics — refund rate suddenly doubles — caught by built-in ML rather than someone eyeballing a report
Commonly confused with
Verified against AWS documentation · 2026-09-09
Amazon Redshift
Fully managed, petabyte-scale data warehouse for SQL analytics and BI reporting on large datasets.
- OLAP, not OLTP — built to scan and aggregate billions of rows, not to serve single-row app lookups
- Columnar storage + MPP: a leader node plans the query, compute nodes run it in parallel on their own slice of data
- Two flavours: Serverless (pay per RPU-second while active, no cluster to size) and Provisioned (node-hours, pause/resume, Reserved Instances)
- Spectrum queries data sitting in S3 directly — no loading, join warehouse tables to lake files in one SQL statement
- Reality check: AWS now steers new clusters to Graviton-based RG nodes with a built-in lake query engine; exam material still says RA3 and DC2
Exam triggers
Phrases and scenarios that point here.
- "Data warehouse", "OLAP", "business intelligence", "petabyte-scale analytics", "complex joins across large tables"
- Reporting queries are crushing the production database → move analytics to Redshift, leave RDS to the app
- Analytics run only at month-end or business hours → Redshift Serverless, no capacity planning
- Query existing S3 data from the warehouse without an ETL load → Redshift Spectrum
Not this service
- Occasional ad hoc SQL over S3, nothing to run or manage → Athena
- Transactional app database, single-row reads and writes → RDS or Aurora
- Spark, Hadoop or custom processing instead of SQL → EMR
- The dashboards and charts themselves → QuickSight (Redshift is what it queries)
Use cases
- One reporting warehouse fed nightly from orders, CRM and billing, so finance runs a single query instead of reconciling three exports
- Five years of clickstream in one place to answer questions no single app database can — which acquisition channel actually produces repeat buyers
- BI backend for QuickSight, Tableau or Power BI, where a few hundred analysts hit the same tables every Monday morning
- Hot months live in the warehouse, cold years stay in S3 as Parquet, and Spectrum joins both in one query — you keep the history without paying warehouse storage for it
- Serverless for a warehouse that only wakes up for the month-end close, so the other 25 days cost nothing in compute
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Glue
Serverless data integration service that discovers your data's schema, catalogs it, and runs ETL jobs without any servers to manage.
- Two halves, tested separately: the Data Catalog (metadata — what your data is) and ETL jobs (serverless Spark that moves and transforms it)
- Crawlers scan S3 and JDBC sources, infer schema and partitions, and write table definitions into the Data Catalog — the data itself never moves
- Athena, Redshift Spectrum, and EMR all read the same Data Catalog — crawl once, query from anywhere
- No-code paths exist: Glue Studio (visual ETL canvas) and DataBrew (point-and-click cleaning for analysts who don't write Spark)
Exam triggers
Phrases and scenarios that point here.
- "Serverless ETL", "no infrastructure to manage", "prepare and transform data for analytics"
- Files already sitting in S3 with no schema defined → Glue crawler + Data Catalog, then Athena
- "Central metadata repository shared across analytics services" → Glue Data Catalog
- Transform + load → Glue; query in place, no transform → Athena; long-running tuned cluster → EMR
Not this service
- Run SQL over S3 without moving or reshaping anything → Athena
- Persistent Hadoop/Spark cluster you tune, patch, and keep warm → EMR
Use cases
- A partner drops CSVs into S3 every night — a scheduled crawler picks up the new partitions and the data is queryable in Athena by morning, with nobody hand-writing a schema
- Converting sprawling raw CSV/JSON into partitioned Parquet, so every downstream Athena query scans a fraction of the bytes and costs a fraction as much
- Nightly job joining a database export with clickstream files into one flat reporting table that QuickSight points at
- One-off backfill over years of archived logs — the Spark capacity spins up, chews through it, and disappears, leaving no cluster to remember to shut down
- An analyst dedupes rows, fixes date formats, and standardizes country codes in DataBrew instead of filing a ticket with the data team
Commonly confused with
Verified against AWS documentation · 2026-09-09