Configure the solution

This section describes the various options that you configure for your use case while deploying Apache Druid in your AWS account.

The following table lists the configuration, setting, and if the configuration is mandatory before you deploy the solution in your AWS account.

Amazon Machine Images (AMI)

By default, the EC2 hosting option provisions EC2 instances with Amazon Linux 2.

To override this, specify the customAmi object in the cdk.json file. This object should provide the AMI name and owners' account IDs or the alias that cdk would use to perform an AMI lookup. Depending on the instance types utilized in the cluster, provide the corresponding AMI for arm64 (Graviton instances) or amd64 (x86-based instance types).

"customAmi": {
    "arm64": {
        "name": "ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-arm64-server*",
        "owners": ["amazon"]
    },
    "amd64": {
        "name": "ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server*",
        "owners": ["amazon"]
    }
},

Data retention policy

By default, all the solution data (S3 buckets, Aurora DB instances, Aurora DB snapshots etc.) is retained when you uninstall the solution.

To remove this data, in the configuration file, set the retainData flag to false. You are liable for the service charges when solution data is retained in the default configuration.

"retainData": false,    

Network

Virtual Private Cloud (VPC)

"vpcCidr": "x.x.x.x/x",  

"vpcId": "vpc-xxxxxxxxxxxxxxxxx"      

Application Load Balancer setting

The solution will provision an ALB to route requests to Druid query instances. It supports both internet facing and private options as follows.

"internetFacing": true, 

The default setting creates a private Application Load Balancer (ALB). To access this private ALB, you can either use an AWS VPN or SSH tunneling via a bastion host. However, if the internetFacing parameter is set to true, the ALB will be publicly available. In such an instance, use the AWS WAF (Web Application Firewall) with your ALB to allow or block requests based on rules in a web access control list (web ACL).

Bastion Host

You can launch a bastion host in the public subnet using this configuration, which facilitates the access to the hosts and services running in private and isolated subnets.

"bastionHost": true, 

Druid domain

This solution can integrate with Amazon Route 53 to automate the creation of domains, streamlining access to the Druid web console and API endpoints.

With the following Route 53 configuration, this solution automatically creates a Route53 domain using the specified druidDomain in the supplied hosted zone. Additionally, this solution creates a certificate in the AWS Certificate Manager (ACM) and associates it with the Application Load Balancer (ALB) to enable secure HTTPS communication.

"route53HostedZoneName": "<The hosted zone name in Route 53. eg. example.com>",

"route53HostedZoneId": "<The hosted zone ID in Route 53. eg. Z03935053V8YUTYYYEXXX>",

"druidDomain": "<A full domain address. eg. druid.example.com>"

"tlsCertificateArn": "<The ARN of ACM certificate>"     

FIPS 140-2

The Federal Information Processing Standard (FIPS ) Publication 140-2 is a US and Canadian government standard that specifies the security requirements for cryptographic modules that protect sensitive information.

If you want to use FIPS 140-2 validated cryptographic modules, you can set this using this configuration:

"useFipsEndpoint": true,    

Identity provider

By default, this solution activates basic authentication, enabling access to the Druid web console and API through a username and password. Additionally, you can use user access federation through a third-party identity provider (IdP) that supports OpenID Connect (OIDC) authentication. If you have an existing enterprise Identity Provider, you can integrate it using this CDK configuration.

"oidcIdpConfig": {
    "clientId": "<OIDC IDP client ID>",
    "clientSecretArn": "<The ARN of the secret in AWS secret manager which stores the client secret and cookiePassphrase.>",
    "discoveryURI": "<OIDC IDP client discovery URI. e.g. https://dev-pkaccwqn.us.auth0.com/.well-known/openid-configuration>",
    "groupClaimName": "<OIDC claim name that contains the group name list that the user belongs to>",
    "groupRoleMappings": {
        "<groupName>": ["<roleName>", ...],
    }
}   

