Amazon EKS Reviews

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)

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)

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)

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.

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)

In my recent project, I have used Amazon EKS to deploy and scale machine learning and generative AI applications, containerizing LLM-powered APIs with Docker and deploying them using EKS for high availability and scalability. I also integrated the CI/CD pipelines and GitHub Actions to automate deployments into EKS clusters, leveraging IAM roles for service accounts, KMS encryption and VPC isolations for security. I used CloudWatch, Prometheus, and Grafana for monitoring, and Amazon EKS allowed me to build scalable, compliant, and enterprise-ready AI services without worrying about managing Kubernetes manually.

When it comes to the best features of Amazon EKS, there are some measurable properties such as variables we can feed into the model to help with market predictions. For example, for a credit risk scoring model, features might include transaction history, credit score, and income repayment. Selecting, cleaning, and transforming raw data into meaningful features to improve model performance will improve the precision and recall of the model significantly.

Amazon EKS has many powerful features that abstract the complexity of Kubernetes. Simple networking can be used for VPC and CNI, such as service meshes. However, EKS upgrades can lag sometimes when Kubernetes versions move quickly, delaying the adoption and adjustment for the latest features. I also see opportunities for better out-of-the-box monitoring, as integrating Grafana and Prometheus requires effort. Amazon EKS itself would make it easier to unify traces and metrics and allow for secure cross-cluster communications.

The initial setup in Amazon EKS is complex, especially compared to services such as ECS and Fargate, which I worked with in my US Bank project, involving VPC networking, IAM roles, or node groups. However, once set up, the deployment becomes easy. Using infrastructure as code, such as pipelines, I usually automate cluster creation with Terraform and integrate GitHub Actions. We use standardized Kubernetes manifests that make spinning up and scaling clusters much easier, so while the initial setup is complex, networking and IAM integrations make deployment and scaling smooth and easy to handle.

I have been using Amazon EKS for four years, and I have used it in my Accenture projects too, so I have good experience with Amazon EKS.

Regarding the support team from Amazon, I have some experience working with them, as most of the support cases I raised were related to cluster upgrades, networking issues, and IAM permission troubleshooting. In my project, we ran into deployment issues with EKS clusters and network failures across multiple nodes, and the support team helped us identify the VPC subnets.

Regarding the support team from Amazon, I have some experience working with them, as most of the support cases I raised were related to cluster upgrades, networking issues, and IAM permission troubleshooting. In my project, we ran into deployment issues with EKS clusters and network failures across multiple nodes, and the support team helped us identify the VPC subnets.

Positive

Before moving to Amazon EKS, I worked on different solutions such as Amazon ECS, which provides elastic containers that are more flexible for fine-grained scaling, making them a better choice. I have also deployed serverless APIs such as AWS Lambda and API Gateway for the LLM interface, where Lambda's runtime and cold starts differ. On the Azure side, I have used Azure Kubernetes Services.

The initial setup in Amazon EKS is complex, especially compared to services such as ECS and Fargate, which I worked with in my US Bank project, involving VPC networking, IAM roles, or node groups. However, once set up, the deployment becomes easy. Using infrastructure as code, such as pipelines, I usually automate cluster creation with Terraform and integrate GitHub Actions. We use standardized Kubernetes manifests that make spinning up and scaling clusters much easier, so while the initial setup is complex, networking and IAM integrations make deployment and scaling smooth and easy to handle.

The pricing of Amazon EKS varies; EKS pricing is somewhat affordable for small clusters but gets expensive at scale. If we manage it carefully, the control plane can be easier to handle. For bigger clusters, it will be somewhat expensive, but smaller clusters can be affordable depending on the choice.

I would recommend Amazon EKS to other people because it is useful, and I believe they will benefit from using it. Based on my extensive experience with the product in my recent project, I rate Amazon EKS 9 out of 10.

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.

Amazon Web Services (AWS)

