Delivering an ECS Fargate Application Runtime Across Two Availability Zones

Ampity deployed a containerized application platform with health-checked Fargate tasks, private PostgreSQL storage, managed secrets, a container release path and...

[Problem] The application needed an operating environment as well as a deployment

The customer needed a web application platform that could handle changing demand, avoid depending on one location, keep credentials out of code and expose operating problems to the team. Shipping a container image alone would not satisfy those requirements. The runtime, data access, release process and monitoring had to work together.

Ampity designed and deployed a production web platform using ECS on Fargate and RDS PostgreSQL. Application tasks ran across two Availability Zones behind an Application Load Balancer. The customer remains unnamed in this public account.

This case covers the application-runtime workstream. A scheduled forecasting pipeline and a partner file-exchange platform were separate parts of the engagement. They are not drawn as runtime dependencies or used as evidence of application performance. A separate development environment on EC2 was also distinct from this Fargate platform.

[Decision] Separate managed task execution from application ownership

Fargate supplied the container execution environment. ECS services and task definitions described how the application ran, while service auto scaling adjusted task capacity as traffic changed. This reduced the need for the team to operate the underlying EC2 instances for those tasks.

The application still needed its own container configuration, release management, database access and operating checks. The delivered architecture did not remove responsibility for the software inside the image or establish that scaling compute would automatically scale every dependency.

The source records a multi-stage container build, security scanning, ECR image storage and lifecycle policies. Those were part of the release foundation. A scanned image should not be described as vulnerability-free, and an image published to a registry is not evidence that a healthy application release reached users.

[Design] Keep traffic-facing tasks separate from private database storage

The Application Load Balancer performed health checks and SSL termination. Healthy ECS tasks served the application, with tasks distributed across two Availability Zones. RDS PostgreSQL sat in private subnet space rather than being directly reachable from the internet. Database credentials were held in Secrets Manager.

This reconstruction shows the documented responsibilities and the distribution of application tasks. It does not specify an unrecorded database replica arrangement, promise a failover duration or imply that every supporting AWS service runs inside the VPC.

The source also lists Route 53 for internal service discovery, S3 for application files and data, and SES for transactional and system email. The figure omits detailed paths for those supporting services because the summary does not establish each application integration.

[Release] Follow the image through to a healthy target

The recorded release path began with the container build and image storage in ECR. An ECS task definition was then deployed to Fargate services, and the load balancer routed traffic to healthy tasks. This connected the release artifact to the runtime the customer actually used.

Database and networking were established in testable phases before traffic-facing components depended on them. Monitoring was in place before handover. CloudWatch dashboards, Container Insights and automated alerts supplied the operating view described in the source.

The summary does not include every deployment gate, an exact rollback procedure or a history of release failures. Those should remain implementation details to inspect, rather than assumptions added to a marketing account. For a future engagement, a useful acceptance record links the intended image, task definition, healthy target state and application-level test.

[Operations] Health and availability need separate evidence

Application tasks running across two zones reduced dependence on one Availability Zone. Load-balancer health checks allowed requests to be directed to healthy targets. Neither fact by itself establishes a measured availability percentage for the whole application.

AWS describes ECS service load balancing and health-check behavior. That documentation explains the service mechanism. Customer-specific availability also depends on application behavior, database access, capacity, dependencies and the checks used to define success.

This account stays with the documented platform and validation scope. A measured latency, cost or uptime comparison would also require its baseline, observation period and definition of a successful request. The current customer summary does not supply those measurement records.

[Result] A runtime with a defined release path and operating view

Ampity delivered a Fargate application platform, private PostgreSQL storage, managed credentials, container-image handling, traffic routing and monitoring. The source records phased validation and operating signals before handover. It does not support describing the system as having no remaining maintenance work.

For another containerized application, establish which checks prove a release usable, who responds to an unhealthy service and what limits task growth when the database is under pressure. Separate image health, container health and the user's completed workflow in that review.

Before reusing the design, document recovery requirements, database connection limits, task-capacity bounds and rollback ownership. Use the workload's own acceptance evidence to decide whether this runtime fits. Explore Ampity's AWS consulting work.