Design of SAP Workloads on AWS practice questions

Deploy the SAP application on a single EC2 instance and use S3 for database backups with cross-region replication.

Why wrong: This option uses a single EC2 instance and S3 backups with cross-region replication. While backups can help with disaster recovery, they do not provide high availability; restoring from backup would exceed the RTO of 30 minutes, and the RPO of less than 15 minutes cannot be guaranteed with periodic backups.

Use two EC2 instances in an Auto Scaling group with instance store volumes for the database, and store application files on S3.

Why wrong: This option uses instance store volumes for the database, which are ephemeral and not persistent. On instance failure or termination, data is lost, making it impossible to meet the RPO requirement. Auto Scaling does not provide database high availability.

Deploy the SAP application on two EC2 instances in different AZs with a shared EFS file system, and use a multi-AZ RDS for SAP HANA with synchronous replication.

Why wrong: This option is invalid because Amazon RDS does not support SAP HANA as a managed database service. Multi-AZ RDS for SAP HANA does not exist on AWS. Therefore, this solution cannot be implemented.

AWS Database Migration Service (DMS)

Why wrong: AWS Database Migration Service (DMS) is used for migrating databases, not for restoring SAP HANA from S3 backups.

AWS Backup

Why wrong: AWS Backup integrates with SAP HANA but is not required for restoring from an S3 backup created by backint; the restore can be done using the backint agent or Storage Gateway.

AWS Snowball Edge

Why wrong: AWS Snowball Edge is used for large data transfers, not for restoring HANA databases from S3.

Reduce the backup window to a shorter time period.

Why wrong: Reducing the window does not change how long the backup takes; it only compresses the allowed time.

Disable automatic backups and rely on manual snapshots.

Why wrong: Manual snapshots do not provide automated recovery and may increase RPO; they may also take similar time.

Increase the backup retention period to allow more frequent backups.

Why wrong: Increasing retention period does not reduce backup duration; it may increase storage.

Configure EBS Multi-Attach to allow multiple instances to share the same volume for parallel I/O.

Why wrong: EBS Multi-Attach allows multiple instances to share a volume for clustered applications like Oracle RAC, but does not improve I/O for a standalone database; it is not a design change for single-database I/O bottlenecks.

Use instance store volumes for the database files to reduce latency.

Why wrong: Instance store volumes offer high I/O but are ephemeral; they are not recommended for database files due to risk of data loss.

Use a smaller instance type to reduce network hops.

Why wrong: Using a smaller instance type would reduce compute resources and likely increase latency, not reduce it.

Place the database instance in a cluster placement group with the application servers.

Why wrong: A cluster placement group reduces network latency between instances but does not address EBS storage latency.

Enable EBS optimization on the database instance and ensure the instance type supports dedicated EBS bandwidth.

Why wrong: EBS optimization is already enabled by default on r5 instances, so this change would have no effect.

Assign public IP addresses to each node for inter-node communication.

Why wrong: Assigning public IP addresses to each node is not required and introduces security risks; inter-node communication should use private IPs within the VPC.

Configure an Elastic Load Balancer to distribute traffic among nodes.

Why wrong: An Elastic Load Balancer distributes external traffic, not internal HANA communication; HANA nodes communicate directly via the internal network.

Enable EBS optimization on all EC2 instances.

Why wrong: EBS optimization is beneficial for storage performance but is not a network configuration requirement for HANA inter-node communication.

AWS Auto Scaling

Why wrong: AWS Auto Scaling is designed for scaling out/in based on demand, not for handling failover of a statically addressed ASCS instance. It does not provide the required IP-level failover.

Amazon CloudWatch with alarms

Why wrong: Amazon CloudWatch with alarms can monitor ASCS health and trigger notifications or automated actions, but it does not directly perform failover routing. It can be used in conjunction with other services like NLB or Route 53, but alone it is insufficient.

Amazon Route 53 with health checks and failover routing

Why wrong: Amazon Route 53 with health checks and failover routing can perform DNS-level failover, but this introduces DNS TTL propagation delays, typically around 60 seconds or more. For SAP ASCS failover within a region, the NLB provides faster, more reliable failover without DNS caching issues.

VolumeIdleTime

Why wrong: VolumeIdleTime indicates how often the volume is idle. While low idle time suggests saturation, it is not as direct as throughput metrics for identifying a bottleneck. Since the question requires exactly two metrics, VolumeReadBytes and VolumeWriteBytes are the better choices.

NetworkIn

Why wrong: NetworkIn measures incoming network traffic, not disk I/O, so it is irrelevant for this purpose.

CPUUtilization

Why wrong: CPUUtilization measures CPU usage, not disk I/O, so it is not applicable.

VPC Peering

Why wrong: VPC Peering connects VPCs, but does not provide a floating IP or traffic routing for application servers.

