Document History

How to Use This Document

This guide is the authoritative reference for deploying, operating, and maintaining the CHAI platform on AWS. It is designed to be self-sufficient — no additional infrastructure documentation is required.

For end-user workflows (running assessments, triggering transformations, managing projects), refer to the CHAI User Guide.

1. Executive Summary

CHAI™ (Context Rich Harness) is CloudHedge's flagship AI-powered modernization platform, purpose-built to accelerate enterprise application migration to AWS at scale. Deployed as a self-contained appliance on Amazon EC2, CHAI orchestrates 17 containerized microservices — coordinating AI-driven discovery, deep application assessment, code transformation, and cloud infrastructure provisioning — all within a single hardened deployment unit. This document provides the authoritative infrastructure and deployment reference for the CHAI platform as deployed in support of enterprise workloads, covering AWS architecture, high availability, disaster recovery, external integrations, and alignment with the EU Digital Operational Resilience Act (DORA).

The CHAI appliance runs on RHEL 8.10 or Amazon Linux 2023, uses Podman for rootless container orchestration, and persists all stateful data — including MongoDB 7.0.12 document storage — to Amazon EFS for decoupled, multi-AZ durability. The platform integrates natively with AWS Bedrock (Claude, Titan, Llama), AWS Transform, Bitbucket, GitHub, Jenkins, and all major container registries. The current production release is ch-rel-2.1.6-13 (February 25, 2026), distributed via AWS Marketplace and the CloudHedge ECR registry at 720029083713.dkr.ecr.us-east-1.amazonaws.com.

This document is DORA-aligned per EU Regulation 2022/2554. It addresses ICT risk management, operational resilience testing, cross-region disaster recovery (RTO < 30 minutes, RPO < 1 hour), incident classification and reporting, third-party risk through SBOM management, and IAM least-privilege access control. All operational teams — infrastructure engineers, security architects, application owners, and compliance officers — will find actionable reference material in the sections that follow.

Companion Document: For end-user workflows — running DART assessments, configuring transformation pipelines, managing projects and tenants, and using AI-powered recommendations — see the CHAI User Guide.

Operational Responsibility Matrix

For support engagement, incident escalation, and SLA terms, refer to the applicable CloudHedge Enterprise Support Agreement.

2. Infrastructure Overview

2.1 Deployment Architecture

CHAI™ supports three primary deployment topologies, each suited to different organizational requirements for scalability, cost, and operational complexity. All three topologies use the same AMI, the same microservice configuration, and the same EFS-backed persistent storage — ensuring consistency across environments.

The recommended standard deployment uses the Single EC2 with ALB and ASG model, with EFS providing persistent multi-AZ storage durability and daily AMI snapshots enabling rapid instance replacement with no data loss.

Choosing a Deployment Topology: Most organizations start with the Single EC2 model for its simplicity and lowest cost, then upgrade to Multi-AZ Active-Standby when production SLAs require automated failover. The Blue/Green model is recommended for organizations with mature CI/CD pipelines that require zero-downtime deployments. All three topologies use the same AMI, the same microservice configuration, and the same EFS-backed storage — upgrading between topologies requires no application changes.

2.2 AWS Services Used

2.3 Compute & Storage Specifications

3. Microservices Architecture

3.1 Service Inventory & Ports

CHAI™ is composed of 17 containerized microservices plus MongoDB, all orchestrated by Podman and managed via the chctl appliance lifecycle tool. Each service runs on the cloudhedge Podman network (10.90.0.0/16, IPv6 fd00:db8:2::/64) and communicates via internal service discovery. Only webapp is exposed through the ALB.

For details on how each microservice is used during assessment, discovery, and transformation workflows, see the CHAI User Guide — Platform Overview.

3.2 Container Registry & Image Naming

All CHAI microservice images are distributed via the CloudHedge AWS ECR registry. Images follow a consistent naming and tagging convention to enable precise version pinning, rollback, and audit.

Example image references:

ECR Authentication:

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

All images are scanned for vulnerabilities at push time via ECR enhanced scanning (Inspector). Lifecycle policies retain the last 10 release tags per repository and expire untagged images after 14 days.

