From no cloud infrastructure to a SOC 2-aligned AWS environment
Backend services that deploy independently, with no full restarts
To provision a new environment or sandbox account
Ficus Platforms, Inc.
New York, NY
Fintech / Insurance Technology
AWS Control Tower, ECS Fargate, Aurora PostgreSQL Serverless v2, Application Load Balancer, CloudFront, WAF, API Gateway, Route 53, Secrets Manager, KMS, ECR, S3, IAM Identity Center, Security Hub, GuardDuty, AWS Config, CloudTrail, CloudWatch, X-Ray, GitHub Actions, Terraform
Ficus Platforms builds a modern digital beneficiary account platform for life insurance carriers, enabling carriers to manage retained asset programs for their beneficiaries. The company needed production-ready cloud infrastructure that could support their dual-service architecture while meeting SOC 2 compliance requirements. Avahi delivered a complete AWS environment from the ground up, including a multi-account landing zone via AWS Control Tower, containerized microservices on ECS Fargate, Aurora PostgreSQL databases, and fully automated CI/CD pipelines. The engagement transformed Ficus Platforms from having no cloud infrastructure to operating a secure, scalable, and independently deployable two-service architecture across development, staging, and production environments.
Ficus Platforms is a fintech company headquartered in New York that provides a digital engagement platform for life insurance carriers managing retained asset programs. Their platform serves two distinct user populations: beneficiaries who access their accounts through a mobile application and web portal, and administrators who manage the platform through a dedicated admin interface. The platform handles sensitive financial and personal data, including social security numbers and beneficiary account information, making security and compliance foundational requirements for their infrastructure.
Ficus Platforms faced a critical infrastructure gap that was blocking their engineering team from shipping product. Every week without production infrastructure meant delayed feature releases and an inability to serve customers. The company needed to move quickly while also meeting stringent security and compliance requirements.
Their application architecture presented specific challenges. The platform consisted of two Rust/Axum backend services (a beneficiary-facing API and an administrative API) plus a Next.js admin portal, all sharing a common database. Without proper infrastructure, these services could not be deployed independently, creating operational risk where a failure or deployment of any component would force a full-service restart.
Beyond basic deployment needs, Ficus Platforms required SOC 2-aligned controls from day one. Their enterprise architecture review board demanded clear audit boundaries, centralized logging, encryption at rest and in transit, and documented architecture decisions. A single-account AWS model would create blast radius risks and complicate the audit boundaries required for compliance.
Ficus Platforms selected AWS as their cloud platform because it offered the specific services needed to address their compliance and operational requirements. AWS Control Tower provided a multi-account landing zone with pre-built security guardrails, enabling clean audit boundaries between development, staging, and production environments without requiring custom policy development from scratch.
The combination of ECS Fargate for serverless container orchestration and Aurora PostgreSQL Serverless v2 for database workloads aligned with their need for automatic scaling without infrastructure management overhead. AWS-native security services (Security Hub, GuardDuty, AWS Config, and CloudTrail) provided the compliance monitoring and threat detection capabilities required for SOC 2 readiness, while IAM Identity Center enabled role-based single sign-on across all accounts.
Ficus Platforms engaged Avahi because of their ability to deliver a complete, production-ready AWS environment within a compressed four-week timeline. The engagement required expertise across multiple domains: AWS landing zone architecture, container orchestration, database design, CI/CD automation, and security compliance.
Avahi’s approach of delivering 100% infrastructure-as-code via Terraform, combined with their experience implementing SOC 2-aligned controls, meant Ficus Platforms would receive not just working infrastructure but also the documentation, architecture decision records, and operational runbooks needed for their enterprise architecture review board. The team’s familiarity with modern application stacks (Rust, TypeScript, containerized microservices) enabled them to design infrastructure that matched the application’s requirements rather than forcing architectural
Avahi delivered a comprehensive AWS infrastructure build that established Ficus Platforms’ cloud foundation across three environments.
Multi-Account Landing Zone
The engagement began with deploying AWS Control Tower to create a multi-account organization structure. The architecture includes a Management account for billing and governance, a Security OU containing Log Archive and Audit accounts for centralized logging and security findings, and a Workloads OU with separate Development, Staging, and Production accounts. This structure provides blast radius isolation, ensuring a security incident or misconfiguration in one environment cannot propagate to others.
IAM Identity Center provides single sign-on access with permission sets scoped per role and account. Developers receive PowerUserAccess in Development and ReadOnlyAccess in Staging and Production, while infrastructure changes require elevated permissions. Control Tower guardrails enforce baseline security: denying root user access, preventing accounts from leaving the organization, and blocking CloudTrail from being disabled.
Containerized Microservices Architecture
The backend was split into two independently deployable ECS Fargate services. The user-svc handles beneficiary-facing API requests from the mobile app and web portal, while the admin-svc serves the administrative interface. Each service has its own Docker image, ECR repository, ECS task definition, security group, and auto-scaling policy.
The container strategy uses multi-stage Docker builds with cargo-chef for Rust dependency caching, producing minimal distroless images (approximately 200MB) that run as non-root users. A single Dockerfile builds both services via a build argument, ensuring consistency while enabling independent deployability. ECS services are configured with target-tracking auto-scaling (CPU 70%, Memory 75%) with minimum 1 and maximum 4 tasks, plus deployment circuit breakers that automatically roll back failed deployments.
Database and Data Layer
Aurora PostgreSQL Serverless v2 provides the relational datastore, configured with automatic scaling from 0.5 to 4 ACUs. The database runs in private subnets across two Availability Zones, with KMS encryption at rest and TLS connections in transit. Development uses a single instance for cost optimization, while production is configured for Multi-AZ deployment with read replicas for high availability.
Row-Level Security policies enforce multi-tenant data isolation at the database layer. The organization_id from Clerk JWT tokens is set via SET LOCAL within each database transaction, and RLS policies filter rows automatically. This provides defense-in-depth: even if application code contains a bug, the database engine prevents cross-tenant data leakage.
Networking and Routing
Each environment has a dedicated VPC with public and private subnets across two Availability Zones. Application Load Balancers in public subnets terminate TLS (using ACM-managed certificates with TLS 1.3) and route traffic based on path: /admin/* routes to the admin-svc target group, while all other traffic routes to user-svc. NAT Gateways in public subnets provide egress for private resources.
The architecture includes CloudFront distributions with WAF at the edge for geographic restrictions and IP allowlisting on the admin service. API Gateway provides additional throttling, usage plans, and request validation in front of the ALB.
CI/CD Automation
Two GitHub Actions pipelines automate infrastructure and application deployments. The Terraform pipeline handles infrastructure changes with format validation, linting, and plan output, using S3 for state storage and DynamoDB for state locking. Manual approval gates control promotion from Development to Staging (one approval) and Staging to Production (two approvals).
The application pipeline builds Docker images for both services, runs security scans via Trivy, pushes to ECR, and deploys to ECS with automatic rollback on health check failures. GitHub OIDC federation provides AWS access without long-lived credentials. A dedicated migration ECS task runs SQLx database migrations before service updates, ensuring schema changes complete successfully before new application code deploys.
Security and Compliance
SOC 2-aligned controls were enabled from day one. Security Hub aggregates findings across all accounts with conformance packs aligned to SOC 2 criteria. GuardDuty provides threat detection, AWS Config monitors resource compliance, and CloudTrail captures API activity to the centralized Log Archive account. All secrets (database credentials, Clerk JWT keys, SSN pepper for PII hashing) are stored in AWS Secrets Manager with KMS encryption and injected into ECS tasks at launch time.
Observability
CloudWatch provides centralized logging with Container Insights for ECS metrics. Per-service dashboards display latency, error rates, and health status. AWS X-Ray integration enables distributed tracing across services. Alarms are configured to support automated rollback and operational awareness.
AWS Control Tower multi-account landing zone with Development, Staging, and Production environments
Two independently deployable ECS Fargate services (user-svc and admin-svc) with auto-scaling
Aurora PostgreSQL Serverless v2 with Row-Level Security for multi-tenant isolation
VPC architecture with public/private subnets across two Availability Zones per environment
Application Load Balancers with path-based routing and TLS 1.3 termination
CloudFront distributions with WAF for edge security and geographic restrictions
API Gateway with throttling, usage plans, and request validation
GitHub Actions CI/CD pipelines for Terraform infrastructure and application deployments
ECR repositories with scan-on-push and lifecycle policies
Secrets Manager integration for credential management
SOC 2-aligned security controls: Security Hub, GuardDuty, AWS Config, CloudTrail
IAM Identity Center with role-based permission sets
CloudWatch dashboards, alarms, and X-Ray distributed tracing
Architecture Decision Records documenting key design choices
Operational runbooks and knowledge transfer documentation
The engagement transformed Ficus Platforms from having no cloud infrastructure to operating a fully functional, SOC 2-aligned AWS environment in four weeks. The engineering team can now ship features independently for each service without deployment conflicts or full-service restarts.
The multi-account structure provides clean audit boundaries that satisfy SOC 2 CC6.1 (logical access) and CC6.6 (network segmentation) requirements, simplifying evidence collection for their compliance journey. Database-level Row-Level Security enforcement provides an auditable isolation boundary for multi-tenant data, addressing a key enterprise architecture criterion.
The infrastructure-as-code approach means Ficus Platforms can extend and modify their environment independently. All Terraform modules are reusable across environments, and the CI/CD pipelines support the same container image promoting from Development through Staging to Production without rebuilds. New environments or sandbox accounts can be provisioned through Account Factory in under 30 minutes.
Ficus Platforms, Inc.
New York, NY
Fintech / Insurance Technology
AWS Control Tower, ECS Fargate, Aurora PostgreSQL Serverless v2, Application Load Balancer, CloudFront, WAF, API Gateway, Route 53, Secrets Manager, KMS, ECR, S3, IAM Identity Center, Security Hub, GuardDuty, AWS Config, CloudTrail, CloudWatch, X-Ray, GitHub Actions, Terraform
Ficus Platforms builds a modern digital beneficiary account platform for life insurance carriers, enabling carriers to manage retained asset programs for their beneficiaries. The company needed production-ready cloud infrastructure that could support their dual-service architecture while meeting SOC 2 compliance requirements. Avahi delivered a complete AWS environment from the ground up, including a multi-account landing zone via AWS Control Tower, containerized microservices on ECS Fargate, Aurora PostgreSQL databases, and fully automated CI/CD pipelines. The engagement transformed Ficus Platforms from having no cloud infrastructure to operating a secure, scalable, and independently deployable two-service architecture across development, staging, and production environments.
Ficus Platforms is a fintech company headquartered in New York that provides a digital engagement platform for life insurance carriers managing retained asset programs. Their platform serves two distinct user populations: beneficiaries who access their accounts through a mobile application and web portal, and administrators who manage the platform through a dedicated admin interface. The platform handles sensitive financial and personal data, including social security numbers and beneficiary account information, making security and compliance foundational requirements for their infrastructure.
Ficus Platforms faced a critical infrastructure gap that was blocking their engineering team from shipping product. Every week without production infrastructure meant delayed feature releases and an inability to serve customers. The company needed to move quickly while also meeting stringent security and compliance requirements.
Their application architecture presented specific challenges. The platform consisted of two Rust/Axum backend services (a beneficiary-facing API and an administrative API) plus a Next.js admin portal, all sharing a common database. Without proper infrastructure, these services could not be deployed independently, creating operational risk where a failure or deployment of any component would force a full-service restart.
Beyond basic deployment needs, Ficus Platforms required SOC 2-aligned controls from day one. Their enterprise architecture review board demanded clear audit boundaries, centralized logging, encryption at rest and in transit, and documented architecture decisions. A single-account AWS model would create blast radius risks and complicate the audit boundaries required for compliance.
Ficus Platforms selected AWS as their cloud platform because it offered the specific services needed to address their compliance and operational requirements. AWS Control Tower provided a multi-account landing zone with pre-built security guardrails, enabling clean audit boundaries between development, staging, and production environments without requiring custom policy development from scratch.
The combination of ECS Fargate for serverless container orchestration and Aurora PostgreSQL Serverless v2 for database workloads aligned with their need for automatic scaling without infrastructure management overhead. AWS-native security services (Security Hub, GuardDuty, AWS Config, and CloudTrail) provided the compliance monitoring and threat detection capabilities required for SOC 2 readiness, while IAM Identity Center enabled role-based single sign-on across all accounts.
Ficus Platforms engaged Avahi because of their ability to deliver a complete, production-ready AWS environment within a compressed four-week timeline. The engagement required expertise across multiple domains: AWS landing zone architecture, container orchestration, database design, CI/CD automation, and security compliance.
Avahi’s approach of delivering 100% infrastructure-as-code via Terraform, combined with their experience implementing SOC 2-aligned controls, meant Ficus Platforms would receive not just working infrastructure but also the documentation, architecture decision records, and operational runbooks needed for their enterprise architecture review board. The team’s familiarity with modern application stacks (Rust, TypeScript, containerized microservices) enabled them to design infrastructure that matched the application’s requirements rather than forcing architectural
Avahi delivered a comprehensive AWS infrastructure build that established Ficus Platforms’ cloud foundation across three environments.
Multi-Account Landing Zone
The engagement began with deploying AWS Control Tower to create a multi-account organization structure. The architecture includes a Management account for billing and governance, a Security OU containing Log Archive and Audit accounts for centralized logging and security findings, and a Workloads OU with separate Development, Staging, and Production accounts. This structure provides blast radius isolation, ensuring a security incident or misconfiguration in one environment cannot propagate to others.
IAM Identity Center provides single sign-on access with permission sets scoped per role and account. Developers receive PowerUserAccess in Development and ReadOnlyAccess in Staging and Production, while infrastructure changes require elevated permissions. Control Tower guardrails enforce baseline security: denying root user access, preventing accounts from leaving the organization, and blocking CloudTrail from being disabled.
Containerized Microservices Architecture
The backend was split into two independently deployable ECS Fargate services. The user-svc handles beneficiary-facing API requests from the mobile app and web portal, while the admin-svc serves the administrative interface. Each service has its own Docker image, ECR repository, ECS task definition, security group, and auto-scaling policy.
The container strategy uses multi-stage Docker builds with cargo-chef for Rust dependency caching, producing minimal distroless images (approximately 200MB) that run as non-root users. A single Dockerfile builds both services via a build argument, ensuring consistency while enabling independent deployability. ECS services are configured with target-tracking auto-scaling (CPU 70%, Memory 75%) with minimum 1 and maximum 4 tasks, plus deployment circuit breakers that automatically roll back failed deployments.
Database and Data Layer
Aurora PostgreSQL Serverless v2 provides the relational datastore, configured with automatic scaling from 0.5 to 4 ACUs. The database runs in private subnets across two Availability Zones, with KMS encryption at rest and TLS connections in transit. Development uses a single instance for cost optimization, while production is configured for Multi-AZ deployment with read replicas for high availability.
Row-Level Security policies enforce multi-tenant data isolation at the database layer. The organization_id from Clerk JWT tokens is set via SET LOCAL within each database transaction, and RLS policies filter rows automatically. This provides defense-in-depth: even if application code contains a bug, the database engine prevents cross-tenant data leakage.
Networking and Routing
Each environment has a dedicated VPC with public and private subnets across two Availability Zones. Application Load Balancers in public subnets terminate TLS (using ACM-managed certificates with TLS 1.3) and route traffic based on path: /admin/* routes to the admin-svc target group, while all other traffic routes to user-svc. NAT Gateways in public subnets provide egress for private resources.
The architecture includes CloudFront distributions with WAF at the edge for geographic restrictions and IP allowlisting on the admin service. API Gateway provides additional throttling, usage plans, and request validation in front of the ALB.
CI/CD Automation
Two GitHub Actions pipelines automate infrastructure and application deployments. The Terraform pipeline handles infrastructure changes with format validation, linting, and plan output, using S3 for state storage and DynamoDB for state locking. Manual approval gates control promotion from Development to Staging (one approval) and Staging to Production (two approvals).
The application pipeline builds Docker images for both services, runs security scans via Trivy, pushes to ECR, and deploys to ECS with automatic rollback on health check failures. GitHub OIDC federation provides AWS access without long-lived credentials. A dedicated migration ECS task runs SQLx database migrations before service updates, ensuring schema changes complete successfully before new application code deploys.
Security and Compliance
SOC 2-aligned controls were enabled from day one. Security Hub aggregates findings across all accounts with conformance packs aligned to SOC 2 criteria. GuardDuty provides threat detection, AWS Config monitors resource compliance, and CloudTrail captures API activity to the centralized Log Archive account. All secrets (database credentials, Clerk JWT keys, SSN pepper for PII hashing) are stored in AWS Secrets Manager with KMS encryption and injected into ECS tasks at launch time.
Observability
CloudWatch provides centralized logging with Container Insights for ECS metrics. Per-service dashboards display latency, error rates, and health status. AWS X-Ray integration enables distributed tracing across services. Alarms are configured to support automated rollback and operational awareness.
AWS Control Tower multi-account landing zone with Development, Staging, and Production environments
Two independently deployable ECS Fargate services (user-svc and admin-svc) with auto-scaling
Aurora PostgreSQL Serverless v2 with Row-Level Security for multi-tenant isolation
VPC architecture with public/private subnets across two Availability Zones per environment
Application Load Balancers with path-based routing and TLS 1.3 termination
CloudFront distributions with WAF for edge security and geographic restrictions
API Gateway with throttling, usage plans, and request validation
GitHub Actions CI/CD pipelines for Terraform infrastructure and application deployments
ECR repositories with scan-on-push and lifecycle policies
Secrets Manager integration for credential management
SOC 2-aligned security controls: Security Hub, GuardDuty, AWS Config, CloudTrail
IAM Identity Center with role-based permission sets
CloudWatch dashboards, alarms, and X-Ray distributed tracing
Architecture Decision Records documenting key design choices
Operational runbooks and knowledge transfer documentation
The engagement transformed Ficus Platforms from having no cloud infrastructure to operating a fully functional, SOC 2-aligned AWS environment in four weeks. The engineering team can now ship features independently for each service without deployment conflicts or full-service restarts.
The multi-account structure provides clean audit boundaries that satisfy SOC 2 CC6.1 (logical access) and CC6.6 (network segmentation) requirements, simplifying evidence collection for their compliance journey. Database-level Row-Level Security enforcement provides an auditable isolation boundary for multi-tenant data, addressing a key enterprise architecture criterion.
The infrastructure-as-code approach means Ficus Platforms can extend and modify their environment independently. All Terraform modules are reusable across environments, and the CI/CD pipelines support the same container image promoting from Development through Staging to Production without rebuilds. New environments or sandbox accounts can be provisioned through Account Factory in under 30 minutes.
Let’s explore your high-impact AI opportunities together in a complimentary session
