At (former employer) were did a good a pretty good job at solving this. We were deployed to AWS, using EKS, SQS, Aurora, S3 and a small amount of lambda. When a

At (former employer) were did a good a pretty good job at solving this. We were deployed to AWS, using EKS, SQS, Aurora, S3 and a small amount of lambda. When a new developer got onboarded, they were given their own slice of the dev environment: ingress, EKS namespace, S3 buckets, database and SQS queues. But it was still running within the same VPC and k8s cluster, with the same IAM (all those roles and policies that matched production and we're an important piece of testing). There was little additional infrastructure complexity, and no extra cost since the partitioning of usage-priced services and EKS namespaces is free. Developers also had access to shared infrastructure and the latest changes made by their colleagues. But everyone also had their own local microk8s + minio + mysql, so as long as they were happy to deploy the latest full testing release of everybody else's stuff, they could use that. When using their local cluster, they still had access to some cloud stuff like SQS and S3 (but not Aurora, they had to reply on a k8s deployed mysql). We saw the cloud environment as an essential tool to provide the developers with, but not a tool that it was essential for developers to use. In fact, we had a preference for keeping dev working, so initial work on large changes should be done locally and deployed to dev once they're working. Dev was there to protect the testing environment and make sure that developers had a "real" cloud environment. In other words, you don't have to deploy to dev, but if you break the testing environment because you didn't deploy to dev, there would be raised eyebrows.