How it works

This page was generated from content adapted from the AWS Developer Guide

Creating a cluster

  • Important You can't change the VPC for an Amazon MSK cluster after you create the cluster.

  • Important Specify exactly two subnets if you are using one of the following Regions: South America (São Paulo), Canada (Central), and US West (N. California). For other Regions where Amazon MSK is available, you can specify either two or three subnets. The subnets that you specify must be in distinct Availability Zones. When you create a cluster, Amazon MSK distributes the broker nodes evenly across the subnets that you specify.

  • Note The create-cluster command might return an error stating that one or more subnets belong to unsupported Availability Zones. When this happens, the error indicates which Availability Zones are unsupported. Create subnets that don't use the unsupported Availability Zones and try the create-cluster command again.

Deleting a cluster

  • Note If your cluster has an auto-scaling policy, we recommend that you remove the policy before you delete the cluster. For more information, see Automatic scaling.

Scaling up broker storage

  • Important When storage is scaled for an MSK cluster, the additional storage is made available right away. However, the cluster requires a cool-down period after every storage scaling event. Amazon MSK uses this cool-down period to optimize the cluster before it can be scaled again. This period can range from a minimum of 6 hours to over 24 hours, depending on the cluster's storage size and utilization and on traffic. This is applicable for both auto scaling events and manual scaling using the UpdateBrokerStorage operation. For information about right-sizing your storage, see Best practices.

Updating the broker type

Expanding a cluster

  • Important If you want to expand an MSK cluster, make sure to use this Amazon MSK operation . Don't try to add brokers to a cluster without using this operation.

Updating security

  • Note The AWS CLI and API operations for updating the security settings of a cluster are idempotent. This means that if you invoke the security update operation and specify an authentication or encryption setting that is the same setting that the cluster currently has, that setting won't change.

Last updated