Amazon EKS Reviews

In my current project, I am handling a US customer who is completely focused on working with LLM and security. Their clients are expected to give us the data sources, and we provision from Greengrass, which works as an agent running on the end client to fetch the customer false alarms. It's primarily focused on the SOC 2 side, where data goes to the SOC dashboard or SOC data source, leveraging LLM to filter how many alarms are false positives versus true positives. In doing this, the NOC engineers observing the SOC 2 dashboard do not have to worry about how many are true positives; our LLM API or tool filters it out and indicates how many true positives and false positives are displayed on the dashboard. This significantly eases the burden on the NOC engineers.

We are utilizing Amazon EKS for our application because most components are LLM and require certain GPUs, so we have specific managed node groups and we also use Carpenter along with HPA in place. Whenever the need arises, process queues are listed in Redis for elastic cache, and all the lists are processed and read from Redis and handed over to the nodes dynamically using HPA. We leverage HPA and Carpenter within Amazon EKS for scaling or scaling out.

Amazon EKS is simple due to its support for diverse AWS tools and various integrations, significantly influencing my application development and management processes. There is the aspect of trust relationships and permissions. Every service we create involves setting a role, and all authentication processes link to a policy, deciding access. This seamless process extends across accounts thanks to ARN (Amazon Resource Names). With the security guardrails in place, services are accessed effortlessly while maintaining high security, giving me confidence in its management capabilities.

The HPA feature within Kubernetes is one aspect I appreciate about Amazon EKS; it's beneficial for scalability. The managed node groups or dedicated node groups with GPU capacity allow us to scale in or out depending on our capacity planning, and Carpenter, which we have provisioned for scaling, contributes to that. These features are not available by default in EC2s or ECS, where you lack control over the nodes. Many people attempt to adopt Lambda functions or serverless solutions, but that approach does not suffice for GDPR and HIPAA compliance as it demands a solid identity of the node and clarity on where it is being provisioned. Hence, we cannot depend on any of the Lambda or serverless components which may be unstable, and this often leads to increased billing due to the dynamic nature of scheduled procedures that require a standalone node rather than a transient one.

When it comes to the integration with IAM, I have two thoughts on the authentication process of Amazon EKS. Previously, when I began using AWS, there was something called the AWS auth config map within Amazon EKS. Initially, only the person who creates the cluster has access to it. Now, if you engage in enterprise roles—as I did while working within the UK for Santander—it presents challenges. Essentially, earlier only the creator had the master role for accessing the node and the onboarding process was rather manual, with companies relying on ServiceNow and other tools for onboarding new joiners or team members. Now, EKS API or EKS CTL has many default settings that are not enabled, you need to enable these. Most clusters are created using Terraform, and you need to create a role that can manage cross-account access, as many customers don't operate with a single account.

My previous employers, such as Fidelity Investment, Nokia, and Ford, have worked across multiple accounts, necessitating single sign-on. This setup allows for cross-account access to the cluster by employing EKS CTL APIs, which leverage single sign-on to onboard team members. As such, once the role has access to the cluster, it can onboard users as a dev user, admin, or tester, simplifying the onboarding process. This way, previously manual tasks can be automated, which is a significant improvement. Earlier, we had to make changes to the config map to onboard users, but with EKS CTL API, this integration between EKS, Kubernetes service, and the cloud side is improved tremendously, alleviating many worries.

Self-healing nodes assist in minimizing administrative burdens in my projects. Coming from a telecom background where I've worked over seven years, I'm familiar with a service called SON—self-organizing and self-healing functionality. At a logical level, these are the layers we interact with, but AWS handles the physical layer through their software components. For instance, if one node is not ready and you enable the auto mode feature, AWS manages that for you—IAM upgrades or any nodes malfunctioning. I've seen these features in the UI; I've enabled them, and every 10 or 15 days, patches roll out. I can check them via AWS Inspector to see if there are any node-level patches or AMI level patches necessary. AWS takes care of these issues automatically. I appreciate that I don't need to manually check the dashboard and apply upgrades one by one, which is a significant improvement.

I measure the impact of Amazon EKS on the organization's management of complex workloads in terms of effectiveness and efficiency through my background in development and systems. Initially, I spent five years as a Java developer before transitioning to DevOps. With my understanding of end-to-end application architecture, I assess workloads based on system and application planning. For example, when I worked on a data lake product in Fidelity Investment, I observed that the cloud onboarding process, including Amazon EKS, had roadmaps extending over five years—from 2019 to 2024. I understand the nuances of enterprise or legacy applications and any system-related complexities. It all boils down to two components: system planning and application planning. Initially, we identify the type of application—whether it is database-related or has high GPU demands. Most applications today involve GPUs, which tend to incur high costs, and often customers are unaware of how to handle dynamic workloads effectively. It's crucial to assess not just one part (system), but various elements CPU, memory, and IOPS since the underlying hardware interacts with those components regardless of domain. First, we need to evaluate the application's requirements—such as its dependency on node storage. With EKS, Kubernetes provides solutions CSI, CNI, and CRI. By understanding the application's demands, I can apply the right Kubernetes configurations for performance optimization, such as taking advantage of Amazon EKS's ability to adjust the container network interface settings to suit the client's workload requirements. This loose coupling allows us to optimize our resources irrespective of whether we're using on-prem or cloud environments.

It has been since 2019 that I started using Amazon EKS. At that time, it was completely new, and many people were not using it just yet; it started from version 1.21, and right now we are on 1.33. Recently, 1.34 has been launched, but it's not yet available in the service catalog; we can see only 1.33. A lot of improvements have been made.

We had numerous add-ons to install manually because Kubernetes is a completely different service than AWS cloud provider, and everyone has opted to use it. After opting, there is an identity that you have to maintain—one at Kubernetes level and one at the AWS provider level. You have to maintain one identity at IAM level and one within the cluster, Amazon EKS. A few things do not make sense within the add-ons, many of the secret providers that read the secret from Secrets Manager and then mount it as a volume. We use a service called EBS CSI driver, which reads the secrets or sensitive data from Secrets Manager and then mounts it as a volume to the pod at runtime. However, that doesn't have a dynamic feature where, if any changes happen in the secrets, it can read and populate in the environment.

Sometimes consider your RDS password or OpenSearch password rotates. Amazon EKS doesn't have that feature to read the dynamic one and consider that the password has changed overnight; there is no functionality from the provider to see the changes and then restart the pod or fetch the new value. This often leads to downtime of 12 or even 6 hours, depending on when you realize it, so that needs improvement.

Nonetheless, mostly on the add-on side, they have developed a lot; earlier we were installing them manually, but now with EKS auto mode, many things VPC CLI and pod identity service—around four plugins—are installed by default, which is a good thing. However, I believe there should be some solution that is self-contained, covering generic use cases.

