EPIC: Ruby Legacy Cleanup

[beqqrry-aws]

Sub-Issues

• [x] #3463
• [x] Create issue list of services in need up cleanup based on the Ruby tech debt file

Each service will need the following tasks:

• [x] #3674
• [ ] Confirm code works as intended
• [ ] Add to SoS and update snippets to current standards
• [ ] Update code comments
• [ ] Fully lint code
• [ ] Delete useless or duplicate code and ensure there are no external links to it
• [ ] Create and/or fix tests as required

List of services:

• [ ] cloudtrail
• [ ] codebuild
• [ ] cloudwatch
• [ ] dynamodb
• [ ] ec2
• [ ] elasticbeanstalk
• [ ] elastictranscoder
• [ ] eventbridge
• [ ] iam
• [ ] lambda
• [ ] polly
• [ ] kms
• [ ] rds
• [ ] sqs
• [ ] ses
• [ ] sns
• [ ] s3
• [ ] secretsmanager
• [ ] workdocs

Work areas

• [x] #3573
  • [ ] workdocs (1 broken test)
  • [ ] lambda (4)
  • [ ] elastictranscoder (3)
  • [ ] cloudtrail (1)
  • [ ] s3 (1)

2. There are also twelve (12) services missing tests entirely.

   • [x] #3574

3. Looking at the code I also see a demand for uniting larger bodies of single actions with MVP scenarios for these services:

   • [ ] RDS (big)
   • [ ] EC2 (big)
   • [ ] SQS (medium)
   • [ ] CloudWatch (small)
   • [ ] Lambda (medium)

4. 'The unified roadmap' says that the next most important services to the customer for Ruby MVP's are:

   • [ ] glue
   • [ ] lambda
   • [ ] ec2 (auto-scaling)

5. There's also some clean-up's that I'd like to do in order to make the examples consistent with the rest:

   • [ ] eventbridge uses ec2 events which consumes more of customers time than necessary
   • [ ] elastictranscoder points to internal wiki for ex-AWS employee
   • [ ] codebuild could project a project file instead of making the user create one in the Console
   • [ ] SES examples require data generation, so could we create some data or mock it?
   • [ ] elasticbeanstalk needs an S3 bucket ARN provided, so can we automate bucket fetching?
   • [ ] delete old S3 and Dynamo single action examples (which are not referenced anywhere) in favor of scenarios?
   • [ ] RDS does not have a create database example, which would be helpful

   • [ ] codebuild and cloudtrail have undocumented runtime args that you have to discover in the code. awkward experience.

       Side note: I need Laren/Scott's input on this, but what's our pattern on making users provide runtime arguments? There is inconsistency in the Ruby examples and I'd like to streamline them all (2-3 days of work, low complexity).

6. Missing examples entirely (based on my rubric solely, as there are certainly more missing):

   • [ ] api gateway
   • [ ] cloudfront
   • [ ] kinesis(firehose)
   • [ ] cloudsearch
   • [ ] cloudwatch events
   • [ ] cognito
   • [ ] lightsail
   • [ ] mediaconvert
   • [ ] security hub
   • [ ] sts
   • [ ] translate

[ford-at-aws]

Research findings for Ruby clean-up

The following is the work I've identified in my research to be high priority for Ruby clean-up effort. I will organize the work units (stories) for all of these items when I get back (e.g. MVP's may be part of existing epics, bug-fixes I may group into a single story) cc: @brmur

There are roughly six (6) item categories:

1. broken snippets
2. no tests
3. MVP's (based on code)
4. MVP's (based on Unified Roadmap deltas)
5. general tidying/standardizing
6. missing services

---

Work areas

1. The following service have at least 1 broken snippet:

   • [ ] workdocs (1 broken test)
   • [ ] lambda (4)
   • [ ] elastictranscoder (3)
   • [ ] cloudtrail (1)
   • [ ] s3 (1)

2. There are also twelve (12) services missing tests entirely.

3. Looking at the code I also see a demand for uniting larger bodies of single actions with MVP scenarios for these services:

   • [ ] RDS (big)
   • [ ] EC2 (big)
   • [ ] SQS (medium)
   • [ ] CloudWatch (small)
   • [ ] Lambda (medium)

4. The unified roadmap says that the next most important services to the customer for Ruby MVP's are:

   • [ ] glue
   • [ ] lambda
   • [ ] ec2 (auto-scaling)

5. There's also some clean-up's that I'd like to do in order to make the examples consistent with the rest:

   • [ ] eventbridge uses ec2 events which consumes more of customers time than necessary
   • [ ] elastictranscoder points to internal wiki for ex-AWS employee
   • [ ] codebuild could project a project file instead of making the user create one in the Console
   • [ ] SES examples require data generation, so could we create some data or mock it?
   • [ ] elasticbeanstalk needs an S3 bucket ARN provided, so can we automate bucket fetching?
   • [ ] delete old S3 and Dynamo single action examples (which are not referenced anywhere) in favor of scenarios?
   • [ ] RDS does not have a create database example, which would be helpful

   • [ ] codebuild and cloudtrail have undocumented runtime args that you have to discover in the code. awkward experience.

       Side note: I need Laren/Scott's input on this, but what's our pattern on making users provide runtime arguments? There is inconsistency in the Ruby examples and I'd like to streamline them all (2-3 days of work, low complexity).

6. Missing examples entirely (based on my rubric solely, as there are certainly more missing):

   • [ ] api gateway
   • [ ] cloudfront
   • [ ] kinesis(firehose)
   • [ ] cloudsearch
   • [ ] cloudwatch events
   • [ ] cognito
   • [ ] lightsail
   • [ ] mediaconvert
   • [ ] security hub
   • [ ] sts
   • [ ] translate