Search the community
HomeKnowledge BaseTech Zone
26

Aviatrix Sandbox Starter Tool - Spin up Cloud Networks in Minutes

Introduction

Aviatrix Sandbox Starter Tool (SST) is a community-based and community-supported tool that deploys a small test/lab cloud network environment in minutes.

This SaaS like lightweight automation tool first deploys an Aviatrix Controller in AWS. Once the Controller is up, the tool uses Terraform to create Aviatrix transit (Hub and Spoke) topology in AWS.

Two EC2 test instances will be deployed with proper connectivity, that can be used to run test cases, POC or SRE work using the Aviatrix platform with simplicity, automation, visibility, and control.

The tool also has an option to automatically build a network in Azure and join clouds together. Additional use-cases can then be added directly from Controller UI or Terraform following step by step tool user guide.

SST itself can be deployed using three different options

  1. Cloud AMI 
  2. Cloud AMI via Terraform Module
  3. Local Machine 

This document uses the Cloud AMI Option#1 to deploy the SST and Cloud Networks.

Cost

The cost estimation is based on standard and current price modeling from AWS and Azure. Depending on your enterprise or partner agreement, reserved instance, and CSP credits, you could be paying around $0.56 cents per hour or even less than that in AWS.

For a detailed cost breakdown, please click here.

Before You Begin

Note:

This tool works the best for a brand new Aviatrix Controller deployment. If you previously deployed Aviatrix Controller, make sure you delete the following first

  • Aviatrix EC2 roles
  • Aviatrix EC2 policies are deleted
  • Delete Aviatrix default key-pair

Launch Sandbox Starter AWS EC2 Instance

You can deploy this tool in any AWS region. Make sure you have a proper EIP and VPC quota for your region. In our example, we will be deploying the Sandbox Starter tool in the N. Virginia region (us-east-1).

  • Click here for the N. Virginia region EC2 setting

 

  • Click here to search for the Sandbox Starter Public AMI under the Images section and select the latest Sandbox Starter AMI

 

  • Click the Launch button and select t3.micro or t2.micro instance size

  

  • Click Configure Instance Details and provide the following information. Leave everything else as default
    • Network: Select the default VPC.
    • Subnet: Select the public subnet
    • Auto-assign Public IP: Enable

  • Click Add Storage button. Do not change anything here
  • Click Add Tags. Do not change anything here
  • Click Configure Security Group and block inbound access to SST EC2
  • Create a new security group with the following information
    • Security Group Name: Aviatrix_Sandbox_Starter_SG
    • Delete the SSH TCP 22 rule and add a new HTTPS TCP 443 rule. You must make sure that only your IP address has access to Sandbox Tool
    • Ignore the warning

 

Reference: Authorize inbound traffic for your Linux instances

  • Review and launch now

 

  • Select the Key Pair and Launch

  • Click on the instance ID to show the details and copy the Public IPv4 address

 

 

  • Once the instance "Running", browse to https://<Public IPv4 address>
    • In our example it is https://54.173.15.154/
    • The tool uses a self-signed certificate
      • Accept the warning and proceed
      • If using Chrome and you get a connection error message, you can bypass that by clicking anywhere and typing thisisunsafe

You should see the "Aviatrix Sandbox Starter" user interface (UI) now.

Standard Mode Wizard with AWS

Standard is the recommended workflow. This will deploy the controller and topology in the regions specified in the diagram.

  

 

Provide AWS Credentials

 

You can get the Access Key under the "Security Credential" area in AWS console. If you don't have one, you should create one.

Launch the Controller in AWS

 

Notes

  • It is recommended to provide a corporate email address to request for Aviatrix CoPilot test license
  • In the future, we might add the option to launch Controller in other Clouds

Launch Global Transit (Hub) and two Spokes in AWS

  

Launch Test EC2 instances

Test EC2 (Amazon Linux VMs) will be launched in their respective Spoke VPCs

  

Provide an Existing Key Pair Name

This must be configured in your AWS account in us-east-2 (Ohio) region as per-requisite. You will need this Key Pair to login to test EC2 instances to verify the end-to-end connectivity.

Select No for "Launch Aviatrix Transit in Azure"

Success Message

Upon success, you will receive the necessary public and private IP addresses. The entire process should take somewhere between 22-30 minutes.

