0

Enabling AWS X-Ray on AWS Lambda

As you have probably noticed, debugging and getting latency data for your microservices can be painful if they interact with multiple distributed services. For these types of microservices, you are usually forced to build your own performance testing application, add an inordinate amount of log statements, or simply crossing your fingers and hoping for the best. From one of AWS’s posts on the subject:

“Traditional debugging methods don’t work so well for microservice based applications, in which there are multiple, independent components running on different services.” – AWS Lambda Support For AWS X-Ray

As a result, AWS built AWS X-Ray which, according to them, solves this problem:

“AWS X-Ray makes it easy for developers to analyze the behavior of their distributed applications by providing request tracing, exception collection, and profiling capabilities. ” – AWS X-Ray Documentation

Back in December, AWS announced a preview release of AWS X-Ray. While this was great and awesome, if you were a serverless shop and used AWS Lambda you were still out of luck.  Fortunately, in May ’17, AWS Lambda support for AWS X-Ray was released. Instrumenting your app has never been easier.

Below, I will go through the steps to update your CloudFormation template and instrument a Java application. We will then take a quick tour of the reporting and search features of the X-Ray dashboard.

Update CloudFormation

While we could enable X-Ray via AWS console, it is always better to have your application be fully deployable with a push of a button and a stack definition. On June 6, 2017 AWS CloudFormation released the TracingConfig property, that, along with a permissions change enables AWS X-Ray on your Lambda function.

Step 1: Enable TraceConfig

In your Lambda resource, you will add a new property called TracingConfig with the mode set to Active.

You will also add a DependsOn field for the execution role as the Lambda service checks permissions as soon as CloudFormation creates the Lambda function.

*Note: The default TracingConfig mode is Passthrough. This means that if any other service that has the Active mode enabled, your Lambda function will send tracing information to X-Ray. But if you access your Lambda function directly or through a service, that does not have X-ray enabled it will not send tracing information.

lambdaDemoXRay:
  Type: "AWS::Lambda::Function"
  Properties:
    Handler": "demo.XRayLambda::handleRequest"
    Role: !Join ["", ["arn:aws:iam::", !Ref "AWS::AccountId", ":role/", !Ref roleLambdaExecutionPolicy ] ]
    Description: Cloud formation created lambda for demo-xray-lambda
    FunctionName: demo-xray-lambda 
    MemorySize: 128
    Timeout: 140
    Code:
      S3Bucket: my.awesome.bucket.lambda.us-west-1
      S3Key: demo-xray-lambda/demo-xray-lambda-1.3.2.zip
    Runtime: java8
    TracingConfig: 
      Mode: Active
  DependsOn:
  - roleLambdaExecutionPolicy

Step 2: Add AWS X-Ray permissions

Next we need to give our Lambda function permission for the xray:PutTraceSegments and xray:PutTelemetryRecords capabilities. Here I have added a new statement to my inline policy in the execution role.

roleLambdaExecutionPolicy:
  Type: "AWS::IAM::Role"
  Properties:
    AssumeRolePolicyDocument:
     Version: "2012-10-17"
     Statement:
     - Action: "sts:AssumeRole"
       Principal:
         Service: lambda.amazonaws.com
       Effect: Allow
    Policies:
      PolicyName: demo-xray-lambda-policy
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
        - Action:
          - "xray:PutTraceSegments"
          - "xray:PutTelemetryRecords"
          Effect: Allow
          Resource: "*"

There are a couple of issues that can trip you up. First, IAM is a global service. As such, when you create a new role, it needs to be propagated to all regions. There is a possibility that your role has not been propagated to your stack’s region by the time CloudFormation starts to create your Lambda function. The Lambda service will throw an exception, and the stack will fail to create if it doesn’t have xray:PutTraceSegments permission. To get around this, you can either make your policy inline in your role resource, have two separate stacks for execution role/permissions and for your Lambda function, or reference an existing managed policy. I made my policy inline and have yet to run into an issue.

