Amazon Braket supported devices
In Amazon Braket, a device represents a QPU or simulator that you can call to run quantum
tasks. Amazon Braket provides access to QPU devices from IonQ, Oxford
Quantum Circuits, QuEra, and Rigetti, three ondemand
simulators, three local simulators, and one embedded simulator. For all devices, you can find
further device properties, such as device topology, calibration data, and native gate sets, on
the Devices tab of the Amazon Braket console or by means of
the GetDevice
API. When constructing a circuit with the simulators, Amazon Braket
currently requires that you use contiguous qubits or indices. If you are working with the
Amazon Braket SDK, you have access to device properties as shown in the following code
example.
from braket.aws import AwsDevice from braket.devices import LocalSimulator device = AwsDevice('arn:aws:braket:::device/quantumsimulator/amazon/sv1') #SV1 # device = LocalSimulator() #Local State Vector Simulator # device = LocalSimulator("default") #Local State Vector Simulator # device = LocalSimulator(backend="default") #Local State Vector Simulator # device = LocalSimulator(backend="braket_sv") #Local State Vector Simulator # device = LocalSimulator(backend="braket_dm") #Local Density Matrix Simulator # device = LocalSimulator(backend="braket_ahs") #Local Analog Hamiltonian Simulation # device = AwsDevice('arn:aws:braket:::device/quantumsimulator/amazon/tn1') #TN1 # device = AwsDevice('arn:aws:braket:::device/quantumsimulator/amazon/dm1') #DM1 # device = AwsDevice('arn:aws:braket:useast1::device/qpu/ionq/Harmony') #IonQ # device = AwsDevice('arn:aws:braket:useast1::device/qpu/ionq/Aria1') #IonQ # device = AwsDevice('arn:aws:braket:useast1::device/qpu/ionq/Aria2') #IonQ # device = AwsDevice('arn:aws:braket:useast1::device/qpu/ionq/Forte1') #IonQ # device = AwsDevice('arn:aws:braket:uswest1::device/qpu/rigetti/AspenM3') #Rigetti AspenM3 # device = AwsDevice('arn:aws:braket:euwest2::device/qpu/oqc/Lucy') #OQC Lucy # device = AwsDevice('arn:aws:braket:useast1::device/qpu/quera/Aquila') #QuEra Aquila # get device properties device.properties
Supported quantum hardware providers
Supported simulators
Choose the best simulator for your quantum task
Note
To view the available AWS Regions for each device, scroll right across the following table.
Amazon Braket devices  

Provider  Device Name  Paradigm  Type  Device ARN  Region  
IonQ 
Aria 1 
gatebased 
QPU 
arn:aws:braket:useast1::device/qpu/ionq/Aria1 
useast1 

IonQ 
Aria 2 
gatebased 
QPU 
arn:aws:braket:useast1::device/qpu/ionq/Aria2 
useast1 

IonQ 
Forte 1 
gatebased 
QPU (reservationonly) 
arn:aws:braket:useast1::device/qpu/ionq/Forte 
useast1 

IonQ 
Harmony 
gatebased 
QPU 
arn:aws:braket:useast1::device/qpu/ionq/Harmony 
useast1 

Oxford Quantum Circuits 
Lucy 
gatebased 
QPU 
arn:aws:braket:euwest2::device/qpu/oqc/Lucy 
euwest2 

QuEra 
Aquila 
Analog Hamiltonian Simulation 
QPU 
arn:aws:braket:useast1::device/qpu/quera/Aquila 
useast1 

Rigetti 
Aspen M3 
gatebased 
QPU 
arn:aws:braket:uswest1::device/qpu/rigetti/AspenM3 
uswest1 

AWS 
braket_sv 
gatebased 
Local simulator 
N/A (local simulator in Braket SDK) 
N/A 

AWS 
braket_dm 
gatebased 
Local simulator 
N/A (local simulator in Braket SDK) 
N/A 

AWS 
SV1 
gatebased 
Ondemand simulator 
arn:aws:braket:::device/quantumsimulator/amazon/sv1 
All Regions where Amazon Braket is available. 

AWS 
DM1 
gatebased 
Ondemand simulator 
arn:aws:braket:::device/quantumsimulator/amazon/dm1 
All Regions where Amazon Braket is available. 

