Nquiry — Customer Environment Requirements

This document specifies the AWS environment prerequisites for deploying a licensed Nquiry instance in your organization's AWS account. Nquiry is deployed as a single-tenant stack — your data never leaves your AWS boundary.

Revision History

Version	Date	Summary of changes
1.0	2026-04-21	Initial draft from architecture decision (NQU-643) and Terraform module inspection.
1.1	2026-05-03	Three operational decisions incorporated: license-validity heartbeat, periodic-disconnect grace tokens, optional cross-account support-access role.
1.2	2026-05-04	Reconciled with v1 sales draft: added Bedrock RPM/TPM starting quotas, AWS managed-policy installer alternative, egress allow-list, complementary AWS services (Config / GuardDuty / Security Hub), consolidated pre-flight checklist.
1.3	2026-05-04	Added revision history, at-a-glance pre-install checklist, and enhanced high-level architecture diagram.

Sizing tiers and cost estimates pending validation against current production telemetry and live AWS Cost Explorer; numbers may shift in a 1.x revision.

Deployment Overview

Nquiry is delivered as an AWS Marketplace container product. Your organization subscribes via AWS Marketplace, then deploys using a Terraform template provided by JE Vectors. The deployment creates a complete, isolated Nquiry stack in your AWS account.

High-Level Architecture

┌──────────────────────────────────────────────────────────────────────────┐
│  Your AWS Account (commercial or GovCloud)                               │
│                                                                          │
│  ┌────────────────────────────────────────────────────────────────────┐  │
│  │  VPC — private-only by default                                     │  │
│  │                                                                    │  │
│  │  ┌──── Private Subnet (AZ-1) ────┐  ┌──── Private Subnet (AZ-2) ─┐ │  │
│  │  │  ECS Fargate (Nquiry app)    │  │  ECS Fargate (Nquiry app)  │ │  │
│  │  │  RDS PostgreSQL (primary)    │  │  RDS PostgreSQL (standby)  │ │  │
│  │  │  ElastiCache Redis (primary) │  │  ElastiCache Redis (replica)│ │  │
│  │  │  ALB (internal, default)     │  │                             │ │  │
│  │  └──────────────────────────────┘  └────────────────────────────┘ │  │
│  │                                                                    │  │
│  │  VPC Endpoints (PrivateLink):                                      │  │
│  │   ECR · S3 · KMS · Secrets Manager · Bedrock · CloudWatch Logs · STS │  │
│  └────────────────────────────────────────────────────────────────────┘  │
│                                                                          │
│  Account-scoped services (outside the VPC):                              │
│   S3 (evidence) · Cognito (auth) · KMS (CMK) · CloudWatch + SNS · WAF    │
│   Bedrock (Claude Sonnet 4, Haiku 4.5, Titan V2 embeddings, Cohere Rerank) │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘
                                  │
              Outbound from the VPC (only):
              · AWS service endpoints (via PrivateLink — no internet egress)
              · license.je-vectors.com  (daily heartbeat, HMAC-signed, no
                customer data — see Section 9 → Telemetry)

All AI inference runs inside your account via AWS Bedrock. No customer data is sent to external APIs or third-party services. Network ingress depends on the access option you choose at deployment time (see Section 4 → Access Options).

At-a-Glance Pre-Installation Checklist

Procurement and infrastructure leads can use this short checklist to scope the work before reading the full document. Each item maps to a section below; the detailed checklist with all items and decision points is in Section 3.

• AWS account — dedicated account or member account; commercial or GovCloud (§1)
• Bedrock model access — Claude Sonnet 4, Claude Haiku 4.5, Titan Embeddings V2, Cohere Rerank v3.5 (§3)
• Bedrock service quotas — raise per the Medium / Large table (§3)
• VPC + private subnets — across 2+ AZs (existing or to-be-created) (§4)
• DNS + ACM certificate — for the chosen Nquiry domain (§3)
• KMS CMK — identified (recommended for IL-4+) or AWS-managed keys accepted (§5)
• Installer IAM role — created with the required permissions (§6)
• CloudTrail — enabled at the org or account level (§2)
• Sizing tier — Small / Medium / Large selected (§7)
• Cross-account support-access role — opt-in decision made (§9)

---

1. AWS Account Requirements

Account Type

