# Infrastructure Guidance ### FormSG Architecture Reference Understanding FormSG's complete architecture helps you plan which components to migrate and which to replace:
### When to Use This Guide Use the guides at [deployment](https://international.open.gov.sg/self-hosting/formsg/deployment "mention") wherever possible, this guide covers * Other cloud deployment not covered like GCP, Azure, or other cloud environment * On-premise deployment * Understanding FormSG architecture for platform adaptation ### What This Guide Covers 1. **Infrastructure Patterns** - What FormSG needs from your platform 2. **Migration Approach** - How to implement it step by step 3. **Getting Started** - Next steps for your deployment ### Platform Context FormSG was architected for AWS and that's where we have production experience. While the architecture is cloud-agnostic in theory, we haven't tested other cloud deployments. {% hint style="info" %} **What We Know** ✅ The architecture uses standard patterns (containers, MongoDB, S3-compatible storage)\ ✅ Other governments have likely deployed on different clouds\ 📋 This guide provides architectural patterns for adaptation to your platform {% endhint %} ### Infrastructure Patterns This section covers FormSG's infrastructure requirements in a cloud-agnostic way that you can adapt to your specific tools and environments. #### Core Deployment Patterns {% tabs %} {% tab title="Container Service" %} **What it does**: Runs FormSG application with auto-scaling and health monitoring **Requirements**: * **Container image**: Build from FormSG source or use your registry * **Port**: 5000 (internal application port) * **Health check**: `/api/v3/admin/forms` endpoint * **Auto-scaling**: 2-10 instances based on CPU utilization (70% threshold) * **Environment variables**: NODE\_ENV, DB\_HOST, SESSION\_SECRET * **Load balancer**: For high availability and traffic distribution **Adapt for your environment**: * Adjust scaling parameters based on expected load * Configure environment variables in your secrets management system {% endtab %} {% tab title="Storage & Database" %} **What it does**: Provides secure, scalable storage for forms, attachments, and application data **Database (MongoDB-compatible)**: * Features needed: transactions, TTL indexes, aggregation pipelines * Connection: Standard MongoDB connection string * Backup and disaster recovery procedures **Object Storage (S3-compatible)**: * Three buckets: attachments, images, static assets * Features needed: presigned URLs, lifecycle policies, server-side encryption * API compatibility with AWS S3 **Session Storage**: * Redis-compatible or database-backed sessions * 24-hour TTL for user sessions * Encryption at rest and in transit **Adapt for your environment**: * Choose managed database service vs. self-hosted based on your policies * Set up backup procedures according to your retention requirements * Implement encryption standards required by your compliance framework {% endtab %} {% tab title="Load Balancing & Network" %} **What it does**: Securely exposes FormSG to users while protecting backend services **Load Balancer**: * HTTPS listener on port 443 with SSL certificate * HTTP to HTTPS redirect on port 80 * Health checks to application containers * DDoS protection and rate limiting **Network Security**: * Public subnets: Load balancer only * Private subnets: Application containers and database * Security rules: Load balancer → App (port 5000), App → Database (port 27017) * Web Application Firewall (WAF) for additional security **SSL/TLS**: * Government-approved SSL certificates * TLS termination at load balancer * Encrypted traffic between all components **Adapt for your environment**: * Configure WAF rules based on your security requirements * Adjust network segmentation for your compliance needs {% endtab %} {% tab title="Monitoring & Logging" %} **What it does**: Provides visibility into application performance, security events, and operational health **Infrastructure Metrics**: * Container CPU and memory usage * Application response time and error rates * Database connection counts and performance * Failed authentication attempts **Alerting Thresholds**: * High CPU and memory usage * High error rates and failed health checks * Database connectivity issues **Log Collection**: * Application logs (errors, warnings, info) * Access logs (user requests and responses) * Security events (login attempts, permission changes) * Audit trail (admin actions, form modifications) **Adapt for your environment**: * Set up log retention according to your compliance requirements * Implement audit logging as required by your security policies {% endtab %} {% tab title="Serverless Functions" %} **What it does**: Provides on-demand virus scanning for file uploads and other serverless processing tasks **Requirements**: * **Function runtime**: Node.js-compatible serverless platform * **Memory allocation**: 512MB minimum for virus scanning operations * **Triggers**: S3 upload events * **Dependencies**: ClamAV or equivalent virus scanning engine * **Network access**: Download virus definitions and communicate with object storage **File Processing**: * Virus scanning for form attachments **Adapt for your environment**: * Choose managed functions (Azure Functions, Google Cloud Functions) or container-based serverless * Configure appropriate memory and timeout limits for your file sizes * Set up virus definition updates according to your security policies {% endtab %} {% endtabs %} ### Migration Approach FormSG uses standard technologies (Docker, MongoDB, S3-compatible storage, SMTP) that exist on all major clouds: * AWS ECS → Any container service * AWS S3 → Any object storage with S3 API * MongoDB Atlas → Any MongoDB-compatible database * AWS SES → Any SMTP service #### Migration Phases and Validation {% stepper %} {% step %} **Phase 1: Infrastructure Foundation** **Objective**: Establish core infrastructure components **Activities**: * Set up container orchestration platform * Deploy object storage solution * Configure networking and load balancing * Establish monitoring and logging **Validation**: * [ ] Container platform can run Docker images * [ ] Object storage passes S3 compatibility tests * [ ] Load balancer routes traffic correctly * [ ] Basic monitoring collects metrics {% endstep %} {% step %} **Phase 2: Data Services** **Objective**: Migrate database and configure data persistence **Activities**: * Deploy MongoDB-compatible database * Configure connection strings and authentication * Set up backup and disaster recovery * Test data migration procedures **Validation**: * [ ] Database accepts MongoDB connections * [ ] Application can read/write form data * [ ] Backup and restore procedures work * [ ] Performance meets requirements {% endstep %} {% step %} **Phase 3: Application Services** **Objective**: Configure external service integrations **Activities**: * Configure email service integration * Set up SMS service (if required) * Configure identity provider integration * Test all communication channels **Validation**: * [ ] Admin login OTPs delivered via email * [ ] Form submissions trigger notifications * [ ] Identity authentication works * [ ] All integrations handle errors gracefully {% endstep %} {% step %} **Phase 4: Security and Compliance** **Objective**: Implement security controls and validate compliance **Activities**: * Configure TLS/SSL certificates * Implement access controls and secrets management * Set up security monitoring and alerting * Conduct security testing **Validation**: * [ ] All traffic encrypted in transit * [ ] Secrets properly managed and rotated * [ ] Access controls enforced * [ ] Security monitoring operational {% endstep %} {% endstepper %} {% hint style="success" %} **💡 Success Tip**: Start with a development environment to validate each component before migrating production workloads. This approach reduces risk and helps identify integration issues early. {% endhint %}