Amazon EKS is used for running any type of application, and it is one of the more stable platforms. We use everything in AWS, CloudFront, and we probably have a hundred applications in AWS.

Several of our platforms have transitioned to Kubernetes because it is more economical than some other methods, and we have lots of apps that use Kubernetes.

The deployment of Amazon EKS took time mainly because of the amount of stuff we had to move, such as old legacy applications and systems, which need changes every few years, and AWS is just better.

We have several applications that run in Amazon EKS.

The best features of Amazon EKS include Kubernetes, as several of our platforms have transitioned to Kubernetes because it is more economical than some other methods, and we have lots of apps that use Kubernetes.

The support for AWS tools integration with Amazon EKS has influenced our management process significantly. The cloud affects everything, with probably 80% of our stuff in the cloud, mainly in AWS.

The self-healing nodes with Amazon EKS help minimize administrative burdens, and while I'm not a system admin myself, I do disaster recovery testing and resiliency assessments for cloud applications.

Improvements could include better support and pricing, which is always important.

There are definitely areas for improvement with Amazon EKS.

My experience with AWS products spans the last six, seven years.

Amazon EKS is stable.

Amazon EKS scales effectively.

I would rank their support close to a 10; they are very responsive.

The initial setup with Amazon EKS is straightforward, and all of our teams are involved with AWS. Some use EC2 containers, and I've seen everything there is to see in AWS.

Amazon EKS is easy to use, and you don't experience the problems that you encounter with some solutions like EC2 containers or S3 buckets.

The support for AWS tools integration with Amazon EKS has influenced our management process significantly. The cloud affects everything, with probably 80% of our stuff in the cloud, mainly in AWS, though we have some in Google Cloud and Azure.

In my role, I don't set anything up; I set up test disaster scenarios and have teams practice against those scenarios. We have encountered challenges during that migration process, and we utilize our AWS dedicated person whenever something arises that we can't handle or don't understand, so we can seek their help.

Amazon EKS helps us manage complex workflows effectively.

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

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.

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.

For our microservice architecture, where we have multiple services for our business use cases, we have been using Amazon EKS from the very beginning.

The integration with IAM enhances the authentication processes as it prevents multiple outages, failures, and mis-deletions from users.

The Amazon EKS support for AWS tools integration is very effective because it's within the ecosystem of AWS itself, integrating almost with everything. Amazon EKS itself uses EC2 instances, which are the basic services that Amazon provides, on top of which we have VPCs, security groups, and all.

The self-healing feature on Amazon EKS identifies when one of the nodes goes down and spawns a new node, degrading the older node, which helps to minimize our administrative burdens by reducing one stage of complexity on our SRE team.

The dashboard of Amazon EKS is very effective, where I can see all the nodes, the pods that are present, and it also shows the current CPU utilization, memory utilization, along with the pods that are scheduled on the nodes. Those insights in one place are very valuable.

We have utilized Amazon EKS's integration with the IAM solution.

We are utilizing the self-healing nodes in Amazon EKS.

I have one suggestion for Amazon EKS. When working on microservice architecture, we need to use that context and have K9s installed for a graphical user interface to check pods and nodes in a clear-cut manner. If that support is added within Amazon EKS itself to check all the config maps and everything within the UI itself, that would be very beneficial.

I have been working with Amazon EKS for one and a half years.

The initial setup of Amazon EKS was completed by other teams, and they performed it straightforwardly as they had some orchestration script which sets up the EKS cluster and has multiple add-ons to be added.

Starting to work with the Amazon EKS product was straightforward for me since I had previously taken a course on Kubernetes.

The main benefits I have seen from using Amazon EKS are the reduced complexity overall, where Amazon manages everything effectively, and the other benefit is the microservice architecture. Amazon is flawless in most cases, though we encountered a few unknowns from the EKS cluster itself. Apart from that, it is always up, and we have the support team for Amazon EKS as well. Our SREs had interactions with EKS, and within minutes or within 10 or 20 minutes, we would get the EKS cluster up if there was an issue.

