Teleglobal designed and deployed a single AWS structure running three separated environments, Production, Testing and Quality Assurance, each on its own Amazon EKS cluster. Every workload sits in a private subnet, traffic reaches the application only through a load balancer behind AWS WAF, and the release pipeline, the analytics pipeline and the machine learning services were all working before handover.

At a glance

What was delivered

About the client

The client builds a software product where machine learning sits in the main path of the application rather than beside it. Models have to train and serve, documents and images have to be read automatically, and event data arrives continuously rather than in a nightly batch. The platform underneath all of that had to carry live traffic and daily development work at the same time, without the two ever meeting. 

What the platform had to support

1. Three environments that behave identically and never touch each other, so a release behaves the same way wherever it lands and a mistake in QA never reaches live data.
2. Managed Kubernetes in every environment with its own worker nodes, because the application runs as microservices and one shared cluster carved up by namespace was not enough separation.
3. Machine learning and analytics inside the platform rather than beside it, with model training, language processing, image analysis, streaming ingestion and SQL analytics all running in the same private network as the application.
4. Security that can be demonstrated, with least privilege access, encryption, managed secrets, edge filtering and alerting configured and tested before the client team started using the platform.

Four architecture decisions

One VPC split into public, private application and private data subnets, carrying three isolated EKS environments.

The solution

Compute and containers

Three Amazon EKS clusters run the containerised microservices, with worker nodes in private subnets in every environment. Amazon ECR stores and versions the images, so the image that passes QA is the one that reaches production rather than a fresh build that only looks the same. Supporting tools including Jenkins, SonarQube, Grafana, Prometheus, Kibana and the OpenVPN access server run on EC2 inside the same private network.

Network and access

An Application Load Balancer in the public subnets is the only way into the application, with AWS WAF filtering requests before they reach it. A NAT Gateway handles outbound traffic, administrators connect through OpenVPN rather than public endpoints, and VPC Endpoints keep service to service calls inside the AWS network.

Data, streaming and analytics

Amazon RDS for PostgreSQL holds relational data with automatic failover and backup retention, DynamoDB carries metadata and transactional records, and ElastiCache for Redis absorbs read pressure. Amazon S3 stores assets, logs, training datasets and backups under lifecycle policies. Kinesis Data Streams and Firehose ingest events into S3 and OpenSearch, AWS Glue transforms them and registers the schema in the Glue Data Catalog, and Amazon Athena queries the result on S3 with standard SQL.

Machine learning, APIs and events

Amazon SageMaker trains, deploys and runs the models, while Amazon Comprehend and Amazon Rekognition add language and image analysis as managed services rather than models the team has to host. Amazon API Gateway exposes the backend, AWS Lambda runs event driven functions, EventBridge triggers work when something happens, SQS queues messages between microservices, and SNS fans out alerts.

Release, monitoring and security

A single pipeline scanning, building and pushing one container image to three separate EKS clusters.

Jenkins runs the pipelines and SonarQube scans the code before packaging, so one pipeline serves all three clusters with the destination as the only difference. Prometheus and Grafana cover metrics, OpenSearch with Kibana centralises logs, and CloudWatch carries alarms. IAM follows least privilege, KMS handles encryption at rest, and Secrets Manager with Parameter Store keeps credentials out of the code.

Services deployed

Validation and handover

Nothing was signed off on the strength of a configuration screen. API endpoints were called, database connections were tested from the workloads that use them, WAF rules were exercised, IAM permissions and security groups were checked against the approved design, and CloudWatch alerts were confirmed to fire. Performance testing and client user acceptance testing both ran before cutover.

The handover pack included the architecture diagrams, an operations runbook and a credential mapping, so the client team could run the platform from the documentation.

Results

The outcome

The client now has three environments that look the same and stay apart. A change can be built, scanned, deployed and tested without going near production, and it lands there on infrastructure that has already run it. Because all three follow one pattern, and because analytics and machine learning already sit inside the same network, growing the platform is a repeat rather than a rebuild.

About Teleglobal International

Teleglobal International is an AWS Partner that designs and delivers production cloud, data and AI infrastructure. Working in cloud and IT transformation since 2016, the company supports clients across BFSI, healthcare, manufacturing and logistics, with delivery from Pune and offices in Mumbai, Gurugram, Dubai, Delaware and Brno.

To plan a build like this one, talk to our team for an architecture review.

Questions we get asked about this build

• Why run Production, Testing and QA as separate AWS environments?
  Separate environments stop test activity from touching live data, and they let a release be proven on the same architecture it will run on. In this build each environment has its own EKS cluster and its own worker nodes, so load, failure or a bad deployment in one cannot reach another.
• How many EKS clusters does a three environment setup need?
  One cluster per environment, so three in total, each with dedicated worker nodes in private subnets. Splitting a single cluster by namespace is possible, but the control plane, the node capacity and the upgrade schedule all stay shared, which is exactly the risk separate clusters remove.
• How is the platform protected when no workload sits on the public internet?
  An Application Load Balancer in a public subnet is the only entry point, and AWS WAF filters requests before they reach it. Every cluster node, database and cache runs in a private subnet. Administrators connect through OpenVPN, and VPC Endpoints keep service to service traffic inside the AWS network.
• How do Jenkins and SonarQube deploy to EKS?
  Jenkins runs the pipeline and SonarQube scans the code before it is packaged. The build produces a container image, pushes it to Amazon ECR, and deploys it to the target EKS cluster. The same pipeline serves all three environments, with the destination cluster as the only variable in it.
• What does an AWS deployment handover include?
  On this engagement the handover covered the architecture diagrams, an operations runbook and a credential mapping, delivered after functional testing, security validation and client user acceptance testing. The client team could run the platform from that documentation rather than depending on the delivery team for context.
• Can this architecture support AI workloads without a redesign?
  Yes. SageMaker, Comprehend and Rekognition already run inside the same private network as the application, and the streaming pipeline through Kinesis, Glue and Athena feeds them. Adding a model or a new data source uses paths that are already built and already tested.