Skip to content

AWS · DevOps · Production operations

Operating a Multi-Service Production Platform on AWS

Client and infrastructure identifiers are intentionally omitted. The environment pre-existed my involvement.

An anonymised look at deployment, service connectivity, CI/CD workflows and production troubleshooting inside an existing AWS environment.

Context

A production-responsibility case note, not a transformation story.

An anonymised media and digital-content platform served external users through a multi-service AWS production environment. This case exists to show the kind of operating context I worked within and the production responsibility handled inside it.

The architecture below describes the environment. The responsibility section describes my work within it. They are deliberately separate.

Environment I worked within

A simplified production path.

Conceptual production environment operated within; simplified and anonymised.

External users reached a frontend delivery layer and application runtime. Services communicated privately and depended on service discovery and a private data layer; separate delivery workflows supplied container and frontend releases.

Frontend delivery

  1. Users
  2. CloudFront
  3. S3 frontend / microfrontends

Application runtime

  1. Application Load Balancer
  2. ECS Fargate services
  3. Service-to-service communication
  4. AWS Cloud Map / service discovery
  5. Private Amazon DocumentDB

Container delivery

  1. Azure DevOps CI/CD
  2. Amazon ECR
  3. ECS deployment workflow

Frontend release

  1. GitHub Actions CI/CD
  2. S3
  3. CloudFront

Work I personally handled

Production work across the operational boundaries.

Deployment workflows
Worked with backend/container deployment workflows involving Azure DevOps, ECR and ECS, and later frontend workflows involving GitHub Actions, S3 and CloudFront.
Containerised services
Worked with ECS Fargate services and their deployment and runtime behaviour inside the existing environment.
Service connectivity
Investigated communication and reachability across services and dependencies rather than treating production behaviour as only an application-code concern.
Load-balancer / target health
Worked through application reachability and target-health situations across the request path.
Service discovery
Worked with AWS Cloud Map and service-discovery behaviour within the environment.
Private data connectivity
Production work also involved troubleshooting around private Amazon DocumentDB connectivity between application services and the database environment.

Diagnostic vignette

Tracing a service through the production path.

Investigated reachability and target-health behaviour for an ECS Fargate service expected to serve traffic on port 9191.

Two Node.js services in the environment were associated with ports 8090 and 9191, with service URLs supplied through environment variables. This does not establish a particular ECS port mapping or target-group configuration.

  1. ALB
  2. Target group
  3. ECS task
  4. Container
  5. Application

The work followed the request path rather than assuming the issue lived in one layer. The exact ALB reason, root cause, configuration change, fix, and observable result remain unverified and are intentionally not claimed.

Diagnostic surface

Method over an invented outcome.

The investigation surface included the following boundaries. These are areas examined, not individual causes proven by this case note.

  • ECS task and service state
  • Expected application or service port
  • Load-balancer and target behaviour
  • Health-check behaviour
  • Network and security reachability
  • Application and service logs
  • Deployment state

Observe the symptom trace the request path verify each boundary identify where runtime behaviour no longer matches assumptions scope the next change

What this demonstrates

Working inside existing production systems means reasoning across more than one layer.

This experience demonstrates context across application expectations, containerised services, delivery workflows, service connectivity, private dependencies, and production troubleshooting. It does not turn the pre-existing environment or this investigation into a claim of platform authorship or a verified outcome.

Next

Have infrastructure context worth discussing?

Discuss Your Infrastructure Book a 30-Minute DevOps Call