AWS Resource Architecture

This page documents the full deployed AWS resource topology for AosCloud. It shows how infrastructure components interconnect: from the VPC and subnets through the EKS cluster to managed databases, storage, and CDN. Use this page to understand the deployed system as a whole before configuring individual components.

Overview

An AosCloud deployment consists of a single VPC containing an EKS cluster (the compute layer) surrounded by managed AWS services that provide persistence, caching, messaging, and content delivery. All resources communicate over private networking — no managed service is exposed to the public internet directly.

The architecture follows a hub-and-spoke model:

• Hub: EKS cluster with multiple node groups running all application workloads
• Spokes: Managed services (Aurora PostgreSQL, ElastiCache Redis, DocumentDB, EFS, S3) connected via VPC security groups
• Edge: CloudFront CDN serving S3 artifacts to external consumers, and an NLB providing public ingress

Prerequisites

• Required AWS Services — catalog of all services
• IAM Roles and Policies — IRSA and role configuration
• Networking Prerequisites — VPC, subnets, endpoints, and security groups

Architecture Diagram

Resource Topology

VPC Layer

All resources deploy into a single VPC with CIDR 10.231.0.0/16 (configurable per environment). The VPC provides:

Component	CIDR Allocation	Purpose
Kubernetes services	/18 (first quarter)	EKS pod and service networking, public AZ subnets
VPC endpoints subnet	/24 at .100.0	Private Link interface endpoints
Aurora PostgreSQL subnets	/26 blocks × 3 AZs	Database subnet group
ElastiCache Redis subnets	/26 blocks × 3 AZs	Cache subnet group
DocumentDB subnets	/26 blocks × 3 AZs	Document database subnet group

All managed service subnets span three availability zones for high availability.

EKS Cluster

The EKS cluster is the central compute resource. It hosts all application and infrastructure workloads as Kubernetes pods.

Property	Configuration
Instance type	Configurable (e.g., t3a.2xlarge for dev, m5.2xlarge for prod)
Volume size	50 GB EBS per node
Scaling	Managed node group with configurable min/max/desired
Addons	EBS CSI driver, CoreDNS, kube-proxy, VPC CNI
OIDC provider	Enabled for IRSA
Public access	Configurable
Log retention	Configurable

The cluster uses a launch template for node configuration, integrates with the VPC's default route table, and has both public (for ingress) and private subnets.

Managed Services

Aurora PostgreSQL

Primary relational data store for all CRUD operations across AosCloud microservices.

Property	Value
Engine	Aurora PostgreSQL (cluster mode)
Subnet group	3 AZs
Encryption	KMS customer-managed key
Security groups	EKS default SG + VPC default SG

Consumers: API, Auth, Backend, Message Handler, Service Discovery, Unit Monitoring

ElastiCache Redis

In-memory cache and pub/sub layer for session management, real-time events, and application caching.

Property	Value
Engine	Redis 6.x
Deployment	Single-AZ with AUTH token
Subnet group	3 AZs
Security groups	EKS default SG + VPC default SG
Encryption	In-transit (TLS)

Consumers: API, Auth, Backend, Message Handler, Unit Monitoring, WebSocket API, Alert Handler, Units Queues Management

DocumentDB

MongoDB-compatible document database storing alert data.

Property	Value
Engine	DocumentDB (MongoDB-compatible)
Port	27017
Authentication	SCRAM-SHA-256 with TLS
Replica set	rs0
Subnet group	3 AZs
Encryption	KMS customer-managed key
Security groups	EKS default SG + VPC default SG

Consumers: Alert Handler

EFS (Elastic File System)

Persistent file storage for InfluxDB time-series metrics data, mounted directly into EKS pods.

Property	Value
Access point	/influxdb2 (UID/GID 1000, mode 775)
Mount targets	All EKS pod subnets
Encryption	KMS infrastructure key
Security group	EKS default SG

Consumers: InfluxDB (Prometheus metrics storage)

S3 Storage

Two S3 buckets serve distinct roles in the architecture:

Bucket	Purpose	KMS Key	CloudFront Origin
{name}-backend	Deployable Items, application artifacts, media	Primary	Yes
{name}-infra	Helm charts, InfluxDB backups, logs	Infrastructure	No

The backend bucket is the origin for the CloudFront distribution, making Deployable Items available to Units globally. The infrastructure bucket has lifecycle rules for automated cleanup (7-day backup expiry, 14-day Helm chart version cleanup).

Consumers:

• Backend bucket: Backend (Deployable Items), API (media), Task service, CloudFront (delivery to Units)
• Infrastructure bucket: Prometheus (InfluxDB backups), Helm installer (chart packages)

CloudFront CDN

A CloudFront distribution fronts the S3 backend bucket, providing edge-cached delivery of Deployable Items and static assets to Units worldwide.

Property	Value
Origin	S3 backend bucket
WAF	WAFv2 Web ACL (IP Reputation, Common Rules, Known Bad Inputs)
Logging	Access logs to infrastructure S3 bucket
Region requirement	WAFv2 ACL must be in us-east-1

The WAFv2 rules are AWS-managed rule groups applied automatically:

1. AWSManagedRulesAmazonIpReputationList — blocks known malicious IPs
2. AWSManagedRulesCommonRuleSet — OWASP Top 10 protections
3. AWSManagedRulesKnownBadInputsRuleSet — blocks known exploit patterns

Microservice-to-Resource Mapping

Each AosCloud microservice accesses specific managed services via IRSA-authenticated service accounts. The table below maps services to their AWS resource dependencies:

Microservice	Service Account	Aurora	Redis	DocumentDB	S3 Backend	RabbitMQ	Other
API	sa_app	✓	✓	—	✓ (read)	—	—
Auth	sa_app	✓	✓	—	—	—	—
Backend Tasks	sa_task	✓	✓	—	✓ (read/write)	—	Secrets Manager
Message Handler	sa_task	✓	✓	—	—	✓	Secrets Manager
Service Discovery	sa_sd	✓	—	—	—	—	—
Unit Monitoring	sa_app	✓	✓	—	—	—	—
WebSocket API	sa_app	—	✓	—	—	—	—
Alert Handler	sa_data_services	—	✓	✓	—	—	—
Units Queues Mgmt	sa_uqm	—	✓	—	—	✓	EC2 (legacy)
Unit Message Handler	sa_task	—	—	—	—	✓	—
Secrets Updater	sa_secrets_manager	—	—	—	—	—	Secrets Manager
Infrastructure (base)	sa_base	—	—	—	✓ (infra)	—	S3 infra, CloudWatch, Secrets Manager

RabbitMQ is deployed in-cluster via the rabbitmq-cluster-operator Helm chart — it is not an AWS managed service but runs as pods within EKS.

Data Flow Paths

Unit-to-Cloud Communication

Unit → Internet → NLB → Istio Ingress Gateway → WebSocket API / API
                                                        ↓
                                          Aurora PostgreSQL (persistence)
                                          Redis (sessions, pub/sub)
                                          RabbitMQ (async messaging)

Deployable Item Delivery

Backend → S3 Backend Bucket ← CloudFront CDN ← Units (download)

Deployable Items uploaded by the Backend service are stored in the S3 backend bucket. Units retrieve them through the CloudFront distribution, which provides edge caching and WAF protection.

Alert Processing

Unit → Message Handler → RabbitMQ → Alert Handler → DocumentDB
                                                         ↓
                                              Alert queries via API

Alert data flows from Units through the message pipeline into DocumentDB for storage. The API service queries DocumentDB (via the Alert Handler) to serve alert data to the management interface.

Metrics Collection

Application Pods → Prometheus → InfluxDB (EFS-backed persistent storage)

Fluent Bit → CloudWatch Logs (container logs)

Secret Distribution

Secrets Manager → CSI Secrets Provider → Pod volumes

All credentials and configuration flow through Secrets Manager. Application pods mount secrets via the CSI Secrets Store Provider.

Security Group Relationships

All managed services are protected by security groups that restrict access to the EKS cluster and VPC-internal traffic only:

┌─────────────────────────────────────────────────────┐
│                    VPC Default SG                     │
│  (base security group for all managed services)      │
├─────────────────────────────────────────────────────┤
│                                                      │
│  ┌──────────────┐    Bidirectional     ┌──────────┐ │
│  │ EKS Default  │ ◄─── all ports ───► │ VPC Base │ │
│  │     SG       │                      │    SG    │ │
│  └──────┬───────┘                      └────┬─────┘ │
│         │                                    │       │
│         │  Attached to:                      │       │
│         ├── Aurora PostgreSQL                │       │
│         ├── ElastiCache Redis                │       │
│         ├── DocumentDB                       │       │
│         ├── EFS Mount Targets                │       │
│         └── VPC Endpoints                    │       │
│                                                      │
└─────────────────────────────────────────────────────┘

Every managed service has both the EKS default security group and the VPC default security group attached. This dual-SG approach ensures:

1. EKS pods can reach all managed services (EKS SG → VPC SG ingress rule)
2. No managed service is accessible from outside the VPC

VPC Endpoint Integration

Twelve VPC endpoints provide private connectivity so that EKS pods never traverse the public internet when calling AWS APIs:

Endpoint	Used By
S3	Pods (artifact upload/download)
ECR API + DKR	EKS (image pull)
STS	EKS OIDC/IRSA authentication
Secrets Manager	CSI Secrets Provider
CloudWatch Logs	Fluent Bit, Container Insights
Elastic Load Balancing	AWS LB Controller
Auto Scaling	Cluster Autoscaler
RDS	Aurora management operations
ElastiCache	Redis management operations
SES SMTP	Email sending

All endpoints are placed in the dedicated endpoints subnet and have both EKS and VPC default security groups attached.

Encryption at Rest

All persistent data is encrypted with customer-managed KMS keys:

KMS Key	Scope	Encrypted Resources
Primary ({name})	Application data	S3 backend, Aurora, DocumentDB, Secrets Manager
Infrastructure ({name}-infra)	Operational data	S3 infrastructure, EFS

Both keys are referenced across the resource topology — no data rests unencrypted.

Related Documentation

• Required AWS Services — detailed catalog of each service
• IAM Roles and Policies — IRSA service accounts that authorize the resource access shown here
• Networking Prerequisites — VPC, subnet, and security group configuration details