Reliability pillar principles in AWS - Commands & Configuration

Introduction

Reliability means making sure your app or service keeps working well even if things go wrong. It helps avoid downtime and keeps users happy by handling failures smoothly.

When you want your website to stay online even if a server crashes

When you need your app to recover quickly from unexpected errors

When you want to test how your system behaves under failure conditions

When you want to automatically fix problems without manual help

When you want to plan for growth without losing service quality

Commands

This command creates an alarm that watches CPU usage on an EC2 instance. If CPU usage goes above 80% for 2 periods of 5 minutes, it triggers an alert to notify or take action. This helps detect problems early.

Terminal

aws cloudwatch put-metric-alarm --alarm-name HighCPUUtilization --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 80 --comparison-operator GreaterThanThreshold --dimensions Name=InstanceId,Value=i-0123456789abcdef0 --evaluation-periods 2 --alarm-actions arn:aws:sns:us-east-1:123456789012:MyTopic --unit Percent

Expected Output

No output (command runs silently)

→

--alarm-name - Name of the alarm

→

--threshold - Value that triggers the alarm

→

--alarm-actions - What happens when alarm triggers

This command creates an auto scaling group that keeps the number of EC2 instances between 1 and 3. It automatically adds or removes instances to keep the app running smoothly during changes in demand.

Terminal

aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg --launch-configuration-name my-launch-config --min-size 1 --max-size 3 --desired-capacity 2 --vpc-zone-identifier subnet-12345678

Expected Output

No output (command runs silently)

→

--min-size - Minimum number of instances

→

--max-size - Maximum number of instances

→

--desired-capacity - Starting number of instances

This command checks the current status of the auto scaling group to see how many instances are running and if scaling actions happened.

Terminal

aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names my-asg

Expected Output

{

    "AutoScalingGroups": [

        {

            "AutoScalingGroupName": "my-asg",

            "MinSize": 1,

            "MaxSize": 3,

            "DesiredCapacity": 2,

            "Instances": [

                {

                    "InstanceId": "i-0123456789abcdef0",

                    "LifecycleState": "InService",

                    "HealthStatus": "Healthy"

                },

                {

                    "InstanceId": "i-0fedcba9876543210",

                    "LifecycleState": "InService",

                    "HealthStatus": "Healthy"

                }

            ]

        }

    ]

}

Key Concept

If you remember nothing else from this pattern, remember: design your system to detect problems early and automatically fix them to keep your service running smoothly.

Common Mistakes

Not setting alarms for important metrics like CPU or disk space

Without alarms, you won't know when your system is struggling until users complain or it crashes

Set alarms on key metrics to get notified early and take action

Setting auto scaling min and max sizes too narrow

If min and max are the same, auto scaling can't adjust capacity to handle load changes

Set a range that allows scaling up and down based on demand

Not verifying auto scaling group status after creation

You might think scaling is working but instances could be unhealthy or missing

Use describe commands to check the health and number of instances regularly

Summary

Create alarms to watch important system metrics and get notified of issues.

Use auto scaling groups to automatically add or remove servers based on demand.

Check the status of your auto scaling groups to ensure your system stays healthy.

Practice

1. What is the main goal of the Reliability pillar in cloud architecture?

easy

A. To reduce the cost of cloud services

B. To keep systems working well and recover quickly from failures

C. To improve the visual design of applications

D. To increase the speed of data processing

Solution

1. Step 1: Understand the purpose of the Reliability pillar

   The Reliability pillar focuses on system uptime and fast recovery from issues.

2. Step 2: Compare options with the pillar's goal

   Only To keep systems working well and recover quickly from failures matches the goal of keeping systems working well and recovering quickly.

3. Final Answer:

   To keep systems working well and recover quickly from failures -> Option B

4. Quick Check:

   Reliability = keep systems working and recover fast [OK]

Hint: Reliability means uptime and fast recovery [OK]

Common Mistakes:

• Confusing reliability with cost savings
• Thinking reliability is about design or speed only
• Ignoring recovery after failure

