mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
doc: architecture for US and EU cloud
This commit is contained in:
Sheen Capadngan
142
docs/internals/architecture/cloud.mdx
Normal file
142
docs/internals/architecture/cloud.mdx
Normal file
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: "Infisical Cloud Architecture"
|
||||
description: "Architecture overview for Infisical's US and EU cloud deployments"
|
||||
---
|
||||
|
||||
This document provides an overview of Infisical's cloud architecture for our US and EU deployments, detailing the core components and how they interact to provide security and infrastructure services.
|
||||
|
||||
## Overview
|
||||
|
||||
Infisical Cloud operates on AWS infrastructure using containerized services deployed via Amazon ECS (Elastic Container Service). Our US and EU deployments use identical architectural patterns to ensure consistency and reliability across regions.
|
||||
|
||||
|
||||
|
||||
## Components
|
||||
|
||||
A typical Infisical Cloud deployment consists of the following components:
|
||||
|
||||
### Application Services
|
||||
|
||||
- **Infisical Core**: Main application server running the Infisical backend API
|
||||
- **License API**: Dedicated API service for license management with separate database (shared between US/EU)
|
||||
- **Application Load Balancer**: Routes incoming traffic to application containers with SSL termination and host-based routing
|
||||
|
||||
### Data Layer
|
||||
|
||||
- **Amazon RDS (PostgreSQL)**:
|
||||
- **Main Database**: Primary database for secrets, users, and metadata (Multi-AZ, encryption enabled)
|
||||
- **License API Database**: Dedicated database for license management services
|
||||
- **Amazon ElastiCache (Redis)**:
|
||||
- **Main Redis Cluster**: Multi-AZ replication group for core application caching and queuing
|
||||
- **License API Redis**: Dedicated cache for license services
|
||||
- Redis 7 engine with CloudWatch logging and snapshot backups
|
||||
|
||||
### Infrastructure
|
||||
|
||||
- **ECS Fargate**: Serverless container platform running application services
|
||||
- **AWS Global Accelerator**: Global traffic routing and performance optimization
|
||||
- **Cloudflare**: DNS management and routing
|
||||
- **AWS SSM Parameter Store**: Stores application configuration and secrets
|
||||
- **CloudWatch**: Centralized logging and monitoring
|
||||
|
||||
## System Layout
|
||||
|
||||
### Service Architecture
|
||||
|
||||
The Infisical application runs as multiple containerized services on ECS:
|
||||
|
||||
- **Main Server**: 10-30 instances (2048 CPU, 4096 MB memory) with auto-scaling
|
||||
- **License API**: 2-4 instances (2048 CPU, 4096 MB memory) with dedicated infrastructure (shared globally)
|
||||
- **Monitoring**: AWS OTel Collector and Datadog Agent sidecars
|
||||
|
||||
Container images are pulled from Docker Hub and managed via GitHub Actions for deployments.
|
||||
|
||||
### Network Configuration
|
||||
|
||||
Services are deployed in private subnets with the following connectivity:
|
||||
|
||||
- External traffic → Application Load Balancer → ECS Services
|
||||
- Main server exposes port 8080
|
||||
- License API exposes port 4000 (portal.infisical.com, license.infisical.com)
|
||||
- Service-to-service communication via AWS Service Connect
|
||||
|
||||
### Data Flow
|
||||
|
||||
1. **DNS resolution** via Cloudflare routes traffic to AWS Global Accelerator
|
||||
2. **Global Accelerator** optimizes routing to the nearest AWS region
|
||||
3. **Client requests** are routed through the Application Load Balancer to ECS containers
|
||||
4. **Application logic** processes requests in the Infisical Core service
|
||||
5. **Data persistence** occurs via encrypted connections to PostgreSQL
|
||||
6. **Caching** utilizes Redis for performance optimization
|
||||
7. **Configuration** is retrieved from AWS SSM Parameter Store
|
||||
|
||||
## Regional Deployments
|
||||
|
||||
### US Cloud (us.infisical.com or app.infisical.com)
|
||||
|
||||
- **Cluster**: `infisical-core-platform` ECS cluster
|
||||
- **Scaling**: 10-30 main server instances, 2-4 license server instances
|
||||
- **Monitoring**: Integrated with Datadog
|
||||
|
||||
### EU Cloud (eu.infisical.com)
|
||||
|
||||
- **Cluster**: `infisical-core-platform` ECS cluster
|
||||
- **Scaling**: 15-30 main server instances, 2-4 license server instances
|
||||
- **Monitoring**: Integrated with Datadog
|
||||
- **Compliance**: GDPR compliant with data residency within EU
|
||||
|
||||
## Configuration Management
|
||||
|
||||
Application configuration and secrets are managed through AWS SSM Parameter Store, with deployment automation handled via GitHub Actions.
|
||||
|
||||
## Monitoring and Observability
|
||||
|
||||
### Logging
|
||||
|
||||
- **CloudWatch**: 365-day retention for application logs
|
||||
- **Health Checks**: HTTP endpoint monitoring for service health
|
||||
|
||||
### Metrics
|
||||
|
||||
- **AWS OTel Collector**: Prometheus metrics collection
|
||||
- **Datadog Agent**: Application performance monitoring and infrastructure metrics
|
||||
- **Auto Scaling**: CPU and memory-based scaling triggers at 60% utilization
|
||||
|
||||
## Container Management
|
||||
|
||||
- **Images**: `infisical/staging_infisical` and `infisical/license-server` from Docker Hub
|
||||
- **Deployment**: Automated via GitHub Actions updating SSM parameter for image tags
|
||||
- **Registry Access**: Docker Hub credentials stored in AWS Secrets Manager
|
||||
- **Platform**: ECS Fargate with 70% standard capacity, 30% Spot instances
|
||||
|
||||
## Security Overview
|
||||
|
||||
### Data Protection
|
||||
|
||||
- **Encryption**: All secrets encrypted at rest and in transit
|
||||
- **Network Isolation**: Services deployed in private subnets with controlled access
|
||||
- **Authentication**: API tokens and service accounts for secure access
|
||||
- **Audit Logging**: Comprehensive audit trails for all secret operations
|
||||
|
||||
### Network Architecture
|
||||
|
||||
- **Load Balancing**: Application Load Balancer with SSL termination and health checks
|
||||
- **Service Communication**: AWS Service Connect for internal service discovery
|
||||
- **Security Groups**: Restrictive firewall rules (port 8080 for main server, 4000 for license API)
|
||||
- **High Availability**: Multi-AZ deployment with automatic failover
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Service Health**: Check ECS service status and CloudWatch logs for application errors
|
||||
|
||||
**Scaling Issues**: Monitor CPU/memory utilization and auto-scaling policies
|
||||
|
||||
**Database Connectivity**: Verify security group rules and database availability
|
||||
|
||||
### Log Locations
|
||||
|
||||
- **Application Logs**: CloudWatch log groups with 365-day retention
|
||||
- **ECS Task Logs**: Available through ECS console or CloudWatch
|
||||
- **Load Balancer**: Access logs and health check status
|
||||
34
docs/internals/architecture/components.mdx
Normal file
34
docs/internals/architecture/components.mdx
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Components"
|
||||
description: "Understand Infisical's core architectural components and how they work together."
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Infisical is architected around several key components that work in concert to provide a secure and streamlined secret management experience. These components span the client, API, and storage layers, ensuring that secrets are protected at every stage of their lifecycle.
|
||||
|
||||
## 1. API (Backend)
|
||||
|
||||
Infisical exposes a well-documented [REST API](https://infisical.com/docs/api-reference/overview/introduction) that enables programmatic interaction with the platform, enabling a wide range of use cases.
|
||||
|
||||
## 2. Storage Backend
|
||||
|
||||
Infisical relies on a robust storage backend to durably store secrets, users, and other platform data. Infisical's storage backend is [PostgreSQL](https://www.postgresql.org/).
|
||||
|
||||
## 3. Caching Layer
|
||||
|
||||
Infisical uses [Redis](https://redis.com) to enable more complex workflows including a queuing system to manage long-running asynchronous tasks, cron jobs, as well as reliable cache for frequently used resources.
|
||||
|
||||
## 4. Clients
|
||||
|
||||
Clients are interfaces through which users and applications interact with the Infisical API:
|
||||
|
||||
- **Web UI**: A browser-based portal providing a user-friendly interface for managing secrets, configurations, and performing administrative tasks.
|
||||
|
||||
- [**CLI**](https://infisical.com/docs/cli): A terminal-based tool for interacting with the Infisical API, enabling automation, scripting, and integration into CI/CD pipelines.
|
||||
|
||||
- **SDKs (Software Development Kits)**: Platform-specific libraries with method abstractions for working with secrets. Supported languages include [Node.js](https://infisical.com/docs/sdks/languages/node), [Python](https://infisical.com/docs/sdks/languages/python), [Java](https://infisical.com/docs/sdks/languages/java), [Golang](https://infisical.com/docs/sdks/languages/go), [Ruby](https://infisical.com/docs/sdks/languages/ruby) and [.NET](https://infisical.com/docs/sdks/languages/csharp).
|
||||
|
||||
- [**Kubernetes Operator**](https://infisical.com/docs/integrations/platforms/kubernetes): A Kubernetes-native component that facilitates the secure retrieval and management of secrets within a Kubernetes cluster. The operator supports multiple custom resource definitions (CRDs) for syncing secrets.
|
||||
|
||||
- [**Infisical Agent**](https://infisical.com/docs/integrations/platforms/infisical-agent): Daemon that automatically fetches and manages access tokens and secrets to be used in various client resources.
|
||||
Reference in New Issue
Block a user