AWS Quantum Technologies Blog

Optimization with OpenQAOA on Amazon Braket

This post was contributed by Leonardo Disilvestro, Shao Hen Chiew, Jing Yi Chan, and Ewan Munro from Entropica, Sighard Schräbler and Volker van Aken from Continental Automotive Technologies GmbH, and Perminder Singh from AWS.

Investigating and optimizing the performance of quantum algorithms such as the quantum approximate optimization algorithm (QAOA) on quantum hardware is a great way to assess the capabilities of today’s Noisy Intermediate-Scale Quantum (NISQ) devices. This was one of the goals of a recent collaboration between Continental AG and Entropica Labs to further understand the potential applications and limitations of current quantum computers.

In this guest post, the teams from Continental AG and Entropica Labs introduce us to OpenQAOA, an open source tool developed by Entropica Labs that made this possible. Using the OpenQAOA software and its integration with Amazon Braket, they demonstrate how to cast an optimization problem relevant to Continental AG into a form that can be tackled by NISQ devices and execute the resulting algorithm on IonQ Harmony.

Today, we’ll introduce you to OpenQAOA, Entropica Labs’ open-source SDK for the QAOA, and OpenQAOA-Braket, a plugin specifically designed by Entropica Labs to expand OpenQAOA’s capabilities by leveraging Amazon Braket. OpenQAOA-Braket contains OpenQAOA Jobs, a new feature of OpenQAOA that leverages Amazon Braket Hybrid Jobs to easily set up and execute quantum-classical algorithms using real quantum hardware. We illustrate the usage of OpenQAOA Jobs and provide a code walkthrough to easily construct and execute QAOA circuits on state-of-the-art quantum devices hosted on Amazon Braket.


OpenQAOA makes it easy to build and customize QAOA algorithms for different applications with only a few lines of code [1]. OpenQAOA is fully compatible with Amazon Braket Hybrid Jobs, which offers priority access to quantum devices, a ‘fire-and-forget’ experience, and real-time insights into algorithm convergence.

As quantum hardware companies continue to increase the size and quality of their devices and roll out new features, it becomes increasingly complex for quantum developers to write quantum algorithms from scratch. There is a growing need for trusted and reliable interfaces to build complex workflows.

OpenQAOA is such an interface: it aims to abstract away the most tedious, repetitive, and error-prone tasks required to build quantum workflows while still granting the user a high level of control over the underlying quantum algorithm.

With OpenQAOA, users can run fully customized QAOA workflows by quickly swapping between simulators and quantum processing units (QPUs) while changing key elements of the circuit and of the algorithm. Choosing a custom mixer Hamiltonian, a different parametrization, or just changing the classical optimization algorithm, is just as easy as changing a parameter in a Python function. OpenQAOA also features algorithmic extensions and modifications of the original QAOA, such as Recursive QAOA [2] and the Alternating Operator Ansatz [3], each with its own customizable settings.

OpenQAOA Jobs: OpenQAOA with Amazon Braket Hybrid Jobs

Variational quantum algorithms such as the QAOA are compatible with existing NISQ hardware, which is characterized by relatively small numbers of qubits and fairly high noise levels. Specifically, the QAOA can tolerate noise by only involving repeated executions of short-depth parametrized quantum circuits, in conjunction with a classical computer that searches for optimal parameters that minimize the problem that the QAOA wants to solve. Consequently, classical and quantum resources are called in a loop, which may require hundreds of iterations and QPU calls.

The requirements of an iterative process between the user and the QPU pose unique challenges to the implementation of QAOA (or any other variational algorithm):

  • It requires an uninterrupted connection with the QPU until the end of the process;
  • The orchestration of classical and quantum resources is delocalized;
  • Iterative processes can delay the completion of the computation due to queuing priorities (if circuits from other users join the queue during the iteration).

Amazon Braket Hybrid Jobs addresses these issues by allowing users to submit a single script that defines the implementation of the variational algorithm. Running QAOA and other quantum algorithms as a hybrid job provides multiple benefits:

  1. Performance: Braket Hybrid Jobs provides priority access to the selected QPU for the duration of your algorithm, making sure your tasks execute ahead of standalone tasks in the queue, reducing the overall runtime of your workload.
  2. Fire-and-forget: You can submit your hybrid job at any time, even if the device is not available immediately or another hybrid job is currently running. Amazon Braket will schedule your hybrid job as soon as the device becomes available, execute your algorithm, and save the results once the hybrid job completes.
  3. Ease-of-use: With Braket Hybrid Jobs, you don’t need to manage your own classical computing environment and keep it running for the duration of the workload. Amazon Braket automatically spins up the requested Amazon EC2 instance, prepares your environment, and executes your algorithm. At the end of the workload, Amazon Braket stops the instance, making sure you only pay for what you use.
  4. Live insights: As part of your algorithm script, you can emit custom metrics, for instance, the value of your QAOA cost function at every iteration. Amazon Braket will automatically publish each defined metric in the Amazon Braket console, so you can track the progress of your workload in real time.

