Home › DevOps › Amazon EMR: Avoid $10K Bills and Silent Data Loss in Hadoop/Spark
Advanced 3 min · July 18, 2026
Amazon EMR: Big Data Processing with Hadoop and Spark

Amazon EMR: Avoid $10K Bills and Silent Data Loss in Hadoop/Spark

Amazon EMR deep dive: avoid costly mistakes in Hadoop/Spark clusters.

N
Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Notes here come from systems that actually shipped.

Follow
✓ Production
production tested
July 18, 2026
last updated
2,466
articles · all by Naren
Before you start⏱ 30 min
  • ✓AWS account with EMR access
  • ✓Basic Hadoop/Spark concepts (YARN, RDD, shuffle)
  • ✓Experience with S3 and IAM roles
 ● Production Incident 🔎 Debug Guide ⚙ Triage Commands
⚡Quick Answer

Amazon EMR spins up a Hadoop/Spark cluster on EC2, processes data from S3 or HDFS, and tears down when done. Use transient clusters for batch jobs and long-running for streaming. Always enable automatic scaling and spot instances to cut costs.

✦ Definition~90s read
What is Amazon EMR?

Amazon EMR is a managed big data platform that runs Hadoop, Spark, and other frameworks on EC2 instances. It handles provisioning, scaling, and monitoring so you don't have to babysit clusters.

★
Think of EMR as a catering service for a massive data feast.
Plain-English First

Think of EMR as a catering service for a massive data feast. You tell them how many guests (data size) and what dishes (Spark jobs), they bring the chefs (EC2 instances), cook the meal, clean up, and send you the bill. You don't buy the kitchen or hire permanent staff.

⚙ Browser compatibility
Latest versions — ✓ supported
ChromeFirefoxSafariEdge
✓✓✓✓

I've seen a single misconfigured EMR cluster rack up a $10,000 bill overnight because someone forgot to set a max bid on spot instances. The cloud doesn't care about your budget. Amazon EMR is powerful, but it's also a loaded gun. This article is about pulling the trigger in the right direction. You'll learn how to design clusters that don't bleed money, handle failures gracefully, and process terabytes without waking up to a pager storm.

Cluster Types: Transient vs Long-Running — Pick the Right One

Most teams get this wrong. They create a long-running cluster for batch jobs that run once a day. That's like renting a bus to drive yourself to the corner store. Transient clusters spin up, run your job, and die. Use them for scheduled batch processing. Long-running clusters are for interactive queries, streaming, or when you need low-latency responses. The cost difference is massive: a transient cluster that runs for 2 hours costs 2 hours of compute. A long-running cluster that sits idle 22 hours a day still bills you for 24. Always prefer transient unless you have a real-time need.

create_transient_cluster.shDEVOPS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// io.thecodeforge — DevOps tutorial

# Create a transient Spark cluster that auto-terminates after step completion
aws emr create-cluster \
    --name "transient-spark-job" \
    --release-label emr-6.10.0 \
    --applications Name=Spark \
    --ec2-attributes KeyName=my-key,InstanceProfile=EMR_EC2_DefaultRole,SubnetId=subnet-abc123 \
    --instance-groups InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 \
                     InstanceGroupType=CORE,InstanceType=r5.2xlarge,InstanceCount=3 \
    --steps Type=Spark,Name="RunETL",ActionOnFailure=TERMINATE_CLUSTER,\
            Jar=command-runner.jar,Args=["spark-submit","--deploy-mode","cluster","s3://my-bucket/etl.py"] \
    --auto-terminate \
    --log-uri s3://my-bucket/logs/ \
    --visible-to-all-users
Output
{
"ClusterId": "j-2ABCDEFGHIJKL",
"ClusterArn": "arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-2ABCDEFGHIJKL"
}
⚠ Production Trap: Forgetting Auto-Terminate
If you omit --auto-terminate, the cluster stays alive forever. You'll get a surprise bill. Always set it for transient jobs. Also set ActionOnFailure=TERMINATE_CLUSTER on the step so a failed job doesn't leave a zombie cluster.