The OIDC group mapping facilitates the integration of Role-Based Access Control (RBAC). Users authenticate through an OIDC identity provider, and their group information is extracted from the ID token. This information is then mapped to the corresponding RBAC roles within Druid, governing users' access to resources based on their external OIDC group memberships. This integration ensures that access privileges in Druid align with the user roles defined in the OIDC identity provider. It consists of the following two fields:

The client secret consists of the following two fields:

Example: Identity provider configuration to federate through Amazon Cognito.

"oidcIdpConfig": {
     "clientId": "<OIDC IDP client ID>",
     "clientSecretArn": "arn:aws:secretsmanager:<region>:<account>:secret:<secret-name>-<random-6-characters>",
     "discoveryURI": "https://cognito-idp.<region>.amazonaws.com/<user pool id>/.well-known/openid-configuration",
     "groupClaimName": "cognito:groups",
     "groupRoleMappings": {
          "developers": ["administrator"],
          "scrum-masters": ["read"]
         }
     }      

Druid basic configuration

Version

Apache Druid release version (eg. 30.0.0) that you want to run. We recommend using the latest stable Druid version.

"druidVersion": "30.0.0",       

Cluster name

A sequence of ASCII characters that uniquely identifies each Druid cluster. If there are multiple deployments, make sure that you have an unique cluster name for each cluster. The cluster name is appended to the CloudFormation stack name.

"druidClusterName": "dev",      

Operation platform

The intended computing service for hosting a Druid cluster currently has two options available:

"druidOperationPlatform": "ec2",        

Custom IAM policy list (optional)

By default, this solution creates an IAM role that gives Druid components the minimum permissions to function. You can extend this role with additional permissions by using the following configuration:

"druidInstanceIamPolicyArns": ["The ARN of custom IAM policy"...]        

Query concurrency rate limit (optional)

The maximum number of concurrent queries that the Druid cluster can handle. The default value is 100.

To customize this default configuration, you can override the values using the following configuration:

"druidConcurrentQueryLimit": number

Extensions

A list of Druid extensions to load into the cluster. To load the core extensions for Druid, you can modify the list by adding or removing extensions from it.

To load any custom extensions that you have developed in-house, make sure that the artifacts for those extensions (such as Java JAR files) are also copied into the source/lib/docker/extensions folder. To reduce the configuration overhead, the solution will automatically incorporate the extensions to the user provided extension list:

Druid extensions example

"druidExtensions": [
    "druid-hdfs-storage",
    "druid-kafka-indexing-service",
    "druid-kinesis-indexing-service",
    "druid-avro-extensions",
    "druid-parquet-extensions",
    "druid-protobuf-extensions",
    "druid-orc-extensions"
],

Common runtime properties(optional)

By default, the solution features a common.runtime.properties file located within the source/lib/uploads/config/_common directory, to cater to the majority of the use cases. However, you can customize and override the settings in this file using the CDK configuration as needed.

Druid common runtime customization configuration example:

"druidCommonRuntimeConfig": {
     "druid.startup.logging.logProperties": false
     }        

Retention rules (optional)

The data retention policies specify which data to retain and which data to drop from the cluster. The rule chain is evaluated from top to bottom, with the default rule chain always added at the bottom. For more information, refer to the Using rules to drop and retain data guide.

Alternatively, you can use the Druid API or the Druid Web Console to configure the retention rules for Druid.

Druid retention rules example

"druidRetentionRules": [
          {
          "type": "loadByPeriod",
          "period": "P1M",
          "includeFuture": true,
          "tieredReplicants": {
              "hot": 3,
              "_default_tier": 1
              }
          },
          {
          "type": "loadForever",
          "tieredReplicants": {
             "hot": 1,
             "_default_tier": 1
              }
          }
]        

Druid metadata store

In the default configuration, this solution sets up an Amazon Aurora Serverless v1 cluster, using the PostgreSQL-compatible engine as the metadata store for Druid. If you prefer to use an Amazon Aurora cluster as the metadata store, connect to an existing PostgreSQL database, or create the metadata store from a snapshot, you can customize the configuration by applying the following settings:

"druidMetadataStoreConfig": {
        // Metadata store type. Acceptable values include aurora, aurora_serverless, or custom.
        "metadataStoreType": "<aurora | aurora_serverless | custom>",
      
        // The metadata store configuration differs based on the chosen type of metadata store.
        "metadataStoreConfig": {
        },
      
        // Optional. The configuration for the backup plan determines the frequency and retention policy for the database snapshots.
        "backupPlanConfig" {
      
        // The cron expression which defines the snapshot frequency. E.g. cron(0 10 * * ? *) which runs at 10:00 am (UTC) every day.
        "scheduleExpression": "<cron expression>",
      
        // Number of days that the snapshot will be kept
        "deleteAfterDays": number
        }
}

Create a new Aurora metadata store (recommended)

This section provides instructions for creating a new Aurora metadata store.

"druidMetadataStoreConfig": {
      "metadataStoreType": "aurora",
      "metadataStoreConfig": {
          // Optional. Aurora DB instance class type. eg. t3.large   
         "rdsInstanceType": string,
          // Optional. Number of DB instances. Default is 2.
         "rdsInstanceCount": number,
         // Optional. The parameter group name for DB instance.
         "rdsParameterGroupName": string,
         // Optional. Aurora PostgreSQL engine version. The default version is 13.6. Please be aware that updating the version of your existing RDS instance will not result in data migration.
         "rdsEngineVersion": string
         }
      }   

Example configuration to create a new Aurora metadata store:

"druidMetadataStoreConfig": {
     "metadataStoreType": "aurora",
     "metadataStoreConfig": {
          "rdsInstanceType": "t3.large",
          "rdsInstanceCount": 2,
          "rdsParameterGroupName":
          "aurora-postgresql13",
          "rdsEngineVersion": "13.6"
          }
     }

Create a new Aurora metadata store from a snapshot

This section provides instructions on how to create a new Aurora metadata store from a snapshot.

"druidMetadataStoreConfig": {
    "metadataStoreType": "aurora",
    "metadataStoreConfig": {
        // Optional. Aurora DB instance class type. eg. t3.large
        "rdsInstanceType": string,

        // Optional. Number of DB instances. Default is 2.
        "rdsInstanceCount": number,

        // The ARN of RDS snapshot
        "rdsSnapshotArn": string,

        // Optional. The ARN of KMS key which is used to encrypt the database. Required if the storage is encrypted with a KMS key.
        "rdsSnapshotEncryptionKeyArn": string,

        // Optional. Required if the snapshot contains 'druid_system' user.
        "druidInternalUserSecretArn": "<The ARN of secret which stores username and password of the druid_system user >",

        // Optional. Required if the snapshot contains 'admin' user.
        "druidAdminUserSecretArn": "<The ARN of secret which stores username and password of the admin user >",

        // Optional. The parameter group name for DB instance.
        "rdsParameterGroupName": string,

        // Optional. Aurora PostgreSQL engine version. The default version is 13.6. Please be aware that updating the version of your existing RDS instance will not result in data migration.
        "rdsEngineVersion": string
    }
}   

Example configuration to create a metadata store from snapshot:

"druidMetadataStoreConfig": {
    "metadataStoreType": "aurora",
    "metadataStoreConfig": {
        "rdsInstanceType": "t3.large",
        "rdsInstanceCount": 2,
        "rdsSnapshotArn": "arn:aws:rds:<region>:<account-id>:cluster-snapshot:<snapshort-name>",
        "rdsSnapshotEncryptionKeyArn": "arn:aws:kms:<region>:<account-id>:key/<key-id>",
        "druidInternalUserSecretArn": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-id>",
        "druidAdminUserSecretArn": "arn:aws:secretsmanager:<region>:<account-id>:secret:<secret-id>",
        "rdsParameterGroupName": "aurora-postgresql13",
        "rdsEngineVersion": "13.6"
    }
}      