OpenQAOA Jobs integrates OpenQAOA with Amazon Braket Hybrid Jobs, and combines the simplicity of designing and executing QAOA workflows with the structural advantages of running and managing variational quantum algorithms using a single hybrid job with Amazon Braket.

OpenQAOA Jobs can also improve best practices when it comes to data governance and security. Since running computations on QPUs can be costly, it is paramount to safely and correctly archive results. We want users to quickly and effectively organize their data when running a proof of concept or testing a hypothesis for a scientific publication.

Finally, since OpenQAOA Jobs is built on top of Amazon Braket, it leverages standard AWS tools such as user access management features, offering a robust computational framework: The quantum-classical loop is executed entirely within Amazon Braket, and, if the user so desires, all data (from the input to the output of the computation) is securely stored within an Amazon S3 bucket.

Solving the Minimum Vertex Cover Problem with OpenQAOA Jobs

For a given graph G = (V, E), determining its minimum vertex cover (MVC) is a difficult optimization problem that has relevance in many real-life scenarios. It can be cast as a quadratic unconstrained binary optimization (QUBO) problem, and hence tackled with QAOA [4, 5].

To run an OpenQAOA Job, users need to create their OpenQAOA repository within their own Amazon ECR repository. Doing so is rather straightforward: all you need to do is use the Docker file provided in the OpenQAOA Github repository and follow the Bring Your Own Container (BYOC) instructions in the Amazon Braket Developer Guide. For additional information, please refer to the OpenQAOA Jobs documentation.

Let’s now examine how the MVC problem can be solved on Amazon Braket using OpenQAOA Jobs.

To execute the OpenQAOA Job, we need two Python scripts: and The role of is to prepare the inputs of the computation as a JSON file called openqaoa_params.json and to create the AwsQuantumJob by sending the JSON parameters and the entrypoint script to Amazon Braket. The file contains the actual code that will be executed by the Amazon Braket Hybrid Job.

Fig. 1. The selects an entry point and creates a JSON file containing the problem statement and the parameters of the desired workflow. These are then passed to an Amazon Braket Hybrid Job instance, whose role is to execute the workflow with the given parameters.

Figure 1. The selects an entry point and creates a JSON file containing the problem statement and the parameters of the desired workflow. These are then passed to an Amazon Braket Hybrid Job instance, whose role is to execute the workflow with the given parameters.

We start by building the file. First, we need to specify the problem we want to solve, and the parameters of the QAOA. Conveniently, OpenQAOA features a pre-built class for MVC problems:

from openqaoa import QAOA
from openqaoa.problems import MinimumVertexCover
import networkx as nx

# Generate the input
gr = nx.Graph()
gr.add_edges_from([(0, 1), (0, 2), (0, 3), (1, 2), (1, 3), (1, 4), (1, 5), (1, 6), (2, 3), (2, 4), (2, 5), (2, 6), (3, 4), (3, 5), (3, 6), (4, 5), (4, 6), (5, 6)])
mvc_qubo = MinimumVertexCover(gr, field=1, penalty=10)

# Generate the QAOA
q = QAOA()
q.set_circuit_properties(p=1, param_type='standard', init_type='ramp', mixer_hamiltonian='xy')
q.set_classical_optimizer(method='cobyla', maxiter=200)


Once the MVC and the QAOA have been defined, we can conveniently pack these into a file called openqaoa_params.json. This is done automatically using the dump method:


We can now create the Amazon Braket Hybrid Job:

job = AwsQuantumJob.create(device="arn:aws:braket:us-east-1::device/qpu/ionq/Harmony",
input_data={"input_data": 'openqaoa_params.json'},	
wait_until_complete=True )

And that’s all for the script. Now, let’s focus on the file. Since the problem input and the parameters of the QAOA were already specified in the script, now we only need to upload them:

from openqaoa.algorithms import AWSJobs
from import save_job_result

def main():

    job = AWSJobs(algorithm="QAOA")

    save_job_result({"result": job.workflow.asdict()})

if __name__ == "__main__":

And that’s it! Simply open a terminal and type python to leverage QAOA in order to find a MVC using OpenQAOA Jobs on Amazon Braket.

Once the optimization is complete, the result is stored in q.result and we can start analyzing it. For example, one can display the results of intermediate quantum computations as a cost vs iteration plot, and visualize the MVC marked on a graph:

Left: cost vs iteration plot of QAOA on IonQ Harmony (black curve), compared to OpenQAOA’s Vectorized simulator with shot noise (blue curves). Right: MVC of G=(V,E), marked in red.