Instance Fleets: The Smart Way to Mix Spot and On-Demand

Instance groups are the old way. They lock you into a single instance type and a fixed mix of spot vs on-demand. Instance fleets let you specify multiple instance types and a flexible allocation. This is crucial for spot instances: if one type gets reclaimed, the fleet can launch another. You also set a target for on-demand vs spot capacity. For cost savings, target 100% spot for core and task nodes, but keep the master on-demand. The master runs the YARN ResourceManager and HDFS NameNode — if it goes down, the cluster dies. Spot instances can be reclaimed with 2-minute notice. That's fine for workers, but not for the master.

create_cluster_with_fleet.shDEVOPS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// io.thecodeforge — DevOps tutorial

# Create cluster with instance fleet for cost-optimized spot usage
aws emr create-cluster \
    --name "cost-optimized-cluster" \
    --release-label emr-6.10.0 \
    --applications Name=Spark Name=Hadoop \
    --ec2-attributes KeyName=my-key,InstanceProfile=EMR_EC2_DefaultRole,SubnetId=subnet-abc123 \
    --instance-fleets \
        InstanceFleetType=MASTER,TargetOnDemandCapacity=1,TargetSpotCapacity=0,\
            InstanceTypeConfigs=[{InstanceType=m5.xlarge}] \
        InstanceFleetType=CORE,TargetOnDemandCapacity=0,TargetSpotCapacity=3,\
            InstanceTypeConfigs=[{InstanceType=r5.2xlarge},{InstanceType=r5a.2xlarge},{InstanceType=r5d.2xlarge}] \
    --auto-terminate \
    --log-uri s3://my-bucket/logs/
Output
{
"ClusterId": "j-3BCDEFGHIJKLM",
"ClusterArn": "arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-3BCDEFGHIJKLM"
}
💡Senior Shortcut: Diversify Instance Types
For spot fleets, include at least 3 instance types with similar specs (e.g., r5, r5a, r5d). AWS will rotate through them, reducing the chance of mass reclaim. Also set MaxPrice to 50-70% of on-demand to avoid paying near on-demand prices.

EMRFS: Consistent View and S3 Performance

S3 is eventually consistent. That means after a write, a read might not see the data for a few seconds. For EMR, this is a disaster: Spark jobs that write intermediate data to S3 and then read it back can fail with 'file not found'. EMRFS consistent view solves this by using DynamoDB to track metadata. Enable it with fs.s3.consistent=true and fs.s3.consistent.retryPolicyType=exponential. But there's a gotcha: DynamoDB costs. If you have many small files, the read/write capacity can add up. Use S3A committers for Spark to avoid rename operations, which are slow and expensive.

emrfs_config.jsonDEVOPS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// io.thecodeforge — DevOps tutorial

// EMRFS configuration for consistent view and performance
[{
  "Classification": "emrfs-site",
  "Properties": {
    "fs.s3.consistent": "true",
    "fs.s3.consistent.retryPolicyType": "exponential",
    "fs.s3.consistent.retryPeriodSeconds": "10",
    "fs.s3.consistent.retryCount": "5",
    "fs.s3.consistent.table.name": "EmrFSMetadata",
    "fs.s3.consistent.table.read.capacity": "100",
    "fs.s3.consistent.table.write.capacity": "200"
  }
}]
⚠ Production Trap: DynamoDB Provisioned Throughput
If you set read/write capacity too low, EMRFS will throttle and jobs slow down. Monitor DynamoDB throttling metrics. For large clusters, use on-demand capacity or auto-scaling. Also, enable S3 server-side encryption — EMRFS consistent view stores metadata in DynamoDB, not the data itself.

Spark on EMR: Tuning for Your Workload

Spark tuning is a dark art. The defaults are for a single-node toy. On EMR, you need to configure executor memory, cores, and overhead. The classic mistake: setting spark.executor.memory too high, causing YARN to kill containers. Rule of thumb: leave 10-15% of memory for OS and overhead. For example, on an r5.2xlarge (8 vCPU, 64 GB RAM), set executor memory to 18 GB per executor with 4 cores. That gives 3 executors per node (3*18=54 GB, leaving 10 GB for overhead). Also enable dynamic allocation: spark.dynamicAllocation.enabled=true so executors scale with load.

spark_configs.jsonDEVOPS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// io.thecodeforge — DevOps tutorial

// Spark configuration for r5.2xlarge instances
[{
  "Classification": "spark-defaults",
  "Properties": {
    "spark.executor.instances": "9",
    "spark.executor.cores": "4",
    "spark.executor.memory": "18g",
    "spark.executor.memoryOverhead": "3g",
    "spark.driver.memory": "8g",
    "spark.driver.cores": "4",
    "spark.dynamicAllocation.enabled": "true",
    "spark.dynamicAllocation.minExecutors": "3",
    "spark.dynamicAllocation.maxExecutors": "30",
    "spark.shuffle.service.enabled": "true",
    "spark.sql.adaptive.enabled": "true"
  }
}]
⚠ Production Trap: Memory Overhead
If you see 'Container killed by YARN for exceeding memory limits', increase spark.executor.memoryOverhead. This memory is for JVM overhead, internal metadata, and off-heap allocations. Set it to 10-20% of executor memory. Also check spark.memory.offHeap.enabled and spark.memory.offHeap.size for large shuffles.

Autoscaling: Don't Let Your Cluster Starve or Bleed

EMR autoscaling can scale core and task nodes based on YARN memory or CPU. But the defaults are conservative. Set minimum and maximum instance counts. For production, use custom autoscaling policies: scale out when pending memory > 20% of total, scale in when idle memory > 30% for 5 minutes. But watch out: scaling in can kill executors mid-job. Enable graceful decommissioning with yarn.resourcemanager.decommissioning.timeout set to 600 seconds (10 min). This lets running tasks finish before the node is removed.

autoscaling_policy.jsonDEVOPS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// io.thecodeforge — DevOps tutorial

// Custom autoscaling policy for EMR
{
  "AutoScalingPolicy": {
    "Constraints": {
      "MinCapacity": 3,
      "MaxCapacity": 20
    },
    "Rules": [
      {
        "Name": "ScaleOutOnPendingMemory",
        "Description": "Scale out when pending memory > 20%",
        "Action": {
          "SimpleScalingPolicyConfiguration": {
            "AdjustmentType": "CHANGE_IN_CAPACITY",
            "ScalingAdjustment": 2,
            "CoolDown": 300
          }
        },
        "Trigger": {
          "CloudWatchAlarmDefinition": {
            "ComparisonOperator": "GREATER_THAN_OR_EQUAL",
            "EvaluationPeriods": 2,
            "MetricName": "YARNMemoryAvailablePercentage",
            "Namespace": "AWS/ElasticMapReduce",
            "Period": 60,
            "Statistic": "AVERAGE",
            "Threshold": 20,
            "Unit": "PERCENT"
          }
        }
      },
      {
        "Name": "ScaleInOnIdleMemory",
        "Description": "Scale in when idle memory > 30% for 5 min",
        "Action": {
          "SimpleScalingPolicyConfiguration": {
            "AdjustmentType": "CHANGE_IN_CAPACITY",
            "ScalingAdjustment": -1,
            "CoolDown": 300
          }
        },
        "Trigger": {
          "CloudWatchAlarmDefinition": {
            "ComparisonOperator": "GREATER_THAN_OR_EQUAL",
            "EvaluationPeriods": 5,
            "MetricName": "YARNMemoryAvailablePercentage",
            "Namespace": "AWS/ElasticMapReduce",
            "Period": 60,
            "Statistic": "AVERAGE",
            "Threshold": 70,
            "Unit": "PERCENT"
          }
        }
      }
    ]
  }
}
⚠ Production Trap: Aggressive Scale-In
If scale-in happens too fast, running tasks fail. Always set a cooldown of at least 5 minutes. Use yarn.resourcemanager.decommissioning.timeout to give tasks time to finish. Also, never scale in below the number of executors your job needs — use dynamic allocation min/max.

