Modernizing on-premises applications using Amazon Elastic Kubernetes Service and Amazon Elastic File System

Modern applications are expected to be available every minute of every day. Achieving the highest levels of availability requires more than setting up redundant hardware, networking, power, and other infrastructure components. You need to architect from the ground up to ensure availability in the event of natural disasters and technology failures. On-premises, this involves setting up synchronous replication between two sites (i.e. metroclustering) and pre-scaling hardware based on your best demand estimates. Synchronous replication to different sites increases management and operational complexity. Pre-scaling hardware requires complex demand forecasting. Additionally, replication to multiple sites and pre-scaling hardware both require significant upfront capital expenditures.

In comparison, modernizing applications on the AWS cloud for the highest levels of availability is simpler, quicker, and removes the need for significant upfront capital expenditures because you only pay for what you use. AWS provides a number of cloud primitives resilient to natural disasters that automatically scale and adapt to customer demand, enabling you to choose the primitive that best fits your needs. Building using AWS primitives is simpler and faster because AWS automatically synchronizes data across multiple sites and will seamlessly scale hardware as your demand increases. Using AWS as your building blocks for technology infrastructure lets you to focus on the continuous innovations of your application rather than the complexity of building and maintaining a highly available architecture.

To build modern architectures in the cloud, you can use a microservice design principle, such as containers, where pieces of your resources are loosely coupled with each other so that they can be scaled and updated individually without having an impact on the availability of your application. Amazon Elastic Kubernetes Service (EKS) is a managed Kubernetes service that automates container deployments, scaling, and management, enabling organizations to build scalable, fault-tolerant application environments. To persist data for your application in a similarly scalable and resilient way, you need a storage platform that transparently adapts to customer demands while minimizing your administrative overhead thereby freeing your teams to focus on application innovation. Amazon Elastic File System (EFS) is a fully managed, highly scalable file storage service that works on NFSv4.0 or 4.1 protocol that provides durable, available, and cost-effective cloud storage for mission-critical applications. With 11-9’s of durability and multi-availability zone (AZ) redundancy, EFS enables organizations to power scalable, resilient workloads while minimizing administrative overhead.

In this blog, we’ll show you how using Amazon Elastic Kubernetes Service (EKS) and Amazon Elastic File System (EFS) work together to quickly modernize your on-premises applications so that your team can focus on delivering exceptional customer experiences rather than undifferentiated engineering work.

Solution Overview

To build a modern application, you must architect your AWS resources such that even if a single Availability Zone were to fail due to a natural disaster or due to a technology failure, your application will still be available. We refer to this concept as Availability Zone Independence (AZI). AZI isolates resources contained inside an Availability Zone from interacting with resources in different Availability Zone. Since no requests are shared across Availability Zones, an AZI architecture has the lowest likelihood of a request being routed to an impacted instance. An AZI architecture therefore provides the highest level of availability by reducing the probability of any single request touching an affected instance.

Each stack in an independent Availability Zone must be highly available. We therefore need to choose a highly available application layer. For a modern architecture, a highly available application layer needs to automatically scale to support variable peaks in customer demand. We selected Amazon EKS, a containerized architecture because it scales automatically based on demand. It simplifies management and orchestration of containerized applications removing the overhead of architecture maintenance.

A highly available application also requires a storage layer that is resilient to disasters and outages. To ensure this level of resiliency, we want our storage to be replicated and synchronized across multiple Availability Zones(AZs). Furthermore, in case of gray failures, to maintain the integrity of an application, we need to be able to concurrently access data in different Availability Zones. At AWS, we call this type of a storage as a “regional” storage offering. We chose Amazon EFS as our regional storage service because it offers a familiar NFS interface and integrates easily with Amazon EKS using an Amazon EFS Container Storage Interface (CSI) driver. Amazon EFS provides virtually unlimited storage and elastically scales to support your storage needs. EFS automatically scales performance to meet your application’s demand. This significantly reduces the likelihood of customer demand overwhelming your application because Amazon EFS automatically optimizes storage and performance for changing levels of customer demand.

This architecture allows you to build modern applications that will deliver the highest level of availability and scalability by ensuring your application automatically scales compute and storage to support variable peaks in demand. We’ll show you three common scenarios that utilize our proposed modern architecture to deliver the highest level of availability.

