Top AWS High Availability Interview Questions And Answers

Introduction

High Availability is an essential aspect of AWS, as it ensures uninterrupted access to applications and services throughout the system, even in the face of system failures or maintenance events. AWS achieves redundancy and fault tolerance by distributing workloads across multiple availability zones within a region. For advanced professionals preparing for AWS interviews, understanding high availability principles demonstrates expertise in architecting resilient solutions that meet stringent uptime requirements.

Our AWS high-availability interview questions and answers will help you easily employ techniques like auto-scaling, load balancing, and database replication in your data science interview.

Q1: What Is AWS High Availability?

A: High Availability means systems are running even during system failures and maintenance. They can handle failures without stopping or losing data and can recover quickly. We measure high Availability by how often the system is up, often using terms like "four nines" to show reliability. For instance, "four nines" means the system is up 99.99% of the time, only down for about 52.6 minutes a year.

Q2: What Are Network Address Translation (NAT) Gateways?

A: NAT servers allow traffic from private subnets to traverse the Internet or connect to other AWS Cloud services. Individual NAT servers can be a single point of failure. The NAT gateway is a managed device, and each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that Availability Zone. To achieve optimum Availability, use NAT gateways in each Availability Zone.

Q3: How Can The Queuing Chain Pattern Help?

A: Queuing Chain Patterns can help in 4 different ways:

• Use asynchronous processing to return responses quickly.

• Structure the system through the loose coupling of Amazon EC2 instances.

• Handle performance and service requirements by increasing or decreasing the number of Amazon EC2 instances used in job processing.

• A message remains in the queue service even if an Amazon EC2 instance fails, enabling processing to be continued immediately upon recovery of the Amazon EC2 instance and facilitating a system that is resistant to failure.

Q4: What Are Some Characteristics Of Amazon SQS?

A: Some characteristics of Amazon SQS include:

• Configurable settings per queue

• Message order is not guaranteed with standard queues.

• Message order is preserved with FIFO queues.

• Messages can be deleted while in the queue.

• Messages can contain up to 256 KB of text data, including XML, JSON, and unformatted text.

• FIFO and standard queues support server-side encryption

Q5: What Are Some Characteristics Of Amazon SNS?

A: Some characteristics of Amazon SNS include:

• Each notification message contains a single published message.

• Message order is not guaranteed.

• A message cannot be deleted after it has been published.

• Amazon's SNS delivery policy can be used to control retries in case of message delivery failure.

• Messages can contain up to 256 KB of text data, including XML, JSON, and unformatted text.

Q6: What Are Dead Letter Queues?

A: A Dead Letter Queue (DLQ) is an Amazon SQS queue that you configure to receive messages from other Amazon SQS queues, referred to as "source queues." Typically, you set up a DLQ to receive messages after a maximum number of processing attempts has been reached. A DLQ provides the ability to isolate messages that could not be processed. 

A DLQ is just like any other Amazon SQS queue—messages can be sent to and received from it. You can create a DLQ from the Amazon SQS API and the Amazon SQS area in the AWS Management Console.

Q7: What Is Amazon Simple Queue Service (Amazon SQS)?

A: Amazon Simple Queue Service (Amazon SQS) is a web service that gives you access to queues that store messages waiting to be processed. With Amazon SQS, you can quickly build message-queuing applications that can run on any computer. You can use the service to move data between diverse, distributed application components without losing messages and requiring each component to always be available.

Amazon SQS can help you build a distributed application with decoupled components by working closely with the Amazon Elastic Compute Cloud (Amazon EC2) and other AWS infrastructure services. 

You can access the service via the Amazon SQS console, the AWS Command Line Interface (AWS CLI), a generic web services Application Programming Interface (API), and any programming language that the AWS Software Development Kit (SDK) supports. Amazon SQS supports both standard and First-In, First-Out (FIFO) queues.

Q8: How Can You Use Amazon Simple Queue Service To Decouple An Application?

A: Consider a queue as a temporary repository for messages awaiting processing. Using Amazon SQS, you can decouple the components of an application so that they run independently of each other, with Amazon SQS easing message management between components. 

The queue acts as a buffer between the component producing and saving data and the component receiving the data for processing. This means that the queue resolves issues if the producer (for example, a web front end) is producing work faster than the consumer (such as the application worker) can process it or if the producer or consumer is only intermittently connected to the network.

Amazon SQS is designed to deliver your message at least once and supports multiple readers and writers interacting with the same queue. A single queue can be used simultaneously by many distributed application components, and those components do not need to coordinate to share it.

Amazon SQS is engineered to always be available and deliver messages. This is achieved by the system being distributed between multiple machines and multiple facilities. Due to this highly distributed architecture, there is a trade-off—Amazon SQS does not guarantee FIFO delivery of messages when using standard queues. 

This may be okay for many distributed applications as long as each message can stand on its own and as long as all messages are delivered. In that scenario, the order is not important. If your system requires that an order be preserved, you can place sequencing information in each message to reorder the messages when the queue returns them.

Q9: What Are Some Use Cases For Amazon SQS?

A: Some use cases of Amazon SQS include:

• Integrate Amazon SQS with other AWS infrastructure web services to make applications more reliable and flexible.

• Use an Amazon SQS queue as a work queue, where each message is a task that needs to be completed by a process. One or many computers can read tasks from the queue and perform them.

• Have Amazon SQS help a browser-based application receive notifications from a server. The application server can add the notifications to a queue, which the browser can poll even if a firewall exists between them.

• Keep notifications of significant events in a business process in an Amazon SQS queue. Each event can have a corresponding message in a queue, and applications that need to be aware of the event can read and process the messages.

Q10: What Are The Types Of Polling Methods SQS Supports?

A: When you retrieve messages from the queue, Amazon SQS samples a subset of the servers and returns messages from just those servers. Amazon SQS supports two types of polling methods:

• Short polling means a sample of queues is polled, and a particular received request might not return all of your messages, whereas a subsequent request will. If you keep retrieving from your queues, Amazon SQS will sample all of the servers, and you will receive all of your messages. This can be CPU-intensive for your application.

• Long polling reduces the number of empty responses by allowing Amazon SQS to wait until a message is available in the queue before sending a response. Unless the connection times out, the response to the ReceiveMessage request contains at least one of the available messages, up to the maximum number of messages specified in the ReceiveMessage action.

Q11: What Is Visibility Timeout?

A: Visibility timeout is when a message is invisible to the rest of your application after an application component gets it from the queue. During the visibility timeout, the component that received the message usually processes it and then deletes it from the queue. This prevents multiple components from processing the same message.

Here is how it works:

• When a message is received, it becomes "locked" while being processed. This prevents it from being processed by other components.

• The component receiving the message processes and deletes it from the queue.

• If message processing fails, the lock expires, and the message becomes available again (fault tolerance).

When the application needs more time for processing, the visibility timeout can be changed dynamically via the ChangeMessageVisibility operation.

Q12: What Are Standard Queues?

A: Amazon SQS offers standard queues as the default queue type. A standard queue allows you to have a nearly unlimited number of transactions per second and supports at-least-once message delivery. Occasionally (because of its highly distributed architecture), however, more than one copy of a message might be delivered out of order. Standard queues provide best-effort ordering versus a First-In, First-Out (FIFO) queue. This ensures that messages are delivered in the same order as they're sent.

You can use standard message queues in many scenarios if your application can process messages that arrive more than once and are out of order. For example:

• Decouple live user requests from intensive background work: Let users upload media while resizing or encoding it.

• Allocate tasks to multiple worker nodes: Process many credit card validation requests.

• Batch messages for future processing: Schedule multiple entries to be added to a database.

Q13: What Is Auto Scaling?

A: Auto Scaling is a web service designed to automatically launch or terminate Amazon EC2 instances based on user-defined policies, schedules, and health checks. Application Auto Scaling automatically scales supported AWS Cloud services with an experience similar to Auto Scaling for Amazon EC2 resources. Application Auto Scaling works with Amazon EC2 Container Service (Amazon ECS) and will not be covered in this guide.

Auto Scaling helps to ensure that you have the correct number of Amazon EC2 instances available to handle the load for your application. You create collections of Amazon EC2 instances called Auto Scaling groups. You can specify the minimum number of instances in each Auto Scaling group, and Auto Scaling ensures that your group never goes below this size. 

Likewise, you can specify the maximum number of instances in each Auto Scaling group, and Auto Scaling ensures that your group never goes above this size. If you specify the desired capacity, when you create the group or at any time after that, Auto Scaling ensures that your group has many instances. If you specify scaling policies, Auto Scaling can launch or terminate instances on demand as your application needs increase or decrease.

Q14: What Are The Components Of Auto Scaling?

A: Auto Scaling components include:

Launch configuration- Launch configuration defines how Auto Scaling should launch your Amazon EC2 instances. Auto Scaling provides you with an option to create a new launch configuration using the attributes from an existing Amazon EC2 instance. When you use this option, Auto Scaling copies the attributes from the specified instance into a template from which you can launch one or more Auto Scaling groups.

Auto Scaling group- Your Auto Scaling group uses a launch configuration to launch Amazon EC2 instances. You create the launch configuration by providing information about the image that you want Auto Scaling to use to launch Amazon EC2 instances. The information can be the image ID, instance type, key pairs, security groups, and block device mapping.

Auto Scaling policy- An Auto Scaling group uses a combination of policies and alarms to determine when the specified conditions for launching and terminating instances are met. An alarm is an object that watches over a single metric (for example, the average CPU utilization of your Amazon EC2 instances in an Auto Scaling group) over a specified period. When the metric's value breaches the thresholds you define over several specified periods, the alarm performs one or more actions. An action can be sending messages to Auto Scaling.

