{"id":2734117,"date":"2023-06-19T19:19:43","date_gmt":"2023-06-19T23:19:43","guid":{"rendered":"https:\/\/wordpress-1016567-4521551.cloudwaysapps.com\/plato-data\/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1-amazon-web-services\/"},"modified":"2023-06-19T19:19:43","modified_gmt":"2023-06-19T23:19:43","slug":"multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1-amazon-web-services","status":"publish","type":"station","link":"https:\/\/platodata.io\/plato-data\/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1-amazon-web-services\/","title":{"rendered":"Multi-tenancy Apache Kafka clusters in Amazon MSK with IAM access control and Kafka Quotas \u2013 Part 1 | Amazon Web Services"},"content":{"rendered":"<p>With <a href=\"https:\/\/docs.aws.amazon.com\/msk\/?id=docs_gateway\" target=\"_blank\" rel=\"noopener\">Amazon Managed Streaming for Apache Kafka<\/a> (Amazon MSK), you can build and run applications that use Apache Kafka to process streaming data. To process streaming data, organizations either use multiple Kafka clusters based on their application groupings, usage scenarios, compliance requirements, and other factors, or a dedicated Kafka cluster for the entire organization. It doesn\u2019t matter what pattern is used, Kafka clusters are typically multi-tenant, allowing multiple producer and consumer applications to consume and produce streaming data simultaneously.<\/p>\n<p>With multi-tenant Kafka clusters, however, one of the challenges is to make sure that data consumer and producer applications don\u2019t overuse cluster resources. There is a possibility that a few poorly behaved applications may overuse cluster resources, affecting the well-behaved applications as a result. Therefore, teams who manage multi-tenant Kafka clusters need a mechanism to prevent applications from overconsuming cluster resources in order to avoid issues. This is where Kafka quotas come into play. Kafka quotas control the amount of resources client applications can use within a Kafka cluster.<\/p>\n<p>In Part 1 of this two-part series, we explain the concepts of how to enforce Kafka quotas in MSK multi-tenant Kafka clusters while using <a href=\"http:\/\/aws.amazon.com\/iam\" target=\"_blank\" rel=\"noopener\">AWS Identity and Access Management<\/a> (IAM) access control for authentication and authorization. In <a href=\"https:\/\/aws.amazon.com\/blogs\/big-data\/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-2\/\">Part 2<\/a>, we cover detailed implementation steps along with sample Kafka client applications.<\/p>\n<h2>Brief introduction to Kafka quotas<\/h2>\n<p>Kafka quotas control the amount of resources client applications can use within a Kafka cluster. It\u2019s possible for the multi-tenant Kafka cluster to experience performance degradation or a complete outage due to resource constraints if one or more client applications produce or consume large volumes of data or generate requests at a very high rate for a continuous period of time, monopolizing Kafka cluster\u2019s resources.<\/p>\n<p>To prevent applications from overwhelming the cluster, Apache Kafka allows configuring quotas that determine how much traffic each client application produces and consumes per Kafka broker in a cluster. Kafka brokers throttle the client applications\u2019 requests in accordance with their allocated quotas. Kafka quotas can be configured for specific <strong>users<\/strong>, or specific <strong>client IDs<\/strong>, or <strong>both<\/strong>. The <strong>client ID<\/strong> is a logical name defined in the application code that Kafka brokers use to identify which application sent messages. The <strong>user<\/strong> represents the authenticated user principal of a client application in a secure Kafka cluster with authentication enabled.<\/p>\n<p>There are two types of quotas supported in Kafka:<\/p>\n<ul>\n<li><strong>Network bandwidth quotas<\/strong> \u2013 The byte-rate thresholds define how much data client applications can <strong>produce<\/strong> to and <strong>consume<\/strong> from each individual broker in a Kafka cluster measured in bytes per second.<\/li>\n<li><strong>Request rate quotas<\/strong> \u2013 This limits the percentage of time each individual broker spends processing client applications requests.<\/li>\n<\/ul>\n<p>Depending on the business requirements, you can use either of these quota configurations. However, the use of network bandwidth quotas is common because it allows organizations to cap platform resources consumption according to the amount of data produced and consumed by applications per second.<\/p>\n<p>Because this post uses an MSK cluster with IAM access control, we specifically discuss configuring <strong>network bandwidth quotas<\/strong> based on the applications\u2019 <strong>client IDs<\/strong> and <strong>authenticated user principals<\/strong>.<\/p>\n<h2>Considerations for Kafka quotas<\/h2>\n<p>Keep the following in mind when working with Kafka quotas:<\/p>\n<ul>\n<li><strong>Enforcement level <\/strong>\u2013 Quotas are enforced at the broker level rather than at the cluster level. Suppose there are six brokers in a Kafka cluster and you specify a 12 MB\/sec produce quota for a client ID and user. The producer application using the client ID and user can produce a max of 12MB\/sec on each broker at the same time, for a total of max 72 MB\/sec across all six brokers. However, if leadership for every partition of a topic resides on one broker, the same producer application can only produce a max of 12 MB\/sec. Due to the fact that throttling occurs per broker, it\u2019s essential to maintain an even balance of topics\u2019 partitions leadership across all the brokers.<\/li>\n<li><strong>Throttling <\/strong>\u2013 When an application reaches its quota, it is throttled, not failed, meaning the broker doesn\u2019t throw an exception. Clients who reach their quota on a broker will begin to have their requests throttled by the broker to prevent exceeding the quota. Instead of sending an error when a client exceeds a quota, the broker attempts to slow it down. Brokers calculate the amount of delay necessary to bring clients under quotas and delay responses accordingly. As a result of this approach, quota violations are transparent to clients, and clients don\u2019t have to implement any special backoff or retry policies. However, when using an asynchronous producer and sending messages at a rate greater than the broker can accept due to quota, the messages will be queued in the client application memory first. The client will eventually run out of buffer space if the rate of sending messages continues to exceed the rate of accepting messages, causing the next <code>Producer.send()<\/code> call to be blocked. <code>Producer.send()<\/code> will eventually throw a <code>TimeoutException<\/code> if the timeout delay isn\u2019t sufficient to allow the broker to catch up to the producer application.<\/li>\n<li><strong>Shared quotas <\/strong>\u2013 If more than one client application has the same client ID and user, the quota configured for the client ID and user will be shared among all those applications. Suppose you configure a produce quota of 5 MB\/sec for the combination of <code>client-id=\"marketing-producer-client\"<\/code> and <code>user=\"marketing-app-user\"<\/code>. In this case, all producer applications that have <code>marketing-producer-client<\/code> as a <strong>client ID<\/strong> and <code>marketing-app-user<\/code> as an authenticated <strong>user<\/strong> principal will share the 5 MB\/sec produce quota, impacting each other\u2019s throughput.<\/li>\n<li><strong>Produce throttling <\/strong>\u2013 The produce throttling behavior is exposed to producer clients via client metrics such as <code>produce-throttle-time-avg<\/code> and <code>produce-throttle-time-max<\/code>. If these are non-zero, it indicates that the destination brokers are slowing the producer down and the quotas configuration should be reviewed.<\/li>\n<li><strong>Consume throttling <\/strong>\u2013 The consume throttling behavior is exposed to consumer clients via client metrics such as <code>fetch-throttle-time-avg<\/code> and <code>fetch-throttle-time-max<\/code>. If these are non-zero, it indicates that the origin brokers are slowing the consumer down and the quotas configuration should be reviewed.<\/li>\n<\/ul>\n<p>Note that client metrics are metrics exposed by clients connecting to Kafka clusters.<\/p>\n<ul>\n<li><strong>Quota configuration <\/strong>\u2013 It\u2019s possible to configure Kafka quotas either statically through the Kafka configuration file or dynamically through <code>kafka-config.sh<\/code> or the Kafka Admin API. The dynamic configuration mechanism is much more convenient and manageable because it allows quotas for the new producer and consumer applications to be configured at any time without having to restart brokers. Even while application clients are producing or consuming data, dynamic configuration changes take effect in real time.<\/li>\n<li><strong>Configuration keys <\/strong>\u2013 With the <code>kafka-config.sh<\/code> command-line tool, you can set dynamic consume, produce, and request quotas using the following three configuration keys, respectively: <code>consumer_byte_rate<\/code>, <code>producer_byte_rate<\/code>, and <code>request_percentage<\/code>.<\/li>\n<\/ul>\n<p>For more information about Kafka quotas, refer to <a href=\"https:\/\/kafka.apache.org\/28\/documentation.html#design_quotas\" target=\"_blank\" rel=\"noopener\">Kafka documentation<\/a>.<\/p>\n<h2>Enforce network bandwidth quotas with IAM access control<\/h2>\n<p>Following our understanding of Kafka quotas, let\u2019s look at how to enforce them in an MSK cluster while using IAM access control for authentication and authorization. IAM access control in Amazon MSK eliminates the need for two separate mechanisms for authentication and authorization.<\/p>\n<p>The following figure shows an MSK cluster that is configured to use IAM access control in the demo account. Each producer and consumer application has a quota that determines how much data they can produce or consume in bytes per second. For example, <code>ProducerApp-1<\/code> has a produce quota of <strong>1024 bytes\/sec<\/strong>, and <code>ConsumerApp-1<\/code> and <code>ConsumerApp-2<\/code> each have a consume quota of <strong>5120<\/strong> and <strong>1024 bytes\/sec<\/strong>, respectively. It\u2019s important to note that Kafka quotas are set on the Kafka cluster rather than in the client applications.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-48964 size-full\" src=\"https:\/\/wordpress-1016567-4521551.cloudwaysapps.com\/wp-content\/uploads\/2023\/06\/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1-amazon-web-services.jpg\" alt width=\"899\" height=\"887\"><\/p>\n<p>The preceding figure illustrates how Kafka client applications (<code>ProducerApp-1<\/code>, <code>ConsumerApp-1<\/code>, and <code>ConsumerApp-2<\/code>) access <code>Topic-B<\/code> in the MSK cluster by assuming write and read IAM roles. The workflow is as follows:<\/p>\n<ul>\n<li><strong>P1<\/strong> \u2013 <code>ProducerApp-1<\/code> (via its <code>ProducerApp-1-Role<\/code> IAM role) assumes the <code>Topic-B-Write-Role<\/code> IAM role to send messages to <code>Topic-B<\/code> in the MSK cluster.<\/li>\n<li><strong>P2<\/strong> \u2013 With the <code>Topic-B-Write-Role<\/code> IAM role assumed, <code>ProducerApp-1<\/code> begins sending messages to <code>Topic-B<\/code>.<\/li>\n<li><strong>C1<\/strong> \u2013 <code>ConsumerApp-1<\/code> (via its <code>ConsumerApp-1-Role<\/code> IAM role) and <code>ConsumerApp-2<\/code> (via its <code>ConsumerApp-2-Role<\/code> IAM role) assume the <code>Topic-B-Read-Role<\/code> IAM role to read messages from <code>Topic-B<\/code> in the MSK cluster.<\/li>\n<li><strong>C2<\/strong> \u2013 With the <code>Topic-B-Read-Role<\/code> IAM role assumed, <code>ConsumerApp-1<\/code> and <code>ConsumerApp-2<\/code> start consuming messages from <code>Topic-B<\/code>.<\/li>\n<\/ul>\n<p><code>ConsumerApp-1<\/code> and <code>ConsumerApp-2<\/code> are two separate consumer applications. They do not belong to the same consumer group.<\/p>\n<h3>Configuring client IDs and understanding authenticated user principal<\/h3>\n<p>As explained earlier, Kafka quotas can be configured for specific users, specific client IDs, or both. Let\u2019s explore <strong>client ID<\/strong> and <strong>user<\/strong> concepts and configurations required for Kafka quota allocation.<\/p>\n<p><strong>Client ID<\/strong><\/p>\n<p>A client ID representing an application\u2019s logical name can be configured within an application\u2019s code. In Java applications, for example, you can set the producer\u2019s and consumer\u2019s client IDs using <code>ProducerConfig.CLIENT_ID_CONFIG<\/code> and <code>ConsumerConfig.CLIENT_ID_CONFIG<\/code> configurations, respectively. The following code snippet illustrates how <code>ProducerApp-1<\/code> sets the client ID to <code>this-is-me-producerapp-1<\/code> using <code>ProducerConfig.CLIENT_ID_CONFIG:<\/code><\/p>\n<div class=\"hide-language\">\n<pre><code class=\"lang-java\">Properties props = new Properties();\nprops.put(ProducerConfig.CLIENT_ID_CONFIG,\"this-is-me-producerapp-1\");<\/code><\/pre>\n<\/p><\/div>\n<p><strong>User<\/strong><\/p>\n<p>The user refers to an authenticated user principal of the client application in the Kafka cluster with authentication enabled. As shown in the solution architecture, producer and consumer applications assume the <code>Topic-B-Write-Role<\/code> and <code>Topic-B-Read-Role<\/code> IAM roles, respectively, to perform write and read operations on <code>Topic-B<\/code>. Therefore, their authenticated user principal will look like the following IAM identifier:<\/p>\n<div class=\"hide-language\">\n<pre><code class=\"lang-markup\">arn:aws:sts::&lt;AWS Account Id&gt;:assumed-role\/&lt;assumed Role Name&gt;\/&lt;role session name&gt;<\/code><\/pre>\n<\/p><\/div>\n<p>For more information, refer to <a href=\"https:\/\/docs.aws.amazon.com\/IAM\/latest\/UserGuide\/reference_identifiers.html\" target=\"_blank\" rel=\"noopener\">IAM identifiers<\/a>.<\/p>\n<p>The <strong>role session name<\/strong> is a string identifier that uniquely identifies a session when IAM principals, federated identities, or applications assume an IAM role. In our case, <code>ProducerApp-1<\/code>, <code>ConsumerApp-1<\/code>, and <code>ConsumerApp-2<\/code> applications assume an IAM role using the <a href=\"https:\/\/docs.aws.amazon.com\/STS\/latest\/APIReference\/welcome.html\" target=\"_blank\" rel=\"noopener\">AWS Security Token Service<\/a> (AWS STS) SDK, and provide a role session name in the AWS STS SDK call. For example, if <code>ProducerApp-1<\/code> assumes the <code>Topic-B-Write-Role<\/code> IAM role and uses <code>this-is-producerapp-1-role-session<\/code> as its role session name, its authenticated user principal will be as follows:<\/p>\n<div class=\"hide-language\">\n<pre><code class=\"lang-markup\">arn:aws:sts::<span>&lt;AWS Account Id&gt;<\/span>:assumed-role\/Topic-B-Write-Role\/this-is-producerapp-1-role-session<\/code><\/pre>\n<\/p><\/div>\n<p>The following is an example code snippet from the <code>ProducerApp-1<\/code> application using <code>this-is-producerapp-1-role-session<\/code> as the <strong>role session name<\/strong> while assuming the <code>Topic-B-Write-Role<\/code> IAM role using the AWS STS SDK:<\/p>\n<div class=\"hide-language\">\n<pre><code class=\"lang-java\">StsClient stsClient = StsClient.builder().region(region).build();\nAssumeRoleRequest roleRequest = AssumeRoleRequest.builder() .roleArn(\"&lt;Topic-B-Write-Role ARN&gt;\") .roleSessionName(\"this-is-producerapp-1-role-session\") \/\/role-session-name string literal .build();<\/code><\/pre>\n<\/p><\/div>\n<h2>Configure network bandwidth (produce and consume) quotas<\/h2>\n<p>The following commands configure the <strong>produce<\/strong> and <strong>consume<\/strong> quotas dynamically for client applications based on their <strong>client ID<\/strong> and authenticated <strong>user<\/strong> principal in the MSK cluster configured with IAM access control.<\/p>\n<p>The following code configures the produce quota:<\/p>\n<div class=\"hide-language\">\n<pre><code class=\"lang-markup\">kafka-configs.sh --bootstrap-server <span>&lt;MSK cluster bootstrap servers IAM endpoint&gt;<\/span> --command-config config_iam.properties --alter --add-config \"producer_byte_rate=<span>&lt;number of bytes per second&gt;<\/span>\" --entity-type clients --entity-name <span>&lt;ProducerApp client Id&gt;<\/span> --entity-type users --entity-name <span>&lt;ProducerApp user principal&gt;<\/span><\/code><\/pre>\n<\/p><\/div>\n<p>The <code>producer_byes_rate<\/code> refers to the number of messages, in bytes, that a producer client identified by <strong>client ID<\/strong> and <strong>user<\/strong> is allowed to produce to a single broker per second. The option <code>--command-config<\/code> points to <code>config_iam.properties<\/code>, which contains the properties required for IAM access control.<\/p>\n<p>The following code configures the consume quota:<\/p>\n<div class=\"hide-language\">\n<pre><code class=\"lang-markup\">kafka-configs.sh --bootstrap-server <span>&lt;MSK cluster bootstrap servers IAM endpoint&gt;<\/span> --command-config config_iam.properties --alter --add-config \"consumer_byte_rate=<span>&lt;number of bytes per second&gt;<\/span>\" --entity-type clients --entity-name <span>&lt;ConsumerApp client Id&gt;<\/span> --entity-type users --entity-name <span>&lt;ConsumerApp user principal&gt;<\/span><\/code><\/pre>\n<\/p><\/div>\n<p>The <code>consumer_bytes_rate<\/code> refers to the number of messages, in bytes, that a consumer client identified by <strong>client ID<\/strong> and <strong>user<\/strong> allowed to consume from a single broker per second.<\/p>\n<p>Let\u2019s look at some example quota configuration commands for <code>ProducerApp-1<\/code>, <code>ConsumerApp-1<\/code>, and <code>ConsumerApp-2<\/code> client applications:<\/p>\n<ul>\n<li><strong>ProducerApp-1 produce quota configuration<\/strong> \u2013 Let\u2019s assume <code>ProducerApp-1<\/code> has <code>this-is-me-producerapp-1<\/code> configured as the client ID in the application code and uses <code>this-is-producerapp-1-role-session<\/code> as the role session name when assuming the <code>Topic-B-Write-Role<\/code> IAM role. The following command sets the produce quota for <code>ProducerApp-1<\/code> to 1024 bytes per second:<\/li>\n<\/ul>\n<div class=\"hide-language\">\n<pre><code class=\"lang-markup\">kafka-configs.sh --bootstrap-server <span>&lt;MSK Cluster Bootstrap servers IAM endpoint&gt;<\/span> --command-config config_iam.properties --alter --add-config \"producer_byte_rate=1024\" --entity-type clients --entity-name this-is-me-producerapp-1 --entity-type users --entity-name arn:aws:sts::<span>&lt;AWS Account Id&gt;<\/span>:assumed-role\/Topic-B-Write-Role\/this-is-producerapp-1-role-session<\/code><\/pre>\n<\/p><\/div>\n<ul>\n<li><strong>ConsumerApp-1 consume quota configuration<\/strong> \u2013 Let\u2019s assume <code>ConsumerApp-1<\/code> has <code>this-is-me-consumerapp-1<\/code> configured as the client ID in the application code and uses <code>this-is-consumerapp-1-role-session<\/code> as the role session name when assuming the <code>Topic-B-Read-Role<\/code> IAM role. The following command sets the consume quota for <code>ConsumerApp-1<\/code> to 5120 bytes per second:<\/li>\n<\/ul>\n<div class=\"hide-language\">\n<pre><code class=\"lang-markup\">kafka-configs.sh --bootstrap-server <span>&lt;MSK Cluster Bootstrap servers IAM endpoint&gt;<\/span> --command-config config_iam.properties --alter --add-config \"consumer_byte_rate=5120\" --entity-type clients --entity-name this-is-me-consumerapp-1 --entity-type users --entity-name arn:aws:sts::<span>&lt;AWS Account Id&gt;<\/span>:assumed-role\/Topic-B-Read-Role\/this-is-consumerapp-1-role-session<\/code><\/pre>\n<\/p><\/div>\n<p><strong><br \/>ConsumerApp-2 consume quota configuration<\/strong> \u2013 Let\u2019s assume <code>ConsumerApp-2<\/code> has <code>this-is-me-consumerapp-2<\/code> configured as the client ID in the application code and uses <code>this-is-consumerapp-2-role-session<\/code> as the role session name when assuming the <code>Topic-B-Read-Rol<\/code>e IAM role. The following command sets the consume quota for <code>ConsumerApp-2<\/code> to 1024 bytes per second per broker:<\/p>\n<div class=\"hide-language\">\n<pre><code class=\"lang-markup\">kafka-configs.sh --bootstrap-server <span>&lt;MSK Cluster Bootstrap servers IAM endpoint&gt;<\/span> --command-config config_iam.properties --alter --add-config \"consumer_byte_rate=1024\" --entity-type clients --entity-name this-is-me-consumerapp-2 --entity-type users --entity-name arn:aws:sts::<span>&lt;AWS Account Id&gt;<\/span>:assumed-role\/Topic-B-Read-Role\/this-is-consumerapp-2-role-session<\/code><\/pre>\n<\/p><\/div>\n<p>As a result of the preceding commands, the <code>ProducerApp-1<\/code>, <code>ConsumerApp-1<\/code>, and <code>ConsumerApp-2<\/code> client applications will be throttled by the MSK cluster using IAM access control if they exceed their assigned produce and consume quotas, respectively.<\/p>\n<h2>Implement the solution<\/h2>\n<p><a href=\"https:\/\/aws.amazon.com\/blogs\/big-data\/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-2\/\" target=\"_blank\" rel=\"noopener\">Part 2<\/a> of this series showcases the step-by-step detailed implementation of Kafka quotas configuration with IAM access control along with the sample producer and consumer client applications.<\/p>\n<h2>Conclusion<\/h2>\n<p>Kafka quotas offer teams the ability to set limits for producer and consumer applications. With Amazon MSK, Kafka quotas serve two important purposes: eliminating guesswork and preventing issues caused by poorly designed producer or consumer applications by limiting their quota, and allocating operational costs of a central streaming data platform across different cost centers and tenants (application and product teams).<\/p>\n<p>In this post, we learned how to configure network bandwidth quotas within Amazon MSK while using IAM access control. We also covered some sample commands and code snippets to clarify how the client ID and authenticated principal are used when configuring quotas. Although we only demonstrated Kafka quotas using IAM access control, you can also configure them using other Amazon MSK-supported authentication mechanisms.<\/p>\n<p>In <a href=\"https:\/\/aws.amazon.com\/blogs\/big-data\/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-2\/\" target=\"_blank\" rel=\"noopener\">Part 2<\/a> of this series, we demonstrate how to configure network bandwidth quotas with IAM access control in Amazon MSK and provide you with example producer and consumer applications so that you can see them in action.<\/p>\n<p>Check out the following resources to learn more:<\/p>\n<hr>\n<h3>About the Author<\/h3>\n<p><img decoding=\"async\" loading=\"lazy\" class=\"wp-image-27271 size-full alignleft\" src=\"https:\/\/wordpress-1016567-4521551.cloudwaysapps.com\/wp-content\/uploads\/2023\/06\/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1-amazon-web-services-1.jpg\" alt width=\"100\" height=\"100\"> <strong>Vikas Bajaj<\/strong> is a Senior Manager, Solutions Architects, Financial Services at Amazon Web Services. Having worked with financial services organizations and digital native customers, he advises financial services customers in Australia on technology decisions, architectures, and product roadmaps.<\/p>\n<p> <!-- '\"` --><\/p>\n<ul class=\"plato-post-bottom-links\">\n<li class=\"plato-post-bottom-link-amplifi\">SEO Powered Content &amp; PR Distribution. <a href=\"https:\/\/www.amplifipr.com\" target=\"_blank\" rel=\"noopener\">Get Amplified Today.<\/a><\/li>\n<li class=\"plato-post-bottom-link-evm-finance\">EVM Finance. Unified Interface for Decentralized Finance. <a href=\"https:\/\/wordpress-1016567-4521551.cloudwaysapps.com\/analytics\/evm-finance\/\" target=\"_blank\" rel=\"noopener\">Access Here.<\/a><\/li>\n<li class=\"plato-post-bottom-link-quantum-media\">Quantum Media Group. IR\/PR Amplified. <a href=\"https:\/\/arizoldan.com\" target=\"_blank\" rel=\"noopener\">Access Here.<\/a><\/li>\n<li class=\"plato-post-bottom-link-platoaistream\">PlatoAiStream. Web3 Data Intelligence. Knowledge Amplified. <a href=\"https:\/\/wordpress-1016567-4521551.cloudwaysapps.com\" target=\"_blank\" rel=\"noopener\">Access Here.<\/a><\/li>\n<li class=\"plato-post-bottom-link-source\"><span>Source:<\/span> <a href=\"https:\/\/aws.amazon.com\/blogs\/big-data\/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1\/\" target=\"_blank\" rel=\"noopener\">https:\/\/aws.amazon.com\/blogs\/big-data\/multi-tenancy-apache-kafka-clusters-in-amazon-msk-with-iam-access-control-and-kafka-quotas-part-1\/<\/a><\/li>\n<\/ul>\n","protected":false},"author":1,"featured_media":2734119,"template":"Default","meta":{"_eb_attr":"","type":"","auto_type":false,"post":"","stream":"","stream_url":"","waveform_data":[],"duration":0,"start":0,"end":0,"bpm":0,"downloadable":false,"download_url":"","purchase_title":"","purchase_url":"","post-count-all":0,"like_count":0,"download_count":0,"editor_note":"","copyright":"","captions":[],"sources":[]},"genre":[42022],"station_tag":[21246,38012,33649,38013,34957,21579,10944,3785,69356,3629,70124,4262,13775,13275,9160,21089,70623,3880,69034,9080,12193,4263,9087,4042,6172,11825,3761,14478,4418,69923,3819,13519,68862,68956,9161,4735,7230,3787,9873,68950,18340,68867,34086,45462,4604,4047,3681,9617,4243,48551,48552,10283,41104,48553,30511,5270,9371,4554,6149,69524,5717,20721,27602,30993,48554,13212,48572,40607,17194,68951,13083,4143,8248,41392,4526,4053,48555,47685,3886,48563,14642,14043,4267,4441,12140,17908,12447,9086,20072,39890,11610,15933,3720,9272,11364,4442,13680,4057,40297,8637,71795,12833,40206,5669,40440,4690,4342,9370,3791,40937,9883,10738,19997,4058,12464,40300,3833,3642,46388,12466,9831,47689,5217,46660,11380,10905,11604,13605,12106,12076,40029,9163,3835,9090,69099,9164,22089,9423,69357,9366,47659,14017,40053,9094,40031,40576,40412,46244,69195,24740,39319,9884,452,39858,13753,47295,9166,13781,13710,40837,8066,20629,24487,11100,12971,70370,9369,20920,40057,4175,30957,3900,4176,3772,9874,12646,48556,13776,9007,11488,3847,48557,9418,68868,3801,3694,4185,12342,18595,48568,3650,45172,48581,40199,14452,40778,4078,40414,3907,69466,69344,69119,70083,9267,10903,9365,19265,40038,9878,3908,40062,68944,28862,3701,3653,48564,5486,48558,43204,4197,3806,5262,4318,4573,3654,48580,14050,47993,13214,27165,10849,13777,11796,10842,10033,9246,34143,26118,10001,71579,14095,69374,8690,14101,475,9170,10997,69523,11457,23391,39876,11673,39917,3742,20482,14094,10785,48559,3855,48560,17454,68953,40419,4100,4388,68946,3662,8377,8411,43410,3663,68864,69348,4577,12344,5870,9171,40330,4102,12133,3861,7457,8453,9642,8570,12062,4210,9879,9876,30372,39896,5662,7934,9221,11810,9992,4430,6209,71829,3939,13082,9054,9675,19521,48421,11057,33137,15551,15116,7118,13810,13484,11950,9612,11484,11101,9836,4111,4432,4112,47471,69754,39868,40337,41680,13274,40791,3921,13653,40668,6196,15409,10034,4220,5588,69188,69380,40074,46344,70466,47328,3778,40194,3975,39976,3976,24463,4026,4221,39869,12345,15952,40347,13654,4581,14914,5494,3779,10951,4223,11458,3977,11562,13785,9255,3714,31196,4412,67549,39843,40075,4034,39844,14103,4127,68954,48561,13215,39845,48569,28675,11938,48566,69021,68948,69022,13569,9055,13164,3671,19267,4036,10956,13287,25082,5207,10035,69591,12348,10873,13074,12068,48332,37458,10367,68866,30318,3755,71140,69023,69191,39873,38738,12446,68959,4590,4809,9178,69189,36520,11454,3941,27168,48562,3816,9089,9249,43538,9608,40104,68949,14555],"artist":[42039],"mood":[],"activity":[],"_links":{"self":[{"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/station\/2734117"}],"collection":[{"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/station"}],"about":[{"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/types\/station"}],"author":[{"embeddable":true,"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/users\/1"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/media\/2734119"}],"wp:attachment":[{"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/media?parent=2734117"}],"wp:term":[{"taxonomy":"genre","embeddable":true,"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/genre?post=2734117"},{"taxonomy":"station_tag","embeddable":true,"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/station_tag?post=2734117"},{"taxonomy":"artist","embeddable":true,"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/artist?post=2734117"},{"taxonomy":"mood","embeddable":true,"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/mood?post=2734117"},{"taxonomy":"activity","embeddable":true,"href":"https:\/\/platodata.io\/wp-json\/wp\/v2\/activity?post=2734117"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}