Deployment Path	Account Type	Use When
Commercial	Standard AWS account	IL-2 workloads, civilian agencies, corporate compliance
GovCloud	AWS GovCloud (US) account	IL-4/5 workloads, DOD, classified-adjacent requirements

AWS Organizations (Recommended)

If your organization uses AWS Organizations, the Nquiry account should be in a dedicated OU with Service Control Policies (SCPs) that:

• Restrict resource creation to the deployment region only (data residency)
• Prevent disabling of CloudTrail, GuardDuty, or Config
• Enforce encryption on all new resources

AWS Marketplace

Your account must be able to subscribe to AWS Marketplace products. Some organizations restrict Marketplace access via SCPs — verify with your cloud team before deployment.

---

2. AWS Service Requirements

The following services must be available in your deployment region. All are standard AWS services available in both commercial and GovCloud regions unless noted.

Compute & Networking

Service	Purpose	Min Configuration
ECS Fargate	Application runtime	0.5 vCPU / 1 GB (small), 1 vCPU / 2 GB (medium), 2 vCPU / 4 GB (large)
VPC	Network isolation	/16 CIDR, 2 AZs minimum
ALB	Load balancing	1 (internal or internet-facing)
VPC Endpoints	Private AWS service access	ECR, S3, Secrets Manager, KMS, Bedrock, CloudWatch Logs, STS
NAT Gateway	Not required	VPC endpoints eliminate internet egress

Data

Service	Purpose	Min Configuration
RDS PostgreSQL	Investigation data, vector search (pgvector)	PostgreSQL 15+, db.t3.medium (small), db.r6g.large (large)
ElastiCache Redis	Sessions, rate limiting, job queues	cache.t3.micro (small), cache.r6g.large (large)
S3	Evidence file storage, exports, archives	Standard + Glacier lifecycle

Security & Identity

Service	Purpose	Notes
Cognito	User authentication	User pool with email/password, optional MFA (TOTP, WebAuthn)
KMS	Encryption key management	Customer-managed CMK recommended (see Section 5)
Secrets Manager	Application secrets	Database password, Redis token, API keys
WAF	Web application firewall	Optional but recommended; Terraform template includes WAF rules
CloudTrail	API audit logging	Should already be enabled organization-wide

AI Services

Service	Purpose	Configuration Required
Bedrock — Claude Sonnet 4	Investigation analysis	Must request model access in Bedrock console
Bedrock — Claude Haiku 4.5	Quality evaluation, AI Guide	Must request model access in Bedrock console
Bedrock — Titan Text Embeddings V2	Evidence vector search	Must request model access in Bedrock console
Bedrock — Cohere Rerank v3.5	Search result reranking	Must request model access in Bedrock console
Bedrock Guardrails	Content safety filtering	Created by Terraform template

Monitoring

Service	Purpose	Notes
CloudWatch Logs	Application logging	30-day retention default (configurable)
CloudWatch Alarms	Infrastructure alerting	8 alarms created by template (CPU, memory, storage, latency, errors)
SNS	Alert delivery	Email notifications to your operations team

Recommended Complementary Services (not deployed by Nquiry)

These services are not provisioned by the Nquiry Terraform template, but are recommended for regulated workloads. Configure at the org or account level per your security baseline.

Service	Recommendation
AWS Config	Recommended for compliance audit narratives. Build a conformance pack scoped to Nquiry resources.
GuardDuty	Recommended in the Nquiry account for runtime threat detection on RDS, S3, and EKS/ECS.
Security Hub	Recommended for aggregated findings across CloudTrail / Config / GuardDuty.
AWS Backup	Optional. RDS automated snapshots are enabled by default; AWS Backup adds cross-account / cross-region copies if your DR plan requires them.

---

3. Pre-Deployment Checklist

Complete these steps before running the Terraform deployment:

AWS Bedrock Model Access (1–3 business days)

Bedrock models require explicit access requests. In the AWS Console → Bedrock → Model access:

1. Request access to Anthropic Claude Sonnet 4 (anthropic.claude-sonnet-4-20250514-v1:0)
2. Request access to Anthropic Claude Haiku 4.5 (anthropic.claude-haiku-4-5-20251001-v1:0)
3. Request access to Amazon Titan Text Embeddings V2 (amazon.titan-embed-text-v2:0)
4. Request access to Cohere Rerank v3.5 (cohere.rerank-v3-5:0)

