AWS Migration Delhi: FinOps Strategies for Indian Firms

A Gurugram-based D2C brand that moved to AWS in 2024 expected its monthly infrastructure bill to fall from ₹6.5 lakh to about ₹4 lakh. Six months later, it was paying ₹9.2 lakh. The main causes were idle development environments, oversized EC2 instances, unexpected data transfer charges and no clear owner for cloud spend. This happens often across Delhi NCR. Fintech startups in Noida, logistics companies in Okhla and manufacturers in Manesar are moving off ageing data centres, but many are surprised by the first few invoices. For Indian firms, aws migration is now as much a finance decision as a technical one. That is where FinOps comes in.

FinOps is the practice of making engineering, finance and business teams jointly responsible for cloud spending. In India, IT budgets are reviewed closely, GST adds 18% to cloud invoices, and exchange rates can change dollar-based costs from one quarter to the next. A migration without a FinOps plan can remove capital expenditure while creating an operating expense that is hard to control.

I have worked with companies in Connaught Place, Nehru Place, Gurugram's Cyber City and Noida Sector 62. The same pattern keeps showing up: companies that set cost guardrails before moving workloads usually save 25–40% compared with their on-premises baseline. Companies that treat cost optimisation as a later task often spend more. In this first part, you will learn:

• The main migration strategies and what each typically costs in INR
• A step-by-step implementation plan using specific tools and versions
• FinOps best practices, including clear dos and don'ts
• A comparison of migration approaches using practical numbers for Indian businesses

Understanding AWS Migration for Indian Businesses

A successful move to AWS starts with understanding what migration means for your workloads. It is rarely one project. It is a set of decisions about each application: whether to move it, rebuild it, replace it or retire it. For Delhi NCR firms, those decisions also depend on data residency rules, latency to users in North India and the need to report costs clearly to leadership in rupees.

The 7 Rs Framework in an Indian Context

AWS groups migration strategies into the "7 Rs." Each option has a different cost and time profile:

• Rehost (lift and shift): Move virtual machines to EC2 with few or no changes. A Noida-based HR software company moved 40 VMware VMs to the Mumbai region (ap-south-1) in 6 weeks using AWS Application Migration Service. The migration cost was about ₹18 lakh.
• Replatform: Make targeted improvements, such as moving a self-managed MySQL database to Amazon RDS. This often cuts database administration effort by 30–50%.
• Refactor: Rebuild an application to use cloud-native services such as AWS Lambda, Amazon ECS or Amazon Aurora. It costs more at the start, but can reduce long-term running costs by 40–60%.
• Repurchase: Replace an application with SaaS, for example moving from an on-premises Tally setup to a cloud accounting platform.
• Retire: Shut down applications that are no longer needed. In most portfolio reviews I have done in Delhi, 10–20% of applications could be retired.
• Retain: Keep certain workloads on-premises for now, often because of latency needs or RBI-regulated data.
• Relocate: Move VMware workloads with minimal disruption. Before choosing this option, review the current licensing and service terms for VMware on AWS.

Why FinOps Matters From the Start

Moving to the cloud turns large upfront hardware purchases into monthly operating costs. A Delhi manufacturer might spend ₹1.2 crore every five years on servers in a colocation facility in Okhla. On AWS, that becomes a monthly bill that can rise quickly if nobody manages it. Common cost problems I see among Indian firms include:

• Data transfer charges: Data leaving AWS for the internet, or moving between regions, is billed separately. A media company in Film City, Noida, found that about 22% of its bill came from egress.
• Region selection: Mumbai (ap-south-1) and Hyderabad (ap-south-2) help with data localisation, but some services and instance types are available later than in US regions or may cost more. Check current pricing before choosing.
• Currency exposure: AWS prices are set in USD. Although billing through AWS India (AISPL) is in INR, rupee depreciation can still increase costs by 3–5% a year.
• GST: The 18% GST on cloud services must be included in budgets. Registered businesses may be able to claim input tax credit.
• Compliance needs: Banking, insurance and healthcare companies must meet RBI, IRDAI or DPDP Act requirements. These can add costs for encryption, logging and backups.

Seeing cost as a design requirement from the start is what separates planned migrations from expensive surprises.

Implementation Guide