Security: IAM Roles, Encryption, and VPC

EMR needs two IAM roles: one for the service (EMR_DefaultRole) and one for EC2 instances (EMR_EC2_DefaultRole). The EC2 role should have least privilege: only access to S3 buckets and DynamoDB tables you need. Never use the default role in production — it's too permissive. For encryption, enable S3 server-side encryption (SSE-S3 or SSE-KMS) and in-transit encryption using TLS. EMR supports at-rest encryption for EBS volumes using KMS. Also, place clusters in private subnets with a VPC endpoint for S3 to avoid internet egress costs.

emr_ec2_role_policy.jsonDEVOPS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// io.thecodeforge — DevOps tutorial

// Minimal IAM policy for EMR EC2 role
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-data-bucket",
        "arn:aws:s3:::my-data-bucket/*",
        "arn:aws:s3:::my-log-bucket",
        "arn:aws:s3:::my-log-bucket/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:DeleteItem",
        "dynamodb:Query",
        "dynamodb:Scan"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/EmrFSMetadata"
    }
  ]
}
⚠ Production Trap: Overly Permissive IAM Role
Using the default EMR_EC2_DefaultRole gives access to all S3 buckets. If a malicious actor gains access to the cluster, they can exfiltrate data. Always scope down to specific buckets. Also, use S3 bucket policies to enforce encryption in transit.

Monitoring and Logging: Don't Fly Blind

EMR pushes logs to S3 and CloudWatch. Enable detailed monitoring for cluster metrics. The key metrics: YARNMemoryAvailablePercentage (memory pressure), ContainerAllocated (resource usage), and S3BytesWritten (data volume). Set CloudWatch alarms for high memory usage, job failures, and spot instance reclaims. For Spark, enable event logging with spark.eventLog.enabled=true and point to S3. Then use the Spark History Server on the master node to debug failed stages. Also, enable Ganglia for OS-level metrics like CPU and disk I/O.

enable_spark_event_logging.shDEVOPS
1
2
3
4
5
6
7
8
9
10
11
12
13
// io.thecodeforge — DevOps tutorial

# Enable Spark event logging to S3
aws emr create-cluster \
    --name "spark-with-logging" \
    --release-label emr-6.10.0 \
    --applications Name=Spark \
    --ec2-attributes KeyName=my-key,InstanceProfile=EMR_EC2_DefaultRole,SubnetId=subnet-abc123 \
    --instance-groups InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 \
                     InstanceGroupType=CORE,InstanceType=r5.2xlarge,InstanceCount=3 \
    --configurations '[{"Classification":"spark-defaults","Properties":{"spark.eventLog.enabled":"true","spark.eventLog.dir":"s3://my-bucket/spark-logs/"}}]' \
    --auto-terminate \
    --log-uri s3://my-bucket/logs/
Output
{
"ClusterId": "j-4CDEFGHIJKLMN",
"ClusterArn": "arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-4CDEFGHIJKLMN"
}
💡Senior Shortcut: Spark History Server

When Not to Use EMR: The Overkill Trap

EMR is not the answer for everything. If your data fits in a single machine, use Pandas or DuckDB. If you need real-time sub-second queries, use Athena or Redshift Spectrum. If your processing is simple ETL on small datasets, use AWS Glue. EMR shines when you have terabytes of data, complex transformations, or need custom libraries. But the overhead of managing a cluster (even managed) is real. For small jobs, the startup time alone (5-10 minutes) kills any benefit. Also, if your team doesn't know Spark or Hadoop, the learning curve will sink the project.

🔥Interview Gold: When to Choose EMR vs Glue vs Athena
EMR: custom Spark/Hadoop, large datasets, long-running jobs. Glue: serverless Spark, simple ETL, small to medium data. Athena: SQL queries on S3, no infrastructure, ad-hoc analysis. The rule: if you need to write custom code beyond SQL, use EMR or Glue. If you can express it in SQL, use Athena.
● Production incidentPOST-MORTEMseverity: high

