# Plan your deployment Plan your deployment This section describes the [Cost](cost.md), [security](security-1.md), and [quotas](quotas.md) considerations prior to deploying the guidance. ## Supported AWS Regions Scalable Analytics using Apache Druid on AWS is available in the following AWS Regions: | Region code | Region name | | --- | --- | | us-east-1 | US East (N. Virginia) | | us-east-2 | US East (Ohio) | | us-west-1 | US West (Northern California) | | us-west-2 | US West (Oregon) | | af-south-1 | Africa (Cape Town) | | ap-east-1 | Asia Pacific (Hong Kong) | | ap-south-2 | Asia Pacific (Hyderabad) | | ap-southeast-3 | Asia Pacific (Jakarta) | | ap-southeast-4 | Asia Pacific (Melbourne) | | ap-south-1 | Asia Pacific (Mumbai) | | ap-northeast-3 | Asia Pacific (Osaka) | | ap-northeast-2 | Asia Pacific (Seoul) | | ap-southeast-1 | Asia Pacific (Singapore) | | ap-southeast-2 | Asia Pacific (Sydney) | | ap-northeast-1 | Asia Pacific (Tokyo) | | ca-central-1 | Canada (Central) | | eu-central-1 | Europe (Frankfurt) | | eu-west-1 | Europe (Ireland) | | eu-west-2 | Europe (London) | | eu-west-3 | Europe (Paris) | | eu-south-2 | Europe (Spain) | | eu-north-1 | Europe (Stockholm) | | eu-central-2 | Europe (Zurich) | | me-south-1 | Middle East (Bahrain) | | me-central-1 | Middle East (UAE) | | sa-east-1 | South America (São Paulo) | **Federal Risk and Authorization Management Program (FedRAMP) compliance** This guidance meets FedRAMP moderate baseline requirements (and subsequently Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG) Impact Level 2 (IL2)) for AWS US East-West Regions. For more information, see our [FedRAMP compliance](https://aws.amazon.com/compliance/fedramp/) page. # Cost You are responsible for the cost of the AWS services used while running this guidance. As of the latest revision, the costs for running this guidance with the default settings (small usage profile) in the US East (N. Virginia) Region is approximately **\$1714.46 per month**, for a medium usage profile in the US East (N. Virginia) Region is approximately **\$12,202.47 per month**, and for a large usage profile in the US East (N. Virginia) Region is approximately **\$113,645.27 per month**. These costs are for the resources shown in the [Cost table](#cost-table) section. See the pricing webpage for each AWS service used in this guidance. We recommend creating a [budget](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create.html) through [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) to help manage costs. Prices are subject to change. For full details, see the pricing webpage for each [AWS service used in this guidance](aws-services-in-this-solution.md). ## Cost table The following tables provide a sample cost breakdown for deploying this guidance with the default parameters in the US East (N. Virginia) Region for one month, encompassing the small, medium, and large usage profiles. **Small usage profile** Profile assumptions: ingestion throughput at 30,000 records per second, query throughput at 25 queries per second. | AWS service | Dimensions | Cost [USD] | | --- | --- | --- | | Amazon EC2 | \$1 Druid master: 3 x t4g.medium \$1 Druid query: 3 x t4g.medium \$1 Druid data: 3 x (t4g.medium \$1 100GB EBS GP2 volume) \$1 ZooKeeper: 3 x t4g.small | \$1287.53 | | Amazon ELB | 1 x ALB, 5 GB/h processed bytes (EC2 Instances and IP addresses as targets) | \$145.63 | | Amazon Aurora | 3 x db.t4g.medium | \$1247.81 | | Amazon S3 | 1 TB standard storage \$1 1,000,000 requests per month | \$129.67 | | AWS Key Management Service | 7 x customer managed keys | \$17 | | AWS Secrets Manager | 4 x secrets | \$11.6 | | Amazon CloudWatch | 50 GB standard logs ingested per month, 200 custom metrics \$1 1,000,000 metric requests per month | \$195.22 | | | **Total:** | **\$1714.46 [USD] / month** | **Medium usage profile** Profile assumptions: ingestion throughput at 120,000 records per second, query throughput at 100 queries per second. | AWS service | Dimensions | Cost [USD] | | --- | --- | --- | | Amazon EC2 | \$1 Druid master: 3 x m6g.xlarge \$1 Druid query: 3 x m6g.xlarge \$1 Druid data: 3 x (m6g.2xlarge \$1 500GB EBS GP2 volume) \$1 ZooKeeper: 3 x t4g.medium | \$11,572.62 | | Amazon ELB | 1 x ALB, 20 GB/h processed bytes (EC2 Instances and IP addresses as targets) | \$1133.23 | | Amazon Aurora | 3 x db.t4g.medium | \$1247.81 | | Amazon S3 | 5 TB standard storage \$1 5,000,000 requests per month | \$1119.76 | | AWS Key Management Service | 7 x customer managed keys | \$17 | | AWS Secrets Manager | 4 x secrets | \$11.6 | | Amazon CloudWatch | 100 GB standard logs ingested per month, 200 custom metrics \$1 1,000,000 metric requests per month | \$1120.45 | | | **Total:** | **\$12,202.47 [USD] / month** | **Large usage profile** Profile assumptions: ingestion throughput at 1.4 million records per second, query throughput at 1,200 queries per second. | AWS service | Dimensions | Cost [USD] | | --- | --- | --- | | Amazon EC2 | \$1 Druid master: 3 x m6g.4xlarge \$1 Druid query: 3 x m6g.4xlarge \$1 Druid data: 3 x (m6g.16xlarge \$1 5 TB EBS GP2 volume) \$1 ZooKeeper: 3 x m6g.2xlarge | \$110,268.76 | | Amazon ELB | 1 x ALB, 200 GB/h processed bytes (EC2 Instances and IP addresses as targets) | \$11,184.43 | | Amazon Aurora | 3 x db.t3.large | \$1427.39 | | Amazon S3 | 50 TB standard storage \$1 10,000,000 requests per month | \$11,181.60 | | AWS Key Management Service | 7 x customer managed keys | \$17 | | AWS Secrets Manager | 4 x secrets | \$11.6 | | Amazon CloudWatch | 1,000 GB standard logs ingested per month, 200 custom metrics \$1 1,000,000 metric requests per month | \$1574.50 | | | **Total:** | **\$113,645.27 [USD] / month** | # Security When you build systems on AWS infrastructure, security responsibilities are shared between you and AWS. This [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) reduces your operational burden because AWS operates, manages, and controls the components including the host operating system, the virtualization layer, and the physical security of the facilities in which the services operate. For more information about AWS security, visit [AWS Cloud Security](https://aws.amazon.com/security/). ## IAM roles AWS Identity and Access Management (IAM) roles allow customers to assign granular access policies and permissions to services and users on the AWS Cloud. The guidance creates IAM roles that grant the guidance’s constructs to access Regional resources provisioned by the guidance, such as: + IAM role used by the EC2 instances that run Druid workloads to read and write data in S3 buckets. + IAM roles used by AWS CloudFormation custom resources to retrieve the password from the Druid `system_user` secret within AWS Secrets Manager. By default, all Amazon S3 buckets for the guidance have the following configuration: + Blocked all public access + Versioning enabled + Access log enabled + Encryption at rest by an AWS KMS customer managed key Additionally, the Amazon S3 buckets are also configured with a default buckets policy that deny all non-HTTPS requests to ensure data in transit encryption. ## AWS WAF This guidance incorporates the deployment of AWS Web Application Firewall (WAF) when the Application Load Balancer (ALB) is configured to be internet-facing. AWS WAF is used to enhance the security of the web applications exposed through the ALB by providing protection against various web-based threats and attacks. ## AWS Key Management Service keys The guidance allows you to provide your own AWS KMS keys to encrypt stored data in the S3 bucket and Aurora cluster. We recommend referring to the [security best practices for AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html) to enhance the protection of your encryption keys. ## Data protection All data committed to the guidance is encrypted at rest using [AWS Key Management Service](https://aws.amazon.com/kms/) (AWS KMS) customer managed keys. This includes data stored in the following services: + Amazon S3 + Amazon Aurora + Amazon SNS Communication between the guidance’s different components is over HTTPS to ensure data encryption in transit. # Security best practices This section provides several security features to consider, as you develop and implement your own security policies. **Note** The following best practices are general guidelines and do not represent a complete security guidance. These best practices might not be appropriate or sufficient for your specific environment, so treat them as helpful considerations, not prescriptive guidance. ## User authentication and authorization The guidance is configured to utilize basic authentication by default, offering adaptability for additional support such as OIDC and LDAP authentication through configuration settings. However, we advise caution when customizing user authentication and authorization settings. + In a production environment, we strongly recommend activating basic authentication at the very least to maintain a baseline security measure. + For OIDC authentication, ensuring the accuracy of group and role mapping is essential. + When creating Druid roles, adhere to the principle of least privilege to establish a minimum permission security stance. ## Domain and TLS certificate The guidance integrates with [Amazon Route 53](https://aws.amazon.com/route53/) and [AWS Certificate Manager](https://aws.amazon.com/acm/), streamlining the provisioning of a domain and TLS certificate during deployment when a Route53 hosted zone configuration is specified. Alternatively, it provides the flexibility to deploy without Route 53 configuration, allowing for an external domain setup. In this scenario, a default HTTP listener is established using the application load balancer, and traffic will be exposed over HTTP without encryption in transit. This scenario poses significant security risks, such as the potential for eavesdropping on sensitive information. To address this concern, we highly recommended establishing a custom domain and employ the TLS policy *ELBSecurityPolicy-TLS13-1-2-2021-06* to enhance security by encrypting the data in transit. Upon completing the external domain setup, it is recommended to configure the TLS certificate ARN along with the domain, and trigger a redeployment of the guidance to implement these changes. This verifies that the application load balancer exposes HTTPS, thereby fortifying communication security through TLS encryption. ## Third-party extensions The guidance’s default configuration includes a minimum set of essential extensions to enable core functionalities. Users have the flexibility to tailor the list of extensions that can be loaded into the cluster. It is important for users to assume responsibility for the security of the selected extensions. To uphold a robust security posture, we strongly advise consistently monitoring for new releases and promptly applying updates, thereby proactively addressing and mitigating any potential vulnerabilities. ## Deploy the guidance into existing VPC The guidance offers the flexibility to deploy into an existing VPC. When opting for this configuration, it is advisable to ensure that the existing VPC is equipped with three distinct types of subnets: public, private, and isolated, spanning across at least two availability zones. Whether a subnet is public or private refers to whether traffic within the subnet is routed through an internet gateway. Public subnets have a route table entry to the internet through the internet gateway, but private subnets do not have this entry. Isolated subnets have no routes to destinations outside its VPC. For more information about subnet types, refer to the definition of [subnet types](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types). This strategic subnet arrangement allows for optimal separation of component; the RDS database clusters operate in the isolated subnets, Druid nodes in the private subnets, and the load balancer is positioned in the public subnets. This architecture enhances security and scalability by appropriately isolating different layers of the infrastructure. ## AMI security The guidance automatically selects the latest AMI for Amazon Linux 2 in the deployment process. Opting for the most recent AMI ensures that the system benefits from the latest security patches, thereby maintaining an up-to-date and secure environment. This proactive approach aligns with best practices for security and helps safeguard the integrity of the deployed instances. Continuous use of the latest AMI version contributes to a more resilient and well-protected infrastructure. The guidance also supports the flexibility to bring your own AMI. It is important to ensure that your base AMI adheres to security best practices. + Start with a secure and minimal base image, and then apply patches systematically to maintain a secure foundation for your instances. + Establish a routine and predictable patching schedule for your AMIs. + Regularly check for operating system and software updates, and apply patches in a timely manner to address known vulnerabilities. ## Public and private mode for EKS cluster endpoint Amazon EKS offers public-only, public-and-private, and private-only cluster endpoint modes. The default mode is configured to be private-only in the guidance, however we recommend configuring cluster endpoint in public and private mode. This option allows Kubernetes API calls within your cluster’s VPC (such as node-to-control-plane communication) to use the private VPC endpoint and traffic to remain within your cluster’s VPC. You can access your cluster API server from the internet. However, we strongly recommend limiting the CIDR blocks that can use the public endpoint. Learn how to configure public and private endpoint access, including limiting CIDR blocks. For more guidance on how to secure the EKS clusters, refer to the [EKS best practices](https://aws.github.io/aws-eks-best-practices/security/docs/) topic. ## EKS master IAM role For EKS deployment, the guidance requires the user to supply an ARN for the EKS master role. This role, serving as the IAM principal responsible for creating the cluster, is automatically endowed with `system:masters` permissions within the cluster’s Role-Based Access Control (RBAC) configuration in the Amazon EKS control panel. For more guidance on how to secure the access for this role, refer to the [EKS best practices](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#create-the-cluster-with-a-dedicated-iam-role) topic. # Quotas Service Quotas, also referred to as limits, are the maximum number of service resources or operations for your AWS account. ## Quotas for AWS services in this guidance Make sure you have sufficient quota for each of the [services implemented in this guidance](aws-services-in-this-solution.md). For more information, see [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html). Use the following links to go to the page for that service. To view the service quotas for all AWS services in the documentation without switching pages, view the information in the [Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/aws-general.pdf#aws-service-information) page in the PDF instead. ## AWS CloudFormation quotas Your AWS account has AWS CloudFormation quotas that you should be aware of when [launching the stack](deployment-process-overview.md) in this guidance. By understanding these quotas, you can avoid limitation errors that would prevent you from deploying this guidance successfully. For more information, see [AWS CloudFormation quotas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-limits.html) in the *AWS CloudFormation User’s Guide*.