A structured implementation reduces risk and gives you cost visibility at each stage. The approach below is based on the AWS Migration Acceleration Program (MAP), adapted for mid-sized Indian firms with IT teams of 5 to 50 people.

Phase 1: Assess and Plan (Weeks 1–4)

1. Discover your inventory: Use AWS Application Discovery Service or the free Migration Evaluator to collect CPU, memory and storage usage for 2–4 weeks. Many firms find that their servers use less than 20% of available CPU.
2. Build a business case: Compare your current total cost of ownership (TCO), including power, UPS, cooling, AMC contracts and staff, with projected AWS costs. For a typical 50-server setup in Delhi NCR, on-premises TCO is often ₹85–95 lakh a year.
3. Set up a landing zone: Use AWS Control Tower to create a multi-account structure with separate production, staging, development and security accounts. This gives you clear cost separation from the start.
4. Define tagging rules: Require tags such as CostCentre, Environment, Owner and Project, and enforce them with AWS Organizations Tag Policies.
5. Set budgets and alerts: Create AWS Budgets with alerts at 50%, 80% and 100% of the monthly limit, and send them to finance and engineering leads.

Here is a Terraform example (Terraform 1.9.x, AWS provider 5.x) that creates a monthly budget alert:

resource "aws_budgets_budget" "monthly_prod" { name = "prod-monthly-budget" budget_type = "COST" limit_amount = "5000" limit_unit = "USD" time_unit = "MONTHLY" cost_filter { name = "TagKeyValue" values = ["user:Environment$production"] } notification { comparison_operator = "GREATER_THAN" threshold = 80 threshold_type = "PERCENTAGE" notification_type = "FORECASTED" subscriber_email_addresses = ["finops@yourcompany.in"] }
}

Phase 2: Migrate and Optimise (Weeks 5–16)

1. Replicate servers: Install the AWS Application Migration Service (MGN) replication agent on source servers. Block-level replication keeps downtime to a few minutes during cutover.
2. Migrate databases: Use AWS Database Migration Service (DMS) 3.5.x with Change Data Capture to replicate data continuously. Use AWS Schema Conversion Tool when moving from Oracle to PostgreSQL. This can remove Oracle licence costs of ₹25–40 lakh a year.
3. Right-size before cutover: Do not copy on-premises server sizes directly. Use AWS Compute Optimizer recommendations. For example, a server with 16 vCPUs running at 12% utilisation may work well as an m7g.xlarge instance.
4. Estimate costs before deployment: Add Infracost (v0.10.x) to your CI pipeline so developers can see cost changes in every pull request.
5. Test in waves: Start with low-risk internal applications, then move customer-facing systems.

This AWS CLI v2 command checks the previous month's spend by service:

aws ce get-cost-and-usage \ --time-period Start=2026-08-01,End=2026-09-01 \ --granularity MONTHLY \ --metrics "UnblendedCost" \ --group-by Type=DIMENSION,Key=SERVICE \ --region ap-south-1

Run this report weekly during migration so cost problems are caught within days, not at the end of the quarter.

Best Practices for AWS Migration

After working on more than 30 migrations across Delhi, Gurugram, Jaipur and Chandigarh, I have found that successful projects depend less on technical skill and more on consistent habits. The practices below are the ones that most clearly separate controlled cloud spending from runaway bills.

FinOps Practices That Deliver Savings

1. Build a FinOps team early: Include one person each from finance, engineering and product. A Noida SaaS company with this setup reduced its monthly AWS bill from ₹14 lakh to ₹8.6 lakh in four months.
2. Buy commitments in stages: Wait 60–90 days after migration before buying Compute Savings Plans. Start by covering about 60% of your stable baseline, then increase coverage as usage becomes predictable. Savings can reach up to 66% compared with On-Demand pricing.
3. Use Graviton instances: AWS Graviton instances (m7g, c7g, r7g) usually offer 20–40% better price-performance than similar x86 instances. Java, Node.js and Python workloads often move with little or no code change.
4. Schedule non-production environments: Turn off development and QA environments outside office hours (for example, 8 PM–8 AM IST) and on weekends using AWS Instance Scheduler. This alone can reduce non-production compute costs by about 65%.
5. Automate storage tiering: Move infrequently accessed S3 data to Intelligent-Tiering or Glacier Instant Retrieval. A Delhi legal-tech company saved ₹2.1 lakh a month on archived case files.
6. Use Spot Instances where suitable: Batch jobs, CI/CD runners and stateless containers can run on EC2 Spot at up to 90% lower cost.
7. Show costs to teams: Use AWS Cost Explorer, Cost and Usage Reports with Amazon QuickSight, or Kubecost for EKS clusters so teams can see what they spend.