• Scenario 1 – Single AWS account using single VPC.
• Scenario 2 – Single AWS account using two VPC’s.
• Scenario 3 – Two AWS accounts using two VPC’s.

The solution we describe corresponds with ideas of AWS Fault Isolation, Availability Zone Independence, Availability Zone Affinity, and Static Stability Patterns. There are three common scenarios outlined below that can utilize the proposed architecture.

Considerations

1. You should understand networking topics including regions, Availability Zones, Availability Zone ID’s, VPC peering and DNS is essential to this architecture, review this material before making use of this architecture.

2. Amazon EFS recommends to use parallelism to maximize performance.  This includes multiple clients, clients with multiple threads, file systems with multiple directories and even multiple file systems associated with different application functions.

3. Make sure you are running the latest versions of the Amazon EFS mount helper and/or the Amazon EFS CSI driver to ensure correct mount target assignment.

Scenario 1 – Single AWS account using single VPC

Figure 1 illustrates the recommended architecture for a single AWS account using a single VPC. This example uses an Amazon EKS cluster as the compute connecting to Amazon EFS storage. The EKS cluster will connect to the EFS mount target in the same AZ using the NFS protocol. That means the network traffic will stay local to an AZ as there is a one-to-one relationship between compute (EKS clusters) and the EFS mount targets. This architecture improves the overall performance and ensures failures are contained since the traffic won’t cross zonal boundaries. This containment of failures within a single Availability Zones without impacting resources in other Availability Zone is referred to as “fault isolation”. To improve resiliency, EKS worker nodes are distributed across the Availability Zones and mounted to a respective EFS mount target within each AZ.

Figure 1 – Single account using single VPC

Scenario 2 – Single AWS account using two VPC’s

Figure 2 illustrates the recommended architecture for a single account and 2 VPC’s.  In this architecture you will notice the addition of VPC peering to facilitate the communication between the two VPC networks. VPC Peering is a networking feature in AWS that allows you to connect two Virtual Private Clouds (VPCs) in the same or different AWS regions, enabling them to route traffic between each other privately. While there is a VPC peering connection, the traffic stays within the same AZ so it doesn’t have to cross zonal boundaries. This architecture also benefits from fault isolation, performance improvements and cost optimizations.

Figure 2 – Single account using two VPC’s

Scenario 3 – Two AWS accounts using two VPC’s

Sometimes, customers may use multiple accounts to mount to an EFS file system. AWS maps the physical AZs randomly to the AZ names for each account. When using multiple accounts, AWS recommends to use the AZ ID instead of the AZ name.  For example, in Figure 3, the accounts contain the same Availability Zones but they are mapped to different AZ names. The Availability Zone ID in the center of the diagram is used to determine the Availability Zone mapping. In this example you can see Account 111111111111 with us-east-1a AZ maps to AZ ID of use1-az1 while the same us-east-1a AZ in Account 222222222222 maps to a different AZ ID of use1-az3.  When using multiple accounts, focus on the AZ-ID rather than the Availability Zone name as this will provide the mapping to ensure that traffic stays within the same zone.

The Amazon EFS team has included AZ-ID awareness in the latest driver for both EFS mount helper and the Amazon EFS CSI driver.  The driver now queries the compute client to determine the source AZ-ID and uses DNS to map to the corresponding mount target of EFS.

Figure 3 – Availability Zone ID mapping

Figure 4 shows the connection between the compute and the local EFS mount target using DNS.  As stated above, the DNS resolution process will first query the AZ-ID of the client and then request the DNS entry for that associated EFS mount target. This will ensure that traffic stays local to the zone thereby ensuring that the architecture contains the same benefits as outlined including resiliency, contained fault isolation, performance optimization and cost optimization.

Figure 4 – Two accounts using two VPC’s

Conclusion

In this post we showed you how to leverage Amazon EFS for persistent storage with Amazon EKS. The recommended architecture of using multiple Availability Zones ensures that high availability and resiliency can be performant and cost optimized using the concepts of Availability Zone Independence.  We showed you three common scenarios that utilize our proposed modern architecture to deliver the highest level of availability. This included Scenario 1 – Single AWS account using single VPC, Scenario 2 – Single AWS account using two VPC’s, and Scenario 3 – Two AWS accounts using two VPC’s.

To see these concepts in action, explore the following Amazon EFS walkthroughs.