With the 1.33 release, they have addressed most of my earlier concerns, but I am still looking for some improvements, particularly in CloudWatch monitoring. In IT, we manage two aspects: either the system or the application. Currently, the application logs and monitoring are not very robust in CloudWatch; you can only find things if you are familiar with them. Fortunately, we are familiar, as most of the monitoring involves two types of databases: one is a time series for monitoring data, and the other is an indexing solution for a streaming service. This means we need to get the logs from each node, index them, and populate them on a screen. That part remains a separate service, but if they managed it within Amazon EKS service, where the monitoring is consolidated in one place, you wouldn't need to rely on Prometheus, Grafana, or different services. It would be advantageous to have a consolidated platform for EKS, as Kubernetes is leveraged; monitoring and logging should also be integrated simply by enabling parameters or tags. This would create a self-contained platform where people can onboard and start using it. Currently, I still need to enable logging and monitoring among other things myself; that shouldn't be the case after six or seven years in the market.

On a scale from 1 to 10, I would rate Amazon EKS tech support an eight. Some individuals have a deep understanding of the services and can identify potential bottlenecks, especially with load balancer endpoints and certificate management. The shift from NGINX to AWS load balancers has diminished many previous issues. However, not every support engineer meets the same level of expertise, hence why I rate it a solid eight, which I consider decent.

I have been using Amazon EKS for seven years.

Amazon's customer support has its merits; it is good overall. However, when it comes to enterprise licenses, the quality declines significantly. Startups may not recognize this at first, engaging with support during their initial phase, but they soon discover the lack of expert guidance and the costs associated with it—it's quite expensive.

Positive

I have experience with other Kubernetes engines, such as those from Oracle, Azure, and Google. For instance, I find Red Hat OpenShift to be an excellent competitor. Many have transitioned to Azure due to the hosting incentives it offers for running open AI models. While people explore Amazon EKS or other Kubernetes solutions, the simplicity in moving between platforms remains an advantage since your manifests mostly stay the same, needing only minor adaptations to services. My experience with Red Hat OpenShift tells me it's a robust solution with competitive attributes against AWS.

In terms of ROI, the return on investment, I have clear examples. When we began, we utilized managed nodes for applications needing dynamic processes. Some applications simply required pod creation once data was queued for processing, allowing the node to remain free afterward. For a customer who was not cost-effective—we had provisioned a node that saw little CPU usage but substantial memory consumption—we implemented effective resource quotas and HPA. This setup enables the system to utilize resources dynamically based on the actual demand observed by reading metrics from the Prometheus adapter. Notably, the adapter isn't an out-of-the-box feature provided by Prometheus; you need to create your own adapter for it. Using tools HPA and Carpenter allowed us to scale resources based on requirements. Initially, not having them resulted in an unoptimized solution. However, with these tools in place, we witnessed a reduction of costs by approximately a third—if it was $100 beforehand, we brought costs down to $25.

Regarding the pricing aspect and the licensing cost of Amazon EKS, sometimes it is not clear. Most discussions revolve around the data transfer costs from one region to another, and there are certain concerns regarding GPU nodes. However, if you optimize your node usage, with tools such as Kubecost, you can analyze how effectively you utilize your nodes. If you manage to optimize usage, you won't face steep costs. Otherwise, the cloud provider will certainly benefit from inefficient usage. Ultimately, it's not out of the box—if you want to monitor costs effectively, applying separate tools and acting accordingly in advance is essential.

I notice key differences between Amazon EKS and its competitors, analyzing both pros and cons. The seamless integration is sometimes lacking in other offerings. When managing software in platforms Kubernetes—including EKS, AKS, GKE, Rancher Kubernetes, and Oracle's Kubernetes engine—I've faced specific challenges, particularly with user management in Oracle's solution, which isn't as seamless as it is in Amazon EKS. Comparatively, OpenShift from Red Hat has notable strengths. Oracle is making improvements, especially with its longstanding database solutions. For cloud providers, though, OS from Red Hat is a formidable competitor, offering robust out-of-the-box solutions around resource limits and dashboard configurations that do not require command-line interventions.

The review suggests that people considering Amazon EKS should heed some recommendations. They often attempt to enforce infrastructure as code with tools Terraform or HashiCorp to maintain workspace and all. I advise using services within a single environment, especially for LLM applications. It's prudent to have multiple LLM sources across various cloud providers while utilizing the same keys within your AWS environment.

My second piece of advice is to establish a separate CI/CD platform independent of AWS. This keeps things loosely coupled; with minimal tweaks in CI/CD pipelines, you can seamlessly migrate from one platform to another—say from EKS to AKS to GKE or OpenShift—thus keeping the focus on feature development rather than migration headaches. This leads to a modular approach in your code and infrastructure, ensuring that only the cloud provider specifics require adjustments.

Overall rating: 8 out of 10

Public Cloud

Amazon Web Services (AWS)

My use cases for Amazon EKS involve different types of workloads, mostly web-related and mobile application related, to orchestrate deployments and make application release easier, smoother, and faster.

What I appreciate best about Amazon EKS is that it's a great solution, especially for teams who search for flexibility and who are in active development of microservices architecture. It gives flexibility not only for DevOps but also for developers to control infrastructure through code, such as through the GitOps approach, which releases a lot of time and effort for system engineers and DevOps engineers to do their business and not provision servers by their own. Scalability and flexibility are the most useful cases there.

The benefits I have seen using Amazon EKS are substantial. Kubernetes is a complex structure, and if you have it self-maintained on your bare metal devices, it's first a pretty big chunk of the infrastructure. Plus, it's very complex and hard to maintain. Not all engineers have the knowledge to control a Kubernetes cluster. Having it as a service reduces release time dramatically. Amazon controls the versions, upgrades, security components, and related elements. It's easy to do system upgrades, even release another cluster in a matter of a few hours and move all workloads to the latest release of Amazon EKS if needed or for development environment testing. This would be much more difficult if you control your Kubernetes cluster manually as self-hosted.

What could be improved in Amazon EKS is the documentation. It's pretty dynamic, moving too fast, and sometimes the documentation doesn't reflect the migration between changes, especially if you use some non-native vendor enterprise components and CRDM modules. If you use only AWS UI, it's pretty hard to debug something in Amazon EKS. You need to be aware about kubectl or another toolset which allows you to dive deeper into the Kubernetes details. Not always do software developers have such expertise. If they could improve their debug capabilities, toolset for debugging, or maybe integrate it with their AI, such as Amazon Q, to support the developers, it could be valuable for developers.

I have been using Amazon EKS practically from the day they implemented this solution, which has been many years already.

I can easily scale up or down with Amazon EKS. Currently, Kubernetes and Amazon EKS itself have many different vendor solutions, native solutions or vendor solutions for scaling. It's easy to control and very cost-efficient.

