Cloud services

This page details the specific cloud services Evolve uses on each provider. The cloud deployment overview covers the general architecture; this page helps teams understand what gets provisioned when you deploy to a specific cloud.

AWS

AWS is the most mature deployment target, with the broadest set of service integrations.

graph TD;
    internet["Internet"]
    cf["CloudFront<br/>(CDN)"]
    alb_pub["Public ALB"]
    alb_int["Internal ALB"]
    frontend["Frontend<br/>(ECS Fargate)"]
    gateway["GraphQL Gateway<br/>(ECS Fargate)"]
    services["Domain services<br/>(ECS Fargate)"]
    lambda["Payment webhooks<br/>(Lambda)"]
    redis["ElastiCache<br/>(Redis)"]
    s3["S3<br/>(static assets)"]

    internet --> cf
    cf --> alb_pub
    cf --> s3
    alb_pub --> frontend
    alb_pub --> gateway
    gateway --> alb_int
    alb_int --> services
    alb_int --> lambda
    services --> redis

Compute

• ECS Fargate: runs all containerized services (frontend, gateway, domain services). Fargate removes the need to manage EC2 instances; you define CPU and memory per task.
• Lambda: used for specific workloads like payment webhook handlers and API extensions, where event-driven invocation is a better fit than a long-running container.

Networking

• Public ALB: routes external traffic to the frontend and GraphQL gateway. Sits behind CloudFront.
• Internal ALB: routes east-west traffic between the gateway and domain services. Not exposed to the internet, keeping service-to- service communication private.
• API Gateway: can be used alongside ALB for Lambda-based services that need HTTP API management.
• Route53: DNS management for all domains.

Storage and caching

• S3: stores static frontend assets (JS, CSS, images) served through CloudFront.
• ElastiCache (Redis): provides caching for domain services (product data, CMS content, session data).

CDN

• CloudFront: sits in front of the entire application. Routes static asset requests to S3 and dynamic requests to the ALB. Supports HTTP/2 and HTTP/3. Origin access control ensures S3 is only accessible through CloudFront.

Security and configuration

• IAM: roles and policies for ECS tasks, Lambda functions, and CI/CD access.
• KMS: encryption key management for secrets and sensitive data.
• SSM Parameter Store: stores configuration values and secrets referenced by ECS task definitions.
• ECR: container image registry.

GCP

GCP uses Cloud Run as its primary compute service, offering automatic scaling (including scale-to-zero) without managing infrastructure.

graph TD;
    internet["Internet"]
    lb["Cloud Load Balancing<br/>(Cloud CDN)"]
    frontend["Frontend<br/>(Cloud Run)"]
    gateway["GraphQL Gateway<br/>(Cloud Run)"]
    services["Domain services<br/>(Cloud Run)"]

    internet --> lb
    lb --> frontend
    lb --> gateway
    gateway --> services

Compute

• Cloud Run: runs all containerized services. Supports automatic scaling based on request volume, including scaling to zero when idle. CPU is allocated only during request processing by default, keeping costs low for lower-traffic services.

Networking

• Cloud Load Balancing: L7 load balancer with Cloud CDN enabled. Uses serverless Network Endpoint Groups (NEGs) to route to Cloud Run services.
• VPC: services run within a VPC for network isolation. Cloud Run services connect through VPC connectors for private communication.
• Cloud DNS: DNS management.

CDN

• Cloud CDN: integrated with Cloud Load Balancing. Uses origin headers for cache control. Managed SSL certificates handle HTTPS.

Security and configuration

• Workload Identity: GCP’s preferred authentication method. CI/CD pipelines and Cloud Run services use workload identity instead of service account keys.
• Artifact Registry (GAR): container image registry.
• Secret Manager: stores sensitive configuration values.

Azure

Azure uses Container Apps, which provides a managed container hosting environment with built-in scaling and networking.

graph TD;
    internet["Internet"]
    fd["Front Door<br/>(CDN + DDoS)"]
    frontend["Frontend<br/>(Container Apps)"]
    gateway["GraphQL Gateway<br/>(Container Apps)"]
    services["Domain services<br/>(Container Apps)"]

    internet --> fd
    fd --> frontend
    fd --> gateway
    gateway --> services

Compute

• Container Apps: runs all containerized services within a Container App Environment. Supports configurable min/max replicas and resource allocation (CPU, memory) per service.

Networking

• Container App Environment: provides network isolation for all services in a deployment. Services within the same environment can communicate internally.
• Front Door: global CDN and DDoS protection layer that routes external traffic to Container Apps.

CDN

• Front Door: combines CDN, DDoS protection, and global load balancing in a single service. Routes traffic to the nearest regional deployment.

Security and configuration

• Managed Identities: user-assigned identities for workload authentication. Avoids storing credentials in configuration.
• Role Assignments: Azure RBAC controls access to resources.
• Azure Container Registry (ACR): container image registry.

Service comparison

Concern	AWS	GCP	Azure
Containers	ECS Fargate	Cloud Run	Container Apps
Serverless functions	Lambda	Cloud Functions	(not used)
Load balancing	ALB (public + internal)	Cloud Load Balancing	Front Door
CDN	CloudFront	Cloud CDN	Front Door
Container registry	ECR	GAR	ACR
Caching	ElastiCache (Redis)	Memorystore	Azure Cache for Redis
DNS	Route53	Cloud DNS	Azure DNS
Secrets	SSM + KMS	Secret Manager	Key Vault
CI/CD auth	OIDC role assumption	Workload Identity	OIDC service principal
Static assets	S3	Cloud Storage	Blob Storage

Networking patterns

Regardless of cloud provider, Evolve follows the same networking principles:

• External traffic (user requests) enters through the CDN and reaches the frontend and GraphQL gateway through a public load balancer or ingress.
• Internal traffic (gateway to domain services) stays within the private network. Services communicate over internal endpoints that are not exposed to the internet.
• Outbound traffic to SAAS backends (commercetools, CMS, payment providers) goes directly from domain services over HTTPS. No special egress configuration is needed beyond standard internet access.

This separation ensures that domain services are never directly reachable from the internet, reducing the attack surface of the platform.