4. Networking & Connectivity

4.1 VPC & Subnet Design

Internal Communication Security: All 17 CHAI microservices communicate over the cloudhedge Podman network (10.90.0.0/16), which is isolated to the EC2 instance. Inter-service traffic does not traverse the VPC network or the internet. External traffic enters only via the ALB (HTTPS :443) and exits only via VPC Endpoints (PrivateLink) or NAT Gateway for explicitly configured integrations.

4.2 Security Groups & Port Matrix

4.3 Data Flow Diagram

4.4 Network Connectivity Map

5. High Availability Deployment Architecture

5.1 HA Architecture Overview

CHAI™ achieves high availability through a combination of ALB health checks, ASG auto-recovery, and EFS-decoupled persistent storage. Because all stateful data resides on Amazon EFS rather than the EC2 instance's local EBS volume, a replacement instance launched by the ASG immediately mounts the same data — eliminating recovery time associated with data reconstruction. The following configuration steps establish the core HA posture:

1. Create the VPC with public subnets in three Availability Zones for ALB placement, and private subnets in three AZs for EC2 and EFS mount targets.
2. Deploy Amazon EFS with mount targets in each private subnet AZ. Enable encryption at rest. Configure inbound NFS (:2049) from the EC2 security group.
3. Launch the CHAI EC2 instance from the marketplace AMI in the private subnet. Mount EFS at /mnt/efs via /etc/fstab. Migrate all stateful data to EFS paths.
4. Create a golden AMI from the configured and validated EC2 instance. This AMI includes the updated chctl-compose.yaml with EFS volume paths, the Podman configuration, and the CHAI software stack.
5. Create a Launch Template referencing the golden AMI, the EC2 security group, the IAM instance profile, and the chctl-compose.yaml user data script that starts the appliance on boot.
6. Create an Auto Scaling Group using the Launch Template. Set Desired: 1, Min: 1, Max: 1. Associate with the private subnet. Configure EC2 health check type with a 300-second grace period.
7. Create an Application Load Balancer in the public subnets. Add an HTTPS :443 listener with an ACM certificate. Create a Target Group pointing to :8080 with a health check on GET /api/health. Register the EC2 instance.
8. Configure DNS (Route 53 or customer DNS) to point the CHAI hostname to the ALB DNS name.
9. Validate HA by terminating the EC2 instance and confirming the ASG launches a replacement that mounts EFS and starts CHAI services within the defined recovery window.

5.2 HA Architecture Diagram

5.3 EFS Persistent Storage

Amazon EFS is the foundation of CHAI's data durability strategy. By decoupling all stateful data from the EC2 instance lifecycle, EFS enables rapid instance replacement without data loss, supports the DR replication model, and ensures that both primary and standby instances always operate on the same data set.

5.4 EFS /etc/fstab Configuration

The following /etc/fstab entry mounts the Amazon EFS file system automatically on instance boot, ensuring CHAI services have access to persistent data before the appliance starts.

# /etc/fstab — Amazon EFS mount for CHAI persistent storage
# Replace <EFS_FILE_SYSTEM_ID> with your actual EFS ID (e.g., fs-0a1b2c3d4e5f6789a)
<EFS_FILE_SYSTEM_ID>.efs.us-east-1.amazonaws.com:/ /mnt/efs efs \
  _netdev,tls,iam,noresvport,nofail,\
  retrans=2,rsize=1048576,wsize=1048576,\
  hard,timeo=600 0 0

Manual mount command (for initial setup or troubleshooting):

sudo mount -t efs -o tls,iam <EFS_FILE_SYSTEM_ID>:/ /mnt/efs

Create required subdirectories after first mount:

sudo mkdir -p /mnt/efs/mongodb/data/db
sudo mkdir -p /mnt/efs/shared
sudo mkdir -p /mnt/efs/nginx/ssl
sudo chown -R 1000:1000 /mnt/efs/mongodb /mnt/efs/shared /mnt/efs/nginx

6. Disaster Recovery

6.1 Cross-Region DR Architecture