Another issue is when you have an existing stack/role that you want to add the X-Ray permissions to and enable TraceConfig in the same changeSet. This fails 100% of the time. Instead what you will need to do is rename your role resource so that it creates a brand new one instead of updating the existing one. As I mentioned with the previous issue you need to have your policy inline instead of as a separate resource. You should also add a dependsOn condition to your Lambda function to avoid parallel updates and ensure it will run/complete the role before creating the Lambda resource.

Instrument The Application

We will now start instrumenting our application by adding the necessary X-Ray libraries as well as adding a few lines of code to add more color to the traces. These libraries give you the mechanism to create your own custom segments to measure the performance of a subsection of your code. They allow you to add annotations which are indexed and enable you to search for subsets of your traces. They also allow you to add metadata to your subsegments which you can use for further debugging. For more information on how to instrument your application, please review the developer’s guide found here: http://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-java.html

Step 1: Add the AWS SDK to your application

The next thing we need to do is import the AWS X-Ray SDK so that we can start getting traces into our X-Ray Service Map. Update your build.gradle, to add aws-xray-recorder-sdk-core and a few other libraries into your dependencies.

dependencies {
  ...
  compile 'com.amazonaws:aws-xray-recorder-sdk-core:1.1.2'
  compile 'com.amazonaws:aws-xray-recorder-sdk-aws-sdk'
  compile 'com.amazonaws:aws-xray-recorder-sdk-aws-sdk-instrumentor'
}

At this point you could theoretically stop. You can push your code and you will begin to see traces in your X-Ray Service Map of your AWS::Lambda and AWS::Lambda::Function with a subsegment of Initialization. Per AWS documentation, this is because “the AWS SDK will dynamically import the X-Ray SDK to emit subsegments for downstream calls made by your function.” But wait, there is so much more we could be doing here.

Step 2: Add Custom Subsegments

Now let’s say that our function does a few things; download an S3 image, do some image manipulation then push it back up to S3.

public void handleRequest(String key, Size size) {
  Image image = downloadImage(String key);
  Image thumbnail = resizeImage(image, size);
  uploadImage(thumbnail);
}

Because you imported the aws-xray-recorder-sdk-aws-sdk-instrumentor you will automagically get subsegments for the S3 API calls. You could, however, create a your own custom subsegments for the image manipulation portion. Like so:

import com.amazonaws.xray.AWSXRay;
...
  public void resizeImage(Image image, Size size) throws SessionNotFoundException {
    // wrap in subsegment
    Subsegment subsegment = AWSXRay.beginSubsegment("Resize Image");
    try { 
      Image resizedImage = image.resizeMagic(size.getWidth(), size.getHeight());
    } catch (Exception e) {
      subsegment.addException(e);
      throw e;
    } finally {
      AWSXRay.endSubsegment(); 
    }
  }

You will now see a subsegment for resizing the thumbnail.

Step 3: Add Annotations to your Subsegments

So now that you have the custom subsegments, how do you know which one is which for, let’s say, large thumbnails versus small thumbnails? In comes annotations, which allows you to query your reports for a subset of your traffic.

*Note: you can only add annotations to subsegments, and not the root segment. I have seen where some people create a subsegment for the length of their handler, to which they add annotations and metadata, and then subsegments for the different subsections of that handler.

Simply updating our above code to this will give us this ability.

  public void resizeImage(Image image, Size size) throws SessionNotFoundException {
    ...
    subsegment.putAnnotation("Size", size.toString());
    subsegment.putAnnotation("ImageFileSize",image.getFileSize());
    Image resizedImage = image.resizeMagic(size.getWidth(), size.getHeight());
    ...
  }

Step 4: Add Metadata to your Subsegments

Additional useful tooling you can add is metadata to your subsegments. This can help you debug traces, for example, that have exceptions. In our image resizing example we could add things like image source size, or file type. That way when reporting on traces with exceptions we can drill down and see if we can narrow down root cause.

subsegment.putMetadata("source", "size", image.getSize().toString());
subsegment.putMetadata("source", "fileType", image.getFileType());

Reporting on your application

Ok, now that we have enabled X-Ray and instrumented our application it is time to head over to the AWS UI and start learning about our application.

