Akamai Release Notes

Managed Databases is now natively enabled in RBAC Identity and Access. This means that you can manage granular user access to your databases. The access of existing users got migrated according to the table:

Previous role assignment Post-migration role assignment database_creator account_database_creator, account_postgresql_database_creator, account_mysql_database_creator, account_valkey_database_creator database_viewer account_database_viewer, account_postgresql_database_viewer, account_mysql_database_viewer, account_valkey_database_viewer database_admin account_database_admin, account_mysql_database_admin, account_postgress_database_admin, account_valkey_database_admin,

What to do next:

We recommend the account administrators to review the Managed Database access of each user. If needed, you may update it.

For new users, check the Available roles list and assign the users a role that fits the user the most.

Original source

This release introduces Premium NodeBalancers for enterprise-grade workloads and expands backend connectivity options to include VPC and public IPv6, in addition to the existing private IPv4 (Legacy) support.

Premium NodeBalancers

NodeBalancers are now offered in both premium (new) and basic versions. The following table compares these options. Use this information to help determine which version best meets your application’s requirements for performance, scalability, and protocol support.

Feature / Specification Premium (premium) Basic (common) Maximum backend nodes per configuration Up to 2,000 Up to 1,000 Backend node connectivity Supports either VPC or public IPv6 backends. Does not support legacy private IPv4. Supports legacy (private IPv4), VPC or public IPv6 backends. Maximum concurrent connections (TCP/HTTP/HTTPS) Up to 100,000 Up to 10,000 Maximum concurrent connections (UDP) Up to 80,000 Not supported UDP (Beta) layer 4 load balancing Supported when UDP protocol is enabled on your account. (Configured using APIs only) Not supported TCP (layer 4) load balancing Supported Supported HTTP/HTTPS (layer 7) load balancing Supported (HTTP/1.1 only) Supported (HTTP/1.1 only) Maximum inbound network bandwidth 10 Gbps 10 Gbps Assigned for LKE-E clusters Automatically assigned Not automatically assigned Infrastructure and performance Dedicated for consistent, predictable capacity Shared, may experience resource contention Reserved IPs Supported (Except when provisioned by IAM restricted users for LKE-Enterprise). Supported

Flexible backend connectivity

NodeBalancers no longer require a private IP in the 192.168.255.0/24 range to communicate with backend nodes. Instead, the connectivity between the NodeBalancer and its backend nodes now depends on its backend connectivity setting. Depending on this setting, IP addresses outside the private range can be used.

The NodeBalancer's backend connectivity setting applies to all its backend nodes and can't be changed after the NodeBalancer is created. You can choose from legacy, IPv6, or VPC for this setting.

NodeBalancer connectivity to backend nodes

Value When to use Example IP used for connectivity Legacy For basic NodeBalancers communicating with non-VPC backend nodes over private IPv4. The NodeBalancer's frontend IPv4 communicates with the backend node's private IPv4 address. Note: Limited quantities of private IPv4s are available. 192.168.255.10 Other types of node addresses (IPv6, VPC IPs) are not allowed. IPv6 For basic or premium NodeBalancers communicating with non-VPC backend nodes using a public IPv6. The NodeBalancer's frontend IPv6 communicates with the backend node's IPv6 address. 2600:3c1f:51:1::1 Other types of node addresses (private IPv4, VPC IPs) are not allowed. VPC For basic or premium NodeBalancers communicating with backend nodes assigned to a VPC. VPCs support IPv4 and IPv6 (BETA). 10.0.250.4/30 Non-VPC IPs are not allowed. undefined (Read-only) This value is assigned only when you create a NodeBalancer without specifying a backend connectivity type, node configuration, or VPC. After you add the first backend node to the NodeBalancer this value updates to either Legacy or IPv6. —

📘

Data transferred between services like NodeBalancers and Linodes in the same data center (using either a private IPv4, public IPv6, or VPC) is free and it doesn’t count against your monthly bandwidth allowance.

Protecting backend nodes from unauthorized access and maintaining secure communication

The NodeBalancer's backend IPs are used for communication between the NodeBalancer and the backend nodes. Your backend nodes should be configured to block direct traffic from external sources or clients, accepting requests only through these NodeBalancer backend IPs.