Model access requests may take 1–3 business days. Do not proceed with deployment until all four models show "Access granted."

GovCloud note: Verify model availability in your target GovCloud region before requesting. Not all models are available in all GovCloud regions.

Bedrock Quota Increases (if needed)

Default Bedrock quotas may be insufficient for active usage. Review and request increases via AWS Service Quotas based on your deployment size. The numbers below are starting recommendations for steady-state usage; bursty workloads (e.g., bulk evidence ingest) may need temporary headroom above these.

Deployment Size	Claude Sonnet 4 RPM	Claude Sonnet 4 TPM	Titan Embeddings V2 TPM	Notes
Small (1–10 users)	Default usually OK	Default usually OK	Default usually OK	Monitor and raise reactively
Medium (10–50 users)	200	400,000	200,000	Request before go-live
Large (50+ users)	600	1,200,000	600,000	Request before go-live; revisit quarterly

Cohere Rerank v3.5 typically does not require a quota increase at the deployment sizes above; raise reactively if rerank latency degrades.

Other Service Quotas

Verify and (if needed) raise the following before deployment:

• VPC: Elastic IPs per region — at least 3 (NAT Gateway is not used in the default private-only deployment, but EIPs are still useful for any internet-facing ALB option and for diagnostic egress).
• RDS: DB instances per account — defaults are usually sufficient; verify ≥ 10 if the account hosts other workloads.

SSL Certificate

Provision an ACM certificate for your Nquiry domain (e.g., nquiry.youragency.gov) in the deployment region. The certificate must cover the domain used for the ALB (and CloudFront, if enabled).

DNS

You need a Route53 hosted zone (or ability to create CNAME records in your existing DNS) for the Nquiry domain.

Secrets

Prepare the following values before deployment:

Secret	Description
Database password	Strong password for RDS PostgreSQL (generated by you)
Redis auth token	16–128 character token for ElastiCache authentication
Alert email	Email address for CloudWatch alarm notifications

For SaaS-channel billing integration (if applicable): Stripe API keys. For licensed deployments without Stripe billing, these can be omitted.

Consolidated Pre-Flight Checklist

Your cloud team should be able to check off all of the following before running terraform apply:

• Dedicated AWS account or member account allocated (commercial or GovCloud)
• Deployment region selected
• Bedrock model access granted: Claude Sonnet 4, Claude Haiku 4.5, Titan Embeddings V2, Cohere Rerank v3.5
• Bedrock service quotas raised per the table above (medium and large deployments)
• VPC + private subnets identified or to-be-created across 2+ AZs
• DNS hosted zone or subdomain delegation in place for the chosen Nquiry domain
• ACM certificate issued (or import target identified) in the deployment region
• CloudTrail enabled at the org or account level
• KMS CMK identified (recommended for IL-4+) or default-key creation approved
• Installer IAM role created (see Section 6)
• Decision made on optional cross-account support-access role (see Section 9)
• Sizing tier selected (see Section 7)
• Egress firewall, if any, allow-list updated (see Section 4)
• Database password and Redis auth token generated
• Alert email distribution list identified

---

4. Network Architecture

Default: Private-Only Deployment

The Terraform template deploys all resources in private subnets with no internet egress. AWS service access uses VPC endpoints (PrivateLink):

Private Subnet A (AZ-1)          Private Subnet B (AZ-2)
┌─────────────────────┐          ┌─────────────────────┐
│ ECS Fargate tasks   │          │ ECS Fargate tasks   │
│ RDS primary         │          │ RDS standby (Multi-AZ)│
│ Redis primary       │          │ Redis replica        │
└─────────────────────┘          └─────────────────────┘
         │                                │
         └──────────┬─────────────────────┘
                    │
            VPC Endpoints
    ┌───────────────┼───────────────┐
    │   ECR    S3   KMS  Bedrock    │
    │   STS    SM   CWL  (etc.)    │
    └───────────────────────────────┘

No NAT gateway is required. All AWS service communication goes through VPC endpoints, eliminating internet exposure entirely.

Access Options

