Deployment Details

Learn more about our flexible deployment options.

We offer a number of flexible deployment options based on what you need. This includes:

• The Standard Deployment which requires filling out only 5 fields in the CloudFormation Template

• This also includes a completely Private Deployment where 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.

All components deployed, created and installed run inside of your account. We do not host any of them and we never send any of your objects/files outside of your account. All scanning is performed close to the data inside your account(s) and in-region.

Our console requires specific permissions to manage its own infrastructure and integrate with your AWS services. To provide the most secure environment, we recommend deploying it in a dedicated AWS account. This isolates the product's permissions and prevents any unintended impact on other resources.

As you'll learn below, we may send some data (IP address, account email, version numbers) to a Cloud Storage Security AWS account to assist you and your users with accessing your application. You can opt out of this if you don't want that information to be reported.

No matter the deployment option you choose, you can also leverage local signature updates for both the Sophos engine and the ClamAV engine through our private mirror functionality.

Standard Deployment

The Standard Deployment is 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 cert yourself, you can leverage the Application Load Balancer options discussed below.

Standard Deployment:

Standard Deployment Single Region

Standard Multi-Region Deployment: `Public Routing

Python - Agents VPC Endpoints Script

Using our Private Deployment Template

If you need a way to deploy privately but aren't sure which subnets to use from your current VPCs or which VPC endpoints to setup, you can use our private deployment CFT to create a new VPC with all of the resources (subnets, VPC endpoints, etc.) needed to deploy your Management Console and scanning agents in a fully private environment.

This template will first deploy the following networking pieces before deploying the software:

• A VPC and public + private subnets

• All necessary VPC endpoints in a single region

• An AWS network firewall

• An application load balancer that will sit in front of your management console. You will need a valid SSL certificate from AWS Certificate Manager to be able to deploy.

AWS Network Firewalls can be costly. If you are only performing testing make sure you don't forget about the deployment and properly tear it down.

Below is a screenshot of the parameters you can expect within the private deployment CloudFormation template.

Select the image to expand it

You can always find the latest version of our private deployment template here.

API Endpoint

The API Endpoint is another Agent Service that allows for an API Driven scan of files and objects. It can be mixed into any of the deployment options above. It earns a special call out because it has its own Application Load Balancer deployed for and associated with it. So you can have a deployment that has an ALB fronting the Console and then another ALB fronting the API Endpoint. Like previously discussed load balancers, you can choose to make the ALB internet-facing or internal, it all depends on your needs.

We are not showing a multi-region deployment below, but if your requirements dictate it, you can deploy as many API Endpoints as needed so scanning can be close to users/applications/data.

API Endpoint - Publicly Accessible

Public API

1. Users can configure their application to upload their file to an API endpoint that the Scanning Agent sits behind via an HTTPS request.

2. The request and file is processed through the Internet Gateway sitting at the entrance of the VPC where the API Agent resides.

3. The request and file reach the Application Load Balancer which resides in the public subnet.

4. The file included in the request is scanned with the API Agent and a verdict is rendered by the Agent.

5. Using the same channels, the Agent returns a JSON response via HTTPS with the decision on the file: Infected, Clean, etc.

6. (Optional) The API Agent can upload Clean files to the S3 bucket of your choice.

API Endpoint - Privately Accessible

Read more about our API Scanning here.