Now you can log in to Aviatrix Controller UI by clicking the controller URL.

Note: The user name is admin and the password is the one you selected earlier in the process.

  

Lock Inbound Access to Controller

After the Controller is deployed, you must do the following to lock the inbound access so that no one has access to it.

1-  Enable the security group management feature so all of the gateways' IP addresses are allowed to reach the controller on HTTPS/port 443

2- Lock all inbound access to Controller except your own IP address

Reference: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html 

Experience the Platform and Deploy Use Cases

Follow the instructions in the Test Plan to experience the Aviatrix Multi-Cloud platform and deploy recommended use case.

Besides that, users are highly encouraged to deploy more use-cases based on their needs and requirement by following the official documentation at https://docs.aviatrix.com

Standard Mode Deployment with AWS and Azure

Azure deployment is optional. You must have an Azure subscription and related information if you are planning on extending the network in Azure.

For Sandbox deployment both in AWS and Azure, follow the video here

https://youtu.be/INqXNQgWgmg

 

Advance Mode Wizard

Advance mode is for users who would want to change the region, naming convention, and subnet scheme.

  

Provide AWS Credentials

 

Before launching the controller, you can change the region and subnet details as shown in the following screenshot.

Notes

  • It is recommended to provide a corporate email address to request for Aviatrix CoPilot test license
  • In the future, we might add the option to launch Controller in other Clouds 

Launch Global Transit (Hub) and two Spokes in AWS

Launch Aviatrix Global Transit (Hub) and two Spokes in the AWS region as per your requirement.

  

Launch Test EC2 instances

Test EC2 (Amazon Linux VMs) will be launched in their respective Spoke VPCs

 

Provide an Existing Key Pair Name

This must be configured in your AWS account in us-east-2 (Ohio) region as per-requisite. You will need this Key Pair to login to test EC2 instances to verify the end-to-end connectivity.  

This concludes the deployment in AWS. Optionally you can also deploy Aviatrix Transit network in Azure and provide connectivity between AWS and Azure clouds.

Launch Aviatrix Transit in Azure

  

  

 

  

Connect AWS and Azure with a Single Click

 

Success Screen

 

Lock Inbound Access to Controller

After the Controller is deployed, you must do the following to lock the inbound access so that no one has access to it.

1- Enable the security group management feature so all of the gateways' IP addresses are allowed to reach the controller on HTTPS/port 443

2- Lock all inbound access to Controller except your own IP address

Detailed Cost Breakdown

Description

Unit Cost

Quantity

Hourly Cost

Cost for 8 hours

Cost for 24 hours

Aviatrix Controller in AWS (t3.large)

$0.09

1

$0.09

--

--

Aviatrix Gateway in AWS (t2.micro)

$0.01

3

$0.03

--

--

Test instances in AWS (t2.micro)

$0.01

2

$0.02

--

--

Aviatrix Encrypted Peering (AWS)

$0.21

2

$0.42

--

--

Cost for resources deployed by Wizard Tool (including minimal network egress charges)

--

--

$0.56

$4.48

$13.44

Note

  • The estimated cost is around 0.56 cents per hour in AWS
  • If you extend the network in Azure, then add $1.09/hour to the cost
    • Aviatrix Gateways in Azure (B1s): 0.01/hour x 3 = $0.03/hour
    • Aviatrix Encrypted Peering (Azure): $0.21/hour x 2 = $0.42/hour
    • Aviatrix Transit Peering (between AWS and Azure): $0.64/hour
  • Customers/students/partners are responsible for paying all the cost for running the instances in the Cloud (AWS/Azure/GCP/OCI/etc) and Aviatrix license cost
  • Additional use-cases/labs would require additional cost depending on the instances deployed and Aviatrix tunnel build
  • The Aviatrix cost breakdown is also listed on the AWS marketplace when you subscribe to the Aviatrix Controller

Further Cost Saving

  • You may shut down the entire setup when not using it. That could also significantly bring the cost down
  • Make sure to disable Aviatrix's "Single AZ HA" feature, otherwise, the Controller will power on the Aviatrix Gateways automatically.

Destroy / Delete the entire LAB

Once you are done testing and validating Cloud Networks, you may destroy or delete the entire lab. Use the "Destroy" option on the top right of the browser UI.

