Migrating a Global CCaaS Platform to Secure AWS Microservices

Industry: SaaS / Cloud Contact Center as a Service (CCaaS)

Geography: Global — North America, Europe, and international markets

Company size: Mid-market SaaS, B2B Enterprise customers

AWS services: EKS, IAM Identity Center, Organizations, Secrets Manager, Parameter Store, Certificate Manager, VPC, Route 53, EC2, CloudTrail, CloudWatch, Backup

Engagement period: 2023–2024

The customer is a world-leading migration, design, and DevOps framework provider for cloud contact centers, helping enterprise organizations eliminate the time-consuming, error-prone, and costly manual effort involved in delivering customer experience transformations. Founded in 2005 and headquartered in Oxford, UK, the company operates as a B2B SaaS provider serving large enterprises globally, with a focus on the North American market and international enterprise clients across multiple industries. The platform supports configuration auditing, automation, and migration services for organizations moving to or between cloud contact center as a service platforms.

The customer was operating its SaaS platform on a legacy ESXi-based on-premises infrastructure, running a monolithic architecture where a separate virtual machine was provisioned for each enterprise customer instance. All application data — database credentials, API secrets, message queue passwords, and configuration — was stored directly on the EBS drive of each VM instance. This created significant and compounding security risks: credentials were hardcoded in application configuration files, there was no centralized secrets management, no environment isolation between production and non-production workloads, and no mutual authentication between internal services.

As the company prepared to scale its platform and expand its enterprise customer base, this architecture represented an unacceptable security posture. Hardcoded credentials created credential exposure risk at every deployment. The absence of service-to-service authentication meant that a compromised component could move laterally across the platform. The lack of environment separation meant that a development incident could affect live customer data. The VM-per-customer provisioning model was also fundamentally incompatible with the company’s growth trajectory — it could not scale efficiently to a large and growing enterprise customer base without incurring proportionally growing operational and security overhead.

Without migration to a modern, secure cloud architecture, the company risked credential exposure incidents, inability to meet enterprise customer security requirements during procurement reviews, and escalating operational overhead as the customer base grew. The decision was made to migrate the entire platform to AWS with security embedded throughout the new architecture.

Zetta Systems designed and delivered a complete migration of the SaaS platform from the legacy ESXi monolith to a secure, containerized microservices architecture on Amazon EKS, with security controls embedded at every layer of the new platform.

Istio mTLS Service Mesh for Zero-Trust Microservice Communication

The platform was migrated to Amazon EKS with Istio service mesh configured to enforce mutual TLS across all microservices. Every service-to-service connection within the cluster is encrypted and both parties authenticate each other cryptographically — providing a level of network security that goes beyond standard VPC security group controls and eliminates the risk of lateral movement from a compromised service. The Istio configuration is defined as code and deployed via the CI/CD pipeline, ensuring that mTLS policy cannot be accidentally disabled or bypassed.

Full Secrets Migration to AWS Secrets Manager and Parameter Store

All credentials previously stored on ESXi EBS volumes — database passwords, API endpoint secrets, message queue credentials — were migrated to AWS Secrets Manager and AWS Systems Manager Parameter Store. Services access secrets at runtime via IAM Roles for Service Accounts (IRSA), meaning no static credentials exist anywhere in the deployment: not in the codebase, not in container images, not in Kubernetes manifests, and not on any persistent storage volume. The acceptance criterion of 100% of sensitive variables managed through Parameter Store was validated at project closure through deployment audit.

Multi-Account AWS Organization with Jumpcloud SSO Federation

A multi-account AWS Organization was designed and deployed with dedicated accounts for production, non-production, and shared services environments, enforcing environment isolation at the AWS account boundary — the strongest available AWS security control. Jumpcloud was configured as the SSO provider federated to AWS IAM Identity Center, providing centralized identity management across all accounts with no long-term credentials issued to any human user. All access is governed by the customer’s identity lifecycle processes, including automatic access revocation when users leave the organization.

Secure CI/CD Pipeline and Engineer Onboarding

The CI/CD pipeline was fully restructured for the new AWS environment, with GitLab executing automated security scanning via Wiz Code and Amazon Inspector on every merge request before any workload reaches production. Blackchair’s engineering team was fully onboarded to the new architecture, AWS best practices, and operational procedures as part of the engagement — including training on AWS Organizations, Secrets Manager, Certificate Manager, EKS, and S3 governance.

Primary AWS Services Used

• Amazon EKS — container orchestration with IRSA-scoped service account roles and multi-AZ node groups
• AWS IAM Identity Center — centralized workforce SSO with Jumpcloud federation, no long-term credentials
• AWS Organizations — multi-account structure enforcing production/non-production isolation
• AWS Secrets Manager — database and service credentials replacing all EBS-resident static secrets
• AWS Systems Manager Parameter Store — centralized application configuration management
• AWS Certificate Manager — TLS certificates for load balancers and public endpoints
• Amazon VPC — network isolation per account with private subnets for application workloads
• Amazon Route 53 — DNS management for service endpoints
• Amazon EC2 + EKS node groups — compute layer with autoscaling
• AWS CloudTrail — management event audit logging across all organization accounts
• Amazon CloudWatch — application and infrastructure log aggregation and alerting
• AWS Backup — automated backup policies for stateful data stores

100% of sensitive credentials were migrated from hardcoded configuration files and EBS-resident static secrets to AWS Secrets Manager and Parameter Store, with runtime access governed by IRSA-scoped IAM roles. This eliminated credential exposure as an attack vector across the entire platform — replacing an architecture where secrets were stored on VM disk with one where no static credentials exist anywhere in the system.

The Istio mTLS implementation provides cryptographic service identity verification for all inter-service communication, replacing an architecture where services communicated without mutual authentication. The multi-account Organizations structure enforces production and non-production isolation at the AWS account boundary, replacing a shared infrastructure model where environment separation was entirely dependent on application-level controls.

The customer’s engineering team successfully completed the migration and took full operational ownership of the new platform by end of 2024. The platform is now operating in production on AWS, generating approximately $125,000 in annual AWS recurring revenue. The new containerized microservices architecture eliminates the per-customer VM provisioning model, providing a scalable foundation that supports the company’s enterprise growth objectives without the security and operational constraints of the legacy monolith.