Before joining AWS, I was using a few services in the suite, particularly to replace the hardware to host sites elsewhere. My exposure to the AWS Command Line Interface (CLI), or Boto (the AWS SDK for Python) was limited at best. I quickly recognized that while using the console (the AWS Web UI) was helpful to new users to understand the relationship between components, it was slow for operations of scale. It was this realization that led me to the power of the CLI, and eventually, to CloudFormation.

For someone who prefers the command line (and manipulation of interfaces via the keyboard versus a mouse), this was fantastic! I could manipulate infrastructure through the CLI minimizing the context switch required when moving hand position from keyboard to mouse, and back. This post describes how I solved the inefficiency of using the AWS Console to check the status of my CodeBuild project build with SQS.

As always, when I start on a project, I itemize my requirements, and then execute each step to reach my end result. In this case, my list included the following:

Requirements

  1. Create an SQS queue
  2. Ensure that the build project is the only entity that can write to it
  3. Define when the message will be sent
  4. Define the message that will be sent
  5. Define how the message will be received

Creating the SQS queue was straight forward, and I put together a CloudFormation template (CFT) to instantiate it into my target account. The habit of writing CFTs is incredibly powerful as it helps standardize resources across your accounts. In this case, the customizations for the CodeBuild specific SQS queue were the following:

DelaySeconds: 0
MaximumMessageSize: 1024
MessageRetentionPeriod: 86400
QueueName: !Ref QueueName
ReceiveMessageWaitTimeSeconds: 5
VisibilityTimeout: 60
DelaySeconds
Delay before the message is added to the queue
Since I prefer to have the message immediately, no delay.
MaximumMessageSize
1KiB is the minimum
(Famous last words) I won’t need a message size larger than 1KiB
MessageRetentionPeriod
86400 seconds
If I don’t pick up the message from the queue in under a day, then I don’t need to persist
ReceiveMessageWaitTimeSeconds
5 seconds
This is all about long polling, to ensure cost effectiveness once attempting to read messages from the queue
VisibilityTimeout
60 seconds
Once I pick a message from the queue, I don’t want to see it again for another minute. I’m considering increasing this to longer due to it still being annoying in live testing

With the queue created, it was time to ensure least privilege. This took a bit longer than I expected because I initially went down the path of an SQS Access Policy (clearly because I was low on coffee, chocolate, or both). Initially, I was thinking of the queue as if it were a resource that was completely exposed. I eventually discovered by reading through the SQS documentation that Queue Ownership dictates the rights to the queue. In my case, since I created the queue with an assumed role, the owner of the queue is the AWS account that it was created in. At this point, I was comfortable with the exposure, and now needed to give CodeBuild the permission to send the message to the queue.

Effect: Allow
Action: sqs:SendMessage
Resource: !Ref SQSQueueArn

All I needed was a three line ammendment to the CFT that I used to create the CodeBuild project. With the resources updated, steps one and two were completed!

In the next post for this series, I’ll walk through my thought process for the message template, and what changes were required in the buildpsec for the project.