SocketX on AWS

Introduction

SocketX Server is an end-to-end encryption system that protects all WebSocket traffic with next-generation application data security. It acts as a proxy server in front of your backend WebSocket infrastructure, communicating with a SocketX Client to encode and decode all WebSocket frames. The server is highly customizable and supports integration with other services through custom adapters.

Below is an example architecture where a client application communicates with a SocketX Server, which then proxies decoded WebSocket traffic to backend services:

Socket X Diagram

Prerequisites

Technical Requirements

A web or mobile application project that communicates with a backend service over WebSockets.

Skills and Knowledge

Familiarity with ECS and/or EKS.
Experience with the AWS CLI.

Deployment Options

SocketX Server is provided as a Docker image and can be deployed on AWS ECS, AWS EKS, or manually using another container runtime.

1. Elastic Container Service (ECS)

Requirements

Git
AWS CLI
AWS permissions to launch resources

Deployment Steps

Clone the GitHub repository:
AWS CloudFormation Templates
Modify the parameters.json file with your configuration.
From the template directory, run the deploy.sh create command to deploy, or the delete command to remove resources.

Configuration

Modify the parameters.json file to configure your deployment:

Required parameters:

VpcId - Your AWS VPC ID.
Subnets - Comma-separated list of subnet IDs. Requires at least two.
DomainMap - A JSON object mapping domain names to their corresponding proxy targets. Wildcards are supported!

Optional parameters include:

LogLevel - Logging level. Values are debug, info, warn, error, fatal,panic, off. Default is info.

paramters.json
[
  {
    "ParameterKey": "VpcId",
    "ParameterValue": ""
  },
  {
    "ParameterKey": "SubnetIds",
    "ParameterValue": ""
  },
  {
    "ParameterKey": "DomainMap",
    "ParameterValue": "{\"*\":\"ws://example.com\"}"
  },
  {
    "ParameterKey": "LogLevel",
    "ParameterValue": "warning"
  }
]

2. Docker Image

You can also run the image using Docker, Podman, K3s, or Docker Swarm.

Commands

bash
PowerShell

aws ecr get-login-password \
--region us-east-1 \
| docker login --username AWS \
--password-stdin 709825985650.dkr.ecr.us-east-1.amazonaws.com

docker pull 709825985650.dkr.ecr.us-east-1.amazonaws.com/eclypses/socketx-server:1.0.0

