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.
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).