Internal Routing (Public Beta)
Last updated 14 August 2018
Internal Routing is a public beta feature available to apps in Private Spaces. Apps with Internal Routing work exactly the same as other Heroku apps (custom domain, SSL termination, logging), except their
web processes are exposed as endpoints that are only routable within the Private Space network and from VPC-peered and VPN-connected networks.
Example use-cases for Internal Routing include:
- Apps (such as APIs or microservices components) deployed on Heroku and consumed securely and solely by other Heroku apps in the same space or from software running in a peered customer AWS VPC.
- Apps that are only accessible to users on a VPN connected on-prem network. Requests to apps can only originate from hosts on the private network and requests and responses can only transit the IPSEC connection.
Internal Routing complements other Heroku features for intra-space networking and locking down app access:
- Private Space DNS Service Discovery: Direct network connections between dynos and process types (but no routing stack and thus no request logging or SSL termination)
- Trusted IP ranges: Limit external access to all apps in a space to a set of CIDR ranges (but no per-app granularity and IP ranges have to be kept updated)
Internal Routing is not available to apps on the Common Runtime
Creating Internally Routed Apps
Internal Routing is a beta feature. Please open a support ticket to request access. Remember to include the name of your Private Space.
Internal Routing can only be configured on app creation. Making an existing Private Space app internally routed is not possible.
--internal-routing option when creating the new app:
$ heroku apps:create --internal-routing --space test-space Creating app... done, ⬢ frozen-oasis-70544 http://frozen-oasis-70544.herokuapp.com/ | https://git.heroku.com/frozen-oasis-70544.git
Using Internally Routed Apps
Deploying internally routed apps is no different than deploying other Heroku apps. Like other apps, they also get a
http://<appname>.herokuapp.com endpoint and additional DNS targets when custom domains are added. Unique for apps with Internal Routing, these endpoints and targets resolve to internal, private IP addresses in the Private Space RFC 1918 CIDR range. The effect is that apps with Internal Routing will only accept connections opened from within the private space and from VPC-peered and VPN-connected networks.
The quickest way to troubleshoot apps with Internal Routing is to check logs with
heroku logs or alternative by using
curl from a
heroku run bash session (you can use the app itself or any other app in the Private Space):
$ heroku run bash -a frozen-oasis-70544 ... $ curl -I http://frozen-oasis-70544.herokuapp.com/ HTTP/1.1 200 OK
Because apps using Internal Routing can be hard to troubleshoot and debug, consider developing and testing code with a normal app, only without sensitive data and using standard access controls such as username/password and Trusted IP ranges.
Internal Routing is compatible with all other Heroku features, including add-ons, logging, application metrics, custom domains and SSL termination.
Automated Certificate Management is not compatible with Internal Routing because Heroku’s certificate partner cannot perform the required validation.
To access internally routed apps from a peered VPC that VPC must have a route for the entire Private Space
/16 CIDR. This is because the endpoint used to reach internally routed apps is not within the dyno CIDR ranges. Previously, Heroku documentation recommended only adding routes for the two Private Space
/20 subnets that contain dynos.
First, obtain your VPC’s routing table ID with the following AWS CLI command:
$ aws ec2 describe-route-tables
Look for the route table with the same VPC ID as your VPC and obtain its route table ID. Provide this ID to the
create-route AWS CLI command:
$ aws ec2 create-route --route-table-id rtb-your-route-table-id --destination-cidr-block 10.0.0.0/16 --vpc-peering-connection-id pcx-111aaa111
Optionally remove the two routes for the
/20 dyno CIDRs since these are covered by the new route.