At a Glance
| EC2 INSTANCES 4 total: Frontend (C6a), Backend (C6a), API (C6a), Bastion (T3a) | ARCHITECTURE 3-tier: Frontend, Backend with MySQL, API | REGION Asia Pacific (Mumbai), ap-south-1 |
| DATABASE MySQL on Backend EC2, restricted to app-tier only | DNS + SECURITY Route 53 + AWS WAF + ALB | MONITORING CloudWatch with proactive alerting |
Executive Summary
The client operates an order management platform that processes transactions across multiple sales channels. The application runs as a 3-tier stack: frontend, backend with MySQL, and an API layer for external integrations.
Teleglobal provisioned the full AWS environment in the Asia Pacific (Mumbai) region. The deployment covers 4 EC2 instances across public and private subnets, Route 53 with ALB and WAF for traffic routing and protection, self-managed MySQL with network-level access restrictions, and a security layer spanning IAM, KMS, Secrets Manager, and CloudWatch.
The Problem
Production application without production infrastructure
The platform was ready for production but had no secure hosting environment. The three application tiers each have different network access requirements. The frontend needs internet traffic, while the backend and API layers should never be directly reachable from outside.
Database access that needed strict boundaries
MySQL runs directly on the backend EC2 instance, not as a managed service. Only the application-tier instances should connect to it. A misconfigured security group would expose the database to the entire VPC or the internet. Access rules had to be locked down before the first connection.
No secure path to reach private servers
With all application servers in private subnets, administrators had no way to SSH in for maintenance. The environment needed a Bastion server as the single controlled entry point, locked down to specific source IPs.
What We Built
Network foundation
A VPC in ap-south-1 with two subnet tiers. The public subnet contains the Bastion server (T3a) and NAT Gateway. The private subnet holds all three application servers (C6a). Route tables direct outbound traffic through the NAT Gateway, while the Bastion provides the only inbound administrative path.
Traffic routing and DNS
Route 53 points the client’s domain to the ALB. The ALB distributes requests across Frontend, Backend, and API instances. AWS WAF filters malicious traffic before it reaches any server. The traffic flow is: User > Route 53 > WAF > ALB > EC2 in the private subnet.
Compute and database
Three C6a instances handle frontend, backend, and API workloads in the private subnet. MySQL is deployed on the Backend instance with security group rules restricting access to application-tier instances only. This is enforced at the network level, not just application-level authentication.
Storage
An Amazon S3 bucket handles application data, backups, static website hosting, datasets, and infrastructure state files with lifecycle policies and access controls.
Security and access control
IAM follows least-privilege principles. KMS manages encryption keys. Secrets Manager stores credentials. Security Groups define exact rules for every instance: Bastion accepts SSH only from approved IPs, application servers accept traffic only from the ALB and Bastion, MySQL accepts connections only from the app-tier security group. Learn more about our cybersecurity services.
Monitoring
CloudWatch monitors EC2 instances, VPC flow logs, and S3 access patterns. Proactive alarms cover CPU, memory, disk, and network anomalies.
AWS Services Deployed
| AWS Service | Role in This Deployment |
| Amazon VPC + NAT Gateway | Public and private subnets with route tables and Security Groups in ap-south-1 |
| Amazon EC2 (3x C6a + 1x T3a) | 3 application servers in private subnet, 1 Bastion in public subnet |
| Application Load Balancer + WAF | Traffic distribution with routing rules and web application firewall |
| Amazon Route 53 | DNS resolution pointing the client’s domain to the ALB |
| Amazon S3 | Application data, backups, static hosting, datasets, and state files |
| IAM + KMS + Secrets Manager | Access control, encryption, and credential storage |
| Security Groups | Instance-level firewall rules restricting traffic by source, port, and protocol |
| Amazon CloudWatch | Monitoring, log collection, metrics, and proactive alerting |
Results
| Area | Before | After |
| Compute | No production infrastructure | 4 EC2 instances (3x C6a + 1x T3a) across public and private subnets |
| Network | No subnet isolation | 2-tier VPC with private subnet for app servers, public subnet for Bastion only |
| Database | MySQL with no network-level access control | MySQL on Backend EC2, Security Groups restrict access to app-tier only |
| DNS + Routing | No managed DNS or load balancing | Route 53 > WAF > ALB traffic path with domain-level routing |
| Security | No centralised access control or encryption | IAM least-privilege, KMS, Secrets Manager, Security Groups on every instance |
| Admin Access | No controlled path to reach production servers | Bastion server (T3a) as single entry point, SSH restricted to approved IPs |
| Monitoring | No visibility into instance health | CloudWatch with proactive alarms across EC2, VPC, and S3 |
Roles and Responsibilities
| Activity | Responsibility |
| Infrastructure setup (VPC, EC2, IAM, S3, security) | Teleglobal |
| Testing and validation | Teleglobal and Client jointly |
| Documentation and handover | Teleglobal |
| Application integration | Client |
What Comes Next
Additional EC2 instances can be added behind the ALB as traffic increases. If the client outgrows self-managed MySQL, the same VPC and Security Group structure supports a migration to Amazon RDS with minimal changes. S3 is already configured for static hosting, giving the option to offload assets to S3 and CloudFront at scale.
Teleglobal International is an AWS Partner delivering cloud infrastructure deployments across the Asia Pacific region from its delivery centre in Pune, India. Get in touch.