Dos and Don'ts

Dos:

1. Do sign up with AWS India (AISPL) to receive INR invoices and GST-compliant billing.
2. Do enable AWS Cost Anomaly Detection so unusual spending is flagged within 24 hours.
3. Do use VPC endpoints for S3 and DynamoDB to reduce NAT Gateway data processing charges, which can cost about ₹3.75 per GB.
4. Do check the AWS Well-Architected Framework's Cost Optimisation Pillar every quarter.
5. Do negotiate through MAP. Qualifying migrations can receive substantial AWS credits.

Don'ts:

1. Don't copy on-premises server sizes directly. Over-provisioning is the biggest source of waste in migrations.
2. Don't buy three-year Reserved Instances before your usage pattern is clear.
3. Don't leave unattached EBS volumes, old snapshots or unused Elastic IPs running. Together, they can quietly add ₹50,000 or more to a monthly bill.
4. Don't send large volumes of data across regions unless necessary. Keep workloads for Indian users in Mumbai or Hyderabad.
5. Don't treat FinOps as a one-time audit. It is a monthly operating practice.

Comparison Table: AWS Migration Approaches for Indian Firms

The table below compares common approaches for a mid-sized Delhi NCR business with about 50 servers. These figures are indicative, based on typical engagements, and include post-optimisation estimates.

The last row matters most. A rehost migration combined with a well-run FinOps programme can deliver savings close to a replatform project, with lower upfront cost and less risk. For many Delhi firms, this is a practical first step before investing in deeper modernisation.

Advanced Techniques

Scaling Strategies for Cost-Controlled AWS Growth

After the initial aws migration is stable, Indian firms should move beyond basic cloud adoption and build a scaling model that responds to business demand without creating unnecessary expenditure. The most effective strategy is to separate predictable workloads from variable workloads. Predictable applications, such as payroll systems, internal dashboards and scheduled reporting platforms, can run on reserved instances or savings plans. Variable workloads, including ecommerce campaigns, lead-generation portals and seasonal transaction systems, should use flexible compute services such as Amazon EC2 Auto Scaling, Amazon ECS, Amazon EKS or AWS Lambda.

A practical scaling policy should combine time-based and demand-based rules. For example, a Delhi-based retail platform may increase capacity between 10 a.m. and 10 p.m. because customer traffic is consistently higher during those hours. However, it should not keep the same capacity overnight. Target tracking can maintain a selected CPU utilisation or request-per-second threshold, while step scaling can add more instances when traffic rises sharply. Indian companies should also account for sale events, cricket tournaments, examination admission periods and regional festivals because these events can produce sudden demand spikes.

FinOps teams should define a scaling budget before increasing capacity. A campaign owner might receive a monthly cloud limit of ₹4 lakh, with alerts at 70%, 85% and 100% utilisation. Automated controls can pause non-production instances outside office hours, remove unattached elastic IP addresses and terminate temporary test environments after a defined period. Tags such as department, application, environment, business owner and cost centre make it possible to assign every rupee to a responsible team.

For distributed applications, scaling should also include the database, cache, queues and storage layers. Increasing web servers without increasing database connection capacity can create a bottleneck while raising costs. Amazon Aurora Serverless, Amazon DynamoDB on-demand capacity, ElastiCache and Amazon SQS can help applications absorb variable traffic, but each service must be governed through usage limits and architecture reviews. A good rule is to scale the smallest constrained component first, measure the effect and then decide whether additional capacity is justified.

Performance Optimisation and Advanced Expert Tips

