Amazon Web Services: CLI (aws)¶

Deploy the RTA with the aws ec2 CLI. Your engagement lead shares a UEFI-boot AMI with your AWS account; you look it up by owner and launch a fully configured instance in a single run-instances call.

Before you start

Review the Amazon Web Services overview. You'll need the AWS CLI configured with credentials for your account, the shared AMI ID and Sophos AWS account ID from your engagement lead, a key pair name, and the IDs of your target subnet and security group.

Quick deploy¶

Experienced operators: fill in the placeholders, launch, then read the activation code off the console screenshot. The step-by-step with explanations follows below.

# Launch (a new security group already allows all outbound by default; add none inbound)
aws ec2 run-instances \
  --image-id <SHARED_AMI_ID> \
  --instance-type t3a.large \
  --key-name <KEY_NAME> \
  --subnet-id <SUBNET_ID> \
  --security-group-ids <SG_ID> \
  --no-associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=Sophos-RTA}]' \
  --count 1 \
  --query 'Instances[0].[InstanceId,PrivateIpAddress]' --output table

# Read the one-time activation code off the console and send it to your engagement lead
aws ec2 get-console-screenshot --instance-id <INSTANCE_ID> \
  --query 'ImageData' --output text | base64 --decode > console.jpg

--instance-type must be Nitro (the AMI is UEFI-only); a Xen family (t2, m4, c3, c4, r3) fails to launch. On a public (internet-gateway) subnet, drop --no-associate-public-ip-address or the appliance has no outbound path.

1. Confirm the shared AMI¶

Your engagement lead provides the AMI ID directly. You can verify it is visible to your account with:

aws ec2 describe-images \
  --owners <SOPHOS_ACCOUNT_ID> \
  --image-ids <SHARED_AMI_ID> \
  --query 'Images[*].[ImageId,Name,BootMode]' \
  --output table

Replace <SOPHOS_ACCOUNT_ID> and <SHARED_AMI_ID> with the values provided by your engagement lead.

AMI not found?

If the command returns an empty list, check that your AWS CLI is configured for the correct region (--region <REGION> or AWS_DEFAULT_REGION). The shared AMI is only visible in the region it was shared into.

2. (Optional) Create a security group¶

If you don't already have an outbound-only security group, create one:

SG_ID=$(aws ec2 create-security-group \
  --group-name rta-outbound-only \
  --description "RTA appliance - outbound only" \
  --vpc-id <VPC_ID> \
  --query GroupId \
  --output text)

A new security group already allows all outbound traffic by default, which is exactly what the appliance needs, so there's nothing more to add. (Re-running authorize-security-group-egress for 0.0.0.0/0 would just fail with InvalidPermission.Duplicate.) Do not add any inbound rules: the appliance establishes an outbound VPN tunnel and requires no inbound connectivity.

3. Launch the instance¶

aws ec2 run-instances \
  --image-id <SHARED_AMI_ID> \
  --instance-type t3a.large \
  --key-name <KEY_NAME> \
  --subnet-id <SUBNET_ID> \
  --security-group-ids <SG_ID> \
  --no-associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=Sophos-RTA}]' \
  --count 1 \
  --query 'Instances[0].[InstanceId,PrivateIpAddress]' \
  --output table

Root volume size

The shared AMI already ships a 40 GB root volume, so you normally don't need a --block-device-mappings override at all. If you do resize it, match the mapping's DeviceName to the AMI's actual root device (from aws ec2 describe-images --image-ids <SHARED_AMI_ID> --query 'Images[0].RootDeviceName') or you'll attach a second volume instead of growing the root.

Replace the placeholders, all provided by your engagement lead unless noted:

Placeholder	Source
`<SHARED_AMI_ID>`	Engagement lead
`<KEY_NAME>`	Your existing EC2 key pair name
`<SUBNET_ID>`	Your private subnet with NAT gateway egress
`<SG_ID>`	Security group ID from step 2 (or an existing outbound-only group)