AWS 
TN1 
gatebased 
Ondemand simulator 
arn:aws:braket:::device/quantumsimulator/amazon/tn1 
uswest2, useast1, and euwest2 
Note
Certain QPUs can only be accessed using reservations via Braket Direct, see Reservations.
To view additional details about the QPUs you can use with Amazon Braket,
see Amazon Braket Hardware
Providers
IonQ
IonQ offers gatebased QPUs based on ion trap technology. IonQ’s trapped ion QPUs are built on a chain of trapped 171Yb+ ions that are spatially confined by means of a microfabricated surface electrode trap within a vacuum chamber.
IonQ devices support the following quantum gates.
'x', 'y', 'z', 'rx', 'ry', 'rz', 'h', 'cnot', 's', 'si', 't', 'ti', 'v', 'vi', 'xx', 'yy', 'zz', 'swap'
With verbatim compilation, the IonQ QPUs support the following native gates.
'gpi', 'gpi2', 'ms'
If you only specify two phase parameters when using the native MS gate, a fully
entangling MS gate runs. A fullyentangling MS gate always performs a π/2 rotation. To
specify a different angle and run a partiallyentangling MS gate, you specify the desired
angle by adding a third parameter. For more information, see the braket.circuits.gate module
These native gates can only be used with verbatim compilation. To learn more about verbatim compilation, see Verbatim Compilation.
Rigetti
Rigetti quantum processors are universal, gatemodel machines based on alltunable superconducting qubits. The 79qubit AspenM3 device leverages their proprietary multichip technology and is assembled from 2 40qubit processors.
The Rigetti device supports the following quantum gates.
'cz', 'xy', 'ccnot', 'cnot', 'cphaseshift', 'cphaseshift00', 'cphaseshift01', 'cphaseshift10', 'cswap', 'h', 'i', 'iswap', 'phaseshift', 'pswap', 'rx', 'ry', 'rz', 's', 'si', 'swap', 't', 'ti', 'x', 'y', 'z'
With verbatim compilation, the Rigetti devices support the following native gates.
'rx', 'rz', 'cz', 'cphaseshift', 'xy'
Rigetti superconducting quantum processors can run the 'rx' gate with only the angles of ±π/2 or ±π.
Pulselevel control is available on the Rigetti devices, which support a set of predefined frames of the following types:
'rf', 'rf_f12', 'ro_rx', 'ro_rx', 'cz', 'cphase', 'xy'
For more information about these frames, see Roles of frames and ports.
Oxford Quantum Circuits (OQC)
OQC quantum processors are universal, gatemodel machines, built using scalable Coaxmon technology. The OQC Lucy system is an 8qubit device with the topology of a ring in which each qubit is connected to its two nearest neighbors.
The Lucy device supports the following quantum gates.
'ccnot', 'cnot', 'cphaseshift', 'cswap', 'cy', 'cz', 'h', 'i', 'phaseshift', 'rx', 'ry', 'rz', 's', 'si', 'swap', 't', 'ti', 'v', 'vi', 'x', 'y', 'z', 'ecr'
With verbatim compilation, the OQC device supports the following native gates.
'i', 'rz', 'v', 'x', 'ecr'
Pulselevel control is available on the OQC devices. The OQC devices support a set of predefined frames of the following types:
'drive', 'second_state', 'measure', 'acquire', 'cross_resonance', 'cross_resonance_cancellation'
OQC devices support dynamic declaration of frames provided that you supply a valid port identifier. For more information about these frames and ports, see Roles of frames and ports.
Note
When using pulse control with OQC, the length of your programs cannot exceed a maximum of 90 microseconds. The maximum duration is approximately 50 nanoseconds for singlequbit gates and 1 microsecond for twoqubit gates. These numbers may vary depending on the qubits used, the device’s current calibration, and the circuit compilation.
QuEra
QuEra offers neutralatom based devices that can run Analog Hamiltonian Simulation (AHS) quantum tasks. These specialpurpose devices faithfully reproduce the timedependent quantum dynamics of hundreds of simultaneously interacting qubits.
One can program these devices in the paradigm of Analog Hamiltonian Simulation by
prescribing the layout of the qubit register and the temporal and spatial dependence of the
manipulating fields. Amazon Braket provides utilities to construct such programs via the AHS
module of the python SDK, braket.ahs
.
For more information, see the Analog Hamiltonian Simulation example notebooks
Local state vector simulator
(braket_sv
)
The local state vector simulator (braket_sv
) is part of the
Amazon Braket SDK that runs locally in your environment. It is
wellsuited for rapid prototyping on small circuits (up to 25 qubits)
depending on the hardware specifications of your Braket notebook instance or your local
environment.
The local simulator supports all gates in the Amazon Braket SDK, but QPU devices support a smaller subset. You can find the supported gates of a device in the device properties.
Note
The local simulator supports advanced OpenQASM features which may not be supported on
QPU devices or other simulators. For more information on supported features, see the
examples provided in the OpenQASM Local Simulator notebook
For more information about how to work with simulators, see the Amazon Braket examples
Local density matrix simulator
(braket_dm
)
The local density matrix simulator (braket_dm
) is part of the
Amazon Braket SDK that runs locally in your environment. It is
wellsuited for rapid prototyping on small circuits with noise (up to 12
qubits) depending on the hardware specifications of your Braket
notebook instance or your local environment.
You can build common noisy circuits from the ground up using gate noise operations such as bitflip and depolarizing error. You can also apply noise operations to specific qubits and gates of existing circuits that are intended to run both with and without noise.
The braket_dm
local simulator can provide the following results, given the
specified number of shots:

Reduced density matrix: Shots = 0
Note
The local simulator supports advanced OpenQASM features, which may not be supported
on QPU devices or other simulators. For more information about supported features, see
the examples provided in the OpenQASM Local Simulator notebook
To learn more about the local density matrix simulator, see the Braket introductory noise simulator example
Local AHS simulator
(braket_ahs
)
The local AHS (Analog Hamiltonian Simulation) simulator (braket_ahs
) is
part of the Amazon Braket SDK that runs locally in your environment. It can be used to
simulate results from an AHS program. It is wellsuited for prototyping on small registers
(up to 1012 atoms) depending on the hardware specifications of your Braket notebook
instance or your local environment.
The local simulator supports AHS programs with one uniform driving field, one
(nonuniform) shifting field, and arbitrary atom arrangements. For details, please refer to
the Braket AHS class
To learn more about the local AHS simulator, see the Hello AHS: Run your first Analog Hamiltonian
Simulation page and the Analog Hamiltonian Simulation example notebooks
State vector simulator (SV1)
SV1 is an ondemand, highperformance, universal state vector simulator. It can simulate circuits of up to 34 qubits. You can expect a 34qubit, dense, and square circuit (circuit depth = 34) to take approximately 1–2 hours to complete, depending on the type of gates used and other factors. Circuits with alltoall gates are well suited for SV1. It returns results in forms such as a full state vector or an array of amplitudes.
SV1 has a maximum runtime of 6 hours. It has a default of 35 concurrent quantum tasks, and a maximum of 100 (50 in uswest1 and euwest2) concurrent quantum tasks.
SV1 results
SV1 can provide the following results, given the specified number of shots:

Sample: Shots > 0

Expectation: Shots >= 0

Variance: Shots >= 0

Probability: Shots > 0

Amplitude: Shots = 0

Adjoint Gradient: Shots = 0
For more about results, see Result types.
SV1 is always available, it runs your circuits on demand, and it can run multiple circuits in parallel. The runtime scales linearly with the number of operations and exponentially with the number of qubits. The number of shots has a small impact on the runtime. To learn more, visit Compare simulators.
Simulators support all gates in the Braket SDK, but QPU devices support a smaller subset. You can find the supported gates of a device in the device properties.
Density matrix simulator (DM1)
DM1 is an ondemand, highperformance, density matrix simulator. It can simulate circuits of up to 17 qubits.
DM1 has a maximum runtime of 6 hours, a default of 35 concurrent quantum tasks, and a maximum of 50 concurrent quantum tasks.
DM1 results
DM1 can provide the following results, given the specified number of shots:

Sample: Shots > 0

Expectation: Shots >= 0

Variance: Shots >= 0

Probability: Shots > 0

Reduced density matrix: Shots = 0, up to max 8 qubits
For more information about results, see Result types.
DM1 is always available, it runs your circuits on demand, and it can run multiple circuits in parallel. The runtime scales linearly with the number of operations and exponentially with the number of qubits. The number of shots has a small impact on the runtime. To learn more, see Compare simulators.
Noise gates and limitations
AmplitudeDamping Probability has to be within [0,1] BitFlip Probability has to be within [0,0.5] Depolarizing Probability has to be within [0,0.75] GeneralizedAmplitudeDamping Probability has to be within [0,1] PauliChannel The sum of the probabilities has to be within [0,1] Kraus At most 2 qubits At most 4 (16) Kraus matrices for 1 (2) qubit PhaseDamping Probability has to be within [0,1] PhaseFlip Probability has to be within [0,0.5] TwoQubitDephasing Probability has to be within [0,0.75] TwoQubitDepolarizing Probability has to be within [0,0.9375]
Tensor network simulator (TN1)
TN1 is an ondemand, highperformance, tensor network simulator. TN1 can simulate certain circuit types with up to 50 qubits and a circuit depth of 1,000 or smaller. TN1 is particularly powerful for sparse circuits, circuits with local gates, and other circuits with special structure, such as quantum Fourier transform (QFT) circuits. TN1 operates in two phases. First, the rehearsal phase attempts to identify an efficient computational path for your circuit, so TN1 can estimate the runtime of the next stage, which is called the contraction phase. If the estimated contraction time exceeds the TN1 simulation runtime limit, TN1 does not attempt contraction.
TN1 has a runtime limit of 6 hours. It is limited to a maximum of 10 (5 in euwest2) concurrent quantum tasks.
TN1 results
The contraction phase consists of a series of matrix multiplications. The series of multiplications continues until a result is reached or until it is determined that a result cannot be reached.
Note: Shots must be > 0.
Result types include:

Sample

Expectation

Variance
For more about results, see Result types.
TN1 is always available, it runs your circuits on demand, and it can run multiple circuits in parallel. To learn more, see Compare simulators.
Simulators support all gates in the Braket SDK, but QPU devices support a smaller subset. You can find the supported gates of a device in the device properties.
Visit the Amazon Braket GitHub repository for a TN1 example notebook
Best practices for working with TN1

Avoid alltoall circuits.

Test a new circuit or class of circuits with a small number of shots, to learn the circuit’s "hardness" for TN1.

Split large shot simulations over multiple quantum tasks.
Embedded simulators
Embedded simulators work by having the simulation embedded with the algorithm code in the same container and executing the simulation on the hybrid job instance directly. This can be useful for removing bottlenecks associated with having the simulation communicate with a remote device. This can result in significantly lower memory usage, reduced number of circuit executions to achieve a desired result, and an improved performance of ten times or more. For more information about embedded simulators, see the Run a hybrid job with Amazon Braket Hybrid Jobs page.
PennyLane’s lightning simulators
You can use PennyLane’s lightning simulators as embedded simulators on Braket. With
PennyLane’s lightning simulators, you can leverage advanced gradient computation
methods, such as adjoint differentiation
Compare simulators
This section helps you select the Amazon Braket simulator that’s best suited for your quantum task, by describing some concepts, limitations, and use cases.
Choosing between local simulators and ondemand simulators (SV1, TN1, DM1)
The performance of local simulators depends on the hardware that hosts the local environment, such as a Braket notebook instance, used to run your simulator. Ondemand simulators run in the AWS cloud and are designed to scale beyond typical local environments. Ondemand simulators are optimized for larger circuits, but add some latency overhead per quantum task or batch of quantum tasks. This can imply a tradeoff if many quantum tasks are involved. Given these general performance characteristics, the following guidance can help you choose how to run simulations, including ones with noise.
For simulations:

When employing fewer than 18 qubits, use a local simulator.

When employing 18–24 qubits, choose a simulator based on the workload.

When employing more than 24 qubits, use an ondemand simulator.
For noise simulations:

When employing fewer than 9 qubits, use a local simulator.

When employing 9–12 qubits, choose a simulator based on the workload.

When employing more than 12 qubits, use DM1.
What is a state vector simulator?
SV1 is a universal state vector simulator. It stores the full wave function of the quantum state and sequentially applies gate operations to the state. It stores all possibilities, even the extremely unlikely ones. The SV1 simulator’s run time for a quantum task increases linearly with the number of gates in the circuit.
What is a density matrix simulator?
DM1 simulates quantum circuits with noise. It stores the full density matrix of the system and sequentially applies the gates and noise operations of the circuit. The final density matrix contains complete information about the quantum state after the circuit runs. The runtime generally scales linearly with the number of operations and exponentially with the number of qubits.
What is a tensor network simulator?
TN1 encodes quantum circuits into a structured graph.

The nodes of the graph consist of quantum gates, or qubits.

The edges of the graph represent connections between gates.
As a result of this structure, TN1 can find simulated solutions for relatively large and complex quantum circuits.
TN1 requires two phases
Typically, TN1 operates in a twophase approach to simulating quantum computation.

The rehearsal phase: In this phase, TN1 comes up with a way to traverse the graph in an efficient manner, which involves visiting every node so that you can obtain the measurement you desire. As a customer, you do not see this phase because TN1 performs both phases together for you. It completes the first phase and determines whether to perform the second phase on its own based on practical constraints. You have no input into that decision after the simulation has begun.