Performance optimisation is a FinOps activity because slow systems consume more compute time, create abandoned sessions and increase customer acquisition costs. Indian firms should monitor latency by city, network provider, application endpoint and transaction type. A customer in Mumbai may experience a different response time from a customer in Jaipur because of mobile network conditions, DNS resolution or content delivery configuration. Amazon CloudFront, compression, image optimisation and suitable caching policies can reduce origin requests while improving the experience for users across Indian cities.

Database optimisation often produces the fastest savings. Teams should identify expensive queries, missing indexes, oversized database instances and unnecessary cross-region data transfers. Read replicas can handle reporting traffic, while connection pooling can reduce the need for excessive database capacity. Tables containing old transaction records can be moved to Amazon S3 using a lifecycle policy, with Amazon Athena used for infrequent analysis. This approach can reduce the need to keep all data in high-cost, high-performance storage.

Experts should establish unit economics for every major workload. Instead of looking only at total AWS expenditure, measure cost per order, cost per verified lead, cost per invoice, cost per active user or cost per support ticket. If an application costs ₹18 to process one qualified lead, the marketing and technology teams can jointly decide whether that result is profitable. Cost anomaly detection, AWS Budgets, Cost Categories and regular rightsizing reviews should support this measurement rather than replace business judgement.

Advanced teams can use a multi-account structure with separate production, development, security and shared-service accounts. Service Control Policies can prevent risky configurations, while centralised logging and identity controls improve governance. Spot Instances can reduce costs for fault-tolerant batch jobs, data processing and continuous integration workloads. Graviton-based instances may lower compute costs for compatible applications, but migration should be tested against application libraries and performance requirements. Finally, every optimisation should be validated with a before-and-after measurement. A cheaper resource that causes downtime, slower pages or lost transactions is not a real saving.

Real World Case Study

A Bangalore-based business-to-business technology company approached an AWS migration programme after experiencing unpredictable infrastructure bills and declining campaign performance. The company operated a lead-generation platform used by customers in Bangalore, Hyderabad, Delhi, Mumbai and Chennai. Its application ran on a combination of rented virtual machines, a manually managed MySQL database and local storage. The company had 68 employees, generated approximately 22,000 website sessions per month and depended on paid search and social campaigns for new business.

Before the project, the company spent ₹6.8 lakh per month on infrastructure, advertising technology and emergency support. The peak monthly AWS-equivalent compute and storage requirement was estimated at ₹4.9 lakh, but poor resource scheduling caused the business to pay for unused capacity. Average page response time was 4.8 seconds, the lead form failed for approximately 11.6% of visitors during traffic spikes and the sales team received only 96 qualified leads per month. Marketing expenditure of ₹8.1 lakh produced a return on advertising spend of 1.4x. The board required a measurable improvement without reducing application reliability.

Week 1-2: Discovery

During the first two weeks, the migration team mapped the application, database dependencies, integration points and ownership of each workload. They discovered 34 virtual machines, of which 12 were used only for testing, 7 had average CPU utilisation below 15% and 5 were running continuously despite being required only during business hours. The team also found 2.4 TB of duplicate backups, 640 GB of old log files stored on premium disks and 19 untagged resources that could not be assigned to a department.

Application monitoring showed that the lead form and reporting dashboard generated most database load. A query review identified 23 expensive queries and an absence of indexes on three high-traffic tables. The team defined target metrics: page response time below 2.5 seconds, form failure below 2%, qualified leads above 170 per month and monthly infrastructure savings of at least ₹2.5 lakh.

Week 3-4: Implementation

In weeks three and four, the company created separate AWS accounts for production, development and security operations. The web tier was moved to an Auto Scaling group behind an Application Load Balancer. Static content was distributed through Amazon CloudFront, while encrypted Amazon S3 storage replaced local backup disks. The database was migrated to Amazon Aurora with Multi-AZ resilience, automated backups and a read replica for reporting traffic.

Non-production environments were scheduled to stop at 8 p.m. and restart at 8 a.m. on weekdays. The company committed eligible baseline usage to a Savings Plan, moved archival logs to a lower-cost storage tier and deleted duplicate backups after approval from compliance and finance teams. Mandatory tags were applied to every resource. AWS Budgets and cost anomaly alerts were configured for each account, and the finance manager received weekly cost allocation reports.

Week 5-6: Optimisation

