Keeping up with the latest skills: AWS IoT, Polly, and Rekognition



Recently, I secured a number of AWS IoT Buttons for our office to play with and wanted to try to see how easy they would be to set-up and use in various mock-up applications. In the spirit of playing around with the buttons and keeping up my technical skills related to the AWS platform, I decided to make a small proof-of-concept project around them by collecting some old Android devices I had lying around, and various bits and pieces of AWS services such as Image recognition.

The concept I finally settled with is a remote surveillance camera solution which can be triggered remotely with the AWS IoT Button, and which performs simple image recognition labelling the image content in the form of gender, roughage, mood, and other parameters. The solution will update a “monitoring” website where the latest surveillance image will be shown and the recognised characteristics spoke out for the viewer, removing the need to read the monitor in detail.

For building the actual solution I selected the following tools and technologies together with the AWS platform:

  • Android tablet – I like to repurpose and recycle old and unused items, so I decided to use a decommissioned tablet as the IoT device which will act as the camera module for the system. Android devices are, in my opinion, one of the best toys to have lying around for building solutions requiring mobile, IoT, or embedded components. The platform is quite easy to use and easy to write applications in.
  • NodeRed – Since I didn’t want to spend too much time configuring and setting up the IoT libraries and framework in the Android devices, I decided to use NodeRed as the solution providing the MQTT protocol support, as it provides easy to use programming tools for doing quick PoCs around IoT. Running NodeRed requires SSH-access to the device, which I established using Termux and associated modules or controlling the camera etc.
  • The AWS IoT Button – This was an obvious choice as it was one of the technology components I wanted to test and one that also made me start working with the project in the first place.

As the main idea of the solution was to build something around the AWS IoT Button and see how easy it is to set-up and use, this meant using the AWS platform as the IoT “backend”. For the rest of the solution, (as I didn’t want to start maintaining or setting up servers myself) I decided to use as many platform services as possible in AWS. I ended up working with the following AWS services:


Using the AWS IoT platform for the message brokering, connectivities, and overall management of the IoT solution.


The requirement here was to configure the various access roles and rights for all the architectural components in a secure way.


Using two distinct S3 buckets. One for uploading the images taken by the camera, one for hosting the website for the “monitoring” purposes.

AWS Lambda

Lambda functions were used to perform the required calculations and actions in a “serverless”-fashion and to remove the need for maintaining infrastructure components.

AWS Polly

Text-to-speech service used for creating the audio-streams required by the solution.

AWS Rekognition

Image recognition service used for analysing, and labelling the images.

AWS CloudWatch and logs

Used for monitoring and debugging the solution during the project.

AWS CloudFormation

Used for creating the resources, functions, roles etc. in the solution.


I selected to use Python as the programming language as the Boto3 libraries provide easy APIs to utilise the AWS services. Python was used to write all the Lambda functions to perform the processing required by the overall solution.

How everything was brought together

After registering the AWS IoT button (which was easily done with the AWS Android app), and Android devices to AWS IoT framework and provisioning the security credentials for them, they were good to be used as part of the solution. The architectural idea was to press a button to trigger a Lambda function which will do a few checks on the “upload” S3 bucket, creating a temporary signed URL for the S3 bucket. It will then use the AWS IoT topic to notify the Android devices on the image capture trigger. The Android device would then take the picture of whatever is standing in front of the camera and upload it securely to the “upload” S3 bucket using the temporary upload URL provided via the MQTT message it received earlier.

Whenever new images are uploaded to the S3 bucket, this will trigger another serverless action in the background. This Lambda-function will take the image and use AWS Rekognition for performing the image recognition on it. The recognised labels and objects will then be run through AWS Polly to create the required audio stream. After all the new content is created, the Lambda-function will upload the content to the other S3 bucket where the website is hosted to show and play the content for whoever is watching the “monitoring” website. The separation of the S3 buckets provides added security measures, (a DMZ of sorts) to safeguard the website for the potentially harmful content which could, in theory, be uploaded to the upload bucket if the temporary upload URL was somehow acquired by an attacker.

The whole solution is secured by AWS IAM by providing the least amount of necessary privileges for all the components to perform their actions in the exact resources they are using.

Enabling Cloudwatch monitoring and logging is a good choice for debugging the solution, at least during the development phase. This enabled me to catch unnecessary typing errors in the granular IAM policies in the Lambda function’s IAM Role during the set-up.

My findings

