It should be noted C4 is for software architecture, specifically. Not system architecture, generally.
When diagramming (say) a cloud system architecture, you should use the abstractions that come with that cloud environment (in AWS it'd be things like Account, Region, Lambda, etc.). There is no benefit in translating these abstractions to C4's abstractions that were designed for software (Context, Container, and Component).
The C4 model also includes an optional deployment diagram (kinda like the deployment diagram from the 4+1 model). You could indeed use the abstractions of your cloud provider to draw that but I think it's more helpful to use C4 abstractions. Since this allows you to map concepts from your software (C4 containers) to your infrastructure.
Let's say to have a reasonable complex (micro)services landscape running in the cloud. I would create:
- one context diagram. System as a blackbox with surrounding actors.
- one or multiple container diagrams. One per bounded context.
- one deployment diagram mapping out the most significant cloud infra, their interrelations AND some example C4 containers to show how the software maps to the infra.
I still find myself making different diagrams for different levels of complexity. Things like "infrastructure diagram", "microservice diagram", "vendor dependency diagram", sequence diagrams. Depending on what's happening the architecture may dynamically change, and I'm not always sure how to represent that.
Making different diagrams to show different concerns is exactly what to do [0]. Trying to show everything in a single view is impossible, you'll just make a mess.
Does not look like that is the case. The syntax is different, this one I shared is based on the plant uml standard, while the one you mention seem to have its own thing. Will try it out! Tx for the link
When diagramming (say) a cloud system architecture, you should use the abstractions that come with that cloud environment (in AWS it'd be things like Account, Region, Lambda, etc.). There is no benefit in translating these abstractions to C4's abstractions that were designed for software (Context, Container, and Component).