AWS provides a robust, scalable foundation for the AI Ticket Support System in production. The platform’s three main workloads — the React frontend, the Node.js + GPT-4o-mini backend, and the PostgreSQL + pgvector database — each map naturally to managed AWS services that handle patching, scaling, and high availability. Two architecture patterns are supported depending on your traffic profile and operational preferences.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/yocxy2/2a/llms.txt
Use this file to discover all available pages before exploring further.
Architecture overview
- Container-based (Recommended)
- Serverless
The container-based approach brings the Docker Compose topology directly into AWS managed container infrastructure, making it straightforward to promote the same images from local to production.
Traffic flow:
| Layer | AWS Service |
|---|---|
| Frontend | ECS Fargate (nginx container) or S3 + CloudFront for a fully static build |
| Backend | ECS Fargate — Node.js container with auto-scaling policy |
| Database | RDS PostgreSQL 15+ with pgvector extension enabled |
| Cache / Queue | Amazon ElastiCache for Redis (replaces the local Redis container) |
| Secrets | AWS Secrets Manager — stores OPENAI_API_KEY and DB credentials |
| Load Balancer | Application Load Balancer (ALB) — routes HTTPS traffic to ECS tasks |
| CI/CD | GitHub Actions or AWS CodePipeline pushing images to ECR |
Key AWS services
ECS Fargate
Serverless container execution for the backend and (optionally) frontend. No EC2 instances to manage — AWS handles placement, patching, and scaling. Task definitions map directly to the
docker-compose.yml service definitions, making promotion from local to production straightforward.RDS PostgreSQL
Managed PostgreSQL with automated backups, Multi-AZ failover, and support for the pgvector extension on PostgreSQL 15+. Replaces the
pgvector/pgvector:pg16 Docker container from the local stack with a fully managed, highly available database.CloudFront
AWS’s global CDN distributes the compiled React frontend from edge locations worldwide, reducing latency for end users and offloading origin traffic. Works with either an S3 origin (static hosting) or an ALB origin (ECS-served nginx).
Secrets Manager
Secure, auditable storage for sensitive credentials including
OPENAI_API_KEY, DATABASE_URL, and Redis passwords. ECS task roles retrieve secrets at runtime via the native Secrets Manager integration — no plaintext environment files required.Security checklist
Follow these practices before exposing the system to production traffic:- Store
OPENAI_API_KEYin AWS Secrets Manager — never commit it to source control, bake it into container images, or store it in plaintext.envfiles in S3. Reference it in ECS task definitions using thesecretsfield. - Place RDS in a private VPC subnet with no public access — only ECS tasks (or Lambda functions) inside the same VPC should be able to reach the database port (5432). Use Security Groups to enforce this.
- Use IAM roles with least privilege for ECS tasks — each task definition should have a dedicated IAM task role that grants only the permissions it needs (e.g.,
secretsmanager:GetSecretValuefor its own secret ARN, nothing else). - Enforce HTTPS with ACM certificates — attach a free ACM certificate to your ALB listener and redirect HTTP (port 80) to HTTPS (port 443). CloudFront distributions should also enforce HTTPS-only viewer policy.
- Add WAF rules for DDoS protection — attach AWS WAF to the CloudFront distribution and/or ALB to block common attack patterns and apply rate-based rules.
- Enable rate limiting on API Gateway — if using the serverless architecture, configure usage plans and throttling on API Gateway to prevent abuse of the
/api/v1/ticketsendpoint and its downstream OpenAI API calls.
Cost optimization
Keep cloud costs proportional to actual usage with these strategies:- Use Spot instances for ECS entity-extraction workers — the async BullMQ workers that perform GraphRAG entity extraction are fault-tolerant and can be interrupted. Running them on ECS Fargate Spot can reduce compute costs by up to 70%.
- RDS Reserved Instances for steady-state production workloads — if the database runs continuously, committing to a 1-year Reserved Instance typically yields 30–40% savings over On-Demand pricing.
- CloudFront caching reduces origin requests — configure cache behaviours to serve the compiled React assets (
/static/*,*.js,*.css) from the edge with long TTLs. Only API calls (/api/*) should bypass the cache. - Lambda pay-per-use option for low-traffic deployments — for environments processing fewer than a few thousand tickets per day, the serverless architecture’s pay-per-invocation model can be more economical than continuously running ECS Fargate tasks.
pgvector on RDS
AWS RDS PostgreSQL 15 and later supports the You can run this via
pgvector extension natively. After provisioning your RDS instance, enable it by running the following command once against the ticket_system database:psql, a Prisma migration, or the RDS Query Editor in the AWS Console. The pgvector extension powers both the hybrid RAG knowledge-base search and the GraphRAG entity similarity lookups that the backend relies on for AI classification.Environment variable mapping
When moving from Docker Compose to ECS, update the following environment variable values in your ECS task definition or Secrets Manager entries:| Variable | Docker Compose value | AWS value |
|---|---|---|
DATABASE_URL | postgresql://postgres:postgres@postgres:5432/ticket_system | postgresql://<user>:<pass>@<rds-endpoint>:5432/ticket_system |
REDIS_HOST | redis | ElastiCache primary endpoint (e.g. my-cluster.abc123.ng.0001.use1.cache.amazonaws.com) |
REDIS_PORT | 6379 | 6379 |
OPENAI_API_KEY | Plaintext in .env | Injected from AWS Secrets Manager |
NODE_ENV | development | production |
PORT | 3001 | 3001 (matched to ECS container port mapping) |