Amazon Web Services — AWS CLI¶

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.

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 t3.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=rta-engagement-01}]' \
  --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 want to resize the root volume, the mapping's DeviceName must match the AMI's actual root device or you'll attach a second volume instead of resizing the root. Read it first:

aws ec2 describe-images --image-ids <SHARED_AMI_ID> \
  --query 'Images[0].RootDeviceName' --output text

Then pass that exact name, e.g. --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":40,"VolumeType":"gp3"}}]'.

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/IGW 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 t3.large (2 vCPU / 8 GB — recommended). For heavier workloads use t3.xlarge or m5.xlarge (4 vCPU / 16 GB).

--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.

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 and shows an Appliance Registration screen with a one-time activation code — you normally don't need to log in at all. SSH from a host inside the same VPC if needed:

ssh swag@<private-ip>

Read the activation code from the console

To read the activation code without SSH, capture the EC2 instance screenshot and look for the Appliance Registration screen; give the code to your Sophos engagement lead to activate the appliance:

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

Open console.jpg to view the current console state. For interactive console access, enable and use the EC2 Serial Console (Nitro instances only):

aws ec2-instance-connect send-serial-console-ssh-public-key \
  --instance-id <INSTANCE_ID> \
  --serial-port 0 \
  --ssh-public-key file://~/.ssh/your_key.pub

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 Amazon Web Services troubleshooting for the most common issues on this platform and how to fix them.