This was a rather quick and fun project to work with and provided some insight into using the AWS IoT Button and Android devices as part of the AWS IoT ecosystem. The devices themselves were rather easy to get registered and functioning in the set-up. Of course in a large-scale real-world environment the set-up, certification creation, and installation of the IoT devices would need to be automated as well to make it feasible. Incorporating small Lambda-functions with image recognition and text-to-speech was quite straightforward and worked as a good learning platform for the technologies.

When applying the project to a customer situation, I would definitely improve it by adding image transcoding for different screen sizes, create a proper web-service with searchable UI and proper picture database/index etc. All in all, I can highly recommend playing around with the IoT framework, IoT button, and NodeRed in Android. Creating these kinds of small side-projects is the perfect platform for people in our business to continue improving our skills and know-how around the ever-expanding technology selection in modern IT environment.

Nordcloud offers deep-dive workshop which will help to identify the opportunities that impact your business and help you shape data-driven solutions which will take your business to the next level, contact us for more information.


Stop murdering “Agile”, and be agile instead

“Agile Macabre” on, Apr-2020 I’ve been leading projects since 2002, becoming a full-blown agilist around 2011. Not so long...


Make Work Better by Documentation

Sharing knowledge in a team is an ongoing challenge. Finding balance between writing documentation and keeping it up to date,...


How can you maximize the value from your data?

Your market is changing in faster and less predictable ways than ever before. Enterprises of all sizes suffer from data...

Get in Touch

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

Throwback – AWS Tech Community Days Summit, Cologne



For the first time ever the largest and most technical gathering of the German AWS community took place in Cologne. Cloud and software experts from all over Germany shared their experiences and best practices on how to use AWS in the best possible ways. Nordcloud, as an AWS Premier Partner, recognises the value and importance of this kind of event and participated with a team of experts, whilst supporting the event as a Gold Sponsor.

The AWS tech community talks were categorised into four key areas: Cloud Software Architecture, DevOps, Big Data & AI (‘Streaming & Freeform), and Containers (‘Kubernetes’). This enabled experts to participate by talking about any of the topics in the context of real-life projects or theoretical work. This meant there was a daily activity composed of four talks running in parallel, which gave attendees the opportunity to switch between the four tracks based on their interests. Between each talk, there were opportunities to mingle with other attendees which provided a great networking platform and chance to talk about challenges that the speaker had discussed.

Lessons Learned

We were able to take away some nuggets of information home with us from the event. Here are our lessons learned:

Containers Kubernetes

Although the talks were mostly from independent speakers from different companies, most of them were attempting to solve or were challenged with similar problems when using Kubernetes. The challenge was the difficulty in finding an efficient and highly available Kubernetes solution in AWS. We hope in the future AWS will address this during the upcoming re:Invent in Las Vegas this November. We will have our team on the ground there to make sure the word is spread quickly.

Cloud Software Architecture

In this track, we had the chance to hear about a variety of different topics. One of the most exciting ones was about ‘how to achieve ‘more security with serverless’, where there was a lot of discussion about how to properly secure today’s most commonly used serverless solution setup, which includes API Getaway, Lambda, DynamoDB, and S3. We had the chance to see some best practices and real use cases from different industries.

Streaming and Freeform

In this track, we learned how to manage PostgreSQL RDS in order to store several customers without impacting query performance, whilst enabling blue-green deployment. We also discovered how to build a cost-effective and scalable infrastructure for handling near-real-time ingestion and analytics of large quantities of sensor data based on Lambda, S3, DynamoDB, and Redshift services.

Upcoming AWS Transformation Day in Cologne

Looking for other ways to add value to your business? This AWS Transformation Day in Cologne brings together enterprises that have already harnessed the advantages of the cloud to share and discuss with their peers about leveraging the potential of the Cloud. Get more information and register for free here.


Time to rescue your data operations

The value created by data can fundamentally influence key areas of your business, from enabling, optimizing and steering key functions. ...


What it’s like to be a new hire during Covid-19

We all have been there before, the thrill of getting that call when your future manager makes the offer. You...


A Recruiter’s Perspective on Remote Work

In the times of the Coronavirus you can read a lot about ways of switching to the remote ways of...

Get in Touch

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.

Everything you needed to know about spot instances



AWS recently announced some more features for Spot instances, an exciting prospect for anyone wanting to make some significant savings. In this blog, we’ll take you through what Spot instances are and how they differentiate from Reserved instances.

