A hot site is a fully equipped recovery location, with hardware, software, network links and current data already in place, that can take over from your primary site within minutes to hours. It is the fastest and most expensive type of disaster recovery site. In the cloud, the equivalent is a hot standby or active/active setup in a second region.
Key takeaways
- NIST describes hot sites as facilities sized for the system and configured with the necessary hardware, supporting infrastructure and support personnel.
- Its data is updated continuously or shortly after the primary, so little data is lost and recovery is fast.
- Warm sites hold some equipment and need setup before use. Cold sites provide space and power only.
- In AWS terms, this maps to "hot standby" (active/passive at full capacity) or "multi-site active/active", the most complex and costly strategy.
- Replication does not protect against corruption or ransomware. You still need point-in-time backups.
What is a hot site in disaster recovery?
It is an alternate location that already runs, or can run at once, a copy of your production systems. When the primary site fails, you redirect users and carry on working.
The US standard reference is NIST SP 800-34, the Contingency Planning Guide for Federal Information Systems. It defines this site type as having enough equipment, the current production software and adequate storage, with the latest backed-up data loaded. In many cases its databases are updated at the same time as, or soon after, the primary ones. NIST also notes the site needs a way to move users' connectivity quickly, and operational support close to that of the production site.
One NIST example is two identical systems in different locations, both in production, each able to carry the full workload, with data synchronised continuously. NIST calls this the most expensive option.
Hot site vs warm site vs cold site
The three site types differ in how much is ready before a disaster. More readiness means faster recovery and higher running cost.
| Feature | Cold site | Warm site | Hot site |
|---|---|---|---|
| What is in place | Space, power, telecom connections, environmental controls | Some or all hardware, software, telecom and power | Full hardware, supporting infrastructure and staff |
| Data | Restored from backup after the event | Restored or partly replicated | Current or near-current, often replicated continuously |
| Setup time | Long | Medium | Short |
| Cost | Low | Medium | Medium to high |
| Typical use | Systems that can be down for days | Important systems with some tolerance | Systems where minutes of downtime matter |
The setup-time and cost rows follow NIST's sample alternate-site criteria table. Exact recovery times depend on your design and testing, not on the label.
How does a hot site work?
A working setup has four parts that must stay in step with production:
- Infrastructure: servers, storage and network capacity sized for the workload you need to run there.
- Data replication: synchronous or asynchronous copying of databases and files from the primary site.
- Configuration and code: the same software versions, patches and settings as production, ideally deployed from the same infrastructure-as-code templates.
- Traffic switching: DNS, load balancer or network changes that send users to the recovery site when you activate it.
What happens at activation?
Activation is a decision, not just a technical step. The incident lead confirms that the primary site cannot recover within the agreed recovery time objective (RTO), then the team follows the runbook: stop writes to the primary if possible, promote the replica databases, switch traffic, check that the applications work, and tell users and stakeholders. AWS notes that automatic failover on health checks should be used with caution, because a false alarm costs availability and data. Many teams therefore trigger failover manually but automate every step behind the button.
Hot sites in the cloud: hot standby and active/active
In the cloud you rarely rent a separate building. Instead you run a second copy of the environment in another region or Availability Zone. The AWS disaster recovery whitepaper describes four strategies, from cheapest to most complete:
| AWS strategy | What runs in the recovery region | Closest site type |
|---|---|---|
| Backup and restore | Backups only; infrastructure is redeployed after the event | Cold site |
| Pilot light | Data replicated and core services on; application servers switched off | Cold to warm |
| Warm standby | A scaled-down but fully working copy that can take traffic at once | Warm site |
| Hot standby / multi-site active/active | Full capacity, either waiting (active/passive) or serving users (active/active) | Hot site |
AWS calls multi-site active/active the most complex and costly approach, but says it can bring recovery time close to zero for most disasters. It also points out that most customers who build a full second environment end up using it active/active, since they are paying for it anyway.
A cloud setup has two advantages over a physical one. You can test failover without moving staff, and you can rebuild the whole environment from code if something drifts. The trade-off is that you pay for full capacity in two places, plus data transfer for replication.
Is a hot site worth the cost?
Only for systems where the cost of downtime is higher than the cost of running a second environment. Start from a business impact analysis, set an RTO and recovery point objective (RPO) for each system, and match the site type to those targets. Our guide to RPO and RTO shows how to set them.
NIST makes a useful point here: one system can need different strategies for different functions. Order processing may need instant failover, while monthly reporting on the same platform can wait days. Tiering like this keeps the always-on footprint small and the bill manageable.
Checklist before you build one
- Far enough from the primary site that one regional event cannot hit both.
- Capacity for the critical workload, not necessarily for everything.
- Replication lag monitored against your RPO, with alerts.
- Point-in-time backups kept separately, to recover from corruption or ransomware that replication would copy.
- Security controls equal to production: identity, firewalls, logging and encryption.
- A failover runbook with named owners, and a failback plan.
- Regular failover tests, recorded in your disaster recovery plan.
How Opsio helps
Opsio designs and runs cloud disaster recovery on AWS, Azure and Google Cloud, from pilot light to full multi-region setups, and tests failover with your team. For WorkBuster, a global SaaS recruitment platform, we built the AWS environment on Multi-AZ MySQL RDS and auto-scaling, with CloudFormation templates so the infrastructure can be redeployed consistently; read the WorkBuster case.
Frequently asked questions
What is the difference between a hot site and a cold site?
The first has equipment, software and current data ready and can take over quickly. The second has space, power and network connections only, so systems must be installed and restored from backup before work resumes.
How fast can a hot site take over operations?
Typically minutes to hours, depending on how current the data is and how automated the switch is. An active/active cloud setup can bring recovery time close to zero for most failures, but recovery from data corruption still depends on backups.
Is a hot site the same as a mirrored site?
They are close. A mirrored site runs an identical, continuously synchronised copy of production. NIST's example of two identical production systems that each carry the full load is effectively a mirrored site.
Do I need a hot site if I run in the cloud?
Not automatically. Running across several Availability Zones already protects against the loss of one data centre. A second-region hot standby is worth it when regional outages, regulation or contracts require very short recovery times.
What does "hotsite" mean in marketing?
In marketing, especially in Brazil, a "hotsite" is a small temporary website for a campaign or product launch. It is unrelated to disaster recovery.
Written By
Group COO & CISO
Fredrik is the Group Chief Operating Officer and Chief Information Security Officer at Opsio. He focuses on operational excellence, governance, and information security, working closely with delivery and leadership teams to align technology, risk, and business outcomes in complex IT environments. He leads Opsio's security practice including SOC services, penetration testing, and compliance frameworks.
Editorial standards: This article was written by the cloud practitioner named in the byline above. We revise it when the technology or regulation it covers changes; the dates on this page show the latest update. Opsio maintains editorial independence.