If you destroyed SST before getting a chance to destroy your environment, you will need to manually delete these resources in order (always check you are in the appropriate region first):

  1. Terminate the Spoke and Transit gateways in AWS (if applicable)
  2. Remove the Resource Groups in Azure (if applicable)
  3. Disable Termination Protection on the EC2 instance for the Controller
  4. Terminate the Controller EC2 instance
  5. Remove the SSH keypair
  6. Delete the Security Groups
  7. Delete the VPC where the Gateways and Controller was deployed
  8. Delete the IAM Roles and Policies starting with ‘aviatrix’

Note that if you deployed CoPilot, it must be deleted manually by logging into AWS/Azure Console.

Support Model

This community-based and open-source tool is NOT supported by the Aviatrix Enterprise support team. For any questions or issues related to this tool, please use the Aviatrix Community platform.

Open Source

  1. Code for this open-source tool is available at https://github.com/AviatrixSystems/sandbox-starter
  2. Terraform module for Sandbox Starter launch is available here at https://github.com/terraform-aviatrix-modules/terraform-aviatrix-aws-sandbox-starter
  3. The container code is available here
25replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular

  • Amazing, Shahzad Ali, I really enjoyed this post

    Like 2

  • Great tutorial; the sandbox build and use case testing went well. Now I'm trying to figure out how to destroy the build; I get "this site can't be reached". The controller and all the gateways are up, but I can't get back to the Sandbox Starter screen to click the "Destroy" button. I try to manually shutdown the instances, but they auto start. How do I run the Destroy command from the Docker CLI?

    Like

    • Mike Arnold You should be able to get to the UI if you reboot. If not, then try this manual method. https://community.aviatrix.com/t/g9htn2y/aviatrix-kickstart-cli

      Your terraform state should be there in the Docker. The terraform destroy should destroy it all.

      Like

    • Shahzad Ali I'm not sure, but I think my issue may be that I ran the sandbox startup from a cloud9 instance; I can't find the terraform files, so it looks like I may need to shut everything down manually from AWS console.

      cloud9
      Like

    • Mike Arnold From your screenshot, it looks like you're just at the root of your cloud9 ec2 instance itself. Since you can't get to the UI, I'm guessing that the sandbox-starter docker container isn't running anymore. You could check with the following command. 

      docker ps

      If there's nothing listed, you could try to start it with this command. 

      docker start $(docker container ls -aq)

      If that doesn't get you the UI (to try and execute the 'destroy' button), but the container is running (verified from the output of 'docker ps'), then you could try this - from your bash prompt (as shown in your screenshot) execute this command: 

      docker exec -it <container_id> /bin/bash

      ..where <container_id> is the id of your container as shown from the 'docker ps' command. This puts your bash prompt inside the container. Then 

      cd controller