CHAI™ implements a cross-region warm-standby disaster recovery architecture with a primary deployment in us-east-1 and a standby deployment in us-west-1. EFS continuous replication keeps the DR data store synchronized in near-real-time. Daily AMI snapshots are copied to the DR region to ensure a consistent, bootable instance is always available. Under normal operations, the DR EC2 instance remains stopped to minimize cost. On DR activation, the instance starts, mounts the now-writable DR EFS (replication must be deleted before the DR EFS becomes writable), and services resume within the RTO window.

6.2 RTO/RPO Table

6.3 DR Activation Procedure

The following 9-step procedure is executed by the CloudHedge on-call operations team or designated customer infrastructure team upon confirmation that the primary us-east-1 deployment is unavailable and cannot be recovered within the established RTO window.

1. Declare DR Event. Notify the DR response team via the incident communication channel. Confirm that primary region failure is not a transient AWS issue resolvable within 30 minutes. Reference the incident severity matrix in Section 10.2 to confirm P1 threshold is met.

2. Navigate to EFS in us-east-1. In the AWS Console, navigate to EFS → chai-appliance-data-prod → Replication tab. Confirm the replication status shows the DR region EFS ID and current lag.

3. Delete EFS Replication. Click "Delete replication" on the primary EFS. This action disables the replication relationship and transitions the DR EFS (chai-dr-data in us-west-1) from READ-ONLY to READ-WRITE. Wait approximately 5 minutes for the state transition to complete.

4. Confirm DR EFS is Writable. In the AWS Console, navigate to EFS in us-west-1. Confirm the chai-dr-data file system shows state = Available and replication role = None (no longer a replica).

5. Start DR EC2 Instance. Navigate to EC2 in us-west-1. Locate the instance tagged CHAI-appliance-DR. Start the instance. Wait for instance state = Running and health checks = 2/2 passed.

6. SSH into DR EC2 and Mount EFS. Connect to the DR EC2 instance. Update /etc/fstab to reference the DR EFS file system ID (chai-dr-data ID). Execute sudo mount -a to mount the DR EFS at /mnt/efs. Confirm with df -h | grep efs.

7. Start CHAI Services. Execute sudo chctl start appliance. Monitor startup with sudo chctl status. All 17 microservices should reach running state within 5–8 minutes. If any service fails to start, inspect logs with podman logs <service-name>.

8. Validate Application Availability. Open the CHAI web UI at the DR ALB DNS name. Confirm login is functional. Run a test discovery or assessment job to validate end-to-end service health.

9. Update DNS. Update the Route 53 failover record (or customer DNS) to point the CHAI hostname to the DR ALB endpoint. Notify customer operations team and end users of the temporary DR URL if DNS propagation will take > 5 minutes. Document the event in the DORA incident log.

6.4 DR Activation Flowchart

7. Data Migration & Transfer

7.1 Critical Data Inventory

7.2 Migration Architecture

7.3 Step-by-Step Migration Procedure

The following procedure migrates an existing CHAI deployment to an EFS-backed architecture, or transfers data from one instance to a new deployment. Execute all steps as root or with sudo.

1. Stop the CHAI appliance on the source instance. This ensures MongoDB performs a clean shutdown and all write-ahead logs are flushed before copying data.
   
   

   Copy

      sudo chctl stop appliance
      sudo chctl status  # Confirm all services are stopped
      

2. Create and mount the EFS file system. In the AWS Console, create an EFS file system in the same VPC. Create mount targets in each private subnet. On the source (or new target) EC2 instance, install the EFS mount helper and mount:
   
   

   Copy

      sudo yum install -y amazon-efs-utils   # RHEL/AL2023
      sudo mkdir -p /mnt/efs
      sudo mount -t efs -o tls,iam <EFS_ID>:/ /mnt/efs
      

3. Create the required EFS directory structure.
   
   

   Copy

      sudo mkdir -p /mnt/efs/mongodb/data/db
      sudo mkdir -p /mnt/efs/shared
      sudo mkdir -p /mnt/efs/nginx/ssl
      sudo chown -R 1000:1000 /mnt/efs/mongodb /mnt/efs/shared /mnt/efs/nginx
      