Use your own PostgreSQL database for metadata store

This section explains how to use your own PostgreSQL database for the metadata store.

"druidMetadataStoreConfig": {
    "metadataStoreType": "custom",
    "metadataStoreConfig": {
        // The endpoint address of database
        "databaseUri": string,

        // Optional. The listening port of database. Default to be 5432.
        "databasePort": number,

        // Optional. Database name. Default to be DruidMetadata.
        "databaseName": string,

        // The ARN of secret in secrets manager which stores the administrative username and password in JSON format
        // The secret must contain fields namely "username" and "password"
        "databaseSecretArn": string
    }
}   

Example configuration to connect to an external metadata store:

"druidMetadataStoreConfig": {
    "metadataStoreType": "custom",
    "metadataStoreConfig": {
        "databaseUri": "druidec2stack-dev296-druidmetadataconstructaurorac-xxx.cluster-xxx.us-east-1.rds.amazonaws.com",
        "databasePort": 5432,
        "databaseName": "DruidMetadata",
        "databaseSecretArn": "arn:aws:secretsmanager:<region>:<account>:secret:<secret-id>"
    }
}

Druid deep storage

By default, this solution will set up a bucket in Amazon S3 for deep storage. To use your own bucket for deep storage, you can override this default configuration using the following configuration:

"druidDeepStorageConfig": {
    // The ARN of S3 bucket to be used as deep storage
    "bucketArn": string,
    // The bucket prefix to be used to store segments
    "bucketPrefix": string,
    // Optional when using SSE-S3. The KMS key to be used to encrypt the data.
    "bucketEncryptionKeyArn": string
} 

Example deep storage configuration:

"druidDeepStorageConfig": {
    "bucketArn": "arn:aws:s3:::<bucket-id>",
    "bucketPrefix": "druid/segments",
    "bucketEncryptionKeyArn": "arn:aws:kms:<region>:<account-id>:key/<key-id>"
}

Druid EC2 configuration

Auto scaling group configuration

This section provides instructions and details about the Auto scaling group configuration for a variety of Druid node types, including master, query, data, historical, middleManager, and ZooKeeper.

This solution also fully supports the service tiering functionalities provided by Druid, offering enhanced resource management and optimization. The service tiering feature allows you to create distinct groups of Historicals and Brokers, each responsible for managing queries based on the segments and resource requirements of the query.

It covers the following fields for each node type:

// Druid node type. Valid values include data, master, query, and zookeeper. In case of service tiering, it also supports data_<tier>, historical_<tier>, middleManager_<tier>

"<Druid node type>": {
      // Minimum number of EC2 instances in the auto scaling group
      "minNodes": number,

      // Optional, maximum number of EC2 instances in the auto scaling group
      "maxNodes": number,
        
      // Optional. EBS volume size in GB for the root file system of EC2 instance.
      "rootVolumeSize": number,

      // Optional. The size of EBS volume (GB) utilized for segment caching on historical node. Required if not using storage optimized instance types.
      "segmentCacheVolumeSize": number,

      // EC2 instance type. eg. m5.2xlarge.
      "instanceType": string

      }

Rolling update policy (optional)

A rolling update is a deployment strategy that incrementally replaces previous versions of an application with new versions of an application by completely replacing the infrastructure on which the application is running.

It minimizes the impact on application availability and ensures a smooth transition to the new version.

The solution operates on a default process of sequentially replacing the Druid EC2 instances in a specific order: data, query, and master. This replacement process involves stopping the previous instance initially, followed by the creation of a new instance.

Once the new instance is confirmed to be in a healthy state, the process proceeds to replace the next instance in the specified order. In the event that an instance is deemed unhealthy during the update process, the system will initiate a rollback to the previous version.

You can customize and override the batch size using the following configuration:

// Optional. The rollingUpdatePolicy defines how an Auto Scaling group resource is updated.
"rollingUpdatePolicy": {
    // Optional. Number of instances that is going to be replaced in each batch. Default 1.
    "maxBatchSize": number
},  

