Skip to main content

AWS ECS (Fargate/EC2)

In order to use Inigo functionality in AWS we have to complete two prerequisite steps: create Inigo service at app.inigo.io and subscribe to AWS Inigo Agent container.

Inigo Service Creation​

In order to be able to provide additional security and analytics to your graphql service create a new Inigo service. Follow these steps to create your service and to obtain INIGO_SERVICE_TOKEN.

  1. After successful registration at app.inigo.io, open the service configuration menu.

    Logo

  2. Select Docker Standalone option.

    Logo

  3. Choose service name and label (optionally), and click the Next button.

    Logo

  4. Save the INIGO_SERVICE_TOKEN value, by clicking on copy button, for the later usage.

    Logo

At this point, the work on Inigo's side is over. We will get back to the Inigo dashboard once the AWS configuration is complete.

AWS Inigo Agent Subscription​

To add Inigo's capabilities to your graphql service we have to configure the AWS Inigo Agent. Let's go through the subscription and deployment process.

  1. Head to the Inigo GraphQL Analytics product page in AWS Marketplace

    Logo

  2. Click the Continue to Subscribe button and accept the terms and conditions.

    Logo

  3. Wait for the AWS to process acceptance request to complete. Once it is done, Continue to Configuration button will be enabled.

    Logo

  4. On the configuration page select Cloudformation stack for AppSync fulfillment option, the latest version and hit Continue to Launch button.

    Logo

  5. For the following tutorials we will use container image directly for complete flexibility. You can use Copy button to download image locally or just use image reference for direct use.

    Logo

ECS

There is plenty of ways that you can configure your Inigo agent in your ECS/Fargate cluster. The only requirement that it has is to be able to call following graphql endpoints:

  1. app.inigo.io - to sync the schema and Inigo service configuration
  2. your-app.run.app - cloudrun to sync query data analytics

There are several combinations of architecture components setup are possible. You can deploy containers with two different networking approaches:

  • Public VPC subnet with direct internet access
  • Private VPC subnet without direct internet access

You can choose two different options for hosting the Inigo agent container:

  • AWS Fargate for hands-off container execution without managing EC2 instances
  • Self managed cluster of EC2 hosts for control over instance type, or to use reserved or spot instances for savings

You can also choose between two different ways of sending traffic to the Inigo agent container:

  • A public facing load balancer that accepts traffic from anyone on the internet (ideal for a public facing web service)
  • A private, internal load balancer that only accepts traffic from other containers in the cluster (ideal for a private, internal service).

We will not cover case of fully public setup as there are more secure ways to configure your Inigo agent in AWS.

Let's focus on two of them:

  • Publicly Exposed Inigo Agent with Private Networking
  • Internal Inigo Agent with Private Networking

Publicly Exposed Inigo Agent with Private Networking​

Logo

This architecture deploys your Inigo agent into a private subnet. The Inigo agent do not have direct internet access, or a public IP address. Its outbound traffic must go out via a NAT gateway, and recipients of requests from the containers will just see the request originating from the IP address of the NAT gateway. However, inbound traffic from the public can still reach the Inigo agent because there is a public facing load balancer that can proxy traffic from the public to the Inigo agent in the private subnet.

Run in AWS Fargate​

  1. Launch the Fargate cluster template
  2. Launch the public facing Inigo agent, private subnet template.

Run on EC2​

  1. Launch the EC2 cluster template
  2. Launch the public facing Inigo agent, private subnet template.

Internal Inigo Agent with Private Networking​

Logo

This architecture deploys your Inigo agent in a private subnet, with no direct internet access. Outbound traffic from your Inigo agent goes through an NAT gateway, and recipients of requests from the containers will just see the request originating from the IP address of the NAT gateway. There is no access to the Inigo agent for the public. Instead, there is a private, internal load balancer that only accepts traffic from other containers in the cluster. This is ideal for an internal service that is used by other services, but should not be used directly by the public.

Run in AWS Fargate​

  1. Launch the Fargate cluster template
  2. Launch the private Inigo agent, private subnet template.

Run on EC2​

  1. Launch the EC2 cluster template
  2. Launch the private Inigo agent, private subnet template.

Note: in any kind of the deployments your Inigo agent can be deployed as a sidecar to the graphql server you want to add additional security and analytics.

Head over to the Standalone agent documentation to learn more about the available environment variables.