Hands-On Lab: Designing Secure Workloads on AWS

Welcome to this guided lab on designing secure workloads and applications. In alignment with the AWS Certified Solutions Architect - Associate (SAA-C03) domain, this lab demonstrates how to implement a defense-in-depth strategy. We will secure the network infrastructure using Virtual Private Cloud (VPC) components, configure least-privilege Security Groups, and enable Amazon GuardDuty for continuous threat detection.

Prerequisites

Before beginning this lab, ensure you have the following:

An active AWS Account with Administrator or equivalent IAM permissions.
AWS CLI installed and configured (aws configure) with appropriate access keys.
Basic familiarity with terminal/command-line interfaces.
Estimated Cost: Most resources fall under the AWS Free Tier, but Amazon GuardDuty incurs a small cost (usually pennies for a short lab).

Learning Objectives

By completing this lab, you will be able to:

Construct a logically isolated VPC network with public and private segmentation.
Design and implement Security Groups enforcing the principle of least privilege.
Deploy a secure EC2 workload within the isolated network.
Enable and verify Amazon GuardDuty to monitor for malicious activity.

Architecture Overview

The following diagram illustrates the defense-in-depth architecture we will build. Traffic must pass through multiple security boundaries before reaching the workload.

Loading Diagram...

To visualize the boundary layers conceptually, here is a breakdown of our defense-in-depth model:

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Step-by-Step Instructions

Step 1: Create the VPC and Subnet

First, we will build the foundational network infrastructure. A custom VPC ensures your workload is isolated from default environments.

bash

# Create a new VPC
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=brainybee-secure-vpc}]'

# Note the VpcId from the output (e.g., vpc-0abcd1234)
# Export it as a variable for future steps (Linux/Mac)
export VPC_ID="<YOUR_VPC_ID>"

# Create a public subnet
aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block 10.0.1.0/24 --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=brainybee-public-subnet}]'

📸 Screenshot: Terminal output showing the successful creation of the VPC and Subnet JSON payload.

▶Console alternative

Navigate to VPC > Your VPCs.
Click Create VPC.
Choose VPC only, set the Name tag to brainybee-secure-vpc, and IPv4 CIDR to 10.0.0.0/16.
Navigate to Subnets > Create subnet.
Select your new VPC, name it brainybee-public-subnet, and set CIDR to 10.0.1.0/24.

Step 2: Configure a Least-Privilege Security Group

Security Groups act as stateful firewalls. We will design one that only permits required traffic (e.g., HTTPS).

bash

# Create the Security Group
aws ec2 create-security-group --group-name brainybee-secure-sg --description "Strict security group for workload" --vpc-id $VPC_ID

# Note the GroupId from the output
export SG_ID="<YOUR_SG_ID>"

# Authorize inbound HTTPS ONLY. We drop SSH (Port 22) for security, relying on Session Manager if access is needed later.
aws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 443 --cidr 0.0.0.0/0

[!TIP] By not opening Port 22 (SSH), we mitigate a significant external threat vector, aligning with the SAA-C03 best practices for credential and access security.

▶Console alternative

Navigate to EC2 > Security Groups.
Click Create security group.
Name it brainybee-secure-sg and select brainybee-secure-vpc.
Under Inbound rules, add a rule: Type HTTPS, Source Anywhere-IPv4.
Do NOT add an SSH rule. Click Create security group.

Step 3: Launch the Secure EC2 Workload

Now we deploy an instance into our secured subnet using the security group we just created.

bash

# Find the latest Amazon Linux 2023 AMI ID in your region (using SSM)
export AMI_ID=$(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.1-x86_64 --query "Parameters[0].Value" --output text)
export SUBNET_ID="<YOUR_SUBNET_ID>"

# Launch the instance
aws ec2 run-instances \
    --image-id $AMI_ID \
    --count 1 \
    --instance-type t2.micro \
    --security-group-ids $SG_ID \
    --subnet-id $SUBNET_ID \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=brainybee-secure-workload}]'

▶Console alternative

Navigate to EC2 > Instances > Launch instances.
Name: brainybee-secure-workload.
AMI: Amazon Linux 2023 AMI.
Instance type: t2.micro.
Network settings: Edit to select brainybee-secure-vpc and brainybee-public-subnet.
Security group: Select existing group brainybee-secure-sg.
Click Launch instance.

Step 4: Enable Threat Detection with Amazon GuardDuty

GuardDuty provides intelligent threat detection using machine learning. It monitors VPC Flow Logs, CloudTrail, and DNS logs continuously.

bash

# Create a GuardDuty detector to enable the service
aws guardduty create-detector --enable

📸 Screenshot: GuardDuty console showing the service enabled and waiting for findings.

▶Console alternative

Search for GuardDuty in the AWS Console search bar.
Click Get Started.
Click the Enable GuardDuty button.

Checkpoints

Verify that your configurations are correctly applied:

1. Verify VPC and Subnet Creation:

bash

aws ec2 describe-vpcs --filters Name=tag:Name,Values=brainybee-secure-vpc --query "Vpcs[0].VpcId"

Expected Result: Returns your VPC ID.

2. Verify Security Group Rules:

bash

aws ec2 describe-security-groups --group-ids $SG_ID --query "SecurityGroups[0].IpPermissions"

Expected Result: Shows only port 443 open. No port 22 should be listed.

3. Check GuardDuty Status:

bash

aws guardduty list-detectors

Expected Result: Returns an array with at least one DetectorId string.

Teardown

[!WARNING] Remember to run the teardown commands to avoid ongoing charges, especially for Amazon GuardDuty.

Follow these commands sequentially to clean up your environment:

bash

# 1. Terminate the EC2 Instance
aws ec2 terminate-instances --instance-ids <YOUR_INSTANCE_ID>
# Wait a few minutes for the instance to fully terminate before proceeding

# 2. Delete the Security Group
aws ec2 delete-security-group --group-id $SG_ID

# 3. Delete the Subnet
aws ec2 delete-subnet --subnet-id $SUBNET_ID

# 4. Delete the VPC
aws ec2 delete-vpc --vpc-id $VPC_ID

# 5. Disable GuardDuty (Replace DETECTOR_ID with the output from list-detectors)
aws guardduty delete-detector --detector-id <YOUR_DETECTOR_ID>

Troubleshooting

Error Message	Likely Cause	Solution
`InvalidVpcID.NotFound`	The VPC ID variable was not exported or typed correctly.	Verify your VPC ID in the console or by running `aws ec2 describe-vpcs` and re-export the variable.
`DependencyViolation` when deleting VPC	The EC2 instance or Subnet still exists inside the VPC.	Terminate the instance, wait 2-3 minutes for it to completely shut down, delete the subnet, and try again.
`UnauthorizedOperation`	Your IAM user lacks permissions for EC2 or GuardDuty.	Ensure you are logged into an IAM user or role with `AdministratorAccess` or sufficient specific policies.
`InvalidParameterValue` for AMI ID	The SSM parameter path is incorrect or AMI is unavailable in your region.	Navigate to the EC2 Launch wizard in the console, copy the AMI ID provided there, and pass it directly to the CLI command.