Very little about your use of AWS is constrained by Substrate. Beyond a few central assumptions, your choices are as endless as AWS makes them. This is a double-edged sword. Part of the value of Substrate is in helping Source & Binary's clients through the endless maze that must be navigated just to start using AWS in a scalable manner. But as soon as Substrate gets in their way, its benefits become costs and it falls to the same "but what if I outgrow it?" fear that has so often doomed the likes of Heroku.
So Substrate stays modest in the constraints it imposes:
That leaves weighty choices like service architecture, storage and compute technologies, multi-tenancy, traffic routing, and more entirely up to you. These can still be overwhelming choices. Some advice follows.
Because it is so notoriously difficult to close an AWS account, you should define domains based on both how you want to isolate services from one another and how you organize your engineers. A domain per engineering organizational unit is a good default. Combine two potential domains into one to increase engineering velocity a bit. Split a service or collection of services into their own domain to increase isolation.
It's easy to put all intranet tools into one basket but, if you look closely, they can typically be cleanly put into two smaller groups. Some tools are, for lack of a better word, devops tools; they're concerned with cluster management, deployment, and the like. Other tools are part of your product; they understand and interact with your data model and your services. You should put devops tools in your admin accounts and you should put product tools in the appropriate domain accounts.
If you like, you can expose them all via your intranet DNS domain name, though you'll want to namespace product tool URLs with an environment e.g. https://example.com/production/user/123.
The particular storage technology you choose makes absolutely no difference but you should absolutely count on hosting many instances of your chosen storage technologies, with at least one in every domain account in every environment. Service-oriented architecture is (partially) about encapsulation, after all, and the services in a domain should absolutely be encapsulating their data.
As with storage technologies, your choice of compute technology is your own except that if you choose to use container orchestration frameworks like ECS or Kubernetes you should operate e.g. one cluster per AWS account. This ensures that the failure domain in case of cluster failure is the same as in case of application failure. ECS and Kubernetes users may be (rationally, justifiably) tempted to define slightly larger domains than they otherwise would in order to take advantage of some economies of scale by having larger clusters where more bin-packing efficiency can be had.
Most SaaS products embrace multi-tenancy as a necessary design point to enable freemium pricing. If you're not subject to such constraints, you could consider something as extreme as creating an environment for every customer. Slightly less extreme would be to create many qualities and host a subset of your customers in each one, further reducing the blast radius of changes by accounting for changes initiated by customers.
It seems like Substrate should express an opinion on how DNS domains and load balancers are organized. The truth, though, is that these decisions are more tightly tied to how traffic enters your network than how that network is laid out.