Recommendations for deploying BigFix on AWS

Usage and Config Platform
1

Does anyone have recommendations for deploying BigFix on AWS for ~500 endpoints? How much CPU/RAM/Disk should I use, assuming I’m using Windows Server 2016 with MSSQL? Are there any (recent) guides for doing this?

1 Like
2

If you have an existing on prem BigFix server, then you don’t actually need to deploy the root server into AWS, you can just put a relay there to connect to the AWS clients.

I’m not an AWS expert, but here are some considerations:

If you are setting up a new BigFix root server in AWS instead of on prem, then you really need faster networking and disks than normal. Not all AWS EC2 VMs can do the higher speed networking, but you are going to need it, especially if you end up having multiple VMs handle BigFix infrastructure duties, rather than all on a single VM. Also, the MSSQL db and the BigFix root server filldb folder will require fast SSD storage, meanwhile the rest of the BigFix root server application should have larger bulk storage.

There are BigFix Capacity and Performance planning docs here:

500 clients is small enough that it should run in AWS without problems, and potentially without Elastic Network Adapter, but it is still a good idea.

Also, it is technically possible, though sometimes a bit of a pain, to switch the type of EC2 VM in AWS as you grow, so you could start smaller and move up as needed.

Enabling Enhanced Networking in AWS

I have been meaning to make BigFix content to determine if ENA is available, enabled, and working or to enable it if available but not currently configured.

SSD Instance Store Volumes in AWS

  • SSD Instance Store Volumes - Windows
  • SSD Instance Store Volumes - Linux
    • The following instances offer non-volatile memory express (NVMe) solid state drives (SSD) instance store volumes: C5d, G4, I3, I3en, F1, M5ad, M5d, p3dn.24xlarge, R5ad, R5d, and z1d
    • The following instances support instance store volumes that use non-NVMe SSDs to deliver high random I/O performance: C3, G2, I2, M3, R3, and X1.
    • The following instances support SSD volumes with TRIM: C5d, F1, G4, I2, I3, I3en, M5ad, M5d, p3dn.24xlarge, R3, R5ad, R5d, and z1d.

The other option is to use EBS Provisioned IOPS SSD (io1) that should work on all EC2 instance types, but should have higher latency and lower performance than dedicated NVMEe volumes. This is probably what I would start with for MSSQL and FillDB and scale up from there if needed.

CPU Cores

For 500 endpoints, you probably only need 4 to 8 cores for a BigFix root server, but if you are going to run all of the main BigFix infrastructure on 1 VM like Web Reports, WebUI, etc… plus the MSSQL db, then I would probably lean more to 8 than 4 cores.

One major problem with AWS is you can’t select CPU cores independently from RAM, and generally running all that stuff on a single VM is going to take more RAM than CPU, in particular MSSQL is RAM hungry. One way to address this is looking at their memory optimized EC2 options: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/memory-optimized-instances.html

These are possible instance types to consider:

Instance type Default vCPUs Memory (GiB)
r4.xlarge 4 30.5
r4.2xlarge 8 61

These, or EC2 instance types with similar vCPUs and RAM seem like good possibilities as far as having CPU and RAM resources to run a BigFix root server, BUT the issue is, in AWS, these “smaller” VMs do not support the SSD Instance Store Volumes, or even EBS NVMe SSDs (need at least r5 for that)

Instance type Default vCPUs Memory (GiB)
r5.2xlarge 8 64

This seems like the ideal starting point for a typical all in 1 BigFix VM since r5.2xlarge supports Elastic Network Adapter and EBS NVMe SSDs (but NOT SSD Instance Store Volumes)

All that said, figuring out the lowest cost EC2 instance type with the correct set of features and specs is quite annoying. I would have to a deep dive on pricing to try to figure out what is most optimal in terms of cost when considering only vCPU and RAM, then go through each one from lowest cost and up until I’d find one that has the right set of features.

2 Likes
3

Never heard of the ENA thing. We just placed relays into AWS and will look into this. Thanks!

1 Like
4

an Elastic Network Adapter (ENA) would help a relay, but is less crucial for a relay, especially if there is a small number of devices connecting to it… that said, it would greatly speed up download distribution for actions.

1 Like