The customer support from Amazon could be better. I find it problematic that customers who don't have a big budget are not able to use the customer support. If you don't have your support subscription, you're only able to use forums, which is challenging because sometimes software can have issues or the setup is pretty tricky and not reflected in the documentation.

Support quality depends on which engineers you're talking with. For bigger clients and companies, AWS dedicates an agent or manager as a point of contact for the specific team, and you can easily reach them and discuss initial key points. It's great. It doesn't always do what you would expect, but at least it's a very good and fast starting point to solve issues.

I would rate their support a seven out of ten.

Positive

I have previously used different solutions before Amazon EKS. For simpler solutions, we used Amazon ECS, which is a native Docker orchestrator. It's much simpler than Kubernetes but does the job well for a simple setup. It's a bit more difficult in the provisioning and control of components, but it works fine for static infrastructure. We used various solutions, from self-hosted Docker containers for ECS, Fargate, to Lambda functions. The choice depends on what you actually expect from your application and infrastructure.

Regarding the pricing of Amazon EKS, if we discuss EKS itself, it's relatively cheap at $75 for deployment for the control plane. However, for running a Kubernetes cluster, you need more resources even for the simplest deployment of any modules. It could be very expensive, but it's mostly about how the architecture is built and how the team controls the resources. It's not about Amazon EKS directly, but related.

I have used Amazon EKS integration with IAM. It's basically one of the core parts of the configurations not only for access to the cluster but also for the services themselves to provide them access to other Amazon resources.

My experience with the deployment in Amazon EKS is that it's easy and has many options for how you can control your deployment in Kubernetes from your native kubectl to the GitOps approach. I strongly support the GitOps approach to control everything and give developers access to infrastructure through GitOps and full code-controlled infrastructure. It's easy when you integrate everything and it works fine.

I would recommend Amazon EKS to others if they're sure that Kubernetes is what they would need. On a scale of 1-10, I rate Amazon EKS an 8.

Public Cloud

Amazon Web Services (AWS)

The use case for Amazon EKS is that we have our multiple pods and services running on the particular microservices application, so we have to integrate and auto-scale the Amazon EKS cluster from the Amazon EKS cluster and pod management services.

If any traffic increases on the application, we have set the load balancer and auto-scaling via the Amazon EKS cluster, the managed cluster.

The value of Amazon EKS for us is due to our microservice-level architecture, where we need to automate and have a fast, scalable application, allowing us to directly configure the Amazon EKS cluster in the application, which will make it very easy to run our application smoothly and scalably.

Amazon EKS's self-healing nodes help minimize administrative burdens in my organization by automating through all of Amazon EKS. We have used multiple types of automation tools which we directly integrate for the deployment purpose of the Amazon EKS cluster. We have integrated them with the Docker side of Amazon EKS, allowing the container service to run over there, so it is directly deployed for the administrative level of the Amazon EKS cluster.

The benefits I have seen from Amazon EKS include a fully managed Kubernetes service for the control plane, the API server level, etcd scheduler, and controller. There's no need to worry about patching, scaling, and maintaining the master node. There is high availability over multiple availability zone control panels, and security compliance is guaranteed for IAM; AWS IAM users authenticate and access the control from the support VPC isolation and security group network policy.

The integration with IAM helps enhance our authentication process because IAM basically helps with access. Nobody can enter with any kind of access, and any kind of vulnerability will be showing in my application. If I set an IAM user to that Amazon EKS cluster, that user will have limited access, and that application will run through that IAM user only. It is very beneficial, and for security purposes, it's also important because vulnerabilities will be found and block all the vulnerability and security issues if you set an IAM user to the Amazon EKS cluster with limited access.

We have not automated patches to be applied for the Amazon EKS cluster because it will resolve live production services. We directly and manually configure and update those patches if any patches are required for the particular application.

I did not configure all related applications since we are running only one application, which is good from my end. To improve the regularity, the IAM Access Analyzer could detect risk permissions, so the IAM Access Analyzer could be applied for this.

From all the AWS services we are using, I have been working with Amazon EKS for the last three years. In that EKS, I've been using it for only one application that will be running over there, so I've been using it for nine to ten months, probably one year.

I have communicated with the technical support of Amazon EKS. When we were trying to configure the Amazon EKS cluster for the first time, we used technical support. If there is any kind of debug or related issue that we cannot find from our end, then we can go directly to the support team for Amazon EKS. It's very helpful and needful; whatever kind of issue we are facing, they immediately tackle it, debug that issue, and resolve it as soon as possible. We have found some related networking or triggering issues on the application side, and that issue was resolved from their side as well. There is no issue from the technical side support; it's always beneficial and helpful.

Amazon EKS is stable and reliable. The control plane is fully managed by the AWS service, so there is no need to run the Kubernetes master, which is very reliable. There are multiple availability zones in the regions, meaning no single point of failure, and 99% of the time, our application will have uptime with the Kubernetes API server.

Amazon EKS is highly scalable; as per the node cluster, it will provide EC2 or Fargate up to 10,000 nodes. It's a very scalable cluster, fully controlled by the Amazon EKS plane.

The support of Amazon EKS for AWS tools integration influences my application development and management process because it is on the AWS side, and the Amazon EKS managed cluster is provided from there. We didn't need to manage etcd and those control management tools; it's totally handled from the AWS side, making it very beneficial. We just monitor and configure all the related services and manage them via the pods and cluster-related aspects, while all the configuration support and configuration-related things via the control plane are directly managed by the AWS side of the services, which is very beneficial for us.

Positive

Before Amazon EKS, we did not use a different solution for these use cases. We are directly running on it. If there is any application running on a small-level architecture, we can directly build as per the build process. We follow the build process step-by-step to build our application via the production environment as well, without any Amazon EKS cluster.

We did not participate in the deployment and the initial setup of Amazon EKS; we are using it as per our need. We have an AWS service account, so as per our need, we are using those services. For whatever AWS service we have to use, we have a paid service account, and as per our need, we directly use it.

I am aware that pricing for Amazon EKS should be based on the cost structure, where what cost is planned depends on what we are using and serving on the instance. We have applied tag resources, depending on what kind of services we are using, and they provide the cost as per the service. It would be better if, when the application is running slower, the price would be less than that application; it could be implemented in the future.

Before choosing Amazon EKS, we did not evaluate other options or other vendors; we have not worked with any other tools till yet. We can directly deploy our application via Kubernetes and Docker, Docker, and Docker Compose files, and Jenkins via the automation.

With the IAM service, we have assigned an IAM policy, IAM user, and policy with limited access for that IAM user as per the needs of the application.

In my opinion, Amazon EKS is very good. It's very easy to monitor Amazon EKS, and the highly built architecture will be smoothly running over this Amazon EKS cluster.

On a scale of 1-10, I rate Amazon EKS a 10.

