Akamai Segmentation [Private Offer Only] Reviews

Akamai Segmentation [Private Offer Only] has been in use for less than one year. The proof of concept began during summer last year and finished in September. Following discussions, migration to production began at the end of Q1 this year, with agents deployed on all workloads including containers before summer. Currently, approximately half of the workload has blocking mode enabled.

The main use case for Akamai Segmentation [Private Offer Only] is observability and visibility of all flows on our on-premises infrastructure. The second priority is blocking flows to achieve the finest segregation between different workloads.

For observability and blocking flows, we have implemented a policy based on labeling. We have implemented observability to ensure that all secret data has request access only from the secret application server. Currently, we block all flows that do not have labeling such as secret and application secret.

During the project with Akamai Segmentation [Private Offer Only], we have gained observability through agents on our workloads and refined how we request to open flows between different workloads and applications. We make calls to the API from Akamai Segmentation and the API from Panorama, resulting in fine-grain segregation on the workload and a more extensive range on the firewall.

The best features Akamai Segmentation [Private Offer Only] offers are observability, mapping of all flows, and the ability to have granularity for one specific workload or another, which is really useful for understanding the flow and implementing rules to transition into blocking mode.

The mapping of all flows helps my team in day-to-day operations by providing observability. For example, we can take one workload such as one DBMS server and have visibility of all servers that try to connect to this server. We can then request to see only SSH connections on this server, allowing us to see all workloads attempting SSH connections and to define whether those connections are legal or not, thereby blocking all illegal flows. Furthermore, we can request to see all flows in terms of file transfer protocol, focusing on transfers between secret and other zones, which provides excellent observability.

Akamai Segmentation [Private Offer Only] has positively impacted our organization by giving us a better understanding of our flows. We save time implementing segregation and when fixing production issues because we have a complete overview, allowing us to determine whether the flow is functioning or if issues are due to flow problems.

Although mapping is currently fine, Akamai Segmentation [Private Offer Only] can improve by providing a more useful and visually appealing graphical user interface for mapping. While we can automate rules through API calls, this is not entirely possible with the same API. Navigation between different sources and generations of APIs can make it time-consuming to achieve cartography. While labeling is beneficial, there is still room for user experience improvements.

The improvements are not solely due to the Akamai project; they also stem from issues related to CMDB and the information systems of our company, where sometimes the information is inconsistent, causing Akamai to be unable to automate labeling if that information is not consistently provided.

Akamai Segmentation [Private Offer Only] has been in use for less than one year.

Akamai Segmentation [Private Offer Only] is very stable in my experience and works very well.

The scalability of Akamai Segmentation [Private Offer Only] is pretty good. We just need to deploy agents and utilize different gateways. Currently, we only use two gateways for fewer than 6,000 workloads, making the scalability very effective.

Customer support is really good. They take the time to answer questions and possess excellent knowledge about the product, with no issues encountered so far.

In my company, UBP, we have not previously used any other solution before Akamai Segmentation [Private Offer Only]. This is the first time we employ micro-segmentation tools.

We have discussed licensing because we want to migrate progressively from visibility to blocking mode, which led to difficult conversations about costs. However, in the end, I believe the price is pretty fair, although it is not a cheap solution. It is quite expensive, to be honest, but it is really useful, as we see positive results.

The project is really good. The technical team and presales teams are pretty good. However, it is important to take into account that this is a huge change in your organization. It is not a difficult one because you have all the observability, but you need to deploy all agents first to have all the visibility. After that, you need to map the flow and design some rules and then implement them. Do not underestimate the time that you need to implement the rules to understand all flows because application owners do not really have an idea about the flow.

Regarding return on investment, we need to review the flow yearly for compliance regulations. I save time through API calls because I can retrieve all the implemented rules and tags, enabling me to review flows in hours instead of weeks as before, leading to significant time and cost savings, including for mapping the flow and reducing the number of firewall rules.

A specific outcome we observe is that before this implementation, we had more than 45,000 firewall rules; currently, we have only 10,000. In terms of deploying open flows or blocking flows, we now take minutes instead of days due to automation. Our incident response time has also improved, providing answers in minutes about whether the flow seems open, although we lack visibility about the application sending the correct packet, only knowing if one packet is sent through an open path.