There is one person from AWS who acts as a bridge between our team and their team, so we can ask them if we have an issue.

Before Amazon EKS, I was in college and did not use any other Kubernetes solutions or container management products.

The initial setup of Amazon EKS was completed by other teams, and they performed it straightforwardly as they had some orchestration script which sets up the EKS cluster and has multiple add-ons to be added.

The initial setup of Amazon EKS was completed by other teams.

The pricing of Amazon EKS is subjective because it depends on the use case and the instances that we are using. Amazon provides everything, every instance, and it also gives a cost at the fore-end, so it depends upon our use case whether we want them to be higher cost or lower cost.

We have not evaluated any other options. From the very start, we were using AWS only, and it has been good and is working fine, so we never evaluated other options.

I am not aware of the automated patching feature in Amazon EKS.

I work with Amazon EKS and am still currently working with it.

We use Kubecost for managing Amazon EKS, which is an external tool we use to find all the healthy status, memory utilization, cost, and all for our EKS cluster.

My advice for organizations considering Amazon EKS for their environment is to proceed with it, especially if they are trying for a microservice architecture. It's already very good, with no flaws. Just one thing is to have a look at the cost of the instances they are trying to provision.

I rate Amazon EKS 10 out of 10.

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.

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.

I use this to develop my products. I use it internally in my company and in the other projects I have been working on for the deployment and managing the services which I'm deploying into the Amazon EKS infrastructure. I have not actually been involved with automated patching, as my role has predominantly been as a developer setting up how we deploy our applications into Kubernetes. That's primarily where I've gained experience, not on the server management side where the patching is done, so I'm not sure how the patching works or what benefits it could offer in that context. However, I can discuss how I manage my CI/CD pipelines, application deployment, and how I use Amazon EKS for deployment. That is the part I have experience with.

I have been using Amazon EKS, and I started with ECS first, which is the Elastic Container Service where I can deploy my workloads. ECS is also one of other managed services from AWS, but it is not supporting Kubernetes. We wanted a platform where we could have an orchestration platform for Kubernetes. Hosting our own Kubernetes server is a very tedious job. Kubernetes itself is a very complex tool to manage and requires a lot of resources and knowledge to build a working solution. That's where Amazon EKS comes into the picture as a managed service built on top of a Kubernetes engine, offering many tools, such as CLI integrated tools or through their console to quickly set up a Kubernetes cluster, which otherwise is a tedious job.

With that offering, it is very easy to set up the Kubernetes cluster in Amazon EKS, and it is very easy to manage the nodes we have there, such as what instances we need. Since it's an AWS offering, we select a variety of EC2 instances available, and it integrates with it nicely. The same applies to the infrastructure as a service tool, IaaS, such as Terraform. It is very easy to create and manage Amazon EKS clusters through Terraform. Overall, it offers a lot of tooling and saves a lot of time compared to setting up and managing a Kubernetes server ourselves.

A specific feature of Amazon EKS is that Kubernetes is open source, and all its capabilities are based on that. The main advantage is launching and managing a Kubernetes server becomes very easy, as I receive out-of-the-box support for other AWS service integrations with Amazon EKS. For example, services such as AWS IAM directly integrate whenever I want to set up access control or security measures on my Kubernetes server. EC2 offers out-of-the-box support when setting up Kubernetes nodes. All this setup we need to do otherwise becomes much easier with Amazon EKS.

Regarding measuring the impact of Amazon EKS on my organization's ability to manage complex workflows effectively, there are measurable metrics we use. Whenever we set up any project, it is crucial to ensure we understand the availability and scalability of our applications. When I set up any application, I look at how we will be able to scale whenever there is a requirement for higher loads. To measure the Amazon EKS platform's effectiveness in this regard, I evaluate the different methods available for scaling the application. For instance, based on CPU and memory consumption, I can scale or use scalability tools such as KEDA. KEDA helps us scale based on various factors, such as the number of requests my application receives or the load on my service based on metrics. These tools can be easily installed on my Amazon EKS server without restrictions. Availability is crucial when setting up a Kubernetes cluster, especially when designing for a global audience using Amazon AWS. The options to configure multi-region and multi-AZ setups are incredibly valuable, as these features ensure high availability without complex traditional setups required for on-premise hosting.

