Alex’s Blog

Random musings on life, tech, and anything else

Buy me a hot chocolate! | About Me

API Gateway And Cloudwatch

So there I was prototyping an API on AWS using API Gateway and wondering where the logs were in CloudWatch – Amazon’s Cloud Logs tool.

Unbenownst to me, and what I think is a user-hostile-terrible-default logs for API Gateway aren’t on by default.

So I google and find this wonderful blog: which, while well written, honestly shouldn’t exist.

They summarize the issue and solution here: “TL;DR: By default, API Gateway does not have the required permission to write logs to CloudWatch logs. Scroll down for the full solution.”

In an attempt to be secure AWS by default doesn’t automatically enable API Gateway to do anything with the AWS account. Makes sense… but come on, at least log stuff – turn that on.

If anything this should be solved in the UI of the console and made super obvious and be enabled by a simple click of a button…no faffing with roles and IAM needed. I’m basically saying make it easier for me to pay Amazon more money since logs in CloudWatch cost me money.

SNS (Simple Notification Service) And SQS (Simple Queue Service) And The Case Of The Missing Messages

In a classic example of companies shipping their org-charts and how well (not well) those orgs talk with one another I hit this issue just today. It seemingly makes no sense.

The scenario is simple. I want to use SNS to publish messages with some attributes that some queue (SQS) will listen on with a filter and from there trigger some Lambda functions. Simple enough stuff.

So create the SNS topic and subscribe it to an existing SQS queue. Use the helpful UI to test the flow from the SNS side with a message and then poll for messages on the SQS side.

No messages. (I literally used the console to connect the things with the assumption that the plumbing to make it all work was being done in the background otherwise what’s the point of a fancy web console?)

Enable logs for SNS.

“SNS (topic foo) is not allowed to publish to SQS (queue bar)”

me: wtf?

Okay – I could faff around with the policy in JSON or use the builder… OR I could follow my hunch and try creating the subscription from the SQS side.

From the SQS side create a sub on the SNS topic.

Test by sending a message.

Message arrives as intended.

So… Which is it? The SNS team didn’t think about this or the SQS team thought about auto-enabling permissions when subscribing to things on their end?

Again, wtf?


Go Back Home

Copyright Alex Narayan - 2023