The Listrak Implementation teams have identified that Cloud Services such as AWS, Azure and/or Heroku can be a source of struggle and/or integration pain point with the Listrak API – Pre-Defined Static IP Sources. For added security the Listrak API restricts access to a subset of IP Addresses configurable per customer account.

At the time of drafting this document, Listrak plans to continue the use of restricting API access by Source IP Addresses in our current API and our developing REST API(s).

The following sections will identify a number of methods to direct / source traffic from a controlled range of IP Addresses when using AWS, Azure, and Heroku Cloud Services.

This document is intended as a living, changing, evolving over time document. As our customers identify and/or use new Cloud Services, we may update this document to reflect those new Cloud Services.

The following are the most common types of deployments on AWS Services.This will more than likely evolve over time to include Container and/or API Gateway services.

When an instance is launched in EC2-Classic, AWS automatically assigns a public IP address.This is the simplest method to get started with AWS, but is the most challenging as far as static outbound / source IP address control.Each time an EC2-Classic instance is stopped or as AWS sees fit the public IP address of the EC2-Classic may change.

The following are a couple of options, in order of simplest to more complicated:

The AWS Elastic IP Address option is a good fit / generally least expensive option for a small number of EC2-Classic instances.Where a third party Proxy Service is a good fit / generally least expensive for a greater number of EC2-Classic instances.

VPC or Virtual Private Cloud, is a customer owned logically isolated virtual network and instances.A VPC Deployment though much more complicated than the original EC2-Classic deployment is more flexible.For example, it’s possible to extend your own Corporate/Company network into a VPC deployment so that it functions as part of your own network, infrastructure, and/or domain.

One key take-away for VPC Deployed EC2 instances – by default VPC EC2 instances will have a private / non-public IPv4 address.
​

Options to control static / outbound IP Addresses within a VPC based deployment

The following are a few options, in order of simplest to more complicated:

Excerpt from AWS Documentation:

Elastic Beanstalk supports applications developed in Java, PHP, .NET, Node.js, Python, and Ruby, as well as different container types for each language. A container defines the infrastructure and software stack to be used for a given environment. When you deploy your application, Elastic Beanstalk provisions one or more AWS resources, such as Amazon EC2 instances. The software stack that runs on your Amazon EC2 instances depends on the container type. For example, Elastic Beanstalk supports two container types for Node.js: a 32-bit Amazon Linux image and a 64-bit Amazon Linux image. Each runs a software stack tailored to hosting a Node.js application. You can interact with Elastic Beanstalk by using the AWS Management Console, the AWS Command Line Interface (AWS CLI), or eb, a high-level CLI designed specifically for Elastic Beanstalk.

Elastic Beanstalk makes use of AWS CloudFormation to generate templates that either end up using EC2-Classic instances or VPC located EC2 instances.The EC2 instances created to support Elastic Beanstalk stacks are fully accessible to the end customer (and may be directly accessed through SSH and/or Remote Desktop).

See the appropriate section above to control static / outbound IP Addresses for either EC2-Classic or VPC deployed EC2 instances.

Excerpts from AWS Documentation, What is AWS Lambda:

AWS Lambda is a compute service that lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and scales automatically, from a few requests per day to thousands per second. You pay only for the compute time you consume - there is no charge when your code is not running. With AWS Lambda, you can run code for virtually any type of application or backend service - all with zero administration. AWS Lambda runs your code on a high-availability compute infrastructure and performs all of the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code monitoring and logging. All you need to do is supply your code in one of the languages that AWS Lambda supports (currently Node.js, Java, C# and Python).

…

When using AWS Lambda, you are responsible only for your code. AWS Lambda manages the compute fleet that offers a balance of memory, CPU, network, and other resources. This is in exchange for flexibility, which means you cannot log in to compute instances, or customize the operating system or language runtime. These constraints enable AWS Lambda to perform operational and administrative activities on your behalf, including provisioning capacity, monitoring fleet health, applying security patches, deploying your code, and monitoring and logging your Lambda functions.

Excerpt from AWS Documentation, Configuring a Lambda Function to Access Resources in an AWS VPC:

AWS Lambda runs your function code securely within a VPC by default. However, to enable your Lambda function to access resources inside your private VPC, you must provide additional VPC-specific configuration information that includes VPC subnet IDs and security group IDs. AWS Lambda uses this information to set up elastic network interfaces (ENIs) that enable your function to connect securely to other resources within your private VPC.

…

Internet Access for Lambda Functions:

AWS Lambda uses the VPC information you provide to set up ENIs that allow your Lambda function to access VPC resources. Each ENI is assigned a private IP address from the IP address range within the Subnets you specify, but is not assigned any public IP addresses. Therefore, if your Lambda function requires Internet access (for example, to access AWS services that don't have VPC endpoints, such as Amazon Kinesis), you can configure a NAT instance inside your VPC or you can use the Amazon VPC NAT gateway. For more information, see NAT Gateways in the Amazon VPC User Guide. You cannot use an Internet gateway attached to your VPC, since that requires the ENI to have public IP addresses.

The following are based on deploying Virtual Machines within Microsoft Azure.Container based deployments should be similar to the Azure Resource Manager Based Deployment.

Prior to 2014, the Classic Cloud Service was the only option for Azure.In some ways the classic method is simpler and provides more options than the current Microsoft recommended Azure Resource Manager framework.By default, outbound Internet access for a privately addressed Virtual Machine will source from a public IP associated to the Cloud Service.By default, the Cloud Service public IP can change, but it is possible to reserve and/or prevent this IP from changing. 

There are a number of options:

In 2014, Azure introduced and recommended that all Azure deployments moving forward utilize the Azure Resource Manager methods for managing, monitoring, and provisioning Azure resources.The main advantage of Azure Resource Manager over the Classic Cloud Service is the concept of the resource group.In the Classic Cloud Service framework, all resources were managed independently.With resources associated to a resource group it’s possible to configure access control to the resource group; or, monitor at the resource group level.The one notable feature not currently available is a public IP address at the resource group level similar to the Classic Cloud Service.
​

The following are a few options, in order of simplest to more complicated:

Heroku is a cloud platform based on a managed container system, with integrated data services and a powerful ecosystem, for deploying and running modern apps.Similar to AWS’s Elastic Beanstalk or Lambda service with one exception, instead of the application / application components running in Virtual OS Instances, they are running in Heroku Containers called dynos.

The sample above is for a Python Application on a single web server instance.Heroku also supports Ruby, Node.js, Java, Clojure, Scala, Go and PHP based applications. With many add-on modules available such as databases / ‘Data Stores’. (i.e. Postgres, Redis, MySQL, Kafka etc.) and the add-ons we are most interested in for this document, ‘Network Services’.

The following are a few options, in order of simplest to more complicated: