Introduction
The client is a housing-finance NBFC (BFSI) that relies on a purpose-built customer relationship management platform to manage its customer engagement, service, and analytics needs. The platform is a multi-component system comprising a CRM application (React front end and PHP back end), a GenAI-powered assistant, and an analytics module, delivered as a SaaS-style application running on containerised, cloud-native infrastructure.
- As the client's operations scaled, the business needed a DevOps-compliant, cloud-native deployment that could meet the resilience, security, and regulatory standards expected of a BFSI-critical system. CitiusCloud was engaged, under the formal scope of the agreed engagement, to design, deploy, and operationalise the platform on Amazon EKS with end-to-end DevOps delivery, covering everything from CI/CD automation to disaster recovery and compliance controls.
Problem Statement (Challenges)
Prior to the engagement, the platform was released through manual, inconsistent deployment processes. Releasing a multi-component CRM by hand was slow and error-prone, and there was no repeatable, standardised path for moving changes across environments.
- As a BFSI-critical workload, the platform also carried significant business risk if it experienced downtime or data loss. It required multi-AZ resilience and a tested disaster-recovery posture with minimal RTO/RPO, and the team additionally had to manage variable, campaign- and month-end-driven traffic peaks that demanded elastic scaling without over-provisioning infrastructure, on top of their core operational responsibilities.
- The absence of an automated, governed deployment process also meant limited consistency in monitoring and auditability, which increased operational risk. This was compounded by the urgency of meeting RBI/NBFC, DPDP, and ISO/SOC 2 regulatory obligations, which demanded strong workload isolation, encryption, auditability, and least-privilege access before the platform could be considered production-ready for a regulated BFSI environment.
Solution Proposed
The proposed solution was to re-platform the CRM as a fully containerised, cloud-native application on Amazon EKS, with each component isolated and deployed through an automated, repeatable DevOps pipeline. The approach was sequenced to first establish a stable, namespace-isolated container foundation, then layer automated CI/CD, elastic scaling, resilience, and security/observability controls on top of it.
- As part of the solution, the CRM (React front end, PHP back end, scheduler and worker pods), the GenAI assistant (FastAPI and a vector store on Amazon Bedrock), and the analytics module were deployed as containerised workloads across multiple Availability Zones, isolated using Kubernetes namespaces. An automated CI/CD process was established using Helm and Kubernetes manifests, with container images built and pushed to Amazon ECR and deployed via versioned Helm charts, supported by runbooks.
- On the architecture and resilience side, Horizontal Pod Autoscaler and KEDA were configured to scale pods on CPU, memory, and custom metrics, while managed node groups (Auto Scaling Groups) scaled EC2 workers and an Application Load Balancer distributed traffic across AZs with TLS termination. High availability and disaster recovery were addressed through RDS MySQL Multi-AZ with a cross-region replica, S3 Cross-Region Replication, and ECR replication into a warm-standby (pilot-light) DR region.
- BFSI-grade security and observability were built in through AWS WAF and Shield, TLS 1.2/1.3, KMS (AES-256) encryption, least-privilege IAM, SSO/MFA/RBAC, Bedrock access over PrivateLink, and centralised CloudWatch/CloudTrail logging with SIEM integration.
Services Used
The solution was delivered primarily on Amazon EKS, using Kubernetes and Helm to containerise and orchestrate the CRM, GenAI assistant, and analytics workloads. Amazon Bedrock, together with a vector store, powered the GenAI assistant, while Amazon RDS (MySQL) and Amazon S3 provided the platform's database and storage layers respectively.
- Delivery and scaling were supported by Docker and Amazon ECR for container image builds and CI/CD, HPA/KEDA and Auto Scaling Groups for elastic scaling, and an Application Load Balancer with ACM for secure traffic distribution. Networking and security were reinforced through VPC, Site-to-Site VPN, PrivateLink, IAM, KMS, and AWS WAF + Shield, while CloudWatch and CloudTrail worked together to provide centralised monitoring, logging, and audit trails across the environment.
Benefits
The engagement replaced manual, ad hoc releases with automated, Helm-based CI/CD, giving the client a repeatable and low-risk deployment process across environments. Pod- and node-level autoscaling (HPA, KEDA, and Auto Scaling Groups) allowed infrastructure capacity to elastically match campaign and month-end traffic peaks, avoiding the cost of over-provisioning while maintaining performance during demand spikes.
- Beyond the measurable process improvements, the client gained a materially stronger resilience and compliance posture: multi-AZ high availability with a cross-region, warm-standby DR setup reduced downtime and data-loss risk for a business-critical BFSI system, while encryption, least-privilege IAM, MFA/RBAC, and centralised audit logging brought the platform in line with RBI, DPDP, ISO 27001, and SOC 2 expectations.
- Centralised logging, SIEM integration, and documented runbooks also gave the operations team greater day-to-day confidence and clearer visibility for monitoring and incident response.