Service Map

After accessing your application a couple times, head over to the X-Ray dashboard in your AWS console. Make sure you are in the region where you deployed your microservice. You will start off on the Service map page. Here you will see something like the below with all the functions that have had hits in the last 5 minutes:

Screen Shot 2017-07-25 at 11.24.57 AM

There are a couple things to note on this page. There is a search bar that you can use to filter requests either by service name, annotations or trace id. You can also change your time range to anything from the last 1 minute to the last 6 hours. Or you can put a specific day, a start time and the length of time which again can be anything from 1 minute to 6 hours.

You can also click on a given bubble in your service map and see additional details as well as filter by response type, fault or throttling.

Screen Shot 2017-07-25 at 11.33.01 AM

Indexing on annotations

At this point let’s take a look at filtering with annotations. In the status bar let’s type in the below:

service(id(name: "demo-xray-lambda", type: "AWS::Lambda")) { annotation.Size = "small" }

Then let’s change it to medium and we will see a slightly higher response time.

service(id(name: "demo-xray-lambda", type: "AWS::Lambda")) { annotation.Size = "large" }

Let’s take that a step further and see source images that are greater that 2 mb.

service(id(name: "demo-xray-lambda", type: "AWS::Lambda")) { annotation.ImageFileSize > 2 }

As I’m sure you are starting to notice, is that with this level of instrumentation and granularity you can start to get a  better understanding of your application’s response times, where some of your pain points are, and what you can improve on.

Drilling deeper

Now that we took a bird’s eye view of performance of our application as a whole, let’s drill down deeper into individual traces. You can get there by clicking on View Traces in your Service Details panel or by clicking in the left navigation on Traces:

Screen Shot 2017-07-25 at 11.49.55 AM.png

Here you will see all the requests that X-Ray chose to sample. You can click on an individual trace by clicking on its ID. This could look something like the below image depending on your application.

Screen Shot 2017-07-31 at 1.05.16 PM

Here you can see each subsegment, its response times, and at what point in your service response time it executed. Also, if you click on a subsegment that, for example, you added annotations or metadata to in your code, you will get a popup panel that will allow you to view that data.

Screen Shot 2017-07-31 at 1.10.05 PM

One use case for this, is to filter by error or fault and then click in the subsegments where we added source image data to the metadata to get a better idea on where the source of the problem is.

service(id(name: "demo-xray-lambda", type: "AWS::Lambda::Function")) { error = true }

Conclusion

As I’m sure you have probably noticed, with very little investment you can get pretty powerful visibility into your distributed application’s performance. AWS has simplified this process to the point where debugging, tracing requests and viewing the performance of a collection of service in one view can happen with just a few lines of code and a few clicks.

I hope this simple getting started guide gets you up and running. Let us know in the comment section below if you find this helpful and any suggestions or questions you may have.

7

AWS Lambdas with a static outgoing IP

Take a spin around the technical universe, and you will see that serverless computing is all the rage these days. Serverless computing doesn’t mean that there are no servers running your code. In the most popular use of the word, it simply means that you, the developer, don’t have to worry about it. Someone else has, and will monitor your service and make sure you have the right infrastructure and scalability in place.

Public Cloud providers like AWS and Google are simplifying the process for developers to leverage this architectural design concept. Do a quick search on the “serverless” keyword and the most popular related topics are in fact AWS with IoT being a close second.

Screen Shot 2016-07-03 at 1.00.04 PM

 

For software developers, serverless computing opens a world of possibilities as well as new security concerns. One of those concerns is how to handle whitelisting your service’s IP address for third party APIs on an infrastructure where IPs change quite frequently. For example, AWS released a post on this very subject & REST APIs where you can see what the IP ranges are at a given moment, saying:

You can expect it to change several times per week…

So, should we then specify a range of IPs in the API whitelist? Well, that would basically allow all of AWS to hit that third party API (not to mention some third party apis do not allow for a range). Not what you want, right?

