Cognito User Pools, Google federation and AWS Amplify

In the previous article, we saw how to secure an API Gateway endpoint using Cognito user pools. We used the built-in capabilities of the user pools to create the users, sign them up, etc. But many applications nowadays don’t create users on their own; they use [social login] and rely on third-party social services such as Facebook or Google to manage users for them. In this article, we’ll see how we can adapt our previous code to allow users to sign-up and sign-in to our service using their Google account.

Basic API Gateway endpoint authentication with Cognito User Pools

In many occasions, you don’t want your whole API open to the public. Maybe you want to make some endpoints available to authenticated users. In this article we’re going to see how to do that using Amazon Cognito User Pools and AWS Amplify. Let’s start! Amazon Cognito User Pools As the documentation says, a user pool is a user directory in Amazon Cognito. You can allow your users to sign-up, sign-in, etc.

Interesting reads - June 2019

My good friend Edu Ferro has a very nice blog called eferro’s random stuff in which he posts the most interesting blogs, talks and podcasts he’s read, viewed and heard lately. I like the idea and, now that I have a bit more free time, I’ll try to do the same, at least once every month. I’m not going to post here podcasts and talks, basically because all the ones I listen I get them from Edu’s blog, so I’m just going to concentrate in blogs.


Last September I turned 40. You know, in the movies, when someone turns forty he buys a new brand card, gets divorced and tries something new. I still don’t have a car and, although I’m not married, I still live with my partner, but I did start something new. In my case, was an old “aspiration” (I tried it 7 years ago): learning to play guitar. Not that I want to be the next Angus Young but I never had any musical education and I always wanted to be able to play an instrument, especially guitar.

Using Key Vault secrets in AppSettings

In the last article we talked about securing Azure Functions and we saw how to insert a message into an Event Hub. To insert the message, we needed the connection string to be in an application setting. This is not the most secure way to store a connection string. We talked that it would be a much better option to store it in Key Vault. Until a couple of days ago, to do that we needed to use a library to get the secret from Key Vault and then use an imperative binding to be able to insert the message into the Event Hub.

Securing Azure Functions

(Thanks to Francesc Ribera, Alex Casquete and Jerry Liu for their guidance on this topic) As far as I know (correct me in the comments if I’m wrong, please), when you create a brand new Azure Function, it has access to everything in your subscription as a contributor. That’s really not great. When you develop a new Lambda function you have to specify all the permissions that the function has to have.

Deploying Azure Functions - Enabling Application Insights

In our previous articles we’ve seen how to deploy a Function App using the Azure CLI or Terraform. Once we have a function deployed and accepting traffic, the next obvious thing to do is to monitor it. Adding some logs to the function is fairly easy. If you take a look at the signature of the function [FunctionName("HelloWorld")] public static async Task<IActionResult> Run( [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req, ILogger log) you’ll see that we hava a parameter of type ILogger that we can use to, yes, you guessed it right, log.

Deploying Azure Functions using slots

In previous articles we’ve seen how to deploy a Function App using Azure Functions Core Tools, Terraform and Azure CLI with Zip Deploy. In this article we’re going to take a look on how to deploy Function apps using deployment slots. Why deployment slots Being able to deploy into slots and decide which slot you use in production has many benefits. To name some of them: - Enable A/B testing - Enable blue/green deployments - No downtime deployments - Easy rollback system

Deploying Azure Functions using Zip Deploy

In a previous article we’ve seen how to deploy a Function App using the Azure CLI and the Azure Functions Core Tools. In this article we’ll see how to get rid of the help of the latter and use the Zip Deploy feauture. Fixing the script. We already have a deployment script. It is something like this: #!/bin/bash location=$2 stage=$3 serviceName=$1-$stage resourceGroupName=$serviceName"-rg" serviceNameToLower="$(echo $serviceName | tr '[:upper:]' '[:lower:]')" storageAccountName="$(echo ${serviceNameToLower//"-"/""})" echo "Creating resource group" az group create --name $resourceGroupName --location $location echo "Creating storage account" az storage account create --name $storageAccountName --location $location --resource-group $resourceGroupName --sku Standard_LRS echo "Creating function app" az functionapp create --name $serviceName --storage-account $storageAccountName --consumption-plan-location westeurope --resource-group $resourceGroupName echo "Publishing function locally" dotnet build echo "Publisihng function to Azure" func azure functionapp publish $serviceName What are we going to do is to change the last two steps.

Deploying Azure Functions using Terraform

In previous articles (I, II) we’ve seen how to deploy an Azure Function App using the Azure CLI and the Azure Functions Core Tools. In this article we’ll see how to deploy it using Terraform. Prerequisites In order to follow this article you will need the .Net SDK 2.1, the Azure CLI and Terraform installed in your laptop/container/VM/whatever. Building the package What Terraform is going to do is take advantage of the Zip deployment capability (More on this in a future article).