Cost effective approaches to achieve failover with AWS ENIs

As the shift of workloads from on-premises datacenter to AWS is becoming more ubiquitous, leveraging AWS best practices for architecting networking solutions can deliver highly scalable, reliable and cost-effective capabilities. Organizations of all sizes globally can also leverage the entire breadth and depth of underlying AWS networking features that are further augmented with a set of AWS Elastic network interfaces (ENI) capabilities.

Amazon Virtual Private Cloud (Amazon VPC) gives you full control over your virtual networking environment, including resource placement, connectivity, and security. In this blog post, we will cover various methods on how to use AWS Elastic Network Interfaces (ENI) feature to deliver high availability and failover features including common use-cases and benefits. An elastic network interface is a logical networking component in a VPC that represents a virtual network card. You can allocate an Elastic IP address which is a public IPv4 address to your AWS account with the ability to associate or disassociate from your instances depending on specific requirements.

Today, customers can build modern AWS networking architectures using Amazon EC2 instances by way of hosting applications with dual functions such as user and management. This requires the need to separate the network for each functionality by creating a separate subnet on the secondary Elastic Network Interface for management traffic. This would not only add another layer of security but adding the secondary elastic network interface allows you to talk to one Amazon EC2 instance from two separate networks simultaneously.

Amazon Web Services (AWS) network interface is a powerful networking construct that provides customers with the flexibility and control to build highly available, fault-tolerant, and cost-effective applications. Elastic Network Interface (ENI) is designed to allow users to quickly create and manage high performance networks across multiple Availability Zones (AZ) in AWS regions. ENIs are used extensively in enterprise deployments but can also be used for personal projects and small businesses.

AWS ENI provides an easy way to create scalable, reliable networks with features such as Elastic IP (EIP) addresses, Security Groups (SG), Network ACLs (NACL), DHCP options sets, subnet peering, and VPC endpoints. With these features, customers can quickly build highly available networks that span multiple availability zones in the same region. The flexibility of ENI allows customers to build secure, reliable networks that meet their business needs.

Figure 1: ENI Failover Architecture Diagram

One common use case for ENI is high availability (HA) web applications. Customers can create a network with multiple Availability Zones in the same region and use an ENI to attach each Availability Zone to the same subnet or CIDR block. This ensures that if one Availability Zone experiences an outage, the other Availability Zones can continue to serve the web application. ENI also allows customers to quickly set up a secure, reliable network that spans multiple Availability Zones and regions.

Another use case for ENI is scalability. Customers can use an ENI to attach multiple subnets across multiple Availability Zones to create a highly available and scalable network that can easily handle increased traffic. This allows customers to quickly build applications that can scale with their business needs.

To use ENI as cost effective method of failover, you can launch two servers in active/standby mode, create a secondary ENI instance to use as failover and associate it to the primary server with an elastic IP. As needed, you can failover to the standby instance and swap the ENI over with a script or with manual intervention.

Another method is to automate the failover process using Amazon CloudWatch alarm on the primary instance to trigger when the instance goes down and have it send you a message in the process, subscribe to Amazon SNS message queue, and trigger an AWS Lambda function that will run off that queue and handle the detaching and reattaching process using the AWS SDK.

The tertiary method would be to configure a DNS failover using Amazon Route 53 by creating a weighted group of records with the same names, types and have Amazon Route 53 perform health check. Based on the results of the health checks, Amazon Route 53 responds to DNS queries.

In more complex configurations, you can create tree of records that route traffic based on multiple criteria. You can use latency alias records to route traffic to the region that provides the best latency. The latency alias records might have weighted records in each region as the alias target. The weighted records can route traffic to Amazon EC2 instances based on instance type. With a simpler configuration, you can configure Amazon Route 53 to route traffic based on the health of your resources. To understand more, you may also refer to AWS documentation on detailed scenarios for network interfaces.

One of the benefits of using an ENI is that it can reduce operational overhead. Customers only need to manage one network and all changes made to the network are automatically applied across all Availability Zones. This can eliminate the need for customers to manually configure and update routing tables in each Availability Zone. It also eliminates the need for customers to constantly monitor and manage their networks, allowing them to focus on their core business.

However, ENI’s may not be the best way to failover in all architectures as customers can also implement a feature called Amazon EC2 Auto Scaling that helps to achieve the same effect. Instead of paying more for high-availability and redundancy, you can deploy a group of horizontally scaled, optimal sized EC2 instances that are setup in an Amazon EC2 auto-scaling cluster. With this solution, in the event one instance goes down, another Amazon EC2 instance can process the ingress or egress traffic.

Finally, using the manual ENI failover process to standby instance is easy compared to automating failover process with Amazon EC2 instances. Customers can use ENI to quickly set up redundant networks that span multiple AWS regions. Customers can create an ENI and attach it to subnets in different regions for high availability and scalability across the globe. This allows customers to quickly build applications that are resilient against regional outages and can easily scale with their business needs.

When architecting these networking solutions on AWS using ENIs, it is also important to understand cost implications to your AWS environment. Currently, there is no charge for the first Elastic IP (EIP) address that gets associated with running Amazon EC2 instance, however customers are charged for each additional EIP including any idle EIPs assigned to your AWS account. As per recent AWS announcement blog, starting February 1, 2024 there will be a charge of $0.005 per IP per hour for all public IPv4 addresses, regardless of if these are attached to a service or not. You can also refer to the AWS blog on how to identify and optimize public IPv4 address usage in order to monitor usage of EIPs as well as estimate future costs and identify cost optimization opportunities.

In this blog post we covered how you can architect AWS networking solutions using Elastic Network Interfaces and walked through different use-cases to achieve high availability and scalability. We also covered some of the key benefits and cost considerations when leveraging ENIs to support design, implementation and operational support for business applications or workloads on AWS.

[ST1]If this is written jointly AWS, please ensure there is a co-author agreement is in place

I will confirm and get back, thanks. [HA2]