Secure Architecture Scenarios

Scenario: An EC2 instance runs a web application that needs to read objects from a specific S3 bucket. The security team requires that no long-term credentials are stored on the instance and that access follows the principle of least privilege. Solution: Create an IAM role with a policy allowing only s3:GetObject on the specific bucket ARN. Attach the role to the EC2 instance as an instance profile. The application uses the instance metadata service (IMDS) to retrieve temporary credentials automatically — no stored keys needed.

Scenario: A company stores customer PII in an RDS PostgreSQL database. The compliance team requires encryption at rest with the ability to audit key usage. Solution: Enable RDS encryption using AWS KMS with a Customer Managed Key (CMK). The CMK allows the security team to control key rotation, view key usage in CloudTrail, and revoke access if needed. Note: encryption must be enabled at RDS instance creation — you cannot encrypt an existing unencrypted RDS instance in place. To encrypt an existing DB, take a snapshot, copy it with encryption enabled, and restore from the encrypted snapshot.

Scenario: A developer accidentally made an S3 bucket public, exposing customer data. The security team wants to ensure no S3 bucket in the account can ever be made public, even if a developer tries. Solution: Enable S3 Block Public Access at the account level. This overrides any bucket-level policy or ACL that grants public access, regardless of what individual teams configure. Combine with an AWS Config rule (s3-bucket-public-read-prohibited) to continuously detect and alert on any non-compliant buckets.

Scenario: A company wants to ensure their RDS database is only accessible from their application servers and not from the internet. Solution: Place RDS in a private subnet with no internet gateway route. Create a security group for RDS that only allows inbound traffic on port 5432 (PostgreSQL) from the application server security group — not from any IP address range. This ensures that even if an app server is compromised, the attacker cannot reach the database from outside the VPC, and lateral movement is limited by security group rules.

Scenario: Application code currently has database credentials hardcoded in configuration files. The security audit flags this as a critical risk. Solution: Store credentials in AWS Secrets Manager and configure automatic rotation (Secrets Manager has built-in Lambda rotation functions for RDS). Update the application to fetch credentials from Secrets Manager at runtime using the SDK. The application automatically gets fresh credentials without any deployment on each rotation. Enable the RDS secret rotation template for fully managed, zero-downtime credential rotation.

Scenario: A company wants to detect if AWS account credentials are compromised and used from unexpected locations. Solution: Enable Amazon GuardDuty in all Regions. GuardDuty analyses CloudTrail events, VPC Flow Logs, and DNS logs using machine learning to detect anomalies: API calls from unusual geographies, Bitcoin mining patterns on EC2, Tor exit node communication, or credential exfiltration patterns. GuardDuty generates findings that can trigger EventBridge rules to automatically notify the security team via SNS or create a support ticket.

Scenario: A web application running behind an ALB is receiving SQL injection attacks. The application cannot be modified immediately. Solution: Associate AWS WAF with the ALB. Deploy the AWS Managed Rules for Common Threats rule group (Core Rule Set + SQL Database rule group) which includes pre-built SQL injection detection. WAF inspects HTTP requests before they reach the ALB and blocks requests matching attack patterns — no application code change required. Also enable WAF logging to Kinesis Firehose for security analysis.

Scenario: A central security account needs read-only access to all workload accounts in an AWS Organisation to run security audits. Solution: In each workload account, create an IAM role with a trust policy allowing the security account (by account ID) to assume it. Attach a read-only policy (e.g., SecurityAudit AWS managed policy). The security team in the central account uses STS AssumeRole to temporarily assume the role in each workload account. This follows the principle of least privilege — no permanent IAM users are created in workload accounts.

Scenario: A company uses AWS Organizations and wants to prevent any account in a non-production OU from launching expensive GPU instances. Solution: Create a Service Control Policy (SCP) that denies ec2:RunInstances for GPU instance families (p3, p4, g4, g5) and attach it to the non-production OU. SCPs apply even to root users and Administrator-level IAM users in the member accounts — they act as guardrails that no identity in the account can override. This prevents accidental or malicious large spend in dev/test accounts.

Scenario: A financial services company must demonstrate to auditors that all AWS API calls are logged, tamper-proof, and retained for 7 years. Solution: Create a multi-region AWS CloudTrail trail that delivers logs to a dedicated S3 bucket in a logging account. Enable Log File Integrity Validation (cryptographic digest files that detect log tampering). Set an S3 Object Lock policy in Compliance mode with a 7-year retention period on the logging bucket. This ensures logs cannot be deleted or modified — even by the root user — for the required retention period.

Scenario: EC2 instances in a private VPC need to access S3 without traffic traversing the public internet. A NAT Gateway is currently used and costs are high due to NAT Gateway data processing fees. Solution: Create an S3 Gateway VPC Endpoint. Add a route entry to the private subnet's route table pointing the S3 prefix list to the endpoint. Traffic to S3 now stays within the AWS network backbone entirely — no NAT Gateway, no internet gateway needed. S3 Gateway Endpoints are free of charge (unlike Interface Endpoints which cost per-hour per-AZ). This also improves security by removing S3 access from the public internet path.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you worked through scenarios covering: IAM roles and instance profiles for credential-free EC2 access, Secrets Manager for automatic database credential rotation, AWS WAF for blocking injection attacks without code changes, and CloudTrail with S3 Object Lock for tamper-proof compliance logs. Next up we tackle resilient and highly available architecture scenarios.