Spot instances, next to On-demand and Reserved instances are another financial model for your EC2 workloads. With On-demand, you pay a fixed hourly price per instance. With Reserved instances, you’re able to reduce your EC2 cost by around 30-40% in exchange for a 1 or 3 year commitment to AWS. While Reserved instances bring you a significant discount compared to On-demand, you are tied into this commitment. If AWS reduces their prices or introduces new instance types that are cheaper, your savings could end up lower and you’ll still be paying for your Reserved instances until the end of the commitment.

Spot instances work on a supply and demand model, meaning AWS takes advantage of unused instance capacity, giving you the opportunity to save as much as 90% compared to the On-demand cost.

So what’s the catch?

First, we need to understand how exactly the pricing model for Spots works. When you want to use Spot instances, you submit a Spot request in the EC2 console or using the CLI. Here, you have to specify all parametres of the instance (OS, type, size, availability) and your bid price. The bid price is the maximum price your willing to pay for a specified EC2 instance. When your bid price exceeds the current market price and the instance is available you can use it at the market price. The current market price is given live updates and reflects the need for specific instances.

If your bid price is lower than the current market price, you will not get the possibility to use the Spot instance. If you’re using a Spot instance and the market price exceeds your bid price, your instance will be terminated or stopped (you’ll receive a notification two minutes before it happens). It’s good to note here that if the instance is stopped you will still be paying for EBS volumes as usual, but you can terminate or stop your instance at any point, (Spots are different from Reserved instances as they can be stopped at anytime). The way pricing works also means you’re not able to forecast your costs and plan your budget with 100% accuracy, however, you can still view a specific instance market price history in the AWS console.

In the example below, we’re looking at an m4.xlarge instance running in a us-east-1 availability zone, (each AZ has its own market price, compared to On-demand and Reserved instances where price is set on a regional level). Let’s say you want to use an m4.xlarge Spot instance in a us-east-1e availability zone. If your bid price was $0.1, (shown on the graph below) the market price would exceed your bid-price, and your instance would be stopped or terminated. However, for the majority of the time you would actually pay around $0.06 per hour, (which would be 70% less that On-demand).

Now let’s say your bid price was $0.18 (close to the On-demand price). In this case, your instance would be stopped less frequently because the price was only exceeded a few times in a given term. You would still pay around $0.06 for the majority of the time, but because you pay the market price, your bid should only exceed the current market price. You would be saving around 65-70%, even though your bid price was much higher. It’s best to bid below the On-demand price, which brings not only savings, but also reduces the risk of your instance becoming inactive.

Note: T2 and HS1 instances are not available on the Spot market

Let’s see how the pricing history looks in an eu-west-1 region fro certain instances:

For the majority of the time, the most popular instances tend to keep their market price significantly below the On-demand price. If you were to run a single Spot instance such as m3.medium in the eu-west-1a availability zone for the previous 3 months, you instance would be running without any interruptions for a whole term, (saving you around 80% compared to the On-demand price).

You could still bid your price around the On-demand price and get the same savings. The problem starts however when you want to use bigger instances (eg. m4.16xlarge). These bigger, more expensive instances tend to exceed the On-demand price, making them a bit riskier. However, over three months in the example below, the m4.16xlarge instance price exceeded the On-demand price only once.

If you choose a more ‘unusual’ instance, there will be a higher possibility of exceeding the On-demand price.

Let’s look at some other examples:

Instances like d2 or g3 fluctuate much more than the ‘standard’ instances. There’s a possibility of saving a considerable amount on these, but you need to be prepared for a sudden stop or termination.

What if you want to run your application on different instance types and recieve optimum savings? The answer to this would be to use Spot fleet.

A Spot fleet is a collection of Spot instances which attempts to maintain the capacity you’ve specified. For example, when you run your application on a single m4.large On-demand instance, you can use Spot fleet to specify that your application needs to be run on multiple instances.

You can also specify that your desired capacity is 1, meaning you can run on either the m4.large, m4.xlarge, m4.2xlarge etc, as all of them have the same specifications as the m4.large, (you can also choose instances from another family that match your desired instances’ parametres). You can then set up your bid price globally for around the same price as the m4.large On-demand price. Spot fleet then attempts to launch the specified instances that will result in the lowest cost. This results in an overall higher ability and can lead to even higher savings. For example, if the m4.large instance price rose over the On-demand price, (some of your other instances in your spot fleet might currently have a lower market price) then your workload will be moved to another instance instead of being stopped or terminated.

What else can I do with Spot fleets?

You can use instance weighting to specify differences between various instances according to what you need. For example, your application performs best with at least 8GIB of RAM and 2 vCPUs. If you wanted to run one 8GIB plus 2 VCPUs as 1 unit (running 16 of them at a time), and use m4.large as our base unit, here’s how the initial list of instances (pools) would look next to a Spot fleet:

Instance Type RAM (GIB) vCPU
m4.large 8 2
m4.xlarge 16 4
m4.2xlarge 32 8
m4.4xlarge 64 16

How do we weight the different instances?

In the example above, your target capacity is 16, meaning that you’ve requested to run 16 m4.large instances. An m4.large instance would then have the weight of 1 and an m4.xlarge (which is two times bigger) would have the weight of 2 and so on. You can weight your instances any way that suits you, but you should do it by using the instance parametres.

Spot fleet allocation strategy: Lowest Price vs Diversified prices

You can choose your strategy to be a diversified price, or the lowest price. The lowest price strategy is the default and means that your Spot instances will come from a pool of the lowest priced per unit. Diversified price allows your instances to be distributed as evenly as possible across all your pools. The bid price works with weighting, so your bid price becomes a bid unit price.

If we wanted to set up the bid price as $0.2 (an m4.large On-demand price), a single m4.2xlarge instance would cost $0.4 ($0.2 per unit times 2 units by weight). You can also override the global bid price for a specific instance in you Spot fleet to either maximise or reduce the risk of interruption.

If you chose to stay with the lowest price allocation strategy, your Spots will be launched in a pool that has the lowest price per unit. If your Spot fleet launched 16 m4.large instances becasue they were the lowest price at the time, at any given moment, the m4.xlarge could become cheaper per unit. This is either because the m4.large Spot price has risen, or the m4.xlarge Spot price lowers. If this does happen, your Spot fleet will switch to run on 8 m4.xlarge instances.

How to weight your instances and which you include in your Spot fleet request is important. Your Spot fleet, whenever a calculated instance count is not a whole number, rounds it up. So if with the given example, we wanted 10 instead of 16 to be the target capacity and m4.2xlarge to be the cheapest per unit, your Spot fleet would launch 3 m4.2xlarge instances. This may not give you the highest savings possible, (because you need 2.5 of this instance, but Spot fleet rounds it up to 3), so be aware of that when requesting your Spot fleet.

If you choose the diversified allocation strategy, your Spot fleet will attempt to distribute the workload evenly across the pools. This is the best strategy when you don’t want to worry about fluctuating prices and keeping a steady usage, but still want to keep you bid price in check. In the example, your Spot fleet would choose to run 1 m4.4xlarge (8 units), 1 m4.2xlarge (4 units), 1 m4.xlarge (2 units) and 2 m4.large (2 units) instances. Whenever one of the pool’s Spot prices are higher than the bid price, your spot fleet will try to adapt to the new situation whilst still trying to diversify your usage across the available pools.

It doesn’t end there: Autoscaling

Autoscaling scales up or down your autoscaling group based on policies and is especially useful when you experience peaks in your application’s usage. You can also do the same with Spot instances. Your autoscaling group is now your requested Spot fleet and you can set up policies based on CloudWatch alarms. With our above example, let’s say you want your applications to use more instances for better availability, or less instances for better savings. You could set up a scaling policy based on CPU utilisation and, whenever you utilisation reaches 90%, you can add one new instance (or unit) to your Spot fleet. If your CPU usage is below 60%, you would want to remove one instance from you Spot fleet. This can also work by percentage, (so you can add or remove 20% of your current capacity) and you can specify the action after the alert to set up where you specify a new capacity amount.

Keep in mind that Spot fleet always rounds up, so your scaling policies can have escalated action, or no action at all. It depends what type of pools you have in your Spot fleet and how you describe your scaling policies.

Are Spots for everyone? No, if you think your application is likely to be stopped or terminated, then you’re better off using Reserved instances. Perhaps you want to run a minimum required workload on Reserved instances, whilst also handling Spot peaks. Spots are perfect for non time-sensitive batch jobs like media encoding, data analysis, or big data, meaning any application that doesn’t need to be up and running all the time is a good example of a Spot use case.

If you’d like to find out more about Spot or Reserved instances, please get in touch here.


Challenges of virtual workshops

In March 2020 I was supposed to give a full-day training about Google Cloud Platform fundamentals. Unfortunately two days before...


All at sea in cloud migration? These 7 considerations might just save you

1) We moved all our Servers into the cloud, nothing appears to have changed, where’s the benefit? The cloud won’t...


Getting started with ARO – Application deployment

This is the fourth blog post in a four-part series aimed at helping IT experts understand how they can leverage...

Get in Touch

Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.