aws ecr get-login-password `
--region us-east-1 `
| docker login --username AWS `
--password-stdin 709825985650.dkr.ecr.us-east-1.amazonaws.com

docker pull 709825985650.dkr.ecr.us-east-1.amazonaws.com/eclypses/socketx-server:1.0.0

Refer to the Server Configuration section for required environment variables.

Server Configuration

SocketX Server is configured using environment variables.

Required Variables

DOMAIN_MAP - JSON string mapping domains. Wildcards are supported.

Optional Variables

LISTEN_HOST - Default: 0.0.0.0.
LISTEN_PORT - Default: 8080.
LOG_LEVEL - One of debug, info, warn, error, panic, off. Default: info.
WS_READ_BUFFER_SIZE - Websocket read buffer size in bytes. Default: 1024.
WS_WRITE_BUFFER_SIZE - Websocket write buffer size in bytes. Default: 1024.

Minimal Example

DOMAIN_MAP={"*":"ws://example.com"}

Full Example

DOMAIN_MAP={"*":"ws://example.com"}
LISTEN_HOST=0.0.0.0
LISTEN_PORT=8080
LOG_LEVEL=info
WS_READ_BUFFER_SIZE=2048
WS_WRITE_BUFFER_SIZE=2048

Client-Side Setup

Eclypses provides client-side SDKs to integrate with SocketX Server:

JavaScript Package

Testing & Health Checks

Monitor container logs for startup messages
Use the default or custom echo routes to test container responsiveness:
- Default: /api/socketx-echo
- Custom Message: /api/socketx-echo?msg=test

Expected response:

{
  "message": "test",
  "timestamp": "<timestamp>"
}

Troubleshooting

Invalid Configuration
- Check logs for missing/invalid environment variables.
SocketX unreachable
- Verify Security Groups and load balancer settings.
Redis connection issues
- Ensure Redis is in the same VPC and credentials are correct.

Enable debug logs by setting the environment variable LOG_LEVEL=debug.

Security

No sensitive data is stored in the container.
No root privileges required.

Compliance Coverage Summary

Purpose:

Demonstrate that SocketX server logs serve as verifiable, cryptographically-anchored compliance evidence across data-layer security, auditability, and AI-governance frameworks.

Governance Domains and Control Alignment

Confidentiality - cryptographic enforcement and keyless privacy Fields: event_type, payload_sha256, eeid, mte_kyber_strength Coverage: NIST SC-13 · FedRAMP SC-13 · SOC 2 CC6.1 · EU AI Act Art 10(3)

Integrity - proof of data fidelity and replay prevention Fields: payload_sha256, cid, duration_ms Coverage: NIST SI-7 · FedRAMP SI-7 · SOC 2 CC7.4 · EU AI Act Art 15(2-3)

Availability - continuous, timestamped operational visibility Fields: time, audit.duration_seconds, close_reason Coverage: NIST AU-12 · FedRAMP AU-12 · SOC 2 CC7.2

Accountability & Traceability - correlation, provenance, and actor identification Fields: cid, user_agent, audit Coverage: NIST AU-10 · FedRAMP AU-6(3) · SOC 2 CC7.2 · EU AI Act Art 13

AI Governance & Transparency - mandatory operational logging for AI workloads Fields: event_type=encryption/decryption, config (version & Kyber params) Coverage: EU AI Act Art 10 · 13 · 15

Framework Coverage Summary

Framework	Primary Control Families Satisfied	Estimated Coverage
NIST 800-53 r5	AU-2, AU-3, AU-6, AU-10, SI-4, SI-7, SC-13	≈ 85 %
FedRAMP (Moderate / High)	AU, SI, SC, CM families + FIPS 140-3 crypto enforcement	≈ 80 %
SOC 2 Type II	CC6.1, CC6.2, CC7.2, CC7.3, CC7.4	≈ 90 %
EU AI Act (2024)	Art 10 (Data Governance), Art 13 (Transparency), Art 15 (Traceability)	100 %

Structural Compliance

Element	Present in Log	Compliance Purpose
Timestamp (`time`)	True	Required for tamper-proof chronology (NIST 800-92 §4.1)
Severity (`level`)	True	Mandatory classification for audit triage
Event Type (`event_type`)	True	Enables control-family mapping (SI-4, AU-2, AU-3)
Correlation ID (`cid`)	True	Provides end-to-end traceability per transaction (SOC 2 CC7.2)
Payload Integrity Hash (`payload_sha256`)	True	Cryptographic proof of data fidelity (NIST 800-53 SI-7, EU AI Act Art. 10 §3 fidelity)
Cryptographic Metrics (`duration_ms`, `payload_size_bytes`)	True	Enables deterministic crypto performance verification
Configuration Snapshot (`config` block)	True	Required system-baseline record (FedRAMP AC-17, CM-6)
User/Agent Info (`user_agent`)	True	Maps to identity and access logging (AU-6, EU AI Act Art. 13 transparency)
Session Audit Block (`audit`)	True	Provides closure evidence (ISO 27001 A.12.4.1 audit trail completeness)

Cryptographic Enforcement Layer (CEL) Alignment

Each MTE encryption/decryption event includes:

One-time payload encoding (eeid = event entropy ID)
SHA-256 verification token
Runtime duration (in ms)

Together these create verifiable, immutable evidence of cryptographic enforcement for every data transaction - fulfilling CEL audit-trace requirements for:

Data Fidelity (tamper-proof chain of custody)
Replay Prevention (unique eeid + transient cid)
Quantum-resistant handshake traceability (Kyber 512 param in config)

Standards Mapping

Framework / Standard	Relevant Clauses Satisfied by Log
NIST 800-92 / 800-53 rev5	AU-2, AU-3, AU-6, SI-4 (logging completeness & incident correlation)
FedRAMP Moderate / High	AU-2(a-d), AU-6(1), SI-7(1-3), SC-13 (cryptographic logging, FIPS 140-3 context)
SOC 2 Type II	CC6.1 (Change mgmt), CC7.2 (Monitoring), CC7.3 (Incident detection)
ISO 27001:2022	A.12.4.1 (Event logging), A.8.16 (Cryptographic controls)
EU AI Act (draft 2024 voted)	Art. 10 (Data governance), Art. 13 (Transparency & traceability), Art. 15 (Logging of operations)

Key Compliance Advantages

Cryptographic Enforcement Layer (CEL): every payload's encrypt/decrypt event is FIPS-140-3 validated and recorded with runtime metrics.
Deterministic Evidence: duration_ms + payload_size_bytes provide measurable cryptographic performance proofs.
Tamper-Evident Logging: SHA-256 hashes + unique entropy IDs (eeid) guarantee payload fidelity.
AI-Governance Ready: fully meets EU AI Act logging mandates for explainability, lineage, and traceability.
Audit Simplified: logs integrate directly into Prometheus, Grafana, or SIEMs with control-family correlation.

SocketX / MTE logging is not mere telemetry - it is cryptographic compliance evidence. Each record proves that data was encrypted, verified, and audited in real time, meeting the governance, traceability, and AI-risk requirements of all major frameworks without exposing any keys or payload content.

Costs

The service uses a usage-based cost per instance per hour.
Associated AWS services include:

AWS Service	Purpose
ECS	Container orchestration
CloudWatch	Logging and monitoring
VPC	Networking isolation
Elastic Load Balancer	Scaling across Relay containers

Maintenance

Routine Updates

Updated container images are distributed through the AWS Marketplace.

Fault Recovery

Relaunch the Relay container task; clients will automatically re-pair.

Service Limits

Supported Regions

SocketX Server is supported in most AWS regions, except:

GovCloud
Middle East (Bahrain, UAE)
China

Support

For assistance, contact Eclypses Support:
📧 customer_support@eclypses.com
🕒 Monday–Friday, 8:00 AM–5:00 PM MST (excluding holidays)

Introduction​

Prerequisites​

Technical Requirements​

Skills and Knowledge​

Deployment Options​

1. Elastic Container Service (ECS)​

Requirements​

Deployment Steps​

Configuration​

2. Docker Image​

Commands​

Server Configuration​

Required Variables​

Optional Variables​

Minimal Example​

Full Example​

Client-Side Setup​

Testing & Health Checks​

Troubleshooting​

Security​

Compliance Coverage Summary​

Governance Domains and Control Alignment​

Framework Coverage Summary​

Structural Compliance​

Cryptographic Enforcement Layer (CEL) Alignment​

Standards Mapping​

Key Compliance Advantages​

Costs​

Maintenance​

Routine Updates​

Fault Recovery​

Service Limits​

Supported Regions​

Support​