It’s a familiar scene: as you’re waking up or making your morning coffee, you hear the garbage truck roaring away outside when you suddenly realize your garbage bags are still rotting away in the garage. Do you run after the truck like a lunatic, even though it’s too late (of course I’ve never done this, but I’ve heard it’s a thing)? Or do you just let it go and let the garbage fester even longer? Either way, it’s a frustrating start to the day.

Luckily for me I live in the modern and very civilised province of Limburg of Belgium where the local government has made a website available with a downloadable calendar showing all dates the garbage truck comes along: so handy! They even provide the calendar in a number of digital formats, including iCal. I could just import this into my phone and set an alert on it, but where’s the fun in that? After some fiddling around or “reverse engineering” as they call it, I found out that the data for the calendar files was provided by an undocumented but publicly available API.

Being the sucker for coding up and fooling around with APIs that I am (and given my state of utter boredom while under full lockdown in Belgium) I decided to code up a project based on this API that would send me an SMS notification the evening before garbage collection. Because that’s my idea of fun. And that way I would be reminded to take out the trash on time and keep my garage clean.

Want to know this neat trick to save you from rubbish resentment? Read on!

So for this project I partly used the AWS SAM framework and set up a CodePipeline to deploy my code changes instantly on AWS (stay tuned for a future blogpost on this).

First let’s code up the AWS SAM template file containing the necessary resources for this project.

The resources I used are:

• Type: AWS::Events::Rule
  A Cloudwatch event rule to invoke a lambda each evening around 8.
• Type: AWS::Lambda::Permission
  To give the Cloudwatch event rule permissions to invoke the lambda.
• Type: AWS::Logs::LogGroup
  A log group for the lambda logs.
• Type: AWS::Serverless::Function
  The lambda that will run the show.
• Type: AWS::IAM::Role
  An IAM role for the lambda to have the necessary rights like accessing SNS for the SMS notification.

Next we code up the lambda that will call the API and send us an SMS.

The API provides event data for each month by just requesting the year and month in the url path like this ‘/2020-03’. So we can easily get the data for the current month and loop through its events, checking whether any are occurring the next morning. If so we receive an SMS notifying us (note that you can provide the number of your girlfriend here, but it’s not recommended as I have found out it isn’t that effective).

And that’s all folks!

I’m aware that this trick is no rocket science, and that this isn’t even a full guide to get to the same result (leave a comment if you want some more details), but I thought it would be fun to share how I resolved one of life’s little problems using AWS.

As I’m moving toward two years of professional experience using the platform, I’m still amazed at how easily you can code some services together and create a working, scalable and highly available project in a matter of minutes or hours.

Hope you liked my trashy tale – keep your garages clean and your heads in the cloud!

The post Let’s trash talk! appeared first on Cloudar.

We recently worked with a customer that had some applications that could be without usage for months. To be more cost efficient, they were looking for a solution where:

• They could turn off as much instances and services as possible
• The users could start the application with one button click if they needed to use it
• The users didn’t have AWS credentials

We came up with the following solution to satisfy these requirements, and if you’re running the same kind of applications, maybe you can also reduce costs by implementing this.

This solutions works by taking advantage of the Route53 health checks. We’ve split up our infrastructure in two parts: an always-on part that uses low cost or usage based services to provide the user with a way to start the real application; and a part that can started and stopped on demand.

We configure the on-demand part to be the primary resource in Route53 and the always-on part as a failover. This way the traffic will be routed to the real application if it’s online, and the user will get a static webpage that gives him the option to start the application if it’s not.

If we look at how this would go if the application is offline, these are the steps that would happen:

1. The user requests the DNS record for application.example.com from Route53. Because the real application is offline, Route53 will respond with the recordset of the fallback CloudFront distribution.
2. The user request a page from CloudFront. CloudFront will get this from S3 and serve it to the user. This page contains an explanation of why the application is not available and a button to start it.
3. When the user clicks the button, it uses javascript to call the API Gateway and invoke a lambda function.
4. The lambda function calls Service Catalog or CloudFormation (depending on your environment) to start the real application
5. When the application has started, the health check will pass, and Route53 will start returning the recordset for the CloudFront distribution that is linked to the application
6. When the user uses the new DNS records, it will go through the second CloudFront distribution and to the real application

Some things to keep in mind.

This only a high level overview of a possible solution. To implement this, you would also have to consider the following:

• After starting the Application, the static webpage should refresh the page, to force the browser to do a new DNS lookup.
• CloudFront will cache errors for 5 minutes by default. Decreasing this will make the failover go faster.
• The TTL of an CloudFront DNS record is 60 seconds

The post Using Route53 to support on-demand applications appeared first on Cloudar.