One area I observed during setup was that while managing it through CLI and Terraform, there are many possibilities for setup and infrastructure updates. However, I believe the console experience could improve. In the AWS console, when trying to set up an Amazon EKS cluster, there were limitations on certain features I encountered a few months back while checking. EKS frequently updates, so I don't know if there's a new release. However, I found some features that I could not manage through the console, requiring me to use CLI or Terraform. It would be beneficial if we could have all features supported through the console, providing full management capabilities there.

I have been working with this tool for around two years now.

My current organization has not been using self-healing nodes, but I have used it in some earlier projects and organizations I worked with. When we decided to move away from containerization services such as ECS, we wanted a better orchestration platform that could easily handle those requirements. Kubernetes comes with many features for scalability, which otherwise we would have to manage ourselves with scripts. While Kubernetes is a good choice, it comes with its own learning curve, and understanding all the details is a big task. Services such as Amazon EKS, or maybe GKE for Google, provide the confidence that we will benefit from the orchestration framework that Kubernetes offers while also setting it up and managing it easily. We gain all the advantages that Kubernetes has as an engine without having to invest a great deal of time learning and configuring everything thanks to managed services such as Amazon EKS.

Regarding technical support, I recall one instance with Amazon EKS. I faced an issue with configuring pods in EKS that required access to other AWS services, such as IAM roles or S3 buckets. The setup was through OIDC providers in EKS, which set up trust relationships with IAM roles. There was a problem with OIDC provider setup a few years back when EKS was newer. I reached out, and I received good support when I submitted a ticket for the issues with the OIDC provider. They helped resolve the issues related to the trust relationship, identifying mistakes that needed fixing.

In my current company, I don't use it, but in my earlier company, we started with ECS, another AWS offering where we deployed our containers. However, as our deployment expanded, the limitations in scalability prompted us to explore better options. We began to reach a point where more than 30 or 40 instances of our services were running, and there was a need to support these across different regions. ECS offered some level of scalability, but it was not as customizable as Kubernetes, so we decided to transition from ECS to Amazon EKS to harness its full capabilities.

Using Amazon EKS as a cluster is free. The pricing only applies when I add the instances and set up nodes. For instance, when I add memory-optimized nodes, the applicable AWS pricing for those instances comes into play. Essentially, the pricing revolves around the nodes added, not the other configurations I'm attempting to set up.

Regarding the pricing of nodes, I find that it generally offers good value. I'm not certain what the comparative costs look against other platforms, such as OCI from Oracle that is known to offer lower pricing, but it ultimately depends. For example, AWS has recently introduced Graviton-based servers, which claim to be cost-saving, although I haven't used them myself. AWS provides several options, allowing me to choose configurations that suit my needs regarding CPU and memory. While I don't have firm details about enterprise pricing options or upfront reservations that may provide discounts, what I appreciate is the flexibility in selecting from various instance categories to meet specific requirements.

Based on my experience with Amazon EKS support, I would rate it a nine out of ten overall.

Amazon EKS is used as a container orchestration platform. Customers use it to develop applications which are containerized and need to be deployed. Kubernetes is the most popular platform across the industry.

Amazon EKS offers replatforming and migration capabilities to our customers, enabling them to move from AWS to other platforms like AKS with minimal changes. It has also helped in smooth integration with other AWS services, especially API gateways and databases.

The serverless capability of Amazon EKS is quite valuable. Earlier, it was necessary to know the exact configuration, including the number of pods and nodes. Now, with the serverless option, you can deploy everything and AWS handles the infrastructure.

Amazon EKS could improve in its pricing model, particularly for medium-sized customers who might find the support costs high.

