Most organisations know they need disaster recovery. Far fewer know what a well-designed DR architecture actually looks like.
The gap between “we have backups” and “we can recover our business in under an hour” is architectural. It’s the difference between storing copies of your data somewhere offsite and building a recovery environment that’s been pre-configured, tested, and ready to take over when your production systems fail.
According to Veeam’s 2025 Ransomware Trends Report, 66% of backup repositories were impacted during attacks, with 34% modified or deleted entirely. Of the organisations that were attacked, only 10% recovered more than 90% of their data. The rest lost significant portions of their business-critical information because their backup and recovery infrastructure wasn’t designed to withstand the threats it was supposed to protect against.
If you’re running Veeam on-premises and considering AWS as your DR target, here’s what a properly designed architecture looks like in practice.
Why AWS as Your Veeam Disaster Recovery Target
The first decision in any DR architecture is where your recovery environment lives. For organisations already invested in Veeam, AWS has become the logical target for several reasons.
Elasticity means you’re not paying for idle hardware waiting for a disaster that might never come. You provision recovery infrastructure on demand and pay for storage at rest. Geographic reach means you can place your DR environment in a different region from your production systems, which matters when the disaster is a hurricane, a flood, or a regional power outage rather than a ransomware attack. And the compliance certifications that AWS carries (HIPAA, PCI-DSS, SOC 2, FedRAMP) mean your DR environment can satisfy the same regulatory requirements as your production infrastructure.
The key is that AWS isn’t your backup destination in this model. It’s your recovery environment. The distinction matters because it changes what you’re designing for. You’re not just copying data offsite. You’re pre-building the environment that your business will run on if production goes down.
Veeam Cloud Connect: The Replication Pathway
Veeam Cloud Connect is the bridge between your on-premises Veeam infrastructure and your cloud-hosted DR environment. It handles two things that matter for DR architecture: backup copy jobs (sending backup data to the cloud repository) and replication (maintaining near-real-time copies of your virtual machines in the cloud, ready to be powered on).
The difference between these two determines your recovery speed. Backup copies give you data you can restore from, but restoration takes time because you’re rebuilding VMs from scratch. Replicas give you pre-built VMs that can be powered on almost immediately, with only the most recent changes needing to synchronise.
For most organisations, the right architecture uses both. Tier 1 workloads (the systems your business can’t function without for more than an hour) get replicated. Tier 2 and Tier 3 workloads get backup copies at varying frequencies. This tiered approach keeps costs manageable while ensuring your most critical systems recover first.
A managed Veeam partner like Opti9 handles the cloud-side infrastructure, including the Veeam Cloud Connect gateway, the recovery compute environment, and the storage repositories. Your on-premises Veeam server connects to this environment through an encrypted tunnel. No VPN configuration required on day one. No secondary site lease. No hardware to purchase and maintain.
Designing Your Storage Tier Strategy
Storage is where DR costs either stay reasonable or spiral. The key is matching storage tier to recovery requirement rather than putting everything on the fastest (and most expensive) tier.
Active replicas for Tier 1 workloads sit on high-performance storage. These are the VMs that power on in minutes during a failover event. The storage cost is higher, but the volume is limited to your most critical systems.
Backup copies for Tier 2 workloads can use standard cloud storage. Recovery from these takes longer (hours rather than minutes) because VMs need to be rebuilt from backup data, but the storage cost per GB is substantially lower.
Long-term retention for compliance and archival purposes can leverage lower-cost storage tiers. This is where you keep 90, 180, or 365 days of backup history to ensure clean recovery points exist, even if an attacker has been in your environment for months before you detect them. The Veeam 2025 data on dwell time makes this especially relevant: ransomware groups are reducing dwell times to hours in some cases, but others still operate with weeks or months of undetected access.
Veeam handles data lifecycle across these tiers automatically through backup copy job scheduling and retention policies. The architecture decision is which workloads go where and how much retention each tier needs.
Networking for Failover: The Most Commonly Missed Step
Networking is where DR plans fall apart most often. Organisations invest in backup infrastructure, configure replication, and then discover during a real event that users can’t actually reach the recovery environment because nobody pre-configured the network.
A properly designed Veeam DR architecture on AWS addresses three networking requirements.
DNS re-routing is the simplest approach for many organisations. When you fail over to the DR environment, DNS records update to point users to the recovery infrastructure. This works well for web-facing applications and services accessed by hostname. The trade-off is propagation delay, which can add minutes to your effective RTO.
VPN tunnels between your primary network and the DR environment allow internal users to access recovery systems as if they were on the same network. For organisations with significant internal traffic (file servers, databases, line-of-business applications), this pre-configured connectivity is essential.
Pre-assigned IP addressing in the DR environment that mirrors your production network simplifies failover for applications with hardcoded IP dependencies. Veeam’s network mapping capabilities handle the re-IP process during failover, but the network design needs to be in place before you need it.
The common mistake is treating networking as something to figure out during the disaster. By then, you’re troubleshooting connectivity under pressure instead of executing a recovery plan. Network pre-configuration should be part of the initial DR architecture design and validated during every test.
Tiering Workloads by Recovery Requirement
Not every workload needs sub-hour recovery. Treating everything as Tier 1 is expensive and operationally complex. Treating everything as Tier 3 leaves your business exposed during the hours when it matters most.
A practical tiering model for most mid-market organisations looks like this.
Tier 1: Business-critical systems with sub-1-hour RTO. These are the applications that generate revenue, serve customers, or support regulatory obligations. Examples include your ERP system, primary database servers, email infrastructure, and patient-facing systems in healthcare. These get active Veeam replicas in the cloud DR environment, ready to power on with minimal data loss.
Tier 2: Important systems with 4-8 hour RTO. These are systems the business needs but can function without for a partial day. File servers, secondary databases, development environments, and internal tools typically fall here. These get Veeam backup copies with regular (every 4-8 hours) copy job schedules.
Tier 3: Non-critical systems with 24-48 hour RTO. Archive systems, test environments, and workloads that can be rebuilt if necessary. These get daily or weekly backup copies on lower-cost storage tiers.
The tiering exercise is a business conversation, not a technical one. IT can advise on what’s possible, but the business needs to define which systems matter most. The output is a recovery priority matrix that drives the entire DR architecture.
DR Testing as Architecture, Not Afterthought
Recovery testing isn’t a quarterly checkbox. It’s part of the architecture.
Veeam SureBackup and SureReplica automate recovery verification by booting VMs from backup or replica in an isolated environment and running predefined tests (heartbeat checks, application-level validation, custom scripts). These tests run on schedule without impacting production and without requiring manual intervention.
The output is documented proof that your backups are recoverable and your recovery procedures work. That documentation matters for two audiences: your leadership team (who need confidence that the DR investment actually works) and your auditors (who need evidence of tested recovery for HIPAA, PCI-DSS, SOC 2, and other compliance frameworks).
According to Veeam’s 2025 research, 69% of ransomware victims believed they were prepared before being attacked, but confidence dropped by more than 20% afterward. The gap between perceived readiness and actual readiness is what DR testing closes. Organisations that test regularly don’t discover their blind spots during an incident. They discover them during a test, when there’s time to fix them.
Build DR Architecture That Actually Works
As a Veeam Platinum VCSP Partner and AWS Premier Tier Services Partner, Opti9 designs and operates Veeam disaster recovery architectures on AWS for organisations that need recovery capabilities they can rely on. From Veeam Cloud Connect configuration to storage tiering, failover networking, and regular recovery testing through the OptiX Dashboard, we handle the architecture so your team can focus on the business.
