Getting started

Connecting AWS is two one-time, org-admin steps: link your compute environment (so we can provision worker nodes) and link an S3 bucket (where pipeline data lives). Both live in the Carolina Cloud console.

You’ll need an IAM user in your AWS account. You can use one key pair with all the permissions below, or two — one scoped to EC2 for compute, one scoped to S3 for the bucket. Either works; the console asks for creds in each step independently.

Step 1 — Link AWS (compute environment)

Admin → Link AWS. Enter your AWS access key ID, secret access key, and the region you want to run in.

When you submit, Carolina Cloud sets up everything needed to launch workers in that region — it finds or creates a VPC, subnet, security group, and machine image, and reads your EC2 vCPU quota. This takes up to ~30 seconds. Your credentials go straight to a secure keyring used only to provision your nodes; they are never stored in Carolina Cloud’s database.

If the credentials can’t reach EC2 in that region, you’ll get a clear error (e.g. “those credentials can’t access EC2 in us-east-1”) rather than a silent failure — fix the IAM permissions or pick a region your policy allows, and retry.

IAM permissions for compute

The simplest working setup attaches these AWS-managed policies to the IAM user:

• AmazonEC2FullAccess — provision and tear down worker instances, VPC/subnet/security-group, and the key pair.
• ServiceQuotasReadOnlyAccess — read your on-demand vCPU quota (shown on the card; used to size the pool). Optional — without it everything works, the quota just shows blank.

Note

These are broad for convenience. A tighter, least-privilege EC2 policy works too — the required actions are instance run/terminate/describe, and VPC/subnet/security-group/key-pair describe + create. Scope it down once you’ve confirmed it works.

Step 2 — Link an S3 bucket

Storage → Link an S3 bucket. Enter the bucket name, its region, and an AWS access key + secret that can read and write it.

Carolina Cloud write-probes the bucket immediately (a tiny test object is written and deleted), so you find out at link time — not mid-pipeline — if the key can’t write. On success the bucket appears as a storage card marked AWS S3 · BYO.

This bucket is yours: Carolina Cloud reads and writes your pipeline’s objects but never deletes the bucket. “Unlink” simply forgets it on our side; your bucket and its contents are untouched.

Tip

Put the bucket in the same region as your compute environment (Step 1). Same-region keeps task data movement free and fast, and avoids cross-AZ/region latency.

IAM permissions for the bucket

The key needs read/write on the bucket (the write-probe fails a read-only key on purpose). Either attach AmazonS3FullAccess, or a tight bucket-scoped policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
    "Resource": [
      "arn:aws:s3:::YOUR_BUCKET",
      "arn:aws:s3:::YOUR_BUCKET/*"
    ]
  }]
}

You’re set

Once both show connected, the AWS compute backend unlocks in the pipeline launcher. Head to Running a pipeline on AWS.