Comment on page
Steps to Deploy
Deployment of our solution happens using a CloudFormation Template.
If you're planning to deploy both AV and DC at the same, then subscribe to both products and deploy AV first. When you enter the AV management console you can navigate to Configuration->License Management, where you will see an option to activate DC.
Which parameters you configure in the CloudFormation Template depends on what your requirements for your deployment are. Options include:
Standard Deploymentwhich requires filling out only 5 fields in the CloudFormation Template
- This also includes a completely
Private Deploymentwhere all of our components run in private VPCs and private Subnets with no public IPs assigned at all
- An in-between option where you have public access (public Load Balancer) while still running all solution components in a private VPC and Subnets
You can mix and match as well as incorporate VPC Endpoints to keep as much traffic as possible going over the AWS backbone.
Standard Deploymentis the simplest deployment. After providing only 5 inputs to the CloudFormation Template you will have a deployed and running solution in ~5 minutes. This deployment expects the Console and the Agent(s) to be placed in VPCs and Subnets that have an Internet Gateway (IGW) allowing for outbound traffic.
This a typical setup for VPCs and Subnets.The outbound routing allows ECS to pull down images from ECR, allows the Console and Agent(s) to communicate with required AWS Services and provides access to the management UI. Although public IPs are assigned, control is still done through Security Groups and access can be limited through IP ranges.
With this deployment, we register your application subdomain with a Route53 Hosted Zone we host and manage in one of the Cloud Storage Security AWS accounts. This allows you to have consistent access to your application. If you'd prefer to manage the domain and SSL certificate required for a persistent URL yourself, you can leverage the Application Load Balancer options discussed below and on the Advanced Deployment Considerations page.
You must provide values for the following fields in the CloudFormation template:
- 1.Virtual Private Cloud (VPC) ID
- 2.Subnet A ID
- 3.Subnet B ID
- 4.Console Security Group CIDR Block
You can leave all the default settings in the rest of the fields.
Set your network configuration
Set an initial email address
You must select a
VPCfrom the drop down list for the Management Console to run in.
You must select a
Subnet A IDfrom the drop down list contained in the selected VPC. Since we are doing a Standard Deployment, the subnet you select should be public, meaning it should have an IGW attached to it that allows outbound traffic.
You must select a different
Subnet B IDfrom the drop down list contained in the selected VPC.
The subnets you choose for
Bmust either be able to offer a public IP or be on a network you can access. Without that, the console will run, but not be reachable. This could simply be a public subnet reachable through an Internet Gateway.
Alternatively, it could be a private subnet that is an extension of your corporate network you access either from your corporate network or through a VPN connection. Or these subnets may be private subnets fronted by a public Load Balancer. Learn more about this option in the Advanced Deployment Considerations.
If you want to deploy privately continue reading further below.
Please note, If you select the same subnets for A and B, stack creation will fail. If you happen to pick the same value for each field, you will get a message as follows, please correct this before moving on.
Ensure both subnets you select belong to the VPC you have selected. You must select subnets in different Availability Zones.
We will create a Security Group (SG) for the Management Console that we deploy. This SG will have rules that contain IP ranges which can access the Console. You must select a
Console Security Group CIDR Block. Specify your network access or set to "0.0.0.0/0" to access the Management Console from anywhere.
If you need to add multiple IP ranges you can set your first one through the CloudFormation Template and once the solution is deployed you can go to the SG to add additional rules.
0.0.0.0/0 is wide open to the world. The application is still protected by SSL, a username and a password, but you may still choose to control this access. This could be your corporate network range or the /32 IP address your specific system is currently assigned. Google "what's my ip" and the first thing returned is what your current IP address is. Note: If your IP address changes, you may have to manually change the AWS Security Group value to represent the new IP
You must set a valid Email address which we will use to send the initial account username and password that you will use to access your Management Console.
You can leave all other parameters as-is and continue to step 2 if you only want to use the Standard Deployment and deploy publicly. If you want to deploy privately continue reading further below.
Acknowledge before creating the stack
I acknowledge that AWS CloudFormation might create IAM resources with custom names.under
Create Stackat the bottom of the screen.
The stack you just created will have a status of
CREATE_IN_PROGRESSas it runs. Wait for this to change to
CREATE_COMPLETEand monitor the events it generates.
When finished the status for the stack will show
Once the stack creation completes, click the
Outputtab. The top row in the table will have the URL for your Management Console. It will be in the format of
You will also receive an email to the address you entered while configuring your CloudFormation Template details.
It may take a few minutes for DNS to propagate the URL of your management console. If you are unable to load the URL provided in the email/CloudFormation Outputs then wait a few minutes. If it continues to be an issue, check the console access troubleshooting to see if it is another issue or Contact Us.
If you chose to use a load balancer, the first field will be called
In order to deploy privately you'll have to set the 5 parameters discussed above in the Standard Deployment section. However, this time you'll need to choose two private subnets (again in separate availability zones).
Private Deploymentsare defined by locking down the solution components (Console and Agents) such that they do not have public IPs (meaning leveraging private subnets that are behind a NAT Gateway). You can still provide public access if desired while locking everything else down. Whether it is best practices, compliance or internal rules you can deploy and leverage the solution as needed.
If you reviewed the Deployment Details page you'll see the deployment options leveraging Application Load Balancers. These can be
internaland can even be leveraged with the
Standard Deployment. You do not have to leverage an ALB in a private deployment, but there are a number of reasons you might want to.
First off, AWS Fargate tasks do not get assigned persistent IP addresses. As a result, the IP address can change underneath you requiring you to look it up. You may also decide you'd like to manage or apply your own domain and SSL certificate for accessing the application. A load balancer allows you to accomplish all of these things: a persistent access point, apply your own domain and leverage your own certificates.
If you only choose to use private subnets and do not use a Load Balancer in front of your Management Console, you will need to use the private IP that is generated by the ECS task that is stood up to host the console.
The 5 fields discussed above are the minimum fields that have to be set to get the product successfully deployed. For many deployments, the default settings will work well. With that said, the other options in the CloudFormation Template could be beneficial for you to configure and therefore could warrant your attention.
To view details for configuring additional settings within your CloudFormation Template you can review our Advanced Deployment Considerations section. Feel free to SKIP this section if you just want to start with the defaults. However, please consider two exceptions:
- 1.By default, the stack will deploy without the use of a Load Balancer. There are times when this will not work for your use case. Two such scenarios are: you want to use your own DNS and SSL certificate or you want to deploy in a private subnet behind a NAT. These are both great reasons to leverage a load balancer.If you would like to include a load balancer at the time of deployment you can do so in your CloudFormation Template. You can also add a load balancer to an existing deployment without one. And you can remove the load balancer after the fact as well. Simply run a Stack Update and add or remove the load balancer. This must be done manually through the CloudFormation Console.
- 2.Resources can only be renamed to match your particular naming scheme at the time of deployment. Changing these values later will result in errors. The default values are fine to leave but if you feel the need to rename values such as your quarantine bucket you should do so now before you've deployed.