The $10,000 Overnight Spot Instance Bill

Symptom
DevOps got an AWS billing alert at 3 AM: $10,200 spent in 6 hours on a single EMR cluster that was supposed to be transient.
Assumption
Someone thought spot instances were automatically cheaper and set no max bid, so the cluster ran on on-demand instances at full price.
Root cause
The EMR cluster was created with --instance-groups using BidPrice: OnDemand (default). Spot instances were not actually used; all nodes launched as on-demand. The cluster was left running after the job completed because --auto-terminate was not set.
Fix
Set --auto-terminate on the cluster creation. Use --instance-fleet with TargetOnDemandCapacity: 0 and TargetSpotCapacity: 100 and a max spot price of 50% of on-demand. Also set a CloudWatch alarm on estimated charges.
Key lesson
  • Always set a max spot bid and auto-terminate.
  • Never trust defaults for cost control.
Production debug guideSystematic recovery paths for the failure modes engineers actually hit.3 entries
Symptom · 01
Cluster creation fails with 'VPC subnet does not have enough IP addresses'
→
Fix
1. Check subnet available IPs: aws ec2 describe-subnets --subnet-ids <id> --query 'Subnets[0].AvailableIpAddressCount' 2. If low, create a new subnet with larger CIDR or use multiple subnets. 3. Also check EC2 service limits: aws service-quotas get-service-quota --service-code ec2 --quota-code L-12345678.
Symptom · 02
Spark job fails with 'java.lang.OutOfMemoryError: Java heap space'
→
Fix
1. Increase spark.executor.memory and spark.executor.memoryOverhead. 2. Check if data skew is causing one executor to hold too much data — use salting or repartition. 3. Enable spark.sql.adaptive.enabled to auto-coalesce partitions.
Symptom · 03
EMRFS consistent view errors: 'File does not exist: s3://...'
→
Fix
1. Verify DynamoDB table exists and has correct read/write capacity. 2. Check IAM role has DynamoDB permissions. 3. Increase retry count and period in emrfs-site configuration.
★ Amazon EMR Triage Cheat SheetFirst-response commands for when things go wrong — copy-paste ready.
Cluster stuck in 'Starting'−
Immediate action
Check subnet IP availability and service limits
Commands
aws ec2 describe-subnets --subnet-ids <id> --query 'Subnets[0].AvailableIpAddressCount'
aws service-quotas get-service-quota --service-code ec2 --quota-code L-12345678
Fix now
Create new subnet with larger CIDR or request limit increase.
Container killed by YARN for exceeding memory limits+
Immediate action
Check Spark executor memory config
Commands
grep -i 'Container killed' /mnt/var/log/hadoop-yarn/yarn-container.log
aws emr describe-cluster --cluster-id <id> --query 'Cluster.Configurations'
Fix now
Increase spark.executor.memoryOverhead to 15% of executor memory.
EMRFS file not found errors+
Immediate action
Check DynamoDB table and IAM permissions
Commands
aws dynamodb describe-table --table-name EmrFSMetadata --query 'Table.TableStatus'
aws iam simulate-principal-policy --policy-source-arn <role-arn> --action-names dynamodb:GetItem
Fix now
Ensure IAM role has DynamoDB access and table has sufficient capacity.
High cost spike+
Immediate action
Check if cluster is still running and spot instance usage
Commands
aws emr list-clusters --active --query 'Clusters[*].{Id:Id,Name:Name,Status:Status.State}'
aws ec2 describe-spot-instance-requests --filters Name=state,Values=active --query 'SpotInstanceRequests[*].{ID:SpotInstanceRequestId,Price:SpotPrice}'
Fix now
Terminate idle clusters: aws emr terminate-clusters --cluster-ids <id>. Set max spot bid to 50% of on-demand.
FeatureInstance GroupsInstance Fleets
Instance type flexibilitySingle type per groupMultiple types per fleet
Spot vs On-Demand mixFixed per groupFlexible per fleet
Auto-recovery on spot reclaimManualAutomatic (launches alternative type)
Cost optimizationManualAutomatic with allocation strategy
RecommendedLegacy, avoidUse for new clusters
⚙ Quick Reference
7 commands from this guide
FileCommand / CodePurpose
create_transient_cluster.shaws emr create-cluster \Cluster Types: Transient vs Long-Running
create_cluster_with_fleet.shaws emr create-cluster \Instance Fleets
emrfs_config.json[{EMRFS
spark_configs.json[{Spark on EMR
autoscaling_policy.json{Autoscaling
emr_ec2_role_policy.json{Security
enable_spark_event_logging.shaws emr create-cluster \Monitoring and Logging

Key takeaways

1
Always use transient clusters for batch jobs and set auto-terminate
never leave clusters running idle.
2
Instance fleets with diverse spot types reduce cost and improve resilience; keep master on-demand.
3
EMRFS consistent view is essential for S3 consistency but watch DynamoDB costs and throttling.
4
Spark tuning is non-negotiable
leave memory overhead, enable dynamic allocation, and use adaptive query execution.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
How does EMR handle spot instance reclaims during a long-running Spark j...
Q02SENIOR
When would you choose EMR over AWS Glue for a Spark ETL pipeline?
Q03SENIOR
What happens when EMRFS consistent view's DynamoDB table throttles?
Q04JUNIOR
Explain the difference between core and task nodes in EMR.
Q05SENIOR
A Spark job fails with 'Shuffle fetch failure' on EMR. What's your diagn...
Q06SENIOR
How would you design an EMR cluster for a 24/7 streaming job with cost o...
Q01 of 06SENIOR

How does EMR handle spot instance reclaims during a long-running Spark job?

ANSWER
EMR detects the reclaim via EC2 termination notices. It stops allocating new tasks to the node and moves shuffle data to other nodes. However, if the node is a core node with HDFS data, that data is lost. Mitigation: use task nodes (no HDFS) for spot instances, and enable HDFS replication factor 3. Also, use Spark's shuffle service to persist shuffle data on other nodes.
FAQ · 4 QUESTIONS

Frequently Asked Questions

01
How do I stop an EMR cluster from running up a huge bill?
02
What's the difference between EMR and Amazon Athena?
03
How do I debug a Spark job that fails on EMR?
04
Can I use spot instances for the master node in EMR?
📖 What to Read Next
→AWS Glue: Serverless ETL and Data Catalog — Production Patterns and PitfallsAWS Glue serverless ETL deep dive: internals, performance tuning, failure modes, and production gotchas from real incide→EC2 Auto Scaling: Elasticity and Capacity ManagementA comprehensive guide to EC2 Auto Scaling: Elasticity and Capacity Management on AWS, covering core concepts, configurat→Amazon Athena: Serverless SQL Query Service – Stop Paying for Idle WarehousesAmazon Athena serverless SQL query service lets you query S3 data with standard SQL. No clusters, no provisioning. Here'→MapReduce and Batch Processing: The Honest Guide to Crunching Data at ScaleMapReduce and batch processing explained with production patterns, trade-offs, and failure modes. Learn when to use Hado→Google Cloud — Dataproc (Hadoop & Spark)Guide to Google Cloud Dataproc for managed Spark and Hadoop clusters including autoscaling, workflow templates, ephemera
From Other Categories
Transactional Outbox PatternAdvanced
N
Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Notes here come from systems that actually shipped.

Follow
✓ Verified
production tested
July 18, 2026
last updated
2,466
articles · all by Naren
🔥

That's AWS. Mark it forged?

3 min read · try the examples if you haven't

←
Previous
Amazon Athena: Serverless SQL Query Service
52 / 63 · AWS
Next
Amazon GuardDuty and Inspector: Threat Detection and Vulnerability Scanning
→