Option	Configuration	Best For
Internal ALB + VPN	ALB in private subnets, users access via agency VPN or Direct Connect	Maximum security, no internet exposure
Internal ALB + reverse proxy	ALB in private subnets, customer routes through existing internet-facing proxy/WAF	Agencies with existing perimeter infrastructure
Internet-facing ALB + WAF	ALB in public subnets with WAF rules	Lower-security environments, quick deployment

The access model is a Terraform parameter — choose at deployment time.

VPC Endpoints Required

The template creates these VPC endpoints automatically:

• com.amazonaws.{region}.ecr.api and com.amazonaws.{region}.ecr.dkr (container image pull)
• com.amazonaws.{region}.s3 (gateway endpoint for evidence storage)
• com.amazonaws.{region}.secretsmanager (application secrets)
• com.amazonaws.{region}.kms (encryption key operations)
• com.amazonaws.{region}.bedrock-runtime (AI inference)
• com.amazonaws.{region}.logs (CloudWatch Logs)
• com.amazonaws.{region}.sts (IAM token service)

Cost note: Interface endpoints (PrivateLink) incur hourly charges (~$0.01/hour per endpoint per AZ). With 6 interface endpoints across 2 AZs, expect ~$90/month for VPC endpoints.

Egress Allow-List (if you run an egress firewall)

The default private-only deployment routes all AWS service traffic through VPC endpoints and requires no internet egress. If you run an egress firewall on the VPC (or are using one of the access options that retains some internet path), allow these destinations:

Destination	Purpose
*.amazonaws.com	AWS service endpoints (control plane fallbacks, ECR pulls if not VPC-endpointed)
*.bedrock-runtime.<region>.amazonaws.com	Bedrock model invocation (data plane)
license.je-vectors.com	License-validity heartbeat (HTTPS, daily; see Section 9 → Telemetry)

No other outbound destinations are required by Nquiry. If your environment uses signed grace tokens for periodic-disconnect operations (Section 9), the heartbeat host above can also be blocked for the duration of the grace window.

---

5. Encryption Requirements

Encryption at Rest

Resource	Encryption	Key Management
RDS PostgreSQL	AES-256 via KMS	Customer-managed CMK (recommended) or AWS-managed key
S3 evidence storage	SSE-KMS	Customer-managed CMK (recommended) or AWS-managed key
ElastiCache Redis	At-rest encryption enabled	AWS-managed key
ECS ephemeral storage	Encrypted by default	AWS-managed

Customer-managed CMK: The Terraform template accepts a kms_key_arn parameter. If provided, RDS and S3 use your CMK for encryption. This gives your organization full control over key rotation, access policies, and key deletion. Recommended for IL-4+ deployments.

AWS-managed keys: If kms_key_arn is omitted, AWS-managed keys are used. These are FIPS 140-3 compliant and sufficient for IL-2 deployments.

Encryption in Transit

• TLS 1.2+ enforced on all connections (ALB, RDS, Redis, S3, Bedrock)
• The application enforces HTTPS — HTTP requests are redirected
• Internal service communication (ECS → RDS, ECS → Redis) uses TLS

Key Rotation

• AWS KMS supports automatic annual key rotation for customer-managed CMKs
• Enable key rotation at CMK creation (Terraform template enables this by default)

---

6. IAM Requirements

The Terraform template creates all necessary IAM roles and policies. Your account needs permission to create:

• ECS task execution role (pulls container image, reads secrets)
• ECS task role (accesses S3, Bedrock, Cognito, KMS)
• CloudWatch logging role
• Service-linked roles for ECS, RDS, ElastiCache (auto-created by AWS)

Minimum IAM Permissions for Deployment

The user or role running terraform apply needs these permissions:

• ecs:*, ecr:* — Compute management
• rds:* — Database provisioning
• elasticache:* — Cache provisioning
• ec2:* (VPC, subnets, security groups, VPC endpoints)
• s3:* — Storage provisioning
• cognito-idp:* — Authentication setup
• kms:* — Encryption key management
• secretsmanager:* — Secrets provisioning
• elasticloadbalancingv2:* — Load balancer setup
• logs:*, cloudwatch:*, sns:* — Monitoring
• wafv2:* — WAF rules (if enabled)
• bedrock:* — Guardrails creation
• iam:* — Role and policy creation
• cloudfront:* — CDN (if enabled)
• route53:* — DNS records

For organizations with strict IAM policies, JE Vectors can provide a narrower IAM policy document scoped to the exact resources created.

