About Expertise Work Managed Apps
Business Website Online Store Sales CRM Team Drive Online Academy Newsletter System Booking System Shared Inbox Knowledge Base Short Links Business Manager Photo Gallery Survey Platform Community Forum Project Boards Estate Agency Car Workshop Restaurant Clinic Photography Studio
AWS
Assess & advise Build & migrate Automate & operate Secure & comply Urgent & go-live
Projects
Hosted Monitoring & Dashboards Self-Hosted Observability Stack Bulk Document Data Extraction Email Deliverability Diagnosis & Repair SEO Migration Recovery AWS Security Review VPS Hardening & ModSecurity Cloud Architecture & Resilience Review SSL & Server Configuration Container Security Review DNS & Email Troubleshooting DevOps Deployment & Rollback Review WordPress Hardening Retainer Data Pipeline Rerun Review Metric Reconciliation
Free Tools
Website Health Check Email Domain Health Check DNS Health Check SSL Certificate Checker Redirect Chain Checker Robots.txt Checker XML Sitemap Validator Docker Compose Checker WordPress Security Check AWS IAM / S3 Policy Checker Domain Registration Lookup Uptime Monitoring Trial Downtime Cost Calculator AWS Cost Estimator Cloud Architecture Self-Assessment DevOps Engagement Builder Self-Managed VPS vs Managed AWS
Blog Certifications Hire Me

AWS Auto Scaling & Rightsizing

Capacity that follows demand, and instances sized for the load you have rather than the one you feared.

Price and scope

From $399

Typically $399–$849, fixed in writing before anything starts.

2–4 days
Working days, counted from the moment I have access — not from the day you agree.

What moves it up

  • Spot adoption, which needs interruption handling before it is safe to rely on
  • A stateful tier, where removing an instance is not simply a capacity decision
  • Traffic with a shape — a daily peak or a weekly one — that the policy has to anticipate

Some of this you can check yourself, right now, for free: AWS Cost Estimator →

Scaling on a metric that is not the constraintA chart over one day. CPU utilisation stays flat around thirty per cent while response time climbs steadily. The scale-out threshold is set at seventy per cent CPU, so the group never scales, even though the service is degrading.one day of trafficscale-out threshold: CPU 70%CPU, flat at 30%response timethe group never scales, because the metric it watches is not the one degrading
AWS Auto Scaling & Rightsizing

What actually goes wrong

Two mistakes, and most accounts have both. The first is an instance chosen for a peak that happens twice a year and then left running at that size for the other three hundred and sixty three days. The second is subtler: autoscaling configured against CPU for a workload that is not bound by CPU at all. Requests queue behind a database or an external API, CPU stays flat at thirty per cent while response times climb, and the group never scales — then scales out later for a reason unrelated to the problem, which teaches everyone that autoscaling does not work here.

How I find it

  • CloudWatch CPU and memory at p95 over 30 days, against the instance size actually provisioned
  • aws autoscaling describe-policies — what metric the group is scaling on, and whether it is the binding one
  • aws ce get-rightsizing-recommendation, read as a starting point rather than as an answer
  • Request latency against CPU on the same time axis, which is what shows the two are unrelated

What you get

  • Instances resized against measured p95 usage, with headroom stated rather than guessed
  • A scaling policy on the metric that actually gates throughput for this workload
  • Scale-out fast and scale-in slow, so a policy cannot oscillate against its own effect
  • Scheduled capacity where load has a known shape, instead of reacting to a peak already underway
  • Spot capacity where interruption is genuinely survivable, and nowhere else

Questions

How do I know what size my instances should be?

From p95 over a month, not from an average and not from a peak. An average hides the spikes that matter and a peak sizes you for a moment. Where memory is the constraint, that needs the CloudWatch agent installed first, because AWS does not report memory on its own.

Should I use Spot instances?

For anything that can be interrupted with two minutes' notice and restarted elsewhere — batch work, stateless web tiers behind a load balancer, CI runners — yes, and the saving is large. For a database or anything holding a session in memory, no, and no discount makes that a good trade.

Will scaling down risk an outage?

Only if it is done by guesswork. Sizes come down in steps against measured usage with headroom left deliberately, and anything ambiguous gets changed in a window rather than on a Friday afternoon. If a workload has no safe answer, I will say so and leave it.

What about Savings Plans or Reserved Instances?

Rightsize first, commit second — always in that order. A one-year commitment on an oversized fleet locks in the mistake and pays for it in advance, which is the most expensive possible sequence and a genuinely common one.

Want this done?

Tell me what you are running and I will come back with a fixed price and a date. If it turns out you do not need this, I will say that instead.

Prefer to talk? Book a free call ↗  ·  Or hire me on Upwork ↗  ·  Typical reply within one business day.

When I answer

Sunday to Thursday, 09:00–18:00 EET. Outside that I will still look, but I will not promise a time.

No 24/7 desk, and I will not pretend otherwise

One person, one time zone. If round-the-clock cover is what you need, you need a team, and I will say so rather than sell you a plan that cannot deliver it.

Your AWS bill stays yours

You pay Amazon directly and you keep control of the account. Nothing here resells your infrastructure or sits between you and your own billing.

A price that starts with "from" is a starting price

Every service page lists exactly what pushes a quote above it, before you ask. You get a fixed number in writing before any work begins.