A Developer's Field Guide to Amazon Braket
A guided tour of the Amazon Braket console. What each button does, why you'd click on it, and how to get started on a real quantum computer today.
Series: Quantum Computing on AWS (8 articles)
- 1A Developer's Field Guide to Amazon Braket This article
Who This Is For (and How to Read It)
If you have an AWS account and a little curiosity about quantum computing, you already have everything you need to run a program on a real quantum processor right now. You don't need a physics degree, you don't need to own a dilution refrigerator, and you don't need to email a national lab. All you need is your browser, the AWS Console, and a few minutes to explore.
This guide is a click-by-click walk through the Amazon Braket console. Amazon Braket is the fully managed quantum computing service on AWS. I'm going to open every panel, press every button, and tell you what happens and why it matters.
Where helpful, I'll drop in a few lines of Python from the Braket SDK so you can go from looking at the console to "my circuit just ran on trapped ions in a lab in Europe."
A few conventions:
- Screenshots mark each stop on the tour. Every image caption describes exactly what you're looking at, so you can follow along in your own console.
Try itcallouts are the "put the guide down and go do this" moments.- Tables are your cheat sheets (device specs, pricing, instance types). Skim them, then come back.
- Everything here reflects the Braket console as of mid-2026. Quantum hardware moves fast — devices come and go monthly (there's a whole section on that), so treat specific device names as a snapshot.
A note on cost before you touch anything: Braket has no flat subscription. Simulators and quantum processors are pay-as-you-go, and the local simulator that ships with the SDK is free. You can run this entire tour's "hello world" for pennies and I'll show you how to set a hard spending limit so you never get surprised. Read the Cost controls section before you submit to real hardware.
The 30-Second Mental Model
Braket wraps three things behind one console and one SDK:
- Simulators — classical computers pretending to be quantum ones. Perfect for development. Some run locally (free), some run on-demand in the cloud.
- QPUs (Quantum Processing Units) — this is the real thing. Trapped ions, superconducting circuits, neutral atoms from several hardware companies, all reachable through the same API.
- What brings it all together — managed Jupyter notebooks, hybrid quantum-classical job orchestration, result storage in S3, cost tracking, and access controls.
The workflow Braket is built around is a simple loop: Build → Test → Run → Analyze.
You build and test for virtually $0 and you only pay real money at the "Run on a QPU" step.
Keep that loop in mind. The whole console is organized around it.
Keep that loop in mind. The whole console is organized around it.
1. Getting In: Finding Braket and Flipping On the Switch
Finding the service
Open the AWS Console and type Braket in the top search bar. Amazon Braket shows up under Services, described as a "Service for exploring, evaluating, and experimenting with quantum computing."
The search panel also surfaces three Braket features directly (Braket Direct, Permissions and Settings, and Service Dashboard) so you can jump straight to a subsection. Click the star to pin Braket to your console favorites; you'll be back.
The left-nav: your whole map
Once inside, everything hangs off the left navigation menu. Here's the entire console in one table. This is also the map for the rest of the guide.
| Nav item | What it's for | Covered in |
|---|---|---|
| Dashboard | At-a-glance widgets: notebooks, jobs, announcements, preferred device | Section 2 |
| Devices | Browse every simulator and QPU; inspect specs, calibration, cost | Section 3 |
| Notebooks | Managed JupyterLab instances, pre-loaded with the SDK | Section 4 |
| Hybrid jobs | Orchestrated quantum-classical workloads with priority device access | Section 5 |
| Quantum tasks | The atomic unit of work — one circuit + shots submitted to one device | Section 6 |
| Algorithm library | 11 ready-to-run textbook algorithms in Python | Section 7 |
| Braket Direct | Reservations, expert office hours, experimental hardware features | Section 8 |
| Administration → Permissions and settings | Enable third-party devices; manage IAM execution roles | Section 1 & 10 |
| Administration → Spending limits | Hard dollar caps per QPU | Section 10 |
| Announcements | New devices, retirements, feature launches | Section 11 |
Enable third-party devices: the one-time setup
Before you can send a workload to any non-AWS device (IonQ, IQM, QuEra, Rigetti, AQT), you have to accept the third-party hardware terms once. Go to:
Administration → Permissions and settings.
On the General tab you'll find Enable third-party devices. Flipping this to Enabled acknowledges that when you use a partner's hardware, your circuit content is transferred to that provider outside AWS facilities for processing. No acceptance, no QPU access.
Execution Roles (the IAM plumbing)
The Execution roles tab is where Braket confirms it has the IAM roles it needs. There are three to know about:
- Service-linked role (
AWSServiceRoleForAmazonBraket) — lets Braket act on your behalf. Braket creates this automatically; you'll see a green "Service-linked role found" banner. - Notebook access role — an IAM role with the
AmazonBraketFullAccesspolicy so notebook instances can call Braket operations. Use Verify existing roles to confirm you have one. - Hybrid jobs execution role — carries the
AmazonBraketJobsExecutionPolicy, the minimum permissions a hybrid job needs to run.
If any are missing, the page offers a one-click Create default role. For a first-time account, click through all three and you're provisioned.
Try it— In your AWS account, spend your first two minutes here: enable third-party devices, then verify all three execution roles. It's the only mandatory setup, and skipping it is the #1 reason a first QPU submission fails.
2. The Service Dashboard
Click Dashboard for the mission-control view. It's a grid of widgets you can rearrange, remove, or add to with Add widgets (and Reset to default layout if you make a mess):
- Active notebooks and Recent hybrid jobs — quick status, with "Create" shortcuts when empty.
- Announcements — the live feed of device launches and retirements (more in §11).
- Community support — direct links to the AWS Quantum Computing Blog, the Quantum Computing Stack Exchange, and AWS re:Post.
- Device — pin a preferred device so its live properties surface right here on the dashboard.
- Resources — links to Quantum Embark (AWS's paid advisory program for Enterprise), the Braket Learning Plan, and the developer guide.
Try it — Hit Set a preferred device and pick a simulator like SV1. Now your dashboard always shows you a live device you can reach for free.
3. Devices: the Heart of Braket
This is one of the pages you'll open most. Devices lists every simulator and QPU you can reach, with provider, device name, live status, and a one-line description.
The current fleet
Out of the box you see the online devices. As of this writing that's nine — two AWS simulators and seven QPUs spanning four qubit technologies:
Three status values are very important: ONLINE (accepting tasks now though QPUs still have availability windows), OFFLINE (temporarily unavailable), and RETIRED (gone for good).
The fleet moves fast : "Show retired devices"
Toggle Show retired devices and the list jumps from 9 to 28. This is the single best lesson the Devices page teaches: quantum hardware is a moving target. The retired list is a graveyard of an entire industry's iteration.
The takeaway for anyone building on Braket: program against device properties, not device names. Query capabilities at runtime (qubit count, native gates, connectivity) so your code survives the next hardware refresh.
Try it— Toggle "Show retired devices" and just read the descriptions. You're looking at the last five years of the quantum industry in one scrollable list.
Inside a device: the detail page
Click any device name to open its detail page. The layout is consistent across the fleet, so learn it once. Up top is a Summary card:
- Status, Device ARN (the string your code needs. Copy it here), and Spending limit.
- Three queue depth counters: Tasks, Priority tasks, and Hybrid jobs. These tell you how many workloads are ahead of yours right now.
- Action buttons: Reserve device (jump the queue via Braket Direct), Open notebook (spin up a notebook pre-pointed at this device), and a refresh icon.
Below that, up to four tabs. Let's use two real devices to see the range.
QuEra Aquila — a 256-qubit analog machine. Aquila is a neutral-atom device that operates in analog mode (continuous evolution of a Hamiltonian rather than discrete gates). Its detail page shows the hardware provider (QuEra, Boston), the Region (
us-east-1), and, importantly, its cost and availability:
The Calibration tab is where hardware honesty lives. For Aquila you get device geometry and error characteristics — 256 sites, a 75 µm × 76 µm lattice, 4 µm spacing, position resolution down to 0.01 µm, plus filling, vacancy, and detection error rates — with a Device geometry / Control fields / JSON switch so you can grab the raw numbers programmatically. Every calibration table is timestamped ("Last updated…") because these values drift and are re-measured regularly.
The Experimental capabilities tab exposes cutting-edge features you enable per-task through the SDK. For Aquila, local detuning, tall geometries, and tight geometries (ways to push past the standard operating modes).
AQT IBEX Q1 — a 12-qubit gate-model machine. On a gate-based QPU, the Native Gates tab lights up. It lists the exact gate set the hardware executes natively. Everything else in your circuit gets compiled down to these. For AQT's ion trap that's
prx (a phase-RX gate), xx (an Ising XX coupling gate), and rz (a Z-axis rotation). Notice this device lives in eu-north-1 This is a reminder that QPUs are Region-specific.
Here's how you'd pull all of that from code instead of the console:
1
2
3
4
5
6
7
8
9
10
from braket.aws import AwsDevice
# Copy the ARN straight from the device page's Summary card
aquila = AwsDevice("arn:aws:braket:us-east-1::device/qpu/quera/Aquila")
print(aquila.status) # ONLINE / OFFLINE
print(aquila.properties.paradigm) # qubit count, geometry, etc.
# Gate-model devices expose their native gate set:
garnet = AwsDevice("arn:aws:braket:eu-north-1::device/qpu/iqm/Garnet")
print(garnet.properties.paradigm.nativeGateSet)| Tab | Appears on | What it tells you |
|---|---|---|
| Details | All devices | Provider, region, qubits, cost, availability windows |
| Calibration | All devices | Live, timestamped error rates and topology |
| Native Gates | Gate-model QPUs only | The exact gate set your circuit compiles to |
| Experimental capabilities | Select devices | Per-task opt-in features (dynamic circuits, geometry tricks) |
Try it— Open SV1 (free) and a QPU like IQM Garnet side by side. Compare their Calibration tabs. The simulator is "perfect"; the QPU is informatively imperfect.
4. Notebooks: your Managed Jupyter Cockpit
You can run Braket from your laptop with
pip install amazon-braket-sdk. But another option is a managed notebook like a JupyterLab instance AWS spins up with the Braket SDK and the major quantum frameworks already installed. Click Notebooks and Braket offers two paths.
| Standard notebook | Advanced notebook | |
|---|---|---|
| Setup | One click | 5-step wizard |
| Compute | ml.t3.medium | EC2 / HPC / GPU, your choice |
| Pre-installed | Braket SDK, CUDA-Q, PennyLane, Qiskit | Everything in Standard, plus… |
| Extras | JupyterLab extensions, example algorithms | Custom IAM, VPC, KMS encryption, custom GitHub repos |
| Best for | Learning, prototyping | Team environments, private networking, big compute |
The one-click standard notebook
Choosing Standard → Create pops a small modal: name your instance (Braket prefixes it with
amazon-braket-, max 35 characters, hyphens allowed, no spaces) and choose whether to enable the Notebook inactivity manager. This is a helpful watchdog that stops the instance after idle time so you stop paying for compute you're not using.
Cost reality check: A notebook instance is billed like the underlying EC2 instance for as long as it's running, whether or not you're using it. Enable the inactivity manager, or make a habit of Stop-ping the instance when you walk away. This is the most common source of a surprise Braket bill and it's not the quantum part.
The advanced notebook wizard, step by step
Click Advanced → Configure for the full five-step wizard. This is where teams tailor an environment.
Step 1 — General settings. Name, light/dark visual mode, and the same inactivity manager toggle.
Step 2 — Notebook configuration. Pick your compute. This is the step that decides your hourly cost and how much classical horsepower sits next to your quantum code.
You also set a volume size (5 GB up to 16 TB) and can import a GitHub repository so your notebook starts with your team's code already cloned.
Step 3 — Access permissions. Choose the IAM role the notebook assumes (e.g., the default
AmazonBraketServiceSageMakerNotebookRole), decide on root access, and optionally supply a KMS key to encrypt the volume.
Step 4 — Network access. Attach the notebook to a VPC (or "No VPC" for a public instance). This is how you keep a notebook on a private network with no internet exposure.
Step 5 — Review and launch. A tidy summary of every choice, plus optional resource Tags (great for cost allocation). Hit Launch and Braket provisions the instance.
Your first circuit (once the notebook opens)
Open the launched notebook, start a
conda_braket kernel, and here's the genuine "hello, world" of quantum computing: a Bell state on the free local simulator:1
2
3
4
5
6
7
8
9
10
from braket.devices import LocalSimulator
from braket.circuits import Circuit
# Build: an equal superposition of |00> and |11>
bell = Circuit().h(0).cnot(0, 1)
print(bell)
# Test: run on the free local simulator (up to ~25 qubits)
result = LocalSimulator().run(bell, shots=1000).result()
print(result.measurement_counts) # ~ Counter({'00': 503, '11': 497})Two entangled qubits, measured a thousand times, coming out as roughly half
00 and half 11 — and never 01 or 10. That's entanglement, and it cost you nothing. When you're ready to leave the simulator, you change exactly one line: the device. THIS is the whole point of Braket's design. We'll do that in §6.5. Hybrid Jobs: Quantum-Classical, Orchestrated
Most useful near-term quantum algorithms (QAOA, VQE, quantum machine learning) are hybrid: a classical optimizer runs a loop, and inside each iteration it calls a QPU. Hybrid Jobs is Braket's managed orchestration for exactly that pattern. It provisions a classical instance to run your driver code, gives your job priority access to the chosen QPU (so you're not re-queuing every iteration), streams metrics, checkpoints progress, and tears everything down when you're done.
The Hybrid jobs page starts empty, with Create hybrid job front and center. Creating one is a five-step wizard.
Step 1 — Specify an algorithm. Upload a Python script from your computer or point at one in S3, set the entry point (the function invokes when the job starts), and optionally mark it Zipped. You can also expand Hyperparameters (values passed into your algorithm) and Input data (extra files staged for the job).
Step 2 — Set hybrid job settings. Name the job (defaults to
braket-job-default) and, under Advanced settings, choose the execution role and the default S3 bucket where Braket stashes your code, inputs, outputs, and checkpoints.
Step 3 — Configure an environment. Pick the container your code runs in. The base images ship with the Braket SDK, Python, and PennyLane; the TensorFlow and PyTorch variants add those frameworks (and CUDA); CUDA-Q adds GPU-accelerated simulation; or bring your own container (BYOC).
| Environment | Adds | Reach for it when… |
|---|---|---|
| PennyLane | Core Braket SDK + PennyLane | Standard variational algorithms |
| PennyLane + TensorFlow | TF + CUDA | ML/AI-flavored quantum work |
| PennyLane + PyTorch | PyTorch | Computer-vision / NLP-style pipelines |
| CUDA-Q | NVIDIA CUDA-Q | GPU-accelerated quantum simulation |
| Custom (BYOC) | Your Docker image | You need exact, reproducible deps |
Step 4 — Configure the execution. Under Quantum compute settings you pick the Device your job gets priority on (or use an embedded simulator inside the classical instance), and optionally attach a Reservation to bypass queues entirely. Under Classical compute settings you size the driver instance. Then set a Stopping condition (max runtime default to 5 days) and optionally configure Checkpoints and Outputs.
| Classical instance | Specs | Use |
|---|---|---|
| Standard | ml.m5.large — 2 vCPU, 8 GiB | Most driver loops |
| GPU accelerated | ml.g4dn.xlarge — 4 vCPU, 16 GiB, 1× NVIDIA T4 | Embedded GPU simulators, ML |
| Advanced selection | any supported type | Full control |
Step 5 — Review and create. Everything in one screen from algorithm source, and role, to environment, hardware, and device ARN. Notice you can build and validate an entire hybrid job pointed at the local simulator (
local:braket/default-simulator) so you never spend a cent debugging orchestration before you point it at real hardware.
The console wizard mirrors a decorator-based API. In a notebook, the same job is a few lines:
1
2
3
4
5
6
7
8
9
10
11
from braket.jobs import hybrid_job
from braket.devices import LocalSimulator
def run_job():
from braket.circuits import Circuit
circ = Circuit().h(0).cnot(0, 1)
return LocalSimulator().run(circ, shots=1000).result().measurement_counts
job = run_job() # Braket provisions, runs, and tears down
print(job.result())Try it— Create a hybrid job pointed at the local simulator with the tiny script above. It costs nothing and teaches you the entire lifecycle — provisioning, running, checkpointing, results in S3 — before real hardware is involved.
6. Quantum Tasks: The Atomic Unit of Work
A quantum task is the smallest thing Braket runs: one program (a circuit, an annealing problem, or an analog schedule) submitted to one device for a set number of shots (repetitions). Every simulator run, every QPU run, every iteration inside a hybrid job; all of it is quantum tasks under the hood. The Quantum tasks page is your run history.
A banner at the top makes a point worth remembering (YET AGAIN): QPUs are Region-specific. A task for IQM Garnet must be submitted in
eu-north-1; a task for QuEra Aquila in us-east-1. If your task list looks empty, check your Region first.
Click a task to open its detail page. This is the receipt for a single run:
- Quantum task ARN and Device ARN — the unique identifiers.
- Status —
CREATED → QUEUED → RUNNING → COMPLETED(orFAILED/CANCELLED). - Successful shots — e.g.,
100 / 100 (100%). - Queue position — where you sit when queued.
- Results — a View in S3 link; raw measurement data always lands in your Braket S3 bucket.
- Reservation ARN / Hybrid job ARN — populated if the task ran under either.
- Tabs for a Results explorer and Tags.
Now the one-line change that turns your free Bell-state test into a real quantum-hardware run — swap
LocalSimulator() for an AwsDevice ARN. This is the moment the guide has been building toward:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
from braket.aws import AwsDevice
from braket.circuits import Circuit
from braket.tracking import Tracker # near-real-time cost tracking
bell = Circuit().h(0).cnot(0, 1)
# On-demand cloud simulator (SV1) — cheap, region-agnostic ARN:
sv1 = AwsDevice("arn:aws:braket:::device/quantum-simulator/amazon/sv1")
# ...or a real QPU (must be in that device's Region!):
garnet = AwsDevice("arn:aws:braket:eu-north-1::device/qpu/iqm/Garnet")
with Tracker() as tracker:
task = garnet.run(bell, shots=100) # returns immediately
print(task.state()) # QUEUED / RUNNING / COMPLETED
counts = task.result().measurement_counts # blocks until done
print(counts)
print(tracker.quantum_tasks_statistics()) # shots, tasks, duration
print(tracker.qpu_tasks_cost()) # estimated $ before the billThe
Tracker context manager is worth its weight in gold. It gives you a maximum cost estimate in USD in near-real-time, so you know what a run cost before the monthly bill confirms it.Try it— Run the Bell state onSV1first (cloud simulator, cents). When the counts look right, change one line to a QPU ARN and watch your task move throughQUEUED → RUNNING → COMPLETEDon the Quantum tasks page. Congratulations — you just used a real quantum computer.
7. Algorithm Library: 11 Ready-to-Run Classics
If you learn better by reading working code, Algorithm library is the best page on the console. It's a catalog of pre-built, textbook quantum algorithms, each written in Python, each with a GitHub link, each runnable in a managed notebook via Open notebook. No blank-page problem. You start from a correct implementation and modify.
| Algorithm | What it demonstrates |
|---|---|
| Bernstein–Vazirani | The first algorithm to beat classical for a specific problem — oracle separation |
| Deutsch–Jozsa | An early, clean quantum-vs-classical advantage |
| Grover's | Quadratic speedup for unstructured search (√N vs N) |
| QAOA | Hybrid optimization — the workhorse of the NISQ era |
| Quantum Circuit Born Machine | Variational generative modeling |
| Quantum Fourier Transform | The subroutine behind Shor's and phase estimation |
| Quantum Phase Estimation | Eigenvalue estimation — foundational to many algorithms |
| Quantum Walk | The quantum analog of a random walk |
| Shor's | Polynomial-time integer factoring — the famous one |
| Simon's | Exponential separation; a precursor to Shor's |
| Violation of Bell's Inequality | Proof that entanglement is real, in code |
Try it— Open Grover's algorithm, run it on the local simulator, then change the "marked" item and watch the probability concentrate on your new target. It's the most satisfying five minutes in the console.
8. Braket Direct: Skip the Line and Go
Braket Direct is a hub of three "power-user" programs bundled together: dedicated hardware access, human expertise, and bleeding-edge features.
Reservations give you exclusive access to a specific QPU for a block of time, so your workloads don't wait behind anyone else's. Key facts (verified against the Braket developer guide):
- Available in 1-hour increments for all Braket devices.
- Cancellable up to 48 hours in advance at no charge; otherwise you pay for the reserved block regardless of how much you use it.
- Queue tasks and jobs in advance against your Reservation ARN, or submit live during the window.
- IonQ perk: reservations raise the per-circuit gate limit to 5,000 (vs. 2,000 on-demand) and lower the error-mitigation minimum shot count to 500 (vs. 2,500).
Clicking Reserve device opens a request form — your name and email, a description of your workload, a duration (1–5+ hours), two or more candidate dates, and an option for a free 30-minute prep session with a Braket expert.
Expert advice connects you to real humans: free weekly Braket office hours (30-minute 1:1 slots), plus dedicated channels to IonQ, QuEra, and Rigetti, and the Advanced Solutions Lab (ASL) for deeper collaborative research engagements.
Experimental capabilities surfaces next-generation features with limited availability — enabled per-task through the SDK. In this snapshot: dynamic circuits (mid-circuit measurement and feed-forward) on IQM Emerald and IQM Garnet, and local detuning / tall geometries / tight geometries on QuEra Aquila.
| Program | What you get | Cost model |
|---|---|---|
| Reservations | Exclusive device access, no queue | Per-hour, billed for the block |
| Expert advice | Office hours, provider channels, ASL | Office hours free; ASL varies |
| Experimental capabilities | Early hardware features | Per-task, standard device pricing |
Try it— Even if you never reserve hardware, book a Braket office hours slot. Thirty free minutes with an AWS quantum specialist is the highest-leverage button on this entire page.
9. Program Sets: Batch many circuits into one task
A mid-2026 addition worth calling out: Program Sets. Historically each circuit was its own quantum task with its own per-task fee and its own trip through the queue. A program set lets you bundle up to 100 unique circuits or a single parametric circuit with up to 100 parameter settings into one quantum task. Braket handles compiling and running the whole package on the QPU, minimizing the gap between executions and the per-task overhead.
Why you care:
- One per-task fee across every circuit in the set (you still pay per shot).
- Less queue waiting — one submission instead of a hundred.
- Ideal for variational algorithms, classical shadows, and quantum machine learning, where you sweep a parameter or run a batch of related circuits.
Program sets are available across the gate-based devices. If your workload is "run this circuit 100 times with different angles," this is the feature that makes it cheap and fast.
10. Cost Controls
Quantum hardware is metered, and QPU time is not cheap. Braket gives you three independent guardrails. Use all of them.
How Braket charges
You pay for what you run:
| Resource | How it's billed |
|---|---|
| Local simulator (in the SDK) | Free |
| On-demand simulators (SV1, DM1) | Per minute of simulation time |
| QPUs | Per task + per shot (rates vary by device) |
| Reservations | Per hour of the reserved block, regardless of use |
| Notebooks / hybrid job classical compute | Per the underlying EC2 instance, while running |
A concrete QPU example straight off the device page: QuEra Aquila: $0.30 per task + $0.01 per shot on-demand, or $2,500 per hour reserved. So a 100-shot Aquila task runs about
$0.30 + 100 × $0.01 = $1.30. Rates differ per device and change over time, so always confirm current numbers on the Amazon Braket pricing page or the device's Details tab before a big run.Guardrail 1 — Spending limits (hard caps)
Under Administration → Spending limits you set a maximum dollar amount per QPU. When spend hits the cap, further tasks to that device are rejected. Because QPUs are Region-specific, so are spending limits: select the device's Region to see and set them.
Create spending limit opens a small form.
Guardrail 2 — In-code cost tracking
The SDK's
Tracker (shown in §6) gives you a near-real-time maximum cost estimate in USD while your code runs. Wrap any run in with Tracker() as tracker: and call tracker.qpu_tasks_cost() / tracker.simulator_tasks_cost(). Every Braket example notebook already includes it.Guardrail 3 — Operational hygiene
- Stop idle notebooks (or enable the inactivity manager) — this is the most common surprise charge, and it's classical compute, not quantum.
- Set a
Maximum runtimestopping condition on every hybrid job so a runaway optimizer can't loop forever. - Test on simulators first. Local is free; on-demand SV1/DM1 are cheap. Only graduate to a QPU when the circuit is correct.
- Tag notebooks, tasks, and jobs so AWS Cost Explorer can slice spend by project.
Try it— Before your very first QPU submission, set a $10 spending limit on that device. You'll run your experiment and physically cannot overspend. Raise it later when you trust your workflow.
11. Announcements: how to stay current
Because the fleet changes monthly, Announcements are very helpful. It's the changelog you actually need. It's where AWS posts new devices, retirements (with hard cutoff dates), and feature launches.
Try it— Skim Announcements once a month, or follow the AWS Quantum Computing Blog (linked from the dashboard's Community support widget). A retirement notice you missed is a broken pipeline you didn't see coming.
12. Your first hour on Braket: a hands-on path
Enough touring. Here's a concrete sequence that takes you from zero to "I ran on a real quantum computer," safely.
- Enable devices (2 min). Administration → Permissions and settings → enable third-party devices; verify the three execution roles.
- Set a guardrail (1 min). Administration → Spending limits → create a small cap (say $10) on one QPU you want to try.
- Browse the fleet (5 min). Devices → open a simulator and a QPU; compare their Calibration tabs; copy a device ARN.
- Launch a notebook (5 min). Notebooks → Standard → Create; enable the inactivity manager; open JupyterLab with the
conda_braketkernel. - Build + test for free (10 min). Run the Bell-state circuit on
LocalSimulator(), then on cloudSV1. Confirm the counts. - Run on real hardware (10 min). Change one line to a QPU ARN (mind the Region!), wrap it in
Tracker(), submit, and watch the task moveQUEUED → RUNNING → COMPLETED. - Analyze (5 min). Quantum tasks → open your task → View in S3 for raw results; check
tracker.qpu_tasks_cost(). - Learn from the pros (rest of the hour). Algorithm library → open Grover's or QAOA and modify it. Book a Braket office-hours slot.
13. Wrap-up: go press the buttons
The thing that surprises most developers about Amazon Braket is how straightforward the experience is. It's the same console muscle memory as any other AWS service: a left-nav, some wizards, IAM roles, an S3 bucket, a spending limit. The only difference is that the "compute" at the end of the pipe happens to be trapped ions in a vacuum chamber or neutral atoms held by lasers. You build and test for free, you flip one line to reach real hardware, and you can cap the cost so tightly that experimentation is genuinely low-risk.
So don't just read about it. Open the console, enable devices, set a $10 limit, and run a Bell state on a real QPU this week. The gap between "quantum computing is fascinating" and "I ran a quantum program" is about a few minutes and a handful of clicks.
Now you have the map.
Let's keep building.
Series: Quantum Computing on AWS (8 articles)
- 1A Developer's Field Guide to Amazon Braket This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article