To secure backend nodes, assign the Linodes to a VPC or use Cloud Firewalls and configure firewall rules to allow only NodeBalancer traffic. Add the NodeBalancer IP access control list (ACL) to the backend node's firewall rules. This setup is typically performed once.

NodeBalancer backend IP addresses differ by data center. You can obtain the ACL using the GET NodeBalancer's backend ACL operation.

Original source

This release expands monitoring capabilities with higher API rate limits, support for webhook alert notifications, an increased number of user-created alerts per account, and additional activity captured in audit logs.

Metrics

• API rate limits: The default API rate limit has increased to 300 requests per minute, per service, per account.
• LKE Enterprise metrics: Support for LKE Enterprise metrics is in limited availability.

Alerts

• Webhook alert notification channels. Alerts can be configured to notify users by webhook when alert conditions are met.
• User alerts. You can now configure up to 50 custom user alerts per account.

Logs

• Valkey managed database events. Audit logs now capture additional events related to API requests and configuration changes for Valkey managed databases.

Original source

We’re thrilled to announce the Beta release of Private Image Sharing. This new capability is designed to streamline the secure distribution of custom images across your accounts. Private Image Sharing allows you to share custom golden images with specific users of your account. It simplifies the management of software delivery without the need to manually duplicate or upload image files for each account. To learn more, see the UI documentation or the API documentation:

• Create a share group
• List share groups
• Create a token
• List a user's tokens
• Get a token
• Update a token
• Delete a token
• Get a token's share group
• List images by token
• Get a share group
• Update a share group
• Delete a share group
• Add images to a share group
• List shared images by group
• Update a shared image
• Revoke access to a shared image
• Add members to a share group
• List members by share group
• Get a membership token
• Update a membership token
• Revoke a membership token
• List share groups by image

Original source

Existing clusters created prior to the release on June 22nd 2026 have switched from using WireGuard to Konnectivity for communication between the control plane and worker nodes. When upgrading, this will cause a brief outage. Since clusters created after June 22nd are already using Konnectivity, they are unaffected by this change. This release also includes updates to Kubernetes versions.

Changed

• Konnectivity is now used for communication between the control plane and worker nodes on clusters created before June 22nd, 2026.
• Cluster control planes have been updated to the following Kubernetes versions:
  • v1.36 has been updated from 1.36.2 to 1.36.3
  • v1.35 has been updated from 1.35.6 to 1.35.7
  • v1.34 has been updated from 1.34.9 to 1.34.10

Upgrade notes

This upgrade will cause a brief outage on clusters created before June 22nd, 2026. See Upgrade a cluster to a newer Kubernetes version to learn how to upgrade existing worker nodes.

Original source

We're happy to announce that Managed Databases now supports Valkey. This is part of the limited availability release.

Valkey is an open source in-memory data structure store used as a database, cache, message broker, and streaming engine. Akamai Valkey Managed Database provides a fully managed, high-performance in-memory data store designed to accelerate AI-powered applications while helping organizations reduce infrastructure costs and operational complexity.

Note that the TLS server certificate for your Valkey Managed Database is issued from a public certificate authority (CA) Let's Encrypt. Most operating systems include Let's Encrypt in their default trust store, so most popular clients verify this certificate automatically. This means that you shouldn't need to do anything to verify this server certificate. If your client doesn't use system trust by default or excludes Let's Encrypt, follow your client's instructions to trust widely recognized CAs.

🚧

Valkey Managed Databases differs from PostgreSQL and MySQL Managed Databases, which use server certificates that a private, account-specific CA issues. You can't use this private CA to verify server certificates for Valkey instances. Use public CAs instead. Always keep certificate verification enabled when you configure clients to connect to Valkey Managed Databases.

If you prefer to verify your Valkey instance's certificate against a private CA similar to MySQL and PostgreSQL, create a support ticket.

To learn more, see the UI documentation or Linode API:

• Get Valkey Managed Database advanced parameters
• Create or restore a Valkey Managed Database
• List Valkey Managed Databases
• Get a Valkey Managed Database
• Update a Valkey Managed Database
• Delete a Valkey Managed Database
• Get Valkey Managed Database credentials
• Reset Valkey Managed Database credentials
• Patch a Valkey Managed Database
• List Managed Databases engines
• Get a Managed Databases engine
• List Managed Databases
• List Managed Databases types
• Get a Managed Databases type

Original source