- This topic has 2 replies, 3 voices, and was last updated 3 weeks, 1 day ago by
.
-
Post
-
I work on a small development team, and our application has grown from a single server into several services running on AWS. We’ve now got separate development and production environments, a couple of databases, storage buckets, and different networking settings. The problem is that nobody on the team has a complete picture of how everything fits together anymore. When something breaks, we end up jumping between AWS console pages and asking whoever configured a particular resource to explain how it’s connected to the rest. We tried maintaining architecture diagrams, but they become outdated whenever someone changes the infrastructure. How are other teams keeping track of their cloud resources and dependencies? Is there a way to see the whole setup visually without constantly updating diagrams by hand?
-
Replies
-
-
A lot of this gets easier when everyone follows the same rules for naming resources and tags. Give each resource an owner, environment, service, and purpose, then keep the infrastructure definitions in Terraform or CloudFormation so changes don’t disappear into somebody’s AWS console history. That gives the team something consistent to work from and makes it much easier to trace a resource back to the service it belongs to.
-
The diagram issue is probably what I’d solve next, because nobody wants another document that needs attention every time AWS changes. After a while people stop checking it, and then you’re back to piecing the infrastructure together from memory. At that point I’d stop treating the map as a separate document and move it into a visual cloud infrastructure workspace like this https://gateways.app/ . The resources and their connections stay together, so the picture changes along with the work you’re doing. That also gives the team something far more useful to open when a service starts acting up.
-