Elastic IP address

Why wrong: Elastic IP addresses are static public IPs that can be remapped, but they require manual intervention and do not provide automated health-based failover.

Amazon Route 53 with failover routing

Why wrong: Amazon Route 53 with failover routing uses DNS to redirect traffic, but it does not manage a floating IP address; it manages DNS records. DNS changes are subject to TTL delays and are not suitable for true floating IP scenarios.

Configure swap space on the instance to handle memory pressure

Why wrong: Swap space is not recommended for SAP HANA as it can cause performance issues; HANA manages memory internally.

Enable multi-attach on EBS volumes for HANA shared storage in scale-out

Why wrong: Multi-attach is relevant only for scale-out configurations and is not a general best practice for all SAP HANA deployments.

Change the hostname after the HANA installation to match the DNS name

Why wrong: Changing hostname after installation can cause HANA configuration issues; hostname must be set before installation.

AWS Config

Why wrong: Config tracks configuration changes, not performance.

Amazon Inspector

Why wrong: Inspector is for vulnerability management.

AWS Trusted Advisor

Why wrong: Trusted Advisor provides best-practice checks, not HANA performance.

AWS Direct Connect

Why wrong: AWS Direct Connect is a dedicated network connection from on-premises to AWS, not for connecting subnets within the same VPC.

AWS Site-to-Site VPN

Why wrong: AWS Site-to-Site VPN connects on-premises networks to AWS, not for intra-VPC subnet communication.

AWS Transit Gateway

Why wrong: AWS Transit Gateway is used for hub-and-spoke connectivity between multiple VPCs or on-premises, not for subnets within a single VPC.

Configure S3 Transfer Acceleration for faster backup uploads.

Why wrong: S3 Transfer Acceleration speeds up uploads but does not provide backup or PITR capability. It is not a backup strategy.

Use a script to copy HANA backup files to S3 every 15 minutes.

Why wrong: Copying backup files to S3 every 15 minutes requires custom scripting and storage costs, but does not provide automated PITR and is less cost-effective than managed services.

Take hourly EBS snapshots of all HANA volumes and retain them for 24 hours.

Why wrong: Hourly EBS snapshots provide recovery points only at the top of each hour, which does not enable precise point-in-time recovery. Potential data loss of up to one hour is not considered minimal. Additionally, for a 2 TB database, storing 24 hourly snapshots incurs higher costs compared to the log-based backup approach of AWS Backup.

Use the AWS root account for daily administration of SAP systems.

Why wrong: Root account should be used sparingly; IAM users are preferred.

Assign public IP addresses to SAP instances for direct internet access.

Why wrong: Direct internet access exposes instances to security risks.

Place SAP application servers in a public subnet for ease of access.

Why wrong: SAP servers should be in private subnets.

Amazon Macie

Why wrong: Macie is for data discovery and protection.

AWS OpsWorks

Why wrong: OpsWorks is for configuration management, not provisioning.

AWS CodePipeline

Why wrong: CodePipeline is for CI/CD pipelines.

Amazon RDS databases

Why wrong: Amazon RDS does not support SAP HANA as a database engine, so AWS Backup backing up an RDS instance is not applicable for SAP HANA workloads.

Amazon S3 buckets

Why wrong: Amazon S3 is not a resource that AWS Backup can directly back up; it is typically used as a backup destination.

Use Amazon RDS encryption for the SAP HANA database.

Why wrong: SAP HANA is not an RDS database.

Use Amazon S3 server-side encryption for database files.

Why wrong: S3 is not used for HANA persistent storage.

Amazon Route 53 health checks to fail over DNS to the DR site.

Why wrong: Route 53 handles routing, not data replication.

Amazon EC2 Auto Scaling groups to launch instances in us-west-2 on failover.

Why wrong: Auto Scaling does not replicate data.

AWS Backup to copy EBS snapshots to us-west-2 every 15 minutes.

Why wrong: Snapshots are not continuous and may not meet 15-min RPO.

AWS Storage Gateway File Gateway

Why wrong: File Gateway provides file access to S3 but adds complexity and latency; not optimal for SAP shared file systems.

Amazon S3

Why wrong: S3 is object storage and does not provide a file system interface suitable for SAP shared files.

Amazon EBS with multi-attach

Why wrong: EBS multi-attach is only supported for certain volume types and has limitations on concurrent writes.

Place the servers in different placement groups but the same Availability Zone

Why wrong: Placing servers in different placement groups but the same Availability Zone does not optimize latency as they may not be physically close.

Use a cluster placement group spanning two Availability Zones

Why wrong: A cluster placement group spanning two Availability Zones would introduce cross-AZ latency, increasing network delay.

Place the servers in different Availability Zones but within the same region

Why wrong: Placing servers in different Availability Zones increases latency due to physical distance and cross-AZ network traversal.