Skip to Content
Technical Articles
Author's profile photo Guilherme Lahr

Advanced Event Mesh: Create your first event broker

This blog is part of a series where my goal is to offer you a practical overview of SAP Integration Suite, Advanced Event Mesh. As I continue to write more blogs, I will provide summaries on this page.

What is SAP Integration Suite, Advanced Event Mesh?

Advanced event mesh for SAP Integration Suite is a complete event streaming, event management, and monitoring platform that incorporates best practices, expertise, and technology for event-driven architecture (EDA) on a single platform. Our platform is offered as a software-as-a-service (SaaS) which:

  • gives you everything you need to accelerate your organization’s EDA adoption, allowing you to fulfill modern use cases that demand real-time, intelligent event streaming
  • provides an intuitive, unified interface to design, deploy, manage, monitor, and govern your event streaming infrastructure (including the events that flow over it) in the most secure manner.

For official documentation, please check SAP Integration Suite, Advanced Event Mesh (

Comparison between SAP solutions

Throughout the blog series, I will showcase details of AEM, aiming to provide a clearer differentiation between the solutions.


Creating EDA with SAP Integration Suite, Advanced Event Mesh

First Step: Create an Advanced Event Mesh instance on SAP BTP.

AEM is not available in all regions, therefore the first step is to check the available regions and create the BTP Subaccount in the correct region.

Go to SAP Discovery Center – Advanced Event Mesh (

On BTP, create your subaccount in your preferred region and with your preferred provider.

Remember to add entitlements to your new subaccount.


Before creating your AEM instance, you must establish trust between SAP Cloud Identity Services and Cloud Foundry, otherwise you won’t be able to deploy your instance successfully.

Finally, you can proceed to create your instance.

Click on the “go to application” button..

and voila!

The platform is composed of three distinct components:

  • Mission control
  • Event Portal
  • Event Insights

Event Portal
Event Portal is the single place to design, create, discover, share and manage all of the events within your ecosystem.

Mission Control
Mission Control makes it easy to deploy event broker services, create event meshes, and optimize and monitor the health and performance of an event-driven system.

Insights is an advanced monitoring service that allows you to detect potential issues before they have a negative impact on your event broker services. You can use dashboards to monitor your event broker services. You can also use Insights to receive email notifications.

In a nutshell, Event Portal is where we document our EDA, Mission Control is our runtime where everything is really happening, and Insights is where we monitor our brokers using Datadog.

We will explore it in more details.

Second step: Create an Event Broker


What we’ve done in the first step is to create a SAP Integration Suite, AEM instance and gain access to the platform. We can now start documenting our events, but we can’t yet publish or consume events. To do this, we need to create an Event Broker.

Click on Cluster Manager:


If you are working on an instance that you know already has brokers created but you can’t see any of them, uncheck “only show my services” option.

Click on the “create service” button.

To create our service, first, we need to have a few things in mind:

  • Service Class
  • Cloud Provider
  • Region

Excluding the “Standard” class, all other plans have high availability enabled. Typically, they differ in terms of number of client connections, spool size, number of queues, message size.

Service Class Options for Event Broker Services (

You don’t need to start it big, you can upscale when necessary. However, be aware that you can’t downscale. Find additional information here: Upscaling Event Broker Services (

After choosing the Service Class that fits your project, you must select a cloud provider.
Choosing the Right Cloud Provider When Creating an Event Broker Service

Each cloud provider offers different regions:

After choosing your service class, cloud provider, and region, click on “create service”.


Broker created!


Okay, now it will begin billing you. There are metrics for billing on a monthly or hourly basis. Typically, when using public cloud services, you will be billed per hour. You can estimate it on SAP Discovery Center – Estimator (

Specify the number of hours you expect your broker will be running and the number of brokers created in the appropriate service class. 730 hours cover one month 24/7.

On the next blog, we will explore the event broker in more detail.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Cameron HUNT
      Cameron HUNT

      Hello Guilherme Lahr, I'm quite confused about the functioning of Regions in the context of AEM. In the case of BTP 'Event Mesh', things are very simple: you have 1x (physical) Broker per BTP Sub-Account, and therefore per Region. As such, an outage in one Region cannot impact other regions.

      1) In the case of AEM, it appears that you must specify a Region every time you create a (physical) AEM Broker, that is entirely decoupled from the Region of the BTP Sub-Account where we find the AEM Platform itself ?

      2) I had thought that the AEM Platform is run on a Kubernetes Cluster. Doesn't this suggest that if your BTP Sub-Account is in Paris -- along with your "AEM instance" (K8s Cluster) -- and your 1st AEM Broker in São Paulo, that any messages published from Rio de Janeiro will need to pass through Paris (your "AEM instance") to get to São Paulo ? Doesn't this also suggest that any outage in Paris (impacting your "AEM instance" K8s Cluster) would in reality prevent your message from getting from Rio de Janeiro to São Paulo ?

      Regards, Cameron

      Author's profile photo Guilherme Lahr
      Guilherme Lahr
      Blog Post Author

      AEM broker is decoupled from your subaccount region. The subaccount region is required to host the AEM Web UI platform, and currently, we have it in only three regions. Essentially, you will create a subaccount to host the platform, and you will position your broker close to producers/consumers. Producers and consumers connect to the AEM broker and not to the BTP subaccount.

      The data does not pass through your subaccount to enter the broker; it does not leave the broker.

      If your subaccount in Paris goes down, your AEM broker remains up and running. While you may not be able to log in to the Web UI platform with your user, as it depends on IAS, your broker continues to operate without interruption. If this scenario happens you can control you broker using SEMP.

      Author's profile photo Cameron HUNT
      Cameron HUNT

      Hello Guilherme Lahr and thanks for your response, but this still leaves me confused about the physical location of the Kubernetes Cluster (K8s Cluster) on which each "AEM instance" runs.

      If I interpret correctly what you have said, if a SAP client has a single AEM Broker running in São Paulo and a single AEM Broker running in Paris, then in fact they have two separate K8s Clusters ?

      A K8s Cluster in São Paulo (running a single Broker/Container) and a separate K8s Cluster in Paris (running a single Broker/Container) ?

      Regards, Cameron

      Author's profile photo Guilherme Lahr
      Guilherme Lahr
      Blog Post Author

      Hi Cameron.
      You can deploy a broker on AWS EKS in São Paulo, another on Azure AKS in Paris, another on GCP GKE in the Iowa, and yet another on your on-premise Kubernetes. They won't exchange messages with each other unless you explicitly create a network between them using the Event Mesh feature, as shown in the image below.

      Author's profile photo Cameron HUNT
      Cameron HUNT

      Thanks Guilherme Lahr for your clear response. As such, 3x AEM Brokers in 3x different Cloud Regions will require 3x entirely separate Kubernetes Clusters !!!

      To be honest, I find this an enormous amount of hardware for such a small need. What's more, if I set up 3x separate (Classic) Event Mesh Brokers in these 3x same BTP Regions, I don't need to worry about any K8s clusters at all !

      Given that (Classic) Event Mesh Brokers almost certainly run on K8s Clusters -- Please confirm this point ? -- the key difference is that those Clusters are fully managed by SAP ? As such, why would I ever bother with AEM if I only need 1x Broker per Region ?

      What's more, AEM has a catalogue price of > € 4000 p/m, and Classic EM Brokers cost € 8 p/m per GB => there is simply no comparison in terms of price. Given this, please also confirm what seems obvious: SAP plans to kill the (Classic) Event Mesh Service as it no longer wishes to manage the underlying K8s Cluster on behalf of its customers ?

      Kind Regards, Cameron

      Author's profile photo Guilherme Lahr
      Guilherme Lahr
      Blog Post Author

      AEM has three deployment options:

      • Public Regions: Dedicated event broker services are deployed in SAP-controlled shared VPC/VNets on public cloud providers such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure.
      • Dedicated Regions: Dedicated event broker services are deployed in SAP-controlled VPC/VNets dedicated to the customer on public cloud providers such as AWS, GCP, and Azure.
      • Customer-Controlled Regions (sometimes referred to as Customer Private Regions): Dedicated event broker services are deployed in a customer's on-premises or cloud-based Kubernetes cluster, such as OpenShift, Rancher (RKE1), Amazon (EKS), Azure (AKS, ARO), Google (GKE), Alibaba (ACK), Huawei (CCE), and more.


      Please, take a look.
      Deployment Options (
      Deployment Roles and Responsibilities (

      Do you want to deploy it on your own k8s?

      I've been working with SAP AEM, and I don't need to worry about Kubernetes. I'm using it in the public region, and if I need to scale up, upgrade, or enable a feature, I just need to raise a ticket to the SAP team, the same as with Event Mesh.

      Being fair, catalog price, Standard 100 = EUR 1,854.20 or Enterprise 250 = EUR 2,781.30 p/m and they have more features than Event Mesh and much more powerful.
      If 1 GB per month is sufficient for your company, you don't need to move to AEM. Customers have more options to choose what suits their scenarios better. As far as I know, there's no plan to discontinue Event Mesh.

      Another point is that you can use AEM for various purposes, which means you don't need to use it exclusively for exchanging events with SAP products.

      Author's profile photo Cameron HUNT
      Cameron HUNT

      Hello again Guilherme Lahr, I'm a little bit surprised by your question to be honest. I will do my very best to completely avoid managing any K8s clusters at all, as their complexity far exceeds any benefits I can foresee today (including IoT Use Cases).

      As such, I will stick with one (Classic) Event Mesh broker per BTP Region, spend a lot less p/m, and have far less technical complexity to document and manage. The skills required to do so are likewise far simpler to find.

      If I'm not mistaken, each (Classic) Event Mesh Broker is in any case (technically) exactly the same as any AEM Broker = a Solace "PubSub+ Event Broker" ?

      Author's profile photo Guilherme Lahr
      Guilherme Lahr
      Blog Post Author

      1 - Sorry Cameron HUNT , maybe I haven't understood your question very well. Again, you don't need to manage k8s with AEM.

      2 - When you say "have far less technical complexity to document and manage. The skills required to do so are likewise far simpler to find".

      I disagree. AEM is one of the simplest tools I've worked with, yet very powerful. AEM helps me document and manage my events efficiently, although I assume you are referring to documenting the broker itself. I can clearly see events running on my broker in a graphical view.

      I can document my events and share them with my team or other teams. They can easily view events available for subscription, protocols, and authentication method.

      3 - AEM has much more features than Event Mesh and supports small to a very large scenarios. There's a comparation table in the beginning of this blog.

      4 - If creating an Event Mesh instance in each BTP region suits your scenario, I don't see a need for change. If your scenario grows and requires additional features, consider moving to AEM

      Author's profile photo Karsten Strothmann
      Karsten Strothmann

      Hi Cameron,

      Your understanding is slightly off track: an EM broker is certainly not an AEM broker.

      SAP Event Mesh provides a shared infrastructure, SAP Integration Suite, advanced event mesh provides an entire broker to you that is used exclusively by you. That is a huge difference, and this reflects in both the price and in the load that you can handle. Plus that AEM provides lots of features that EM simply does not offer (event replay, distributed tracing, advanced analysis, filtering, to name a few).

      In a single statement: SAP Event Mesh works all fine for smaller, less demanding scenarios. It's great to get you started and for isolated EDA use cases. As soon as you target a full blown EDA strategy on enterprise level, go for Advanced Event Mesh.



      Author's profile photo Alexander Aigner
      Alexander Aigner

      Hello Guilherme Lahr ,

      you mentioned, that AEM is billed per hours and brokers. Can you controll the time the systems are running or will it always be 730 hours? Would it be possible to turn it on/off on request manually?

      We want to test the solution, but there is no free tier available. what would you suggest to use for a POC scenario?

      Thanks and best regards,

      Author's profile photo Guilherme Lahr
      Guilherme Lahr
      Blog Post Author

      It's charged per hour. So, if you create your broker and it operates for one week, you will be charged for one week (24x7 - 168 hours). As far as I know, it's not possible to start/stop the broker. Depending on your PoC, you can create a broker with the service class Standard (the cheapest one), and after your PoC is done, you can delete it.

      Author's profile photo Karsten Strothmann
      Karsten Strothmann

      Hi Alexander,

      Typically customers keep their productive brokers up and running. For these I'd plan with 730 hours / month.

      Dev and potentially Q brokers (customers have different set ups) you can shut down and spin up if not needed. This would require doing the config again though, which you could potentially automate.



      Author's profile photo Abdul Shaik
      Abdul Shaik

      Hi Guilherme Lahr,


      The UI of this application appears to be identical to that of Solace Event Broker. I think many of their functions are too similar. Did we partner with them to develop Advance Event Mesh?

      Author's profile photo Guilherme Lahr
      Guilherme Lahr
      Blog Post Author

      I'm sorry, but I don't have any information about this partnership.

      Author's profile photo Karsten Strothmann
      Karsten Strothmann

      Hi Abdul,

      You are right. AEM is closely related to Solace. In the end you get a best of breed Solace broker/mesh that is further optimized to the SAP ecosystem (direct connectivity to SAP S/4HANA 2308 and S/4HANA Cloud starting from February 2024, upcoming integration with CAP etc.).