AWS Managed Policies (Alternative)

If your team prefers attaching AWS managed policies instead of a custom action list, the following set is equivalent for the installer role. IAMFullAccess is needed only during the first install (Terraform creates the runtime task roles); strongly recommended to revoke afterward.

• AmazonECS_FullAccess
• AmazonRDSFullAccess
• AmazonElastiCacheFullAccess
• AmazonS3FullAccess (can be scoped to bucket prefixes after first install)
• CloudFrontFullAccess
• AWSWAFFullAccess
• AWSCertificateManagerFullAccess
• AmazonRoute53FullAccess
• AWSKeyManagementServicePowerUser
• AmazonSSMFullAccess (Parameter Store)
• SecretsManagerReadWrite
• IAMFullAccess (install only — revoke after)
• CloudWatchFullAccess
• AWSCloudTrail_FullAccess
• AmazonBedrockFullAccess

Runtime IAM (created by Terraform, not customer-provided): ECS task execution role, ECS task role, RDS monitoring role, Lambda execution roles for periodic jobs.

Optional Cross-Account Support-Access Role

See Section 9 → Support for the opt-in, default-off cross-account support role used to accelerate JE Vectors support cases.

---

7. Sizing Guide

Small Deployment (1–10 users)

Typical for small OIG offices, agency EEO offices, specialized compliance teams.

Resource	Configuration	Est. Monthly Cost
ECS Fargate	0.5 vCPU, 1 GB, 1 task	~$15
RDS PostgreSQL	db.t3.medium, 50 GB, Single-AZ	~$55
ElastiCache Redis	cache.t3.micro, Single-AZ	~$15
S3	Standard, <50 GB	~$2
ALB	1 ALB	~$25
VPC Endpoints	6 interfaces × 2 AZs	~$90
CloudWatch	Logs + 8 alarms	~$15
Bedrock	~500K tokens/day	~$50
Total		~$270/month

Medium Deployment (10–50 users)

Typical for mid-size OIGs, regional compliance operations, DOD component offices.

Resource	Configuration	Est. Monthly Cost
ECS Fargate	1 vCPU, 2 GB, 2 tasks (multi-AZ)	~$60
RDS PostgreSQL	db.r6g.large, 100 GB, Multi-AZ	~$250
ElastiCache Redis	cache.r6g.large, Multi-AZ	~$200
S3	Standard + Glacier lifecycle, <200 GB	~$8
ALB	1 ALB	~$30
VPC Endpoints	6 interfaces × 2 AZs	~$90
CloudWatch	Logs + 8 alarms + dashboard	~$25
Bedrock	~2M tokens/day	~$150
Total		~$815/month

Large Deployment (50+ users)

Typical for VA enterprise, DOD enterprise, DHS, HHS/CMS.

Resource	Configuration	Est. Monthly Cost
ECS Fargate	2 vCPU, 4 GB, 4 tasks (multi-AZ)	~$240
RDS PostgreSQL	db.r6g.xlarge, 500 GB, Multi-AZ	~$550
ElastiCache Redis	cache.r6g.xlarge, Multi-AZ	~$400
S3	Standard + Glacier, <1 TB	~$25
ALB	1 ALB	~$40
VPC Endpoints	6 interfaces × 2 AZs	~$90
CloudWatch	Full observability stack	~$50
Bedrock	~10M tokens/day	~$500
Total		~$1,895/month

Estimates based on us-east-1 pricing as of April 2026. GovCloud pricing is typically 10–20% higher. Actual Bedrock costs depend on usage patterns.

---

8. Deployment Process

Step 1: Pre-Flight (1–2 weeks)

1. Provision AWS account (or identify existing)
2. Subscribe to Nquiry on AWS Marketplace
3. Request Bedrock model access (all 4 models)
4. Provision ACM certificate for your domain
5. Prepare secrets (database password, Redis token)
6. Review sizing guide and select configuration

Step 2: Deploy (1–2 hours)

1. JE Vectors provides the Terraform template and a terraform.tfvars file customized for your environment
2. Review the template (all infrastructure is defined as code — fully auditable)
3. Run terraform init and terraform plan — review the plan
4. Run terraform apply — creates all resources
5. Run database migrations: npm run db:migrate (via ECS exec or bastion)
6. Verify: access the health endpoint at your domain

