Private Cloud Deployment
Run MX4 Atlas in your own VPC.
Overview
Private cloud deployment allows you to run MX4 Atlas within your own Virtual Private Cloud (VPC) while maintaining full control over your data and infrastructure. This option provides infrastructure sovereignty with cloud flexibility.
Deployment Prerequisites
Infrastructure Requirements
- ✓ Dedicated VPC with CIDR block
- ✓ Private subnets (at least 3 across AZs)
- ✓ NAT gateways for egress traffic
- ✓ VPC Flow Logs enabled
- ✓ Kubernetes cluster (EKS/AKS/GKE) 1.24+
Access & Security
- ✓ KMS/Key Vault setup for encryption
- ✓ Service account with minimal permissions
- ✓ SSL certificates for TLS
- ✓ Network security group/firewall rules
- ✓ Audit logging configured
Pre-Deployment Checklist
Network isolation verified
Private subnet config, no public IPs for compute
Encryption enabled
KMS keys created, key policy configured
RBAC configured
Service accounts with least privilege
Monitoring setup
CloudWatch/Azure Monitor/Cloud Logging
Backup strategy
Snapshots, disaster recovery plan
DNS and TLS
Private hosted zones, valid certificates
Cloud Provider Best Practices
AWS Best Practices
- • Use VPC endpoints to eliminate internet gateway exposure
- • Enable VPC Flow Logs for network troubleshooting
- • Configure AWS PrivateLink for secure cross-account access
- • Use CloudFront with S3 for model artifact distribution
- • Implement instance profiles instead of storing credentials
Azure Best Practices
- • Use Private Endpoints to block all public access
- • Enable Azure Bastion for secure VM access
- • Implement Azure DDoS Protection Standard
- • Use Managed Identities instead of shared credentials
- • Configure Azure Policy for access control enforcement
GCP Best Practices
- • Disable public IPs on all compute instances
- • Use Cloud NAT for egress-only access
- • Implement Cloud Armor for DDoS protection
- • Configure VPC Service Controls for data exfiltration prevention
- • Use Service Accounts with Workload Identity
MX4 Atlas supports deployment on all major cloud platforms with infrastructure-as-code templates.
Amazon Web Services (AWS)
Deploy in your AWS VPC with support for EKS, ECS, and EC2. Includes CloudFormation templates and Terraform modules.
Key features: KMS encryption, VPC endpoints, CloudTrail integration, AWS Config baselines
Microsoft Azure
Deploy in Azure Virtual Networks with AKS support. Includes ARM templates and Terraform configurations.
Key features: Azure Key Vault, Private Link, Azure Monitor, Azure Policy controls
Google Cloud Platform (GCP)
Deploy in GCP VPC networks with GKE support. Includes Deployment Manager templates and Terraform modules.
Key features: Cloud KMS, Private Google Access, Cloud Logging, Organization Policy controls
Deployment Methods
Terraform
Infrastructure-as-code deployment with version control and automated provisioning.
1module "mx4_atlas" {2 source = "mx4/atlas/aws"3 version = "~> 1.0"45 vpc_id = var.vpc_id6 subnet_ids = var.private_subnet_ids78 security = {9 encryption = "kms"10 sovereignty = "local"11 }12}
Helm Charts
Kubernetes-native deployment with Helm for container orchestration.
1# Add MX4 Helm repository2helm repo add mx4 https://charts.mx4.ai3helm repo update45# Install Atlas6helm install atlas mx4/atlas \7 --namespace mx4-atlas \8 --set security.encryption.enabled=true \9 --set sovereignty.enabled=true
Cloud-Specific Networking
AWS VPC Configuration
1# AWS VPC with private subnets and NAT2resource "aws_vpc" "atlas" {3 cidr_block = "10.0.0.0/16"4 enable_dns_hostnames = true5 enable_dns_support = true6}78resource "aws_subnet" "private" {9 count = 310 vpc_id = aws_vpc.atlas.id11 cidr_block = "10.0.${count.index + 1}.0/24"12 availability_zone = data.aws_availability_zones.available.names[count.index]13}1415resource "aws_security_group" "atlas" {16 vpc_id = aws_vpc.atlas.id1718 ingress {19 from_port = 44320 to_port = 44321 protocol = "tcp"22 cidr_blocks = ["10.0.0.0/16"]23 }2425 egress {26 from_port = 027 to_port = 028 protocol = "-1"29 cidr_blocks = ["0.0.0.0/0"]30 }31}
Azure Virtual Network Configuration
1# Azure Virtual Network with private endpoints2resource "azurerm_virtual_network" "atlas" {3 address_space = ["10.0.0.0/16"]4}56resource "azurerm_subnet" "private" {7 address_prefixes = ["10.0.1.0/24"]8 enforce_private_link_endpoint_network_policies = true9}1011resource "azurerm_private_endpoint" "atlas" {12 name = "atlas-endpoint"13 private_dns_zone_id = azurerm_private_dns_zone.atlas.id1415 private_service_connection {16 name = "atlas-connection"17 is_manual_connection = false18 subresource_names = ["Atlas"]19 }20}
GCP VPC with Cloud NAT
1# GCP VPC without public IPs2resource "google_compute_network" "atlas" {3 auto_create_subnetworks = false4}56resource "google_compute_subnetwork" "private" {7 ip_cidr_range = "10.0.1.0/24"8 private_ip_google_access = true9}1011resource "google_compute_router" "nat" {12 name = "atlas-nat"13}1415resource "google_compute_router_nat" "nat" {16 name = "atlas-nat-config"17 nat_ip_allocate_option = "AUTO_ONLY"18 source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"19}
Network Isolation
Deploy Atlas in private subnets with no public IP addresses. Configure VPC endpoints or Private Link for secure access.
Encryption at Rest
Enable customer-managed encryption keys for all data storage. Models and user data are encrypted using your keys.
1security:2 encryption:3 enabled: true4 key_management: customer5 kms_key_arn: "arn:aws:kms:region:account:key/key-id"6 data_sovereignty:7 region_lock: true8 export_controls: enabled
Access Control
Implement least-privilege access using IAM roles, Azure RBAC, or GCP IAM. Enable activity journaling for all operations.
Compliance Monitoring
Continuous monitoring for sovereignty requirements with automated reporting and alerting for routing violations.
Monitoring and Management
Private cloud deployments include comprehensive monitoring and management capabilities.
Integrated Monitoring
Troubleshooting
Pod Cannot Reach External Resources
Container fails to pull images or access external APIs
Solution: Verify NAT gateway/Cloud NAT is properly configured. Check route tables include egress rules. Confirm security groups allow outbound traffic on port 443.
KMS Key Access Denied
Pods fail to decrypt data with permission errors
Solution: Verify IAM role/service account has KMS decrypt permissions. Check key policy includes the service account. Confirm key is in the same region as resources.
High Egress Costs
Unexpectedly high data transfer charges
Solution: Use VPC endpoints/Private Link to avoid internet gateway NAT charges. Implement artifact caching close to compute nodes. Monitor egress with CloudWatch/Azure Monitor.
Network Policy Blocking Traffic
Services cannot communicate even within VPC
Solution: Check Kubernetes network policies allow required traffic. Verify security group rules permit inter-pod communication. Review service mesh policies if using Istio/Linkerd.
Advanced Cost Optimization
Reserved Instances Strategy
1# Calculate optimal reserved instance commitment2import boto334ec2 = boto3.client('ec2')56# Analyze on-demand usage patterns7on_demand = ec2.describe_instances(Filters=[8 {'Name': 'instance-state-name', 'Values': ['running']}9])1011# Build RI recommendation based on:12# - Consistent high-performance nodes (3-year RI)13# - Variable inference nodes (1-year RI or on-demand)14# - Burst capacity (spot instances)1516# Expected savings: 70% for 3-year commitment17annual_compute_cost = 120000 # estimated18ri_annual_cost = annual_compute_cost * 0.319spot_savings = 40000 # 50% more for burstable capacity2021print(f"Reserved: ${ri_annual_cost:,.0f}")22print(f"Spot savings: ${spot_savings:,.0f}")23print(f"Total annual: ${ri_annual_cost + spot_savings:,.0f}")
Data Transfer Optimization
Key strategies to reduce egress charges (often 50-70% of total compute cost):
- • VPC Endpoints: AWS - $7.20/month per endpoint, saves ~$0.02/GB egress
- • Caching: CloudFront ($0.085/GB) vs NAT ($0.45/GB) = 5x cheaper
- • Model Distribution: S3 → Local storage reduces repeated transfer costs
- • Example: 100GB daily inference = $1,350/month → $300/month with optimization
Right-Sizing Nodes
1# Monitor actual resource utilization2kubectl top nodes --containers34# Check pod CPU/memory usage5kubectl top pods -A --sort-by=memory67# Right-size recommendations:8# GPU Utilization < 30% → Reduce instance type9# Memory Utilization < 40% → Reduce memory allocation10# CPU Bursting frequent → Use larger instances (better $/performance)1112# Example AWS Graviton instances:13# - 60% cheaper than x8614# - Excellent for Arabic NLP workloads15# - Reduced egress with local ML acceleration