While a public yum repository is easy to set up with S3, going private is more difficult. The privacy must be enforced by some plugin that can retrieve files from the S3 bucket using the API with stored credentials (maybe). Storing credentials can be avoided on EC2 machines that are assigned a proper role, but this is not possible in any other scenario.
Nevertheless, the first steps are common for both public and private setups:
1. Create the proper directory structure
This is achievable with the “createrepo” binary that can be installed on both RedHat and Debian-based systems (e.g. Fedora/Centos or Ubuntu). Running this program results in a “repodata” sub-directory being created with a couple of files that store parsed rpm information.
2. Sync the local repository with the S3 bucket
Going back in time to early 2000s, one can find a lot of businesses on “web hosting” or providing services directly from bare-metal servers. After all, the “cloud” only became a thing and gained traction in the last 5 to 10 years. Many such businesses survived to present day.
What was (and in many scenarios still is) the reality of being able to provide services from a colocated or on-premises bare-metal server?
The physical server had to be purchased before anything else; there were requirements on the enclosure size that sometimes prevented consumer-grade hardware from being used;
The operating system had to be installed by hand, from installation media;
The configuration was a tedious process, with many details being fixed throughout the days after going live.
CloudFormation is the core functionality provided by Amazon Web Services in the area of expressing infrastructure as code. One can write the infrastructure design in either JSON and YAML (with similar syntax keywords); there is also a template designer that may help in putting together the infrastructure elements and their dependencies. The particular details of each resource being defined must be coded out, though.
There are no limitations on the types of resources that can be brought up, as far as I noticed – each resource type provided by Amazon can be coded and subsequently created and provisioned. One can also define an explicit order (e.g. some resource to be created before another), apart from the implicit order that can be deduced (e.g. if an EC2 instance is defined with a IAM Role, the role is always created before the instance). The revert process is also clean: deleting the CloudFormation stack does delete everything created by the stack itself; nothing gets left behind.