This topic describes the background information, prerequisites, and billing of message integration.
Background information
Message integration is implemented based on the event stream feature of EventBridge. You can create message integration tasks in a visualized manner to forward messages across regions, instances, and applications. For more information, see Overview.
Message integration allows you to reliably distribute messages in ApsaraMQ for MQTT to various data destinations. During the distribution, messages are filtered and transformed.
Prerequisites
The underlying layer of message integration is implemented based on EventBridge and Function Compute. Before you create a message integration task, make sure that the following services are activated:
EventBridge is activated and the required permissions are granted to a Resource Access Management (RAM) user. For more information, see Activate EventBridge and grant permissions.
(Optional) Function Compute is activated. For more information, see Activate Function Compute. You need to activate Function Compute only if you want to use the transformation feature in the message integration task.
The destination service is activated. For example, if you want to create a message integration task whose sink is ApsaraMQ for Kafka, activate ApsaraMQ for Kafka.
Billing
For information about the billing of EventBridge, see Billing.
For information about the billing of Function Compute, see Billing overview.
For information about the billing of the destination service, see the related documentation of the service.
Migration guide for legacy Kafka rules
[TODO: This entire section is pending product/PD confirmation. The facts below (current usability of legacy Kafka rules, deprecation timeline, migration steps, and post-migration billing/feature differences) were not confirmed in the source support ticket and cannot be verified without a code review, which is out of scope for a direct edit. Do not publish until confirmed.]
If you created a legacy Kafka rule in the ApsaraMQ for MQTT console, migrate to a message integration task, which is built on EventBridge.
Current status of legacy Kafka rules: [TODO: confirm value - whether existing legacy Kafka rules can still run, whether new legacy Kafka rules can still be created, and whether any feature or region limits apply.]
Deprecation timeline: [TODO: confirm value - deprecation timeline for legacy Kafka rules, if any has been set by the product team.]
Migration path: To migrate from a legacy Kafka rule to a message integration task, create a message integration task whose sink is ApsaraMQ for Kafka in the ApsaraMQ for MQTT console. [TODO: add steps - the exact console entry point and step-by-step migration procedure from an existing legacy Kafka rule to a message integration task.]
Billing and feature differences after migration: [TODO: confirm value - how billing changes after moving from a legacy Kafka rule to an EventBridge event stream, and which capabilities differ between the two.]
Policies
If you use an Alibaba Cloud account to create a message integration task in the ApsaraMQ for MQTT console, follow the on-screen instructions to grant the permissions.
If you use a RAM user to create a message integration task in the ApsaraMQ for MQTT console, make sure that the following policies are attached to the RAM user:
AliyunMQFullAccess: the permissions to manage ApsaraMQ for MQTT resources.
AliyunFCFullAccess: the permissions to manage Function Compute resources.
AliyunEventBridgeFullAccess: the permissions to manage EventBridge resources.
The policy that contains the permissions to manage the resources of the destination service.
If you want to use extended capabilities, you must also obtain other required permissions. Examples:
If you want to access the destination service in a virtual private cloud (VPC), the AliyunVPCFullAccess policy must be attached to the RAM user. The policy contains the permissions to manage VPC resources.
If you want to view the running logs of Function Compute, the AliyunLogFullAccess policy must be attached to the RAM user. The policy contains the permissions to manage Simple Log Service resources.