I have used Amazon EKS for the past five to six years.

I rate the stability of Amazon EKS as ten out of ten. It is highly stable.

Amazon EKS has high scalability. It can scale very well according to needs, and it doesn't have any issues with scalability.

Amazon's technical support is quite good, especially for those who purchase support services. As a partner, we receive excellent support due to our relationship with Amazon.

The initial setup of Amazon EKS is much less complex compared to setting up Kubernetes manually on Linux virtual machines, as it takes away the complexities of installing and configuring everything.

We have experience working with both EKS from AWS and AKS from Microsoft Azure, as well as Google GKE.

For those who are Amazon customers and want to deploy containerized applications, Amazon EKS is the best option.

I'd rate the solution ten out of ten.

I used Amazon EKS for my personal learning purposes. I used the solution to learn how to initiate and upgrade the Kubernetes cluster for testing in my own lab.

Amazon EKS is a good tool for my testing and learning purposes. The solution's performance is good. It is a good solution for my learning and my labs.

The solution's graphical interface is not the best. It could be better in terms of enabling some integrations or managing the configuration.

I have been using Amazon EKS for one or two years.

I rate the solution’s stability ten out of ten.

Amazon EKS is good when it comes to scaling the cluster, adding, removing, or upgrading the nodes. Upgrading the machine's resources is easy.

Amazon EKS has a big community, and support is really good.

The solution's initial setup was easy.

If the deployment fails, you're still up and running. Scaling up or down can be done with zero downtime.

Some of the Kubernetes clusters were on Amazon, GCP, and Azure. I used most of them on-premises. I installed the Kubernetes cluster in my own environment.

Overall, I rate the solution ten out of ten.

I use the solution for its microservices. I used the product in some of my personal projects for deploying applications. From an organizational standpoint, the product is useful for its microservices.

When it comes to Amazon EKS, there are IAM permissions and RBAC. When you create an IAM user, you give the privileges on the cluster level, but there won't be anything inside the clusters. In the clusters and their respective files, you will have to map the IAM user created with the help of AWS. The documentation part of the product is an area of concern that needs to be made easier from an improvement perspective.

I have experience with the tool for the past six to eight months. For some of my personal projects, I have been using the product for a year and a half. I am a customer of the product.

Stability-wise, I rate the solution a ten out of ten.

Scalability-wise, I rate the solution a ten out of ten.

The product's initial setup phase is easy since it is only based on a one-line command to help you set up an EKS cluster.

The product is available at such a huge scale in the market since the resources that are offered under the tool are competitively priced and available at a much cheaper rate compared to other solutions.

One of the aspects of Kubecost and Amazon EKS is that you don't have to manage the master node. The scalability and connectivity between API servers and its resources, including its scheduler and controller, are all taken care of by AWS. Not being easily able to log in to your master node makes things secure.

I found the cluster autoscaler of AWS to be very helpful. It is easier for users since the cluster autoscaler takes care of the nodes, making everything easy for me. With the cluster autoscaler, all the resources are presented to me, so I need not consider any integrations from the outside environment. The aforementioned reasons made it easy for me to set up the software and scale down the resources easily.

I recommend the product to those who plan to use it. Kubernetes is a product from Google, which offers good compatibility. Kubernetes and its compatibility with Amazon is decent enough for users, in my opinion.

I rate the overall tool a ten out of ten.

I have clients that run on Kubernetes engines.

The tool works well with the nodes in AWS. It's scalability is also good in terms of architecture.

I am not impressed with the tool's Amazon console. It also needs to add security features.

I have been working with the product for four years.

I would rate the solution's stability a ten out of ten.

I would rate the product's scalability a ten out of ten.

The tool's premium support is good.

The solution's deployment gets completed in minutes. You need one DevOps engineer to maintain the solution.

The solution is pricey. The tool's pricing is monthly.

I would rate the solution a ten out of ten. It is the best platform for Kubernetes. The tool is also compliant. You need a demo to get started with it.