Skip to main content
Welcome, future solutions architects. I’m Michael Forrester. This lesson introduces Designing for Security concepts for AWS network services. We’ll focus on “turning up” security on services you already know — highlighting which knobs and features to use, how to map stakeholder requests to security domains, and how to reason about trade-offs between security effectiveness, cost, performance, and operational overhead. Take notes — there’s a lot to cover and we’ll move at a steady pace. This lesson emphasizes practical controls and design conversations more than introducing new AWS services.

​
How design conversations start

Security design requests usually arrive as specific asks. Examples:
  • “Can we secure the data we’re storing on AWS?” (S3, RDS)
  • “Please ensure all systems are patched to a specific Java version.”
  • “Can we increase logging for access to this resource?”
As an architect you should translate a stakeholder request into the security domain it targets (data protection, identity & access management, detection, infrastructure protection, application security, security foundations, or incident response) and then map that domain to service features that satisfy the requirement. Often a managed AWS service already provides the needed capability (S3 supports encryption at rest; RDS can use encryption; Systems Manager Patch Manager handles patching). When it doesn’t, propose viable alternatives (third‑party products, operational processes, or other AWS features) and explain trade-offs in cost, operational overhead, and security effectiveness. Match requests to security domains and features
  • Request: “Encrypt the bucket contents.”
    Domain: Data protection. Feature: S3 default encryption or SSE‑KMS.
  • Request: “Increase logging on S3.”
    Domain: Detection. Feature: S3 Server Access Logging, CloudTrail Data Events, or sending logs to CloudWatch.
You won’t memorize every feature forever — features change. For certification, know common security features and their domains; in practice, look things up and explain options and trade-offs.
A presentation slide asking "What Task Statement is the requirement?" with three dotted boxes listing security tasks (Design Secure Access to AWS Resources; Design Secure Workloads and Applications; Determine Appropriate Data Security Controls). To the right is an AWS Certified Solutions Architect – Associate exam guide table showing four domains and their exam weightings, with colored arrows linking the tasks to the domains.
When you hear a requirement, first classify it into a security domain (e.g., data protection, detection, IAM). Then list the AWS features that best address that domain and present trade-offs (cost, complexity, and time to operate).

​
Exam context: Domain one task statements

For the AWS Solutions Architect — Associate exam, Domain 1 covers “Designing secure architectures.” You should be able to:
  • Design secure access to AWS resources
  • Design secure workload and application environments
  • Determine appropriate data security controls
On the exam (and in the real world), choose the most secure option that is practical — balancing security with reliability, performance, cost, and operational overhead.

​
Practical example: “No unneeded ports”

Fictional case: Chubby Unicorn Company runs an application called Glitterbomb and wants to ensure no unneeded ports are accessible. Possible controls to meet this request:
  • Security Groups — instance-level, stateful filtering
  • Network ACLs (NACLs) — subnet-level, stateless filtering
  • AWS Network Firewall or inline appliances for advanced filtering
  • Architectural changes (private subnets, load balancers, VPC endpoints)
As we review networking services, keep mapping each service/feature to security domains: detection, data protection, IAM, infrastructure protection, application security, etc.
A presentation slide that maps security domains (like Identity Access Management, Detection, Data Protection, Infrastructure Protection, Application Security and Incident Response) to AWS networking and security features (NACLs, Security Groups, public/private subnets, NAT gateway, VPN, etc.). The right side includes simple diagrams of a public and private subnet with icons for NAT gateway and security group.

​
High-level guidance when choosing solutions

When evaluating controls, consider:
  • Security effectiveness: Does the control meet the requirement?
  • Operational overhead: How much work to deploy and maintain?
  • Cost: Is it cost-effective for the required posture?
  • Performance: Will it introduce latency or capacity constraints?
Document these trade-offs and recommend the most appropriate solution for the business context.

​
Deconstruct complexity with a campus analogy

Think of an AWS account/region as a corporate campus with buildings, floors, public lobbies, and secure office areas. This maps to VPCs, subnets, gateways, and security controls and makes reasoning about segmentation and access simpler.
A slide-style diagram showing a dotted box labeled "Chubby Unicorn Corporation" containing several stylized building icons. On the left are circular icons labeled "CR Employees" and "Public People" with an arrow pointing into the corporation box, illustrating access to an AWS-like account.

​
Questions to ask when designing network segmentation

  • How many regions or Availability Zones are required?
  • How many AWS accounts are needed for separation of duties or billing isolation?
  • Should we segment by group (HR, Finance, Production)?
  • Which parts should be publicly accessible (lobbies, cafés) vs. private (server floors, sensitive systems)?
  • How will employees authenticate and reach private areas (VPN, Direct Connect, PrivateLink)?