Public Cloud

Amazon Web Services (AWS)

We have been working on a use case where we need to deploy an application in Amazon EKS, which is a Kubernetes cluster. Kubernetes is a managed service provided by Amazon, and if we want to deploy any applications in Amazon EKS, such as application A, I want my application A to be more scalable, more tangible, and I want to deploy this in an Amazon EKS cluster. Then I check for any open source Helm charts, configure them, and deploy that Helm chart in the Amazon EKS cluster. This is how our day-to-day work goes. In general, we also deploy applications such as Apache Spark in the Amazon EKS clusters.

The features of Amazon EKS that I find most valuable include IRSA and IAM Roles for Service Accounts. While creating Amazon EKS clusters, Kubernetes offers a feature where we need to create an OIDC provider. Once configured, the authentication and authorization in the Kubernetes cluster is done by service accounts. Through the concept of service accounts, all the pods utilize IRSA, which is called IAM Roles for Service Accounts. By integrating AWS IAM roles with Amazon EKS service accounts, we can leverage other services from Amazon EKS. For example, if we want to access S3, Secrets Manager, or EC2, the concept of IRSA helps us integrate with external services of the Amazon EKS cluster easily. Additionally, Amazon offers Karpenter for scaling workloads and minimizing billing, along with managed node groups and advanced scheduling to manage our pods on different node groups.

To measure the impact of Amazon EKS on my customers' ability to manage complex workflows effectively, scaling in and scaling out is one of the key aspects for us. Since all our workloads are batch workloads that are intangible and unpredictable, we cannot keep nodes stale 24/7. Accordingly, scaling is of utmost priority. The appropriate node must spin up based on the workloads created at a given time, and pods should schedule on that node so that workloads run. For instance, if there are no workloads, there is no reason to maintain 100 nodes in the cluster, so scaling in and out is essential for not wasting resources or budgets.

One area of Amazon EKS that could be improved in the future is related to the behavior of the cluster autoscaler. We need enhancements so that scaling in and scaling out happens more effectively. Currently, the cluster autoscaler lacks visibility on the Kubernetes labels of a node group. The cluster autoscaler should at least be able to check the labels of the Kubernetes nodes, which is a necessary feature.

My experience with Amazon EKS is three years, and it has been very interesting to understand and easy to collaborate with other AWS services. It has been good working on Amazon EKS for the past three years.

Initially, I did not face challenges with the deployment of Amazon EKS, but I was not very familiar with Kubernetes initially, so it took me some time to understand Kubernetes first. The platform could be anything, including EKS, GKE, or AKS, but understanding Kubernetes was the first step necessary. After gaining familiarity with Kubernetes, Amazon EKS provided me with a good platform to work on, and I later cleared my CKA certification with a 95 percentile.

My impression of how stable and reliable Amazon EKS has been for me is positive. The upgrade process is also very fruitful, happening swiftly and without hassle or issues, so I have not faced numerous challenges. Moreover, the control plane is quite stable in Amazon EKS, and I find it to be 100% available.

Self-healing in Amazon EKS refers to what happens if any node becomes unreachable.

In our case, while I am not much sure about self-healing nodes, we utilize the cluster autoscaler in Amazon EKS. If any node is not ready, the cluster autoscaler ensures that it is removed from the AWS auto-scaling group and replaces it with a new node in the cluster.

My interaction with technical support and customer service at Amazon has been generally helpful, but they sometimes do not provide direct solutions. They tend to divert the conversation before giving a solution, which would be easier if they provided direct answers.

Once, we faced a situation where an EC2 instance got deleted due to unforeseen reasons. We reached out to support and inquired about the possibility of restoring our instance. They informed us that there was no possibility to bring it back, which felt like a dead end. I believe there should be a recovery solution available for at least a few hours so that we might bring it back; instead, we had to start again from scratch.

Positive

I usually participate in the deployment and setup of Amazon EKS. We create Amazon EKS clusters from scratch, deploy applications, and integrate them with all the AWS services.

Within the last 12 months, I have only been working with Amazon EKS. Currently, I have not been working with anything else other than Amazon EKS.

For the automated patching feature of Amazon EKS, we currently use EKS baked AMIs, which are straightforward to integrate with the Amazon EKS cluster. If we want to add additional packages or anything by boot time, it is very simple to do so while working with Amazon EKS. We can utilize a user data script to perform any patches, software upgrades, or installations, all accomplished at the instance creation time using EC2 node templates.

On a scale of 1-10, I rate Amazon EKS an 8.

Public Cloud

Amazon Web Services (AWS)

It is a managed service, a Kubernetes cluster, specifically for Amazon EKS. Whatever application is going to deploy on the cloud, cloud provided this solution, a managed service cluster, a Kubernetes cluster. In that scenario where we will use for seamless and zero downtime, we are using Amazon EKS.

The major advantage of Amazon EKS is that it is a managed service. Whatever error or downtime, if we are dealing with an on-prem Kubernetes, we have to understand the root cause. If the control plane is down, understanding and fixing takes time. But AWS provides a solution, Amazon EKS, where we are not worried about any control plane components, such as ETC, other API servers, etc. It is a significant advantage, as AWS continuously checks for problems. If they occur, they will fix them immediately. They will also configure the backup from the background. As an end user, we are not able to understand any kind of downtime. For us as end users, it is always working for the managed services.

When dealing with Amazon EKS, as an end user, we also configure the IAM policies, role, and responsibility for users managing the cluster and node cluster. The user-specific permissions determine whether they are able to deploy applications to the managed service, whether at root level, admin level, or developer level with view access. We make decisions accordingly and provide the IAM permissions.

We have RBAC and context, two major parts of the Kubernetes services that provide security and the authentication and authorization process. We implement context and RBAC to secure our Amazon EKS cluster.

Because it is Kubernetes, these services need to be integrated with the Kubernetes repository. ECR is a repository, an Elastic Container Registry. When creating or integrating any images with updated builds, we create updated Docker images, push them into ECR, and integrate our Amazon EKS services with ECR. It syncs with that repository, so whenever it identifies new Docker images, it will pull and deploy them into the Amazon EKS cluster.

When setting up an Amazon EKS cluster, we define the number of nodes with minimum, actual, and maximum parameters. For example, with a minimum of two nodes for normal load, only two nodes will always be running. If it identifies increasing server load, it will automatically increase to two more nodes if we have set the maximum to four. In the Amazon EKS cluster configuration background, we specify load thresholds at 70% or 80%. It will identify that and increase or decrease nodes accordingly. If load changes persist for more than 15 minutes, it will take appropriate action. We define an auto-healing process there.

The automatic patching is valuable because it is a managed service. Whatever patching is required, the vendor itself will provide communication. If we provide confirmation, we will provide the upgradation time window. AWS itself will do all kinds of patching during that specified window to upgrade the Amazon EKS cluster.