We have discussed licensing because we want to migrate progressively from visibility to blocking mode, which led to difficult conversations about costs. However, in the end, I believe the price is pretty fair, although it is not a cheap solution. It is quite expensive, to be honest, but it is really useful, as we see positive results.

Before choosing Akamai Segmentation [Private Offer Only], we evaluated Illumio, NSX from VMware, and Cisco Tetration, the latter now known as Cisco Workload Protection.

The accuracy and reliability of Akamai Segmentation [Private Offer Only] output are pretty good. Some suggestions are excellent, though we occasionally need to perform manual actions, yet we save time overall.

Regarding its governance and security, Akamai Segmentation [Private Offer Only] is used for automation and suggestions regarding flow, but I do not have much insight into its current status. It is useful but not fully finished and requires enhancements in security hardening and clearer guardrails for our data. I would rate this review an overall rating of 8.

I have used Akamai Segmentation [Private Offer Only] for CDN purposes, specifically for Content Delivery Network and static content caching, delivering static assets and content globally near the edge locations.

When a customer accesses our resources or makes a request, all the static content and static assets such as images, PDFs, and documents are delivered from the edge locations near to the browser. This reduces the overall latency, increases page performance, and ensures static content is delivered from the edge locations rather than from the application server. This reduces the overall load on our application server.

Akamai provides custom headers to be passed from the browser to the application servers to achieve personalization based on language, country, and state headers. These specific headers are passed to the application server, and based on that, we can achieve personalization.

Without the CDN and without Akamai, all requests would be flooded to the application server. If Akamai CDN were not in place, the application server could crash due to overloaded request handling.

Previously, page load time was more than 10 seconds, but now it has been reduced to less than five seconds because of static content caching, including libraries, JavaScript, CSS, and other assets that we cache at the CDN layer. We are caching assets such as images, PDFs, and documents, and we are even caching the HTML.

The best features Akamai Segmentation [Private Offer Only] offers are static content caching and dynamic routing of requests to various application servers or to the load balancer, as well as bypassing certain request headers. These are the main use cases.

We had content to be rendered on the homepage based on language and country. These two headers were bypassed from the dispatcher and CDN configuration, and these header details are available to the application layer where the header is read and the respective content is delivered to the homepage based on the language and country headers.

Akamai could pass more headers directly to the application layer, such as user details or other user attributes, which would enable more granular personalization.

These configurations require collaboration with the CDN team, specifically the Akamai CDN team or the Akamai administrating team. These are not within the control of application developers. If Akamai could provide a console where application developers themselves could access configurations either through an API or through some configuration interface, that would be helpful.

The reason is that Akamai configurations are controlled by Akamai administrators, and I have not seen any API exposed for direct manipulation of these headers.

I have been using Akamai Segmentation [Private Offer Only] for more than five years.

Akamai Segmentation [Private Offer Only] is quite consistent and a very stable product.

Because it is a globally distributed CDN network, wherever customers access our application, Akamai's presence is there. It serves content or requests near the edge location, so content does not need to travel to the origin server. This makes it a quite performing and scalable solution.

I need to connect with Akamai either by writing an email or calling them. They are available through these channels.

I would rate their customer service as four out of ten.

I have used other CDN providers such as CloudFront. However, I later moved to Akamai because Akamai is globally available with globally distributed edge locations and presence across the globe. With Akamai, all content can be cached near the edge locations, which ultimately benefits our customers.

It is about user experience and user satisfaction. Earlier, the site was taking too much time to load, but with Akamai Segmentation [Private Offer Only] in place and its features, I was able to cache the content and libraries, which has enhanced overall user experience, page load time, and page speed.

I have a separate account team who manages the cost and handles product procurement, licensing, and license renewal.

I have explored CloudFront as another CDN provider, and they have some personalization attributes that I explored. However, I could not find those convincing, so I moved to Akamai.

On a scale of 1 to 10, I would rate Akamai Segmentation [Private Offer Only] an eight.

I have not explored the AI capabilities yet.

Akamai Segmentation [Private Offer Only] is on Akamai cloud.

Akamai uses its own cloud provider, but the internals of this may only be confirmed by the Akamai administration team. I have no clarity on this.

Organizations should use this product if they need personalization based on request headers such as language or country name. Akamai fully supports these headers.