Global AWS Transit VPC solution with Integrated security at a competitive price point

By praviraj posted 07-10-2017 15:39


Most AWS deployments evolve from a single VPC to multiple VPCs spread across numerous regions as the enterprise expands. However, with multi-VPC deployments, enabling connectivity between VPCs requires explicit peering using VPC peering modules, which are restricted to peering VPCs within a single AWS region and do not possess the ability to granularly filter and control traffic flowing between VPCs.


Transit-VPC solution with Juniper’s virtual SRX allows enterprises to seamlessly add NGFW services and connectivity to large multi-VPC AWS deployments. This solution utilizes a hub-and-spoke topology where every VPC connects to a special “transit VPC” which serves as a central hub for internal traffic, as well as external traffic sent to the corporate on-premises data center or the internet. For enterprises with large deployments in multiple regions, the same solution can easily scale to support a global transit network by connecting multiple transit networks as seen in the Figure.



Global AWS Transit VPC deployment in a multi-region hybrid cloud deploymentGlobal AWS Transit VPC deployment in a multi-region hybrid cloud deployment 

For the sake of simplicity only 3 VPCs are shown connecting to each transit VPC in Figure1. However, the AWS limit of 100 spoke VPC per transit-VPC can be achieved.


Benefits of an AWS Transit VPC solution with Juniper vSRX:


  • Integrated security: Juniper’s vSRX Virtual Firewall can offers NGFW services, in addition to the routing and carrier-grade IPsec capabilities on a single instance thereby eliminating the need for Switch Port Analyzer (SPAN) ports
  • High performance routing: AWS allows for 100 spoke VPCs to connect to a transit VPC. Juniper’s vSRX can support 128 Virtual Routing Functions (VRFs), which supports the scaling requirement needed to take full advantage of a transit VPC deployment.
  • Ease of deployment: This solution can be easily deployed within minutes in an AWS deployment using CloudFormation templates or ansible scripts.
  • Centralized management and granular policies: Junos Space Security Director provides intuitive and centralized management to configure and monitor security policies across the entire network. Each VPC could have a unique security policy, allowing granular control based on roles and responsibilities.
  • Lower licensing costs and TCO: vSRXs software licensing costs on the AWS marketplace is lower than similar offerings from the competitors like Cisco, Palo Alto Networks, and Checkpoint. Also, the vSRX consumes significantly fewer AWS resources, which translates to lower operating costs.





To learn more about how Juniper can help enterprises deploy a Transit VPC solution with integrated security on their AWS deployments, read this Solution Brief


Juniper Networks supports two modes of deployment for AWS Transit VPC:


  • Cloudformation templates - Checkout the implementation guide here 
  • Ansible scripts - Reach out to learn more about this option 






10-11-2018 13:21

Considering this or the software defined perimeter model by the likes of Cyxtera Appgate. Pros/Cons? 

05-27-2018 02:57

This solution with automatically add connection between spoke VPC and transit VPC in different region of the same AWS account.

Is there any cloudformation to add spoke VPC with different AWS account to transit VPC?


e.g. Transit VPC in AWS account A. Spoke VPC in AWS account B. Add connection with each other.


08-14-2017 16:20

@ Kurt, Thanks for your feedback. We are working towards addressing the issues with the documentation and also looking at publishing a more efficient workflow using CloudInit. I will update this thread once it becomes available.


08-14-2017 14:12

Yeah, there seems to be issues with this implementation as well as a few holes in the documentation. I followed Buck's blog post and was able to get everything running except the 'juniper-configurator' function that pushes the new configuration to the vSRX's in the Transit VPC. Also, the '' file referenced is not in the GIT repo. You have to download the file from: and then place the file in the S3 bucket that you reference in your CF template. But, as I stated above, there are still issues with this implementation and documentation.

07-25-2017 17:18

@Buck, Thank you very much for your feedback and suggestions. We will try to clarify that better in our next revision of the guide .The issue on first glance seems to be with importing the 'paramiko' module as you pointed out. Let me circle back with the team to investigate potential causes. 

07-25-2017 15:53

After a bit if work this seems to function great, thanks for creating it and giving a little competition in the marketplace.


I'd just like to note; It isn't really clear by reading the imp guide however when going with at least the CF deploy route, make sure you that you download these files from Juniper's github repo and then re-upload them to a newly-created S3 bucket in your account.


This part specifically is what I think lacks clarity (to me, anyway):


 Step 3: Under Function’s hierarchy, navigate to the container “Configurator.”
 • Check for the CodeLocation flag—the code location for the archive file should be a folder in the account’s S3 bucket, accessible by the CF template.
 For example: Use “juniper-transit-vpc-1/” for the .zip file stored in the S3 bucket “juniper-transit-vpc-1” in your AWS account.


 Step 4: Under Function’s hierarchy, navigate to the container “Poller.”
 • Check for the CodeLocation flag—the code location for the “” script file should be a folder in your account’s S3 bucket, accessible by the CF template.
 For example, use “juniper-transit-vpc-1/” for the Python script stored in the S3 bucket “junipertransit-vpc-1”


Obviously, not everyone is going to be able to use a bucket by the name "juniper-transit-vpc-1", so you will need to create a unique name.


In essense, to make this CF solution work is really a five-step process:

1. Clone the repo (git clone && cd vSRX-AWS/Transit-VPC/)
2. Zip & Upload the `Configurator` and `Poller` lambda function files to a NEW S3 bucket (don't forget permissions!)
3. Modify `transit-vpc-primary-account.template` to update two 'CodeLocation' values with previously created S3 bucket
4. Accept vSRX EULA(s) in AWS Marketplace
5. Finally deploy the CF Stack using modified `transit-vpc-primary-account.template` JSON file


As an unsolicited feature request, I think it would be nice if you can allow a user to input the separate S3 bucket name. You'd still have to manually create the new, separate bucket and upload files, but you don't have to manually update the json file. Not even sure that's possible, but just a thought anyway!

07-13-2017 02:25

The CloudFormation template from Juniper also contains Lambda functions to automatically discover and connect new Spoke VPCs.

Please take a look at the implementation guide referenced above for more details.

07-11-2017 09:08

One of the value proposition of the solution offered by AWS and the Big-C is that is apparently discovers new VPCs in the account with a Lambda function, S3-buckets and some CloudWatch events, I believe, and deploys the VPNs and routing automatically.


Is the intent that the customer would automate the deployment of new spokes on their own or is there plans to reproduce something like the AWS/Big-C bundled solution?