On-premises Kubernetes requires daily updates. With managed services, the Amazon EKS version upgrades are very helpful. The managed services handle the control panel upgrades, and they will upgrade node dependency software by default. Sometimes we will check if the node dependency software needs manual updates.

The major advantage is reduced setup time. The Amazon EKS setup is much simpler compared to on-premises AKS setup, where the control plane configuration is very difficult. It is very flexible as we configure the required number of nodes into Amazon EKS, and it starts working. We get high availability and scalable architecture. Even if the control plane has issues, AWS will understand, control, and take immediate action.

We only need to ensure that Docker images are pushed to ECR are correct, and Amazon EKS will handle the deployment. The major advantages include reduced time, high availability, and scalability. From a security perspective, AWS has multiple security layers. We also implement IAM roles, different ILBs, ingress controllers, and multiple security features. CNI implementation on top of Kubernetes is also available.

The costing perspective could be improved. With normal on-premises servers using Kubernetes services, the costing might be slightly higher compared to other Kubernetes vendors. If the pricing becomes more comparable and they match other vendors while providing more flexibility, it would be more advantageous for AWS.

The solution has been in use for more than four years.

The deployment has been confirmed as successful.

There have not been any gaps felt between Amazon EKS and AKS. Whatever capabilities AKS has, Amazon EKS has similar capabilities feature-wise.

The service is very straightforward. The official manuals provided are very helpful. We have not experienced any discomfort or hidden aspects.

Whenever we face challenges or have questions about different platforms or tech stacks, or if we need to verify support or integration possibilities, we raise a ticket. They will set up a call, guide us, or provide solutions regarding integration with AWS or Amazon EKS.

The service is very professional, rated five out of five. When we raise requests, they follow their process and are always available to support us.

Positive

Having worked on both AWS and Azure, AWS is very straightforward and helpful to implement, both as a support engineer and as a developer. The AWS support team is very knowledgeable and helpful. When requests are raised, they take immediate action. It is recommended that everyone should consider AWS.

Our organization maintains a strong team. For major projects, we first work on the architecture perspective. With well-designed architecture, 90% of potential problems are prevented. Being a managed service, we focus on security and managing node services, along with the application perspective.

We are not concerned about the Amazon EKS cluster setup as it is a managed service. We only need to add nodes and utilize the features Amazon EKS contains. This reduces our effort and is very helpful for our organization.

The reviewer rated Amazon EKS 10 out of 10.

Public Cloud

Amazon Web Services (AWS)

Amazon EKS's main use case is using compute in a highly containerized format. Building and running applications is my primary use case for Amazon EKS.

I currently use Amazon EKS to run a web application. I have my own website which I host on Amazon EKS.

Currently, I use Amazon EKS to host a web application, but Amazon EKS is so versatile. I have used it previously to host a whole host of different applications.

One of the features I really appreciate about Amazon EKS is its ability to integrate with other AWS tooling. That is very useful because it is part of the wider Amazon ecosystem. For example, if you wanted to grant access to a specific pod within Kubernetes, you could use Amazon EKS to provision a service account for that pod to interact directly with a bucket. You would not get this type of benefit if you used Kubernetes out of the box which was not running on an Amazon service. The ability to integrate with other Amazon tooling and do it at a very granular level is something I value.

From a security perspective, Amazon EKS is very strong. That granularity allows for specific pods to have access to specific buckets or specific EC2 instances. It allows for the principle of least privilege at a very granular level, which improves the security of using the tool.

Amazon EKS allows me to use applications and deploy them in a specified format and to scale that across huge numbers. Because you can deploy Amazon EKS via Terraform or other infrastructure as code tools, it allows for a repeatable architecture, which is brilliant because once it is developed, it is very simple to then deploy further versions for potentially different customers or different versions of the same application.

One limitation I have found with using Amazon EKS is that there is a very big learning curve. It is very complicated to use the tool. I have used Google's GKE which offers an easier framework because they offer managed clusters, which are called Autopilot clusters. With that, a lot of the management is abstracted away and managed by Google. Amazon does not have the equivalent of that, so you would have to manage everything yourself. In some scenarios you would want to do this because you might want that level of granular control. But if you are running a proof of concept or developing in a very quick way, it becomes very difficult and time-consuming to get it initially running.

Another limitation I have found is the management overhead of upgrading Amazon EKS. Because Kubernetes has frequent updates, you have to manually trigger those in AWS, which can be quite time-consuming, especially if you are managing many clusters. Amazon could potentially make it easier by automatically triggering upgrades, but it is definitely a high toil activity, especially for smaller teams.

I have been using Amazon EKS for around four years.

Amazon EKS is very stable. You can set up your clusters to have however many nodes you want, which allows for greater stability when users are using it. You are able to upgrade whenever a new upgrade comes out.

Amazon EKS's scalability is brilliant. You can easily scale from zero nodes all the way up to the tens of thousands, probably even higher. There would not really be a bottleneck in terms of scalability. You can have it however you wish.

Customer support for Amazon EKS is brilliant. It uses AWS's customer support which could be as quick as probably five-minute response time or 15-minute response time. Whenever I have contacted them, I get responses every single time, same day, and Amazon's expertise is immense. There are no complaints there.

I have previously used GKE from GCP. You would only really use that if your other workloads are running within Google Cloud as well. If your workloads are running in AWS, using Amazon EKS is better because it allows for better linkages between different products within that cloud platform.

In terms of deployment speed, if Terraform files are configured to deploy on Amazon EKS and they are written in a very efficient way, deployment could be as quick as five minutes. Compared to deploying on a traditional virtual machine in a data center, which would be hours, that is a big time saving. You can very easily save over 50% of the time if you are deploying on Amazon EKS compared to in a traditional manner.

Return on investment with Amazon EKS is positive, because it allows applications to be hosted. In terms of money saved, if a team was to go from not using autoscaling to using autoscaling in terms of how much user traffic is actually generated, teams could easily save over 30% of costs just from that one tool being enabled alone.

Pricing for Amazon EKS is quite good, because you can choose the instances which are running under the hood. If you wanted to use smaller machine types, you can control your cost quite well. You are also only paying when those machines are up. You could configure your nodes to scale down massively when you do not need them up all the time. It is very cost-efficient due to its flexibility.

I did not really evaluate other options before choosing Amazon EKS, because if workloads are run on AWS, you would only really use Amazon EKS if you wanted a managed Kubernetes service. Amazon does not offer another service which would compete with that.

Overall, Amazon EKS is a very good tool to use and it is commonly used in the industry. However, GKE is easier to use and some of the management is abstracted away, which is not the case with Amazon, so that is one drawback. The need to upgrade yourself as well is another limitation. I believe with GKE Autopilot, you do not have to do that because Google manages it under the hood. The fact that it is not as automated as similar Kubernetes products on the market is what takes off those last two points.