Segment by group, floor, or security zone to guide resource placement and control choices.
A presentation slide titled "Should we segment the buildings by group?" shows icons for "CR Employees" and "Public People" on the left. On the right a dashed box labeled "Chubby Unicorn Corporation" contains stylized office buildings with colored arrows pointing to them labeled groups like "5th HR," "3rd DC," and "2nd Fin."

​
Controlling access beyond public areas

In the campus:
  • Ground-floor areas ≈ public subnets (Internet Gateway attached).
  • Upper floors ≈ private subnets (no direct route to the Internet Gateway).
  • Security Groups ≈ instance-level door locks (stateful).
  • NACLs ≈ subnet-level gates (stateless).
  • NAT Gateways ≈ proxies for private IPv4 instances to reach the Internet.
  • Egress-only IGW ≈ outbound-only for IPv6.
  • VPN / Direct Connect ≈ private employee links into the network.
  • VPC Endpoints ≈ private backdoors directly to AWS services without traversing the public Internet.
Map these physical controls to AWS features when designing access.
A slide titled "What about Security beyond Public Access?" showing CR Employees and Public People entering two connected office buildings. The buildings are marked with multiple "Security" checkpoints on each floor and a special employee-only blue door for staff access between buildings.

​
Logging and detection

You need to know who signed in and which doors were used. In AWS:
  • VPC Flow Logs capture network traffic metadata (flow records) — think of them as key‑card logs and cameras for network traffic.
  • Use CloudTrail for API activity, AWS Config for configuration history, GuardDuty for threat detection, and Network Firewall logs for inline filtering insights.
Correlate logs across these sources to improve detection and incident response.
An infographic showing two office buildings with labeled "Security" checkpoints and arrows indicating entry paths for "CR Employees" and "Public People." A sidebar notes that cameras and key‑card readers log who signs in and which floors are accessed.

​
Internet access patterns and gateway types

If a private subnet occupant needs outbound Internet access, evaluate the appropriate gateway/proxy: Important distinctions:
  • Security Groups are stateful: return traffic for allowed inbound is automatically permitted outbound, and vice versa.
  • NACLs are stateless: you must configure both inbound and outbound rules explicitly.
  • Each subnet is associated with one route table; multiple subnets can share the same route table.
  • VPC endpoints (gateway and interface) let you reach AWS services without going over the public Internet.
A labeled AWS core networking diagram showing a Virtual Private Cloud (VPC) spanning availability zones with public and private subnets, NAT and internet gateways, network ACLs, resolvers, instances, elastic load balancers, VPC endpoints and AWS services like Route 53 and S3. Icons on the left show users connecting via the internet to the VPC through the internet gateway.

​
Putting it all together: how to deconstruct diagrams

When you see a complex architecture diagram, build it up and reason from the outside in:
  1. Identify the Internet boundary and Internet Gateway.
  2. Locate the VPC(s) and route table associations.
  3. Determine subnets (public vs. private) and any NACLs applied.
  4. Find instances and the Security Groups protecting them.
  5. Spot NAT Gateways, Egress‑only IGWs, and Internet Gateways — understand directionality (NAT ≈ outbound IPv4).
  6. Identify VPC endpoints that bypass the public Internet for AWS service access.
  7. Note load balancers (internal vs internet-facing), VPNs, and Direct Connect links.
  8. Locate logging and detection mechanisms (VPC Flow Logs, CloudTrail, GuardDuty).
By reconstructing the diagram region → VPC → AZs → subnets → routing → gateways → instances → security controls, you can reason where to “turn up” security.

​
Example security hardening strategies

  • Place application servers in private subnets behind internal or internet-facing load balancers.
  • Restrict management access: prefer Systems Manager Session Manager or bastion hosts with strict access controls rather than direct SSH from the Internet.
  • Minimize exposed ports: default-deny and allow only required ports with Security Groups and NACLs.
  • Use VPC Endpoints to access S3/DynamoDB privately.
  • Enable VPC Flow Logs and correlate with CloudTrail and GuardDuty for better detection.
  • Apply encryption: TLS for data in transit and AWS KMS for data at rest.
Avoid relying on a single control (for example, only Security Groups). Use layered controls (subnet segmentation, NACLs, endpoints, logging) and enforce least privilege across networking and IAM.

​
Final note

When a stakeholder makes a request:
  1. Classify the request into a security domain.
  2. Identify the AWS feature(s) that match that domain.
  3. Propose the most secure, practical solution considering cost and operational overhead.
  4. If diagrams look complex, decompose them layer-by-layer and reason about each control.
This approach helps you design secure networked applications on AWS and present practical, defensible recommendations during security design conversations.

​
Useful references

Watch Video