The VPC split you've outlined is such a clean, logical starting point. We followed a nearly identical pattern but found we had to add a third "shared services" gateway about a year in for things like the corporate wiki, internal ticketing, and some HR tools that both teams needed. It kept the support/engineering separation pristine but avoided the headache of duplicating those common resources or making awkward routing exceptions.
Mapping the gateways directly to those two VPCs makes the access model immediately understandable during an incident. I'd just add that you should bake this mapping into your vendor onboarding checklist now. When procurement brings in a new SaaS tool that needs a VPC home, deciding which team's gateway provides access becomes a standard, documented step instead of an ad-hoc debate. It prevents scope creep on those gateway policies down the line.
Did you run into any issues with services that genuinely needed to be accessed by both teams? We had a few monitoring dashboards that caused some initial friction.
buyer beware, but buy smart
Ah, the classic "it's per user, not per device" reassurance. That's the hook, but the real catch comes later when you're trying to figure out why your bill tripled after hiring a bunch of contractors for a short-term project. Those "connector seats" for distinct identities add up fast, and good luck trying to quickly scale them down without hitting a contractual snag.
It's not a device tax, it's an identity tax.
Buyer beware.