Why defense in depth matters in AWS - See It in Action

Why defense in depth matters

📖 Scenario: You are working as a cloud engineer for a small company. Your manager wants you to set up a simple AWS environment that shows how multiple layers of security protect the company's data and services. This is called defense in depth. Think of it like locking your house with a door lock, window locks, and an alarm system. Each layer adds more safety.

🎯 Goal: Build a basic AWS setup with multiple security layers: a Virtual Private Cloud (VPC), a security group, and an IAM role. This will demonstrate how defense in depth works by protecting resources at different levels.

📋 What You'll Learn

Create a VPC with a specific CIDR block

Create a security group that allows only SSH access from a trusted IP

Create an IAM role with a policy that allows read-only access to S3

💡 Why This Matters

🌍 Real World

Companies use defense in depth to protect their cloud environments by adding multiple security layers. This reduces the chance of unauthorized access or data leaks.

💼 Career

Cloud engineers and security specialists must understand how to configure layered security in AWS to build safe and compliant infrastructures.

1

Create a VPC

Create a variable called vpc_cidr and set it to the string "10.0.0.0/16". Then create a VPC resource named my_vpc using the vpc_cidr as its CIDR block.

AWS

# Your code here

Hint

Start by defining the CIDR block as a string variable. Then use it in the VPC resource properties.

2

Create a Security Group

Create a variable called trusted_ip and set it to the string "203.0.113.0/24". Then create a security group resource named ssh_sg that belongs to my_vpc and allows inbound SSH (port 22) access only from trusted_ip.

AWS

vpc_cidr = "10.0.0.0/16"

my_vpc = {
    "Type": "AWS::EC2::VPC",
    "Properties": {
        "CidrBlock": vpc_cidr
    }
}

# Your code here

Hint

Define the trusted IP as a string variable. Then create the security group with inbound rules referencing that IP.

3

Create an IAM Role

Create a variable called read_only_policy that contains the AWS managed policy ARN for Amazon S3 read-only access: "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess". Then create an IAM role resource named s3_read_role that attaches this policy.

AWS

vpc_cidr = "10.0.0.0/16"

my_vpc = {
    "Type": "AWS::EC2::VPC",
    "Properties": {
        "CidrBlock": vpc_cidr
    }
}

trusted_ip = "203.0.113.0/24"

ssh_sg = {
    "Type": "AWS::EC2::SecurityGroup",
    "Properties": {
        "VpcId": {"Ref": "MyVPC"},
        "GroupDescription": "Allow SSH from trusted IP",
        "SecurityGroupIngress": [
            {
                "IpProtocol": "tcp",
                "FromPort": 22,
                "ToPort": 22,
                "CidrIp": trusted_ip
            }
        ]
    }
}

# Your code here

Hint

Use the AWS managed policy ARN for S3 read-only access. Attach it to the IAM role's managed policies.

4

Combine all resources into a CloudFormation template

Create a dictionary called cloudformation_template with a key Resources that includes my_vpc, ssh_sg, and s3_read_role as its entries.

AWS

vpc_cidr = "10.0.0.0/16"

my_vpc = {
    "Type": "AWS::EC2::VPC",
    "Properties": {
        "CidrBlock": vpc_cidr
    }
}

trusted_ip = "203.0.113.0/24"

ssh_sg = {
    "Type": "AWS::EC2::SecurityGroup",
    "Properties": {
        "VpcId": {"Ref": "MyVPC"},
        "GroupDescription": "Allow SSH from trusted IP",
        "SecurityGroupIngress": [
            {
                "IpProtocol": "tcp",
                "FromPort": 22,
                "ToPort": 22,
                "CidrIp": trusted_ip
            }
        ]
    }
}

read_only_policy = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"

s3_read_role = {
    "Type": "AWS::IAM::Role",
    "Properties": {
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Principal": {"Service": "ec2.amazonaws.com"},
                    "Action": "sts:AssumeRole"
                }
            ]
        },
        "ManagedPolicyArns": [read_only_policy]
    }
}

# Your code here

Hint

Put all your resources inside a dictionary under the key "Resources" with clear names.

Practice

1. Why is defense in depth important in AWS cloud security?

easy

A. It only uses encryption without other security measures.

B. It relies on a single strong password to secure all resources.

C. It removes all security layers to improve performance.

D. It uses multiple layers to protect resources, so if one fails, others still protect.

Solution

1. Step 1: Understand defense in depth concept

   Defense in depth means using several security layers to protect cloud resources.

