Your question is somewhat ambiguous, but what you are asking does seem to fit the AWS IoT Greengrass architecture, so I'll describe it using that topology.
First of all, you should understand the basic pub/sub topology of MQTT itself. MQTT relies on a broker to receive all messages (published) and then forward those messages on to any devices that have told the broker that they want to receive messages with a specific topic (subscribed). Devices that send messages and devices that receive messages don't have to know about each other. All communication is routed via the broker(s).
- Original Image from HiveMQ MQTT Essentials -
A cloud based MQTT broker is part of AWS IoT Core and handles the routing of MQTT messages. In the AWS Greengrass topology, a GG core device communicates with the AWS IoT cloud service, and it also acts as a gateway for IoT edge devices. So you might have one Raspberry Pi running the GG Core software that communicates with AWS IoT, along with a few dozen ESP32s with sensors running FreeRTOS that communicate with the Raspberry Pi on the same local network. In this case, the data from the ESP32s don't go directly to AWS. They are routed through the local Raspberry Pi.
In addition to acting as a gateway, the Raspberry Pi can also act upon locally collected data from the ESP32s without having to communicate with the cloud. It can also aggregate data collected from the local ESP32s and push it up to the cloud in one message rather than sending a separate MQTT message for every piece of data.
To summarize, in this scenario the MQTT broker is in the AWS cloud, the Raspberry Pi is a Greengrass Core "edge server", and the ESP32s are edge devices that only communicate on the local network.
- Original Image from Amazon Web Services Developer Guide -