Legacy application modernization on AWS with controlled releases.

Five layers, one governed path.

Traffic enters through one front door, runs on private compute, and is released and watched by layers the client operates. The detailed graph is below if you want to trace individual components.

One path in, the same for every request. Nothing behind the load balancer has a public address of its own.

Two things sit alongside every request rather than inside it: one promotion chain that puts new versions into that runtime, and a control plane the client operates to watch it and decide who may change it.

• A request: One public address: Route 53 answers for the platform; there is no second way in. → Filtered at the edge: CloudFront and WAF apply the rules for public traffic in one place. → Encryption terminated: Managed certificates end TLS before anything reaches the network behind it. → Load balanced inward: The only hop permitted to reach the private runtime. → Served privately: ECS services on Fargate read and write managed data over private endpoints.
• Public edge: One governed way in. Route 53, WAF, CloudFront, Certificates, Load balancing
• Private runtime: Services run where the internet cannot reach them. ECS services, Fargate tasks, Private subnets
• Data: Stores stay inside the private boundary. Managed data services, Private endpoints
• Delivery: One path from a code change to a running service, with the same steps every time. GitHub, ECR, CodeDeploy, ECS deployment
• Control plane: What the platform reports, and who may change it. CloudWatch, Security Hub, Inspector, IAM, KMS, Secrets Manager, Systems Manager
• How does a request reach the application? Public traffic arrived through scattered point solutions, so there was no single place to route, filter, terminate, or balance it. Every public request now passes one path: Route 53 to CloudFront and WAF, TLS terminated with managed certificates, then load balancing into the private runtime. There is one place to change the rules for public traffic, and the runtime behind it has no public address of its own.
• How does a release ship, and how is it undone? Releases were too risky to promote confidently, so backend change turned into a full-platform event. GitHub, ECR, CodeDeploy and ECS form one promotion chain with blue-green as the default, so a new version runs beside the old one before traffic moves. Recovery is a traffic shift rather than a redeploy, and one service can change without the rest of the platform moving with it.
• Who can reach what, and who finds out when something breaks? Runtime visibility was fragmented, so operating problems surfaced late and ownership was unclear. Access is scoped through IAM, KMS and Secrets Manager, while CloudWatch, Security Hub, Inspector and Systems Manager report into the channels the team already works in. The same layer answers "who may change this" and "what is it doing", and both route to a named owner rather than a shared inbox.

Why the business changed now.

The program was framed as incremental modernization. Business capabilities could be carved out over time, reducing cutover risk and allowing investment to show value earlier.

• Release pressure: Ship backend change without full-platform cutovers. The platform needed safer release mechanics. Blue-green promotion and bounded services made backend change possible without turning every deployment into a broad platform event.
• Ingress control: Harden the public entry path. Public traffic had to be routed, filtered, terminated, and balanced through one clear control layer instead of scattered point solutions.
• Operating visibility: Make runtime activity operationally accountable. Telemetry, alerting, and security signals had to become an operating surface. CloudWatch, Security Hub, Inspector, Systems Manager, Slack, and Teams were positioned to surface issues early and keep ownership clear.
• Protect internet-facing traffic through one governed entry path.
• Promote releases through blue-green workflows instead of in-place cutovers.
• Keep runtime and data services private behind bounded network controls.
• Push operational and security signals into response channels before incidents widen.

Protected ingress, private runtime, and governed control layers.

The target state was designed around three visible requirements in the diagram: an explicit public front door, a private application and data boundary, and a control layer for release, security, and operations. The architecture earns its complexity by making those relationships legible.

• Protected ingress: Route 53, WAF, CloudFront, certificates, and load balancing create one governed public entry path.
• Blue-green releases: GitHub, ECR, CodeDeploy, ECS, and Fargate form a controlled promotion chain.
• Managed control plane: CloudWatch, Security Hub, Inspector, IAM, KMS, Secrets Manager, and Systems Manager keep the platform governable.
• Scale: Scale was concentrated where demand actually appears: the public edge, the service tier, and the Fargate runtime. Route 53 and CloudFront shape traffic before requests reach the application tier. Load balancing and ECS keep ingress scale separate from runtime scale. Fargate, RDS, and ElastiCache support growth without exposing data services directly.
• Observability: Observability was designed in as an operating surface, not added after the fact. CloudWatch provides the main telemetry and alarm layer. Teams and Slack receive signals quickly enough to support response loops. Systems Manager supports action once issues are identified.
• Security: Security was layered across ingress, identity, secrets, encryption, and runtime scanning so the environment stayed governable as delivery speed increased. WAF, certificates, and private boundaries narrow the exposed surface area. IAM, Secrets Manager, and KMS keep identity and protected material under explicit control. Security Hub and Inspector turn review into a continuous operating function.
• Delivery control: The architecture was wired for controlled software movement across source, artifacts, deployment promotion, and infrastructure change. GitHub workflows feed versioned artifacts into ECR and downstream services. CodeDeploy manages blue-green promotion instead of ad hoc cutovers. Terraform keeps infrastructure changes reviewable and repeatable.

Built to be operated, audited, and evolved continuously.

The delivery model is part of the architecture, not something wrapped around it later. GitHub, ECR, CodeDeploy, ECS, Terraform, and the surrounding control services create one repeatable promotion path where change, rollback, telemetry, and governance stay connected.

• Blue-green delivery as the default release path: GitHub, ECR, CodeDeploy, and ECS were structured as one promotion chain, reducing deployment risk and making rollback more defensible than in-place change.
• Managed governance around the runtime: IAM, Secrets Manager, KMS, Security Hub, Inspector, CloudWatch, and Systems Manager were positioned as explicit controls around the runtime.
• Signals move to people as well as systems: Alarms and operational signals were routed into Slack and Teams, not left inside dashboards alone.

The business case translated into an operating advantage.

The result was more than a technical migration. The client gained a platform with a protected front door, a controlled release chain, private runtime boundaries, and clearer operating signals across security and observability.

• Safer public-facing change with a clearer ingress model: Route 53, WAF, CloudFront, certificates, and load balancing now work as one explicit front door.
• Lower release risk through controlled promotion: Blue-green deployment and versioned artifacts create a more defensible release model than changing live services in place.
• Stronger operational maturity around the runtime: CloudWatch, Security Hub, Inspector, Systems Manager, Slack, and Teams turn the platform into a monitored operating system, not just a deployed workload.
• More governed scale across edge, compute, and data: Internet entry, runtime execution, and stateful data are now separated clearly enough for growth to happen without blurring risk boundaries.

Protected ingress. Safer releases. A platform built for governed scale.

The trade-off stayed explicit throughout: microservices add complexity, so the platform had to earn that complexity back through business outcomes. Here, protected ingress, controlled promotion, bounded runtime and data services, and operating signal flow made the shift commercially defensible.