Cloud Architecture & Infrastructure Design

Terraform is an open-source Infrastructure as Code (IaC) tool by HashiCorp that allows cloud infrastructure to be defined in HCL (HashiCorp Configuration Language) files and provisioned, changed, and destroyed via a CLI. Terraform supports all major cloud providers (AWS, Azure, GCP, and 1,000+ others) with provider-specific resource types. Key benefits: reproducibility (the same Terraform code creates identical infrastructure in dev, staging, and production - no 'works on my environment' infrastructure drift), version control (infrastructure changes are Git commits, reviewed like application code), collaboration (pull request reviews for infrastructure changes), disaster recovery (infrastructure destroyed by an incident can be recreated from code in minutes), and change preview (terraform plan shows exactly what will change before applying - no surprises). Terraform state tracks the mapping between code and real cloud resources.

Multi-AZ and multi-region are two different levels of fault tolerance. Availability Zones (AZs) are separate physical data centres within the same geographic region - they have independent power, networking, and cooling, but are close enough (typically 10-60km apart) to maintain synchronous database replication with millisecond latency. Multi-AZ deployment (e.g., RDS Multi-AZ, ECS tasks in 3 AZs) protects against individual data centre failures - the most common cause of cloud outages. Multi-region deployment uses two or more separate geographic regions (e.g., AWS Mumbai and AWS Singapore) for protection against rare region-wide outages, compliance with data residency requirements for international data, and lower latency for globally distributed users. Multi-region is significantly more complex and expensive than Multi-AZ. Most Indian applications need Multi-AZ for their uptime targets; multi-region is reserved for applications requiring near-zero RTO or serving international users.

FinOps (Cloud Financial Operations) is the practice of understanding and optimising cloud spending. Typical cloud cost reduction potential: (1) Reserved Instances / Savings Plans for steady-state compute - 40-60% discount versus on-demand by committing to 1-3 years. (2) Instance rightsizing - reducing oversized instances running at 5-15% utilisation to correctly sized instances - typically 20-40% compute cost reduction. (3) Spot/Preemptible Instances for batch workloads - 60-90% discount versus on-demand (with interruption risk). (4) Storage lifecycle policies - automatically moving S3/Blob objects to cheaper tiers as they age - 40-70% storage cost reduction for archival data. (5) Idle resource elimination - unused load balancers, Elastic IPs, stopped instances with EBS volumes, old snapshots - typically 10-20% waste reduction. Combined, these interventions typically reduce cloud bills 30-50% from their unoptimised state. The right time to apply FinOps is before the bill grows large - implementing cost tagging, budgets, and anomaly alerts at architecture design time.

Kubernetes (K8s) is an open-source container orchestration platform that automates deploying, scaling, and managing containerised applications. Kubernetes manages: scheduling containers onto worker nodes based on resource requirements, health checking and restarting failed containers, scaling container replicas based on CPU/memory or custom metrics (HPA), rolling updates without downtime, service discovery and load balancing between container replicas, secrets and configuration management, and persistent storage for stateful applications. Use Kubernetes when: you have multiple services to deploy independently (microservices), you need fine-grained scaling control per service, you want consistent deployment across environments, your team has DevOps maturity to manage cluster configuration, or you want cloud-provider portability. Consider managed Kubernetes alternatives (ECS Fargate, Azure Container Apps, Cloud Run) when: you have a small number of services, you want less operational complexity, or your team does not have Kubernetes expertise. Kubernetes adds significant operational overhead - it is not the right choice for every application.

