Amazon EKS Reviews

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.

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.

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.

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 use Amazon EKS for hosting our applications. It is also a version of compute service with its own perks. Amazon EKS is built on Kubernetes. Kubernetes is complex and is not something used for basic or simple applications due to its complex nature. It is really meant for complex apps such as banking applications or AI-enabled applications that have many services.

When dealing with microservices, if an application has around 20 microservices, then Kubernetes generally begins to make sense. Then it becomes a question of whether to host it on Amazon EKS, Azure Kubernetes Services, or Google Kubernetes Engine. That is basically what we use Amazon EKS for.

Amazon EKS is fairly reliable. The latest feature that was added last year, Amazon EKS auto mode, helps manage compute instances and EC2 instances. Amazon EKS auto mode is a very good addition as it helps reduce stress since users do not have to worry about upgrading Kubernetes versions. For example, when Kubernetes 1.34 is released, Amazon EKS handles the upgrade automatically.

Another beneficial feature of Amazon EKS is the Fargate offering. It helps run some compute instances on AWS Fargate, which means they only run when needed. Unlike typical EC2 instances that keep running once turned on, with Fargate, charges only apply when someone visits that service. For instance, in a banking app with multiple services, including a reviews service, Fargate can be utilized to ensure charges only occur when someone actually uses the review feature.

Amazon EKS is fairly stable and highly available. Once configured properly, it requires minimal maintenance. It integrates effectively with other services such as API Gateway, security groups, and load balancers.

The integration capabilities could be improved compared to Azure. While AWS services are integrated with Amazon EKS, there is room for enhancement.

For example, Azure DevOps provides better pipeline integration. When writing pipelines in Azure DevOps, users can easily import various built-in tasks into pipeline YAML files, such as kubectl tasks or native Kubernetes plugins, once a service connection to Azure is created.

We encountered challenges with WebSocket integration when implementing chat functionality on Amazon EKS. The chat service, which was part of our microservices running on Amazon EKS, needed to be exposed on application load balancer. Despite both application load balancer and network load balancer having native WebSocket integration on AWS, the connections were unstable. This required extensive tweaking of network load balancer configurations to manage API calls through the API Gateway. AWS could improve WebSocket integration across API Gateway, network load balancer, and Amazon EKS.

We have not used it recently because we prefer to make patches ourselves.

When auto mode is enabled, self-healing functionality becomes active. If a node encounters issues or someone makes incorrect configurations, Amazon EKS automatically resets it to maintain standard configurations. This is particularly useful when someone SSH's into Amazon EKS instances and modifies Linux kernel configurations, as the self-healing node resets it to normal, helping reduce administrative burden.

We only escalated questions regarding increasing CPU and memory allocations for Fargate. We contacted AWS through their service quota system. The process required submitting a request with justification for increasing the quota for CPU and memory on Fargate. The resolution was quick after providing a brief justification for the quota increase.

Positive

The setup process is very straightforward.

When considering Amazon EKS, it is important to use Infrastructure as Code (IAC), not just Terraform. Having a repeatable configuration of infrastructure as code is essential for creating clusters, as manual cluster creation is not common in professional production environments.

It is crucial to consider Fargate carefully, as it can help save costs. Fargate is particularly useful when parts of an application or the entire application are not used constantly, as it can reduce costs compared to running on EC2 instances.

On a scale of 1-10, this solution rates as an 8.

I am actually the end user myself without a third party at my company.

I am using Amazon EKS for my Kubernetes with a private ECR on AWS. The application focuses on workforce software as a service.

Amazon EKS adapts and fits with my needs. It provides correct tools since I still need to configure manually some nodes or setting an SSH into the nodes.

I love the automatic automation of Amazon EKS as it manages my Kubernetes. It has a log dashboard for my Kubernetes, and I can manage it easily. Sometimes I need to manually manage using Amazon EKS rather than ECS for fully managed service from AWS. There is more override capability for myself, so I can manually create another group for nodes when needed.

Amazon EKS is integrated with IAM. If I want to allow my coworker to access Amazon EKS, I can allow some permissions with least privileges. For example, if my colleague wants to look at application logs, I can grant permission only to see the logs without editing or deleting the pods.

Amazon EKS helps significantly with the development process because I can rest without worries about outages. If an outage occurs, Amazon EKS automatically replaces nodes. It helps with automation in the development lifecycle.

I am using self-healing nodes on Amazon EKS when deploying new nodes. If nodes become unhealthy, Amazon EKS replaces them with new ones, which helps with my role as a DevOps Engineer.

The benefit of Amazon EKS's automated patching feature saves my time. I can leave it to automatically handle any node issues, which greatly benefits my job efficiency.

From my perspective, Amazon EKS is quite sufficient. The main issue is that Amazon EKS only has an update for Amazon Linux 2023. The challenge occurs when switching to a new operating system. Currently, I am using Amazon Linux 2, but according to AWS information, it will be deprecated. I hope AWS continues to support the operating system for Amazon Linux 2.

I started using Amazon EKS since late 2022.

For stability management, I can allow developers to access Amazon EKS with specific permissions using least privileges. This allows them to perform necessary tasks such as viewing logs without having the ability to edit or delete pods.

Amazon EKS helps significantly with the development process by handling outages automatically. When an outage occurs, it automatically replaces nodes, allowing for continuous development and automated lifecycle management.

I don't frequently communicate with the technical support and customer service of Amazon EKS. They are quite helpful since when I need to verify infrastructure issues from their side, I receive good information. I would rate them seven out of ten because sometimes communication can be challenging due to difference accents

Neutral

Before Amazon EKS, I only used plain containers using Docker on a plain EC2, without services orchestration from AWS.

Initially, I deployed Amazon EKS manually without infrastructure as code. The challenges were related to permissions, but I understood them adequately. It can be accomplished more easily using infrastructure as code tools.

The implementation was done internally.

This solution is very important since my applications must run continuously because many users need the application with minimal downtime.

The price of Amazon EKS is not a major issue since my company accepts it. The price remains good from the company's perspective.

I chose Amazon EKS because AWS provides robust and more complete services than other service providers. I selected Amazon EKS because I wanted to manually override settings. I prefer it over fully managed services like ECS or Fargate. For cost optimization, Amazon EKS fits my needs perfectly.

I am using RDS, EC2, S3, Route 53, and a load balancer alongside Amazon EKS. The overall rating I would give Amazon EKS is 8 out of 10.

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.

Positive

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.