# Architecture patterns In this section, we elaborate on the architecture patterns that you can select based on your availability and recovery requirements. We also analyze failure scenarios that can help you select the right pattern for your SAP system(s). # Failure scenarios For the failure scenarios below, the primary consideration is the physical unavailability of the compute and/or storage capacity within the Availability Zones. ## Availability Zone failure An Availability Zone failure can be caused by a significant availability degradation of one or more AWS services utilized by your resources within that Availability Zone. For example: + Several Amazon EC2 instances have failed with [System Status Check errors](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html) or are unreachable and cannot be restarted. + Several Amazon Elastic Block Store (Amazon EBS) volumes with [Volume Status Check errors](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html#monitoring-volume-checks) have failed. ## Amazon Elastic Block Store failure Loss of one or more Amazon EBS volumes attached to a single Amazon EC2 instance may result in the unavailability of a critical component (i.e. the database) of the SAP system. ## Amazon EC2 failure Loss of a single Amazon EC2 instance may result in the unavailability of a critical component (i.e. the database or SAP Central Services) of the SAP system. ## Logical data loss You should also consider the potential for logical data loss where the underlying hardware capacity still exists but the primary copies of the data have been corrupted or lost. This data loss could be due to malicious activity within your AWS account or due to human error. To protect against logical data loss, it is recommended that regular copies of the data are backed up to an Amazon S3 bucket. This bucket is replicated (using [Single-Region or Cross-Region replication](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-s3-replication)) to another Amazon S3 bucket owned by a separate AWS account. With the appropriate AWS Identity and Access Management (IAM) controls between the two AWS accounts, this strategy ensures that not all copies of the data are lost due to malicious activity or human error. # Patterns In this section, we examine the architecture patterns available to handle the failure scenarios detailed above. There are two key parameters to consider when selecting a pattern to meet your organization’s specific business requirements: + Availability of compute for the SAP single points of failure + Availability of the SAP data persisted on Amazon EBS These parameters determine the time taken to recover from a failure scenario, that is, the time taken by your SAP system to return to service. *Types of architecture patterns* The architecture patterns are grouped into single Region and multi-Region patterns. The distinguishing factor would be: 1. If you require the data to only reside in a specific geographical location (AWS Region) at all times (for example, data residency requirements). or 1. If you require the data to reside in two specific geographical locations (AWS Regions) at all times (for example, two copies of SAP data must reside at least 500 miles apart for compliance). If your production systems are critical to your business and you require minimal downtime in the event of failure, you should select a Multi-Region pattern to ensure that your production systems are highly available at all times. When deploying a Multi-Region pattern, you can benefit from using an automated approach (such as, Cluster solution) for fail over between Availability Zones to minimize the overall downtime and remove the need for human intervention. Multi-Region patterns not only provide high availability but also disaster recovery, thereby lowering overall costs. # Single Region architecture patterns Select a single Region pattern if: + You require the data to reside only in a specific geographical Region (AWS Region) at all times + You want to avoid the [potential network latency](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-multi-region-considerations) considerations associated with a Multi-Region approach + You want to avoid the cost implications or differences associated with a Multi-Region approach including: + [AWS service pricing in different AWS Regions](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-selecting-the-aws-regions) + [Cross-Region data transfer costs](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-cross-regional-data-transfer) ## Pattern 1: A single Region with two AZs for production **Figure 7: A single Region with two Availability Zones for production** ![\[A single Region with two Availability Zones for production\]](http://docs.aws.amazon.com/sap/latest/general/images/arch-guidance-pattern-1.png) In this pattern, you deploy all your production systems across two Availability Zones. The compute deployed for the production SAP database and central services tiers are the same size in both Availability Zones, with automated fail over in the event of a zone failure. The compute required for the SAP application tier is split 50/50 between two zones. Your non-production systems are **not** an equivalent size to your production and are deployed in the same zones or a different Availability Zone within the Region. **Select this pattern if:** + You require a defined time window to complete recovery of production as well as assurance of the availability of compute capacity in another Availability Zone for the production SAP database and central services tiers. + You can accept the additional cost of deploying the required compute and storage for production SAP database and central services tiers across two Availability Zones. + Your non-production environment is not of equivalent size as production and therefore cannot be used as sacrificial capacity for production in the event of an Availability Zone failure or significant Amazon EC2 service degradation. + You can accept data replication across Availability Zones (database replication capability or a block level replication solution required) and the associated cost. + You can accept that automated fail over between Availability Zones requires a third-party cluster solution. + You can accept the variable time duration required (including any delay in availability of the required compute capacity in the remaining Availability Zones) to return the application tier to 100% capacity in the event of a zone failure. **Key design principles** + 100% compute capacity deployed in Availability Zone 1 and Availability Zone 2 for production SAP database and central services tiers. + Compute capacity is deployed in Availability Zone 1 and Availability Zone 2 for production application tier (Active/Active). In the event of an Availability Zone failure, the application tier needs to be scaled to return to 100% capacity within the remaining zone. + The SAP Database is persisted on Amazon EBS in two Availability Zones using either a database replication capability or a block level replication solution. + Amazon EC2 auto recovery is configured for all instances to protect against underlying hardware failure, with the exception of instances protected by a third-party cluster solution. + Amazon EFS is used for the SAP Global File Systems. + SAP Database is backed up regularly to Amazon S3. + Amazon S3 [single-Region replication](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-s3-replication) is configured to protect [logical data loss](arch-guide-failure-scenarios.md#arch-guide-logical-data-loss). + Amazon Machine Image/Amazon EBS Snapshots are taken for all servers on a regular basis. **Benefits** + Low Mean Time to Recovery (MTTR) + Predictable Return to Service (RTS) + Ability to protect against significant degradation or total Availability Zone failure through fail over of database and central services tiers to Availability Zone 2 + No requirement to restore data from Amazon S3 in the event of an Availability Zone or Amazon EBS failure **Considerations** + Well documented and tested processes are required for the automated fail over between Availability Zones. + Well documented and tested processes are required for maintaining the automated fail over solution. + Well documented and tested processes are required for scaling the AWS resources to return the application tier to required capacity in the event of an Availability Zone failure or significant Amazon EC2 service degradation. ## Pattern 2: A single Region with two AZs for production and production sized non-production in a third AZ **Figure 8: A single Region with two Availability Zones for production and production sized non-production in a third Availability Zone** ![\[A single Region with two Availability Zones for production and production sized non-production in a third Availability Zone\]](http://docs.aws.amazon.com/sap/latest/general/images/arch-guidance-pattern-2.png) In this pattern, you deploy all your production systems across two Availability Zones. The compute deployed for the production SAP database and central services tiers are the same size in both Availability Zones, with automated fail over in the event of a zone failure. The compute required for the SAP application tier is split 50/50 between two Availability Zones. Your non-production systems are an equivalent size to your production and deployed in a third Availability Zone. In the event of an Availability Zone failure where your production systems are deployed, the non-production capacity is reallocated to enable production to be returned to a Multi-AZ pattern. **Select this pattern if:** + You require the ability to continue to have a Multi-AZ configuration for production in the event of an Availability Zone failure within the Region. + You require a defined time window to complete recovery of production and assurance of the availability of the compute capacity in another Availability Zone for the production SAP database and central services tiers. + You can accept the additional cost of deploying the required compute and storage for production SAP database and central services tiers across two Availability Zones. + You can accept data replication across Availability Zones (database replication capability or a block level replication solution required) and the associated cost. + You can accept that automated fail over between Availability Zones requires a third-party cluster solution. + You can accept the variable time duration required (including any delay in availability of the required compute capacity in the remaining Availability Zones) to return the application tier to 100% capacity in the event of an Availability Zone failure. **Key design principles** + 100% compute capacity is deployed in Availability Zone 1 and Availability Zone 2 for production SAP database and central services tiers. + 100% production compute capacity (database and central services) is deployed in the third Availability Zone for use by non-production in normal operations. + Compute capacity is deployed in Availability Zone 1 and Availability Zone 2 for production application tier (Active/Active). In the event of an Availability Zone failure, the application tier needs to be scaled to return to 100% capacity within the remaining zone. + [Amazon EC2 auto recovery](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-ec2-auto-recovery) is configured for all instances to protect against underlying hardware failure, with the exception of instances protected by a third-party cluster solution. + The SAP Database is persisted on Amazon EBS in two Availability Zones using either a database replication capability or a block level replication solution. + Amazon EFS is used for the SAP Global File Systems. + SAP Database is backed up regularly to Amazon S3. + Amazon S3 [single-Region replication](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-s3-replication) is configured to protect against [logical data loss](arch-guide-failure-scenarios.md#arch-guide-logical-data-loss). + Amazon Machine Image/Amazon EBS Snapshots for all servers are taken on a regular basis. **Benefits** + Low Mean Time to Recovery (MTTR) + Predictable Return to Service (RTS) + Ability to protect against significant degradation or total Availability Zone failure through fail over of database and central services tiers to Availability Zone 2 + No requirement to restore data from Amazon S3 in the event of an Availability Zone failure or Amazon EBS failure + Option for data to be persisted on Amazon EBS in three different Availability Zones, dependent on capabilities of database or block level replication solution + Use of non-production compute capacity to return to production run across two Availability Zones in the event of a significant degradation or total Availability Zone failure **Considerations** + Well documented and tested processes are required for the automated fail over between Availability Zones. + Well documented and tested processes are required for maintaining the automated fail over solution. + Well documented and tested processes are required for scaling the AWS resources to return the application tier to required capacity in the event of an Availability Zone failure or significant Amazon EC2 service degradation. + Well documented and tested processes are required for re-allocating the compute capacity from non-production to return production to run across two Availability Zones in the event of an Availability Zone failure impacting production. ## Pattern 3: A single Region with one AZ for production and another AZ for non-production **Figure 9: A single Region with one Availability Zone for production and another Availability Zone for non-production** ![\[A single Region with one Availability Zone for production and another Availability Zone for non-production\]](http://docs.aws.amazon.com/sap/latest/general/images/arch-guidance-pattern-3.png) In this pattern, you deploy all your production systems in one Availability Zone and all your non-production systems in another Availability Zone. Your non-production systems are an equivalent size to your production. **Select this pattern if:** + You require a defined time window to complete recovery of production and assurance of the availability of compute capacity in another Availability Zone for the SAP database and central services tiers. + You can accept the additional time required to re-allocate compute capacity from non-production to production as part of the overall time window to recover production. + You can accept the time required to restore data to Amazon EBS from Amazon S3 in another Availability Zone as part of the overall time window to recover production. + You can accept the variable time duration required to return the application tier to 100% capacity following an Availability Zone failure (including any delay in availability of the required compute capacity in the remaining Availability Zones). + You can accept a period of time where there is only one set of computes deployed for the production SAP database and central services tiers in the event of an Availability Zone failure or significant Amazon EC2 service degradation. **Key design principles** + 100% compute capacity is deployed in Availability Zone 1 for production SAP database and central services tiers. + 100% compute capacity is deployed in Availability Zone 1 for production SAP application tier. + 100% of production compute capacity (SAP database and central services) is deployed in Availability Zone 2 for use by non-production in normal operations. + Amazon EC2 auto recovery is configured for all instances to protect against underlying hardware failure. + The SAP database is persisted on Amazon EBS in a single Availability Zone only and not replicated on another Availability Zone. + Amazon EFS is used for the SAP Global File Systems. + SAP Database Data is backed up regularly to Amazon S3. + Amazon S3 single-Region replication is configured to protect against logical data loss. + Amazon Machine Image/Amazon EBS Snapshots are taken for all servers on a regular basis. **Benefits** + Cost optimized through use of non-production capacity in the event of production Availability Zone failure + Required compute capacity deployed in two Availability Zones to allow a more predictable recovery time duration **Considerations** + Well documented and tested processes for re-allocating the required compute capacity from non-production to production and restoring the data in a different Availability Zone are required to ensure recoverability. + There may be loss of non-production environments in the event of an Availability Zone failure impacting production. + Due to the lack of high availability across two Availability Zones, the time required to recover production in the event of compute failure or Availability Zone failure increases. ## Pattern 4: A single Region with a single AZ for production **Figure 10: A single Region with a single Availability Zone for production** ![\[A single Region with a single Availability Zone for production\]](http://docs.aws.amazon.com/sap/latest/general/images/arch-guidance-pattern-4.png) In this pattern, you deploy all your production systems in one Availability Zone and all your non-production systems in either the same Availability Zone or another Availability Zone. Your non-production systems are **not** a similar size to your production.**\$1**\$1 **Select this pattern if:** + In the event of an Availability Zone failure or significant Amazon EC2 service degradation, you can accept the risks related to the variable time duration required (including any delay in availability of the required compute capacity in the remaining Availability Zones) to re-create the AWS resources in a different Availability Zone and restore the persistent data to Amazon EBS. + You want to avoid the cost implications with a Multi-AZ approach and accept the related risks of downtime of your production SAP systems. **Key design principles** + 100% compute capacity is deployed in Availability Zone 1 for production SAP database and central services tiers. + 100% compute capacity is deployed in Availability Zone 1 for production SAP application tier. + Amazon EC2 is configured for all instances to protect against underlying hardware failure. + Deployed non-production compute capacity is less than 100% the compute capacity deployed for production SAP database and central services tiers. + The SAP database is persisted on Amazon EBS in a single Availability Zone only and not replicated on another Availability Zone. + Amazon EFS is used for the SAP Global File Systems. + SAP Database is backed up regularly to Amazon S3. + Amazon S3 single-Region replication is configured to protect against logical data loss. + Amazon Machine Image/Amazon EBS Snapshots for all servers are taken on a regular basis. **Benefits** + Lowest cost + Simplest design + Simplest operation **Considerations** + Well documented and tested processes for scaling the AWS resources and restoring data in a different Availability Zone are required to ensure recoverability. # Multi-Region Architecture Patterns You should select a multi-Region architecture if you require the following: + You require the data to reside in two specific geographical AWS Regions at all times. + You can accept the potential network latency considerations associated with a multi-Region approach. + You can accept the increased complexity associated with multi-Region approach. + You can accept the cost implications / differences associated with a multi-Region approach including: + [AWS service pricing (e.g. Amazon EC2)](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-selecting-the-aws-regions) in different AWS Regions + [Cross-Region data transfer costs](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-cross-regional-data-transfer) + Additional compute and/or storage costs in the second Region. ## Pattern 5: A primary Region with two AZs for production and a secondary Region containing a replica of backups/AMIs **Figure 11: A primary Region with two Availability Zones for production and a secondary Region containing a replica of backups/AMIs** ![\[A primary Region with two Availability Zones for production and a secondary Region containing a replica of backups/AMIs\]](http://docs.aws.amazon.com/sap/latest/general/images/arch-guidance-pattern-5.png) In this pattern, you deploy your production system across two Availability Zones in the primary Region. The compute deployed for the production SAP database and central services tiers are the same size in both Availability Zones with automated fail over in the event of an Availability Zone failure. The compute required for the SAP application tier is split 50/50 between two Availability Zones. Additionally, the production database backups stored in Amazon S3, Amazon EBS Snapshots, and Amazon Machine Images are replicated on the secondary Region. In the event of a complete Region failure, the production systems would be restored from the last set of backups in the second Region. **Select this pattern if:** + You require a defined time window to complete recovery of production and assurance of the availability of compute capacity in another Availability Zone within the primary Region for the production SAP database and central services tiers. + You can can accept the additional cost of deploying the required compute and storage for production SAP database and central services tiers across two Availability Zones within the primary Region. + You can accept the cross-Availability Zone related data transfer costs for data replication. + You can accept that automated fail over between Availability Zones requires a third-party cluster solution. + You can allow for a period of time where there is only one set of computes deployed for the SAP database and central services in the event of an Availability Zone failure or significant Amazon EC2 failure. + You can accept that data replication across Availability Zones requires either a database replication capability or a block level replication solution. + You can accept the variable time duration required (including any delay in availability of the required compute capacity in the remaining Availability Zones) to return the application tier to 100% capacity. + You can accept the variable time duration required to complete recovery of production in the event of a Region failure. + You can accept the increased complexity and costs associated with multi-Region approach. + You can accept that manual actions are required to restore production in the second Region. **Key design principles** + 100% compute capacity is deployed in Availability Zone 1 and Availability Zone 2 for production SAP database and central services tiers. + Compute capacity is deployed in Availability Zone 1 and Availability Zone 2 for production SAP application tier (Active/Active) and needs to be scaled in the event of an Availability Zone failure or significant Amazon EC2 service degradation. + [Amazon EC2 auto recovery](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-ec2-auto-recovery) is configured for all instances to protect against underlying hardware failure with the exception of instances protected by a third-party cluster solution. + The SAP database-related data on Amazon EBS is replicated between Availability Zones using either a database replication capability or a block level replication solution. + Amazon EFS is used for the SAP Global File Systems and is replicated on the secondary Region. + SAP Database data is backed up regularly to Amazon S3. + Amazon Machine Image/Amazon EBS Snapshots are taken for all servers on a regular basis  + Amazon S3 Data (database backups), Amazon EBS Snapshots and Amazon Machine Images are replicated/copied to a secondary Region to protect [logical data loss](arch-guide-failure-scenarios.md#arch-guide-logical-data-loss). **Benefits** + Low Mean Time to Recovery (MTTR) in the event of Amazon EC2 or Availability Zone failure + Predictable Return to Service (RTS) in the event of Amazon EC2 or Availability Zone failure + Database-related data persisted on different sets of Amazon EBS volumes in two Availability Zones via database replication capability or a block level replication solution + Required compute capacity deployed in two Availability Zones in primary Region + No dependency on restoring data from Amazon S3 in the event of an Availability Zone failure in the primary Region + Ability to protect against significant degradation or total Availability Zone failure through fail over to Availability Zone 2 of database and central services tiers + Ability to protect against significant degradation or total Region failure through fail over to secondary Region **Considerations** + Well documented and tested processes are required for the automated fail over between Availability Zones. + Well documented and tested processes are required for maintaining the automated fail over solution. + Well documented and tested processes are required for scaling the AWS resources to return the application tier to full capacity in the event of an Availability Zone failure or significant Amazon EC2 service degradation. + Well documented and tested processes are required for scaling the AWS resources, restoring the data, and moving production to the secondary Region. + Higher network latency from your on-premises locations to the secondary AWS Region may impact end user performance. ## Pattern 6: A primary Region with two AZs for production and a secondary Region with compute and storage capacity deployed in a single AZ **Figure 12: A primary Region with two Availability Zones for production and a secondary Region with compute and storage capacity deployed in a single Availability Zone** ![\[A primary Region with two Availability Zones for production and a secondary Region with compute and storage capacity deployed in a single Availability Zone\]](http://docs.aws.amazon.com/sap/latest/general/images/arch-guidance-pattern-6.png) In this pattern, you deploy all of your production systems across two Availability Zones in the primary Region. The compute deployed for the production SAP database and central services tiers are the same size in both Availability Zones with automated fail over in the event of Availability Zone failure. The compute required for the SAP application tier is split 50/50 between two Availability Zones. Your non-production systems are **not** an equivalent size to your production and are deployed in a different Availability Zone within the Region. Additionally, compute capacity is deployed in Availability Zone 1 in secondary Region for production SAP database and central services tiers. The production database is replicated to the secondary Region using a database replication capability or a block level replication solution. The Production database backups stored in Amazon S3, Amazon EBS Snapshots, and Amazon Machine Images are replicated to the secondary Region. In the event of a complete Region failure, the production systems would be restored in the secondary Region using the replicated data for the database tier and the last set of backups for the SAP central services and application tiers. **Select this pattern if:** + You require a defined time window to complete recovery of production and assurance of the availability of compute capacity in another Availability Zone within the primary Region for the production SAP database and central services tiers. + You can accept the additional cost of deploying the required compute and storage for production SAP database and central services tiers across two Availability Zones within the primary Region. + You can accept the increased cost of deploying the required compute and storage for production SAP database and central services tiers across two Availability Zones in the primary Region. + You can accept the cross-Availability Zone related data transfer costs for data replication. + You can accept that automated fail over between Availability Zones requires a third-party cluster solution. + You can allow for a period of time where there is only one set of computes deployed for the SAP database and central services in the event of an Availability Zone failure or significant Amazon EC2 failure. + You can accept that data replication across Availability Zones of the database-related data requires either a database replication capability or a block level replication solution. + You can accept the variable time duration required (including any delay in availability of the required compute capacity in the remaining Availability Zones) to return the application tier to 100% capacity. + You require a defined time window to complete recovery of production in the event of a Region failure. + You can accept the increased complexity and costs associated with multi-Region approach. + You require assurance of availability of compute capacity in a single Availability Zone in the secondary Region for the production SAP database and central services tiers. + You can accept the increased cost of deploying the required compute and storage for production SAP database and central services tiers across two Availability Zones in one Availability Zone in the secondary Region. + You can accept that manual actions are required to fail over between Regions. **Key design principles** + 100% compute capacity is deployed in Availability Zone 1 and Availability Zone 2 for production SAP database and central services tiers. + 100% compute capacity is deployed in Availability Zone 1 in the secondary Region for production SAP database and central services tiers. + Compute capacity is deployed in Availability Zone 1 and Availability Zone 2 for production SAP application tier (Active/Active) and needs to be scaled in the event of an Availability Zone failure or significant Amazon EC2 service degradation. + [Amazon EC2 auto recovery](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-ec2-auto-recovery) is configured for all instances to protect against underlying hardware failure with the exception of those instances protected by a third-party cluster solution. + The database-related data on Amazon EBS is replicated between Availability Zones using either a database replication capability or a block level replication solution. + The SAP database-related data on Amazon EBS is replicated between Regions using either a database replication capability or a block level replication solution. + Amazon EFS is used for the SAP Global File Systems and replicated to the secondary Region. + SAP database data is backed up regularly to Amazon S3. + Amazon Machine Image/Amazon EBS Snapshots are taken for all servers on a regular basis  + Amazon S3 data (database backups), Amazon EBS Snapshots, and Amazon Machine Images are replicated/copied to a secondary Region to protect [logical data loss](arch-guide-failure-scenarios.md#arch-guide-logical-data-loss). **Benefits** + Low Mean Time to Recovery (MTTR) in the event of an Amazon EC2, Availability Zone or Region failure + Predictable Return to Service (RTS) + Database-related data persisted on different sets of Amazon EBS volumes in two Availability Zones in primary Region and one set of volumes in an Availability Zone in secondary Region via database replication capability or a block level replication solution + Required compute capacity deployed in two Availability Zones in primary Region and one Availability Zone in secondary Region + No dependency on restoring data from Amazon S3 in the event of an Availability Zone failure or Region failure + Ability to protect against significant degradation or total Availability Zone failure through fail over to Availability Zone 2 of database and central services tiers + Ability to protect against significant degradation or total Region failure through fail over to secondary Region **Considerations** + Well documented and tested processes are required for the automated fail over between Availability Zones. + Well documented and tested processes are required for maintaining the automated fail over solution. + Well documented and tested processes are required for scaling the AWS resources to return the application tier to full capacity in the event of an Availability Zone failure or significant Amazon EC2 service degradation. + Well documented and tested processes are required for moving production to the secondary Region. + Higher network latency from your on-premises locations to the secondary AWS Region may impact end user performance. + There is an overhead of maintaining the same software version and patch levels (OS, Database, SAP) across two different Regions. ## Pattern 7: A primary Region with two AZs for production and a secondary Region with compute and storage capacity deployed and data replication across two AZs **Figure 13: A primary Region with two Availability Zones for production and a secondary Region with compute and storage capacity deployed and data replication across two Availability Zones** ![\[A primary Region with two Availability Zones for production and a secondary Region with compute and storage capacity deployed and data replication across two Availability Zones\]](http://docs.aws.amazon.com/sap/latest/general/images/arch-guidance-pattern-7.png) In this pattern, you deploy all of your production systems across two Availability Zones in the primary Region. The compute deployed for the production SAP database and central services tiers are the same size in both Availability Zones with automated fail over in the event of Availability Zone failure. The compute required for the SAP application tier is split 50/50 between two Availability Zone. Additionally, you have compute capacity deployed in Availability Zone 1 and Availability Zone 2 in secondary Region for production SAP database and central services tiers and the production database is replicated to the secondary Region using either a database replication capability or a block level replication solution. The production database backups stored in Amazon S3, Amazon EBS Snapshots, and Amazon Machine Images are replicated on a secondary Region. In the event of a complete Region failure, the production systems would be moved over to the secondary Region manually. **Select this pattern if:** + You require a defined time window to complete recovery of production and assurance of the availability of compute capacity in another Availability Zone within the primary Region for the production SAP database and central services tiers. + You can accept the additional cost of deploying the required compute and storage for production SAP database and central services tiers across two Availability Zones within the primary Region. + You can allow for a period of time where there is only one set of computes deployed for the SAP database and central services in the event of an Availability Zone failure or significant Amazon EC2 failure. + You can accept that data replication across Availability Zones of the database-related data requires either a database replication capability or a block level replication solution. + You can accept the cross-Availability Zone related data transfer costs for data replication. + You can accept that automated fail over between Availability Zones requires a third-party cluster solution. + You can accept the variable time duration required (including any delay in availability of the required compute capacity in the remaining Availability Zones) to return the application tier to 100% capacity. + You require a defined time window to complete recovery of production in the event of a Region failure. + You require assurance of availability of compute capacity in two Availability Zones in the secondary Region for the production SAP database and central services tiers. + You can accept the additional cost of deploying the required compute and storage for production SAP database and central services tiers across two Availability Zones in the secondary Region. + You can accept the increased complexity and costs associated with multi-Region approach. + You can accept that manual actions are required to fail over between Regions. **Key design principles** + 100% compute capacity is deployed in Availability Zone 1 and Availability Zone 2 in the primary Region for production SAP database and central services tiers. + 100% compute capacity is deployed in Availability Zone 1 and Availability Zone 2 in the secondary Region for production SAP database and central services tiers. + Compute capacity is deployed in Availability Zone 1 and Availability Zone 2 in the primary Region for production SAP application tier (Active/Active) and needs to be scaled in the event of an Availability Zone failure or significant Amazon EC2 service degradation. + Amazon EC2 auto recovery is configured for all instances to protect against underlying hardware failure with the exception of instances protected by a third-party cluster solution. + The SAP database-related data on Amazon EBS is replicated between Availability Zones using either a database replication capability or a block level replication solution. + The SAP database-related data on Amazon EBS is replicated between Regions using either a database replication capability or a block level replication solution. + Amazon EFS is used for the SAP Global File Systems and replicated on the secondary Region. + SAP database data is backed up regularly on Amazon S3. + Amazon Machine Image/Amazon EBS Snapshots for all servers are taken on a regular basis. + Amazon S3 data (database backups), Amazon EBS Snapshots, and Amazon Machine Images are replicated/copied to a secondary Region to protect [logical data loss](arch-guide-failure-scenarios.md#arch-guide-logical-data-loss). **Benefits** + Low Mean Time to Recovery (MTTR) in the event of Amazon EC2, Availability Zone or Region failure + Predictable Return to Service (RTS) + Database-related data persisted on different sets of Amazon EBS volumes in two Availability Zones in the primary Region and different sets of Amazon EBS volumes in two Availability Zones in the secondary Region via database replication capability or a block level replication solution + Required compute capacity deployed in two Availability Zones in primary Region and two Availability Zones in secondary Region + No dependency on restoring data from Amazon S3 in the event of an Availability Zone or Region failure + Ability to protect against significant degradation or total Availability Zone failure through fail over to Availability Zone 2 of database and central services tiers + Ability to protect against significant degradation or total Region failure through fail over to secondary Region **Considerations** + Well documented and tested processes are required for the automated fail over between Availability Zones. + Well documented and tested processes are required for maintaining the automated fail over solution. + Well documented and tested processes are required for scaling the AWS resources to return the application tier to full capacity in the event of an Availability Zone failure or significant Amazon EC2 service degradation. + Well documented and tested processes are required for moving production to the secondary Region. + Higher network latency from your on-premises locations to the secondary AWS Region may impact end user performance. + There is an overhead of maintaining the same software version and patch levels (OS, Database, SAP) across two different Regions. ## Pattern 8: A primary Region with one AZ for production and a secondary Region containing a replica of backups/AMIs **Figure 14: A primary Region with one Availability Zone for production and a secondary Region containing a replica of backups/AMIs** ![\[A primary Region with one Availability Zone for production and a secondary Region containing a replica of backups/AMIs\]](http://docs.aws.amazon.com/sap/latest/general/images/arch-guidance-pattern-8.png) In this pattern, you deploy your production systems in the primary Region in one Availability Zone. Your non-production systems are **not** an equivalent size to your production and are deployed in the same Availability Zones or a different Availability Zone within the Region. Additionally, the production database backups stored in Amazon S3, Amazon EBS Snapshots, and Amazon Machine Images are replicated to a secondary Region. In the event of a complete Region failure, the production systems would be restored from the last set of backups in the second Region. **Select this pattern if:** + In the event of an Availability Zone failure or significant Amazon EC2 service degradation, you can accept the risks related to the variable time duration required (including any delay in availability of the required compute capacity in the remaining Availability Zones) to re-create the AWS resources in a different Availability Zone and restore the persistent data to Amazon EBS. + You can accept the risks related to variable time duration required to complete recovery of production in the event of a Region failure. + You want to avoid the cost implications with a Multi-AZ approach and accept the related risks of downtime of your production SAP systems. + You can accept the increased complexity and costs associated with multi-Region approach. + You can accept that manual actions are required to restore production in the secondary Region. **Key design principles** + 100% compute capacity is deployed in Availability Zone 1 for production SAP database and central services tiers. + 100% compute capacity is deployed in Availability Zone 1 for production SAP application tier. + [Amazon EC2 auto recovery](arch-guide-architecture-guidelines-and-decisions.md#arch-guide-ec2-auto-recovery) is configured for all instances to protect against underlying hardware failure. + Deployed non-production compute capacity is less than 100% of the compute capacity deployed for production SAP database and central services tiers. + The SAP database is persisted on Amazon EBS in a single Availability Zone only and not replicated to another Availability Zone using either a database replication capability or a block level replication solution. + Amazon EFS is used for the SAP global file systems. + SAP database is backed up regularly to Amazon S3. + Amazon S3 is configured to protect against [logical data loss](arch-guide-failure-scenarios.md#arch-guide-logical-data-loss). + Amazon Machine Image/Amazon EBS Snapshots are taken for all servers on a regular basis. + Amazon S3 data (database backups), Amazon EBS Snapshots, and Amazon Machine Images are replicated/copied to a secondary Region to protect [logical data loss](arch-guide-failure-scenarios.md#arch-guide-logical-data-loss). **Benefits** + Reduced cost compared to Multi-AZ + Ability to protect against significant degradation or total Region failure through fail over to secondary Region **Considerations** + Well documented and tested processes are required for scaling the AWS resources to return the SAP application tier to full capacity in the event of an Availability Zone failure or significant Amazon EC2 service degradation. + Well documented and tested processes are required for scaling the AWS resources, restoring the data, and moving production to the secondary Region. + Higher network latency from your on-premises locations to the secondary AWS Region may impact end user performance. + In the event of compute, Availability Zone or Region failure due to lack of high availability across two Availability Zones, there is an increased time required to recover production.