External reviews are not included in the AWS star rating for the product.
I use Amazon EKS for creating users, depending on the project I've worked on. I use it to update config maps and for role binding in the Kubernetes cluster. Additionally, I use it for creating namespaces and accessing different clusters, such as dev clusters.
Regarding integration with IAM in Amazon EKS, I use it primarily for creating IAM users and managing permissions for users.
While I cannot specify a single favorite feature in Amazon EKS, I particularly value the user creation and config map functionalities. Both processes are straightforward - creating users and updating the config map are easy tasks.
The main benefit of using Amazon EKS is that it makes work more efficient and enables faster delivery.
The main area for improvement in Amazon EKS relates to master node control. When setting up a Kubernetes cluster independently, you have access to the master, but with AWS, you do not have control over it.
The support team of Amazon EKS is excellent and very helpful. I have never experienced any issues with them.
Positive
We briefly used Google's solution before switching to Amazon EKS. After that brief period, we have exclusively used AWS.
For the initial setup of Amazon EKS, we typically follow established guidelines. In most cases, we are not responsible for creating it directly. We work through our Jira and Confluence systems, completing assigned tickets and projects rather than setting up the system from scratch.
The pricing of Amazon EKS varies depending on the size and specific requirements of individual companies or clients. Many companies choose AWS because of its competitive pricing. The prices are considered fair by most users.
On a scale of 1-10, I rate Amazon EKS a 9.
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.
Positive
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.
We wanted to easily integrate our on-premise nodes with Amazon EKS to fully utilize the cloud service with our already persistent on-premise nodes. The major use case was that we wanted to host calls where the latency has to be in one digit. We can't have a call here in Mongolia jump from the Hong Kong AWS server and jump back to us. That would be a terrible experience for our users. We would have to implement the one-digit latency solution within our country, so we have to utilize the on-premise data center nodes. That was a bit of a challenge for us. Other than that, it's usually great.
In our old cluster, we were using on-premise Kubernetes. We had some downtimes here and there, with downtime being a monthly occurrence to our business. When we switched to Amazon EKS, we haven't faced any downtime in two years so far. That means no stop business growth for our type, and we can continue focusing on our business agility. The maintenance, configuration, and maintenance of our cluster has never been needed. We can update our Kubernetes cluster versions by just clicking one button. Before that, it was a long and tedious task. We would have to do it during nighttime operations. Operations are minimized and downtimes are non-existent now. Adding nodes and removing nodes are automatic so we could save costs there too.
The application supply chain integration has never been easier with Amazon EKS. We have integrated Amazon EKS into the CICD pipeline. Our developers are just pushing our code to our repository, and a few minutes later, it's deployed in Amazon EKS.
Mostly, it's just minimizing the manual preparations and increasing our business time with Amazon EKS so we can focus more on improving our applications and researching new ways to improve our business side. This means less time on the system side manual configuration and more time on making our applications better for our users.
It was really positive. The customer support was nice, informative, and very helpful.
Positive
Currently, we are just following the best practices with Amazon EKS. We follow the usual best practices or workflow with Amazon EKS and load balancing.
In comparison, the latency is a bit high with Amazon EKS. When we were researching about a year ago, Google offers almost forty milliseconds delay to Mongolia, as Amazon EKS in Hong Kong offers sixty milliseconds delay. That was the only downside from not choosing Google over Amazon EKS. Other than that, Amazon EKS has a lot of services.
On a scale of 1-10, I rate Amazon EKS a nine out of ten.
I use Amazon EKS for one of my customers when I am an independent contractor. They do video recording for events such as weddings, advertisements, and other occasions. They wanted to stream their content, and I advised them to use Amazon EKS as a good solution so they can easily ingest the raw materials, process it, do all the cuts using specific video software, and then publish it wherever they need.
The ease of implementation and integration was accomplished by writing some small scripts. I implemented workflows for data ingestion, sending it for cuts, and then directing it to the presentation layer. The simplicity of it was key.
The automated patching feature for the Kubernetes clusters provided valuable benefits through ease of maintenance and simplification of maintenance. I don't have to manually monitor or create any additional services for monitoring the patches; it's just there and does the work automatically.
From my perspective, integrating existing applications into a single workflow is beneficial for application development and application integration.
The workflows were straightforward, collecting data from raw recordings from cameras, putting them on cloud storage, ingesting them into video editing software, and going to a CDN for publishing.
About a year and a half ago, the cost was somewhat high. Though I wasn't directly affected as my customer paid for it, they complained about the billing. If they could reduce the price, that would probably attract more customers, especially from this industry, as they are rather small companies with limited budgets for such tooling.
I have been working with Amazon EKS for about a year and a half, with my first notes dating from March 2024.
I escalated a couple of cases to AWS support. I have mixed feelings about this as they were quite helpful, but the response times were quite long. It took them about five business days to get a response to my question, but when they replied, the response was very valuable and helped me.
I didn't notice any crashes, slowness, or performance issues with the Amazon EKS product. My client could have potentially experienced such issues while using it, but they never reported any complaints, so I don't believe there were any issues.
I would rate the tech support around seven or eight on a scale of one to ten.
Positive
I worked with container services about a year ago as part of my project at that time. I enjoyed using AKS, but I think its equivalent in AWS is better; it's more mature and easier to implement than AKS on Azure.
The best feature I found in Amazon EKS is ease of implementation. I'm not very knowledgeable about video software and had to learn it quickly for this specific project, and I found it very easy to implement. It probably took me a couple of hours to really understand it and learn how to use videos, and it was probably the easiest of all the solutions that I tried.
I use the DevOps server as software as a service on Azure. I didn't need to set any server for that; it was just there. I added it to my dashboard and started using it.
In terms of cost savings, time savings, and efficiency improvements, I've definitely seen returns on investment. Considering my rate and the couple of hours spent, rough calculations show around 30% return on investment.
The majority of my time setup cost was very affordable, taking just two hours. It was easy as I didn't have to worry about setting all the infrastructure underneath, just using what's there. This saved my time, allowing me to complete the project within several hours instead of days or weeks.
When I evaluated several solutions, Amazon EKS looked more intuitive to learn. I was prototyping for two hours each, and with Amazon EKS, I had this raw prototype running after around two hours. With other services, after two or three hours, I was still in the middle of my work with no visible effect, so that was the benefit.
I am working with a set of tools within the Azure toolbox. Azure is a huge collection of services with over 100 of them. I use virtual machines, Azure Functions for serverless processing, especially for creating APIs that do automated tasks. Additionally, I use SQL Server database and infrastructure as code, creating using Terraform, creating virtual private networks, setting up firewall rules to increase the security of my customer's solution.
I give Amazon EKS a rating of 8 out of 10.
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.
We use Amazon EKS for hosting our policy admin system, and it has its own benefits. The scalability aspect of it is what we considered Amazon EKS for. It is a managed service, so we don't need to take care of the underlying operating system and other things. It was one of the preferred services in AWS which we chose.
The benefits I have experienced with using the automated patching feature are key, because considering that this is a managed service, we want to be more focused on our application rather than doing all these upgrades, especially given the amount of upgrades at each of these microservices level applications. We don't want to worry about that, and there is always this blue and green setup which we can have where, if there are any issues, I should be able to switch over to my blue whenever there is a deployment. Those aspects have helped us.
What I appreciate best about Amazon EKS is the managed service part of it because we don't need to worry about the underlying operating systems or the upgrades we need to have. The flexibility at which we can spin up multiple pods in each of the Kubernetes service and the service availability aspect of it are the key points.
I have used the integration with IAM; we used IAM roles, focusing on security aspects. We had multiple IAM roles and policies defined so that it is quite secure.
A few improvements I can think of for Amazon EKS would be on the monitoring side; they have very good monitoring aspects of it, but it has its pros and cons. Having some access and visibility into their Amazon EKS services and setup would be good because there are instances where some of the pods crash, but we don't have detailed monitoring available since once the pod crashes, we can't get enough logs. If they can have a backdoor or backup capability, whenever a pod is not able to serve, to get all the metrics before killing it, that would help us investigate the reasoning behind it more thoroughly. I think that side of it is missing.
Regarding Amazon EKS pricing, they have corporate level discounts, but one key aspect is the pros and cons. One immediate deploy capability is that I can trigger a pipeline to get an Amazon EKS setup done and start using it, which is much more efficient in the short term. However, in the long run, the scenarios we've seen indicate that it requires integration with other services, and the network egress charges are a bit higher. The intent of starting with reduced costs using Amazon EKS doesn't hold as clearly when we consider it for the long run; we start with a low cost and then realize it doesn't justify that.
I have been using Amazon EKS for almost five years.
The support for AWS tools, such as integration, has significantly influenced our management. Considering that we are a big corporate with direct connects with the AWS solution architect and other people we work with, it's as simple as raising that support request and they will be here. I think we even had the highest level of support we can get from AWS with respect to this.
I think very highly of Amazon's support team; they are really good, especially considering that we have the highest level of support and their support management team is also involved in calls to give any kind of priority to our requests.
Positive
I would recommend Amazon EKS to other people, but it depends on the scenario. Kubernetes for sure, but I suggest going for Amazon EKS if yours is a smaller enterprise. If your load is too high and fluctuating, then it makes sense to try Amazon EKS, learn how Kubernetes works for your organization, and evaluate the cost-benefit analysis. If you are considering it for a longer run, I recommend conducting a cost analysis to see if moving to a local on-prem system could be more beneficial. It truly depends on the case scenario, so it's important to do the cost analysis as well. On a scale of one to ten, I rate Amazon EKS an eight.
I usually work with AWS tools focused on infrastructure deployments, onboarding new customers to the cloud, and offering the best practices across infrastructure, networking, security, monitoring, and availability, discussing high availability solutions and implementing the best practices over these. That's mainly my scope. For the development part, when it comes to services such as functions, Lambda functions and X-Ray and development services, I actually interfere with them in the deployment part and not for the configuration or the development part.
I've built a tool that can manage all these resources, whether it's on Microsoft Azure or Amazon Web Services or Oracle itself. This tool is efficient when it comes to assessments, assessing the environments for customers, getting the best security practices and measurements across the environment the customer has, having a cost optimization component that can be used to optimize the cloud environment. It covers automated deployments that you use with a user interface, so you don't have to write any code while deploying complex scenarios.
Regarding my experience with Amazon EKS, I have a complete solution for deployment as well. The tool is really powerful and can be used to do various things. I'm involved in the infrastructure, networking, and deployment part, so deploying these resources is one of my daily responsibilities. I use this tool to deploy all of these.
The deployment process for Amazon EKS is straightforward; you don't have to do anything basically. You just have to get the right image and the normal operation for Amazon EKS.
The best features of Amazon EKS involve the orchestration, which may be the concerning part of each customer when it comes to Amazon EKS especially. The automation part, the deployment and monitoring part, the security as well, having the connectivity going private or public, or using Kubelet are various aspects that users should be aware of, providing good experience while discussing these options with customers.
The integration capabilities of Amazon EKS seem fine, but it can be challenging using AWS services compared to other cloud providers, for example, Microsoft Azure. From using both platforms, Microsoft Azure offers more simplicity while doing complex deployments. AWS offers the same solutions; however, it seems more complicated when it comes to independent resources, where you need to establish dependencies before doing the actual resource deployment. This part needs an automation layer that already exists with the Microsoft Azure portal, which facilitates everything for the user experience.
I don't see much room for improvement for Amazon EKS; the Kubernetes technology is the same across all cloud providers. Most customers focus on the main common features they will use, such as the monitoring or the orchestration part, which is their main concern when it comes to this service specifically.
I have experience using Amazon EKS for approximately six years.
Regarding technical support from Amazon, I never personally experienced it, but the team I'm handling has faced their support, and they indicated they're quite good, but not on the first level part.
Positive
I have definitely seen an ROI with Amazon EKS. I developed a tool for cost optimization that can cover all of these, even with better approaches than the cloud itself. The tool I developed uses the native AWS recommendations, so ROIs and any saving plans that can be offered are included within the cost optimization. However, we've added our experience component upon using these resources as well.
For example, AWS will never tell you that you have to delete a virtual machine or an EC2 instance. However, our report can detect the stopped instances and provide a recommendation for the customer that for cost saving, they can use a backup or snapshot for this machine, and delete it. If they need to restore it, they can do that, or they may have to remove it if they're not using it.
In terms of pricing for Amazon EKS, I think it's quite reasonable. If we compare the cost to other providers, with providers such as Oracle, it will be much higher in cost. When comparing it to Microsoft Azure, it seems similar, with some variations. On a scale of one to ten, I rate Amazon EKS a seven out of ten.
The main use cases for Amazon EKS included testing some POC concepts to see how Amazon EKS works. Additionally, we can use the Kubernetes service as a VM, and AWS provides Amazon EKS, which allows us to get directly connected nodes and all the VMs without having to provision additional VMs for Amazon EKS. This feature enables us to test how it works easily.
I have used self-healing nodes with Amazon EKS, and on one occasion, I mistakenly stopped the Amazon EKS cluster. While configuring the PVC on the nodes for the pods, the node went down, and the new pods were in a waiting period because there was no node available for pod scheduling. The automatic healing feature created a new node, as I had set the minimum node size to two. Since one node was unavailable, my pod could not schedule, but the auto healing created the second node automatically, which was the easiest part.
What I appreciate about Amazon EKS is the autoscaling feature. When you configure the Kubernetes cluster manually on the VMs and need to add new VMs or if you run out of storage for the VM, you don't have to worry about that with Amazon EKS. It automatically scales the nodes and provides another VM ready for you automatically, which is a great aspect of Amazon EKS.
The main benefit of using Amazon EKS is the automation for the cluster. When creating it manually, it takes a long time to set up the VMs and configure them as server, master, and worker nodes. With Amazon EKS, you can run just one command to configure the whole cluster with the desired number of nodes.
Regarding improvements for Amazon EKS, I am unable to specify anything at the moment because it has been a year since I used it, and some problems I faced might have been due to my mistakes.
I cannot specify improvements for Amazon EKS at the moment. However, I believe they could improve pricing, as I currently find Azure Kubernetes Service to be less expensive than Amazon EKS.
I have been working with Amazon EKS for around three to four months during my internship period before I joined this organization.
The initial deployment of Amazon EKS was straightforward, although I faced some challenges due to a lack of knowledge about the service. Once you fully understand the service, you won't encounter challenges or problems while deploying the cluster.
The integration part was not very challenging; I faced just a few configuration issues, and then we were good to proceed.
I have not utilized Amazon EKS's integration with IAM; I have just used it normally and did not use that feature much.
I have not integrated Amazon EKS with AWS services; however, I have hosted the cluster in Amazon EKS and used it with Jenkins and Argo CD, focusing on CI/CD pipelines and deployment.
I have not escalated many questions to AWS support, but I did raise a question regarding the cost because I was not aware of the total pricing for the cluster, which cost me around $100 or $150. I escalated this to AWS support, expressing my confusion about the pricing, and they waived the issue away as it happened by mistake.
Neutral
I have experience working with Kubernetes and the Azure AKS product.
I cannot recall all the key differences and both pros and cons of Amazon EKS compared to Azure AKS because it has been a long time since I used EKS. Currently, I am using Azure, so I cannot compare them at this moment. If you ask me about Azure separately, I can provide insights on it, but comparing both is difficult as I do not remember all the services offered by each platform.
The initial deployment of Amazon EKS was straightforward, although I faced some challenges due to a lack of knowledge about the service. Once you fully understand the service, you won't encounter challenges or problems while deploying the cluster.
I find the pricing for Amazon EKS to be quite expensive. The EKS service itself is free, but you will incur costs for the VMs used as nodes in that cluster. The pricing is similar to provisioning EC2 instances, which may be much higher than normal EC2 instances, but the automated provisioning is worth the cost.
In my opinion, they are pretty much the same.
Regarding your organization's social media presence, I inquired about a certificate that I can share on LinkedIn to show that I have participated in this review and reviewed some products.
I would rate the impact of Amazon EKS on the organization's ability to manage complex workflows as nine or ten out of ten.
For users evaluating Amazon EKS for their environment, I recommend gaining knowledge first about the service, as it becomes quite easy to use afterward.
The documentation for Amazon EKS is quite good; I do not see any areas needing improvement in the knowledge base.
I would rate Amazon EKS as a solution an eight out of ten. I am not completely aware of the service and have not explored all the parts, which may affect my rating. I might be wrong at that part, but I give it an eight due to my self-doubt regarding not using the service in all aspects.
I decided to go with AWS because during my graduation, we had a course on AWS in our extracurricular activities, which sparked my interest in it. Additionally, during my internship, there was a need for a Kubernetes cluster, which led me to land in the Amazon EKS service.
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.
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.
Positive
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.