Our usual use cases for Amazon EKS include IoT applications for edge computing devices, where we deploy some of our proprietary IoT applications to edge devices running in multiple locations, and artificial intelligence deployment to multiple systems, with a couple of them purely on the cloud where we manage bundled infrastructures into Amazon EKS for several proprietary customers.

The features and capabilities of Amazon EKS that I have found most valuable include the ease of deployment and the interesting part being the cost, which is not as expensive as setting up other cloud infrastructure.

Amazon EKS's support for AWS tools integration has influenced our application development and management process by being quite easy, with the integration being straightforward. Whenever issues arise, we talk to the support team who provide us with documentation, which is how we basically sort out most of those issues.

Amazon EKS's self-healing nodes help minimize administrative burdens in my organization by being wonderful and seamless, as it reduces the need for a whole lot of people on the team to handle issues, and it has really been seamless for us.

An area of Amazon EKS that could be improved in the future is its use for edge computing, which has been a small issue for us, especially since most of our recent work has been on edge computing applications such as Raspberry Pi and Jetson. If they could integrate things such as K3s, that would really be helpful as K8s feels a little bit bulky for edge computing deployment.

I have been working with Amazon EKS since last year, when we started moving some of our solutions to AWS EKS.

My experience with the stability and reliability of Amazon EKS has been very positive, with only a couple of intermittent shutdowns previously, but recently there have been no issues at all.

My impression of Amazon EKS's scalability has been positive, though we have not done very large-scale deployments. Most of what we've done has been on a much smaller but continuous scaling for multiple systems, and there has not been an issue on that aspect so far, although we haven't scaled up to a million or five million devices yet.

I often communicate with Amazon EKS technical support, as they have been our main go-to people.

An example of my interaction with Amazon EKS technical support was during the initial setup when we talked with them, and they provided us an easier route by suggesting how we should bundle our solutions in Docker for easy deployment.

Positive

Before Amazon EKS, I did not use a different solution for these use cases, as our path has always been with Amazon EKS.

My experience with the initial setup of Amazon EKS was straightforward with no challenges at all on my part, although the interns might complain about some snags. It's basically about studying the documentation.

My setup process involves building the application on GitHub, bundling it in Docker, and connecting with Amazon EKS.

I have seen a return on investment with Amazon EKS for time, as it has helped me save a significant amount of time. However, the cost side has not been as positive since some of the applications run in dollars, leading to complaints from customers and ourselves about the cost, particularly when providing services to customers across Nigeria and some African countries. The return on investment has not been great due to the foreign exchange rate, but for time savings, it has been wonderful in helping with deployment.

My opinion on the pricing and licensing of Amazon EKS is that it is quite varied, especially when doing projects in the African continent. It's quite expensive considering the local currency with respect to the conversions to dollars or euros, and if this could be lowered, it would help more deployments on our side with Amazon EKS.

Before choosing Amazon EKS, I evaluated other options or technologies, including Kubernetes on AWS, Google Cloud, and Microsoft Azure, but most of our experiences came from AWS, so we stayed with AWS.

I have not utilized Amazon EKS's integration with IAM solution.

I have not encountered specific benefits using Amazon EKS's automated patching feature for my Kubernetes clusters, but it has been satisfactory as we haven't actually had many issues with using Kubernetes.

The impact of Amazon EKS on my organization's ability to manage complex workflows effectively has been purely managed by my colleague, and it has been quite seamless with no issues on that particular aspect.

Some of the benefits and positive impact that I have received from Amazon EKS include getting cloud credits through Activate and certain deployments around migration, which have been quite beneficial, along with business support credit and support during certain issues. During the initial times of integrations and migrations, AWS connected us with more specialists in different locales with much more experience while also paying for their services.

Based on my overall experience with Amazon EKS, I would rate it an eight out of ten due to the lack of K3s from Rancher.

Amazon Web Services (AWS)