Cloud Spectra Gateway -- User Guide v1.0.0

Introduction & how configuration works

Cloud Spectra Gateway runs entirely inside your own AWS account. It is a software networking and AI appliance that replaces metered Amazon VPC networking services and metered LLM-API spend with a fixed EC2 cost -- Your Cloud, Off the Meter. There is no vendor control plane: traffic, configuration and logs stay in your account at all times.

This page is the full v1 configuration reference. Cloud Spectra ships three tiers on one cumulative ladder -- Platform -> Network -> Security -- each a strict superset of the one below it. Platform carries the compute and Kubernetes worker stack (CPU and GPU, which have no runtime settings of their own -- see Architecture and the FAQ) and runs a single stateful application elastically:

Beyond the cumulative network stack, Cloud Spectra ships one more tier on a different axis. It is not part of the superset chain above -- it does a different job, and is documented in its own section, ElasticApps tier, at the end of this guide.

Three ways to configure -- one source of truth

Every feature on this page is set the same way regardless of which interface you use. The dashboard, the Terraform provider, and the configuration API all write into the same place: AWS SSM Parameter Store, in your account. The gateway instances poll that configuration and reconcile the running data plane toward it.

flowchart LR
    DASH["Dashboard
(HTTPS 443)"]
    API["Config API
(REST 8080)"]
    TF["Terraform provider
cloudspectra/cloudspectra"]
    SSM["AWS SSM
Parameter Store
(your account)"]
    DP["Gateway data plane
(per-AZ ASG instances)"]
    DASH --> SSM
    API --> SSM
    TF --> API
    SSM -->|"poll & reconcile"| DP

Network Gateway tier Network

The Network Gateway tier is the base appliance. It delivers ten data-plane features that replace AWS-metered networking services with a fixed EC2 cost. The diagram below shows the common packet paths these features sit on -- outbound NAT, inbound port forwarding, the in-appliance L4 load balancer, and the forward proxy.

flowchart LR
    subgraph VPC["Your VPC"]
      PRIV["Private instances"]
    end
    GW["Cloud Spectra Gateway
(per-AZ ASG behind GWLB)"]
    EIP["Elastic IP
(stable endpoint)"]
    INET["Internet"]
    PRIV -->|"0.0.0.0/0 route"| GW
    GW -->|"sNAT"| EIP --> INET
    INET -->|"dNAT / port fwd"| EIP --> GW --> PRIV
    GW -->|"forward proxy (Squid)"| INET
    GW -->|"IPVS L4 load balance"| PRIV

Source NAT (sNAT)

What it does. Provides outbound internet access for instances in private subnets. The gateway source-translates private traffic to its Elastic IP so private instances can reach the internet without a public IP of their own.

Replaces. The AWS NAT Gateway -- specifically its hourly charge and its per-GB data-processing meter. With Cloud Spectra, outbound egress carries no per-GB networking fee beyond standard EC2 data-transfer.

Configure. In the dashboard, open the Features dialog and set Network Address Translation (NAT) to enable. Then point each private subnet's route table at the gateway ENI for that Availability Zone (default route 0.0.0.0/0). The same setting is available through the Terraform provider (cloudspectra_nat_gateway) and the configuration API (PUT /api/cloudspectra/nat-gateway).

Verify. From a private instance routed through the gateway:

curl -s https://checkip.amazonaws.com
# Returns the gateway's Elastic IP -- confirms egress is source-NATed.

Destination NAT / port forwarding (dNAT)

What it does. Forwards inbound TCP connections that arrive at the gateway's public endpoint to a private target inside the VPC. Use it to expose a service running on a private instance without giving that instance a public address.

Replaces / uses. A common pattern that would otherwise require a public-facing load balancer or a bastion. dNAT pairs naturally with the gateway's Elastic IP as the stable inbound endpoint.

Configure. In the dashboard, open Port Forwarding and add a rule mapping a listen port on the gateway to a private destination IP and port. The same setting is available through the Terraform provider and the configuration API.

Verify. From outside the VPC, connect to the gateway's Elastic IP on the listen port and confirm you reach the private service:

curl -s http://<GATEWAY_EIP>:<listen_port>/
# Reaches the forwarded private target.

Network Load Balancer (IPVS L4)

What it does. Provides Layer-4 load balancing inside the appliance using the Linux IPVS engine. The gateway distributes incoming TCP/UDP flows across a set of backend targets, and keeps the IPVS target set in sync with an AWS Network Load Balancer target group so you manage targets the AWS-native way.

Replaces. The metered per-LCU/NLCU cost of an AWS Network Load Balancer for L4 traffic, while still using the AWS NLB target set as the source of truth for membership.

Configure. Enable the IPVS L4 balancer and select the AWS NLB target set to mirror through the Terraform provider (cloudspectra_nlb_gateway) or the configuration API.

flowchart LR
    CL["Client"] --> GW["Gateway
IPVS L4 virtual service"]
    AWSNLB["AWS NLB target group
(source of truth)"] -. "sync targets" .-> GW
    GW --> T1["Target 1"]
    GW --> T2["Target 2"]
    GW --> T3["Target 3"]

Verify. Send repeated L4 connections to the virtual service and confirm they spread across the backend targets (for example, by checking which target served each request in your application logs), and confirm the IPVS target list matches the AWS NLB target group membership.

TLS termination (ACM)

What it does. Terminates HTTPS at the gateway using HAProxy, presenting a certificate issued by AWS Certificate Manager (ACM). Inbound TLS on port 443 is decrypted at the appliance; plaintext on port 80 is redirected to HTTPS.

Uses. An ACM certificate from your account. The same HAProxy listener also fronts the management dashboard on 443.

Configure. The certificate to present is set on the NLB gateway section, through the Terraform provider (cloudspectra_nlb_gateway, ssl_certificate_id) or the configuration API.

Verify. Inspect the served certificate and confirm the redirect:

# Confirm the ACM certificate is presented on 443
openssl s_client -connect <GATEWAY_EIP>:443 -servername your.domain </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject

# Confirm HTTP redirects to HTTPS
curl -sI http://<GATEWAY_EIP>/  # 301/302 to https://

Per-AZ Auto Scaling

What it does. Runs one Auto Scaling Group per Availability Zone. Each AZ's instances egress through that AZ's own ENI, so traffic stays within its zone. This is the design that keeps a gateway healthy in every AZ while avoiding cross-AZ data-transfer charges.

Replaces / uses. Uses EC2 Auto Scaling. The per-AZ split avoids the cross-AZ data-transfer cost a single shared appliance would incur when instances in one AZ NAT through an ENI in another.

Configure. Availability Zones are chosen at deployment (the CloudFormation template or the Terraform module). For each enabled AZ the stack creates a dedicated subnet, ENI, route table, and Auto Scaling Group. Point each AZ's private subnets at that AZ's gateway ENI. The same routing is settable through the Terraform provider and the configuration API.

flowchart TD
    subgraph AZa["AZ a"]
      ASGa["ASG a"] --> ENIa["ENI a"]
    end
    subgraph AZb["AZ b"]
      ASGb["ASG b"] --> ENIb["ENI b"]
    end
    subgraph AZc["AZ c"]
      ASGc["ASG c"] --> ENIc["ENI c"]
    end
    PA["Private subnets in AZ a"] --> ENIa
    PB["Private subnets in AZ b"] --> ENIb
    PC["Private subnets in AZ c"] --> ENIc

Verify. Confirm that each enabled AZ has a running gateway instance and its own ENI, and that each private subnet's route table targets the ENI in its own AZ.

Vertical & horizontal scaling (GWLB)

What it does. Scales the gateway two ways. Vertically, you can change the EC2 instance size. Horizontally, the fleet scales out behind a Gateway Load Balancer (GWLB) using GENEVE encapsulation, so multiple instances share the data-plane load. GWLB connection draining lets active flows finish before an instance is removed.

Replaces / uses. Uses a Gateway Load Balancer for horizontal scale-out and a range of EC2 instance types for vertical sizing. This removes the single-box ceiling (one NIC, fixed cores) of a fixed virtual appliance.

Configure. In the dashboard, open Autoscale Config from the header menu: the instance-type ladder (vertical) is on the Single-Instance tab, and the min / desired / max instance counts per AZ (horizontal) are on the Multi-Instance tab. The same settings are available through the Terraform provider and the configuration API.

flowchart LR
    SRC["Traffic"] --> GWLB["Gateway Load Balancer
(GENEVE)"]
    GWLB --> I1["Gateway instance 1"]
    GWLB --> I2["Gateway instance 2"]
    GWLB --> I3["Gateway instance N"]

Verify. Increase the desired count and confirm new instances register healthy behind the GWLB target group and begin taking traffic; reduce the count and confirm draining lets active flows complete before an instance is removed.

Forward HTTP proxy + caching (Squid)

What it does. Runs an outbound forward proxy based on Squid. It supports proxy authentication, HTTP response caching, domain filtering, and per-client bandwidth limits -- giving you a single controlled egress point for HTTP/HTTPS traffic.

Replaces / uses. A standalone forward-proxy deployment. Caching reduces repeated outbound fetches (and therefore egress), and the filtering/bandwidth controls give you policy at the egress edge.

Configure. In the dashboard, open Web Proxy, enable the proxy on a configurable port, and set authentication, caching, domain rules, and bandwidth limits. The same settings are available through the Terraform provider (cloudspectra_web_proxy_gateway) and the configuration API.

Verify. Configure a client to use the proxy and confirm egress flows through it:

export https_proxy=http://proxyuser:PASSWORD@<GATEWAY_IP>:<proxy_port>
curl -s https://checkip.amazonaws.com   # Returns the gateway EIP
# Repeat a cacheable request and confirm a cache HIT in the proxy access log.

Sticky Secondary ENI

What it does. Gives each Auto Scaling slot a pre-provisioned secondary Elastic Network Interface with a fixed private IP address. The ENI belongs to the slot, not to the instance: when the instance behind that slot is replaced -- by a resize, a Spot reclaim, or a health-check failure -- the replacement attaches the same ENI and comes back on the same private IP, with the same security group and the same source/destination-check setting.

Replaces / uses. Uses EC2 network interfaces directly. It removes the usual churn of a self-managed appliance fleet, where every instance replacement hands out a new private IP and forces you to re-point routes, security-group references, and allow-lists at the new address.

Configure. Enable it through the Terraform provider (cloudspectra_sticky_eni) or the configuration API. It is off by default -- enable it explicitly when you want slot-stable private addressing.

Verify. Note a slot's secondary ENI and its private IP, then terminate the instance in that slot. Confirm the replacement instance attaches the same ENI and comes back on the same private IP.

Per-Slot Route Table

What it does. Creates one dedicated route table per slot, with a default route (0.0.0.0/0) pointing at that slot's ENI. You associate your private subnets with the slot's route table once; because the route targets the slot's sticky ENI rather than a particular instance, it keeps working across every instance replacement without being rewritten.

Replaces / uses. Uses VPC route tables. It pairs with Sticky Secondary ENI: the sticky ENI is what makes a route table target stable enough to wire up once and leave alone.

Configure. The per-slot route tables are created with the slot's ENI. Associate each private subnet with the route table for the slot in its own Availability Zone -- a one-time association. The same wiring is settable through the Terraform provider and the configuration API.

Verify. Confirm each slot has its own route table whose default route targets that slot's ENI, and that your private subnets are associated with the route table for their own AZ. Replace an instance and confirm the route table is unchanged and egress never breaks.

Security Gateway tier Security

The Security Gateway tier includes everything in the Network tier and adds ten inline inspection and enforcement features. Together they let you inspect, allow, and deny traffic at the data plane. The diagram below shows where the core enforcement points sit in the packet path.

flowchart LR
    IN["Inbound / outbound packet"] --> NFT["nftables
stateless allow/deny"]
    NFT -.->|"denied"| DROP1["Drop"]
    NFT -->|"allowed"| BUMP["TLS inspection (ssl-bump)
decrypt on the proxy path"]
    BUMP --> NFQ["NFQUEUE -> Suricata
IDS/IPS inline
(ET Open + community feeds)"]
    NFQ -.->|"alert / block"| DROP2["Drop / log"]
    NFQ -->|"pass"| APPID["App-ID (nDPI)
app-aware egress control"]
    APPID -.->|"blocked app"| DROP4["Drop"]
    APPID --> DOM["Domain / URL filter
+ URL categories
(firewall + Squid paths)"]
    DOM -.->|"blocked domain / category"| DROP3["Drop"]
    DOM -->|"allowed"| AV["ICAP RESPMOD -> ClamAV
antivirus scan (proxy path)"]
    AV -.->|"infected"| DROP5["Block download"]
    AV -->|"clean"| FWD["Forward / NAT"]
    NFQ -.->|"events"| SIEM["SIEM export
(OCSF / CEF / syslog)"]
    DOM -.->|"events"| SIEM

Suricata IDS/IPS (inline)

What it does. Runs Suricata as an inline intrusion detection and prevention system. Packets are handed to Suricata via the Linux NFQUEUE mechanism, so Suricata can inspect them and enforce a deny or allow verdict at the data plane (not just alert).

Replaces / uses. An inline IDS/IPS layer, enforced in your account on the gateway instances. No separate inspection endpoints are required.

Configure. Enable the firewall gateway and list the AWS Network Firewall policy names to sync Suricata rules from, through the Terraform provider (cloudspectra_firewall_gateway: enable, firewall_policies) or the configuration API. Suricata's inline status is shown in the dashboard's Firewall panel.

Verify. Generate a benign test signature match from a routed instance and confirm it appears in the Suricata events/threat view in the dashboard, and that the matching traffic is dropped at the data plane.

nftables firewall rules

What it does. Enforces stateless allow/deny rules in the Linux kernel with nftables. Rules match on source and destination CIDR, port, and protocol, and are applied at the data plane on every gateway instance.

Replaces / uses. A kernel-level packet filter on the gateway. It complements the inline Suricata layer: nftables makes fast stateless allow/deny decisions; Suricata performs deep inline inspection on the traffic nftables permits.

Configure. The nftables rules are not authored on the gateway: they are synced from the AWS Network Firewall policies you name in firewall_policies (Terraform provider cloudspectra_firewall_gateway, or the configuration API), so you author policy the AWS-native way and the gateway enforces it inline. The dashboard's Firewall panel shows the nftables status and the active rule count.

Verify. Add a deny rule for a known destination/port to one of the synced AWS Network Firewall policies, wait for the next sync, and confirm the connection is blocked from a routed test instance; remove it and confirm the connection succeeds again. The Firewall panel's nftables rule count reflects each sync.

Domain / URL filtering

What it does. Blocks or allows traffic by domain. The policy is enforced on both data paths: the firewall path and the Squid forward-proxy path. This gives you consistent domain policy whether a client routes through NAT or through the proxy.

Replaces / uses. Domain-based egress control. Enforced in-account, on the same gateway instances.

Configure. In the dashboard, open Web Proxy and expand Domain Filtering to choose an allow-list or deny-list model and add domains. The same settings are available through the Terraform provider (cloudspectra_web_proxy_gateway) and the configuration API.

Verify. Add a domain to the deny-list and confirm it is blocked from a routed instance and also blocked when going through the proxy; confirm a non-listed domain still resolves and connects.

URL-category filtering

What it does. Blocks whole categories of destinations -- adult, gambling, malware, anonymizer -- rather than making you enumerate domains one at a time. Categories are backed by the free UT1 blacklists. Matching is done at the domain level, so it needs no TLS decryption: you can filter categories without turning on TLS inspection.

Replaces / uses. The category-filtering half of a commercial secure web gateway, using freely licensed category lists. There is no per-seat category subscription and no lookup call to a vendor -- the lists live on the gateway, in your account.

Configure. Category filtering is part of the web proxy. In the dashboard, open Web Proxy and select the categories to block alongside your explicit domain rules. The same settings are available through the Terraform provider (cloudspectra_web_proxy_gateway) and the configuration API.

Verify. Block a category, then request a known domain in that category from a routed instance and confirm it is denied; confirm an uncategorized domain still connects.

ET Open threat detection

What it does. Enforces the Emerging Threats (ET Open) rule sets on the inline Suricata engine, giving you a broad community signature base for known malware, exploit, and command-and-control traffic. The rule sets are cached in the AMI, so a gateway has working signatures from first boot without reaching out to a rule server.

Replaces / uses. The signature feed of a commercial IPS. ET Open is openly licensed, so there is no per-sensor rule subscription to buy.

Configure. The enable flag and the signature categories are set through the Terraform provider (cloudspectra_firewall_gateway: threat_detection_enabled, threat_detection_categories) or the configuration API. The dashboard's Threat Detection panel shows the resulting status, the active categories, and the loaded rule files.

Verify. Generate a benign ET Open test signature match from a routed instance and confirm the alert appears in the dashboard's Threat Detection panel and that the traffic is dropped at the data plane.

Multi-source community threat feeds

What it does. Adds free, open-source reputation feeds to the inline IPS -- abuse.ch, CINS Army, and the Spamhaus DROP list -- so traffic to known-bad hosts is blocked on reputation, complementing the signature matching of ET Open.

Replaces / uses. The threat-intelligence subscription of a commercial firewall. All the feeds used here carry $0 vendor licensing, and they are evaluated in your account -- no traffic metadata is shipped to a reputation service to make a verdict.

Configure. In the dashboard, open Threat Detection and enable the community threat feeds you want in the Community Threat Feeds section. The same settings are available through the Terraform provider (cloudspectra_firewall_gateway, threat_feeds) and the configuration API.

Verify. Confirm the enabled feeds are loaded by the inline engine and that a connection attempt to an address listed in an active feed is alerted and dropped.

TLS inspection (SSL bump)

What it does. Transparently decrypts TLS on the proxy path using Squid's ssl-bump, so the inline IPS and the proxy can inspect cleartext instead of an opaque tunnel. The gateway presents a certificate signed by an inspection CA and re-encrypts to the origin. By default the CA is self-managed on the gateway; AWS Private CA (ACM PCA) is an opt-in alternative. Either way the keys never leave your account.

Replaces / uses. The TLS-decrypt function of a commercial secure web gateway -- performed in-account, with no vendor holding the interception key material.

Configure. TLS inspection is a firewall setting. In the dashboard, open Firewall and toggle TLS inspection on or off. The CA mode (self-managed or ACM PCA) is set through the Terraform provider (cloudspectra_firewall_gateway: tls_inspection.ca_mode, tls_inspection.acm_private_ca_arn) or the configuration API, and is shown read-only in the panel.

Verify. From a client that trusts the inspection CA, fetch an HTTPS URL through the proxy and confirm the presented certificate chains to your inspection CA, and that the request appears (with its URL path) in the proxy access log rather than as an opaque CONNECT tunnel.

SIEM export (OCSF / CEF / syslog)

What it does. Streams the gateway's IDS, firewall, and audit events to your existing SIEM -- Splunk, Microsoft Sentinel, or IBM QRadar -- in vendor-neutral formats (OCSF, CEF, or syslog). Events leave the gateway only for the SIEM destination you configure; there is no vendor collector in the path.

Replaces / uses. The log-forwarding agent of a commercial security stack. Because the formats are open, you are not locked to one SIEM vendor.

Configure. SIEM export is its own configuration section, separate from the IDS/IPS settings whose events it forwards. Set the destination, format, and event sources through the Terraform provider (cloudspectra_siem) or the configuration API.

Verify. Trigger a firewall deny and an IDS alert, then confirm both arrive at the configured SIEM in the selected format with their event fields populated.

Antivirus scanning (ClamAV ICAP)

What it does. Scans files downloaded through the forward proxy for malware, in your account. Squid hands each response to ClamAV over ICAP (RESPMOD, via c-icap); an infected download is blocked before it reaches the client. Files never leave your account -- there is no upload to a vendor scanning service.

Replaces / uses. The AV/content-scanning function of a secure web gateway, using the open-source ClamAV engine on the gateway instances.

Configure. Enable scanning of proxied downloads on the web proxy through the Terraform provider (the antivirus settings of cloudspectra_web_proxy_gateway) or the configuration API.

Verify. Download the harmless EICAR antivirus test file through the proxy and confirm it is blocked rather than delivered; repeat over HTTPS with TLS inspection enabled and confirm it is blocked there too.

L7 App-ID (nDPI)

What it does. Identifies the application behind a flow -- not just its port or domain -- using a standalone nDPI daemon, and lets you control egress on that identity. Use it to block Tor, BitTorrent, and anonymizers, and to flag suspicious signals such as DGA-generated domains, self-signed certificates, and command-and-control patterns.

Replaces / uses. The App-ID / application-control layer of a commercial next-generation firewall, delivered as a sovereign in-account daemon with no vendor application database call-out.

Configure. Set the application-control policy -- which identified applications to block, and which signals to flag -- through the Terraform provider (the application-control settings of cloudspectra_firewall_gateway) or the configuration API.

Verify. Block an application such as BitTorrent, then generate that traffic from a routed instance and confirm it is identified and denied even when it uses a non-standard port; confirm ordinary traffic on the same port still passes.

AI Gateway Security

The AI Gateway is the Security tier's in-account AI data plane. It exposes an OpenAI-compatible endpoint on port 8090, caches responses to cut cost and latency, and adds an in-dashboard AI assistant. The diagram traces a request from a client through the gateway: an exact-match cache check, then a semantic cache check, then a route to a governed remote provider (Amazon Bedrock, OpenAI, Anthropic) with token metering and audit logging.

flowchart LR
    CLIENT["Client app
OpenAI base URL -> :8090"] --> EXACT{"Exact-match
cache hit?"}
    EXACT -->|"yes"| RESP["Cached response"]
    EXACT -->|"no"| SEM{"Semantic
cache hit?"}
    SEM -->|"yes"| RESP
    SEM -->|"no"| ROUTE{"Route by model"}
    ROUTE -->|"bedrock/openai/anthropic"| REMOTE["Remote provider"]
    REMOTE --> METER["Token metering
+ audit log"] --> RESP

AI LLM Proxy with response caching

What it does. An OpenAI-compatible reverse proxy for LLM API calls. It fronts Amazon Bedrock, OpenAI, and Anthropic behind a single endpoint, with exact-match response caching, token metering, and audit logging. Clients keep using their existing OpenAI client libraries -- they just point the base URL at the gateway on port 8090.

Replaces / uses. A centralized LLM egress point. Exact-match caching returns identical prior responses without re-billing the provider; token metering and audit logging give you per-call accounting in your own account.

Configure. In the dashboard, open AI Gateway, enable the proxy, and configure providers, caching, metering, and audit logging. The same settings are available through the Terraform provider (cloudspectra_ai_gateway) and the configuration API.

OpenAI-compatible usage. Point your OpenAI client at the gateway's base URL on port 8090 and call the standard OpenAI API routes:

# Set the base URL to the gateway on port 8090
export OPENAI_BASE_URL=http://<GATEWAY_IP>:8090/v1

# Standard /v1/chat/completions request through the gateway
curl -s http://<GATEWAY_IP>:8090/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello, world"}]
  }'

# Route to a Bedrock or Anthropic model just by changing the model name:
curl -s http://<GATEWAY_IP>:8090/v1/chat/completions \
  -H "Authorization: Bearer $PROVIDER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic.claude-3-5-sonnet",
    "messages": [{"role": "user", "content": "Hello, world"}]
  }'

Verify. Send the same chat-completion request twice and confirm the second is served from cache (lower latency, no second provider charge), and confirm the call appears in the audit log with token counts.

AI Assistant

What it does. An in-dashboard AI assistant, backed by Amazon Bedrock, that answers questions about gateway status, configuration, and troubleshooting. It runs in your account; no vendor control plane sees your data.

Replaces / uses. Uses Amazon Bedrock in your own account for inference. It replaces the round trip of correlating dashboard views, logs, and this reference by hand when you are trying to answer "what is my gateway doing right now, and why."

Configure. There is nothing to configure: the assistant is a dashboard capability that is present on the Security tier, with no runtime settings of its own. Its one dependency is IAM -- Bedrock access comes from the operational IAM role (see Cross-account / home-account IAM role), so that role must be deployed for the assistant to reach a model.

Verify. Open the assistant in the dashboard and ask it about the gateway's current status; confirm it answers, and that the Bedrock invocation is made from your own account.

Local AI Inference (vLLM) Roadmap

What it will do. Serve LLMs locally on GPU instances in your own account using vLLM, exposed through the same OpenAI-compatible endpoint. Local models would be addressed with a local/<model> prefix in the model field. On a pre-first-token failure, the gateway would be able to fall back to a configured remote model according to an overflow policy.

Planned overflow policy. The intended fallback behavior on a pre-first-token failure:

In v1, use the AI LLM Proxy to route to Amazon Bedrock, OpenAI, or Anthropic, with exact-match and semantic response caching to cut provider spend.

AI Semantic Cache

What it does. Adds an embedding-based cache that recognizes similar prompts, not just byte-identical ones. Where the exact-match cache only hits on an identical request, the semantic cache returns a stored response for a sufficiently similar prompt -- raising the overall cache hit rate.

Replaces / uses. Extends the response caching of the AI LLM proxy. Higher hit rates mean fewer billed provider calls and lower latency for near-duplicate prompts.

Configure. In the dashboard, open AI Gateway -- Semantic Cache and enable it. The same setting is available through the Terraform provider and the configuration API.

Verify. Send a prompt, then send a slightly reworded but semantically equivalent prompt, and confirm the second is served from the semantic cache (lower latency, no new provider charge).

ElasticApps tier Platform

The ElasticApps tier is a distinct product line -- it is not part of the cumulative network stack above. Its job is to make a single stateful open-source application cost-elastic without clustering it and without putting a load balancer in front of it. You pick one application; the Cloud Spectra control plane runs it on a single instance that it continuously right-sizes -- moving the app onto a bigger instance when it is busy and a smaller one (or Spot) when it is idle -- while a sticky EBS volume keeps the data and an Elastic IP plus DNS name keep the address stable across every move.

Why it saves money. Databases, search and analytics engines, and dashboards are hard to scale horizontally -- so most teams run them on a fixed, oversized, always-on box sized for peak. ElasticApps instead moves the app onto exactly the instance the current load needs and rides Spot when it can. Two levers multiply: Spot discounts the box you run, and right-sizing changes which box you run. And because the Marketplace software fee is a small multiple of the instance's on-demand price (with a per-hour cap), scaling the box down shrinks the fee along with the EC2 bill.

flowchart TB
    subgraph VPC["Your VPC (singleton spans AZ A + AZ B)"]
      direction TB
      ASG["Singleton Auto Scaling Group
min=max=desired=1"]
      INST["ElasticApps instance
(one selected app + nginx :443)"]
      VOL["Sticky EBS data volume
(follows the instance)"]
      ASG --> INST
      INST --- VOL
    end
    EIP["Elastic IP + private DNS name
(stable endpoint)"] --> INST
    CTRL["Elastic control plane
(right-size / Spot / re-attach)"] -.manages.-> ASG
    CTRL -.re-associates.-> EIP
    style INST fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    style VOL fill:#fef3c7,stroke:#f59e0b,color:#92400e
    style EIP fill:#d1fae5,stroke:#10b981,color:#065f46
    style CTRL fill:#ede9fe,stroke:#8b5cf6,color:#5b21b6

The application catalog

What it is. A single AMI bakes more than a dozen popular stateful open-source applications and observability agents, all dormant. At launch you select one to activate; the control plane initializes it on first boot, seeds its admin secret from SSM Parameter Store, sizes it to the instance's memory, and serves it over HTTPS. Every app is unmodified upstream; configuration is delivered entirely through Cloud Spectra.

A logging bundle (OpenSearch + OpenSearch Dashboards + a Fluent Bit shipper) can also be activated as a set. Only one application (or bundle) runs per instance, so ports never conflict and the external surface is a single HTTPS endpoint. RAM-bound apps such as ClickHouse and OpenSearch see the largest right-sizing wins; the memory-optimized r7i / r8g families are recommended.

Vertical right-sizing & Spot Platform

What it does. Keeps the app on the smallest instance that comfortably carries its current load, and prefers Spot capacity for the deepest discount. You define an ordered instance ladder (for example r7i.large -> r7i.xlarge -> r7i.2xlarge) and scale-up / scale-down utilization thresholds; the control plane picks the rung that fits.

How it works. The app runs on a singleton Auto Scaling Group (min=max=desired=1). To resize, the control plane publishes a new launch-template version at the target instance type and lets the ASG relaunch the singleton on it -- a clean instance replacement rather than an in-place stop/start that would fight the ASG health check. The sticky volume detaches from the old instance and re-attaches to the new one, so no data is lost. On-demand vs Spot is handled by the ASG's mixed-instances policy, so the same replacement path also moves the app between purchase options.

Configure. Set the instance ladder, the scale-up / scale-down thresholds, and the Spot preference through the Terraform provider (cloudspectra_elastic_apps) or the configuration API. Leaving the ladder empty pins the app to its launch instance type (no automatic resizing).

sequenceDiagram
    autonumber
    participant M as Elastic control plane
    participant A as Singleton ASG
    participant Old as Current instance
    participant New as Replacement instance
    participant V as Sticky EBS volume
    Note over M: Load crosses a ladder threshold -> choose target size
    M->>A: publish new launch-template version (target instance type)
    M->>Old: gracefully stop the app, detach the volume
    A->>New: launch replacement on the new size (Spot or on-demand)
    V-->>New: re-attach the sticky volume (same data)
    New->>New: start the app; refresh the cert if the endpoint moved
    M->>Old: terminate the old instance
    Note over New: Elastic IP + DNS re-pointed -> clients see one address

Verify. Drive sustained load above the scale-up threshold and confirm the app comes back on the next ladder rung with the same data and the same endpoint; let load fall below the scale-down threshold and confirm it settles onto a smaller (or Spot) instance.

Predictive Vertical Scaling Platform Roadmap

What it will do. Attach an EC2 Predictive Scaling policy in ForecastOnly mode to the singleton Auto Scaling Group (min=max=desired=1). AWS trains a 14-day ML forecast from the utilization history; because the ASG is a singleton, AWS never changes the desired count itself. Instead Cloud Spectra reads the forecast and performs a vertical instance-type resize in the next low-load window before the predicted peak arrives.

Why it matters. Reactive scaling fires only after a threshold has already been breached. Pre-sizing during the preceding quiet period matters for the vertical case, where an instance-type change requires a brief replacement gap -- so the resize is best taken when the app is idle rather than at the peak.

Training warmup. AWS needs about 14 days of utilization history before the forecast is usable. Until then the reactive right-sizing path is the only one in effect -- as it is throughout v1.

flowchart LR
    CW["CloudWatch
utilization history"] --> ML["EC2 Predictive Scaling
(14-day ML model, ForecastOnly)"]
    ML --> FC["Look-ahead
load forecast"]
    FC --> GW{"Peak forecast
AND current load low?"}
    GW -->|"yes"| ACT["Pre-emptive vertical
resize of the singleton"]
    GW -->|"no"| WAIT["Wait for the reactive
right-sizing path"]

Sticky EBS storage & a stable endpoint

What it does. Decouples the app's data and its address from the instance, so both survive every resize, Spot reclaim, and instance replacement -- "kill the box, keep the data." The app's data directory lives on a dedicated EBS volume that is detached and re-attached rather than rebuilt; the endpoint is a stable Elastic IP together with a managed private Route 53 DNS name.

How it stays stable. When the instance moves, the control plane re-associates the Elastic IP and upserts the private DNS record to the new instance. HTTPS works out of the box: on first boot the control plane generates a self-signed certificate whose subject alternative name is built on the DNS name (not the private IP, which changes when the instance moves between AZs), so the certificate stays valid across moves. Web apps are fronted by nginx on port 443; databases such as PostgreSQL and Valkey use their own native TLS.

flowchart LR
    subgraph BEFORE["Before a move"]
      I1["Instance (size N, AZ A)"] --- D1["Data volume"]
    end
    subgraph AFTER["After resize / Spot swap / AZ move"]
      I2["Instance (size M)"] --- D2["SAME data volume
(re-attached)"]
    end
    I1 -->|"resize / interruption / replacement"| I2
    EP["Elastic IP + DNS name
(unchanged)"] --> I1
    EP --> I2
    style D1 fill:#fef3c7,stroke:#f59e0b,color:#92400e
    style D2 fill:#fef3c7,stroke:#f59e0b,color:#92400e
    style EP fill:#d1fae5,stroke:#10b981,color:#065f46

Verify. Note the app's endpoint, write some data, then terminate the running instance. Confirm the ASG relaunches the app, the same volume re-attaches (your data is intact), and the endpoint resolves to the new instance without a certificate warning.

Multi-AZ resilience

What it does. Because the app is a single box, there is no in-zone-traffic reason to pin it to one Availability Zone -- so the singleton Auto Scaling Group spans multiple AZs (one instance placed across several subnets). Spanning AZs gives the scheduler more Spot capacity pools to draw from and lets the app come back in a healthy zone if its own zone has a problem, with no cross-AZ data-transfer cost (there is only one box).

Spot interruptions. On a Spot interruption notice the control plane gracefully stops the app (flushing/checkpointing) and cleanly detaches the volume, then the ASG relaunches the replacement biased to the volume's AZ so it re-attaches the existing volume with no data loss. Same-AZ re-attach is the normal path; downtime is just the boot time.

Enable & configure

Subscribe and launch. Subscribe to the Platform listing on the AWS Marketplace and launch the stack the same way as any other tier (see Deployment & upgrades). ElasticApps deploys from the same base CloudFormation template -- the multi-AZ singleton is a runtime construct, not a separate template.

Select the app and its policy. After launch, choose the application (or the logging bundle) and set the scaling ladder, thresholds, and Spot preference. Like every other feature in this guide, these are written once to SSM Parameter Store; in v1 they are set through the Terraform provider (cloudspectra_elastic_apps) or the configuration API.

Fleet monitoring & analytics Network Roadmap

What it will do. Give you a single pane of glass over the whole gateway fleet -- every instance, across every per-AZ Auto Scaling Group -- with no external service. A Prometheus server on the primary (leader) instance scrapes a lightweight exporter on each fleet instance, and a Grafana instance renders the dashboards. All of it runs in your account; no telemetry leaves your boundary.

How you would reach it. In the planned design, Grafana would be served from the management dashboard over HTTPS at the /grafana/ path, behind the same authenticated login -- single sign-on via the dashboard's reverse proxy, with Grafana bound to loopback and never exposed directly.

flowchart LR
    subgraph A["ASG -- Availability Zone A"]
      IA["gateway instances"]
    end
    subgraph B["ASG -- Availability Zone B"]
      IB["gateway instances"]
    end
    IA -->|"metrics (pull)"| M["Primary (leader) instance
Prometheus + Grafana"]
    IB -->|"metrics (pull)"| M
    M --> PANE["Single-pane dashboards
(HTTPS /grafana/)"]
    style M fill:#ede9fe,stroke:#8b5cf6,color:#5b21b6
    style PANE fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    style IA fill:#d1fae5,stroke:#10b981,color:#065f46
    style IB fill:#d1fae5,stroke:#10b981,color:#065f46

The dashboards Roadmap

Four dashboards are planned, each templated so you can filter by Auto Scaling Group, instance, Region, and Availability Zone:

Settings

The fleet monitoring settings are configured like every other feature -- written once to SSM Parameter Store, and settable from the dashboard's Monitoring panel, the Terraform provider (cloudspectra_monitoring), or the configuration API. (The built-in Grafana fleet dashboards above remain on the roadmap; these settings do not.)

Ports & endpoints reference

The gateway exposes the following ports. Restrict access to each to the smallest client CIDR that needs it.

Cross-account / home-account IAM role

The base CloudFormation template (in either VPC mode) ships an intentionally minimal instance role. From it the gateway boots, elects a leader, associates its Elastic IP, and runs outbound source NAT on its primary interface -- with no further configuration. Most other features, however, require a separately deployed operational IAM role -- the cross-account / home-account role -- without which those features will not work.

You deploy this operational role once in your home account (the account running the gateway) and once in each additional account you want the gateway to manage. The gateway computes every IAM policy for you; you never hand-edit policy JSON.

What the operational role unlocks

Each capability below maps to one operational function role named <name>-cross-account-roleN. When the matching role is absent -- the stack is not deployed, or you deselected the feature -- that capability is simply inert: the gateway keeps running and retries; it does not crash.

Naming and trust

The operational roles are named <name>-cross-account-roleN, where <name> is derived from your resource-name prefix (default cloudspectra), the manager stack name, and the manager stack ID. The gateway rebuilds these names at runtime in order to assume the roles, so the deployed names must match exactly. Each role trusts only two principals in your home account -- the gateway instance role (<name>-instance) and the CloudFormation handler role (<name>-cf-handler-role) -- gated by an external ID, and optionally by your AWS Organizations ID. Each role's permissions are inline and fully visible to your security team for review.

Setting it up

From the dashboard's Setup IAM Roles view, each account row offers three ways to deploy the operational role. The gateway pre-fills every IAM policy, so you never type permissions.

After the stack reaches CREATE_COMPLETE (or the CLI finishes), use the dashboard's Add Account action to register the account so the gateway begins managing it.

Updating it over time

As Cloud Spectra ships features that need new permissions, the operational role is updated through CloudFormation -- the gateway never edits your IAM at runtime. The template itself is frozen -- only its parameter values change between releases, so an update never disturbs the roles you have already deployed.

After your gateway auto-upgrades, it regenerates the policies and -- on the dashboard's account view -- stages a CloudFormation Change Set on your existing stack against the new release. You open the link, review the diff in the CloudFormation console, and click Execute. (For an account that has no stack yet, the dashboard gives you a Quick-Create URL instead.) The cloudspectra-setup CLI is the alternative: re-run it with a fresh token to apply the update.

flowchart TD
    BASE["Base CloudFormation template
(minimal instance role)"] --> BOOT["Boot, leader election,
master EIP, primary-interface NAT"]
    DASH["Gateway dashboard"] -->|"Quick-Create URL /
Change Set / CLI / IaC"| OPS["Operational role stack
(cross-account / home-account)"]
    OPS --> FEAT["Most features:
full NAT data plane, GWLB, DNS,
ACM export, scaling, AI Gateway"]
    DASH -->|"new release:
stage Change Set"| UPD["Review diff in console,
click Execute"]
    UPD --> OPS
    TRUST["Trust: instance role +
cf-handler role, external ID"] --> OPS
    style BASE fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    style BOOT fill:#d1fae5,stroke:#10b981,color:#065f46
    style OPS fill:#fef3c7,stroke:#f59e0b,color:#92400e
    style FEAT fill:#d1fae5,stroke:#10b981,color:#065f46
    style DASH fill:#ede9fe,stroke:#8b5cf6,color:#5b21b6
    style UPD fill:#ede9fe,stroke:#8b5cf6,color:#5b21b6
    style TRUST fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a

Deployment & upgrades

There are three supported ways to deploy Cloud Spectra Gateway. All three deploy into your own AWS account and produce the same runtime: a per-AZ Auto Scaling Group behind a Gateway Load Balancer, with an Elastic IP as a stable endpoint and configuration in SSM Parameter Store.

flowchart TD
    MP["AWS Marketplace
1-click subscribe"] --> CF["CloudFormation
(one base template)"]
    CF --> MODE{"newOrExistingVpc"}
    MODE -->|"createNew"| RUNTIME["Per-AZ ASG behind GWLB
+ EIP + SSM config"]
    MODE -->|"selectExisting"| RUNTIME
    TFM["Terraform
(network mirror provider)"] --> RUNTIME
    AMI["Standalone AMI
(no CloudFormation)"] --> RUNTIME

CloudFormation (new VPC or existing/BYO VPC)

From the AWS Marketplace listing, 1-click launches a CloudFormation stack. A single base template covers both VPC modes; the newOrExistingVpc parameter selects which:

See the Quick Start for the step-by-step CloudFormation walkthrough.

Terraform (via a one-time network mirror)

Deploy and configure with Terraform using the cloudspectra/cloudspectra provider plus AWS modules. The provider is installed from a network mirror -- add a one-time network_mirror block to your ~/.terraformrc so Terraform can fetch it:

# ~/.terraformrc  (one-time)
provider_installation {
  network_mirror {
    url = "https://<cloudspectra-network-mirror>/"
  }
  direct {
    exclude = ["cloudspectra/cloudspectra"]
  }
}

terraform {
  required_providers {
    aws          = { source = "hashicorp/aws", version = ">= 5.0" }
    cloudspectra = { source = "cloudspectra/cloudspectra" }
  }
}

provider "cloudspectra" {
  gateway_url    = "https://<GATEWAY_EIP>"
  admin_password = var.cloudspectra_admin_password
}

# Every feature on this page maps to a provider resource, e.g.:
resource "cloudspectra_nat_gateway"        "main" { enable = true }
resource "cloudspectra_firewall_gateway"   "main" { enable = true }
resource "cloudspectra_web_proxy_gateway"  "main" { enable = true }
resource "cloudspectra_ai_gateway"         "main" { enable = true }

Standalone AMI (no CloudFormation)

You can launch the AMI directly into a subnet. It boots with outbound NAT and the management dashboard already running -- no CloudFormation stack required. This is the lightest-weight way to evaluate the gateway or to run it in environments where you manage the surrounding infrastructure yourself.

Upgrades

Because the runtime is a per-AZ Auto Scaling Group, upgrades roll through the fleet instance by instance. Gateway Load Balancer connection draining lets active flows on an instance finish before it is replaced, so planned upgrades and resizes are seamless. Configuration in SSM Parameter Store is preserved across instance replacement, so the data plane reconciles back to your declared state automatically.

Cleanup tool (cloudspectra_cleanup)

To decommission a deployment normally, delete its CloudFormation stack (or run terraform destroy, or "Destroy" from the dashboard) — that path drains the deployment gracefully. If a teardown ever aborts, fails, or gets stuck, cloudspectra_cleanup is a standalone, last-resort tool that fully removes the deployment's AWS resources so nothing is left orphaned (and billing).

• Safe by default — with no flags it only lists what it would delete (a dry run); deleting requires --force, and --force without --yes prompts for confirmation.
• Scoped to your deployment — it matches resources by the Cloud Spectra owner tag and a delimited name token, so it never touches your other resources or a different deployment that merely shares a name prefix.
• Independent — a single self-contained binary (no dependencies) that runs with your own AWS credentials and needs no running gateway, so it works precisely when the in-product teardown could not.
• Complete — VPC, subnets, route tables, gateways, ENIs and EIPs; GWLB / endpoint services / load balancers; instances, Auto Scaling groups and launch templates; SSM parameters and Secrets Manager secrets; CloudWatch logs and alarms, EventBridge rules and Lambda functions; IAM roles, instance profiles and managed policies; AMIs and snapshots; ACM certificates, Route 53 zones and Network Firewall policies; and the CloudFormation stacks themselves.

It is already installed on every gateway instance at /opt/cloudspectra/bin/cloudspectra_cleanup. To run it from your workstation or CI, download the single binary for your platform (gzip-compressed, ~5 MB): Linux x86-64 · Linux ARM64 · macOS Intel · macOS Apple Silicon.

# Download (Linux x86-64), decompress, make executable
curl -fsSL https://cloudspectra-gateway-17ylb4c35xo49-public.s3.us-east-1.amazonaws.com/gateway/1.0.0/cleanup-tool/cloudspectra_cleanup-linux-amd64.gz \
  | gunzip > cloudspectra_cleanup
chmod +x cloudspectra_cleanup

# List Cloud Spectra deployments in your account/region
./cloudspectra_cleanup --discover

# DRY RUN (default): show everything that WOULD be removed for a deployment
./cloudspectra_cleanup <deployment-name>

# Actually remove it (prompts to confirm; add --yes for non-interactive)
./cloudspectra_cleanup <deployment-name> --force

The deployment name is your CloudFormation stack name (or the name shown by --discover). It uses the standard AWS credential chain (--profile <name> to pick a profile); add --regions us-east-1,us-west-2 to span regions and --json for machine-readable output.