During weeks five and six, engineers created database indexes, rewrote the slowest queries and introduced connection pooling. The application’s image files were compressed and cached at the edge. Queue-based processing was added for email notifications and document generation so that these tasks no longer blocked the lead form. The team also used Graviton-compatible instances for selected services after load testing, reducing compute consumption without changing the customer-facing functionality.

Marketing and technology teams then introduced a cost-per-qualified-lead dashboard. Campaigns that generated traffic but few completed forms were adjusted, while higher-performing campaigns received more budget. This connected infrastructure optimisation with commercial performance. A controlled load test simulated 2.5 times the normal peak traffic and confirmed that capacity could scale without manual intervention.

Week 7-8: Results

By weeks seven and eight, average page response time had improved from 4.8 seconds to 2.3 seconds, representing a 47% improvement. Form failures declined from 11.6% to 1.8%, and monthly qualified leads increased from 96 to 183. The company saved ₹3.2 lakh per month through rightsizing, scheduling, storage lifecycle policies, committed-use discounts and query optimisation. Advertising efficiency improved as more visitors completed forms, increasing ROAS from 1.4x to 2.7x.

The case demonstrated that FinOps is not simply a cost-cutting exercise. The company reduced waste while improving speed, reliability and lead conversion. Because the savings were tied to measurable business outcomes, department heads continued participating in monthly cloud reviews instead of treating the AWS migration as a one-time technology project.

Common Mistakes to Avoid

1. Migrating Without Resource Ownership

Moving workloads without assigning an owner leads to forgotten instances, uncontrolled storage and unclear accountability. In a mid-sized Indian business, this mistake can create an avoidable cost impact of ₹60,000 to ₹1.5 lakh per month. To avoid it, require tags for application, team, environment, owner and cost centre before production deployment. Every budget alert should reach both the technical owner and the finance representative.

2. Choosing Oversized Resources at the Start

Teams often select large EC2 instances or databases because they fear performance problems. If the selected capacity is twice the actual requirement, the organisation may waste ₹1 lakh to ₹3 lakh during the first quarter alone. Begin with measured workloads, use load testing and review CPU, memory, network and storage metrics after two to four weeks. Rightsizing should be based on peak behaviour and business risk rather than guesswork.

3. Ignoring Data Transfer and Storage Lifecycle Costs

Data transfer between availability zones, regions and third-party services can add ₹40,000 to ₹2 lakh per month for data-heavy applications. Keeping old backups and logs on premium storage can add another ₹50,000 or more. Teams should map data flows, keep services in suitable availability zones, compress large payloads and define lifecycle rules. Frequently accessed data, archive data and compliance-retention data should not use the same storage class.

4. Treating Non-Production Environments as Permanent

Development, testing and demonstration environments frequently run continuously even when nobody uses them. For a company with several engineering teams, this can cost ₹80,000 to ₹2.5 lakh each month. Automated schedules, temporary environment expiry dates and infrastructure-as-code destruction workflows can prevent this waste. Exceptions should require approval with a named expiry date, not an informal request to keep resources running.

5. Optimising Cost Without Measuring Application Performance

Reducing instance size or database capacity without observing user impact can cause slow pages, failed transactions and lost sales. The direct cloud saving may be ₹75,000 per month, but lost leads and customer complaints can cost ₹3 lakh to ₹10 lakh. Every cost change should therefore include performance thresholds, rollback procedures and a post-change review. Monitor response time, error rate, conversion rate and revenue alongside AWS billing data so that savings do not hide operational damage.

Frequently Asked Questions

What does aws migration mean for an Indian business?

Aws migration means moving applications, databases, files, integrations and related operations from existing infrastructure to Amazon Web Services. For an Indian business, it should include more than relocating servers. The process should evaluate data residency expectations, GST-related records, customer privacy, local support requirements, connectivity across Indian cities and the financial effect of variable usage. A successful migration defines which workloads should be rehosted, modernised, rebuilt or retired. It also establishes tagging, budgets, security controls, backup policies and ownership before resources are created. When planned properly, aws migration can improve application availability, support rapid expansion and provide better cost visibility. When treated as a simple server move, it may transfer existing inefficiencies to the cloud and create higher monthly bills.

How much does an AWS migration cost in India?