4. Copy MongoDB data to EFS. This is the most time-consuming step for large databases. Use rsync for resume capability:
   
   

   Copy

      sudo rsync -avz --progress \
        /opt/appliance/mongodb/data/db/ \
        /mnt/efs/mongodb/data/db/
      

5. Copy shared application files to EFS.
   
   

   Copy

      sudo rsync -avz --progress \
        /opt/appliance/shared/ \
        /mnt/efs/shared/
      

6. Copy Nginx configuration and TLS certificates.
   
   

   Copy

      sudo cp /opt/appliance/nginx/nginx.conf /mnt/efs/nginx/nginx.conf
      sudo cp /opt/appliance/nginx/ssl/server.key /mnt/efs/nginx/ssl/server.key
      sudo cp /opt/appliance/nginx/ssl/server.crt /mnt/efs/nginx/ssl/server.crt
      

7. Update chctl-compose.yaml volume paths. Edit the appliance manifest to replace all local /opt/appliance/ volume references with /mnt/efs/ paths. The critical paths are the MongoDB data directory and the shared files directory. Copy the updated manifest to EFS:
   
   

   Copy

      sudo cp /opt/appliance/chctl-compose.yaml /mnt/efs/shared/chctl-compose.yaml
      

8. Add EFS to /etc/fstab for persistent mounting. Add the fstab entry from Section 5.4 to ensure EFS mounts automatically on every reboot before the CHAI appliance service starts.

9. Start the CHAI appliance and validate. Start services and confirm all 17 microservices are running correctly, MongoDB is reading data from the EFS-backed path, and the web UI is accessible:
   
   

   Copy

      sudo chctl start appliance
      sudo chctl status
      # Open web UI and confirm login and data integrity
      

7.4 Amazon Linux 2023 Deployment Notes

CHAI supports both RHEL 8.10 and Amazon Linux 2023 as host operating systems. Organizations may choose either based on their OS standardization policy, licensing model, and AWS optimization preferences. The following notes document the key differences between the two platforms that affect CHAI deployment and operations.

8. External System Integrations

8.1 Integration Overview Diagram

This section covers infrastructure-level connectivity and credentials setup. For step-by-step instructions on connecting repositories and running discovery from the CHAI web UI, see the CHAI User Guide.

8.2 Source Code Repository Connectivity Table

8.3 Bitbucket Server Configuration (Reference Example)

The following walkthrough uses Bitbucket Server as a reference example. CHAI supports all repository systems listed in Section 8.2 — including GitHub, GitLab, Azure DevOps, CodeCommit, and generic Git over SSH. The configuration steps (create service account → generate token → store in CHAI vault → test connection) follow the same pattern for all platforms. For platform-specific setup instructions, see the CHAI User Guide.

8.4 CI/CD Integration Table

8.5 Build Box Connectivity Table

9. AWS AI Services Integration

9.1 AWS Bedrock Connectivity

CHAI™ leverages AWS Bedrock as the primary AI inference layer for all large language model operations — including application assessment, code transformation, architecture recommendation, and natural language report generation. Bedrock is accessed via a VPC PrivateLink endpoint, ensuring all model traffic remains within the AWS network and never traverses the public internet. The core-engine and cruize-service microservices are the primary Bedrock consumers; cruize-service handles complex multi-step AI orchestration workflows using chained model invocations.

9.2 Foundation Models Table

Model Selection Flexibility: CHAI does not require a specific foundation model. Organizations can enable any combination of the models listed above based on their performance, cost, and data-residency requirements. Model selection is configurable per CHAI project — different teams can use different models within the same deployment. For model selection guidance, see the CHAI User Guide.

9.3 Bedrock VPC Endpoint Setup

9.4 AWS Transform

AWS Transform provides additional automated code modernization capabilities that CHAI integrates with for .NET and Java legacy code conversion. CHAI's transform-service-linux and transform-service-windows microservices can invoke AWS Transform jobs as part of the CHAI Flow™ orchestration pipeline, enabling hybrid AI-powered transformation where CHAI handles assessment and workflow orchestration while AWS Transform executes specific language upgrade tasks.

