CCHQ ARTICLE GUIDE / HANDS-ON LABS
Practical learning, clear decisions, real-world context
An easy-to-navigate field guide with key takeaways, applied checks, FAQs, and official references. Approximately 7 minutes of reading.
A private AWS web application built with Terraform should separate the public request entry point from the application compute and data it protects.
The typical pattern is a public HTTPS load balancer forwarding approved requests to a service or instance without a public IP address. The compute tier may access private dependencies through tightly scoped security groups and appropriate VPC routing.
Terraform can define these relationships as code and make planned changes reviewable, but a working plan does not guarantee good architecture or secure access.
This article walks through a security-first lab blueprint: prerequisites, network boundaries, role design, Terraform structure, deployment review, validation, cost risks, troubleshooting, and cleanup.
It is an implementation plan for an authorized sandbox, not a claim that these resources were deployed or tested.
At a glance
The main topics you’ll work through:
- Define the smallest useful workload
- Prepare account, tooling, and budget
- Draw the network and application boundary
- Choose compute and deployment model
In this guide
ARCHITECTURE AT A GLANCE
Private web application: request path
01
Browser over HTTPS
02
Public load balancer
03
Private application tier
04
Protected data service
The private tiers still require authorization, monitoring, and appropriate network routing.
01 / KEY CONCEPT
Define the smallest useful workload
KEY TAKEAWAY
Choose a trivial application that responds on one HTTP endpoint, such as a small service that returns a version string and has a separate health path.
Avoid databases, file uploads, and user accounts for the first iteration unless they are necessary for the learning objective.
Define what private means: the application compute has no public IP, the database is not internet-reachable, and only a deliberate public entry point accepts user traffic.
The application still needs authentication and authorization if it handles sensitive operations.
Write acceptance criteria before Terraform. The public entry point should serve the intended response through TLS, the app should not be directly reachable from the internet, and the application role should have only documented permissions.
Logs should show both a successful request and an invalid request. The deployment should have a predictable cleanup path and costs that fit your lab budget.
This scope is sufficient to demonstrate real networking and identity decisions without creating an oversized reference architecture.
02 / PRACTICAL APPLICATION
Prepare account, tooling, and budget
KEY TAKEAWAY
Use an AWS account or sandbox you are authorized to modify.
Configure federation or an approved IAM role with temporary credentials and multi-factor authentication as appropriate. Install supported Terraform and AWS CLI versions, then confirm your identity with aws sts get-caller-identity.
Choose a single AWS region for the lab and verify service support there. Before provisioning, enable AWS Budgets notifications and inspect current prices for load balancing, compute, data transfer, logging, NAT gateways, and VPC endpoints.
A public application load balancer and continuously running compute can incur charges even with minimal traffic. NAT gateways and private connectivity endpoints can introduce additional recurring costs.
If the goal is strictly a near-zero-spend lab, consider a paper architecture and Terraform validation exercise before creating chargeable networking. Never assume free-tier eligibility across all components.
Keep an inventory of resource names and deletion steps, and separate this lab’s permissions and state from any real production environment.
03 / KEY CONCEPT
Draw the network and application boundary
KEY TAKEAWAY
Start with a VPC address range and two tiers: public subnets for an internet-facing entry point and private subnets for application compute.
Place each resource in the intended availability zone and attach route tables consistent with the design. Public-facing load balancers normally need appropriate subnet placement and a path to the internet. The backend compute should not have a public address.
Its security group should accept application traffic only from the load balancer’s security group on the required port.
Think about how backend compute reaches container images, software repositories, logging endpoints, and other AWS APIs. A private subnet without an outbound path may prevent tasks from starting or reporting logs.
NAT, service endpoints, and application packaging solve different aspects and can affect cost. Document exact egress requirements before creating resources.
For a production system, consider multiple availability zones and failure behavior; for a lab, explicitly state where simplifying to fewer resources reduces reliability.
Do not call the architecture private merely because a resource name contains the word private.
04 / PRACTICAL APPLICATION
Choose compute and deployment model
KEY TAKEAWAY
You can use a private EC2 instance or a managed container service for the application.
EC2 requires more host maintenance and often a secure administrative access strategy. ECS can run containers with defined task roles, execution roles, health checks, and supported compute types such as Fargate.
Choose one path for the lab rather than mixing both. Use a simple application image without embedded credentials, and use an appropriate registry or artifact delivery method.
If you use ECS, understand the separation between the task execution role and the application task role. The execution role enables image pulling and logging operations where required, while the task role controls AWS API calls made by the application.
For a trivial HTTP service that doesn’t access AWS APIs, the application role may need very few permissions.
Regardless of compute model, collect useful logs and configure health checks so a task reporting Running is not mistaken for an application actually serving responses.
05 / KEY CONCEPT
Organize Terraform for reviewability
KEY TAKEAWAY
Create a repository with a README, a Terraform configuration directory, variable declarations, output definitions, and provider version constraints.
Separate modules only when the grouping improves clarity; a simple lab doesn’t need a large module hierarchy. Use meaningful names for the VPC, subnets, security groups, entry point, compute, roles, and logging.
Keep secrets out of variables committed to the repository and do not publish state files or saved plans.
Run terraform fmt and terraform validate before planning. Use terraform plan to inspect every create, update, and destroy action.
For team-ready state, choose a protected remote backend with encryption, versioning, and locking according to current HashiCorp guidance. Avoid beginning with a shared production backend for an experimental workload.
Review the provider and module versions and keep any approved lock file under version control. A Terraform configuration is an infrastructure proposal until it has been applied and verified in the target account.
06 / PRACTICAL APPLICATION
A staged implementation sequence
KEY TAKEAWAY
Stage one creates only the VPC, subnets, routes, and security groups.
Inspect the live resources and confirm that the private tier has no unexpected public exposure. Stage two provisions the HTTPS entry point and any required certificate or DNS integrations.
Stage three deploys the small app with a least-privilege identity and logging configuration. Stage four introduces the exact connectivity the app requires. Stage five runs functional and security checks and records an architecture review.
Use separate plans or deliberate change sets to make each stage understandable. If a plan unexpectedly adds broad network exposure, new IAM grants, or destructive resource replacement, stop and investigate.
For TLS, use a supported certificate management path rather than placing private keys in Terraform variables or state without considering the implications. Do not publish a public HTTP endpoint containing sensitive data simply to simplify the tutorial.
If a temporary endpoint is needed, label it as a lab-only exception and remove it during cleanup.
07 / KEY CONCEPT
Verify reachability and authorization
KEY TAKEAWAY
From an appropriate client, test the intended public application URL and inspect its TLS certificate and response status.
Then verify that the backend compute has no public IP or directly exposed public service path. Inspect security group source references and confirm that backend traffic originates through the approved entry point.
When an unauthorized path is testable safely, attempt a harmless connection from an untrusted lab source and record the expected restriction.
Validate the application identity as well. If the service accesses S3 or another AWS resource, confirm a narrow allowed action and a denied action against an unrelated test resource.
Check application logs, load balancer target health, and relevant AWS audit events. A green health check is not proof of authentication, authorization, or data protection.
Record the actual observations, time and region of testing, and any configuration changes required. These notes distinguish a real hands-on lab from an untested architecture plan.
08 / PRACTICAL APPLICATION
Troubleshooting, cost review, and teardown
KEY TAKEAWAY
If the load balancer reports unhealthy targets, verify target group port and protocol, application listen address, health path, security group rules, and backend logs.
If containers cannot start, inspect image pull permissions, execution-role configuration, private subnet egress, and logging dependencies. For TLS errors, check DNS, certificate matching, and listener configuration.
Change one hypothesis at a time and document why it explains the symptom. Avoid opening every port or attaching administrator policies as a troubleshooting shortcut.
Review the cost drivers while the lab is active. Determine whether the load balancer, networking, compute, log retention, image storage, and any managed dependencies are still charging.
Use a reviewed terraform destroy plan when the project is complete and check for resources Terraform does not own, such as manually created certificates, DNS records, or backend storage.
Do not delete shared infrastructure or Terraform state that other workloads use. Record cleanup evidence, estimated cost categories, and lessons learned in the final README.
Before you finish: practical checklist
Turn the main lessons into a short review of your own environment:
- Choose a trivial application that responds on one HTTP endpoint, such as a small service that returns a version string and has a separate health path.
- Avoid databases, file uploads, and user accounts for the first iteration unless they are necessary for the learning objective.
- Define what private means: the application compute has no public IP, the database is not internet-reachable, and only a deliberate public entry point accepts user traffic.
- Use an AWS account or sandbox you are authorized to modify.
- Choose a single AWS region for the lab and verify service support there.
Command quick reference
Use these commands only in an appropriate, authorized environment, after checking prerequisites.
aws sts get-caller-identity
terraform fmt
terraform validate
terraform planFrequently asked questions
Does a private subnet guarantee a private application?
No. Routes, public addresses, firewall rules, ingress configuration, IAM, and application authorization determine exposure.
Is this lab free?
Not necessarily. Load balancers, Fargate or EC2, NAT, endpoints, logging, and transfer can create charges even for a small workload.
Should I use one or two availability zones?
A production architecture should follow availability objectives; a cost-limited lab may simplify infrastructure while clearly documenting the resulting resilience limitations.
Official references and next steps
AWS Well-Architected Framework · AWS ECS Fargate getting started · ECS IAM role guidance · Terraform workflow · AWS Budgets
Create the architecture drawing and Terraform plan in a disposable account before applying anything. Mark each trust boundary and cost-bearing resource, then record real observations only after deployment.
Visit Hands-On Labs and DevOps & Automation for related learning paths.
