When designing this, remember to consider deployment cycles. If the shared resources are likely to be updated with a different frequency (which is almost always the case), then you will want different projects.

automation-api can wrap external projects, so it is fine to have a project for shared resources, one for app-specific resources, and an automation-api app that wraps them both.

This is particularly handy for handling things like the initial deployment of one stack of shared resources, plus multiple stacks off app-specific resources (all using the same shared resources). And once deployed, you can use the specific projects and stacks to roll out individual updates on independent cycles.