India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Amazon EC2, Auto Scaling & Load Balancing Services in India
Amazon EC2 is AWS's virtual server service, and EC2 Auto Scaling adds or removes those servers automatically behind Elastic Load Balancing as demand changes. NTSPL designs EC2 fleets for Indian companies with spiky or compute-heavy workloads, mixing Graviton, Spot and Savings Plans in the Mumbai and Hyderabad regions so capacity follows real traffic and the monthly bill follows usage.
AWS services in scope
The Problem Amazon EC2 and Amazon EC2 Auto Scaling Solve
Most EC2 estates we audit in India were sized for the worst day of the year and then left alone. A fleet of m5.2xlarge instances runs at 9-14% average CPU for eleven months, then still falls over during a Diwali sale or an exam result because the Auto Scaling group has a five-minute warm-up, a cold AMI and a maximum size somebody set two years ago. The underlying problem is not raw capacity; it is the time between demand arriving and a healthy, registered instance serving it, and the price paid for idle cores in between.
NTSPL treats compute as three separate questions: which instance families and processor architecture fit the workload profile, how fast new capacity can become healthy behind the load balancer, and which purchase model covers each slice of demand. We measure launch-to-InService time, build golden AMIs with EC2 Image Builder, pre-warm with warm pools and predictive scaling, and then layer Compute Savings Plans under the baseline and Spot over the burst, using attribute-based instance selection so the fleet is never pinned to one scarce instance type.
When to Run Workloads on Amazon EC2 Auto Scaling (and When Not To)
Signals that point to compute & scaling on AWS
- Your Auto Scaling group takes more than 4-5 minutes from launch to InService and you see 5xx errors in the first minutes of every campaign or result announcement.
- Cost Explorer shows average EC2 CPU utilization below 20% across the month while peak-day CPU still crosses 85%.
- More than 40% of your EC2 spend is On-Demand with no Savings Plan or Reserved Instance coverage.
- Engineering simulation, rendering or analytics jobs queue for hours on a fixed on-premises cluster before marketing or design deadlines.
- You are running x86 instances for interpreted or JVM-based workloads that have never been benchmarked on Graviton.
- A single instance type is hard-coded in launch configurations and you have hit InsufficientInstanceCapacity errors during a scale-out.
When a different approach is better
- Event-driven code that runs for seconds and sits idle most of the day is cheaper and simpler on AWS Lambda than on an always-on EC2 fleet.
- Teams already packaging microservices as containers and wanting no OS patching should use Amazon ECS on AWS Fargate or Amazon EKS rather than managing EC2 hosts directly.
- A small brochure site or internal tool with a few hundred users a day fits Amazon Lightsail or AWS App Runner better than an Auto Scaling group with a load balancer.
EC2 Building Blocks: Instances, Launch Templates, Auto Scaling Groups and ELB
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Amazon EC2 | Provides the virtual machines, from general-purpose M-family to compute-optimized C-family and memory-optimized R-family instances, that run the application and batch tiers. | The workload needs OS-level control, licensed software tied to a host, or long-running processes that do not fit a container or function model. |
| Amazon EC2 Auto Scaling | Maintains a target fleet size across Availability Zones using target-tracking, step, scheduled and predictive scaling policies, with warm pools for pre-initialized instances. | Request volume swings by more than roughly 3x between quiet and peak hours, or instance health failures need automatic replacement without an on-call engineer. |
| Elastic Load Balancing (Application and Network Load Balancer) | Distributes HTTP/HTTPS traffic with path and host routing (ALB) or TCP/UDP traffic with static IPs and very low added latency (NLB), and health-checks every target. | More than one instance serves the same endpoint, or TLS termination, WAF attachment and slow-start for newly added targets are needed. |
| AWS Graviton (Arm-based EC2 instances) | Runs Linux workloads on AWS-designed Arm processors such as Graviton3 and Graviton4 instance families (for example m7g, c7g, r8g) at a lower price per vCPU than comparable x86 families. | The stack is Java, Node.js, Python, Go, .NET on Linux or open-source databases and the build pipeline can produce arm64 artefacts. |
| Amazon EC2 Spot Instances | Supplies spare EC2 capacity at steep discounts to On-Demand pricing, with a two-minute interruption notice delivered through instance metadata and Amazon EventBridge. | Tasks are stateless, checkpointable or queue-driven, such as simulation solver jobs, CI runners, rendering or horizontally scaled web nodes above the baseline. |
| Savings Plans | Commits to a fixed hourly compute spend for one or three years in exchange for lower rates, with Compute Savings Plans applying across EC2, AWS Fargate and AWS Lambda regardless of family or Region. | There is a predictable floor of compute usage that has held steady for at least two to three months of Cost Explorer history. |
| EC2 Image Builder | Produces versioned, patched and CIS-hardened golden AMIs through a pipeline, so scale-out launches need minimal bootstrap time. | User-data scripts take more than two to three minutes to install packages, or instances drift from the approved baseline over time. |
Multi-AZ elastic compute tier with mixed purchase options
Multi-AZ elastic compute tier with mixed purchase options
Users resolve the domain through Amazon Route 53, pass through Amazon CloudFront and AWS WAF, and reach an Application Load Balancer that spreads requests across an Auto Scaling group running a mixed-instances policy of On-Demand Graviton and Spot capacity in three Mumbai Availability Zones. Background and simulation work is posted to an Amazon SQS queue consumed by a separate Spot-heavy Auto Scaling group, with session and scratch state held in ElastiCache and EFS so any instance can be terminated safely.
Select any component
Multi-AZ elastic compute tier with mixed purchase options: click any of its 10 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
EC2 Engineering Decisions: Graviton, Scaling Metrics, Spot Diversification and Commitments
Instance family and Graviton selection
We benchmark the actual application, not a synthetic test, on three candidates: the current x86 family, the matching Graviton family and one generation newer. JVM and Node.js services usually move to Graviton with only a rebuild, while workloads with x86-only binaries, some commercial agents or Windows stay on Intel or AMD. If Graviton delivers equal or better p95 latency at a lower hourly rate, we move it; if the saving is under roughly 10% after porting effort, we defer.
Scaling metric and policy design
CPU utilization is a lagging signal for web tiers, so we prefer target tracking on ALB RequestCountPerTarget, set from load-test results at about 70% of the per-instance breaking point. Predictive scaling is enabled once at least 24 hours, and ideally 14 days, of history exists, and scheduled actions raise the minimum size ahead of known events such as sale launches or exam slots. Scale-in is deliberately slower than scale-out, with cooldowns of 300 seconds or more.
Spot strategy and interruption handling
Spot is used only where an instance loss costs seconds of rework, not an outage. We spread across at least six instance types using attribute-based selection on vCPU and memory ranges, choose the price-capacity-optimized allocation strategy, and enable capacity rebalancing. Applications handle the two-minute notice by draining from the target group and checkpointing. For web tiers we cap Spot at around 50-70% of capacity above an On-Demand base so a regional capacity crunch never removes the floor.
Commitment mix: Savings Plans vs Reserved Instances
We size commitments to the lowest sustained hourly spend over the last 60-90 days, not the average. Compute Savings Plans are the default because they float across instance families, Regions and Fargate or Lambda, which protects a Graviton migration. EC2 Instance Savings Plans are used only where a family is fixed for three years. Coverage targets are typically 60-75% of steady usage, reviewed quarterly, leaving Spot and On-Demand for the variable remainder.
Time-to-healthy engineering
The scale-out that matters is measured from the scaling decision to the instance passing ALB health checks. We cut this by baking dependencies into Image Builder AMIs, keeping user data under 30 seconds, using warm pools for applications with long cache or JIT warm-up, and setting health check grace periods from measured boot time. A target we often set is under 90 seconds launch-to-InService for web tiers.
How NTSPL Rolls Out an EC2 Auto Scaling Tier
Per-instance load ceiling test
Load-test one instance of each candidate family, x86 and Graviton, to find the request rate at which p95 latency breaks, which becomes the target-tracking value.
Golden AMI pipeline
Build EC2 Image Builder recipes for arm64 and x86 that bake runtimes and dependencies, run Amazon Inspector scans and publish a new launch template version.
Launch template and mixed-instances group
Define attribute-based instance requirements, IMDSv2, encrypted gp3 volumes and an On-Demand base with price-capacity-optimized Spot above it across three Availability Zones.
Scaling policies, warm pool and health checks
Configure target tracking on ALB RequestCountPerTarget, scheduled and predictive scaling, warm pool size and a health check grace period set from measured boot time.
Spot drain and instance refresh rehearsal
Inject Spot interruptions with AWS Fault Injection Service and run an instance refresh at 90% minimum healthy to prove that capacity loss and AMI rollouts cause no errors.
Savings Plan sizing after 30 days
Read the new baseline from Cost Explorer once the fleet has run for a month and buy a Compute Savings Plan for the lowest sustained hourly spend.
What you receive
Hardening EC2 Fleets: IMDSv2, Instance Profiles, Session Manager and AMI Scanning
The EC2 attack surface is the instance itself: its metadata endpoint, its open ports, its credentials and its unpatched packages. NTSPL removes SSH keys and bastions in favour of Session Manager, enforces IMDSv2 to block SSRF-based credential theft, attaches least-privilege instance profiles per Auto Scaling group, and keeps every instance in private subnets behind the load balancer. AMIs are rebuilt and scanned so a scale-out never launches a server missing last month's patches.
- IMDSv2 required with hop limit 1, preventing SSRF attacks from reading instance role credentials
- Amazon Inspector continuous scanning of EC2 instances and AMIs for CVEs, gated in the Image Builder pipeline
- EBS encryption by default with customer managed AWS KMS keys per environment
- Security groups that reference the ALB security group, not CIDR ranges, for application ports
- AWS Systems Manager Session Manager with session logging to Amazon S3 instead of port 22
EC2 Pricing Levers: On-Demand, Compute Savings Plans, Spot and Graviton Rightsizing
EC2 is billed per second for Linux instances by instance type and purchase model, plus attached EBS volumes, public IPv4 addresses and data transfer; load balancers add hourly and capacity-unit charges. The biggest savings come from matching each slice of demand to the right purchase model and processor, then shrinking idle time through faster scaling rather than permanently lower capacity.
- Compute Savings Plans for the steady baseline and Spot for stateless burst capacity
- Graviton families for compatible Linux workloads to lower price per request
- Predictive and scheduled scaling to lower minimum fleet size outside business and event hours
- gp3 volumes in place of gp2, provisioning IOPS and throughput independently of disk size
- Releasing unused Elastic IPs and public IPv4 addresses, which are charged hourly
EC2 Auto Scaling vs AWS Fargate vs AWS Lambda: which should run my workload?
Choose by three criteria. Runtime shape: requests that finish in under 15 minutes and arrive in bursts suit Lambda; long-running services suit EC2 or Fargate. Packaging: if the application is already containerized and the team does not want to patch operating systems, Fargate removes host management at a higher per-vCPU rate; if you need custom kernels, GPUs, Windows licensing, specific instance storage or the deepest Spot and Graviton discounts, EC2 wins. Utilization: at high, steady utilization EC2 with Savings Plans is usually the cheapest per unit of compute, while Lambda is cheapest when traffic is low or intermittent. Many NTSPL designs mix them: EC2 for the core application and batch solvers, Fargate for side services and Lambda for event glue.
Key facts about compute & scaling on AWS
Compute & Scaling on AWS in Practice
3 compute & scaling scenarios from D2C e-commerce (fashion and lifestyle), Automotive components manufacturing, EdTech (online assessments and proctored exams): the starting position, the services chosen, the architecture, the rollout and the measured outcome.
D2C fashion brand absorbs 14x festive flash-sale traffic with zero checkout outages
Auto components maker cuts CAE simulation queue from 3 days to 6 hours with Spot bursts
Online exam platform holds 2.2 lakh concurrent candidates with predictive scaling
Pharma distributor runs SQL Server ERP on RDS Multi-AZ and cuts DB recovery to minutes
Stock broker builds dual-location Direct Connect for trading apps with sub-second failover
Compute & Scaling on AWS: Frequently Asked Questions
How much can Spot Instances actually save compared to On-Demand?
AWS states Spot Instances can cost up to 90% less than On-Demand, though the real discount varies by instance type, Availability Zone and time. In our designs blended savings on Spot-eligible tiers typically land between 50% and 70% because we diversify across many instance types and keep an On-Demand base. Spot suits work that can tolerate a two-minute interruption notice.
Should we buy Savings Plans or Reserved Instances for EC2?
For most Indian mid-size estates, Compute Savings Plans are the better default because the discount follows you if you change instance family, move to Graviton, shift Regions or move workloads to Fargate or Lambda. EC2 Instance Savings Plans give a deeper discount but lock you to one family in one Region. We usually commit only to the lowest sustained hourly usage and top up quarterly.
Can we move our on-premises VMware or Hyper-V servers to EC2 without rewriting them?
Yes. AWS Application Migration Service replicates on-premises servers block by block to EC2 and lets you run non-disruptive test launches before cutover. NTSPL usually rehosts first, right-sizes using two to four weeks of CloudWatch data, and only then introduces Auto Scaling, which requires the application to keep session state off the instance.
Which AWS Region in India should host our EC2 workloads?
Asia Pacific (Mumbai), ap-south-1, has the widest range of instance families and Availability Zones and is the usual primary choice. Asia Pacific (Hyderabad), ap-south-2, gives a second in-country Region for disaster recovery, which helps organizations that want data processed within India under the DPDP Act 2023 or sector rules from regulators such as RBI. We verify instance family availability in Hyderabad before designing DR.
How fast can EC2 Auto Scaling react to a sudden traffic spike?
Scaling decisions happen within a minute or so of the metric breaching, but the real limit is how long a new instance takes to pass health checks. With golden AMIs and warm pools we typically bring web tiers to under 90 seconds. For spikes that arrive faster than that, such as a sale opening at a fixed time, we use scheduled actions and predictive scaling to add capacity in advance.
Is moving to Graviton risky for an existing application?
The risk is mostly in dependencies, not your own code. Interpreted and JVM languages typically run unchanged on arm64; native libraries, older agents and some commercial software may need arm64 builds. NTSPL runs a compatibility scan and a side-by-side canary behind the same load balancer, sending 5-10% of traffic to Graviton targets before committing.