Step 3: Configure (30 minutes)

1. Create the first admin user via Cognito console
2. Log in and verify the application
3. Configure CloudWatch alarm notifications (SNS topic → your email/PagerDuty)
4. (Optional) Configure SSO integration via Cognito federation

Step 4: Validate

1. Create a test investigation
2. Upload sample evidence files
3. Run an analysis — verify Bedrock connectivity and AI output
4. Verify CloudWatch logs are flowing
5. Verify encryption (check RDS and S3 encryption settings in console)

---

9. Ongoing Operations

Updates

Updates to Nquiry are customer-initiated. JE Vectors publishes new container image versions and Terraform template versions to AWS Marketplace; your operations team chooses when to apply them. Updates never touch your environment without action from your side.

Release model

• Minor releases (e.g., 1.2.0 → 1.3.0) — monthly cadence. New features, non-breaking schema changes. Safe to apply during a standard maintenance window.
• Patch releases (e.g., 1.2.0 → 1.2.1) — ad hoc. Bug fixes, security patches. No schema changes. Typically applied within 24–72 hours for security patches.
• Major releases (e.g., 1.x → 2.0) — quarterly at most. May include breaking schema changes that require a two-step upgrade (see below). Advance notice minimum 60 days with a migration runbook.

JE Vectors supports the current major version and the two prior minor releases (N, N-1, N-2). Customers more than two minor versions behind must upgrade incrementally — the migration path is verified only across supported versions.

Zero-downtime update path (minor and patch releases)

Minor and patch releases are designed to deploy with no service interruption. The application runs on ECS Fargate behind an ALB with rolling deploys (deployment_minimum_healthy_percent = 100, deployment_maximum_percent = 200). During an update, ECS launches new tasks on the new image, waits for ALB health checks to pass, shifts traffic, then drains and terminates the old tasks. In-flight requests on old tasks complete normally (30s connection drain).

Database schema changes in minor/patch releases follow an expand/contract pattern — the schema is always backward-compatible with the prior release. You can apply the migration before, during, or after the app deploy without a coordination window. This is the same discipline JE Vectors uses for our own production deployments.

Steps for a minor or patch update:

1. Review the release notes (published with each version on AWS Marketplace and the JE Vectors customer portal).
2. Pull the new image tag: listed in release notes, referenced as image_version in your terraform.tfvars.
3. If the release notes include schema changes: run npm run db:migrate against RDS via the bastion (or the customer environment's equivalent). The migration is forward-compatible — the running application will not break.
4. Update image_version in terraform.tfvars and run terraform apply. ECS executes the rolling deploy automatically.
5. Verify: check the health endpoint and CloudWatch alarms for five minutes post-deploy.

Total user-visible impact: none. Total admin time: 15–30 minutes including verification.

Maintenance-window update path (major releases)

Major releases may include schema changes that are not backward-compatible in a single step (e.g., column drops, table restructuring). JE Vectors ships these as a guided two-release upgrade — release N adds the new schema alongside the old and starts reading from the new; release N+1 drops the old. Both releases individually deploy with zero downtime using the same ECS rolling pattern. The release notes for release N identify any operations to run in a low-traffic window, if applicable.

Some organizations prefer a planned maintenance window even for minor releases — for change-control reasons or to coordinate with downstream dependent systems. That is fully supported: you may schedule updates in a window of your choosing.

Rollback

If an update introduces an issue, rollback is immediate:

• Application rollback (~3 minutes): update image_version in terraform.tfvars to the previous value and run terraform apply. ECS rolls back to the previous task definition.
• Schema rollback: every migration ships with a paired .down.sql. Run the down migration against RDS before rolling back the application if the release included schema changes. Down migrations are verified by JE Vectors before release.

The Terraform template retains the ability to pin to any prior image version listed on Marketplace for 12 months. If you need to pin to an older version than that, contact support.

Scheduling notifications

You can configure update notifications in the JE Vectors customer portal — immediate alerts for patch/security releases, advance notice for minor releases, and 60-day notice for major releases. Notifications go to the email(s) you provide.

Monitoring

The Terraform template configures 8 CloudWatch alarms out of the box:

• ECS: CPU high, memory high, unhealthy host
• RDS: CPU high, storage low, connections high
• ALB: 5xx error rate, latency p95

All alarms send to the SNS topic configured during deployment.

Backup

• RDS: Automated daily snapshots (7-day retention, configurable)
• S3: Versioning enabled, lifecycle policy archives to Glacier after 90 days
• Redis: Not backed up (ephemeral cache; session data is regenerated)

Telemetry

At GA, Nquiry licensed installs phone home only for a license-validity heartbeat. The heartbeat sends:

• License key (HMAC-signed)
• Install ID (UUID generated at first install)
• Timestamp
• Nquiry application version

The heartbeat does not include any customer data, evidence content, user information, query content, organization metadata, or operational telemetry (errors, performance, usage). Heartbeat traffic is HTTPS to license.je-vectors.com and is the only outbound network call from the licensed installation other than AWS service endpoints.

Default cadence: daily. Grace window: 30-day cached grace — if license validation cannot reach JE Vectors for any reason (network outage, DNS issue, our service degradation), the install continues operating normally on the cached license for 30 days. After 30 days without successful validation, the install enters a degraded mode that admins are notified of; full read-only mode after 60 days. No customer data is ever locked or destroyed by license expiry.

Post-GA roadmap: opt-in error/usage telemetry (aggregated, no customer data) for customers who want JE Vectors to monitor their install proactively. This will require explicit customer opt-in.

Periodic-disconnect operations

Some operating contexts require the install to function without outbound network access for extended periods — maintenance windows, classified-mode operations, disconnect drills. JE Vectors supports these via signed grace tokens.

On request (with reasonable advance notice), JE Vectors issues a signed 90-day grace token bound to your specific install_id and license_id. The install consumes the token and operates normally without phone-home for the duration. Multiple grace tokens can be stacked across consecutive 90-day windows; each issuance is logged on JE Vectors' side for audit purposes.

Customer-facing summary: Nquiry licensed installs typically phone home daily for license validation. For periodic-disconnect operations, we issue signed 90-day grace tokens on request. Fully disconnected (no outbound, indefinite) deployments are on our post-GA roadmap; contact us to discuss your timeline.

Fully disconnected / air-gapped deployments (zero outbound traffic, indefinite operation) are post-GA roadmap with no committed date. Customers with this requirement should contact JE Vectors to discuss timeline and engineering investment.

Support

Licensed deployments include annual maintenance/support. Contact JE Vectors for:

• Deployment assistance and configuration review
• Incident response and troubleshooting
• Version upgrades and migration guidance
• Architecture consultation for scaling

Cross-account support-access role (opt-in, recommended). To accelerate support cases, your team can optionally provision a read-only cross-account IAM role granting JE Vectors describe-only access to CloudWatch Logs, ECS, and RDS. The role is opt-in — the default deployment does not include it.

When provisioned, the trust policy uses an external_id your team chooses, and your team can revoke access at any time without notice. The role's permissions are limited to read-only describe operations; the role does not grant the ability to mutate resources, read database contents, or read S3 evidence storage.

Without the support-access role, support cases proceed via customer-shared logs and screen-sharing sessions — equivalent in capability but slower in time-to-resolution. The Terraform template includes an optional support_access_role module disabled by default; enabling requires setting enable_support_access_role = true and providing the trusted external_id.

---

10. Frequently Asked Questions

Q: Does Nquiry need internet access? No. The default deployment uses VPC endpoints for all AWS service access. No internet egress is required.

Q: Can we use our existing VPC? Yes. The Terraform template can deploy into an existing VPC if you provide subnet IDs. Contact JE Vectors for a custom configuration.

Q: What happens if Bedrock is unavailable? AI analysis features are unavailable during a Bedrock outage. All other application features (evidence management, reporting, collaboration) continue to work. Nquiry displays a clear error message if AI analysis cannot be completed.

Q: Can we restrict which AI models are used? Yes. The Bedrock model IDs are Terraform parameters. You can pin to specific model versions or restrict to models approved by your organization.

Q: Is data shared between customers? No. Each licensed deployment is a completely isolated stack. There is no shared infrastructure, no shared database, and no network connectivity between customer deployments.

Q: Can we audit the infrastructure? Yes. All infrastructure is defined in Terraform — every resource, permission, and configuration is visible in the template. CloudTrail logs all API activity. Audit logs record all application-level state changes.