Configuring AWS options
Advanced on-prem options are available to:
Team customers as an optional add-on
Enterprise customers as standard
AWS Transit GatewayCopy
This setup will allow Tray's connectors to reach inside your private network using routes established via attachment of a Tray-owned VPC to the your Transit Gateway.
This option will therefore only work if you are (at least partially) hosted on AWS and also use Transit Gateways to govern your network topology.
Transit Gateway required infoCopy
| Details | Notes |
|---|---|
| Customer Name | |
| Geographic location | The region in which your VPC is locatedwe will place the Tray VPC in the same region as required by AWS |
| Tray OrgID | |
| Your AWS Account number | |
| Your Transit Gateway ID | |
| Your subnet CIDR ranges | Tray uses 10.200.0.0/25 by defaultThis cannot overlap with your VPC CIDR rangeIn the unlikely event that it does, you should notify us so we can update it to be in another range |
Transit Gateway setup processCopy
We set up a separate Tray VPC network which does not overlap with your network and will not require you to reserve a large chunk of routes
We then create a Transit Gateway Attachment request to your network which will normally require manual acceptance by your AWS admins ('auto-accept' is not a recommended security practice)
Once accepted, our connectors will be able to reach the services hosted in your VPC
Transit Gateway technical ConsiderationsCopy
Once the request is accepted, you can still explicitly limit Tray’s access to the different corners of your network by using NACLs and Security Groups.
AWS PrivateLinkCopy
This setup will allow specific Tray connectors to reach your services hosted on AWS.
VPC Endpoints are what facilitate this type of connectivity - using a technology called PrivateLink.
PrivateLink enables private connectivity between VPCs and supported AWS services hosted by other AWS accounts, as well as third-party services on AWS Marketplace.
Key points in using PrivateLinkCopy
Traffic will stay within the AWS backbone and hence won’t be exposed to the public internet
A VPC endpoint does not require an internet gateway, virtual private gateway, NAT device, VPN connection, or AWS Direct Connect connection or any other networking component hence we are looking at a simplified buildout topology and less costs.
There is no option to natively encrypt this traffic, unless we use application-level tools such as TLS.
AWS PrivateLink required infoCopy
| Details | Notes |
|---|---|
| Customer Name | |
| Geographic location | The region in which your VPC is locatedWe will locate the Tray.io VPC in a region that is optimal in terms of latency when connecting |
| Tray OrgID | |
| Your AWS Account number | |
| VPC Endpoint Service fully qualified name | |
| VPC Endpoint Service ports |
AWS PrivateLink setup processCopy
We set up a separate Tray VPC network which does not overlap with your network and will not require you to reserve a large chunk of routes
We deploy the relevant connectors inside that dedicated VPC
We then create and host a VPC Endpoint
This endpoint will request connectivity to your network which normally requires manual acceptance by your AWS admins ('auto-accept' is not a recommended security practice)
Once accepted, our connectors will be able to reach the services hosted in your VPC
AWS PrivateLink technical considerationsCopy
In this scenario:
Tray will become a Service Consumer
You become a Service Producer
As per the above diagram Tray hosts the VPC Endpoint and will point it towards a fully qualified service name that is provided to us by you.
Your VPC endpoint service which supports integration with PrivateLink should be put behind a Network Load Balancer
VPC PeeringCopy
Allows Tray connectors to reach inside your private network using routes established via attachment of a Tray-owned VPC, as if both our VPCs were inside the same network.
This option will therefore only work if you are (at least partially) hosted on AWS.
Key points in using VPC peeringCopy
A Tray and customer VPC can communicate as if in the same network
No additional infrastructure (i.e. VPN servers) required
VPCs can be in different regions
No separate piece of physical hardware is required
No gateway is required
There is no single point of failure, or bandwidth bottleneck
VPC resources including EC2 instances, Amazon RDS databases and Lambda functions can communicate with each other using private IP addresses
All inter-region traffic is encrypted
Traffic never traverses the public internet - reduced threats from common expolits and DDoS attacks
There is no option to natively encrypt this traffic, unless we use application-level tools such as TLS
VPC Peering required infoCopy
| Details | Notes |
|---|---|
| Customer Name | |
| Geographic location | The region in which your VPC is locatedWe will locate the Tray.io VPC in a region that is optimal in terms of latency when connecting |
| Tray OrgID | |
| Your AWS Account number | |
| Your VPC ID | |
| Your subnet CIDR ranges | Tray uses 10.200.0.0/25 by defaultThis cannot overlap with your VPC CIDR rangeIn the unlikely event that it does, you should notify us so we can update it to be in another range |
VPC Peering setup processCopy
We set up a separate Tray VPC network which does not overlap with your network and will not require you to reserve a large chunk of routes
This endpoint will request connectivity to your target network which normally requires manual acceptance by you ('auto-accept' is not a recommended security practice)
Once accepted, our connectors will be able to reach the services hosted in your network
VPC Peering technical considerationsCopy
Once the request is accepted, you can still explicitly limit Tray’s access to the different corners of your network by using NACLs and Security Groups.
If you use Transit Gateway to manage your network governance - as opposed to individual VPCs and route tables - we would recommend using our Transit Gateway offering.