Split aws cookbook apart

[jakauppila]

:frowning: Problem Statement

The aws cookbook currently supports many AWS resources and that number could grow, but think most people would agree that Chef is not always the most appropriate tool for the job in that regard.

I find that having a single cookbook to manage them all leads to a bit of churn in terms of versions as resources are added or modified and can be a bit bothersome to manage your own dependencies to check whether any of the versions impact the resources you utilize.

:grey_question: Possible Solution

I propose that we split up the aws cookbook.

I don't think we necessarily want an explosion of cookbooks to maintain, but I think separating out those that carry the most value/use would be beneficial.

So with that, I'd propose the following:

aws

• aws_autoscaling
• aws_cloudformation_stack
• aws_cloudwatch
• aws_dynamodb_table
• aws_ebs_volume
• aws_elastic_ip
• aws_elastic_lb
• aws_iam_group
• aws_iam_policy
• aws_iam_role
• aws_iam_user
• aws_instance_monitoring
• aws_instance_role
• aws_instance_term_protection
• aws_kinesis_stream
• aws_resource_tag
• aws_route53_record
• aws_route53_zone
• aws_secondary_ip
• aws_security_group
• aws_ssm_parameter_store

aws_s3

• aws_s3_file
• aws_s3_bucket

:arrow_heading_up: Describe alternatives you've considered

I was originally thinking about the split in terms of where the gems diverge, but that would result in ~12+ cookbooks containing a single or handful of resources each; overkill.

I could see making a split of aws_iam as well, but personally, I don't use those today.

:heavy_plus_sign: Additional context

A few years back, we forked the aws cookbook internally to strip out all the resources we didn't use and reduced the dependent gems down to the bare minimum. I'd like to get back to utilizing a community cookbook.