Google’s implementation of serverless computing comes in the form of Google Cloud Functions, which was released in February 2016. At the time of this article, it is still an Alpha release and there is currently no way to define a static outgoing IP address. AWS’s implementation of serverless computing, called AWS Lambda functions has been in the wild for over a year now. As of February 2016, your Lambda functions can now access VPC resources. What does that mean for us? Simply put, we can now put them in a private subnet in our VPC and in essence assign static outgoing public IP addresses to them!

As a POC of this feature I decided to have a little fun with my latest game addiction, Clash of Clans. Over the next couple paragraphs I’ll walk you through how I configured my AWS Lambda behind a static public IP address, to then hit Clash of Clans’ public APIs.

Architectural Design

For this project we will need the following resources:

  • A VPC with:
    • Public Subnet
    • Private Subnet
    • NAT Gateway
    • Elastic IP
    • 2 Routes (public/private)
    • Internet Gateway
  • Lambda
  • API Gateway

lambda-ip-design-architecture

Following the digram, at a high level, this is what we need to do and, what these resources will do for us. First we will create a new VPC.

Next we will create 2 subnets. When you initially create a subnet it will get a default route and are both basically private subnets. Since we want one of these subnets to be public, we will create an Internet Gateway, and a new route that points all traffic to this gateway which we will then assign to our public subnet. Now any subsequent resources created in our public subnet will automatically get internet access, and as long as it has a public IP it will be publicly accessible to the outside world.

Then we will create a NAT Gateway in the public subnet. Its job is to provide internet access to resources in our private subnet. It will need a public IP which EIP (Elastic IP) will provide us with. At this point we will update our default route table (assigned to our private subnet) to route all web traffic to our NAT Gateway.

The last service we will need to configure is our AWS Lambda service. By using the microservice-http-endpoint blueprint, we will create a function that is publicly accessible with API Gateway. It will live in the private subnet of our newly minted VPC so that we can leverage the outgoing elastic IP address. The code will be very simple. It will make an authenticated HTTPS call to the Clash of Clans API and return the JSON object of the top ten international clans.

Resource Creation

Step 1: Create a new VPC

Head over to your AWS VPC dashboard and click on over to your list of VPCs. If you have never done anything with VPCs you will see a default VPC that AWS gives you out of the box. Click on the Create VPC link and enter in a meaningful name for you VPC. For example I used:

lambda-ip-create-vpc

Step 2: Create 2 Subnets

Now we are going to go to the Subnets page and create two subnets. One public and one private. (For availability purposes you would want to have multiple private subnets in different availability zones for your lambda to run on. For simplicity sake we will stick to one here) In the Subnet tab click on “Create Subnet”. For the name tag, make sure to include “Private subnet” in one and in the other “Public Subnet,” choose our newly created VPC, and select an availability zone (us-west-2c for example). For CIDR block use the same IP Range as your public subnet, but increment the 3rd octet by 1 from the highest number in your subnets in the same VPC. For example:

lambda-ip-create-public-subnet

lambda-ip-create-private-subnet

Step 3: Create an Internet Gateway

Next we will head over to the Internet Gateway view, click on Create Internet Gateway and tag it with a descriptive tag.

lambda-ip-create-internet-gateway

Then, we will click on our new internet gateway, and click on Attach to VPC, to attach it to our newly minted VPC like this:

lambda-ip-attach-igw-to-vpc

Step 4: Create a public Route Table and Assign it to our public route

Now that that is done we can head over to our Route Tables view and click on Create Route Table, giving it a descriptive tag and linking it to our VPC:

lambda-ip-create-route-table

Then we need to edit this route to point it to our new internet gateway. Click on the new route, click on the Routes tab, and click edit. Then add a new route, and we will set all traffic (0.0.0.0/0) to target our internet gateway and save it:

lambda-ip-configure-public-route

Now, click on Subnet Associations tab, click edit and, by ticking the check box by your public subnet and clicking Save, you will associate this new route to your public subnet.

lambda-ip-subnet-associations-public-route

Step 5: Create a NAT Gateway

