Grover's algorithm on Amazon Braket, and what one search actually costs

Grover's algorithm is the cleanest illustration I know of why quantum computing is different. Suppose you have an unstructured search problem. There is a function that says yes for exactly one input out of a large number and no for all the rest, and you have no clever index to exploit. Working classically, you check the candidates one at a time, which takes about half the total number of guesses on average. Grover's method finds the marked item in roughly the square root of that number of steps. For a space of four answers this means a single step, and on an ideal machine it lands on the correct answer with certainty. The original result was published by Lov Grover in 1996, in a paper titled A fast quantum mechanical algorithm for database search, and it remains one of the most approachable entry points into the field.

That last phrase, on an ideal machine, is where honesty enters. The quantum-on-braket repository lets you run the very same circuit two ways, on a perfect local simulator and on a real quantum processor, and the difference between those two runs is the whole point of this article.

One interface, a fleet of real machines

What makes this practical today is that Amazon Braket has turned the act of reaching a quantum computer into an ordinary service call against a menu of real hardware. From one software library you can target trapped ion machines from IonQ, superconducting machines from IQM and Rigetti, and neutral atom machines from QuEra and AQT. The same library also understands the common community frameworks, so you are not locked into a single dialect.

The hardware on offer keeps growing. On the seventh of April 2026, Amazon added Rigetti's Cepheus 1 108Q to Braket, the first gate based device with more than one hundred qubits available on the service. It is built from twelve interconnected nine qubit chiplets tiled into a single processor, it was performing at a median two qubit gate fidelity of about ninety nine percent at launch, and it replaced the earlier Ankaa 3 system. Notably, it uses a controlled Z operation as its native two qubit gate, which is exactly the operation our small Grover circuit leans on.

For anyone learning, the most important detail is that the local state vector simulator is free. You develop and debug at no cost, and you pay only when you deliberately reach for real silicon. The repository defaults to the simulator and puts a spending guard in front of every hardware call, which I will come back to.

A warm up, entanglement in two lines

Before the search, here is the customary first program in quantum computing, a Bell pair, which is the maximally entangled state of two qubits.

from braket.circuits import Circuit
from braket.devices import LocalSimulator

bell = Circuit().h(0).cnot(0, 1)        # put one qubit in superposition, then entangle
result = LocalSimulator().run(bell, shots=1000).result()
print(result.measurement_counts)

Measure it a thousand times and you get roughly five hundred readings of zero zero and five hundred of one one, and almost never the mixed outcomes. The two qubits are correlated, so reading one tells you the other. Hold that picture, because Grover's algorithm is the same machinery aimed at a goal.

The search itself

For a space of two qubits there are four possible answers, and Grover's method finds the one we mark in a single iteration. The circuit has two moving parts. An oracle flips the phase of the marked answer, quietly tagging it without yet changing how likely we are to measure it. Then a diffuser reflects every amplitude about the average, which turns that hidden phase tag into a towering probability for the marked state and almost nothing for the rest.

def grover_2qubit(marked="11"):
    circ = Circuit()
    circ.h(0).h(1)                  # 1. equal superposition over all four answers

    # 2. oracle: flip the phase of the marked answer. A controlled Z marks
    #    one one, and the X gates rotate any other target into place and back.
    if marked[0] == "0": circ.x(0)
    if marked[1] == "0": circ.x(1)
    circ.cz(0, 1)
    if marked[0] == "0": circ.x(0)
    if marked[1] == "0": circ.x(1)

    circ.h(0).h(1)                  # 3. diffuser: reflect about the average
    circ.x(0).x(1)
    circ.cz(0, 1)
    circ.x(0).x(1)
    circ.h(0).h(1)
    return circ

Run it on the local simulator and the result is unambiguous.

Measurement results (1000 shots):
  |11⟩  1000  100.0%  ########################################

One thousand shots, one thousand correct answers. On a perfect machine, Grover's algorithm at this scale does not miss.

Now run it on a real machine

Switching to hardware is a single line. You point the device at a machine's Amazon Resource Name instead of the simulator.

from braket.aws import AwsDevice
device = AwsDevice("arn:aws:braket:us-east-1::device/qpu/ionq/Forte-1")
result = device.run(grover_2qubit("11"), shots=1000).result()

The same circuit now runs on physical qubits, and the clean hundred percent blurs. The marked answer still dominates, which means the algorithm is working, but a few percent of the shots come back wrong, landing on outcomes that should have been impossible. That spread is not a bug in your code. It is the device's error rate made visible, the combined effect of imperfect gates, decoherence, and readout error. This is the texture of what John Preskill named the era of Noisy Intermediate Scale Quantum hardware in his widely cited 2018 essay, Quantum Computing in the NISQ era and beyond. A two qubit Grover circuit turns out to be a pleasant little benchmark for how noisy a given machine is on a given day. For this exercise, the error rate is the result worth measuring.

The part most demonstrations skip, the bill

Braket charges for hardware on a straightforward model. There is a fee each time you submit a task, plus a fee for every shot, and an option to reserve a machine by the hour if you need dedicated time. The current rates are published on the Amazon Braket pricing page. None of it is expensive at this scale, but it is real money, and accounting for it is what separates a one off experiment from work you would put a team behind. So the repository refuses to send anything to a quantum processor without telling you the likely cost first.

def _estimate_cost(shots):
    per_task, per_shot = 0.30, 0.01      # illustrative only, check current pricing
    est = per_task + per_shot * shots
    print(f"about {shots} shots is roughly ${est:,.2f} per circuit")

# and nothing runs on hardware until you type the word yes

It is a small thing, and it reflects a habit built over twenty years of being accountable for other people's cloud bills. You make the cost visible at the moment of the decision, not at the end of the month. A spending guard in front of a quantum processor is the same instinct as a budget alarm in front of a fleet of accelerators. Frontier compute does not get a pass on financial discipline.

Where this goes next

Grover's algorithm is the teaching example. The method I find genuinely interesting for the kind of work I do is the Quantum Approximate Optimization Algorithm, because it targets the combinatorial optimization problems that real businesses care about, such as routing, scheduling, and portfolio selection. It is also a hybrid method that loops between a quantum circuit and a classical optimizer, which is exactly what the hybrid jobs feature on Braket is designed to run. That is the next entry in the repository, and the next article here.

Until then, clone the repository, run the demonstration, and watch a quantum search land for free. When you are ready to see the noise for yourself, add the flag for a real machine and run it on the hardware.