Amazon Web Services

AWS Deployment

Running ARROW on AWS means uploading a disk image, importing it as an EBS snapshot, registering that snapshot as an AMI, and launching instances from it. Your AWS build downloads as a ZIP containing the disk image and arrow-deploy, a single tool that does all of it.

VM credentials

Credentials are generated per VM during the build and are never included in the download. Retrieve them from the ARROW Portal on your device’s details page.

---

What is in the download

File	What it is
*.vmdk	The disk image, stream-optimized, around 23 GB
arrow-deploy-linux-amd64	The deploy tool for Linux
arrow-deploy-darwin-arm64	The deploy tool for macOS (Apple silicon)
arrow-deploy-windows-amd64.exe	The deploy tool for Windows
*-deployment.txt	A summary of this build and the manual commands
DEPLOY-README.txt	Quick reference
import-to-aws.sh, Import-To-AWS.ps1	The previous scripts, still included during the transition

---

Prerequisites

You need the AWS CLI, credentials (aws configure), and a default region. Two further things are required once per account, and arrow-deploy offers to create both:

• An S3 bucket to stage the disk image during import.
• The vmimport IAM role. AWS VM Import/Export assumes this role to read your bucket and register the AMI. It is account-wide and AWS will not import anything without it.

Check everything before you start

doctor verifies your prerequisites and creates nothing:

chmod +x arrow-deploy-linux-amd64
./arrow-deploy-linux-amd64 doctor --cloud aws

If the vmimport role is missing, doctor says so and import offers to create it for you, with a policy scoped to just your staging bucket.

---

Deploy

Step 1: Import the disk image

./arrow-deploy-linux-amd64 import \
  --cloud aws \
  --image kali-arrow-yourclient-aws.vmdk \
  --image-name arrow-kali

With no --bucket, the tool lists your buckets to choose from, and offers to create one if you have none. It then uploads the image, imports it as an EBS snapshot, and registers an AMI. The AMI id is printed at the end.

The snapshot import is the slow part and runs entirely inside AWS. Expect it to take longer than the upload.

Why a snapshot import rather than an image import

ARROW images use a custom kernel. import-image inspects the guest operating system and rejects it, while import-snapshot treats the disk as opaque blocks and lets the AMI registration describe it instead. That is why these images register with legacy-bios boot mode and a /dev/sda1 root device.

Step 2: Launch an instance

./arrow-deploy-linux-amd64 launch \
  --cloud aws \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --vm-name arrow-kali-01 \
  --size t3.xlarge \
  --ssh-key my-key-pair

The tool offers an instance type and one of your EC2 key pairs if you do not pass them, and prints the instance’s public address when it is ready.

Step 3: Sign in

The instance has two separate accounts, reached by different means.

Account	How you get in	Password
kali	Your EC2 key pair	No password; key only
arrow	Password	Unique to this VM, shown in the ARROW Portal

Your key pair is injected by cloud-init into the distribution’s default user, which is kali on a Kali image. It is not injected into the arrow account.

ssh -i my-key.pem kali@<instance-address>

The arrow account is for console access and manual configuration using the password from the Portal. Most of the time you do not need to sign in at all, because the instance connects back to ARROW on its own as soon as it has network access.

The instance needs a security group that allows SSH

Without one, AWS attaches your VPC’s default security group, which permits traffic only from itself. The instance launches and reports a public address but refuses every connection.

arrow-deploy offers to create a group allowing SSH from your current address only. To use your own, pass --security-group sg-xxxxxxxx.

---

The instance keeps its ARROW name

A deployed instance’s hostname is the name shown on its device record in the ARROW Portal, not the EC2 instance name or tag. This is deliberate, because the Portal name is the identity your team works with, so the image keeps it.

---

Removing what you created

cleanup reports what it would remove and deletes nothing until you add --yes:

./arrow-deploy-linux-amd64 cleanup --cloud aws
./arrow-deploy-linux-amd64 cleanup --cloud aws --yes

It terminates instances, deregisters AMIs, and deletes the EBS snapshots behind them. Only resources it created are touched, identified by its own tag; narrow it further with --name-prefix.

Deregistering an AMI by hand leaves its snapshot behind

If you remove images through the AWS console instead, deregistering an AMI does not delete the EBS snapshot it was built on. A 120 GB snapshot per import will keep billing until you delete it explicitly. arrow-deploy cleanup handles this for you.

The staged copy of your disk image in S3 is deleted automatically once the import succeeds, since AWS has copied it into the snapshot by then.

---

Command reference

Commands

Command	What it does
doctor	Checks prerequisites, creates nothing
import	Uploads the image, imports a snapshot, registers an AMI
launch	Creates an EC2 instance from an AMI
cleanup	Removes instances, AMIs and their snapshots
version	Prints the version

Flags used with AWS

Flag	Applies to	Meaning
--cloud aws	all	Target cloud, always required
--image	import	Path to the .vmdk
--image-name	import	Name to register the AMI under
--bucket	import	S3 bucket used to stage the upload
--image-id	launch	The AMI id that import printed
--vm-name	launch	Name tag for the instance
--size	launch	Instance type, for example t3.xlarge
--ssh-key	launch	Name of an EC2 key pair in your account
--security-group	launch	Existing security group to attach
--subnet	launch	Subnet to launch into
--name-prefix	cleanup	Restrict cleanup to matching names
--yes	cleanup	Actually delete; without it cleanup only reports

Flags available everywhere

Flag	Meaning
--dry-run	Report what would happen without changing anything
--json	Machine-readable output, for scripting
--non-interactive	Never prompt; every value must be supplied as a flag
--no-color	Disable coloured output. NO_COLOR is also honoured

Under --non-interactive the tool creates no IAM role and no security group. It prints the exact commands to run instead.

---

Recommended instance types

Type	vCPU / RAM	Use
t3.large	2 / 8 GB	Minimum
t3.xlarge	4 / 16 GB	Recommended for most work
m5.2xlarge	8 / 32 GB	Heavier workloads

---

Troubleshooting

doctor reports the vmimport role missing. Run arrow-deploy import --cloud aws and accept when it offers to create it, or create it yourself following the AWS VM Import permissions guide.

doctor reports no usable credentials. Run aws configure, and set a default region while you are there.

The instance is running but SSH times out. Its security group almost certainly does not allow inbound SSH from your address. Attach one that does, or let arrow-deploy launch create one.

SSH is refused with “Permission denied (publickey)”. Check which user you are signing in as. The key pair goes to the distribution’s default user, kali on a Kali image, not to arrow.

The import fails with a disk format error. ARROW builds a stream-optimized VMDK, which is what VM Import requires. Re-download the artifact if it may have been altered or truncated in transit.

A snapshot is still billing after cleaning up in the console. Deregistering an AMI does not delete its snapshot. Delete it explicitly, or use arrow-deploy cleanup --yes, which does both.

---

Previous deploy scripts

import-to-aws.sh and Import-To-AWS.ps1 are still included in the download and still work:

chmod +x import-to-aws.sh
./import-to-aws.sh                    # import the VMDK
./import-to-aws.sh --launch           # launch from an existing ARROW AMI
./import-to-aws.sh --cleanup          # remove ARROW resources

New deployments should use arrow-deploy. It is the same flow on every platform, it supports --dry-run and --json, it removes the snapshot and staged object that the scripts leave behind, and it rolls back what it created if something fails partway.