Auto scaling policy (optional)

An Auto scaling policy consists of predefined rules and parameters that dictate how the scaling process should occur. These rules are defined by the user based on specific metrics, such as CPU utilization, network traffic, or application-specific performance metrics. In addition to dynamic auto scaling based on Scalable metrics, it also offers schedule-based auto scaling.

"autoScalingPolicy": {
    "cpuUtilisationPercent": number between [1, 100],
    "schedulePolicies": [
        {
            // A UTC timestamp represented by a cron expression.
            // eg. "0 5 * * *" means 5:00 AM in UTC time
            "scheduleExpression": "<cron expression>",
            "minNodes": number,
            "maxNodes": number
        }
    ]
}       

Runtime configuration (optional)

The solution comes pre-configured with Druid, which suits most use cases. You can customize the Druid configuration (runtime.properties) using the following settings:

"runtimeConfig": {
    // Druid process type depending on the node type. Valid values include coordinator, overlord, middleManager, historical, router, and broker.
    "<Druid process type>": {
        // The key name of Druid configuration item. eg. druid.server.http.numThreads
        "<druid configuration key>": "<druid configuration value>"
        ...
    },
}        

Runtime configuration customization example:

"runtimeConfig": {
    "historical": {
        "druid.server.http.numThreads": 300
    },
    "middleManager": {
        "druid.server.http.numThreads": 200
    }
}

Druid EC2 configuration example

"druidEc2Config": {
    "master": {
        "minNodes": 2,
        "maxNodes": 2,
        "rootVolumeSize": 50,
        "instanceType": "m5.2xlarge"
    },
    "query": {
        "minNodes": 2,
        "maxNodes": 3,
        "rootVolumeSize": 50,
        "instanceType": "m5.2xlarge",
        "autoScalingPolicy": {
            "cpuUtilisationPercent": 60
        }
    },
    "data": {
        "minNodes": 3,
        "maxNodes": 3,
        "rootVolumeSize": 200,
        "segmentCacheVolumeSize": 500,
        "instanceType": "m5d.2xlarge"
    },
    "zookeeper": {
        "minNodes": 3,
        "maxNodes": 3,
        "rootVolumeSize": 50,
        "instanceType": "m6g.xlarge"
    }
}

Example: Druid deployment using EC2 for a medium profile

{
    "vpcCidr": "xx.xxx.0.0/16",
    "route53HostedZoneName": "<route53 hosted zone name>",
    "route53HostedZoneId": "<route 53 hosted zone ID>",
    "druidDomain": "<Domain where Druid is hosted>",
    "internetFacing": true,
    "druidClusterName": "ec2",
    "druidVersion": "30.0.0",
    "druidOperationPlatform": "ec2",
    "retainData": true,
    "druidExtensions": [
        "druid-hdfs-storage",
        "druid-kafka-indexing-service",
        "druid-datasketches",
        "druid-s3-extensions",
        "postgresql-metadata-storage",
        "druid-kinesis-indexing-service",
        "druid-avro-extensions",
        "druid-parquet-extensions",
        "druid-protobuf-extensions",
        "druid-cloudwatch",
        "druid-orc-extensions",
        "druid-basic-security",
        "druid-pac4j",
        "simple-client-sslcontext"
    ],
        "druidEc2Config": {
            "master": {
                "minNodes": 3,
                "maxNodes": 3,
                "rootVolumeSize": 50,
                "instanceType": "m6g.xlarge"
            },
            "query": {
                "minNodes": 3,
                "maxNodes": 3,
                "rootVolumeSize": 50,
                "instanceType": "m6g.xlarge"
            },
            "data": {
                "minNodes": 3,
                "maxNodes": 3,
                "rootVolumeSize": 200,
                "segmentCacheVolumeSize": 500,
                "instanceType": "m6g.2xlarge"
            },
            "zookeeper": {
                "minNodes": 3,
                "maxNodes": 3,
                "instanceType": "t4g.medium"
            }
        },
        "druidMetadataStoreConfig": {
            "metadataStoreType": "aurora",
            "metadataStoreConfig": {
                "rdsInstanceType": "t3.medium",
                "rdsInstanceCount": 3
            }
        }
}