Connectivity: HTTPS :443 to transform.us-east-1.amazonaws.com. No VPC endpoint required; outbound via NAT Gateway or dedicated VPC endpoint.

IAM Permissions Required for AWS Transform:

9.5 Model Usage Guidance

For guidance on how AI models are used within CHAI assessment and transformation workflows — including prompt strategies, output review, and confidence scoring — see the CHAI User Guide.

10. Security & DORA Compliance

The European Union's Digital Operational Resilience Act (DORA), established under Regulation (EU) 2022/2554, mandates that financial entities and their critical ICT third-party service providers demonstrate structured, measurable operational resilience. DORA is organized around five pillars: (1) ICT Risk Management — continuous identification, classification, and mitigation of technology risks; (2) ICT-Related Incident Reporting — structured classification, internal escalation, and regulatory notification of significant ICT incidents; (3) Digital Operational Resilience Testing — periodic testing of business continuity, disaster recovery, and threat-led penetration testing (TLPT) for systemically important entities; (4) ICT Third-Party Risk Management — due diligence, contractual obligations, and ongoing monitoring of technology vendors; and (5) Information and Intelligence Sharing — participation in industry threat intelligence sharing arrangements. CHAI's infrastructure architecture, operational procedures, and security controls have been designed to support the licensee's compliance obligations under each of these five pillars.

10.1 DORA Compliance Matrix

10.2 Incident Severity Matrix

10.3 SBOM Management

CloudHedge maintains a published Software Bill of Materials (SBOM) for every CHAI release. The SBOM documents all first-party and third-party software components and their versions. Image scanning is performed automatically on every ECR image push via AWS Inspector Enhanced Scanning, and a full SBOM report is generated with each release. Customers may request the SBOM for any release from their CloudHedge account team.

SBOM Technology Stacks:

10.4 IAM Policy Reference

The following IAM policy represents the minimum permissions required for the CHAI EC2 instance role. This policy follows the principle of least privilege and should be attached to an IAM role assigned to the CHAI EC2 instance profile. No inline policies, wildcard accounts, or administrative permissions should be granted.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EFSAccess",
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite",
        "elasticfilesystem:ClientRootAccess"
      ],
      "Resource": "arn:aws:elasticfilesystem:us-east-1:<ACCOUNT_ID>:file-system/<EFS_ID>"
    },
    {
      "Sid": "SSMParameterAccess",
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter",
        "ssm:GetParameters",
        "ssm:GetParametersByPath"
      ],
      "Resource": "arn:aws:ssm:us-east-1:<ACCOUNT_ID>:parameter/chai/*"
    },
    {
      "Sid": "ECRAccess",
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchCheckLayerAvailability"
      ],
      "Resource": "*"
    },
    {
      "Sid": "BedrockAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-6",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-opus-4-6",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-haiku-4-5-20251001",
        "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-text-express-v1",
        "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0",
        "arn:aws:bedrock:us-east-1::foundation-model/meta.llama3-70b-instruct-v1:0"
      ]
    },
    {
      "Sid": "CloudWatchMetricsAndLogs",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricData",
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": "*"
    }
  ]
}

10.5 Access Control Matrix

11. Operational Runbook

This section covers infrastructure operations (start, stop, upgrade, backup, monitor). For application-level operations — managing users, tenants, projects, and running assessments — see the CHAI User Guide.

11.1 Appliance Lifecycle Commands

All CHAI appliance lifecycle operations are performed using the chctl command-line tool, which abstracts Podman orchestration into human-readable, atomic operations. chctl must be run as root or with sudo.

