Category Archives: Tech Blog

Alexa, Lambda & One Time Passwords – A match made in heaven

By now, you must have heard of the amazing Amazon Echo devices; echodotsmart speaker/microphone devices backed up by the Alexa voice service.

Now, the cool thing is you can build your own skills quite easily. Register as a developer and start building your custom skill so your Echo reacts to things like “what’s up for dinner?” or maybe something more useful. Your custom skill does require some programming but where to host this? Sounds event-driven… And yes, your custom skill can be implemented as a Lambda function running on AWS; reliable, scalable and only consuming resources when actually invoked.

So what shall we build? Since we are well into AWS anyway, we’ve choosen to build a skill that can interact with AWS itself:

You                      Alexa responds
Alexa, open easytocloud  <welcome tune>Welcome
List instances           You have the following instances..
Describe kinesis shards  You have a four shard Kinesis stream in Ireland

Now, we would like to be able to actually modify resources as well. This, however, would be rather unsafe. Anyone in the same room as the Alexa Echo can now stop and start our EC2 instances (i.e. ‘splunk‘) We need authentication:

You                      Alexa responds
Start splunk             You need to authenticate

Speaking the password out loud would not make sense:

Authenticate secret123

Luckily, AWS is a very secure place and it’s IAM users can be authenticated by both a password and a one time token; multi-factor authentication or MFA. We are already using the following devices for secure access to AWS:gemalto

You can validate a token from your Lambda skill by using the AWS SDK and make a call to the AWS STS service requesting a ‘session token’. Don’t worry; we are not really interested in this ‘session token’ but it is a neat trick to leverage the existing AWS MFA integration for your own use 🙂

So now we have (supposing the OTP device is displaying 123456):

You                      Alexa responds
Start splunk             You need to authenticate
Authenticate 123456      Access granted
Start splunk             I have started splunk

Done already? Not just yet… If you don’t not have an MFA device you can use a virtual MFA application on your phone instead. But AWS can offer something cooler. Remember the AWS notification service SNS; it can send messages to a variety of destinations; email, webserver, SQS and it also supports text messaging (SMS). And that’s what we are going to use. By indicating ‘text’ we request the skill to send a one-time-password to our phone. Then, we use that code to authenticate:

You                      Alexa responds
Authenticate text        I've sent the code to your phone

Almost instantly, your phone displays how to proceeed:


You follow instructions and gain access:

You                      Alexa responds
Authenticate 5143        Access granted
Start splunk             I have started splunk

In reality, there is much more around the solution then explained in the previous steps. To name a few;

  • DynamoDB to store user profiles (including phone numbers)
  • API Gateway with a second Lambda function for a re-usable implementation of the MFA-authentication service
  • Logging into CloudWatch Logs

Feel free to contact us by email for more detailed instructions.

Visualize EC2 Performance and Pricing

As a Unix expert, I used to think everything is a file. Now I know better: everything is an API (or should be). AWS took this to the max by even disclosing their prices and specifications through an API. That allows us to write code that presents the EC2 specs and prices in a whole new way.

We ingest the AWS specs and prices daily and store it in a bucket for future reference. When you direct your browser to you get a view on this data. Hitting the big green ‘graphics’ button changes the view. From the traditional ‘table’ view we have got used to over the last hundreds of years, to a more modern 3D graphics representation.


The page your browser downloads from an S3 bucket, contains the code to do the visualisation. Another example of a serverless application on the AWS platform.

You can filter the family and see the different sizes. This reveals the difference in memory and CPU capacity for the sizes large, xlarge and 2xlarge and so on. You can also see that the ‘c’ family has relatively much compute power compared to an ‘r’ instance, which is more geared towards memory (RAM) intensive workloads. This all can be visualisesd in either 2D or 3D graphs, as Alexa (!)
explains in this video.

And although the website is hosted as a static page in a S3 bucket, the content it shows is not static at all: when the Bombay region became available, the region appeared in our selec2or without any modification to the code.

Thanks to the “Everything is an API” way of life.

A serverless EC2 scheduler using Lambda and Cloudwatch Events

In an attempt to further reduce costs of our EC2 instances, we determined some instances that are running 24/7 unnecessarily. An automated process to schedule  stop and start instances would greatly help cutting costs. Of course, the solution itself should not add an extra instance to our infrastructure. The solution has to be an example of serverless computing.

Automagically stop running EC2 instances 24/7  unnecessarily

We created a lambda function that scans all instances for a specific tag. The tag we use is named ‘Schedule’ and contains the desired ‘runtime’ for the specific instance. Instances without a Schedule tag will not be affected. We support the following content format in the Schedule tag:

08:00-19:15   start the instance at 08:00, stop it at 19:15
21:00-07:45   start the instance at 21:00, stop it at 07:45 the next day
-17:45              stop this instance at 17:45 today
-16:30T           Terminate instance at 16:30 today
# whatever     Anything starting with a # is totally ignored

NOTE: All times are UTC times!

Invalid tag-content is automatically prefixed with an # so that it is ignored in future invocations of te lambda function. Also instances with only an end-time will have their tag rewritten to avoid restarts at 00:00.

Our lambda function is written in python using boto3 for AWS integration. The function requires a role to be able to interact with EC2. The lambda function has to be able to read and change tags, stop and start instances and even terminate them!

To further automate the process we need to automatically execute the lambda function, which can be achieved by creating a Cloudwatch Event Rule. It is a bit of a funny place for a schedule, but that’s where you configure it. The event will be used as a trigger to start our lambda function.

Instead of giving you instructions on how to create all of this nice stuff, we have written a cloud formation template for you to deploy in your own environment. It creates the lambda function, a role for it and a scheduler to activate the lambda function regularly. Make sure to adopt it for your local needs! It is a starting point more than a ready-to-use product.

The scheduler we create in the stack runs the lambda function every 10 minutes, giving your EC2 scheduler a granularity of 6 runs per hour.

Tag your instances with a Schedule tag and start reducing costs!

You can download the cloud formation template here and deploy it using cloud formation!

Or just press the button below and it will automatically be deployed!

Lanuch EC2 scheduler

Launch EC2 scheduler

The scheduler only works in the region(s) you deploy it in.

Share & Enjoy