Check this page regularly as it will be updated frequently over the incoming months as the deployment of the software progresses and configuration changes.

This page summarises the information needed to access QPUs hosted on AWS Braket through Pawsey’s Quantum Hub Portal.

1 Overview
2 Using the Portal
3 Setonix-Q QPUs
4 Allocation
- 4.1 Usage
- 4.2 Accounting and Tracking Budget
5 Using QPUs
- 5.1 Using Braket SDK
- 5.2 Using AWS Braket Directly
- 5.3 Using AWS CLI
- 5.4 Braket from Setonix
6 Submitting and Tracking Quantum Tasks

Overview

The Quantum Hub portal is accessible from hub.quantum.pawsey.org.au (see Figure 1 for login screen).

This portal can be accessed with your Pawsey credentials. The first time you access this site, it will require you to setup MFA if you haven’t already done so.

Once you have logged in you will be taken to the hub (see Figures 2a, 2b for Hub access), where users are presented with a high-level overview of all the projects they are involved in, the budgets of those projects and the amount of budget they have consumed. A project dashboard has links to AWS regions and the QPUs hosted on AWS Braket accessible to those regions and budget details (see Figure 3 below for more details).

Figure 1. A Screenshot of the portal hub login.

Figure 2a. Hub dashboard providing high-level overview of all projects a user is part of. For each project, we list name, description along with access and the budget of the project.

