Airflow Summit 2025 is coming October 07-09. Register now for early bird ticket!

Amazon EMR on Amazon EKS

Amazon EMR on EKS provides a deployment option for Amazon EMR that allows you to run open-source big data frameworks on Amazon EKS.

Prerequisite Tasks

To use these operators, you must do a few things:

Generic Parameters

aws_conn_id

Reference to Amazon Web Services Connection ID. If this parameter is set to None then the default boto3 behaviour is used without a connection lookup. Otherwise use the credentials stored in the Connection. Default: aws_default

region_name

AWS Region Name. If this parameter is set to None or omitted then region_name from AWS Connection Extra Parameter will be used. Otherwise use the specified value instead of the connection value. Default: None

verify

Whether or not to verify SSL certificates.

  • False - Do not validate SSL certificates.

  • path/to/cert/bundle.pem - A filename of the CA cert bundle to use. You can specify this argument if you want to use a different CA cert bundle than the one used by botocore.

If this parameter is set to None or is omitted then verify from AWS Connection Extra Parameter will be used. Otherwise use the specified value instead of the connection value. Default: None

botocore_config

The provided dictionary is used to construct a botocore.config.Config. This configuration can be used to configure Avoid Throttling exceptions, timeouts, etc.

Example, for more detail about parameters please have a look botocore.config.Config
{
    "signature_version": "unsigned",
    "s3": {
        "us_east_1_regional_endpoint": True,
    },
    "retries": {
      "mode": "standard",
      "max_attempts": 10,
    },
    "connect_timeout": 300,
    "read_timeout": 300,
    "tcp_keepalive": True,
}

If this parameter is set to None or omitted then config_kwargs from AWS Connection Extra Parameter will be used. Otherwise use the specified value instead of the connection value. Default: None

Note

Specifying an empty dictionary, {}, will overwrite the connection configuration for botocore.config.Config

Operators

Create an Amazon EMR EKS virtual cluster

The EmrEksCreateClusterOperator will create an Amazon EMR on EKS virtual cluster. The example DAG below shows how to create an EMR on EKS virtual cluster.

To create an Amazon EMR cluster on Amazon EKS, you need to specify a virtual cluster name, the eks cluster that you would like to use , and an eks namespace.

Refer to the EMR on EKS Development guide for more details.

tests/system/amazon/aws/example_emr_eks.py[source]

    create_emr_eks_cluster = EmrEksCreateClusterOperator(
        task_id="create_emr_eks_cluster",
        virtual_cluster_name=virtual_cluster_name,
        eks_cluster_name=eks_cluster_name,
        eks_namespace=eks_namespace,
    )

Submit a job to an Amazon EMR virtual cluster

Note

This example assumes that you already have an EMR on EKS virtual cluster configured. See the EMR on EKS Getting Started guide for more information.

The EmrContainerOperator will submit a new job to an Amazon EMR on Amazon EKS virtual cluster The example job below calculates the mathematical constant Pi. In a production job, you would usually refer to a Spark script on Amazon Simple Storage Service (S3).

To create a job for Amazon EMR on Amazon EKS, you need to specify your virtual cluster ID, the release of Amazon EMR you want to use, your IAM execution role, and Spark submit parameters.

You can also optionally provide configuration overrides such as Spark, Hive, or Log4j properties as well as monitoring configuration that sends Spark logs to Amazon S3 or Amazon Cloudwatch.

In the example, we show how to add an applicationConfiguration to use the AWS Glue data catalog and monitoringConfiguration to send logs to the /aws/emr-eks-spark log group in Amazon CloudWatch. Refer to the EMR on EKS guide for more details on job configuration.

tests/system/amazon/aws/example_emr_eks.py[source]

job_driver_arg = {
    "sparkSubmitJobDriver": {
        "entryPoint": f"s3://{s3_bucket_name}/{S3_FILE_NAME}",
        "sparkSubmitParameters": "--conf spark.executors.instances=2 --conf spark.executors.memory=2G "
        "--conf spark.executor.cores=2 --conf spark.driver.cores=1",
    }
}

configuration_overrides_arg = {
    "monitoringConfiguration": {
        "cloudWatchMonitoringConfiguration": {
            "logGroupName": "/emr-eks-jobs",
            "logStreamNamePrefix": "airflow",
        }
    },
}

We pass the virtual_cluster_id and execution_role_arn values as operator parameters, but you can store them in a connection or provide them in the DAG. Your AWS region should be defined either in the aws_default connection as {"region_name": "us-east-1"} or a custom connection name that gets passed to the operator with the aws_conn_id parameter. The operator returns the Job ID of the job run.

tests/system/amazon/aws/example_emr_eks.py[source]

job_starter = EmrContainerOperator(
    task_id="start_job",
    virtual_cluster_id=str(create_emr_eks_cluster.output),
    execution_role_arn=job_role_arn,
    release_label="emr-7.0.0-latest",
    job_driver=job_driver_arg,
    configuration_overrides=configuration_overrides_arg,
    name="pi.py",
)

Sensors

Wait on an Amazon EMR virtual cluster job

To wait on the status of an Amazon EMR virtual cluster job to reach a terminal state, you can use EmrContainerSensor

tests/system/amazon/aws/example_emr_eks.py[source]

job_waiter = EmrContainerSensor(
    task_id="job_waiter",
    virtual_cluster_id=str(create_emr_eks_cluster.output),
    job_id=str(job_starter.output),
)

Reference

Was this entry helpful?