2. Which AWS service is commonly used to monitor system health and trigger alerts for reliability?

easy

A. Amazon S3

B. Amazon EC2

C. Amazon CloudWatch

D. AWS Lambda

Solution

1. Step 1: Identify monitoring services in AWS

   Amazon CloudWatch is designed to monitor resources and send alerts.

2. Step 2: Eliminate unrelated services

   Amazon S3 is for storage, Lambda for running code, EC2 for servers, so they don't primarily monitor health.

3. Final Answer:

   Amazon CloudWatch -> Option C

4. Quick Check:

   Monitoring and alerts = CloudWatch [OK]

Hint: CloudWatch monitors and alerts in AWS [OK]

Common Mistakes:

• Choosing storage or compute services instead of monitoring
• Confusing Lambda with monitoring
• Not knowing CloudWatch's role

3. Consider this AWS setup: An application uses multiple Availability Zones (AZs) with automatic failover. What is the expected behavior if one AZ fails?

medium

A. The application performance improves in the failed AZ

B. The application stops working until the failed AZ is restored

C. The application data is lost permanently

D. Traffic automatically shifts to healthy AZs to keep the app running

Solution

1. Step 1: Understand multi-AZ and failover

   Using multiple AZs with failover means if one AZ fails, traffic moves to others automatically.

2. Step 2: Analyze each option

   The application stops working until the failed AZ is restored is false because failover prevents downtime. The application data is lost permanently is false because data is replicated. The application performance improves in the failed AZ is illogical as failed AZ cannot improve performance.

3. Final Answer:

   Traffic automatically shifts to healthy AZs to keep the app running -> Option D

4. Quick Check:

   Multi-AZ failover = automatic traffic shift [OK]

Hint: Failover shifts traffic to healthy zones automatically [OK]

Common Mistakes:

• Assuming app stops during AZ failure
• Thinking data is lost without backups
• Believing failed AZ improves performance

4. You have a backup system that runs daily but sometimes misses backups due to network issues. What is the best way to improve reliability?

medium

A. Add monitoring and alerts to detect backup failures immediately

B. Reduce backup frequency to weekly

C. Ignore the missed backups since they are rare

D. Delete old backups to save space

Solution

1. Step 1: Identify the problem with backup reliability

   Missed backups reduce reliability and risk data loss.

2. Step 2: Choose a solution that improves detection and response

   Adding monitoring and alerts helps detect failures quickly and fix them, improving reliability.

3. Final Answer:

   Add monitoring and alerts to detect backup failures immediately -> Option A

4. Quick Check:

   Detect failures fast = add monitoring and alerts [OK]

Hint: Monitor backups to catch failures early [OK]

Common Mistakes:

• Ignoring backup failures
• Reducing backup frequency which lowers reliability
• Deleting backups without ensuring new ones exist

5. A company wants to design a highly reliable web application on AWS. Which combination of strategies best supports the Reliability pillar?

hard

A. Deploy across multiple Availability Zones, automate backups, and enable CloudWatch alarms

B. Use single Availability Zone, manual backups, and no monitoring

C. Use only on-premises servers with no cloud services

D. Deploy in one region with no failover and no testing

Solution

1. Step 1: Identify key reliability strategies

   Reliability requires redundancy (multi-AZ), automated backups, and monitoring with alerts.

2. Step 2: Evaluate each option

   Deploy across multiple Availability Zones, automate backups, and enable CloudWatch alarms includes all key strategies. Options A, C, and D lack redundancy, automation, or monitoring, reducing reliability.

3. Final Answer:

   Deploy across multiple Availability Zones, automate backups, and enable CloudWatch alarms -> Option A

4. Quick Check:

   Multi-AZ + backups + monitoring = high reliability [OK]

Hint: Combine multi-AZ, backups, and monitoring for reliability [OK]

Common Mistakes:

• Choosing single AZ or no monitoring
• Ignoring automation and failover
• Relying only on on-premises servers