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

Highly Available AWS Architecture

More than one of everything that matters, and a failover somebody has actually performed.

Price and scope

From $849

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

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

What moves it up

  • A stateful application, where the state has to move somewhere before anything else can
  • A database failover that has to be tested rather than assumed
  • A recovery time objective somebody outside engineering has committed to

Some of this you can check yourself, right now, for free: Downtime Cost Calculator →

Multi-AZ on the database onlyTwo availability zones. The first holds the single application instance, the RDS primary and session state in local memory. The second holds only an RDS standby that has never been failed over, with no application instance beside it.AVAILABILITY ZONE Aapplication instancethe only oneRDS primarysessions in memoryAVAILABILITY ZONE Bno application instance hereRDS standbynever failed over,so it is a beliefreplicating
Highly Available AWS Architecture

What actually goes wrong

Multi-AZ gets switched on for RDS, and from that point the system is described as highly available. The application tier is still one instance in one availability zone, so the database can survive something the thing in front of it cannot. And nobody has ever performed the failover, which means the standby is a belief rather than a measurement. The detail that turns a successful failover into an outage anyway is almost always session state held in the instance's memory: the infrastructure recovers in ninety seconds and every logged-in user is signed out.

How I find it

  • aws rds describe-db-instances --query 'DBInstances[].[MultiAZ,SecondaryAvailabilityZone]'
  • aws autoscaling describe-auto-scaling-groups --query 'AutoScalingGroups[].[MinSize,AvailabilityZones]'
  • aws rds reboot-db-instance --force-failover, in an agreed window, with the seconds counted
  • Where sessions are stored — checked in the application configuration, not assumed from the framework

What you get

  • At least two availability zones carrying real capacity, not one plus a standby nobody uses
  • Session and upload state moved out of instance memory and off local disk
  • A load balancer with health checks that remove a bad instance rather than balancing onto it
  • A forced failover performed in an agreed window, with the actual recovery time measured and written down
  • A written statement of what survives which failure, and what does not — including the cases still single-homed

Questions

What does this actually protect me against?

One availability zone failing, one instance failing, and one database failing. It does not protect against a whole region going down, a bad deploy, or somebody deleting the data — those are different pieces of work, and conflating them is how people end up paying for one and believing they bought all four.

How much more will it cost to run?

Roughly double for anything that has to exist twice, plus cross-zone data transfer. That is a real number and it is worth checking against what an hour of downtime costs you before you agree to it — sometimes the honest answer is that you should not buy this yet.

Do you test the failover, or just configure it?

Test it. A forced failover in an agreed window, with the recovery time measured rather than quoted from documentation. An untested standby has failed as often as it has worked, and you find out which on the worst possible day.

Is three availability zones better than two?

Rarely, at this size. Three costs meaningfully more in cross-zone traffic and buys protection against a scenario — two simultaneous zone failures — that is far less likely than the deploy that takes you down anyway. Two, done properly, beats three done partially.

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.