Figure 2b. Hub dashboard for specific project. The page provides the access restrictions, AWS shortcuts to AWS Brakt to access QPUs in a specific region, details of the project such as users, and budget information (for more details see Figure 4.

Using the Portal

The portal is designed to facilitate access of QPUs and provide budget information related to QPU access. It is your principal start point for accessing QPUs using the AWS Shortcuts visible on a project’s dashboard and tracking the consumed and remaining budget related to using QPUs. For a guide on using the hub, please follow the tutorial below

Setonix-Q QPUs

The Quantum Hub portal provides access to AWS Braket hosted QPUs (see external AWS documentation for information on Braket and Figure 4 for view of AWS devices). The number and costs of each device can change without notice, though this is unlikely. A list of current devices and a screenshot of the view from AWS Braket is provided below.

Table 1. Devices on AWS Braket have different charging models and costs per shot. As of Oct 2025, devices are

Device	Number of Qubits	Type	SU cost of 100 shots (see below for calculation)	USD costs

Device	Number of Qubits	Type	SU cost of 100 shots (see below for calculation)	USD costs
IonQ Aria1, Aria2	25	Universal gate-model ion-trap QPU with error mitigation support	232	$0.30 / task + $0.03 / shot
IonQ Forte1, Forte1 Enterprise	36	Universal gate-model ion-trap QPU with error mitigation support	342	$0.30 / task + $0.08 / shot
IQM Garnet	20	Universal gate-model superconducting QPU	18	$0.30 / task + $0.00145 / shot
IQM Emerald	56	Universal gate-model superconducting QPU	19	$0.30 / task + $0.0016 / shot
QuEra Aquila	256	Analog neutral atom-based configurable QPU	52	$0.30 / task + $0.01 / shot
Rigetti Ankaa-3	82	Universal gate-model superconducting QPU	16	$0.30 / task + $0.0009 / shot

Figure 4. AWS Braket Devices.

For a full list of the available QPUs please see external AWS documetation.

QPU Availability

The availability of a given QPU can change without notice, even in the middle of running a quantum task so we recommend not running production workflows with strong uptime requirements on QPU resources. Though each vendor tries to provide significant availability through AWS Braket, QPUs can go down for maintenance, calibration or just be unavailable without notice. It is also important to realise that these QPUs are shared by all global users of AWS Braket, so even when a device is online, the queue may be significant.

Pawsey does not provide any guarantees of availability of any specific QPU to researchers.

Allocation

This quantum allocation (Setonix-Q Quantum) of Setonix-Q pilot is separate from the Setonix-Q Pilot classical computing allocation but is related to this allocation. Unlike other allocations on the CPU, GPU and Setonix-Q classical, which can be accessed via Origin or using CLI tools once you’ve logged into Setonix, the quantum budget is viable only through the Quantum Hub Portal (see Figure 3).

The quantum allocation of Setonix-Q pilot is itself subdivided into “Quantum” and “Classical” budgets. This is because there are specific costs associated with running an individual quantum task on a given QPU and costs that are associated with classical compute (such as storing results on AWS S3 storage, retrieving data from this storage, running jupyter notebooks on AWS instances, etc). Thus, there is some separation between these two types of costs.

The allocation on the hub is presented as a budget in USD rather than SU’s as seen in Origin for the classical computing allocation of Setonix-Q Pilot.

Figure 3. Breakdown of a project’s budget. There is the total budget, a quantum budget related to costs incurred running quantum tasks on QPUs and the classical budget costs with compute associated with running QPUs.

Quantum Allocation Unit

Another key difference is that the quantum allocation is presented in USD, rather than SU. We relate USD to SU based on classical computation, with each SU costing approximately 0.025$AUD. Thus 1 USD is equivalent to 62.5 SU. This is necessary due to how AWS charges for services.

Usage

The Setonix-Q Quantum component allocation (both the quantum and classical sub-budgets) is given on a yearly timescale. This is in contrast to the Setonix-Q Classical component, which follows the quarterly approach for other computing allocation schemes. Additionally, once this Setonix-Q Quantum budget is exhausted, no more jobs will run.

Exhausted allocation

If the total, quantum or classical budget is exhausted, the hub will revoke access for all users of a project. They will be unable to submit new quantum tasks, create new jupyter notebooks or AWS hybrid jobs. Although access is revoked, previously submitted jobs can be retrieved from the AWS S3 storage using the Braket API.

Take extra care managing your quantum budget.

User Level Allocation

This budget is also split between individual user allocations. Users have allocations based on the percent of the total budget, which can be 1-99%. The total % sum of all individuals must be >= 100% of the total budget. This ensures that individuals can have access to the entire allocation, similar to the Setonix-Q Classical component where every member of the project has equal access to the entire allocation. One can also set specific budgets for users so that a single user is not able to exhaust the entire budget.

Individual user allocations example

Users can have allocations of a percent of the total allocation, limiting their ability to consume the entire budget. Consider a project with 3 users, A, B, C.

A has an allocation of 99%
B has an allocation of 40%
C has an allocation of 70%

In this scenario, if 50% of the total budget is consumed and B consumed 40%, only user B will no longer have permission to submit any quantum tasks. Both A and C can still submit quantum tasks and consume more of the budget.

If B has consumed 40%, C 58%, then despite having access to all of the budget A will only be able to consume 2% of the budget before the total budget is exhausted and all users of the project are blocked from submitting quantum tasks.

Accounting and Tracking Budget

Budget information can be tracked at a high-level using the hub dashboard as seen in Figure 3. This provides a view of the total budget and how much has been consumed. It also provides a view of the individual level budgets and how much has been consumed and a more detail breakdown is available for PIs via AWS CloudWatch link on the Details tab of the dashboard (see Figures 4a, b).

Figure 4a. Allocation and consumption of individual allocations.

Figure 4b. Detailed cost break down of individual user allocations and quantum cost breakdown. In this example, historical consumption has been preserved to provide an example of device consumption, hence the mismatch between user consumption and device consumption.

Using QPUs

Quantum tasks are submitted to QPUs using AWS’s Braket SDK (see external Braket documetation for complete details). Although, there are several other ways of accessing QPUs through other Quantum Computing APIs, we strongly recommend only using AWS Braket to submit quantum tasks to QPUs. This Python-based API provides a given AWS profile the means of submitting quantum tasks to simulators and specific devices. For examples, we refer users to external documentation on the SDK and some useful online repositories.

Here we show running

Using Braket SDK

Here we present a minimal Python example of using the Braket SDK. This Python code would submit a job to a local simulator and print results.

Listing N. Example Python code using the Braket SDK API.

# Use Braket SDK Cost Tracking to estimate the cost to run this example
from braket.tracking import Tracker
t = Tracker().start()
# Use the devices. 
from braket.aws import AwsDevice
# AWS imports: Import Braket SDK modules
from braket.circuits import Circuit
from braket.circuits.observables import Z
from braket.devices import Devices, LocalSimulator

# set up device: Local Simulator
device = LocalSimulator()
# run circuit
result = device.run(some_circuit, shots=1000).result()
# get measurement shots
counts = result.measurement_counts
# print counts
print(counts)

This example just uses Braket SDK’s rather limited quantum computing simulator. If you would like to run a circuit on a QPU, you need to select the relevant device.

Listing N. Example Python code using the Braket SDK API and submitting a job to a QPU.

# the Rigetti device
from time import sleep
device = AwsDevice(Devices.Rigetti.Ankaa3) 
# submit circuit
quantum_task= device.run(some_circuit, shots=1000)

# get id and status of submitted task
quantum_task_id = quantum_task.id
print("Status of quantum task:", quantum_task.state())
# let's sleep till the task is completed
while quantum_task.state() != "COMPLETED":
  sleep(10)

# get results 
results = task_load.result()
# get all metadata of submitted quantum task
metadata = task_load.metadata()
# example for metadata
shots = metadata["shots"]
machine = metadata["deviceArn"]
# print example metadata
print(f"{shots} shots taken on machine {machine}.\n")
# get measurement counts
counts = results.measurement_counts
print("Measurement counts:", counts)

Using AWS Braket Directly

The most common way of accessing the AWS Braket QPUs is through Jupyter notebooks running on AWS as this will have set all the relevant permissions to access these QPUs. AWS has a large collection of online tutorials that use jupyter notebooks to learn how to code in braket. Below we will focus on how you might launch jupyter notebooks and access QPUs as shown in Figures 5a-c.

Figure 5a shows the Quantum Hub portal dashboard of a project. The AWS shortcuts provide quick access to the relevant AWS Braket landing zones where you can quickly go to the Notebook tab to create a small compute instance on AWS running a Juypter Hub with relevant permissions for accessing QPUs. Once you launch a notebook instance, it will spin up Jupyter where you can begin using Braket and other Quantum Computing APIs. In this environment, you can submit quantum tasks to AWS Braket hosted QPUs.

Figure 5a. Quantum Hub Portal project dashboard showing the AWS shortcuts.

Figure 5b. AWS Braket Landing Zone for Notebook access.

Figure 5c. AWS Braket launched Jupyter landing page. Here you can see there are already several collections of notebooks available.

For a walkthrough, please follow the video tutorial below.

Useful external pages

Using AWS CLI

Braket can also be accessed through any device with the appropriate profile. This AWS profile can be setup and logged into using the AWS CLI tool (see external page for overview). This tool can be installed locally (see this guide for installation instructions) and will be available on the Setonix-Q quantum partition module stack. With this tool you can log in to the profile by connecting to the portal, using the shortcuts to take you to the AWS Landing Zone and copy the relevant information for your profile associated with a specific project.

To get the relevant information, log into the access portal via https://d-97675dbf09.awsapps.com/start/#/. You will then be able to retrieve the relevant information by clicking on the relevant pawsey project account, your user account and copy the information in the pop-up window produced by clicking on the AWS Keys link as show in Figure 6a-c.

Figure 6a. AWS access portal page.

Screenshot 2025-10-24 at 10.13.12.v2.png

Figure 6b. Link to click for Access Keys.

Figure 6c. Example pop-up window with access key information.

If you have saved your information to the credentials file for instance, you will then be able to log in using the AWS CLI with the following commands.

export AWS_DEFAULT_REGION=us-east-1
export AWS_PROFILE=<your_profile>
echo "Logging into AWS ${AWS_PROFILE}" 
aws sso login --profile ${AWS_PROFILE}  --use-device-code

Once you have logged in, you will now be able to submit quantum tasks to braket directly from the device from which you logged in.

Braket from Setonix

Once logged in using the AWS CLI tool, you can run hybrid quantum-classical workflows where the computationally expensive classical component can run on the Setonix-Q quantum partition. For example, a simple job might be to submit a python script that runs some braket job and then once results are received and stored locally, run a classical job on Setonix. We provide an example below.

Terminal N. Example Python code using the Braket SDK API and submitting a job to a QPU.

salloc -p work -A <project-id> --ntasks=1 --cpus-per-task=8
# log in to aws 
aws sso login --profile ${AWS_PROFILE}  --use-device-code
# then run the python code that will submit a follow-up classical task
module load python/<version> py-braket/<version>
srun python3 myquantum_submission.py

Listing N. Example Python code using the Braket SDK API and submitting a job to a QPU.

from time import sleep
import os, sys, subprocess, shutil
from braket.tracking import Tracker
t = Tracker().start()
# Use the devices. 
from braket.aws import AwsDevice
# AWS imports: Import Braket SDK modules
from braket.circuits import Circuit
from braket.circuits.observables import Z
from braket.devices import Devices

# submit circuit
quantum_task= device.run(some_circuit, shots=1000)
# get id and status of submitted task
quantum_task_id = quantum_task.id
print("Status of quantum task:", quantum_task.state())
# let's sleep till the task is completed
while quantum_task.state() != "COMPLETED":
  sleep(10)
  
# get results 
results = task_load.result()
# get all metadata of submitted quantum task
metadata = task_load.metadata()

# save data 
with open(my_quantum_output, "w") as f:
  f.write(results)
  f.write(metadata)

# create a new sbatch script and submit
# grab the quantum oriented sbatch script and submit
sbatch_template : str = "work_partition.template.sbatch"
my_sbatch : str = "work_run.sbatch"
shutil.copy2(sbatch_template, my_sbatch)
# edit file as necessary, such as updating batch script with relevant slurm job id.
slurm_job_id=os.environ["SLURM_JOB_ID"]
slurm_node_id=os.environ["SLURM_NODELIST"]

# now submit file 
process = subprocess.run(
  ["sbatch", my_sbatch],
  capture_output=True,
  text=True,
)

# do some clean-up of quantum task now that new sbatch has been submitted.

Listing N. Example sbatch script running computational workflow

#!/bin/bash
#SBATCH -p work
#SBATCH -A <project-id>
#set the resources
#SBATCH --ntasks=<number_of_tasks> 
#SBATCH --afterok:<job_id>

# load relevant modules 
module load ...

#run executable 
srun <resources> <exec> <args>

#if want to run further python scripts, submit a task to node running the AWS CLI
sbatch -w <awscli_node_id> more_python.sbatch

The result will be a job that uses a small amount of cpu resources to run a job on AWS Braket and then runs a computational sbatch script. There are tools that can assist running hybrid workflows and variational workflows using Setonix compute resources.

QBitBridge

Pawsey has developed a workflow tool that can be run on workflow nodes or compute nodes called QBitBridge. This tool is designed to integrate Setonix with cloud hosted QPUs or virtual QPUs. The code is available as a module, which setups up the appropriate Python virtual environment and provides scripts relevant to run database services, run the Prefect job orchestration server so as to launch a hybrid workflow.

Examples of workflows can be found on https://pawseysc.github.io/vqpu-hybrid-workflow/.

Useful external pages

Submitting and Tracking Quantum Tasks

Documentation and tutorials can be found …

Quantum Hub: Portal Quick Start

Overview

Using the Portal

Setonix-Q QPUs

Device

Number of Qubits

SU cost of 100 shots (see below for calculation)

Device

Number of Qubits

SU cost of 100 shots (see below for calculation)

Allocation

Usage

User Level Allocation

Accounting and Tracking Budget

Using QPUs

Using Braket SDK

Listing N. Example Python code using the Braket SDK API.

Listing N. Example Python code using the Braket SDK API and submitting a job to a QPU.

Using AWS Braket Directly

Useful external pages

Using AWS CLI

Braket from Setonix

Terminal N. Example Python code using the Braket SDK API and submitting a job to a QPU.

Listing N. Example Python code using the Braket SDK API and submitting a job to a QPU.

Listing N. Example sbatch script running computational workflow

QBitBridge

Useful external pages

Submitting and Tracking Quantum Tasks