Plan, deploy, validate, monitor, and approve a production-shaped web application on Amazon ECS with AWS Fargate.
Intermediate · 75–100 min
i
This is an interactive console simulation.
No AWS account, credentials, internet calls, cloud resources, or charges are used. Product names teach the workflow; no vendor logo is used.
Scenario
Deploy the RCW Orders service
A business-critical containerized web API must be reachable through HTTPS while its tasks remain private. Security, platform, and operations teams require traceable controls before a limited release.
✓ Scan and pin an immutable container image
✓ Separate build, execution, and runtime permissions
✓ Run two non-root Fargate tasks across Availability Zones
✓ Terminate TLS at an Application Load Balancer
✓ Prove health, rollback, scaling, logging, and cleanup
○Human approvalEvidence and release decisionPending
Start with the workload boundary before creating resources.
Amazon ECS/Amazon ECR
Objective 2 · 15 points
Create a protected image repository
Make the deployable artifact identifiable, immutable, encrypted, scanned, and lifecycle managed.
Required
!
Do not deploy :latest.
Use an immutable version tag and record the image digest. Promotion must fail when unresolved critical or high findings exceed policy.
Private repository
Repository configuration
ECR
Scan result
Image sha256:9a51…d824
Critical0
High0
Medium2
Packages86
Production rule
Re-scan continuously because new vulnerabilities can affect an unchanged digest. EventBridge should route actionable Inspector findings to the security team and deployment gate.
Image approval is required before IAM configuration.
Amazon ECS/IAM and Secrets Manager
Objective 3 · 10 points
Separate control-plane and application permissions
Give the ECS agent only startup permissions and the application only its explicit runtime permissions.
Required
Build role
rcw-orders-build-role
Pushes only to the approved ECR repository from the trusted delivery pipeline.
✓ ECR upload actions on one repository
✓ No ECS runtime permission
✓ Short-lived federation
Execution role
rcw-ecs-execution-role
Used by the ECS/Fargate agent before the application starts.
✓ Pull approved ECR image
✓ Write one CloudWatch log group
✓ Read one secret version and decrypt
Task role
rcw-orders-task-role
Used by application code after the task starts.
✓ Read orders-config only
✓ No ECR push or IAM actions
✓ No static access keys
The execution role is not the application task role.
Amazon ECS/Clusters/Create
Objective 4 · 10 points
Create the Fargate cluster
Use serverless capacity with enhanced telemetry, managed encryption, cost allocation, and controlled debugging.
Required
Compute decision
Why Fargate?
Fargate removes container-instance administration, but the customer still owns images, IAM, task definitions, networking, application security, data protection, monitoring, and configuration.
i
Shared responsibility remains.
Serverless does not mean control-free. Patch base images and redeploy; do not attempt to patch a running container.
Define a reproducible Fargate workload with an immutable image, bounded resources, health checks, secret references, and protected logging.
Required
Familyrcw-orders-web:1
CompatibilityFARGATE
Networkawsvpc
ImageDigest pinned
SecretsReference only
Task definitions are immutable revisions; deploy a new revision for changes.
Amazon ECS/VPC and Elastic Load Balancing
Objective 6 · 15 points
Build the private service boundary
Expose only the HTTPS load balancer. Keep Fargate tasks private and permit traffic by security-group identity.
Required
Security group path
Identity-based rules
Clientapproved CIDR
443/TLS →
ALB SGpublic subnets
8080 →
Task SGprivate subnets
No direct task ingress
The task rule references the ALB security group rather than accepting an internet CIDR. Network ACLs provide subnet-level defense but do not replace security groups.
Endpoint availability, cost, DNS, policies, and Region support require review.
Amazon ECS/Clusters/rcw-prod-ecs/Create service
Objective 7 · 10 points
Deploy the highly available service
Maintain two healthy tasks, automate safe rolling replacement, propagate ownership, and bound scale.
Required
DeploymentCOMPLETED
Desired / running0 / 0
Healthy targets0
AZ distributionPending
Public task IPDisabled
Do not approve release until health and rollback tests pass.
Amazon ECS/Monitoring and validation
Objective 8 · 10 points
Prove health, detection, rollback, and scale
Operational readiness needs observable evidence—not a screenshot of two running tasks.
Required
Validation suite
Seven release checks
Not run
○
Image digest and scanImmutable digest; no critical/high policy breach
○
TLS and ingressHTTPS succeeds; direct task access denied
○
Application health/healthz returns 200 through the ALB
○
Multi-AZ service2 desired, 2 running, 2 healthy in separate AZs
○
Protected telemetryApplication, flow, metric, and API audit events arrive
○
Failed-deployment rollbackBad revision is rejected and revision 1 restored
○
Autoscaling and recoveryScale-out to 4, then controlled scale-in to 2
RecoverImmutable revision · redeployment · rollback test · multi-AZ service · runbook
This lab is control-aligned educational guidance. It does not certify compliance with NIST, ISO, CIS, PCI DSS, or any legal/regulatory requirement. Applicability and evidence sufficiency require qualified organizational review.
Human approval
Release record
Required production runbook
Cleanup order
Stop traffic and preserve required evidence.
Disable autoscaling, set service desired count to zero, and delete the service.
Delete listeners, load balancer, target group, and related DNS records.
Deregister task revisions; remove approved images only after retention and rollback review.
Delete log groups, secrets, alarms, dashboards, endpoint resources, and KMS keys only under their retention/deletion procedures.
Delete cluster, security groups, endpoints, subnets, routes, and VPC in dependency order.
Remove IAM roles/policies and verify no orphaned resources, data, snapshots, ENIs, addresses, or charges remain.