Datalore On-Premises in AWS
This section provides AWS-related information that is recommended for consideration when planning Datalore On-Premises deployment in AWS.
Regions supported
Datalore has been tested and can be run in all the AWS regions where Elastic Kubernetes is available (excluding AWS China, which is currently not supported).
Reference architecture
The below diagram represents the most typical Datalore deployment within the AWS environment (click for full screen view).
Architectural considerations
The above diagram shows an approximate approach to Datalore deployment, leaving out some environmental-specific components (for example, the networking part).
Below are some of the key aspects for environment administrators to consider when planning their Datalore deployment tailored to their needs.
IAM permissions
Make sure the IAM entity used to deploy Datalore has sufficient permissions to interact with the EKS cluster. This will enable you to provision new entities (StatefulSet, Pod, Ingress, ConfigMap, Secret) in a desired namespace.
For more guidance, refer to the EKS documentation about the managing access entries.
Networking
By its nature Datalore has also to communicate with various data sources, which could be located anywhere: from the same AWS region to an on-premises database exposed via a VPN.
Therefore, it is required to configure an appropriate egress security group's rules to allow Datalore agents to communicate with these data sources. The same rule applies both for when the data source is remote (on-premises) or local to the environment (Datalore and the database deployed in different VPCs which are connected via VPC peering, as an example).
Database
For its own operation, Datalore requires a PostgreSQL database. We recommend referring to Getting started with RDS for database provisioning instructions.