You can find more configuration examples about EC2 configuration in the source/quickstart directory.

Druid EKS configuration

The solution will set up a new Amazon EKS cluster to serve as the hosting environment for Druid.

This section provides instructions on the configuration for the EKS cluster, including node group settings, involves the provisioning of four distinct node groups during deployment: master, query, data, and zookeeper.

EKS cluster configuration

"druidEksConfig": {
    // Kubernetes API server endpoint access. Valid values include PUBLIC, PRIVATE, and PUBLIC_AND_PRIVATE
    "endpointAccess": "PUBLIC",

    // The ARN of IAM role for the EKS cluster master
    "clusterMasterPrincipalArn": "<the ARN of IAM role for the cluster master>",

    // The underlying capacity provider for the EKS cluster. Valid values include ec2 and fargate.
    "capacityProviderType": "<ec2 or fargate>",

    // The capacity provider configuration. It differs based on the chosen capacity provider.
    "capacityProviderConfig": {
    }
} 

EC2 capacity provider configuration

This is required if capacityProviderType is ec2.

// Node group name, valid values include master, query, data, and zookeeper. In case of service tiering, data_<tier> is also supported.

"<nodeGroupName>": {
    // Minimum number of EC2 instances in the node group
    "minNodes": number,

    // Optional. Maximum number of EC2 instances in the node group
    "maxNodes": number,

    // Optional. EBS volume size in GB for the root file system of EC2 instance.
    "rootVolumeSize": number,

    // EBS volume size in GB. Persistent volume for middleManager pods. Only required for middleManager pods.
    "taskCacheVolumeSize": number,

    // EBS volume size in GB. Persistent volume for historical pods. Only required for historical pods.
    "segmentCacheVolumeSize": number,

    // EC2 instance type for the node group.
    "instanceType": string
},        

Fargate capacity provider configuration

This is required if capacityProviderType is Fargate.

// Druid process name, valid values include coordinator, overlord, middleManager, historical, router, broker, and zookeeper.

"<druidProcessName>": {
    // Minimum number of kubernetes pods
    "minNodes": number,

    // Optional. Maximum number of kubernetes pods
    "maxNodes": number,

    // Number of vCPUs to assign to each pod. eg. 2 means 2 vCPUs.
    "cpu": number,

    // The amount of memory to assign to each pod. eg. 4Gi means 4GB memory.
    "memory": string
}        

Druid EKS configuration example (EC2 capacity provider)

"druidEksConfig": {
    "endpointAccess": "PUBLIC",
    "clusterMasterPrincipalArn": "arn:aws:iam::<account id>:role/<role name>",
    "capacityProviderType": "ec2",
    "capacityProviderConfig": {
        "master": {
            "minNodes": 2,
            "maxNodes": 2,
            "rootVolumeSize": 50,
            "instanceType": "m5.2xlarge"
        },
        "query": {
            "minNodes": 2,
            "maxNodes": 2,
            "rootVolumeSize": 50,
            "instanceType": "m5.2xlarge"
        },
        "data": {
            "minNodes": 3,
            "maxNodes": 3,
            "rootVolumeSize": 50,
            "taskCacheVolumeSize": 300,
            "segmentCacheVolumeSize": 500,
            "instanceType": "m5.2xlarge"
        },
        "zookeeper": {
            "minNodes": 3,
            "maxNodes": 3,
            "rootVolumeSize": 50,
            "instanceType": "m5.large"
        }
    }
}        

Example: Druid deployment using EKS for a medium profile

