Multi-Cloud Deployment
HatiData runs on AWS, GCP, and Azure through a cloud-agnostic abstraction layer. The same codebase supports all three providers, and infrastructure-as-code modules provide consistent provisioning across clouds. This page covers the abstraction architecture and deployment topology per provider.
Cloud-Agnostic Design
HatiData's multi-cloud support is built on three abstraction layers that isolate cloud-specific implementation details from the core platform:
- Storage abstraction — A unified interface for object storage that works identically across S3, GCS, and Azure Blob Storage
- Key management abstraction — A unified interface for encryption key operations across AWS KMS, GCP Cloud KMS, and Azure Key Vault
- Identity federation — Cloud-native authentication that eliminates long-lived credentials on all three providers
Each abstraction has a local implementation for development and air-gapped deployments, so no cloud dependencies are required for local operation.
The platform can be built for a single cloud provider (reducing binary size and dependencies) or for all three simultaneously. Local-only builds have zero cloud dependencies.
Storage Abstraction
Object storage is used for cached query results, audit log archival, snapshot storage, and data exports. HatiData provides a single storage interface with four implementations:
| Backend | Cloud | Configuration |
|---|---|---|
| AWS S3 | AWS | Bucket name + region |
| Google Cloud Storage | GCP | Bucket name + region |
| Azure Blob Storage | Azure | Container name + region |
| Local filesystem | Local / dev | Storage path (default: ./data/storage) |
The backend is selected at deployment time based on your cloud provider configuration. All implementations support the same operations: put, get, delete, list, and exists.
Key Management Abstraction
Encryption key management handles data key generation, encryption, and decryption. HatiData provides a single key management interface with four implementations:
| Backend | Cloud | Key ID Format |
|---|---|---|
| AWS KMS | AWS | arn:aws:kms:region:account:key/id |
| Google Cloud KMS | GCP | projects/p/locations/l/keyRings/r/cryptoKeys/k |
| Azure Key Vault | Azure | https://vault.vault.azure.net/keys/name |
| Local AES-256-GCM | Local / dev | Local key file path |
The default provider is local for development. Production deployments should use cloud KMS for key management, rotation, and audit logging.
Federation (Workload Identity)
HatiData supports cloud-native authentication to eliminate long-lived credentials:
| Provider | Mechanism | Configuration |
|---|---|---|
| AWS | IAM Roles for Service Accounts | Instance profile / EKS IRSA |
| GCP | Workload Identity Federation | Service account binding on GKE / Cloud Run |
| Azure | Managed Identity | System-assigned or user-assigned on AKS |
Cloud-native identity federation means agents running in GKE pods, ECS tasks, or AKS pods do not need to manage any credentials at all — they exchange their cloud-provider identity for a HatiData JWT automatically.
# GCP: proxy running on Cloud Run uses Workload Identity automatically
# No static credentials needed
# AWS: proxy running on EKS uses IRSA
# IAM role is attached via service account annotation
# Azure: proxy running on AKS uses Managed Identity
# Identity is assigned via Azure AD workload identity
Per-Cloud Deployment Options
AWS
HatiData on AWS deploys the data plane on EC2 instances (auto-scaling group) with high-performance local SSD for the local cache tier. Infrastructure includes:
- Compute: EC2 auto-scaling group with launch template
- Networking: VPC with private subnets, NAT gateway, Network Load Balancer
- Storage: S3 with Object Lock for tamper-evident audit storage
- Encryption: KMS with automatic key rotation
- Private connectivity: VPC Endpoint Service (PrivateLink)
- Monitoring: CloudWatch dashboards and alarms
GCP
HatiData on GCP offers two deployment modes:
GKE (data plane): Standard GKE cluster with node pools configured for high-performance local SSD. Ideal for organizations that need full Kubernetes control over their data plane.
Cloud Run (control plane): Serverless deployment for the control plane, with Cloud SQL for metadata and Secret Manager for credentials. Ideal for managed, low-operational-overhead deployments.
Additional infrastructure:
- Storage: GCS bucket with retention policies
- Encryption: Cloud KMS key ring and crypto key
- Private connectivity: Private Service Connect
- Monitoring: Cloud Monitoring and alerting
Azure
HatiData on Azure deploys with:
- Compute: AKS cluster for the data plane
- Networking: Virtual Network with subnets and NSGs
- Storage: Azure Blob Storage with immutability policies
- Encryption: Azure Key Vault for key management
- Private connectivity: Private Link Service and endpoint
- Monitoring: Azure Monitor and Log Analytics
Infrastructure as Code
Each cloud provider has a complete set of Terraform modules covering networking, compute, storage, encryption, identity, private connectivity, and monitoring. A shared module provides cross-cloud variable definitions and output formats.
Deployment follows a standard workflow:
# Initialize and plan for your cloud provider
terraform init
terraform plan -var-file=environments/production.tfvars
# Apply
terraform apply -var-file=environments/production.tfvars
Environment-specific variable files (dev, staging, production) control instance sizing, scaling parameters, and feature toggles. Development and staging environments can use spot/preemptible instances for cost optimization.
Related Concepts
- Two-Plane Model -- Data plane vs control plane
- PrivateLink & VPC -- Private networking per cloud
- Security Model -- Auth across cloud providers
- Cost Model -- Pricing across cloud tiers