First-Time Deployment? After starting the appliance for the first time, access the CHAI web UI at https://<alb-hostname> to complete initial setup: create the first admin user, activate the license key, and configure your first project. See the CHAI User Guide — Getting Started for the step-by-step setup wizard walkthrough.
| sudo chctl stop appliance | Gracefully stop all 17 services in reverse dependency order (MongoDB last) | Before taking an AMI snapshot; before data migration; planned maintenance | All services transition to stopped state; MongoDB performs clean shutdown |
| sudo chctl restart appliance | Stop then start all 17 services | After updating chctl-compose.yaml; after a configuration change affecting multiple services | Full restart cycle; expect ~10 minutes total |
| sudo chctl restart <service> | Restart a single named service (e.g., core-engine) | After a single service crash; after updating a single service's environment variable | Named service restarts without affecting other services |
| sudo chctl status | Display running state of all 17 services | Health verification; post-startup validation; troubleshooting | Table showing service name, container ID, state, port, uptime |
| sudo chctl status <service> | Display detailed status of a single named service | Deep troubleshooting of a specific service | Container metadata, environment variables, mount points, recent log tail |
| sudo chctl logs <service> | Tail live logs for a named service (wraps podman logs -f) | Real-time troubleshooting; monitoring startup sequences | Streaming log output; Ctrl+C to exit |
| sudo chctl upgrade | Pull latest container images from ECR and restart services with new images | During planned release upgrades (e.g., 2.1.6-12 → 2.1.6-13) | Pulls new images, stops old containers, starts new containers; data preserved on EFS |
| sudo chctl backup | Trigger an on-demand MongoDB backup to the configured backup path | Before major changes; supplement to automated EFS backup policy | Backup archive created at /mnt/efs/backups/<timestamp>/ |
| sudo chctl health | Run end-to-end health check across all services and external integrations | Pre-incident validation; post-upgrade verification | Pass/Fail status per service and integration; total health score |

11.2 Appliance Upgrade Procedure

To upgrade CHAI to a new release version:

1. Review release notes for the target version at the CloudHedge support portal
2. Create a backup AMI of the current running instance: sudo chctl snapshot
3. Pull new images from ECR: sudo chctl pull --tag ch-rel-<new-version>
4. Stop the appliance: sudo chctl stop appliance
5. Start with new images: sudo chctl start appliance
6. Verify health: sudo chctl health — all services should show PASS
7. Verify version: sudo chctl version — should show the new release tag

Rollback: If the upgrade fails health checks, run sudo chctl pull --tag ch-rel-<previous-version> followed by sudo chctl stop appliance && sudo chctl start appliance to restore the previous version. MongoDB data on EFS is version-independent and is not affected by container image upgrades.

For detailed release notes and upgrade advisories, contact CloudHedge support or visit the CHAI User Guide.

11.3 Log Management

CHAI microservice logs are written to stdout/stderr within Podman containers and captured by CloudWatch Logs Agent running on the EC2 instance. Log retention is configured per-service based on volume and compliance requirements.

Log File Paths (on EC2 instance):

11.4 Monitoring & Alerting

CloudWatch alarms are configured to alert the operations team on the following conditions. All P1/P2-threshold alarms route to the customer incident management system via SNS topic → webhook → ticketing integration.

11.5 Health Check Procedure

Execute this procedure after any appliance restart, upgrade, DR activation, or infrastructure change to confirm full operational status.

1. Verify all services are running.
   
   

   Copy

      sudo chctl status
      # Expected: All 17 services in "running" state; no "exited" or "error" status
      

2. Confirm EFS is mounted.
   
   

   Copy

      df -h | grep efs
      # Expected: /mnt/efs mounted with expected available capacity
      mount | grep efs
      # Expected: EFS ID visible with tls,iam options
      

3. Confirm MongoDB is accessible and data is present.
   
   

   Copy

      podman exec -it db-service mongosh --eval "db.adminCommand('ping')"
      # Expected: { ok: 1 }
      podman exec -it db-service mongosh --eval "show dbs"
      # Expected: chai_db visible with non-zero size
      

4. Test ALB health endpoint.
   
   

   Copy

      curl -k https://<ALB_DNS_NAME>/api/health
      # Expected: HTTP 200; JSON body with {"status":"healthy","services":17}
      

5. Confirm Bedrock connectivity.
   In the CHAI web UI: Settings → AI Configuration → Test Bedrock Connection.
   Expected: "Connection successful" with response latency < 2 seconds.

6. Verify CloudWatch log ingestion.
   In AWS Console: CloudWatch → Log Groups → /chai/core-engine. Confirm log events are being written within the last 5 minutes.

