My team has been creating the /PKG directory within our repo structure and committing component resource files to be shared between projects within that repo. An example would be an AWS S3 bucket with lifecycle policies and security settings predefined as separate profiles for an s3 bucket. Then an example parameter for the component would be which profile name to use for applying the settings. Say we want to share this to multiple other git repositories that involve other teams. I'm interested in hearing what organization/sharing/versioning strategies you all have. My understanding is that before sharing component resources, I would combine them all together into a package, and then publish the package as a whole to a registry. Maybe I'd have a "{MyCompanyName}-components" package that is versioned within every project and downloaded at run time of that project.

If you have an internal package registry, distributing a component library as you described is a good strategy. Alternatively, you can also have them access the Git repository directly, either as a Git submodule or by using the Git repo as the package source. The latter is straightforward with npm or pip (I'm sure other package managers have a similar feature) and has the advantage over Git submodules that it behaves like a "regular" dependency when it comes to versioning. Depending on your infrastructure and org requirements, it can also make sense to keep all infrastructure projects and internal components in a monorepo that's used by all teams.