Cloud Spectra Gateway -- Frequently Asked Questions v1.0.0

This FAQ answers the questions enterprise buyers and AWS Marketplace reviewers ask most often about Cloud Spectra Gateway. Cloud Spectra Gateway deploys entirely into your own AWS account and replaces metered AWS networking and per-token LLM-API spend with a fixed EC2 cost -- "Your Cloud, Off the Meter." There is no vendor control plane: your data, traffic, and prompts stay inside your account boundary.

If a topic is not covered here, see the Quick Start for a guided deployment, the User Guide for the full configuration reference, or the Architecture page for how the components fit together.

graph LR
    subgraph ACCT["Your AWS Account (trust boundary)"]
        direction LR
        APP["Private workloads
(EC2 / EKS / Lambda VPC)"]
        GW["Cloud Spectra Gateway
per-AZ ASG behind GWLB"]
        AWS["AWS services in-account
SSM / ACM / Bedrock"]
        APP -->|"traffic + prompts"| GW
        GW -->|"NAT egress / LLM proxy"| AWS
    end
    GW -->|"internet egress via EIP"| NET["Internet / LLM providers"]
    style ACCT fill:#eef2ff,stroke:#6366f1,color:#312e81
    style GW fill:#d1fae5,stroke:#10b981,color:#065f46
    style NET fill:#fef3c7,stroke:#f59e0b,color:#92400e

Everything inside the dashed boundary runs in your account. Cloud Spectra operates no external service that sees your traffic.

Billing & Cost

How is Cloud Spectra Gateway billed?

Cloud Spectra Gateway is sold through AWS Marketplace as a software product that runs on EC2. The Cloud Spectra software fee is a fixed hourly fee per running instance, charged through your existing AWS bill, in addition to the underlying EC2 instance cost. There is no separate invoice from Cloud Spectra and no usage-based metering on the software itself -- the fee does not change with how much traffic you push, how many gigabytes you NAT, or how many tokens you proxy.

How does this replace metered AWS networking spend?

AWS managed networking services bill on usage. A NAT Gateway charges an hourly rate plus a per-gigabyte data-processing charge; a Network Load Balancer charges per capacity unit. Cloud Spectra Gateway performs the equivalent work -- outbound NAT, inbound port forwarding, L4 load balancing, TLS termination -- on EC2 instances you own. You pay the EC2 instance cost plus the fixed software fee instead of the per-gigabyte and per-capacity-unit meters. Because the software fee does not scale with throughput, the savings grow as your traffic grows.

flowchart LR
    subgraph M["Metered model"]
        NATM["NAT Gateway
hourly + per-GB"]
        NLBM["NLB
per capacity unit"]
        LLMM["LLM APIs
per token"]
    end
    subgraph F["Cloud Spectra fixed model"]
        EC2["EC2 instance cost"]
        SW["Fixed software fee
per running instance"]
    end
    M -->|"replace with"| F
    style NATM fill:#fecaca,stroke:#ef4444,color:#991b1b
    style NLBM fill:#fecaca,stroke:#ef4444,color:#991b1b
    style LLMM fill:#fecaca,stroke:#ef4444,color:#991b1b
    style EC2 fill:#d1fae5,stroke:#10b981,color:#065f46
    style SW fill:#d1fae5,stroke:#10b981,color:#065f46

How does it reduce per-token LLM API spend?

The Security tier's AI Gateway adds an OpenAI-compatible reverse proxy with exact-match response caching and an embedding-based semantic cache. When a prompt has been seen before (or is semantically close to one already answered), the cached response is returned without a new upstream call, so you do not pay the provider's per-token charge again. Both caches run on the gateway in your account. See the AI Gateway section for details.

Can I run it on Spot Instances?

Yes. Cloud Spectra Gateway runs in a per-Availability-Zone Auto Scaling Group, so you can choose On-Demand or Spot Instances per your tolerance for interruption. Spot lowers the EC2 portion of the cost; On-Demand gives the most predictable capacity. Because the fleet is horizontally scaled behind a Gateway Load Balancer, the loss of a single Spot instance is absorbed by the surviving instances in that zone.

Deployment

How do I deploy Cloud Spectra Gateway?

There are three supported paths, all of which run in your own account:

flowchart TD
    A["Subscribe in AWS Marketplace"] --> B{"Choose deployment path"}
    B -->|"1-click"| C["CloudFormation
new-VPC or existing/BYO-VPC"]
    B -->|"IaC"| D["Terraform
cloudspectra/cloudspectra provider"]
    B -->|"direct"| E["Standalone AMI
boots NAT + dashboard"]
    C --> F["Per-AZ ASG behind GWLB,
EIP endpoint, dashboard on 443"]
    D --> F
    E --> F
    style A fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    style F fill:#d1fae5,stroke:#10b981,color:#065f46

Which AWS Regions are supported?

Cloud Spectra Gateway runs in commercial AWS Regions that offer the EC2 instance families and AWS services it relies on -- Elastic IP, SSM Parameter Store, Gateway Load Balancer, and ACM. The AI Gateway's Bedrock integration is available where Amazon Bedrock and your chosen models are available. Confirm Region availability for your selected instance types on the EC2 instance types page.

What is the difference between the new-VPC and existing-VPC templates?

The new-VPC template provisions a fresh VPC with its subnets, route tables, and gateway in one step -- ideal for a clean greenfield deployment or an evaluation. The existing-VPC (BYO-VPC) template deploys the gateway into a VPC and subnets you already operate, so it slots into your established network design and CIDR plan. Both produce the same runtime: a per-AZ ASG behind a Gateway Load Balancer with an Elastic IP endpoint.

What is the standalone AMI for?

The standalone AMI launches the appliance directly with no CloudFormation stack. It boots ready with NAT and the management dashboard, which is useful when you want the smallest possible footprint, are deploying outside a CloudFormation workflow, or want to evaluate the gateway on a single instance before adopting one of the orchestrated paths.

How do I install the Terraform provider?

The Cloud Spectra Terraform provider is distributed through a network mirror. You add a one-time network_mirror block to your ~/.terraformrc, after which terraform init resolves the cloudspectra/cloudspectra provider from that mirror. From there you manage the gateway configuration as code alongside your AWS resources.

How do upgrades work?

Upgrades roll through the Auto Scaling Group fleet. New gateway instances launch from an updated AMI and join the Gateway Load Balancer target set; older instances are drained and retired. Because traffic is balanced across the fleet behind the GWLB, replacement happens instance by instance without taking the data plane offline. Configuration is preserved in SSM Parameter Store, so new instances read the same settings as the ones they replace.

How do I update the operational IAM role over time?

Through CloudFormation, not by the gateway editing your IAM at runtime. The operational (cross-account / home-account) role is deployed from a frozen template; as Cloud Spectra ships features that need new permissions, only the template's parameter values change. 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 -- you stay in control of applying the change. (The cloudspectra-setup CLI is an alternative: re-run it with a fresh token to apply the update.) A dashboard permission picker also lets you deselect optional features, which removes their roles on the next stack update; core features are always retained. See the User Guide for the full procedure.

Security & Compliance

Does my data leave my AWS account?

No. Cloud Spectra Gateway is deployed into your account, and the data plane runs entirely on instances you own. Traffic that the gateway NATs, load-balances, inspects, or proxies stays inside your VPC and your account boundary. Cloud Spectra operates no external control plane that receives, brokers, or observes your traffic. The only outbound destinations are the ones your own routes and policies send traffic to -- the public internet for NAT egress, or the LLM providers you explicitly configure in the AI Gateway.

Is there a vendor control plane or call-home?

No. There is no Cloud Spectra-hosted control plane. Configuration lives in your account's SSM Parameter Store, management is performed through the in-account dashboard and config API, and the gateway does not depend on an external Cloud Spectra service to forward traffic. This is central to the product's model: your cloud, off the meter, under your control.

flowchart LR
    subgraph YOURS["Your AWS Account"]
        direction TB
        DASH["Dashboard + config API
(in-account)"]
        SSM["SSM Parameter Store
(config of record)"]
        DP["Data plane
NAT / NLB / firewall / AI proxy"]
        DASH --> SSM --> DP
    end
    VENDOR["Cloud Spectra
(software vendor)"]
    VENDOR -. "Marketplace AMI + software fee only" .-> YOURS
    VENDOR -. "NO traffic, NO control plane, NO data egress" .-x DP
    style YOURS fill:#eef2ff,stroke:#6366f1,color:#312e81
    style DP fill:#d1fae5,stroke:#10b981,color:#065f46
    style VENDOR fill:#f1f5f9,stroke:#94a3b8,color:#334155

What IAM permissions does the gateway need?

The gateway runs under a least-privilege IAM role scoped to the resources it actually manages -- for example its own Elastic IP, network interfaces, Auto Scaling and Gateway Load Balancer resources, SSM parameters for its configuration, and, on the Security tier, Bedrock model invocation. The CloudFormation templates create this role for you, and the permissions are documented so your security team can review them before deployment.

Why do most features need an extra IAM role?

The base CloudFormation template ships an intentionally minimal instance role -- enough for the gateway to boot, associate its Elastic IP, and run outbound NAT on its primary interface, but nothing more. Every other capability (the full per-AZ NAT data plane for your private subnets, Gateway Load Balancer, EventBridge, scaling, teardown, the AI Gateway, and managing other accounts) is gated on a separately deployed operational IAM role -- the cross-account / home-account role. This keeps the always-on base permissions small and lets your security team review and approve the operational permissions on their own. You deploy the operational role once per account from a CloudFormation stack the dashboard pre-fills; without it, most features will not work. See the User Guide for the full setup.

What does the Security Gateway tier actually inspect?

The Security Gateway tier adds ten in-account enforcement features on top of everything in the Network Gateway tier: inline Suricata IDS/IPS, nftables firewall rules, domain/URL filtering, URL-category filtering, ET Open threat detection, multi-source community threat feeds, TLS inspection (SSL bump), SIEM export (OCSF/CEF/syslog), antivirus scanning (ClamAV ICAP), and L7 App-ID (nDPI). All of them run on your own gateway instances -- no traffic, file, or event is sent to Cloud Spectra or any third-party inspection service. Each one is documented in the User Guide.

Can I block whole categories of sites, not just individual domains?

Yes. Domain / URL filtering gives you policy-driven allow and block lists for egress, and URL-category filtering extends that to whole categories -- adult, gambling, malware, and anonymizer -- using the free UT1 category lists. Category matching is done at the domain level, so it needs no TLS decryption and carries no per-seat category-feed license. See URL-category filtering in the User Guide.

Where do the intrusion-detection rules and threat intelligence come from?

From free, open sources, cached in the AMI and refreshed in your account -- there is no vendor subscription to buy. ET Open threat detection supplies the Emerging Threats (ET Open) Suricata rule sets, and multi-source community threat feeds add inline-IPS blocklists from abuse.ch, CINS Army, and Spamhaus DROP. The result is $0 in vendor licensing for threat intelligence, with the feeds fetched and applied entirely inside your account. Bringing your own commercial ruleset (ET Pro, Talos) is on the roadmap and is not enabled in v1. See ET Open threat detection and community threat feeds.

Can the gateway inspect HTTPS traffic?

Yes, with TLS inspection (SSL bump). The gateway transparently decrypts proxied TLS sessions so the inline IPS and the proxy can inspect the cleartext, then re-encrypts to the destination. By default it uses a self-managed certificate authority created in your account (AWS Private CA is an opt-in alternative); the private keys never leave your account. In v1 the CA is auto-trusted on your EC2 instances through SSM -- Kubernetes pods and on-premises clients must be given the CA out of band. See TLS inspection in the User Guide.

Can it scan downloads for malware?

Yes. Antivirus scanning runs ClamAV behind c-icap and scans files that pass through the proxy using ICAP RESPMOD. Files are scanned on the gateway in your account and are never uploaded anywhere for analysis. Scanning HTTP downloads works on its own; scanning HTTPS downloads requires TLS inspection to be enabled first, because the file must be in cleartext to be scanned. See Antivirus scanning.

Can I block Tor, BitTorrent, and other applications by name?

Yes. L7 App-ID uses a standalone nDPI daemon to identify applications from the traffic itself rather than from ports, so you can block Tor, BitTorrent, and anonymizer/proxy tools, and flag suspicious signals such as DGA domains, self-signed certificates, and command-and-control patterns. It runs in your account with no external classification service. See L7 App-ID.

Can I send security events to my SIEM?

Yes. SIEM export streams IDS, firewall, and audit events to Splunk, Microsoft Sentinel, QRadar, or any syslog collector, in vendor-neutral OCSF, CEF, or syslog format. The events are generated on your gateway and shipped directly to the destination you configure; Cloud Spectra is not a relay. See SIEM export.

How is the dashboard secured?

The Angular management dashboard is served over HTTPS. TLS is terminated by HAProxy on port 443 using an AWS Certificate Manager (ACM) certificate, so the certificate is issued and stored in your account. You restrict who can reach the dashboard with security groups and the client CIDR you allow at deployment time.

Where do my prompts and traffic live?

In your account. NAT, load-balancing, firewall, and proxy traffic transits the gateway instances in your VPC. LLM prompts sent to the AI Gateway are processed on the gateway in your account; cache entries and audit logs are stored in your account. A prompt only leaves your account when it is served by a remote provider you explicitly configured (Amazon Bedrock, OpenAI, or Anthropic) -- Cloud Spectra is never in that path. Cache hits are answered entirely in-account. See the AI Gateway section for the data-privacy specifics.

Networking

Does it replace the AWS NAT Gateway?

Yes. The Network Gateway tier provides source NAT (sNAT) for outbound internet access from private instances, replacing the metered NAT Gateway hourly and per-gigabyte charges. You point a private subnet's default route at the gateway's network interface, and its traffic egresses through the gateway's Elastic IP. It also provides destination NAT (dNAT) for inbound TCP port forwarding to private targets.

Does it replace the AWS Network Load Balancer?

The gateway provides in-appliance Linux IPVS L4 load balancing, kept in sync with an AWS NLB target set, plus TLS termination via HAProxy using an ACM certificate. This covers the common L4 load-balancing and HTTPS-termination patterns customers use a Network Load Balancer for, while keeping the work on instances you own.

How does the per-AZ design avoid cross-AZ data charges?

Cloud Spectra runs one Auto Scaling Group per Availability Zone, and each AZ egresses through its own network interface. When you route each AZ's private subnets to that same AZ's gateway interface, traffic NATs locally instead of hopping to another zone -- which avoids the inter-AZ data-transfer charges that a single centralized appliance would incur. This per-AZ locality is built into the architecture.

graph TD
    subgraph AZ1["Availability Zone A"]
        S1["Private subnets (AZ A)"] --> G1["Gateway ASG (AZ A)
own ENI"]
    end
    subgraph AZ2["Availability Zone B"]
        S2["Private subnets (AZ B)"] --> G2["Gateway ASG (AZ B)
own ENI"]
    end
    G1 -->|"local egress, no cross-AZ fee"| NET["Internet"]
    G2 -->|"local egress, no cross-AZ fee"| NET
    style G1 fill:#d1fae5,stroke:#10b981,color:#065f46
    style G2 fill:#d1fae5,stroke:#10b981,color:#065f46
    style NET fill:#fef3c7,stroke:#f59e0b,color:#92400e

What about source IP -- is the client IP preserved?

For outbound NAT, private instances appear on the internet as the gateway's Elastic IP, which is the expected and desired behavior for a NAT appliance (a stable, allow-list-friendly egress address). For inbound and load-balanced flows, source-IP handling follows the relevant data path -- consult the User Guide for the specifics of each feature so you can match it to your application's needs.

Does the gateway keep a stable private IP when an instance is replaced?

Yes, with the Sticky Secondary ENI feature. Each Auto Scaling Group slot gets a pre-provisioned secondary network interface with a fixed private IP. When the instance in that slot is replaced -- by a scale event, a resize, a Spot reclaim, or a health-check failure -- the same interface is attached to the replacement, so the private IP that your routes and allow-lists point at does not change. It is a Network Gateway tier feature and is off by default; you opt in through the Terraform provider (cloudspectra_sticky_eni) or the configuration API. See Sticky Secondary ENI in the User Guide.

Do I have to re-point my route tables every time the fleet changes?

No. The Per-Slot Route Table feature gives each slot its own route table with a default route (0.0.0.0/0) pointing at that slot's network interface. You associate your subnets with the slot's route table once, and Cloud Spectra keeps the route pointed at the live interface as instances come and go -- so there is no manual route edit on every replacement. See Per-Slot Route Table.

Is there a forward web proxy?

Yes. The Network Gateway tier includes a forward HTTP proxy built on Squid, with response caching, bandwidth limiting, and metrics. Caching cuts repeated egress for things like package downloads and container-image layers, which reduces both the traffic you pay to move and the time your builds wait. The proxy port is configurable. It is also the data path that the Security tier's domain/URL filtering, TLS inspection, and antivirus scanning attach to.

Can I keep a persistent data volume across instance replacements?

Yes. Sticky EBS attaches one persistent EBS data volume to each Auto Scaling Group's lead instance and re-homes it onto the replacement within the same Availability Zone -- without reformatting, so the data survives. It is a universal primitive available on every tier, not only on ElasticApps, and it is off by default (you opt in, since the volume carries its own storage cost).

How is high availability achieved?

Each zone's Auto Scaling Group runs behind a Gateway Load Balancer (using the GENEVE protocol) so the fleet scales horizontally and survives the loss of an individual instance: traffic shifts to the surviving instances in the zone. The gateway also maintains an Elastic IP for a stable endpoint. Deploy across multiple Availability Zones for zone-level resilience.

Can I scale the gateway up or out?

Yes -- both vertically and horizontally. You can change the instance size live to add capacity per node, and you can scale out by adding instances behind the Gateway Load Balancer. The per-AZ Auto Scaling Groups handle adding and removing instances within each zone.

AI Gateway

Which LLM providers does the AI Gateway support?

The AI Gateway is an OpenAI-compatible reverse proxy that routes to Amazon Bedrock, OpenAI, and Anthropic. Your clients point their OpenAI base URL at the gateway's endpoint (port 8090), and the gateway forwards to the configured upstream provider. Because the interface follows the OpenAI API shape, most existing SDKs and applications work by changing only the base URL.

flowchart LR
    APP["Your app
(OpenAI base URL -> gateway:8090)"] --> GW["AI Gateway proxy"]
    GW --> CACHE{"Cache hit?"}
    CACHE -->|"exact or semantic match"| HIT["Return cached response
(no provider call)"]
    CACHE -->|"miss"| ROUTE{"Route to provider"}
    ROUTE -->|"bedrock"| BR["Amazon Bedrock"]
    ROUTE -->|"openai"| OAI["OpenAI"]
    ROUTE -->|"anthropic"| ANT["Anthropic"]
    ROUTE -.->|"roadmap (v2)"| VLLM["vLLM in-account GPU
ROADMAP -- not in v1"]
    style GW fill:#d1fae5,stroke:#10b981,color:#065f46
    style HIT fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    style VLLM fill:#f1f5f9,stroke:#94a3b8,color:#334155

Is local vLLM inference available? Roadmap

As planned, the AI Gateway would serve models locally with vLLM on in-account GPU instances, exposed through the same OpenAI-compatible interface and addressed as local/<model>. A local model with no remote fallback would keep the prompt and completion inside the account, with a pre-first-token overflow policy of queue, spill, or reject.

What do the response cache and semantic cache do?

The response cache stores completions keyed on an exact match of the request, so an identical prompt returns the stored answer without a new upstream call. The semantic cache goes further: it uses embeddings to recognize prompts that are similar (not just byte-identical) to ones already answered, raising the hit rate beyond exact match. Both caches live in your account and reduce the number of billable provider calls.

Is there an in-dashboard AI assistant?

Yes. The Security tier includes an AI Assistant: an in-dashboard 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. Together with the LLM proxy and the semantic cache, it is one of the three AI features the Security tier adds.

What are the data-privacy properties of prompts sent to the AI Gateway?

Prompts are processed by the gateway running in your account. Cache entries, token-metering counters, and audit logs are stored in your account. When you route to a remote provider (Bedrock, OpenAI, or Anthropic), the request goes to that provider exactly as your configuration directs -- Cloud Spectra is not in that path and does not receive a copy. Requests answered from the response cache or the semantic cache are served entirely in-account, with no provider call at all. You decide, per model and per policy, where each request may go.

ElasticApps

What is the ElasticApps tier?

ElasticApps is a separate Marketplace tier that makes 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 from a built-in catalog, and Cloud Spectra runs it on a single instance that it continuously right-sizes -- a bigger instance when the app is busy, a smaller one when it is idle, and Spot when your interruption tolerance allows -- while a sticky EBS volume keeps the data and an Elastic IP plus DNS name keep the address stable. It is documented in full in the User Guide and the Architecture guide.

flowchart LR
    A["ElasticApps instance
(one selected app)"] -- "resize / Spot swap / AZ move" --> B["Right-sized replacement
(same data, same address)"]
    V["Sticky EBS volume
(the data)"] -. follows .-> A
    V -. re-attaches .-> B
    EP["Elastic IP + DNS name
(stable address)"] --> A
    EP --> B
    style A fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    style B fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    style V fill:#fef3c7,stroke:#f59e0b,color:#92400e
    style EP fill:#d1fae5,stroke:#10b981,color:#065f46

How does ElasticApps save money on a stateful app?

Databases, search and analytics engines, and dashboards are hard to scale horizontally, so they are usually run on a fixed, oversized, always-on instance sized for peak. ElasticApps instead moves the app onto the smallest instance that carries its current load and rides Spot when it can. Two levers multiply: Spot discounts the box you run, and right-sizing changes which box you run. The Marketplace software fee is a small multiple of the instance's on-demand price with a per-hour cap, so scaling the box down lowers both the EC2 bill and the fee. See Pricing for the multiplier and cap.

Which applications can I run?

One application per instance, chosen from a catalog of more than a dozen popular open-source apps -- including Grafana, Prometheus, ClickHouse, OpenSearch, OpenSearch Dashboards, PostgreSQL, Neo4j, Trino, Valkey, Qdrant, MinIO, JupyterLab, Fluent Bit, and single-node Kubernetes (k3s, with the Calico CNI and an HTTPS dashboard) -- plus a logging bundle. Each ships unmodified from upstream; Cloud Spectra initializes it, seeds its admin secret from SSM Parameter Store, sizes it to the instance's memory, and serves it over HTTPS out of the box.

Is my data safe when the instance is resized or reclaimed?

Yes. The app's data directory lives on a dedicated EBS volume that is detached from the old instance and re-attached to the new one on every resize, Spot reclaim, or replacement -- the volume is never rebuilt, so the data persists ("kill the box, keep the data"). On a Spot interruption the app is gracefully stopped and the volume cleanly detached before the replacement launches, and the replacement is biased to the volume's Availability Zone so the re-attach is lossless.

Does the endpoint change when the app moves?

No. The app keeps a stable Elastic IP and a managed private DNS name; when the instance moves, the control plane re-associates the Elastic IP and updates the DNS record. The HTTPS certificate's name is built on the DNS name (not the private IP, which changes across Availability Zones), so it stays valid across moves without a certificate warning.

Is ElasticApps highly available?

ElasticApps targets cost-elasticity for a single stateful app, not synchronous high availability. The singleton runs across multiple Availability Zones for more Spot capacity and resilience to a single-AZ failure, and it self-heals by relaunching and re-attaching its volume -- so brief downtime during a move or replacement is expected. A cross-AZ snapshot-restore escalation for sustained capacity shortages, and predictive (forecast-driven) pre-sizing, are on the roadmap and not enabled in v1.

Can I run an elastic app on the Network, Security, or AI tiers?

Yes. Sticky EBS and vertical + Spot scaling are available on every tier, and the network tiers are a strict superset of ElasticApps. ElasticApps packages those primitives together with the application catalog as a standalone, lower-cost product for teams whose goal is simply to run one app elastically.

Monitoring & Analytics Network Gateway Roadmap

Does Cloud Spectra include monitoring dashboards? Roadmap

Not in v1. A built-in Grafana monitoring stack -- driven by a Prometheus server on the primary instance that scrapes every instance across all Auto Scaling Groups -- is planned, gated at the Network Gateway tier. The planned design is a single pane of glass over the whole fleet -- CPU, memory, disk, and network for every instance and every ASG -- with dashboards for a fleet overview, per-instance detail, NIC saturation (AWS ENA allowance), and cost savings. See Fleet monitoring & analytics in the User Guide, which is likewise marked roadmap. Today, the gateway dashboard's status views plus CloudWatch metrics and logs cover fleet visibility.

How does this differ from running Grafana as an ElasticApp?

They are separate things. The built-in fleet monitoring described above is on the roadmap and is not enabled in v1. The Grafana application in the ElasticApps catalog does ship in v1 -- it is one of the stateful open-source apps Cloud Spectra runs elastically for you (right-sized, sticky-EBS-backed, on a stable endpoint), pointed at whatever data sources you choose.

Which tiers will include monitoring, and will it cost extra? Roadmap

The planned fleet dashboards are gated at the Network Gateway tier, so they would be available on Network Gateway and the tiers above it. There is no separate monitoring SKU and no per-metric charge from Cloud Spectra. Nothing ships in v1, so there is nothing to enable or turn off today.

Where will I view the metrics? Roadmap

The planned design serves Grafana from the management dashboard, at the /grafana/ path behind the same login: reached through the dashboard's authenticated reverse proxy (single sign-on) and bound to loopback on the instance, so it is never exposed directly to the network. This is planned design, not a v1 capability.

Will monitoring affect data-plane performance? Roadmap

It is not designed to. In the planned design, Prometheus and Grafana run only on the primary instance; every other instance runs just a lightweight exporter. The server components are resource-capped and the time-series database has a bounded retention window, so the monitoring stack cannot starve the NAT, firewall, or AI data plane.

Does my telemetry leave my AWS account?

No. Cloud Spectra runs entirely inside your account and sends no telemetry anywhere else -- consistent with the no-vendor-control-plane design. That holds for the planned monitoring stack too: it is designed to keep metrics in your account. Alerting and exporting metrics to an external store (for example Prometheus remote-write to Grafana Cloud, Datadog, or a self-hosted backend) are on the roadmap. Dashboards over VPC flow-log / NAT traffic are also on the roadmap and are not enabled in v1.

Support & Operations

How do I manage the gateway day to day?

The primary management surface is the Angular dashboard, served over HTTPS on port 443. From it you enable and configure features, review status, and adjust scaling. The same configuration is available through the config API on port 8080 and through the Terraform provider, so you can manage the gateway interactively or as code. The configuration of record is stored in SSM Parameter Store in your account.

Where are the logs?

Operational logs -- including AI Gateway audit logs and token metering -- are produced and retained within your account, alongside the metrics surfaced in the dashboard. Because the data plane runs on your instances, you can also forward host and service logs into your own observability stack.

Which features are included, and how do tiers relate?

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) and runs a single stateful application cost-elastically; Network adds the networking data plane; Security adds inline inspection, enforcement and the governed AI LLM gateway.

How does scaling behave during operations?

Scaling is handled by the per-AZ Auto Scaling Groups behind the Gateway Load Balancer. You scale out by adding instances to absorb more load and scale in when demand drops; you scale up by selecting a larger instance size. Combined with multi-AZ deployment, this lets the fleet match capacity to demand while remaining resilient to the loss of any single instance.