How do you draw a data-flow diagram for a serverless architecture with no host to put on it?

## Why the diagram feels impossible at first A data-flow diagram (DFD) has four element types: **external entities** (actors outside your control that talk to the system), **processes** (code that transforms data), **data stores** (where data rests), and **data flows** (the arrows between them). **Trust boundaries** are drawn across flows wherever the level of trust changes, and they are the reason a DFD is worth drawing at all: a threat is most often something crossing a boundary in a way you did not intend. On a classic deployment the boundaries almost draw themselves, because they line up with things you can point at: the internet edge, the DMZ, the application subnet, the database subnet, the machine you administer versus the machine you do not. A serverless workload takes all of that away. The compute exists for the duration of one invocation, you never log into it, there is no long-lived process to attach to, and often no network diagram to trace at all. Many engineers conclude the system has no boundaries. It has the same number as before. They are drawn along **identity** rather than along wiring. ## Map the four elements onto managed services ``` Element Typical serverless representative ----------------- ------------------------------------------------------------- External entity a browser or mobile client, a partner system, an uploader holding a presigned URL, a scheduler, another team's account Process a function, a managed transform or workflow step, a container task - anything that runs under exactly one execution role Data store an object bucket or prefix, a table, a queue or topic, a parameter or secret store, and the function's own configuration Data flow an invocation, a read or write, an event delivery, and a role assumption ``` Two of those entries surprise people. A **queue is a data store, not an arrow**: something writes to it, something else reads from it later, and it has its own access policy that decides who may do each. And **configuration is a data store**: environment variables, parameter entries and the role attached to a function are data at rest, with their own reader and writer sets, and they are frequently where a secret actually lives. ## Identity is the perimeter On a managed-services diagram, the useful boundary is the set of things one principal can reach. Concretely: - Two functions with **different execution roles** are separated by a trust boundary, even though they sit in the same account, the same repository and the same deployment. - Two functions with the **same execution role** are not separated by anything. Compromise one and you have the other's access. Draw them as one element for threat-enumeration purposes even if you keep two boxes for readability. - **Role assumption is a boundary crossing.** Wherever code assumes another role, that arrow changes what the code can reach. Draw it, and label who may assume it, under what condition, and what the assumed role reaches. This is why the network picture is the wrong picture. A function inside a private network segment that holds a role with read access to a customer data store reaches that data regardless of the segment; a subnet drawn as the only boundary hides exactly the reachability that matters here. ## Annotate the flows, not just the boxes For each arrow write down how the call is authenticated and what authorises it: a signed request from a named role, a queue resource policy naming one producer, a presigned URL with a short expiry, a public endpoint with no authentication at all. Unlabelled arrows are where teams silently assume that an internal-looking hop is trusted. There is also a second plane of flows worth marking even if you do not model it in depth here: the **control plane**. Someone can change a function's code, its environment variables or its role without touching the data path at all, and the set of principals who can do that is usually different from the set who can call it. Mark that crossing on the diagram; modelling the build and deploy path as a system in its own right is a separate exercise. ## A worked sketch A media-transcoding workload, drawn the way this section argues: ``` (External uploader, holds a presigned URL) | PUT object v [ uploads/ prefix ] --object-created event--> ( Transcoder, role: transcoder ) | write v [ output/ prefix ] Boundaries: anonymous internet | transcoder role | readers of output/ ``` There is no host anywhere on that picture and it is still a complete model. It tells you the uploader is anonymous and bounded only by the presigned URL's scope and expiry; that the object-created event is an entry point carrying attacker-chosen bytes; that everything the transcoder role can reach is inside one blast radius; and that the interesting question about `output/` is who else can read it. ## Common failure modes - Drawing infrastructure - regions, network segments, service icons - instead of data flows, and ending up with a deployment diagram that supports no threat enumeration. - Collapsing every function into one box called *the app*, which erases exactly the role differences that are the boundaries. - Leaving configuration and secrets off the diagram, so nobody asks who can read them. - Treating a managed store as somebody else's problem rather than a data store with a reader set you chose.