Aws

This blog post was inspired by a question on stackoverflow. The user experienced intermittent HTTP 500 error codes from CloudFront. They seemed confident, that their setup was correct, so I was intrigued. The user had deployed a static website to S3 and was using CloudFront in a continuous deployment configuration. That’s a setup, where you have two distributions - production and staging. In such a setup, you can test configuration changes in the staging distribution and divert a fraction of production traffic to it in order to to see how it behaves. Once you’re satisfied with your configuration changes in the staging environment, you promote them to the production distribution and serve all traffic from there. ...

Lambda@Edge allows you to run your own business logic as part of the CloudFront request flow. You can intercept all requests that arrive at CloudFront, all connections to the origin and the responses from the origin and to the client. Lambda@Edge functions come with a series of constraints that make them different from regular Lambda functions, but also a lot of commonalities. One of these is the concurrency quota, which you should check before a production deployment. ...

Interacting with Cloud services is rarely a tactile experience. You write some code, run some command or click a button on a screen and things happen. Today we’re going to change that. We’ll write a plugin for the Elgato Stream Deck to trigger an AWS Lambda function on demand with a customizable event. In case you haven’t heard of it, the Stream Deck is basically a set of buttons with tiny screens behind them that you can customize to do your bidding through plugins. Today, we’ll write a small plugin that invokes a Lambda function of our choosing, thereby allowing us to do pretty much anything in AWS. ...

Occasionally, you’ll do something that you think you’ve done dozens of times before and are then surprised it no longer works. While setting up a log delivery mechanism for Splunk, I had one of these experiences again. (Feel free to replace relearning with forgetting in the headline.) Splunk’s preferred method of ingesting log data from AWS is the SQS-based S3 input. In a nutshell, you ensure that all logs end up in an S3 bucket. That bucket is configured to send all object create events to an SNS topic (so that multiple systems can subscribe), to which an SQS queue is subscribed. Splunk subsequently consumes the object create events from the queue and ingests the corresponding objects from S3. ...

Links and References for my Talk at the AWS Community Day 2024 in Sofia As soon as the recording is available, it will appear here Contact If you want to get in touch, send me an e-mail hi [ät] mauricebrg.com. Presentation The slides are available as a PDF here. Links Blog Post: Using undocumented AWS APIs with Python Python Package that implements some undocumented APIs (Github) If you’re interested in (un)documented or non-production APIs for Security research, Datadog has an interesting article here ...