{
    "vpcCidr": "xx.xxx.0.0/16",
    "route53HostedZoneName": "<route53 hosted zone name>",
    "route53HostedZoneId": "<route 53 hosted zone ID>",
    "druidDomain": "<Domain where Druid is hosted>",
    "internetFacing": true,
    "druidClusterName": "eks",
    "retainData": false,
    "druidVersion": "30.0.0",
    "druidOperationPlatform": "eks",
    "druidExtensions": [
        "druid-hdfs-storage",
        "druid-kafka-indexing-service",
        "druid-datasketches",
        "druid-s3-extensions",
        "postgresql-metadata-storage",
        "druid-kinesis-indexing-service",
        "druid-avro-extensions",
        "druid-parquet-extensions",
        "druid-protobuf-extensions",
        "druid-cloudwatch",
        "druid-orc-extensions",
        "druid-basic-security",
        "druid-pac4j"
    ],
    "druidEksConfig": {
        "endpointAccess": "PUBLIC",
        "clusterMasterPrincipalArn": "arn:aws:iam::<account id>:role/<role name>",
        "capacityProviderType": "ec2",
        "capacityProviderConfig": {
            
"master": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "instanceType": "m5.xlarge"
                },
                "query": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "instanceType": "m5.xlarge"
                },
                "data": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "taskCacheVolumeSize": 300,
                    "segmentCacheVolumeSize": 500,
                    "instanceType": "m5.large"
                },
                "zookeeper": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "rootVolumeSize": 50,
                    "instanceType": "t3.medium"
                }
            }
        },
        "druidMetadataStoreConfig": {
            "metadataStoreType": "aurora",
            "metadataStoreConfig": {
                "rdsInstanceType": "t3.medium",
                "rdsInstanceCount": 3
            }
    }
}        

Example: Druid configuration using EKS and Fargate, for a medium profile

{
    "vpcCidr": "xx.xxx.0.0/16",
    "route53HostedZoneName": "<route53 hosted zone name>",
    "route53HostedZoneId": "<route 53 hosted zone ID>",
    "druidDomain": "<Domain where Druid is hosted>",
    "internetFacing": true,
    "druidVersion": "27.0.0",
    "druidClusterName": "fargate",
    "druidOperationPlatform": "eks",
    "retainData": false,
    "druidExtensions": [
        "druid-hdfs-storage",
        "druid-kafka-indexing-service",
        "druid-datasketches",
        "druid-s3-extensions",
        "postgresql-metadata-storage",
        "druid-kinesis-indexing-service",
        "druid-avro-extensions",
        "druid-parquet-extensions",
        "druid-protobuf-extensions",
        "druid-cloudwatch",
        "druid-orc-extensions",
        "druid-basic-security",
        "druid-pac4j"
    ],
    
"druidEksConfig": {
            "endpointAccess": "PUBLIC",
            "clusterMasterPrincipalArn": "arn:aws:iam::<account id>:role/<role name>",
            "capacityProviderType": "fargate",
            "capacityProviderConfig": {
                "historical": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 4,
                    "memory": "16Gi"
                },
                "middleManager": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 4,
                    "memory": "16Gi"
                },
                "broker": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 2,
                    "memory": "8Gi"
                },
                "router": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 2,
                    "memory": "8Gi"
                },
                "coordinator": {
                    "minNodes": 1,
                    "maxNodes": 1,
                    "cpu": 2,
                    "memory": "8Gi"
                },
                "overlord": {
                    "minNodes": 1,
                    "maxNodes": 1,
                    "cpu": 2,
                    "memory": "8Gi"
                },
                "zookeeper": {
                    "minNodes": 3,
                    "maxNodes": 3,
                    "cpu": 2,
                    "memory": "4Gi"
                }
            }
        },
        "druidMetadataStoreConfig": {
            "metadataStoreType": "aurora",
            "metadataStoreConfig": {
                "rdsInstanceType": "t3.medium",
                "rdsInstanceCount": 3
            }
    }
}        

You can find more examples about EKS configuration in the source/quickstart directory.