Security Now
Security is top-of-mind, especially right here where Juniper experts share their insights on the latest security trends and breakthroughs
Security Now
Global AWS Transit VPC solution with Integrated security at a competitive price point
08.14.17

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.

 

vsrx_price_competition_small.png

 

 

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 

 

 

07.11.17
Simon thibaudeau

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?

07.13.17
Juniper Employee
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.25.17
Buck Wallander

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 transit-vpc-push-juniper-config.zip archive file should be a folder in the account’s S3 bucket, accessible by the CF template.
 For example: Use “juniper-transit-vpc-1/transit-vpc-push-juniper-config.zip” 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 “transit-vpc-poller.py” script file should be a folder in your account’s S3 bucket, accessible by the CF template.
 For example, use “juniper-transit-vpc-1/transit-vpc-poller.py” 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 https://github.com/Juniper/vSRX-AWS.git && 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.25.17
Buck Wallander
07.25.17
Juniper Employee

@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. 

Top Kudoed Authors