First, take note of your public subnet’s id. You can see in my previous screenshot that it is subnet-8225a8da. Head over the the NAT Gateway view and click on Create NAT Gateway. On the creation screen go ahead and paste in your subnet id and click on “Create New EIP.” For example here is my new NAT Gateway with public IP of 52.43.112.142.

lambda-ip-create-nat-gateway

On the confirmation screen copy your nat instance id and let’s go back and edit our default route created when we created our VPC. Click on the default route (you will see the Main column for that route says Yes), click on the Routes tab, and click edit. Then add a new route, and we will set all traffic (0.0.0.0/0) to target our nat instance id and save it:

lambda-ip-configure-private-route

Lambda and API Gateway Configuration

Ok, now that our VPC is configured we can head over to Lambda and create/configure our new function.

Step 1: Create a new Lambda Function

On the Lambda Dashboard, click on Create a Lambda Function. On the first page, called “Select blueprint,” select the microservice-http-endpoint. This will then prompt you for API Gateway configuration options as well as Lambda configuration options.

Clicking next, I then configure the trigger (API Gateway options) giving it an API name of TechBlog-Lambda-IP, a resource name of /top10ClashOfClans, set the method type to GET and deployment to prod. Lastly, for the purposes of this demo, I’m setting the Security to Open. (Note: In the real world you wouldn’t want to do this, instead you would want to use either IAM, Open with access key, or implement CORS).

lambda-ip-configure-api-gateway-trigger

Step 2: Configure our Lambda Function

On the next page we then configure our Lambda function. First, I give my function a name (e.g. topTenClashOfClans), select Node.js as my runtime and after selecting “Edit code inline” for the code entry type, I paste in the below code (NOTE: ideally your key doesn’t reside as clear text in your code, instead you can leverage KMS encryption, but that’s a post for another day):

'use strict';
var http = require('https');
console.log('Loading function');

exports.handler = function(event, context) {
  console.log('start request to ' + 
    "https://api.clashofclans.com" +
    "/v1/locations/32000006/rankings/clans?limit=10");
  var options = {
    "method": "GET",
    "hostname": "api.clashofclans.com",
    "port": null,
    "path": "/v1/locations/32000006/rankings/clans?limit=10",
    "headers": {
      "authorization": "Bearer SUPER_SECRET_KEY",
      "cache-control": "no-cache"
    }
  };

  var req = http.request(options);
  req.on('response', function(res) {
    var chunks = [];

    res.on("data", function (chunk) {
      chunks.push(chunk);
    });

    res.on("end", function () {
      var body = Buffer.concat(chunks);
      console.log("Got response: " + body.toString());
      context.succeed(body.toString());
    });
  })
  req.on('error', function(e) {
    console.log("Got error: " + e.message);
    context.done(null, 'FAILURE');
  });
  req.end();

  console.log('end request to ' + 
    "https://api.clashofclans.com" + 
    "/v1/locations/32000006/rankings/clans?limit=10");
}

Below the code block you will now need to create a role and configure your VPC settings. I selected our newly minted VPC along with our private subnet. For example:

lambda-ip-configure-lambda-function

Below that I also selected the default security group. (Note: in production you would want to have this tightened down a bit more. Like for example, only allowing outgoing and inbound traffic via HTTPS.) Finally click next, verify your details and click on Create function.

So we did quite a lot of configurations between our Lambda service and in our VPC, but it is important to note that this was all done manually to better understand the interconnectivity of each resource. Ideally you would instead use something like AWS CloudFormation, Terraform by HashiCorp, etc. where you can spin up your complete stack or even subsequently destroy it with one click.

Clash Of Clans API configuration

Hopping on over to the Clash of Clans developer portal, I now need to tell them about my new IP address as well as download my auth key.

Step 1: Create a Key

To create a key, I need to give my key a name, and description and tell them the IP address I’ll be using. (At this point you might want to create separate keys for each environment and use your API Gateway configuration to tell your Lambda service what environment it is running in and therefore which key it should use.) So for example their UI looks like this:

lambda-ip-create-coc-key

Step 2: Get Authentication Token

Upon clicking Create Key I now get my token which I’ll update my lambda code with:

lambda-ip-get-coc-token

Testing it out

Now that my VPC has been configured, my lambda function is configured, Clash of Clans now knows my IP and I got my super secret key, I can know test out my API. Head over to the triggers tab of your Lambda service and you can see your API Gateway url. This is the url you will call from your application:

lambda-ip-view-api-gateway-triggers

If I head over to my browser and paste it in. Here is my snazzy JSON response from my lambda service, from Clash of Clans:

{
   "items":[
      {
         "tag":"#2VR2YY0G",
         "name":"Kings Rock",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/H_UNCwAz5F5o9SnxYPEqwhE8tijdg5ztf8Ffi_y20as.png",
            "large":"https://api-assets.clashofclans.com/badges/512/H_UNCwAz5F5o9SnxYPEqwhE8tijdg5ztf8Ffi_y20as.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/H_UNCwAz5F5o9SnxYPEqwhE8tijdg5ztf8Ffi_y20as.png"
         },
         "clanLevel":10,
         "members":50,
         "clanPoints":56417,
         "rank":1,
         "previousRank":1
      },
      {
         "tag":"#2JGYRJVL",
         "name":"MEGA EMPIRE",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/P51qQIW5aDVBI6ePeuj1u7anlf1qaDVr0qPQdAgSmXQ.png",
            "large":"https://api-assets.clashofclans.com/badges/512/P51qQIW5aDVBI6ePeuj1u7anlf1qaDVr0qPQdAgSmXQ.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/P51qQIW5aDVBI6ePeuj1u7anlf1qaDVr0qPQdAgSmXQ.png"
         },
         "clanLevel":8,
         "members":49,
         "clanPoints":55883,
         "rank":2,
         "previousRank":2
      },
      {
         "tag":"#YJLRUQY8",
         "name":"HOUSE of CLOUDS",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/uYP4fFjKjVCPEHxLSTji76wGgLRGDp-C60_oZI2B9fQ.png",
            "large":"https://api-assets.clashofclans.com/badges/512/uYP4fFjKjVCPEHxLSTji76wGgLRGDp-C60_oZI2B9fQ.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/uYP4fFjKjVCPEHxLSTji76wGgLRGDp-C60_oZI2B9fQ.png"
         },
         "clanLevel":7,
         "members":50,
         "clanPoints":55123,
         "rank":3,
         "previousRank":4
      },
      {
         "tag":"#PCG9G0L2",
         "name":"Come & Take It",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/FDV-1GfIK5FxhTDgR5JdEOr1XJ4NGO8mUvO0STYRyi4.png",
            "large":"https://api-assets.clashofclans.com/badges/512/FDV-1GfIK5FxhTDgR5JdEOr1XJ4NGO8mUvO0STYRyi4.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/FDV-1GfIK5FxhTDgR5JdEOr1XJ4NGO8mUvO0STYRyi4.png"
         },
         "clanLevel":10,
         "members":48,
         "clanPoints":54821,
         "rank":4,
         "previousRank":3
      },
      {
         "tag":"#PV0UP0Y",
         "name":"GULF KNIGHTS",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/HZWcNNf5_I3CCV7gGPG0GmZJ6OFKUFB9N1dNxeX5xUY.png",
            "large":"https://api-assets.clashofclans.com/badges/512/HZWcNNf5_I3CCV7gGPG0GmZJ6OFKUFB9N1dNxeX5xUY.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/HZWcNNf5_I3CCV7gGPG0GmZJ6OFKUFB9N1dNxeX5xUY.png"
         },
         "clanLevel":8,
         "members":45,
         "clanPoints":54063,
         "rank":5,
         "previousRank":5
      },
      {
         "tag":"#2JG20YYU",
         "name":"kurdistan is 1",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/K4OvVfQow1H4pRmjrdy1t6ev49M6LcGZfU6EdsPWTRQ.png",
            "large":"https://api-assets.clashofclans.com/badges/512/K4OvVfQow1H4pRmjrdy1t6ev49M6LcGZfU6EdsPWTRQ.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/K4OvVfQow1H4pRmjrdy1t6ev49M6LcGZfU6EdsPWTRQ.png"
         },
         "clanLevel":10,
         "members":47,
         "clanPoints":53553,
         "rank":6,
         "previousRank":6
      },
      {
         "tag":"#8PCL0Y9J",
         "name":"BRASIL TEAM",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/l7PnLiAsZG8WNPKBiGdSmzmzQGHMj8hsd2_AUoQ3vtc.png",
            "large":"https://api-assets.clashofclans.com/badges/512/l7PnLiAsZG8WNPKBiGdSmzmzQGHMj8hsd2_AUoQ3vtc.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/l7PnLiAsZG8WNPKBiGdSmzmzQGHMj8hsd2_AUoQ3vtc.png"
         },
         "clanLevel":8,
         "members":50,
         "clanPoints":53103,
         "rank":7,
         "previousRank":7
      },
      {
         "tag":"#9QCJGJPY",
         "name":"FACÇÃO CENTRAL",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/m3q5ZFSiIDDTFHIEtZfuLlQFXgvovohntlW1IMC4IMM.png",
            "large":"https://api-assets.clashofclans.com/badges/512/m3q5ZFSiIDDTFHIEtZfuLlQFXgvovohntlW1IMC4IMM.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/m3q5ZFSiIDDTFHIEtZfuLlQFXgvovohntlW1IMC4IMM.png"
         },
         "clanLevel":9,
         "members":50,
         "clanPoints":52997,
         "rank":8,
         "previousRank":-1
      },
      {
         "tag":"#Q0909PUG",
         "name":"Los Inmortales",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/SxnbX9hipl2xGrQUEz9G037jTLVI3gKv3hh_etgKiaw.png",
            "large":"https://api-assets.clashofclans.com/badges/512/SxnbX9hipl2xGrQUEz9G037jTLVI3gKv3hh_etgKiaw.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/SxnbX9hipl2xGrQUEz9G037jTLVI3gKv3hh_etgKiaw.png"
         },
         "clanLevel":9,
         "members":49,
         "clanPoints":51763,
         "rank":9,
         "previousRank":-1
      },
      {
         "tag":"#YRPJ280Y",
         "name":"Req and Leave",
         "location":{
            "id":32000006,
            "name":"International",
            "isCountry":false
         },
         "badgeUrls":{
            "small":"https://api-assets.clashofclans.com/badges/70/CHUt9lOScEJ0m0CeUTha8KdTpVZ73oqQxhNunoI0BLw.png",
            "large":"https://api-assets.clashofclans.com/badges/512/CHUt9lOScEJ0m0CeUTha8KdTpVZ73oqQxhNunoI0BLw.png",
            "medium":"https://api-assets.clashofclans.com/badges/200/CHUt9lOScEJ0m0CeUTha8KdTpVZ73oqQxhNunoI0BLw.png"
         },
         "clanLevel":8,
         "members":49,
         "clanPoints":51163,
         "rank":10,
         "previousRank":10
      }
   ],
   "paging":{
      "cursors":{
         "after":"eyJwb3MiOjEwfQ"
      }
   }
}

In Conclusion

So there you have it. The fact that our API call returned successfully, proves that the Clash Of Clans APIs where able to verify that 1) we called from the IP we said we would call from, 2) we used the token they created for us, and 3) we made our call via SSL.

Granted, there are definitely quite a few shortcuts we took in this implementation where security could be tightened up. This is in no way a productized implementation. It is, instead, an over simplified POC on demonstrating the new relationship between AWS Lambda and AWS VPCs. We have proven that we can use AWS VPC infrastructure to configure a AWS Lambda to use a static outgoing IP. This allows for tighter security when locking down who has rights to access your APIs. In our business case we can now say that our microservices connecting via SSL, using a security token X, as well as, a calling from IP X.X.X.X can access our financial resources is a fully trusted consumer, and any other connection is blocked from accessing those same resources.

Feel free to take a spin with the above instructions and provide any comments or feedback on this implementation.