Nitro instance types only

The --instance-type must be a Nitro-based type. The RTA AMI uses UEFI boot mode and will fail to launch on Xen-based families (t2, m4, c3, c4, r3). The example uses t3a.large (2 vCPU / 8 GB, recommended). For heavier workloads use t3a.xlarge or m5a.xlarge (4 vCPU / 16 GB). The Intel t3/m5 equivalents are also Nitro and work fine; the a (AMD) variants are typically a bit cheaper.

--no-associate-public-ip-address requires --subnet-id

The --no-associate-public-ip-address flag works when specifying --subnet-id directly. If you instead use the --network-interfaces parameter, you must embed the public-IP setting there (AssociatePublicIpAddress=false) and omit --subnet-id and --security-group-ids from the top level.

Public (internet-gateway) subnets need a public IP

The example assumes a private subnet behind a NAT gateway. If your only option is a public subnet (one that routes via an internet gateway), drop --no-associate-public-ip-address: without a public IP, an internet-gateway subnet has no outbound path and the appliance can never register.

4. Wait for the instance to be running¶

aws ec2 wait instance-running --instance-ids <INSTANCE_ID>
echo "Instance is running"

Verify¶

# Get the private IP
aws ec2 describe-instances \
  --instance-ids <INSTANCE_ID> \
  --query 'Reservations[0].Instances[0].[InstanceId,PrivateIpAddress,PublicIpAddress,State.Name]' \
  --output table

Confirm:

State: running
PublicIpAddress: None
PrivateIpAddress: populated with your VPC address

The AMI is a generic image, so on first boot the appliance comes up in activation mode (see How delivery works on AWS).

Send us the activation code¶

You read the activation code off the console screenshot, no SSH required. Allow about a minute after launch for first boot, then capture the screenshot and open console.jpg:

aws ec2 get-console-screenshot \
  --instance-id <INSTANCE_ID> \
  --query 'ImageData' \
  --output text | base64 --decode > console.jpg

The console shows the Appliance Registration screen: a one-time activation code (for example 4 5 D C V Y) under the prompt "Provide this code to your Sophos staging team." You do not log in to the appliance to read it.

Send that activation code to your Sophos engagement lead so they can activate the appliance on the Sophos side. Once activated, the console switches from the registration screen to the appliance's live status dashboard, and no further action is needed on your end.

Registration needs outbound 443 to get.remotetesting.secureworks.com

Registration and activation use outbound TCP/443 (HTTPS) to get.remotetesting.secureworks.com, in addition to the OpenVPN tunnel to connect.remotetesting.secureworks.com covered under Network access below. Its IP addresses are not guaranteed to stay constant, so allowlist get.* by FQDN (not by IP). If that egress is blocked, the console shows a registration error ("ensure outbound HTTPS to get.remotetesting.secureworks.com") instead of an activation code.

If break-glass SSH is ever needed, your engagement lead provides the login account; SSH from a host inside the same VPC:

ssh <username>@<private-ip>

Network access¶

The appliance makes one connection to do its job: an outbound tunnel to the Sophos headend. Nothing inbound is ever required: you never open or forward any ports to the appliance.

Allow this outbound destination


Destination	`connect.remotetesting.secureworks.com`
IP addresses	`3.33.194.251` and `15.197.255.2` (static; these do not change)
Port / protocol	TCP 443, carrying OpenVPN (not HTTPS)
Direction	Outbound only

Allow egress on TCP/443 to that destination from the appliance's network. On a next-generation firewall or NAC-controlled network, an L3 "allow 443" rule is often not enough: Layer-7 application control, TLS/SSL decryption, or NAC can still drop the tunnel even when the port is open. See Connectivity troubleshooting for the exact firewall and NAC exceptions to request.

Troubleshooting¶

Deployed but something isn't right?

See this platform's troubleshooting guide for the most common issues here and how to fix them.