I did not purchase Amazon EKS through the AWS Marketplace. I bought it directly through Amazon on their AWS platform.

I would recommend using Amazon EKS if your workloads are running on AWS. If your workloads are running on Azure or GCP, you probably would not want to use it just because you would get better linkages if you were using the cloud platform's own Kubernetes service. I personally prefer GKE because of the Autopilot feature, but Amazon EKS is a brilliant tool if you are already on Amazon's platform. I have provided a review rating of 8 out of 10 for this product.

We are the end user of Amazon EKS. I will provide context for clarity. In my previous project at Johnson & Johnson, we had assets including Jenkins running on Amazon EKS cluster. This is how we were using it as an end user.

One of our use cases for Amazon EKS involved Jenkins running as a pod. We had an EBS volume in AWS that handled all storage-related tasks, while Amazon EKS managed the heavy lifting of ensuring Jenkins was always operational. Additionally, we integrated Prometheus and Grafana for data and metrics, which also ran as pods on Amazon EKS.

We have also utilized Amazon EKS's integration with IAM.

The most valuable aspect of Amazon EKS, from my perspective as someone who has worked with on-premises solutions, is that it eliminates manual setup requirements. Amazon EKS handles everything automatically, removing the effort of manual configuration that is necessary with on-premises solutions.

The auto-scaling capabilities are particularly notable. Based on the nodes configured, it automatically scales according to minimum and maximum node parameters. The load balancing functionality is another significant feature that makes Amazon EKS exceptional.

Amazon EKS's self-healing nodes have significantly minimized administrative burdens in our organization. This functionality stems from the auto-scaling capability of Kubernetes. From the Amazon EKS perspective, it provides features for setting up nodes, giving users and administrators the flexibility to ensure applications running on those nodes remain operational.

From a DevOps engineer's perspective, the IAM roles system could be improved. When creating a cluster, we need to create and assign roles. If this process could be simplified, especially for users with limited AWS knowledge, it would be beneficial. Currently, users need to understand IAM fundamentals, how it works, and how roles and users are defined.

It would be helpful if Amazon EKS offered ready-made templates, similar to AWS's default VPC option. This would make the service more accessible to new users while maintaining its functionality for experienced users.

We have not encountered any issues with Amazon EKS's automated patching feature for our Kubernetes clusters.

We have been using the Amazon EKS cluster since August 2023, which is more than two years.

For the initial setup, since we were a private organization, we had to establish the VPC, ensuring all due diligence with private and public subnets and internet gateways from the network standpoint.

When launching our Amazon EKS cluster, we had a dedicated cluster that needed to be bound with EBS to manage volume requirements. This setup supported our Jenkins implementation, followed by other tools such as Prometheus, Grafana, and deployments managed by Helm.

While the process wasn't entirely straightforward, requiring prerequisites such as IAM knowledge and strong understanding of Kubernetes, the managed service aspect of Amazon EKS makes it significantly easier compared to on-premises solutions.

Amazon EKS has proven quite stable. We haven't faced any challenges, and it consistently delivers on its committed SLA. There haven't been any bottlenecks in terms of reliability.

In terms of scalability, Amazon EKS deserves a perfect score. However, regarding storage, we must rely on services such as EBS, considering the ephemeral nature of pods. The load balancing capability and scalability are excellent. Regarding pricing, based on experience, Azure Kubernetes Service (AKS) offers slightly better pricing compared to Amazon EKS.

Our interaction with Amazon EKS technical support has been primarily during our disaster recovery (DR) region setup. While exploring options for potential Amazon EKS downtime scenarios, we found Velero to be the only backup option, which is both overwhelming and complicated to set up.

Our interaction with AWS customer support has been minimal because operations ran smoothly. When we did interact with them regarding organizational issues, they were courteous and resolved problems promptly. Based on these experiences, the technical support deserves a rating of 9.5 out of 10.

Amazon EKS was straightforward to set up. I personally participated in the initial setup and deployment of Amazon EKS.

Amazon EKS's support for AWS tools integration has positively influenced our application development and management process. In 2023, when Johnson & Johnson segregated to form Kenvue, our team was responsible for building the entire DevOps infrastructure.

For any startup implementing Amazon EKS cluster for infrastructure or DevOps needs, the solution is excellent. It minimizes configuration time and offers a user-friendly experience that allows even less technically skilled individuals to complete basic cluster setup tasks.

Our entire Jenkins pipeline is fully onboarded on Amazon EKS cluster, which we use as a fully managed cluster for our CI/CD workflow. End users, unaware of the backend operations, benefit from Amazon EKS's management of scalability and auto-scaling capabilities.

I would rate Amazon EKS 8 out of 10. While it excels in usability, scalability, and high availability, there is room for improvement. The addition of ready-made templates, similar to EC2's default security group feature, would enhance the user experience for newcomers.

Integration templates for new users would be a valuable addition to the service.

Private Cloud

Amazon Web Services (AWS)

For Amazon EKS, the usual use cases I have been working with include many microservices where we cannot orchestrate in a better way in the ECS, which is an AWS native component. The major reason for moving to Amazon EKS is that if we have a microservice that takes more time to do the job, we need to return it while also running some other small microservices in parallel with that application, which we cannot do in ECS.

We moved to Amazon EKS where we have the feasibility to do parallel jobs with different microservices within the same pod, since we can run multiple containers in one pod. This helps us mitigate challenges in the company, and it works smoothly and fast, providing good performance and strong security. That has been our journey towards Amazon EKS across all customer platforms.

The most valuable feature of Amazon EKS is the add-ons service, which includes the Ingress feature that allows us to connect to both public and internal-facing load balancers. The best thing I have found is the management; using Rancher management, we can connect to Amazon EKS and manage the deployment from the UI without always needing to use the AWS console. We can create our own Rancher portal and directly manage the deployments and all other tasks from there.

Amazon EKS is a major tool for our application functionality and job purposes; it helps us at the orchestration level, allowing us to not worry about the entire deployment and service migration. We manage everything from Amazon EKS, and it's also very convenient to set up CI/CD deployment through GitHub. Additionally, we can utilize AWS native services such as CloudDeploy, so in both ways Amazon EKS has been convenient for running our applications.

I believe there is room for improvement in Amazon EKS, particularly regarding security; if Amazon EKS would provide more options for cluster-based security, it would be beneficial. Currently, it's completely managed by AWS, but I suggest that if Amazon EKS could allow monitoring of the backend of the nodes or workflows, it would greatly help users. Sometimes, AWS's shared responsibility model means that if any issues arise, the misconception lies with the users.

For instance, failures from containers running on nodes in AWS data centers can halt our workflows, especially when running in single availability zones. If AWS could enhance user interaction for improving security, it would be very helpful.

