Learn WebSocket - Cloud Deployment (AWS, GCP, Azure)

#Introduction

Running WebSocket in the cloud is more than renting a server: you must choose a service, configure the load balancer so long connections do not break, and ensure scaling works. Each provider has its own solution, including managed services that remove the infrastructure burden.

Episode 29 covers cloud deployment on AWS, GCP, and Azure: container options, WebSocket-specific load balancing configuration, and managed WebSocket services that can cut operational costs.

#AWS

#ECS and Fargate

Amazon ECS with Fargate runs containers without managing servers.

aws ecs create-service \
  --cluster ws-cluster \
  --service-name ws-service \
  --task-definition ws-task \
  --desired-count 2 \
  --load-balancers targetGroupArn=arn:aws:elasticloadbalancing:ap-southeast-1:123456789012:targetgroup/ws-tg/abc

--desired-count 2 keeps two tasks running. The target group is attached to an Application Load Balancer (ALB) that understands WebSocket and supports target-based sticky sessions.

#ALB for WebSocket

The ALB natively supports WebSocket connections: it reads the Upgrade header and maintains long-lived connections. The key configuration: a target group with the HTTP/HTTPS protocol, a keep-alive timeout above the connection duration, and cookie-based session stickiness.

#EKS and CloudFront

For full control, EKS (managed Kubernetes) brings everything learned in episode 28. CloudFront can serve static assets, while WebSocket is served directly from the ALB — CloudFront is not designed to forward very long WebSocket connections.

#GCP

#Cloud Run

Cloud Run runs stateless containers with auto-scaling down to zero.

steps:
  - name: gcr.io/cloud-builders/docker
    args: ["build", "-t", "gcr.io/$PROJECT_ID/ws-server", "."]
  - name: gcr.io/cloud-builders/gcloud
    args:
      - run
      - deploy
      - ws-server
      - --image=gcr.io/$PROJECT_ID/ws-server
      - --region=asia-southeast1
      - --cpu=1
      - --memory=512Mi

Cloud Build builds the image, then gcloud run deploy launches it. Cloud Run can scale to zero, but active WebSocket connections prevent scaling below the number of connections — cost follows the connections actually in use.

#Cloud Load Balancing

Google Cloud Load Balancing supports WebSocket and can be configured with the same backend as a Kubernetes Ingress. GKE (managed Kubernetes) is the choice for teams already using Kubernetes.

#Azure

#App Service and AKS

Azure App Service supports WebSocket via the WebSockets setting. AKS (Kubernetes) is the more powerful path for large scale.

#Azure SignalR Service

Azure SignalR is a managed WebSocket service that handles connections and scaling automatically.

SignalR server in Node.js

const { Server } = require("@microsoft/signalr");
 
const server = new Server({
  transport: 1,
  url: "https://ws-app.service.signalr.net",
  hubName: "chat",
});

url points to the Azure-managed SignalR service. Connections are held by this service, not the application server — the app only processes events. For teams that want to focus on business logic without managing load balancers and sticky sessions, managed services like this save a lot of time.

#Managed Services

#Comparison

Beyond Azure SignalR, there are other managed WebSocket services:

AWS API Gateway  : WebSocket API terkelola, bayar per koneksi dan pesan
Azure SignalR    : integrasi erat ekosistem .NET dan Node.js
Pusher Channels  : pub-sub real-time sebagai service
Ably             : WebSocket dan pub-sub dengan jaminan SLA

Managed services remove the infrastructure burden: no load balancer, no sticky sessions, no scaling. The consequences: more limited control, per-message costs can run high for large volumes, and vendor lock-in needs consideration.

#AWS API Gateway WebSocket API

API Gateway provides a WebSocket endpoint with a route-based integration model:

aws apigatewayv2 create-route \
  --api-id <id> \
  --route-key '$connect'

The $connect route fires when a client does the handshake, $disconnect when the connection closes, and $default for general messages. Sending messages back to the client uses the connection management API, not a direct connection to the application server.

#Choosing a Provider

Choose based on need:

• Small team focused on the product: managed services (API Gateway, SignalR).
• Already using Kubernetes: EKS, GKE, or AKS per provider.
• Full control and measurable budget: containers on ECS, Cloud Run, or App Service.
• High per-message costs: consider self-managed with the Redis adapter.

#Closing

Episode 29 mapped the cloud landscape: containers on three major providers, load balancers that understand WebSocket, and managed services that remove the infrastructure burden. There is no single answer — the choice depends on the team and the cost.

Key takeaways:

• ECS Fargate, Cloud Run, and App Service run containers in the cloud.
• ALB and Cloud Load Balancing support long-lived WebSocket connections.
• Managed Kubernetes (EKS, GKE, AKS) brings episode 28 to the cloud.
• Managed services remove the infrastructure burden at a certain price.
• AWS API Gateway uses routes like $connect and $disconnect.
• Choose a service based on team, control, and cost patterns.

In the next episode we cover CI/CD pipeline: continuous integration and deployment, GitHub Actions, and the blue-green and canary strategies.