The contraction phase: This phase is analogous to the execution phase of a computation in a classical computer. The phase consists of a series of matrix multiplications. The order of these multiplications has a great effect on the difficulty of the computation. Therefore, the rehearsal phase is accomplished first in order to find the most effective computation paths across the graph. After it finds the contraction path during the rehearsal phase, TN1 contracts together the gates of your circuit to produce the results of the simulation.
TN1 graphs are analogous to a map
Metaphorically, you can compare the underlying TN1 graph to the streets of a city. In a city with a planned grid, it is easy to find a route to your destination using a map. In a city with unplanned streets, duplicate street names, and so forth, it can be difficult to find a route to your destination by looking at a map.
If TN1 did not perform the rehearsal phase, it would be like walking around the streets of the city to find your destination, instead of looking at a map first. It can really pay off in terms of walking time to spend more time looking at the map. Similarly, the rehearsal phase provides valuable information.
You might say that the TN1 has a certain “awareness” of the structure of the underlying circuit that it traverses. It gains this awareness during the rehearsal phase.
Types of problems best suited for each of these types of simulators
SV1 is wellsuited for any class of problems that rely primarily on having a certain number of qubits and gates. Generally, the time required grows linearly with the number of gates, while it does not depend on the number of shots. SV1 is generally faster than TN1 for circuits under 28 qubits.
SV1 can be slower for higher qubit numbers because it actually simulates all possibilities, even the extremely unlikely ones. It has no way to determine which outcomes are likely. Thus, for a 30qubit evaluation, SV1 must calculate 2^30 configurations. The limit of 34 qubits for the Amazon Braket SV1 simulator is a practical constraint due to memory and storage limitations. You can think of it like this: Each time you add a qubit to SV1, the problem becomes twice as hard.
For many classes of problems, TN1 can evaluate much larger circuits in realistic time than SV1 because TN1 takes advantage of the structure of the graph. It essentially tracks the evolution of solutions from its starting place and it retains only the configurations that contribute to an efficient traversal. Put another way, it saves the configurations to create an ordering of matrix multiplication that results in a simpler evaluation process.
For TN1, the number of qubits and gates matters, but the structure of the graph matters a lot more. For example, TN1 is very good at evaluating circuits (graphs) in which the gates are shortrange (that is, each qubit is connected by gates only to its nearest neighbour qubits), and circuits (graphs) in which the connections (or gates) have similar range. A typical range for TN1 is having each qubit talk only to other qubits that are 5 qubits away. If most of the structure can be decomposed into simpler relationships such as these, which can be represented in more, smaller, or more uniform matrices, TN1 performs the evaluation easily.
Limitations of TN1
TN1 can be slower than SV1 depending on the graph’s
structural complexity. For certain graphs, TN1 terminates the simulation
after the rehearsal stage, and shows a status of FAILED
, for either of these
two reasons:

Cannot find a path — If the graph is too complex, it is too difficult to find a good traversal path and the simulator gives up on the computation. TN1 cannot perform the contraction. You may see an error message similar to this one:
No viable contraction path found.

Contraction stage is too difficult — In some graphs, TN1 can find a traversal path, but it is very long and extremely timeconsuming to evaluate. In this case, the contraction is so expensive that the cost would be prohibitive and instead, TN1 exits after the rehearsal phase. You may see an error message similar to this one:
Predicted runtime based on best contraction path found exceeds TN1 limit.
Note
You are billed for the rehearsal stage of TN1 even if contraction is
not performed and you see a FAILED
status.
The predicted runtime also depends on the shot count. In worstcase scenarios, TN1 contraction time depends linearly on the shot count. The circuit may be contractable with fewer shots. For example, you might submit a quantum task with 100 shots, which TN1 decides is uncontractable, but if you resubmit with only 10, the contraction proceeds. In this situation, to attain 100 samples, you could submit 10 quantum tasks of 10 shots for the same circuit and combine the results in the end.
As a best practice, we recommend that you always test your circuit or circuit class with a few shots (for example, 10) to find out how hard your circuit is for TN1, before you proceed with a higher number of shots.
Note
The series of multiplications that forms the contraction phase begins with small, NxN matrices. For example, a 2qubit gate requires a 4x4 matrix. The intermediate matrices required during a contraction that is adjudged to be too difficult are gigantic. Such a computation would require days to complete. That’s why Amazon Braket does not attempt extremely complex contractions.
Concurrency
All Braket simulators give you the ability to run multiple circuits concurrently. Concurrency limits vary by simulator and region. For more information on concurrency limits, see the Quotas page.