Figure 2: On the left is a cost vs iteration plot of QAOA on IonQ Harmony (black curve), compared to OpenQAOA’s Vectorized simulator with shot noise (blue curves). On the right is the MVC of G=(V,E), marked in red.


While NISQ devices of the near future continue to develop, their limited size and resilience to noise will still challenge the execution of quantum algorithms at scale. This raises the crucial question of developing an understanding, within the industry, of the challenges and the potential rewards of using quantum processors to solve industrial relevant tasks.

In this post, we showcased an example of how the integration between Entropica Labs’ OpenQAOA and Amazon Braket greatly facilitated and enhanced our ability to investigate the application of a common quantum algorithm to today’s quantum hardware.

Dr. Sighard Schraebler, New Technologies and Liaison at Continental AG commented: “We started with quantum computing at Continental in mid-2021 and of course you start with the usual: Bell’s inequality and the comparison between simulation and reality. It took some time to understand how data is represented in the quantum computer and what superposition and entanglement do. By working with Entropica and AWS, we now have a better understanding of the state of the art and are excited about the future.”

If this blog post sparked your curiosity, and you want to get started with OpenQAOA Jobs on Amazon Braket, check out OpenQAOA’s website and OpenQAOA’s official documentation for other workflows and ideas.

OpenQAOA is a step towards building easy-to-use quantum applications that can deliver value to industry and research communities. It is an open-source project, and we welcome contributions from developers. If you want to join our community, consider starting a PR on the github repository, joining our Discord channel, or come and meet us at our monthly community calls hosted by the Unitary Fund.


[1]: OpenQAOA — An SDK for QAOA :

[2]: Obstacles to State Preparation and Variational Optimization from Symmetry Protection:

[3]: From the Quantum Approximate Optimization Algorithm to a Quantum Alternating Operator Ansatz :

[4]: A Quantum Approximate Optimization Algorithm :

[5]: Ising formulations of many NP problems –

Leonardo Disilvestro

Leonardo Disilvestro

Leonardo Disilvestro – In the previous decade, Leonardo has graduated as a theoretical physicist from the University of Edinburgh, managed to earn himself a Ph.D. in quantum information theory from Telecom ParisTech, and has successfully learned how to code and be a programmer. He is pretty pleased with the way things have turned so far, so he has decided to become a proper quantum scientist, and now he enjoys working at Entropica Labs while busking in Singapore’s tropical climate. In his free time, he likes to cook, walk his dog, and train for the next marathon. Oh, he also apparently likes to write in the third person.

Shao Hen

Shao Hen

Shao Hen is a quantum computing scientist at Entropica Labs. He holds Master’s degrees in Physics (from the National University of Singapore) and engineering (from ENS Mines Paris-PSL), with a strong research interest at the intersection of quantum computing, quantum information, and many-body physics. His current work at Entropica Labs focuses on optimizing the execution of quantum computers at various levels, and developing applications for quantum algorithms.

Jing Yi

Jing Yi

Jing Yi holds a physics degree from Imperial College London and currently leads business and operations activities at Entropica Labs. She started her career with IBM, and has held various roles on projects involving hardware, hybrid cloud, Cognitive AI, Big Data, HPC and IoT solutions. At IBM, she achieved the CEO’s Special Award for Strong Performance, Skills and Leadership Recognition; ASEAN Team Contributor Award; and was nominated IBM Quantum Distinguished Ambassador to mentor internal teams, work with industry, government and academic partners. In her spare time, Jing Yi plays classical piano, is an avid baker, enjoys travelling and loves exploring new food spots.

Ewan Munro

Ewan Munro

Ewan Munro is a theoretical physicist with a strong interest in algorithms, benchmarking, and product building. He enjoys travel, reading, and real ales. Ewan has a Master’s in Mathematical Physics from the University of Edinburgh, and a PhD in Physics from the Centre for Quantum Technologies at the National University of Singapore. He was also a visiting scientist at the Institute for Photonic Sciences (ICFO) in Barcelona. As CTO, Ewan leads Entropica’s technical strategy, working with our team to design and build products and workflows, as well as engaging in customer projects.

Sighard Schräbler

Sighard Schräbler

Sighard Schräbler is Senior Manager New Technologies & Liaison and Senior Expert AI Hardware to Advanced Engineering, Continental Automotive Technologies GmbH, Frankfurt. His research interests include Autonomy Stack, Data Driven Ecosystem, Hybrid AI-Classical Algorithms, Large Language Models & Transformer Nets, Hardware-Accelerators with GPUs, High Level Synthesis, Quantum Computing, Quantum Sensing and Post Quantum Cryptography.

Volker van Aken

Volker van Aken

Volker van Aken is a Mobile Robotics engineer at Continental Automotive Technologies GmbH in Frankfurt / Germany. He works as an AI drive stack developer and data scientist with Large Language Models and Transformer Nets.