7. Run CHAI health command.
   
   

   Copy

      sudo chctl health
      # Expected: All services PASS; all integrations PASS; overall health score 100%
      

8. Confirm web UI login.
   Open the CHAI web URL in a browser. Log in with an admin account. Confirm the dashboard loads and displays existing application portfolio data from MongoDB.

Appendix A — Port Reference

A.1 Internal Ports

Ports used by CHAI microservices for inter-service communication. All traffic runs on the cloudhedge Podman network (10.90.0.0/16) and does not traverse the VPC or internet. These ports are never exposed to end users or external systems.

A.2 External Ports

Ports used by users or external systems to communicate with CHAI. These ports must be open on the relevant security groups and accessible from the specified sources.

Appendix B — AWS Cost Estimate

Cost Estimate Notes: The following estimates are monthly costs for a single CHAI deployment in us-east-1 using on-demand pricing. Actual costs vary based on deployment topology (single EC2 vs Multi-AZ), instance family, EFS usage, Bedrock inference volume, and applicable AWS enterprise discount. Reserved Instance or Savings Plans pricing can reduce EC2 costs by 30–60%. For a customized TCO estimate based on your deployment requirements, contact CloudHedge sales.

The following estimates are based on us-east-1 on-demand pricing as of March 2026. Actual costs will vary based on usage patterns, reserved instance commitments, and enterprise discount programs. All estimates assume continuous 24/7 operation.

Appendix C — Deployment Checklist

Appendix D — Legal & Trademarks

Intellectual Property

This document and all referenced CHAI platform software are the intellectual property of CloudHedge Technologies Inc. All rights reserved. No part of this document may be reproduced, distributed, or transmitted in any form or by any means without the prior written permission of CloudHedge Technologies Inc., except as expressly authorized in the applicable software license agreement between CloudHedge Technologies Inc. and the licensee.

Trademarks

CHAI™, CHAI DART™, CHAI Flow™, and CHAI Universe™ are trademarks of CloudHedge Technologies Inc., registered or pending registration in the United States and other jurisdictions. R6Ai® is a registered trademark of CloudHedge Technologies Inc. The CloudHedge name and logo are trademarks of CloudHedge Technologies Inc.

All other trademarks, service marks, product names, and company names mentioned in this document are the property of their respective owners. References to third-party products, services, and trademarks do not constitute or imply endorsement, sponsorship, or affiliation by CloudHedge Technologies Inc.

Regulatory References

• EU Regulation 2022/2554 (Digital Operational Resilience Act / DORA) — European Parliament and Council, December 14, 2022
• AWS Shared Responsibility Model — Amazon Web Services Inc.
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
• CIS AWS Foundations Benchmark v1.4

License & Warranty Disclaimer

THE CHAI PLATFORM SOFTWARE IS PROVIDED UNDER THE TERMS OF THE CLOUDHEDGE ENTERPRISE LICENSE AGREEMENT. THE PLATFORM IS PROVIDED "AS IS" WITH RESPECT TO THIRD-PARTY OPEN-SOURCE COMPONENTS. CLOUDHEDGE TECHNOLOGIES INC. MAKES NO WARRANTIES, EXPRESS OR IMPLIED, REGARDING THIRD-PARTY SOFTWARE COMPONENTS IDENTIFIED IN THE SBOM. CLOUDHEDGE'S OBLIGATIONS WITH RESPECT TO DEFECTS, UPTIME, AND SUPPORT ARE EXCLUSIVELY GOVERNED BY THE APPLICABLE ENTERPRISE LICENSE AGREEMENT AND SUPPORT ADDENDUM.

Legacy Product Note

For historical reference only: CHAI is the successor platform to the CloudHedge legacy product line. All new deployments use the CHAI platform. References to legacy product nomenclature in prior customer agreements should be interpreted as referencing the current CHAI platform for all purposes of the applicable agreement.

Contact

CloudHedge Technologies Inc.
33 Wood Avenue S, Suite 600
Iselin, NJ 08830, USA
Web: cloudhedge.io
Support: support@cloudhedge.io
Security: security@cloudhedge.io