Amazon EKS Reviews

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

We are migrating our services into container services. We build websites and all of our products' backends are based on Amazon EKS.

The simplicity and management portal make it a neat solution. You don't have to fiddle around with too many open source tools, as it's just a comprehensive solution.

We use the pipeline, which is critical for us to deploy automatically. This eliminates manual intervention, which is really helpful.

We initially had some issues getting the logging out of it, because what they're providing into CloudTrail is what we get. If we wanted to go in-depth, we had to deploy third-party tools. We did try the sidecar way of getting the logs. Ideally, if the platform was able to provide those kinds of valuable logs, that would be beneficial. Adding enhanced logging capabilities would be a nice improvement.

We have been using the solution for three plus years.

Time to value is good with fast deployment and very good documentation that is really helpful.

I don't personally deal with the costing part, but I think it's a fair amount. That's the only reason we're using it continuously, as otherwise we would have moved somewhere else.

The implementation was done in-house.

On a scale of 1-10, I rate this solution a 9.

Public Cloud

Amazon Web Services (AWS)

I'm actually working for a company that uses AWS as a cloud platform, and for our clients, we use Amazon EKS. We utilize multiple clusters and other requirements, making Amazon EKS our choice for deployment service or orchestration service.

The usual use case for Amazon EKS is to deploy an application intended for heavy user load and traffic. In technical terms, there are multiple services to choose from, but we choose Amazon EKS for its orchestration, load balancing, and auto-scaling capabilities. With this service, you don't have to worry about manual auto-scaling or manual load balancing. Before Kubernetes, manual intervention was needed for scaling applications, leading to potential crashes if capacity was exceeded. Amazon EKS alleviates those concerns with its auto-scaling feature, where predefined thresholds automatically trigger the launching of additional resources to handle increased traffic. Also, Amazon EKS allows configurations such as minimum and maximum server requirements, ensuring scalability while minimizing costs.

The features of Amazon EKS that I find most valuable include load balancing, auto-scaling, networking, security, and scalability.

Scalability in Amazon EKS refers to the ability to automatically scale up or down your application based on traffic needs. For instance, if you initially expect 10 users but suddenly have 20, Amazon EKS automatically handles the scaling, thereby preventing application crashes and maintaining service availability.

Reliability is crucial when running an application on Amazon EKS, as it ensures your application never crashes. With Amazon EKS, you don't manage the infrastructure yourself; Amazon takes care of it all. You simply need to deploy your container, select the required configurations, and Amazon EKS handles the rest without requiring you to manage the underlying resources.

I have utilized Amazon EKS's integration with IAM, which stands for identity and access management. IAM restricts access to services, ensuring only authorized personnel can access certain capabilities. This prevents mistakes or unauthorized actions, maintaining security throughout the platform.

The support for AWS tools integration in Amazon EKS influences our application development and management significantly. With integrated features related to security, scalability, and billing, we ensure the efficiency of our processes. At my company, we manage around 600 clusters on Kubernetes and emphasize reliability by integrating Amazon EKS with various third-party applications. This integration aids in deployment, security, and ultimately, efficiency, as it ensures that applications remain available and perform efficiently.

One area of Amazon EKS that could be improved is the manual process for adjusting the number of nodes. When I've already defined configurations in Docker or YAML files, it seems unnecessary to go back and make similar adjustments in the console.

I have been working with Amazon EKS for 4.7 years.

I do not often communicate with the technical support and customer service of Amazon EKS.

Negative

Currently, I am using GKE in Google Cloud, which is similar to Amazon EKS. The differences between GKE, Amazon EKS, and AKS mainly come down to minor functional variations; overall, they provide similar capabilities.

Regarding the pricing and licensing of Amazon EKS, I am not entirely certain, but from my perspective, it's somewhat comparable to AWS's compute instances. While it may be on the pricier side due to being a managed service provided by Amazon, the features and functionalities justify the cost, especially for applications requiring reliability and scalability.

I participate in the setup and deployment of Amazon EKS, though I don't do it directly through the console. I use a third-party application called Argo CD, which allows me to deploy Kubernetes applications without accessing the Amazon console directly, making the process efficient and straightforward.

On a scale of one to ten, I rate Amazon EKS a nine out of ten.

Public Cloud

Amazon Web Services (AWS)

The main use cases for Amazon EKS are that we use it normally in some new projects to optimize our costs. Instead of having many ECS services running, we prefer to set up a Kubernetes cluster and set everything there. For me, it is primarily for optimizing our resources.

