Hypothetical Project

The names have been changed to protect the innocent, but the story is true.

Note: When I get time I will refresh this design, but at least it shows more about my design style.

I created the following generic reference architecture for imaginary product teams to follow. Below are some ideas for an AWS deployment architecture. (Circa 2019)

For teams just getting started, a simplified version of the reference AWS design is needed. In most cases teams would be deploying containerized applications to ECS, with Keycloak as the Identity Provider and Aurora has the Data Tier. (Cognito could be swapped in as well.) The preferred database flavor specified would be PostgreSQL. This was due to many teams potentially working on geospatial prototypes (e.g. to visualize rail data). Most teams will use Circle CI with Cloud Formation handling continuous deployments. Artifacts are handled by JFrog Artifactory.

Monitoring could be implemented as Cloud Watch feeding an ELK stack. Later this could be augmented by Grafana visualizations.

An Elaborated Reference

As we progress into planning for the future, more options are needed. For example, drawing from my K8s experience, we moved from ECS to EKS, setup Istio as our ingress, and leveraging AWS Mesh in some cases. Moving to EKS allows for more efficiency compared to ECS.

Teams can now choose between PostgreSQL or MongoDB, and a few teams might need a time series database like Timestream or InfluxDB. (e.g. to store rail data).

Some teams would need messaging, and they could use SQS/SNS, Kinesis, or MQ.

Static content would be delivered by CloudFront and all DNS would be in Route 53.

Dev, Test, Stage, Production

As much as possible, the DevOps team would use Cloud Formation to define the infrastructure, and higher environments would be cookie cutter copies of the lower environments. This would be to ease adoption, but in later iterations Terraform could be used.