Scheduled action- Scheduled action is scaling based on a schedule, allowing you to scale your application in response to predictable load changes. You need to create scheduled actions to configure your Auto Scaling group to scale based on a schedule. A scheduled action tells Auto Scaling to perform a scaling action at a certain time. 

To create a scheduled scaling action, you specify the start time at which you want the scaling action to take effect, along with the new minimum, maximum, and desired size you want for that group at that time. At the specified time, Auto Scaling will update the group to set the new values for minimum, maximum, and desired sizes, as specified by your scaling action.

Q15: What Is The Auto Recovery Feature In Amazon EC2?

A: Auto Recovery is an Amazon EC2 feature that increases instance availability. It allows you to recover supported instances automatically when a system impairment is detected.

To use Auto Recovery, create an Amazon CloudWatch Alarm that monitors an Amazon EC2 instance and automatically recovers it if it becomes impaired due to an underlying hardware failure or a problem that requires AWS involvement to repair. Terminated instances cannot be recovered. A recovered instance is identical to the original instance, including the instance ID, private IP addresses, elastic IP addresses, and all instance metadata.

When the StatusCheckFailed_System alarm is triggered, and the recovery action is initiated, you will be notified by the Amazon SNS topic that you selected when you created the alarm and associated the recovery action. During instance recovery, the instance is migrated during an instance reboot, and any data in memory is lost. When the process is complete, information is published to the Amazon SNS topic you configured for the alarm.

Anyone subscribed to this Amazon SNS topic will receive an email notification that includes the status of the recovery attempt and any further instructions. You will notice an instance reboot on the recovered instance.

Q16: How Do You Set Up The Failover Configuration Using Amazon Route 53?

A: You can set up various failover configurations using Amazon Route 53 alias, weighted, latency, geolocation routing, and failover resource record sets.

Active-active failover- Use this failover configuration when you want all of your resources to be available the majority of the time. When a resource becomes unavailable, Amazon Route 53 can detect it as unhealthy and stop including it when responding to queries.

Active-passive failover- Use this failover configuration when you want a primary group of resources to be available the majority of the time and a secondary group of resources to be on standby in case all of the primary resources become unavailable. When responding to queries, Amazon Route 53 includes only healthy primary resources. If all primary resources are unhealthy, Amazon Route 53 begins to include only the healthy secondary resources in response to DNS queries.

Active-active-passive and other mixed configurations- You can combine alias and non-alias resource record sets to produce a variety of Amazon Route 53 behaviors.

For these failover configurations to work, health checks will need to be configured. There are three types of health checks: health checks that monitor an endpoint, health checks that monitor Amazon CloudWatch Alarms, and health checks that monitor other health checks.

Q17: What Is Disaster Recovery?

A: Disaster recovery (DR) is about preparing for and recovering from a disaster. Any event that hurts your company's business continuity or finances could be a disaster. This includes hardware or software failure, a network or power outage, physical damage to a building like fire or flooding, human error, or other significant event. You should plan on minimizing the impact of a disaster by investing time and resources to plan and prepare, train employees, and document and update processes.

The amount of investment for DR planning for a particular system can vary dramatically depending on the cost of a potential outage. Companies with traditional physical environments typically must duplicate their infrastructure to ensure spare capacity is available in the event of a disaster. The infrastructure must be procured, installed and maintained to support the anticipated capacity requirements. 

During normal operations, the infrastructure typically is under-utilized or over-provisioned. With Amazon Web Services (AWS), your company can scale up its infrastructure on an as-needed, pay-as-you-go basis. You get access to the same highly secure, reliable, and fast infrastructure that Amazon uses to run its global network of websites. AWS also allows you to change and optimize resources quickly during a DR event, which can result in significant cost savings.

Q18: What Are The Common Terms For Disaster Planning?

A: We will be using two common industry terms for disaster planning:

Recovery time objective (RTO) This represents the time it takes after a disruption to restore a business process to its service level, as defined by the operational level agreement (OLA). For example, if a disaster occurs at 12:00 PM (noon) and the RTO is eight hours, the DR process should restore the business process to the acceptable service level by 8:00 PM.

Recovery point objective (RPO) This is the acceptable amount of data loss measured in time. For example, if a disaster occurs at 12:00 PM (noon) and the RPO is one hour, the system should recover all data that was in the system before 11:00 AM. Data loss will span only one hour between 11:00 AM and 12:00 PM (noon).

A company typically decides on an acceptable RTO and RPO based on the financial impact on the business when systems are unavailable. The company determines the financial impact by considering many factors, such as the loss of business and damage to its reputation due to downtime and the lack of system availability.

IT organizations then plan solutions to provide cost-effective system recovery based on the RPO within the timeline and the RTO's established service level.

Conclusion

JanBask Training's AWS courses provide comprehensive training on building high-availability architecture in AWS, equipping professionals with the skills needed to excel in AWS interviews. These courses cover various topics, including designing fault-tolerant systems, implementing auto-scaling and load balancing, configuring disaster recovery solutions, and optimizing performance.