terraform destroy

      If your terraform state is still available, you'll get a listing of all the infrastructure you provisioned and be able to reply yes to have it destroyed. I'm making assumptions as to the current state of your environment, so you may run into issues with these commands.

      If you want to destroy you environment manually, you'll need to start with the controller first. It's the one that is restarting other instances.

      Let us know how it goes

      Like

  • John, thanks for the tips

    I was able to start the container after running the image; however, it looks like I need to re-initialize the terraform script. 

    NOTE: because I was getting billed to my personal account, I used the controller to detach and delete all the gateways; this gave me a little breathing room to play with this. I configured backups to an S3 bucket before I deleted the gateways. I'm wondering if I performa a restore if I would be able to run the destroy command; or, if it even matters. Can I run the destroy command if some objects have been removed manually?

    Like

    • Mike Arnold I wouldn't expect destroy via the tool to be an option based on your screenshot. Having removed the gateways via the controller, the only objects left are the controller ec2 instance, 2 iam roles, 2 iam policies, and the ec2 keypair. Once you remove those, you'd be able to run the tool again if you want.

      Like

  • John Smoker  yep, gotcha. I could run a restore then a destroy, but to tell you the truth, I'm getting a little bored with this; I'll go ahead and do the cleanup manually. 

    I'm not sure if my reasoning for using cloud9 is valid, but it was quick and easy to get sandbox started; docker was pre-installed. I just had to run the commands.

    I think my first mistake was setting a 30min time for sleep mode; it made since at the time. I didn't realize that the container wouldn't startup automatically

    Thanks for your help; I have a much better understanding of how this process works. I'm going to dig a little more into the terraform  scripts then clean it all up manually

    Like 1

    • Mike Arnold Yeah, the starter is really just that - a jumpstart to demo the product. Once you're looking at the terraform code itself, you've got the tool and patterns for deploying the infrastructure directly (no docker required). Good luck!

      Like 1

  • Hi Shahzad,

    I just deployed with the Standard option by following the instructions and the result was instances (Spokes) that are disconnected from Transit.
    I also checked this to be sure..the route tables for them have just 0/0 via IGW :)
    I assume there should have been some routes via the ENI of the Spoke GW (wanted to reverse engineer a bit).
    I can also see this with FlightPath.
    Is there any quick way to correct this?

    Thanks.

    Like

    • Mihai The tool automatically connects Spoke to Transit. How did you verify that Aviatrix Spoke GWs (EC2) are disconnected from Aviatrix Transit GWs (EC2)? Can you send u screen shot please?

      In any case, you can connect them in the Controller UI under Multi-Cloud Transit --> Setup section.

      John Smoker Umair Hoodbhoy

      Like

    • Mihai Confirming that this is a bug in the current version and that the spokes do not attach to the transit as you've described. You can fix this manually by going to 'Multi-Cloud Transit' on the left-hand navigation, choosing 'Setup', scrolling to '6a Attach Spoke Gateway to Transit Network', selecting a spoke and transit and clicking 'Attach'. Repeat for the other spokes. Be sure to only attach aws gateways to aws transit and the same for azure (if applicable). Version 0.5 (latest) of the sst image fixes this issue. If you launched from the ami, that will be updated in the next few hours, depending on the launching region.

      Like

  • John Smoker

    Thank you for confirming this and the "fix" worked :) (I have to recognise that I did spot that menu but did not try it out to see what happens, I rushed a bit through).
    I had launched it from ami (used the latest guide, I know that before there was a docker container -> Terraform that did all the magic in the background).

    Like 1

    • Mihai Glad that worked for you! The ami is just a packaging of the sst container. Which, you're correct, is powered by Terraform. The code is open source and you'll find it here.

      Like

  • Obviously the Starter Tool in AWS doesn't destroy itself, just the components it deploys.

    Apart from destroying that SST EC2 instance, whatever else should be destroyed?

    Like

    • Erik Lawaetz If you've executed the 'Destroy' from the sst UI, the only thing remaining is the sst ec2 instance. If there was an issue during that process (your aws access key or azure credentials not having permissions to clean up), the components that the sst deploys are resource groups (and infrastructure contained within) in azure, and ec2 instances, keypairs, and vpcs (in the regions you've selected), 2 iam roles and 2 policies in aws.

      Like

  • I set this up which went well, but I (and two other colleagues) all had issues with destroying the environment. The destroy button only removed the controller itself, but nothing else in AWS and Azure. I went into docker on the Sandbox instance and only saw terraform deploying the controller and as such it only wanted to destory that, but nothing else. I had to remove the rest manually.

    Like

    • I found that the rest of the state is in the mcna folder, but it seems like terraform destroy doens't get executed in that folder for some reason.

      Like

    • Adam Stipkovits The destroy button code calls terraform destroy from both the mcna and controller folders. Interesting that didn't occur in your case. Was there any error message in the debug output (blue bug button in the bottom right corner)? Since you're inside the container, what's the output for: 

      terraform state list

      ...inside the mcna folder? If there are items in that list, what happens if you: 

      terraform destroy -auto-approve

      ?
       

      Like

  • there are reference to the IAM user credentials in the beginning of the guide, but not a single word about which IAM permissions this user should have assigned, could you please clarify this point?

    Like

    • vjacheslav Great question! I've updated the Before you begin section to provide guidance under the access/secret key topic. Hope this helps clarify. Let me know if you have further questions.

      Like 1
      • vjacheslav
      • vjacheslav
      • 1 mth ago
      • 1
      • Reported - view

      hello John Smoker much appreciated for the update!

      Like 1
Login to reply
Like26 Follow
  • 26 Likes
  • 2 wk agoLast active
  • 25Replies
  • 4136Views
  • 19 Following
cancel
Mention someone by typing their name
No matching users
Powered by Forumbee

Home

 View all topics

Tags

 View all tags