Disaster recovery (DR) in cloud is the strategy for recovering application availability and data after a major failure - cloud provider outage, data corruption, accidental deletion, or cyberattack. RTO (Recovery Time Objective) is how long the application can be down during a disaster - defined as a business requirement (how much downtime is acceptable before the business impact is severe?). RPO (Recovery Point Objective) is how much data can be lost - the maximum acceptable gap between the last backup and the failure point. These two parameters determine the DR architecture and cost. DR strategies in increasing cost and complexity: Backup and Restore (RTO: hours; RPO: hours - restore from periodic backup), Pilot Light (RTO: 30-60 minutes - minimal standby infrastructure, scale up on failover), Warm Standby (RTO: minutes - scaled-down live environment), Active-Active Multi-Region (RTO: near-zero - traffic split across regions simultaneously). For most Indian applications, Multi-AZ deployment achieves 99.9% uptime and handles AZ-level failures within seconds - a DR architecture for region-level failures (Warm Standby or Active-Active) is additional complexity and cost that only makes sense when the business cost of a regional outage justifies it.

The compute model choice depends on the workload characteristics: Serverless (AWS Lambda, Azure Functions, GCP Cloud Functions): best for event-driven, infrequent, or highly variable workloads where billing per invocation is cheaper than always-on instances. Limitations: cold start latency (100ms-5 seconds), execution time limits (15 minutes on Lambda), limited local storage, and no long-running processes. Containers without orchestration (ECS Fargate, Azure Container Apps, Cloud Run): best for stateless HTTP services that scale between zero and many instances, benefit from containerised packaging, but do not require Kubernetes complexity. No OS management, pay for container runtime. Kubernetes (EKS, AKS, GKE): best for complex multi-service applications requiring advanced orchestration, custom scheduling, service mesh, or strong cluster customisation. Significant operational overhead. VMs (EC2, Azure VM, GCE): best for workloads requiring OS-level control, legacy applications not containerised, Windows workloads requiring specific Windows features, or hardware access (GPU, FPGA). Choose the lightest model that meets requirements - serverless first, then containers, then Kubernetes, then VMs.

The most common hidden cloud costs that cause bill surprises: (1) Data transfer egress - cloud providers charge for data leaving their network. AWS charges $0.09/GB from EC2 to internet, $0.02/GB between AZs in the same region. A 10TB/month application transferring data across AZs pays $200/month in data transfer alone - invisible until the bill. (2) NAT Gateway - AWS NAT Gateway charges $0.045/hour ($32/month) plus $0.045/GB of processed data. A microservices architecture with 10 services making external API calls can accumulate significant NAT Gateway data processing charges. (3) CloudWatch Logs ingestion - $0.50/GB. An application logging 10GB/day generates $150/month in log ingestion. (4) Elastic IPs - unused Elastic IPs charge $0.005/hour ($3.60/month each). 20 test environment Elastic IPs left after testing = $72/month in idle resource waste. (5) Snapshot storage accumulation - automated RDS snapshots beyond the retention period are billed. Old snapshots from deleted databases continue to charge until explicitly deleted.

Cloud architecture design and review, Kubernetes infrastructure design (EKS/AKS/GKE), Terraform Infrastructure as Code, cloud security architecture, FinOps and cost optimisation, disaster recovery architecture, cloud migration planning and execution, and observability and monitoring architecture.

AWS (primary - most engagements), Microsoft Azure (especially for Microsoft-ecosystem organisations), and Google Cloud Platform (especially for AI/ML and data analytics workloads). Multi-cloud architecture for organisations requiring provider portability.

Yes. Evolution Infosystem designs production-grade Kubernetes clusters on AWS EKS, Azure AKS, and GCP GKE - including cluster autoscaling, HPA, pod topology spread, RBAC, network policies, ingress design, and GitOps with ArgoCD.

Yes. All Evolution Infosystem cloud architecture work is delivered as Terraform Infrastructure as Code - modular Terraform with remote state, CI/CD pipeline (GitHub Actions or Azure DevOps), and code review process for all infrastructure changes.

40% average cloud cost reduction across FinOps engagements - through rightsizing (20-40% compute saving), Reserved Instance purchasing (40-60% discount), storage lifecycle policies, idle resource elimination, and NAT Gateway and data transfer optimisation.