I have been working with Amazon EKS since 2017, which amounts to approximately eight years.

I have utilized Amazon EKS's integration with IAM through the service account, which is a great feature because we don't need to depend on storing secrets in Amazon EKS. We can directly use service accounts and rotate our tokens every 24 hours, which helps us achieve fine-grained access for both the user and the cluster-wise.

Compared to different cloud providers, AWS EKS pricing and licensing is absolutely reasonable and one of the best options available.

In terms of stability and reliability, I can say that among all options in the market, Amazon EKS is very reliable. I haven't experienced much downtime in the Amazon EKS cluster, so I can confidently say it is stable.

Amazon EKS has been quite scalable; people nowadays are moving to multi-AZ setups. When we choose Fargate, the beauty of Amazon EKS is that we can run multiple containers from different availability zones within the same pod. This is beneficial for availability and scalability because, using ReplicaSet, we can ensure that our containers remain at the desired count, automatically pulling new containers whenever one goes down.

I often communicate with Amazon EKS technical support, and my impression is positive. When I was initially setting up, I needed to understand a few things from AWS, and they provided substantial support, being very professional and helpful.

I had to address technical support when one of our nodes was suddenly terminated while utilizing a single availability zone, which caused application downtime and business disruption. However, AWS management tackled this situation very well by providing us with a solution that enabled us to shift to multi-AZs, as AWS guarantees 99.9% availability but acknowledges the need for users to avoid relying entirely on a single AZ.

Positive

I usually participate in the initial setup and deployment of Amazon EKS; I've done this in four projects, giving me good hands-on experience with Amazon EKS.

My usual deployment and initial setup process for Amazon EKS is straightforward. First, we need to spin up the cluster, which involves providing the cluster name, VPC details, subnet details, security details, and network mode—either AWS VPC or a customized network mode. There are several options, including attaching an IAM role and adding on features such as proxy connection and network protection. After spinning the cluster, we start the Kubelet client installation from where we can manage the cluster and begin deployments using YAML scripts and manifest workflows.

Recently, Amazon EKS launched an automated patching feature that allows us to schedule a time frame for cluster scaling up, down, and patching, which has been very helpful across all aspects.

I usually measure the impact of Amazon EKS on managing complex workflows by evaluating performance, specifically how the containers are available and performing. Based on application latency, we can determine that Amazon EKS performs well. We measure in this way because latency is the differentiator between every service; with ECS, latency can be slightly higher, which causes user difficulties when accessing applications.

Overall, based on everything I've described about Amazon EKS, I would rate this solution eight out of ten.

Public Cloud

Amazon Web Services (AWS)

I used Amazon EKS throughout my internship while working on Docker-based deployments, Kubernetes orchestration, and cloud infrastructure tasks at Cognizant.

I used Amazon EKS when working as an intern at Cognizant, where it was used to deploy, manage, and scale containerized web applications. Our workflow started with building Docker images, storing them in Amazon ECR, and deploying them to Amazon EKS clusters running on EC2 worker nodes with CI/CD pipelines. We used many tools; for example, Jenkins was part of our CI/CD pipelines that automated the build and deployment process.

Additionally, I worked on application deployments, updating Kubernetes manifests, managing pods and services, and verifying application health. Amazon EKS acted as a central platform that connected Docker, AWS infrastructure, and DevOps automation into one consistent system.

I used Amazon EKS during my internship at Cognizant as part of a cloud and DevOps-focused environment, where it served as the core Kubernetes platform to run containerized applications built with Docker, deployed through CI/CD pipelines, and hosted on AWS infrastructure. We deployed numerous web applications, and we wanted to learn Amazon EKS through dummy projects with dummy web interfaces. Beyond dummy projects, we also deployed some client websites into the Kubernetes environment and managed traffic, although I cannot name the clients.

Amazon EKS is an excellent choice for organizations already invested in AWS. I recommend having a solid foundation in Docker, Kubernetes basics, and AWS core services before implementing Amazon EKS. Using infrastructure-as-code tools and following AWS best practices can significantly improve maintainability and security. Amazon EKS is particularly strong for enterprise environments and microservice-based architectures.

Amazon EKS is ideal for teams already using Docker, CI/CD, and AWS infrastructure, which our team was already utilizing. I strongly recommend learning Kubernetes fundamentals and AWS networking, containers, and security before using Amazon EKS in production, as it positively impacted our organization by making it easy to connect all our existing AWS services.

I deployed Docker applications to Amazon EKS using CI/CD pipelines, integrating with EC2, ECR, IAM, and automated workflows.

The most valuable feature of Amazon EKS is the managed Kubernetes control plane, which allows teams to focus on DevOps and application workflow instead of cluster maintenance. Another major benefit is how naturally Amazon EKS fits into the AWS ecosystem, integrating with EC2 for compute, IAM for access control, and Amazon ECR for container images. CloudWatch for monitoring creates a complete DevOps pipeline. The self-healing nature of Kubernetes combined with AWS scalability makes the environment reliable and suitable for real-world workloads.

The most promising feature, which I prefer the most, is its integration with all the AWS services, including EC2, IAM, VPC, ECR, and CloudWatch, making it a key part of my workflow.

Amazon EKS works very well with Docker-based container workflows; it is highly scalable and self-healing, complemented by its rolling update capabilities.

There are some drawbacks regarding Amazon EKS; pricing can increase as clusters and workloads scale, and there is an initial configuration learning curve. A beginner has to learn about IAM networking and cluster setup, plus improved built-in cost visibility and simplified monitoring tools could be beneficial.

Pricing can be improved, especially for small teams or landing projects, and the initial setup, as well as understanding IAM networking and cluster configuration, can be complex for beginners; improving this would enhance the experience. Troubleshooting sometimes requires deeper AWS and Kubernetes knowledge, which also could use improvement.

Amazon EKS is very stable; during my usage, the clusters remained consistently available and workloads ran reliably. The self-healing capabilities of Kubernetes, combined with AWS managed infrastructure, help ensure minimal disruption to running applications.

Amazon EKS is highly scalable; it supports horizontal scaling of pods and seamless scaling of worker nodes. It features AWS auto-scaling for vertical scaling, making it suitable for handling varying workloads and preparing the environment for real-world production demands.

Support and documentation from AWS are very strong, with extensively available official documentation, and AWS support channels are very kind and responsive. Most issues can be resolved through AWS knowledge bases, documentation, and our organizational support teams.

Positive

Previously, I used open-source Kubernetes as a normal Kubernetes solution. I wanted to switch to Amazon EKS because Amazon EKS connects with numerous AWS services, making it easier to deploy my applications than using open-source Kubernetes.

The initial setup is moderately complex; creating clusters, configuring IAM roles, setting up the network, and connecting with the worker nodes requires careful planning. However, once the environment is configured, ongoing operations such as deployment, updates, and scaling are smooth and efficient.