What I find valuable about Amazon EKS is that it helps us manage all the Kubernetes. It isn't the workload, it is the main part of the Kubernetes, the head of all the cluster. Automatic updates are available, and we can set everything we created in AWS in Kubernetes, including IAM configuration. We can create policies such as creating a private endpoint for S3. The integration of Kubernetes with the AWS ecosystem is the best feature that Amazon EKS provides.

The IAM integration in Amazon EKS helps enhance the authentication processes because we can do this in a more granular way. Using IAM, you can set exactly what the service needs. If a service or application needs to upload objects or data to S3, connect to RDS, or perform other tasks, using IAM is the easiest way. The benefit is that it works in a granular way and it's easy to set up and validate. When you examine the permissions and rules to ensure everything has the correct permission at the correct moment, using IAM is perfect because you can validate and set up everything effectively.

Amazon EKS's support for different AWS tools integrations has accelerated our application development because we can think about all aspects comprehensively. We can architect using AWS services and objects, and Amazon EKS accepts this seamlessly. We don't need to translate the idea for AWS. We can write this idea using AWS objects and services, and Amazon EKS corresponds to that. It accelerates projects and is easy to manage because we can use Terraform to implement it.

I am using the self-healing nodes in the Amazon EKS solution. We have a client with a production workload running on spot instances. When a spot or node crashes, Amazon EKS starts a new node and moves everything before the node stopped. This self-healing is excellent because we don't experience disruptions. We don't face situations where a node stops and we need five minutes to start a new one. We use it in specific environments and can observe the difference when enabling or disabling Amazon EKS self-healing.

We are utilizing the automated patching in Amazon EKS. The valuable benefits I have experienced using the automated patching feature for the Kubernetes clusters directly increase security. Kubernetes typically releases patches focused on security rather than new features. It's beneficial because we can focus on our work without constantly thinking about new patch releases or upgrade deployments. Amazon EKS handles this automatically for us.

We face some issues with Amazon EKS when using the node group to control which nodes can start. We have a limitation where we need to set just one kind of instance - only large instances, only small instances, or only extra-large instances. This is a problem. It would be beneficial if we could specify that certain containers or services start on small instances rather than large ones.

I am uncertain whether Amazon EKS supports all LTS versions, and I think this would be something beneficial. Additionally, AWS has great AI features, so when we need to make updates to Amazon EKS, it would be helpful if AI could assist with planning, identifying migration requirements, and considering costs.

I have been working with Amazon EKS for about two years in production. Including study time and other experiences, I have been involved with it for approximately four years.

I faced challenges in the initial stages with Amazon EKS. The main challenge is that when we set up the cluster, it appears as a huge infrastructure just for a small application. When you set up Amazon EKS, it is configured at a large scale by default. You can't start small and gradually expand. This makes sense because for smaller applications, ECS works effectively. If you want a more integrated ecosystem, you can use Amazon EKS. The challenge lies in migrating everything, as you can't start using Amazon EKS on a small scale. It typically requires a big cluster with one, two, or three nodes. We also faced challenges with developers needing to adapt their mindset to the new way of doing things.

I have escalated questions to the technical support of Amazon EKS two or three times, and they always provided good solutions. When we don't understand the questions, we schedule a call to demonstrate the issue, and we always receive the correct answer.

I reached out for technical support with Amazon EKS because we faced issues starting a service. The way we declared the services was incorrect, but we weren't aware of this. We called AWS support for assistance. Another issue involved a security problem that we identified and reported to AWS.

I would rate the technical support of Amazon EKS a 10. The documentation is good, and when human interaction is needed, it's readily available.

Positive

From my perspective, I don't see any disadvantages of Amazon EKS compared to competitors in the market. Amazon EKS represents the state of the art. While Google has a powerful engine that offers more granular control, the additional configuration can be overwhelming. Amazon EKS balances the power of custom configuration with ease of setup.

I find the pricing of Amazon EKS complicated because I live in Brazil, where we use reals. With the exchange rate and taxes, the price appears six times higher. However, when viewed in dollars, it offers great features at reasonable pricing. Lower prices are always beneficial, and a reduction in hourly cost or promotional discounts would be appreciated, but the current price-to-benefit ratio is worthwhile.

My advice to other organizations considering Amazon EKS for their environment is to plan carefully. I strongly recommend planning and reading the documentation because Amazon EKS is resourceful and typically offers multiple ways to accomplish the same task. Careful planning, reviewing case studies for comparison, and thoughtful migration to Amazon EKS are worthwhile investments. Overall, I rate Amazon EKS a 9 out of 10.

Public Cloud

Amazon Web Services (AWS)

I have a total of around four years of experience in multiple clouds, especially in AWS, and many times I used Amazon EKS for our multiple products and projects.