2. Step 2: Recognize the benefit of multiple layers

   If one layer fails, other layers still protect the data, increasing overall security.

3. Final Answer:

   It uses multiple layers to protect resources, so if one fails, others still protect. -> Option D

4. Quick Check:

   Multiple layers = safer protection [OK]

Hint: Multiple layers protect better than one [OK]

Common Mistakes:

• Thinking one strong password is enough
• Believing encryption alone is full protection
• Ignoring the need for backup security layers

2. Which AWS service is NOT typically part of a defense in depth strategy?

easy

A. AWS Identity and Access Management (IAM)

B. AWS Key Management Service (KMS)

C. Amazon Simple Notification Service (SNS)

D. AWS Web Application Firewall (WAF)

Solution

1. Step 1: Identify services used for security layers

   IAM controls access, KMS manages encryption keys, WAF protects web apps.

2. Step 2: Recognize SNS purpose

   SNS is for messaging and notifications, not a security control layer.

3. Final Answer:

   Amazon Simple Notification Service (SNS) -> Option C

4. Quick Check:

   SNS is messaging, not security [OK]

Hint: SNS is for notifications, not security [OK]

Common Mistakes:

• Confusing SNS with security services
• Assuming all AWS services add security layers
• Ignoring the role of IAM and WAF

3. Given this AWS setup: IAM roles restrict access, data is encrypted with KMS, and VPC security groups limit traffic. What happens if an attacker bypasses the security group?

medium

A. The attacker is blocked by IAM roles and encrypted data remains protected.

B. The attacker can access data without any other barriers.

C. The attacker can change encryption keys easily.

D. The attacker can disable KMS encryption remotely.

Solution

1. Step 1: Analyze the layered security setup

   Security groups limit traffic, IAM controls access, KMS encrypts data.

2. Step 2: Consider bypassing security group

   If security group is bypassed, IAM roles still restrict access and encryption protects data.

3. Final Answer:

   The attacker is blocked by IAM roles and encrypted data remains protected. -> Option A

4. Quick Check:

   Multiple layers block attacker even if one fails [OK]

Hint: Bypass one layer, others still protect [OK]

Common Mistakes:

• Assuming bypassing one layer means full access
• Thinking encryption keys can be changed easily
• Believing KMS can be disabled remotely

4. You configured AWS WAF rules but still see unwanted traffic reaching your application. What is the most likely mistake?

medium

A. Not attaching the WAF to the correct resource like CloudFront or ALB.

B. Using IAM roles instead of WAF for traffic filtering.

C. Encrypting data with KMS before applying WAF rules.

D. Disabling CloudTrail logging.

Solution

1. Step 1: Understand WAF role and attachment

   WAF must be attached to resources like CloudFront or Application Load Balancer to filter traffic.

2. Step 2: Identify common misconfiguration

   If WAF is not attached properly, it won't filter traffic, allowing unwanted requests.

3. Final Answer:

   Not attaching the WAF to the correct resource like CloudFront or ALB. -> Option A

4. Quick Check:

   WAF must be attached to filter traffic [OK]

Hint: Attach WAF to resource to filter traffic [OK]

Common Mistakes:

• Confusing IAM roles with traffic filtering
• Thinking encryption affects WAF filtering
• Ignoring resource attachment for WAF

5. You want to design a defense in depth strategy for an AWS web app. Which combination of layers provides the best protection?

hard

A. Encrypt data but allow open access to all resources for easy management.

B. Use IAM for access control, encrypt data with KMS, enable VPC security groups, and enable CloudTrail logging.

C. Rely on security groups alone to block all unwanted traffic.

D. Use only IAM roles and skip encryption and logging to reduce complexity.

Solution

1. Step 1: Identify key defense layers for AWS security

   IAM controls who can access, KMS protects data, security groups limit network traffic, CloudTrail logs actions for auditing.

2. Step 2: Evaluate options for best defense in depth

   Use IAM for access control, encrypt data with KMS, enable VPC security groups, and enable CloudTrail logging, which combines multiple layers, providing strong protection and monitoring.

3. Final Answer:

   Use IAM for access control, encrypt data with KMS, enable VPC security groups, and enable CloudTrail logging. -> Option B

4. Quick Check:

   Multiple layers + monitoring = best defense [OK]

Hint: Combine access, encryption, network, and logging layers [OK]

Common Mistakes:

• Skipping encryption or logging
• Relying on one security layer only
• Allowing open access for convenience