The cost depends on application complexity, data volume, downtime requirements, security controls and the migration approach. A small business with a few websites may spend ₹2 lakh to ₹8 lakh on assessment, configuration, testing and cutover. A medium organisation with multiple databases and integrations may require ₹12 lakh to ₹40 lakh for professional services, temporary infrastructure and application changes. Large enterprises can spend substantially more over several phases. Monthly AWS consumption is separate from migration project fees and may range from ₹50,000 to several lakhs. Indian firms should prepare a total-cost model covering compute, storage, data transfer, monitoring, support, licences and staff training. A staged migration with clear success metrics generally controls risk better than a rushed all-at-once transition.

How can FinOps reduce AWS bills after migration?

FinOps reduces AWS bills by bringing engineering, finance and business teams into a shared operating process. The first step is visibility through account separation, mandatory tags, Cost Categories, budgets and regular reports. Teams then remove idle resources, schedule non-production environments, rightsize compute, select suitable storage classes and use Savings Plans for predictable usage. They can also improve application efficiency by optimising database queries, caching static assets and reducing unnecessary data transfer. The most mature organisations measure unit costs such as cost per order or cost per qualified lead, rather than focusing only on the total bill. FinOps should not automatically choose the cheapest resource. It should find the best balance among cost, availability, performance, security and business value, with every major change reviewed against measurable outcomes.

Should an Indian company choose one AWS Region or multiple Regions?

Most organisations should begin with a primary region that meets application latency, compliance and service availability requirements. A single-region design is often simpler and more affordable for smaller Indian businesses, especially when it uses multiple availability zones for resilience. Multiple regions may be appropriate for disaster recovery, national-scale services, contractual requirements or applications serving users outside India. However, multi-region architecture introduces additional costs for replicated storage, data transfer, monitoring, testing and operational support. Before selecting it, calculate the business impact of downtime and define recovery time and recovery point objectives. A company serving customers mainly in Bangalore, Delhi and Mumbai may obtain excellent performance from a well-designed regional deployment with CloudFront and resilient availability zones, without immediately paying for full active-active infrastructure.

What security controls should be included in AWS migration planning?

Security planning should begin before workloads are moved. Indian firms should use least-privilege IAM roles, multi-factor authentication, separate accounts for production and non-production, encryption at rest and in transit, centralised logging and tested backups. Security groups and network access controls should allow only required traffic, while private subnets should protect databases and internal services. AWS CloudTrail, Amazon GuardDuty, AWS Config and security alerts can improve visibility, but they must be monitored by an accountable team. Sensitive customer and financial data should be classified, retained only as long as required and accessed through auditable processes. Regular vulnerability scans, patch schedules, incident response exercises and restore tests are equally important. Security controls should be documented in the migration runbook so that they are not postponed until after the cutover.

How long does a typical AWS migration take?

A small, well-documented application may be migrated in four to eight weeks, including assessment, design, testing and production cutover. A medium business with legacy databases, third-party integrations and strict availability requirements may need three to six months. Enterprise programmes commonly run in multiple waves over six to eighteen months. The timeline depends on the quality of documentation, application dependencies, data volume, testing capacity and the selected strategy. Discovery should identify technical and operational risks before a date is promised. A pilot workload can validate networking, monitoring, security and deployment processes. Subsequent waves should use lessons from the pilot and include rollback plans. Indian teams should also schedule cutovers around business cycles such as financial closing, festival sales, examination admissions and other periods when downtime would have a high commercial cost.

Conclusion

Aws migration can help Indian firms build faster, more resilient and financially accountable technology platforms when it is managed as a business transformation rather than a simple infrastructure move. The Bangalore case shows that disciplined FinOps, performance engineering and ownership can deliver a 47% improvement, save ₹3.2 lakh each month, generate 183 qualified leads and increase ROAS to 2.7x. The central lesson is to connect every cloud rupee with an application owner and a measurable business result.

1. Complete a workload discovery exercise, document dependencies and establish baseline metrics for cost, speed, availability, conversion and security.
2. Create a governed AWS foundation with separate accounts, mandatory tags, budgets, access controls, backup policies and automated environment schedules.
3. Review performance and unit economics every month, then apply rightsizing, storage lifecycle policies, committed-use discounts and architecture improvements based on measured evidence.