my personal take is you should only be striving for re-usability where it makes sense and you should limit the amount of abstraction you use over the base resources provided by your chosen cloud. Making things too generic and/or re-usable takes more time and will often require more code and more testing to ensure it works in the large number of possible use cases. If you're only using a component in one or two places, just make it work for those cases and move on. If things change in future you can always refactor. I also try and limit how much abstraction i use. For example I refrain from making custom resources where possible and when I do make custom resources I try to make them composed of base resources only (like the base

pulumi.aws

resources rather than composing things with

pulumi.awsx

resources and/or other custom resources). The main reason being is because it then increases the learning curve for other developers to understand what that custom resource does and how it works. Most developers (as opposed to SREs or operations engineers) working on infrastructure code will only have a basic understanding of the cloud provider they're using so putting too much abstraction on top of the base resources they may know about makes it harder for them to learn and contribute. if you don't work in a team then the second point is probably less important but I'd still recommend the first. This is just my personal opinion though and it seems to work for me.