Design Secure Architectures · Lesson 2

Private networking and application protection

7 min read

Lesson objectives

Analyze Private networking and application protection and justify decision limits.

Skill

SAA-C03 task 1.2 requires more than saying “put the database in a private subnet.” A solutions architect traces every request: where clients enter, where TLS terminates, which tier receives the request, which ports connect the tiers, and how a private tier reaches AWS services without an unnecessary general internet path. The deliverable is a traffic diagram and a reason for each port and route, not a list of service names. The case below uses a three-tier web application; an internal-only or serverless workload may need a different decision.

Read network boundaries first

A public subnet has a route to an internet gateway. The label is not conferred merely by an instance having a public address. A private subnet has no direct internet-gateway route, but its resources are not automatically isolated from every other network: they may receive traffic from an authorized security group or use a VPC endpoint or a deliberately designed NAT path. Inspect the routes rather than trusting the subnet label.

Security groups control traffic for their associated resources and are stateful: replies to allowed traffic need no separate reverse rule. Network ACLs act at subnet level and are stateless, so a request and its reply need matching rules. A broad NACL does not replace a narrow security group, and a correct security group cannot repair a missing route. When connectivity fails, examine DNS, routing, security groups, NACLs and the destination service in sequence. Evidence at each layer avoids opening every boundary at once.

Do not bake database credentials into an image or expose them through uncontrolled configuration. Use a managed secret with narrowly scoped read access for the runtime identity, and consider secret rotation and how connection pools refresh credentials. Choosing Secrets Manager does not itself authorize the application; the identity must retrieve the secret and may need key access when a customer managed key is involved. Keep deployment and runtime identities separate. For a public API, consider AWS WAF rules on a supported resource such as an ALB or CloudFront based on the HTTP threat; WAF does not replace application authentication or narrow network ports. Neither WAF nor Shield is a promise to remove every attack or application defect.

Worked case: booking gateway

First mark trust boundaries: internet client to ALB on 443; ALB to container service on the chosen application port; container service to database on the engine port; and container service to AWS dependencies through appropriate egress paths. Move containers and database to private subnets across two zones. ALB subnets remain public to accept clients, while the database needs neither an internet-gateway route nor a public address. ALB security group inbound permits clients on 443. Container security group inbound permits the ALB security group only on the application port. Database security group inbound permits only the container security group on the database port. Do not expose the database to the internet or every resource in the VPC.

Second, choose egress deliberately. For private containers reading S3, associate each relevant private route table with an S3 gateway endpoint in the appropriate Region, then inspect endpoint and bucket policies alongside IAM. A network path does not grant object permission. Gateway endpoints for S3 and DynamoDB avoid NAT or an internet gateway for that traffic, but they are not generic endpoints for every service. For private images or Secrets Manager, verify supported interface endpoints, DNS and port requirements, or design NAT for required egress, accounting for availability and cost later. Do not conflate an S3 gateway endpoint with an interface endpoint: the latter uses private IP addresses and has different access and cost behavior. Do not assume a regional endpoint route covers traffic to another Region.

Third, test intended failure as well as success. An external client should reach `GET /health` through the ALB, but a direct connection to the database port should fail. A container in a private subnet should read an authorized S3 object over the designed path after IAM and endpoint policies are checked; an unauthorized object should fail. Observe which route is actually selected rather than treating successful DNS resolution as policy proof. If a private image pull fails, examine ECR endpoint and related S3 requirements before opening broad internet egress. The design decision is one public entry point and only justified internal and external paths. Its limit is that a public ALB still receives web requests; the risk assessment may require authentication, monitoring and application protection.

A network diagram is not complete when the database box is merely labeled private. For each hop, identify initiator, protocol, port, route table, and target security group. Client-to-ALB, ALB-to-app, and app-to-database are separate flows. An S3 gateway endpoint changes the private route, but IAM, bucket, and endpoint policies still govern access. Test return traffic and inventory other outbound services before removing NAT. For HTTP attacks, place WAF on a suitable HTTP entry point while retaining application validation and authorization. Widening a database network rule cannot repair an injection flaw even if network connectivity improves.

Exercise with an observable product

Exercise

Consider another design: an internet-facing ALB in a public subnet has a 443 listener and SG rule, containers are in two private subnets, and the database is private. Local route tables permit VPC traffic, and the case supplies no NACL block for a request or reply. The container SG allows inbound from the ALB SG on 8080, but the database SG allows 5432 from all of `10.0.0.0/16`. Containers must read S3; they have no NAT, and the S3 gateway endpoint is associated with only one private route table. Produce five traffic rows: client→ALB, ALB→container, container→database, and container→S3 from each private subnet separately. State success or failure, the smallest change, and a test for each row. Allow 18 minutes: four to draw sources and targets, six for route and SG decisions, five for both S3 paths, and three to test intended denials.

Check your answer

Solution: the client reaches ALB on 443 if its listener, route and security group are configured as the diagram states. ALB reaches containers on 8080 because the container SG names the ALB SG. Any resource in the VPC CIDR can currently reach the database port under that SG rule, an unnecessarily broad exposure even if the application works; change the source to the container SG, then test an application container and an unrelated instance. Containers whose private route table is associated with the S3 gateway endpoint have a network path to S3, subject to IAM and endpoint policy. The second private subnet lacks that path and NAT, so success cannot be assumed. Associate its route table with the appropriate gateway endpoint; test an allowed and denied object and inspect the selected route. Do not fix the second network's problem by exposing the database or enabling blanket internet egress. If the ALB has no 443 listener or a NACL blocks responses, the first or second row changes; these are bounds on the exercise assumptions, not reasons to ignore them.

Path	Result from the inputs	Action and test
Client→ALB:443	Reaches ALB	Test HTTPS and public route; do not expose database port
ALB→container:8080	Reaches target	Test ALB target health and application reply
Container→database:5432	Works but source rule is broad	Restrict source to container SG and test denial from unrelated instance
First private subnet→S3	Endpoint path exists; authorization still needs checking	Test IAM, endpoint policy and an allowed object
Second private subnet→S3	No endpoint or NAT path	Associate route table, then test permitted and denied objects

Professional distinction

For an exam choice, distinguish “private” as a routing property, “allowed” as a policy decision, and “secure” as a set of controls. An endpoint supplies a path; IAM and resource policies decide access. A security group controls network traffic; application and data permissions govern what happens after a connection. A strong answer fixes the first proven exposure or failure without adding static credentials or broad egress that the requirement never asked for.

Lesson summary

The table checks 443 and 8080, narrows 5432, and restores S3 reachability for each subnet. For a non-S3 destination, the gateway endpoint alone is insufficient; revisit interface endpoints or NAT.

Report an error in this lesson