The Console Settings page is used to make modifications to the console characteristics. This includes the CPU and Memory it is running with, the VPC and Subnets it is running within as well as the access URL you leverage to reach the console. Also included on this page is useful information about this particular deployment.
It is often useful to know the details of how the particular console you are in came about. Which stack did this console get deployed from? Where is it running? What is the unique service name? etc. Whether this is for your own purposes to explore within your AWS account or whether it is to get support from Cloud Storage Security, these data points are helpful. The Console Information section does just that. It gives you your current Subdomain, the CloudFormation Stack Name used to deploy, the uniquely generated Service Name and the AWS Region the console is deployed in.
In order to give you a secure and consistent experience with how you access the Console, Cloud Storage Security has implemented a subdomain registration process on your behalf. By default, we create a subdomain that is made up of your
AWS account ID - AppID. With this we generate an access URL to the Management Console consisting of
<accountID-appID>.cloudstoragesecapp.com. This is shown to you in the Stack Outputs after completing the CloudFormation Template stack create. You are welcome to continue with this URL for as long as you use the product. But, we have seen with some customers they would prefer something more meaningful and relevant to their organization.
This management page is to allow you to do just that. Pick a value that is useful and meaningful to you. Check the availability just in case it is being used. If your value is unique, the
Save button will be enabled. Clicking
Save will replace the
With any DNS changes, you may find that it takes a couple of minutes for the new URL to be recognized by the DNS servers you are pointing at.
Console Security Group Inbound Access¶
External inbound access to the Console is controlled through an AWS Security Group (identified by the name CloudStorageSecConsoleGroup-
Console Task Settings¶
Task Settings apply to the actual AWS Fargate Task (container) running the console. The default settings within the CloudFormation Template are to run the console with .5vCPU and 1GB of Memory. This is suitable in most cases and certainly when you get started. As your data sets grow and you do more with it as well and if you have large numbers of existing objects you plan to retro scan regularly, you may find that bumping these numbers will help your console run more smoothly. You selected a VPC and two subnets to run the console in during the CloudFormation deployment. There may be times you'd like to change these values after the fact and this section makes it very easy to do so.
This section is to allow you to easily modify the running values of the console.
The Memory must always be set to a value that is between 2x and 8x of the vCPU.
vCPU = 0.5, then 1gb <= memValue <= 4gb vCPU = 1, then 2gb <= memValue <= 8gb vCPU = 2, then 4gb <= memValue <= 16gb vCPU = 4, then 8gb <= memValue <= 32gb
You'll notice a
Private associated with each VPC. This is an indicator of whether or not the VPC is tied to an Internet Gateway. Thought process being that with an IG in place you will have the required outbound access. The console does not require a public IP address or to be accessible from the public in general, but it does require outbound internet access to get to AWS ECR to pull new Task images.
You'll notice a
Restricted associated with each Subnet. This is an indicator of whether or not the Subnet is outbound routable to the internet. Minimally, the agent task must be able to reach the AWS ECR to pull new Task images and to be able to pull AV signature updates. Two validations are performed for this check. First, we check to see if the NACL associated with the Subnet(s) has outbound open for 0.0.0.0/0. Secondly, we check to see if there is a custom Route Table in place and verify it is routed to an internet gateway.
Generally, the first indicator for a good configuration will be whether or not the VPC has an internet gateway or something that is taking its place. Secondly, check the subnets for their outbound access.
Changing these values will cause the console to reboot.
If the VPC or Subnets are not proper for the console, you could have trouble reaching the console.
Retro Scanning Performance Example
Retro Scanning starts by crawling the objects in a given bucket(s) for a given time period. Crawling performance will be impacted by the specs (mainly vCPU) of the Console container. The default specs of .5vCPU will crawl one million objects (spread across 4 buckets in our testing) in about 4 minutes. A console with 2vCPU crawled the same one million objects in ~70 seconds. Extrapolate that out over 10s of millions or billions of objects and it can make a significant difference. We will be providing a mechanism to dynamically change the console specs for the duration of the crawl, but in the mean time please make adjustments to the specs here.