Time is definitely saved because Amazon EKS provides automation with CI/CD pipelines, allowing us to simply monitor it, and if there is any fault, we know immediately in the pipeline. Regarding the need for fewer employees, I do not think that will happen since only a few employees will know about Amazon EKS deployments in the cloud, so some knowledge is necessary. We can see a return on investment; we can save a lot of money by using Amazon EKS as it is directly connected with all AWS services and can be integrated with coding storage options such as GitHub and GitLab.

I did not evaluate many options; I evaluated some, specifically open-source Kubernetes, which I thought would be more difficult than Amazon EKS. Therefore, I chose Amazon EKS.

The benefits that I observed after adopting Amazon EKS are improved deployment speed and reliability, while resource usage remains the same, but we can handle a larger amount of traffic and application deployments without any issues. The user interface is very great, providing clarity on where the fault or error lies while deploying our application. I would rate this product nine out of ten.

Public Cloud

Amazon Web Services (AWS)

Our use cases for Amazon EKS include deploying and managing microservice-based applications, where Kubernetes excels at orchestrating microservices and Amazon EKS handles the heavy lifting of managing the control plane. We also use it for application modernization such as migrating legacy applications to containers and for hybrid and multi-cloud deployments, running Kubernetes workloads across on-premise and cloud environments. Additionally, we run secure and compliant workloads that require strict security and compliances, utilizing AWS IAM, VPC, and security services.

Furthermore, we leverage CI/CD pipelines to automate build, test, and deployment processes, and for machine learning, we implement SageMaker.

The most valuable features of Amazon EKS are the managed Kubernetes control plane, where AWS handles the provisioning, scaling, and maintenance, ensuring high availability and automatic patching. Integrations with AWS services offer seamless access such as IAM for access control, CloudWatch for monitoring, ELB and ALB for load balancing, and storage options including EBS, EFS, and S3. In terms of security and compliance, we utilize fine-grained access control through IAM role service accounts, support for private clusters, and network policies.

Amazon EKS supports both EC2 for full control over nodes and Fargate for serverless Kubernetes pods.

The positive impacts I have seen from using Amazon EKS include enhanced security and compliance with a managed control plane, automatic patching, updates, IAM integration for secure access to AWS services, private clusters, network policies, and encryption options. Additionally, I experience operational efficiency, scalability, performance, developer productivity, flexibility, portability, and observability and monitoring through CloudWatch, Prometheus, Grafana, and OpenTelemetry, which assists in troubleshooting issues and optimizing resources, ultimately leading to cost optimization.

Areas for improvement within Amazon EKS include the management of infrastructure. Prior to using Amazon EKS, we handled manual provisioning, patching, and scaling of our Kubernetes cluster, but now AWS manages control plane operations, automatic patching, and scaling, which has reduced our operational burden and resulted in fewer infrastructure-related incidents.

I believe only operational management could be improved in the next releases of Amazon EKS.

When it comes to stability and reliability in Amazon EKS, the reliability of the control plane managed by AWS is paramount, running across three availability zones in each region to ensure high availability and fault tolerance. AWS also automatically manages the scalability and health of crucial components such as the Kubernetes API server and etcd cluster. We have options for worker nodes, including auto mode, Fargate, managed node groups, and self-managed nodes, ensuring data plane reliability.

Regarding scalability in Amazon EKS, we see managed node groups and Fargate profiles, where we can automatically scale the number of EC2 instances in a node group using Cluster Autoscaler or Karpenter. For serverless pods, Amazon EKS can scale without managing EC2 nodes, and we can utilize horizontal pod auto-scaling based on CPU, memory, or custom metrics, along with support for cluster limits, multi-cluster, and multi-region load scalability.

Amazon EKS is highly scalable, showing improvement in areas such as infrastructure management, security, and cost efficiency, with features such as auto-scaling for pods and nodes, making it suitable for bursty and high-demand workloads.

Before using Amazon EKS, we relied on self-managed Kubernetes on EC2 as well as Docker Swarm for our workloads.

We decided to switch from Docker Swarm to Amazon EKS because it is a managed service that simplifies the handling of complex scalable and modern application workflows.

Setting up Amazon EKS for the first time involves prerequisites such as installing and configuring the Amazon CLI, then installing `kubectl`, and while `eksctl` is optional, I install it for easier setup. IAM permissions are also needed to create EKS resources.

My experience with the initial setup has been straightforward, and I did not face any challenges so far, especially with `eksctl`, although there are common challenges such as IAM role configuration, network complexity, and cluster access control.

We have managed to estimate savings of around 20 to 40% using Amazon EKS, specifically achieving savings on Fargate ranging from $30 to $45 per month based on our usage.

I consider Amazon EKS to be an affordable product overall.

Before choosing Amazon EKS, I did not evaluate other solutions as I found it to be the best one for us after checking the market.

The integration of Amazon EKS with IAM enhances our authentication process as IAM users or roles can be granted access to the Kubernetes API server, managed via the AWS Auth ConfigMap in the EKS cluster, allowing us to map IAM roles or users to Kubernetes RBAC roles.

When it comes to Amazon EKS integrating IAM into application development, we utilize IAM roles for service accounts that allow our application pods to securely access services such as S3 and DynamoDB without storing credentials. We first create a Kubernetes service account and associate it with IAM roles using annotations, enabling the pod to use this role to access AWS services via temporary credentials, providing a significant developer benefit by eliminating the need to manage secrets manually and ensuring access is secure and scoped per pod.

The benefits of Amazon EKS's automated patching feature for our Kubernetes clusters primarily include improved security through the automatic application of critical security patches to the control plane and worker nodes, which reduces exposure to known vulnerabilities such as CVEs and ensures compliance with security standards. A second benefit is the reduction of operational overhead, and thirdly, enhanced cluster stability, minimized downtime, and consistency across environments. With intelligent patch management, Amazon EKS often tests patches before release.

When it comes to managing complex workflows effectively on Amazon EKS, I find that it simplifies infrastructure management by abstracting away the complexity of managing Kubernetes control planes, allowing us not to worry about patching, scaling, or securing the master nodes. It also supports scalability for high-demand applications with auto-scaling features for both pods and nodes and provides enterprise-grade security.

I utilize the AWS EKS official documentation, accessible via docs.aws.amazon.com.

My impression of the documentation is that it is very easy to learn from scratch, making it accessible even for beginners, as it is comprehensive, well-structured, and production-ready. Especially for developers and DevOps engineers such as myself, we find the user guide, best practice guide, API reference, CI tools, and workshops to be highly reliable, developer-friendly, scalable, and flexible for deployment needs.

On a scale of 1-10, I rate Amazon EKS an 8.

Amazon Web Services (AWS)