In our environment, we already have all the other infrastructure and services running on AWS, so we benefit from using Amazon EKS because the other services can easily communicate with it. For example, some of our services need to access S3, and our application objects reside there, so we can easily integrate them with Amazon EKS. We also use IAM rules for integration to provide granular access to resources. As per your question, in our environment, most of our clients and resources reside in AWS, which is why we prefer to deploy other services there, as most of our development environment uses Lightsail. This gives us an edge, allowing us to easily move from development to staging or production environments within the same cloud.

When we compare other clouds, AWS has an edge among all the crowded options right now. My observations and reviews with AWS also affirm this because it provides a user-friendly experience and offers many options that other clouds do not provide. When my team and I work with AWS, we always feel comfortable. I do not know the exact reason behind it; maybe we have a lot of previous experience, and we are familiar with AWS. That is why other reviews from my colleagues at previous companies indicate that AWS has some edge compared to other clouds.

I would recommend Amazon EKS to other organizations because it provides simple configuration, easy management, safety, granular access, and vast monitoring capabilities where we can easily monitor our clusters using CloudWatch. However, I would think about a clearer dashboard for Amazon EKS, but overall, I think it is sufficient.

When we need to deploy the application, we require a large number of instances. Therefore, I hope and believe I will not face out-of-capacity issues in AWS, especially since I have not yet experienced traffic around 50,000 plus, and I believe I will not face such issues in Amazon EKS the next time we deploy with a large number of nodes and worker nodes.

Additionally, the upgradation process of Kubernetes rapidly rolls out new releases, so it should be easier for our production environment to upgrade Amazon EKS clusters. Sometimes when we are going to upgrade the Amazon EKS cluster, we need to check the backups, and we should have options to export our configurations, such as exporting the configuration to S3 or somewhere else to find backups. Other tools, such as Velero, provide this functionality to back up configurations, so I hope this backup process will help us fulfill our backup policies and other requirements.

For the pricing aspect of Amazon EKS, one specific issue arises when we deploy applications, especially as we provide SaaS services to our clients. We would like to know the cost for each customer, but we face issues because AWS charges $70 USD for the Amazon EKS engine. We struggle to divide the worker nodes' fees and the engine cost among clients, as some users have low traffic and visibility while others have large amounts of visibility and traffic. Thus, we face cost-related issues when running multiple customers on the same Amazon EKS cluster.

I have been using the solution for approximately four years.

The initial setup and deployment of Amazon EKS was straightforward; I easily provisioned the correct cluster. Sometimes, due to the depreciation of the AMIs, AWS provides warnings to use the latest version of the EKS AMIs because some of our scripts or Terraform scripts are old. I think it is good practice for AWS to provide messages to the console to upgrade your cluster, but overall, my experience with provisioning the Amazon EKS cluster is good, and I highly appreciate it.

I have not faced any issues that require escalation to customer support, and until today, I do not feel any need to escalate anything to the support team. I am happy with the service.

To meet our requirements, our services need a large amount of CPU and memory, so we need high-spec machines. When we deploy applications, we require a large number of instances.

I have not faced any issues that require escalation to customer support, and until today, I do not feel any need to escalate anything to the support team. I am happy with the service.

Positive

I also work with other clouds, such as Oracle Cloud, but I feel comfortable with AWS because I faced some issues, such as out of capacity when we designed the infrastructure for our large traffic.

The initial setup and deployment of Amazon EKS was straightforward; I easily provisioned the correct cluster. Sometimes, due to the depreciation of the AMIs, AWS provides warnings to use the latest version of the EKS AMIs because some of our scripts or Terraform scripts are old. I think it is good practice for AWS to provide messages to the console to upgrade your cluster, but overall, my experience with provisioning the Amazon EKS cluster is good, and I highly appreciate it.

I used Amazon EKS through its console rather than through the AWS Marketplace.

I have not checked the pricing yet, but I will look into it to see if EKS brings ROI or a return on investment for us.

Regarding self-healing nodes in Amazon EKS, I have not worked on that self-healing feature.

For automated patching in Amazon EKS, I have not used that feature.

Regarding disadvantages of Amazon EKS compared to competitors in the market, I think every cloud provider has the same Kubernetes engine and worker nodes. However, I believe AWS provides a more user-friendly environment, which is why many of our customers are trying to deploy their infrastructure or applications on AWS. I do not think there is any specific reason not to prefer Amazon EKS.

I have not integrated IAM tools with Amazon EKS yet, but my other teams have. I think they used Okta, but I'm not certain about it. I have some demos from a long time ago, but I think Okta is for SSO.

On a scale of one to ten, I rate Amazon EKS a nine out of ten.

Private Cloud

Amazon Web Services (AWS)