Page 1 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

Avi Vantage Reference Architecture for Amazon Web view online

Services
Introduction
About AWS

Amazon Web Services (AWS) is the largest public cloud services provider offering fully automated, elastic, and resilient
services pertaining to cloud infrastructure and application provisioning.

The Amazon Elastic Compute Cloud (Amazon EC2) service provides on-demand, scalable compute services for hosting
compute hosts. This typically resides in an Amazon Virtual Private Cloud (VPC) which provides isolation and a virtual network
for the resources to operate in.

All AWS offerings can be customized and automated to facilitate minimal deployment and management intervention.

Enterprises adopt Amazon Web Services (AWS) to serve as a natural extension to their data centers and private clouds. These
organizations are application-centric and adopt continuous delivery practices across multiple environments (on-premises and
cloud) and diverse infrastructures (bare-metal servers, VMs, and containers).

Traditional appliance-based load balancers lack the ability to elegantly scale across multiple clouds and do not offer real-time
visibility into end-user experience or application performance. These legacy solutions also lack native integration with AWS
APIs and require manual configuration. Each instance needs to be managed separately and is not developer-friendly.

Cloud-native solutions like AWS?s Elastic Load Balancing (ELB) and Application Load Balancing (ALB) also lack enterprise-class
load balancing capabilities, multi-cloud traffic management, and real-time application analytics.

Premium Load Balancing for AWS with Avi Networks

The Avi Vantage Platform is a next-generation, full-featured elastic application services fabric that is built on software-defined
architectural principles.

Avi Vantage offers application services such as load balancing, security, application monitoring and analytics, and multi-cloud
traffic management for workloads deployed in bare metal, virtualized, or container environments in a data center or a public
cloud (Amazon Web Services, Google Cloud Platform, or Microsoft Azure).

A consistent feature set across diverse cloud environments enable IT teams to be agile without needing to constantly re-skill
their IT personnel.

Copyright © 2020 Avi Networks, Inc. Page 2 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

What Avi Vantage Provides for AWS

Enterprises modernize and maximize infrastructure utilization with AWS. The next phase of this modernization is to extend the
app-centricity to the networking stack. Avi Networks delivers elastic application services that extend beyond load balancing to
deliver real-time app and security insights, simplify troubleshooting, auto scale predictively, and enable developer self- service
and automation.

Avi Networks provides an ELB-like experience for applications deployed in on-premises and multiple cloud infrastructures.

Full-featured load balancing

AWS ELB and ALB provide basic load balancing capabilities and lack enterprise-class features and advanced policy support. Avi
Vantage delivers full-featured load balancing, including multiple load-balancing algorithms, advanced HTTP content switching
capabilities, comprehensive persistence, customizable health monitoring, DNS services, and GSLB across multiple clouds. Avi
Vantage provides these capabilities in an as-a-service experience similar to AWS ELB with native AWS API integration.

Automation

Avi Vantage is a 100% REST API-based solution, that offers Python SDK, Ansible playbooks, and CloudFormation templates for
automating configuration and operations. Avi Vantage natively integrates with AWS APIs for spinning up EC2 instances,
allocating Elastic IPs, Route53 integration, auto scaling, and availability zone awareness. Avi Vantage simplifies CI/CD ops by
supporting blue-green deployments and canary upgrades.

Advanced Security

AWS ELB and ALB lack advanced security policies, SSL insights, and DDoS capabilities. Avi Vantage provides network ACLs,
advanced HTTP security policies, SSL insights, DDoS detection and mitigation capabilities, along with micro-segmentation in
container environments. Avi Vantage also provides Web Application Firewall (WAF) capabilities seamlessly integrated with the
load balancing feature sets.

Visibility and Monitoring

With ALB and ELB, admins and developers do not have integrated real-time telemetry and must deploy third party tools and
services for analytics. Avi Vantage delivers real-time insights into application health, end-user experience, log analytics, and
security insights.

Copyright © 2020 Avi Networks, Inc. Page 3 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

Multi-cloud load balancing

Inconsistent capabilities across clouds create challenges for network engineers to move workloads across multiple cloud
infrastructures. This also forces enterprises to re-invest in training and education. Using native tools locks enterprises to the
specific cloud, preventing workload mobility and increasing business risk. Avi Vantage enables dynamic workload mobility
across clouds based on business metrics such as cost, performance, security, and compliance requirements, reducing risk and
providing flexibility.

Reduced TCO

With AWS, the cost of load balancing (ELB, ALB), security (WAF), and visibility (third-party logging tools) adds up to a
significantly higher investment. Avi Vantage reduces the total cost of ownership (TCO) while providing rich functionality.

Intended Audience

To understand this reference architecture, we assume familiarity with: * Basic AWS functionality, particularly Networking
(VPC), Compute (EC2) and DNS (Route53). For complete information, refer to AWS Documentation. * Basic understanding
of Load Balancing and ADC, refer to Avi Documentation.

Avi Vantage Reference Deployments in AWS

This section discusses few reference deployments where Avi Vantage is used to provide application delivery services to
workloads on AWS.

Single VPC, Multiple Availability Zones (AZs)

The single VPC deployment has all workloads present within a single AWS VPC. This is a typical deployment when an
application is hosted solely on AWS. Multiple Availability Zones (AZs) are leveraged for high availability and redundancy.

Copyright © 2020 Avi Networks, Inc. Page 4 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

Consider the following points while deploying Avi Vantage in this architecture: * Spawn the Avi Controller cluster in the same
VPC. As the Avi Controller cluster has three controller nodes, these nodes can be spawned in separate Availability Zones to
ensure high availability. * The virtual service is configured with multiple VIPs, one per Availability Zone. As the virtual service is
distributed across multiple AZs, a minimum of one Service Engine per AZ is sufficient to provide high availability. This can be
achieved by updating Buffer Service Engines to zero when the default Elastic HA (N+M) HA mode is selected. * As there will
be one VIP created per AZ, the virtual service will end up having multiple VIPs. To redirect client traffic to various SEs, Route
53 or Avi DNS needs to be configured. DNS Load balancing will ensure that all VIPs are advertised and utilized.

Centralized Management VPC, Dedicated Application VPCs

This deployment separates out the management function (Avi Controller) to a separate VPC. The workloads are present in
other VPCs. One AWS cloud is configured within the Avi Controller cluster for each VPC where application delivery services
are required.

This separation of management VPC is typically preferred when a central IT team is tasked with managing the infrastructure,
but wants to provide multi-tenant, self-service functionality to its internal users. The AWS resource usage billing is also
separated out in this architecture, to be at the per-VPC level.

Per-line-of-business VPCs is a primary use case for this approach.

Copyright © 2020 Avi Networks, Inc. Page 5 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

Consider the following points while deploying Avi Vantage in this architecture:

Spawn the Avi Controller cluster in the management VPC. As the Avi Controller cluster has three controller nodes,
these nodes can be spawned in separate AZs to ensure high availability.
Configuring a separate AWS cloud in Avi Vantage, per application VPC. Each AWS cloud can be associated with a
separate Avi tenant, so that only designated users can provision or manage virtual services for that VPC.
Within each VPC, it is recommended to use multiple AZs for Service Engine (and correspondingly virtual service) HA.
Route 53 or Avi DNS integration will be required to advertise and manage the virtual services with multiple VIPs.

AWS Multi-Region Deployment with GSLB

This deployment comprises of applications that are available in multiple AWS regions simultaneously, for redundancy as well as
better latency and user experience for global end users.

Copyright © 2020 Avi Networks, Inc. Page 6 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

In this deployment, at least two VPCs, each in a different region are used. There is one Avi Controller cluster per VPC. As the
applications are deployed in each VPC, the Avi Controller of the respective VPC manages the virtual service for the
application.

To tie multiple virtual services across the VPCs or regions and make them available to the end-users transparently, Avi
Vantage?s Global Server Load Balancing (GSLB) feature is used across all the controller clusters.

Hybrid ? Avi Controller On-Premises, Applications in AWS

This deployment comprises of an architecture where the Avi Controller is present on-premises in the customer datacenter.
The application workloads could either be hosted exclusively in an AWS region, or present in both AWS and the on-premises
datacenter.

Copyright © 2020 Avi Networks, Inc. Page 7 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

In the case where the application workloads are exclusively in AWS, an AWS cloud is configured in the Avi Controller. The Avi
Controller spawns Service Engines in the AWS VPC provided.

This scenario requires connectivity between the datacenter and AWS VPC to allow management communication between Avi
SEs and Avi Controllers.

Copyright © 2020 Avi Networks, Inc. Page 8 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

The second use case has the application workloads hosted in the on-premises datacenter as well as AWS. The on-premises
datacenter could be the primary application workload provider, with the AWS cloud being configured for a smaller percentage
of traffic, or for scaling up in case of traffic rise. This provides a seamless way to increase application availability during high
load, while making efficient use of cloud resources.

Hybrid ? Multi Cloud with GSLB

A combination of (c) and (d), this is a multi-cloud approach. In this scenario, the multiple Avi Controller clusters are all not on
AWS. Instead, they could be distributed across public and private cloud ecosystems, such as AWS, Google Cloud Platform,
Microsoft Azure, Openstack, VMware, etc.

GSLB is used to manage DNS queries for the virtual services and redirect requests to individual application instances as
required.

Given Avi Vantage?s extensive support for multiple ecosystem, this enables end customers to have a truly diverse and resilient
architecture for applications and be served seamlessly.

Avi Vantage Architecture

The Avi Vantage Platform provides enterprise-grade distributed ADC solutions for on-premises as well as public cloud
infrastructure. Avi Vantage also provides inbuilt analytics that improves the end-user application experience as well as ease of
operationalizing for network administrators.

Avi Vantage is a complete software solution which runs on commodity x86 servers or as a Virtual Machine and is entirely
enabled by REST APIs.

Avi Architecture Components

Copyright © 2020 Avi Networks, Inc. Page 9 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

Avi Architecture Components

The Avi Vantage Platform is built on software-defined architectural principles which separates the control and data planes.
The product components include:

Avi Controller (control plane): Central policy and management plane that analyzes the real-time telemetry collected
from Avi Service Engines and presents visual, actionable dashboards using an intuitive user interface built on RESTful
APIs.

Avi Service Engines (data plane): Distributed load balancers that are deployed closest to the applications across
multiple cloud infrastructures. The Avi Service Engines collect and send real-time application telemetry to Avi
Controller.

Interactions with AWS Services

The above diagram depicts the Avi Vantage deployment process briefly.

1. The Avi Controller is available in the AWS Marketplace. A new instance of the controller is deployed.

2.

Copyright © 2020 Avi Networks, Inc. Page 10 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

2. Once the Avi Controller is instantiated and is running, the controller UI is accessed, and an AWS Cloud is configured
within the controller. This entails providing AWS credentials, VPC details, etc. At the end of this process, an Amazon
Machine Images (AMI) is generated and uploaded to an Amazon Simple Storage Service (S3) bucket within the
account. This AMI is used to deploy Service Engines as required.

3. In this step, a new virtual service is configured using the Avi UI. Details related to the VIP, backend pool members,
FQDN for the virtual service are entered. This in turn triggers the following events:

4. Step 4a: The controller scans for information regarding any existing Service Engine with capacity to place the virtual
service. Step 4b: As this is a new controller (or if all the Service Engines are loaded), a new Service Engine instance is
launched in EC2 with the AMI uploaded by the controller in step 2.
Step 4c: The Service Engine instance obtains a couple of ENIs ? one for management communication to the controller
and other SEs, and another for data traffic between clients and the application servers.
Step 4dd: Route 53 is updated with the FQDN, if specified, and the VIP is advertised.

5. The virtual service is marked up and starts load balancing operations for traffic from the client to the application
servers.

The various AWS components that Avi Vantage interacts with are explained below:

i. Authentication and IAM Roles

The Avi Controller needs permissions to deploy and manage the Service Engines, and optionally interact with Route 53 on
AWS. The following are the two methods used by Avi Vantage for authentication:

1. Access key ID and secret access key

2. IAM role that has been configured and used while creating the Avi Controller. For complete information on creating
IAM roles, refer to iam role setup for installation into aws.

ii. EC2: Instances

Avi Vantage deploys the controller and service engines in the AWS EC2 environment. Typically, a VPC would have been
provisioned for your infrastructure, including the application servers, etc. Avi Vantage will be deployed within this VPC and
will utilize resources connected to this VPC, as described in the sections below.

iii. Controller resources and deployment

The Avi Vantage Controller is available in the AWS marketplace at the link here.

To get started, launch an Avi controller instance on AWS EC2.

The Avi Controller can be deployed on different instance sizes, depending on the scale expected. At a minimum, an m4.
2xlarge instance is recommended. Please refer to this link for controller sizing details.

Once the Avi Controller is launched and is online, perform the initial configuration for the cloud type you want to use (In this
document, we assume that the backend servers are on AWS, and this guide will use the AWS cloud).

At this stage, once the AWS cloud credentials (or IAM roles have been provided), Avi Vantage reports back with cloud status
as Ready after verification.

The system is now available to configure virtual services.

iv. SE resources and deployment

Copyright © 2020 Avi Networks, Inc. Page 11 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

The Avi Service Engine (SE) is the load balancing entity on which the virtual service IP (VIP) is programmed. The SEs are
automatically spawned by the Avi Controller when an application is configured. The entire lifecycle of the SE is automated.

The SE can be of varied instance type, depending on application needs ? from [Link] to c4.8xlarge. Depending on
application traffic and load requirements, the appropriate instance type can be configured.

In addition, multiple SEs can be spawned (scaled out) to handle more incoming traffic.

v. Networking: VPC, Subnets, ENIs, Elastic IP

The Avi Controller interacts with the following AWS networking elements:

Virtual Private Cloud (VPC) : Avi Vantage is typically deployed in a VPC. All instantiations of Service Engines, virtual
service creation, addition of application pool members happens in this context.
Subnets: Avi Vantage accesses AWS subnets to obtain IP addresses for multiple purposes:
IP address for the Service Engines? management interface.
IP address for the virtual services.
IP address for the Service Engine data ENIs, to be able to communicate with the back-end application servers.
ENIs: Avi Vantage automatically creates ENIs and assigns IP addresses from the appropriate subnet, and attaches
these to the requisite Service Engine.
Elastic IP: Avi Vantage can use an elastic IP with a public IP for a virtual service, if required. This is not a mandatory
configuration. If it is not a public facing application, you can continue using the internal IP address accessible within
the VPC.

vi. DNS - Route 53 and IPAM

Avi Vantage provides native support for DNS (to resolve virtual service IPs) and IPAM (for virtual service IP address
management). Both these services are optional, but will likely be used in production deployments.

In addition to providing native support, Avi Vantage also interacts with various third party services depending on the
configured cloud ecosystem.

In the case of AWS, IPAM for native AWS workloads is provided by default, without any configuration. As the controller and
service engines are powered up, they interact with the AWS VPC and networking infrastructure to receive appropriate IP
addresses.

For DNS, the options available for AWS are either Avi Vantage?s Native DNS or Route 53.

When Route 53 is used, Avi Vantage will request an optional FQDN for each virtual service being created. On providing a valid
FQDN, Avi Vantage will program this record on AWS Route 53 DNS.

When the virtual service is deleted, all resources including the DNS record are removed.

For more details on configuring DNS with Avi Vantage on AWS, refer to Avi Vantage DNS with AWS Cloud.

Starting release 17.1.2, Avi Vantage is multi-AZ capable. As a result, virtual service can be hosted on Service Engines in
different availability zones. One virtual service IP (VIP) will be configured in each AZ, and the DNS record can point to the
multiple VIPs for load balancing.

vii. AWS Auto Scale Groups, SNS and SQS

Copyright © 2020 Avi Networks, Inc. Page 12 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

Starting Avi Vantage release 17.1.2, Avi pool configuration can reference an AWS Auto Scale group. When this is configured,
Avi Vantage polls the AWS Auto Scale group for membership changes, and synchronizes the Avi pool configuration
accordingly.

For example, when a new application instance is added to the AWS auto scale group, Avi Vantage will automatically add it to
the Avi pool configuration without any user intervention. This new instance will then start servicing client requests.
Conversely, when an instance is removed from the AWS auto scale group, the same event is synchronized with Avi Vantage?s
pool configuration.

For more details on this feature, refer to Avi Integration with AWS Auto Scaling Groups.

Starting release 17.2.3, Avi Vantage can take over the management of an AWS Auto Scale group. In this case, the membership
for the AWS Auto Scale group can be administered by Avi Vantage?s metrics, providing more granular control over member
scale out and scale in.

Advantages of using Avi Vantage

A single Avi Controller cluster can manage hundreds of Service Engines. The Avi Controller has the intelligence to place
virtual services on appropriate SEs. Due to Avi Vantage?s architecture, the distributed load balancers can achieve unique high-
availability features.

1. Per-application load balancer:

a. As Avi Vantage enables the deployment of hundreds of distributed load balancers and it becomes administratively
simpler to dedicate a load balancer per application.
b. A per-app load balancer reduces security concerns from neighboring applications.
c. A per-app load balancer also removes the noisy neighbor problem.
d. A per-app load balancer can be configured by enabling the Per Application knob within the Service Engine Group tab.

2. Auto-healing load balancers:

a. As Avi Controller can communicate with AWS to dynamically spin up and spin down Service Engines, it can
automatically recover lost load balancing capacity. If one of the Service Engines fails or faces some issues, Avi
Controller moves the virtual service to a buffer Service Engine and will then spin up a new Service Engine to recover
the HA capability.
b. Auto-healing improves high availability and reduces application downtime.
c. Auto-healing provides ease of use and management for load balancing administrators.

3. Auto scaling load balancers:

Avi Controller provides automatic scaling up and down of load balancing capacity depending upon the virtual service
requirements. Auto scaling is decided based on the Service Engine CPU usage. The following are few examples:
a) If Service Engine CPU usage goes above 80% (MAX_ALLOWED_CPU) then Avi Controller will spin up one more instance of
Service Engine and perform the scale out operation.
b) If Service Engine CPU usage goes below 30% (MIN_ALLOWED_CPU) then Avi Controller will spin down one of the
instances of Service Engine and perform the scale in operation.

Sizing and Performance

Controller Sizing

During the deployment, the Avi Controller?s system capacity can be specified based on the following system resource
allocations:

Copyright © 2020 Avi Networks, Inc. Page 13 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

CPUs
Memory (RAM)
Disk

There is a minimum requirement for each of the above, and larger amount of resources will be required based on the virtual
service scale and application load.

In a production environment, a cluster of the three similar-sized controllers is recommended.

For a non-production environment, a single controller may suffice.

In case of deployment in AWS, provisioning of the Avi Controller AMI is allowed only on instances with enough resources.

For more details on controller sizing, refer to Avi Controller Sizing.

Service Engine Sizing

i. SE Instance Size

When deploying an Avi SE on AWS, the instance type needs to be selected.

Avi Vantage supports many instance types and sizes. The main considerations are support for at least two ENIs, 1 vCPU, and 1
GB RAM. By default, a [Link] instance is instantiated. This can be modified in the SE group properties.

For general purpose requirements, t2.* instances may suffice. Note that t2.* instances are not supported in a
dedicated VPC.
For high performance requirements, Avi recommends using the C5.* and R4.* instances as these provide superior
performance, and also support enhanced networking.

ii. Virtual Service Scale per SE

The number of virtual services that can be created on each instance type also varies.

Prior to release 17.1, Avi Vantage supported one data NIC, and hence the number of virtual services that can be created was (n-
1), where n is the number of IPv4 addresses supported on the NIC. One IPv4 address was reserved as the interface IP address.
For example [Link] supports 10 IP addresses on each interface. Hence, a maximum of 10 ? 1 = 9 virtual services can be
configured.

Starting release 17.1, Avi Vantage supports multiple data NICs, and the number of virtual services that can be created is equal
to (n-1) * (m-1). Here, n is the number of IPv4 addresses supported on each NIC, and m is the number of NICs supported on
the instance. For example [Link] supports 10 IP addresses on each interface. And supports 3 interfaces. Hence, a maximum
of (10 ? 1) * (3 ? 1) = 18 virtual services can be configured.

For more details on AWS ENI and IPv4 limits, refer to the AWS documentation for Elastic Network Interfaces.

iii. Per-App Deployment

The per-app deployment can be turned on in the Service Engine Group properties using a check-box as shown below.

Copyright © 2020 Avi Networks, Inc. Page 14 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

The per-app deployment mode is useful in cases where higher resilience is required for the applications. As the number of
virtual services is limited to two per Service Engine, the failure domain for a given application is reduced. In this mode, each
Service Engine is limited to hosting a maximum of two virtual services, and four pools per virtual service. There is no limit on
the size of the Service Engine and this can be selected based on the sizing considerations.

Each license in this mode counts as a 0.25 core, providing cost optimization.

iv. Service Engine Performance

The performance of Avi Service Engine can be characterized based on the following parameters:

SSL transactions per second (TPS)

SSL TPS signifies the number of GET requests for a 128-byte page, that can be served by Avi Vantage in one second,
over an HTTPS connection.

As x86 chipsets increasingly provide advanced encryption offload capabilities, the Avi SE takes advantage of these x86
features to provide high SSL performance.

AWS instances such as the C5.* are compute optimized with dedicated Intel V3 CPUs, providing TPS performance
comparable to a bare-metal SE.

L4, HTTP and HTTPS throughput

This metric portrays the maximum traffic that can be serviced by the Service Engine, and is calculated by requesting
multiple GET requests for a 128 KB document.

The network performance is largely constrained by the hypervisor or QoS bandwidth limitations. In case of AWS as
well, the instances which support Enhanced Networking, such as c4., c5., r4., and some m4. instances, provide high
throughput.

Concurrent connections per second

Copyright © 2020 Avi Networks, Inc. Page 15 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

This metric signifies the number of open, concurrent connections that the Avi SE can process. This is largely governed
by the memory size.

Provisioning
This section covers Avi Vantage features in AWS, and references related to provisioning, monitoring, and troubleshooting
various Avi Vantage elements.

Provisioning - CloudFormation

The Avi Controller can be deployed and configured using AWS CloudFormation templates. This are useful when the controller
deployment needs to be done multiple times.

In addition to the controller deployment, the CloudFormation template can also contain the configuration data for the pools,
virtual services and others, that need to be configured at initialization.

A sample CloudFormation template is available here.

Scaling - Auto Scale

Avi Vantage collects more than 700 data points per second regarding the performance and characteristics of various network
and compute entities ? service engines, backend application servers, front-end (virtual service) CPU/traffic load, etc. Using
these metrics, Avi Vantage can predict and fine-tune its functioning. One important use-case is knowing when to scale the
system automatically, based on the current and predicted loads.

At first level, Avi Vantage can scale out the virtual service to another Service Engine based on these metrics. This will ensure
that any increase in load to the virtual service is met with using the additional service engine instance(s) that have been
created. This can be done manually or automatically based on CPU utilization thresholds, or by using user-defined
ControlScripts tied to specific events.

On AWS, service engine scale out is a matter of checking whether an existing service engine instance with sufficient capacity
exists within the same SE group. If not, a new EC2 instance is spawned and assimilated into the group of SEs servicing the
virtual service.

The second level of auto scaling is when the backend application pool servers need to be scaled out as well. If the load on an
application has increased, chances are that only scaling the load balancer will not alleviate the load on the application servers.

Avi Vantage facilitates auto scaling of application server by using an user-defined event (or a set of events) to be the trigger
to create another instance of the application in AWS. Once this is done, Avi Vantage adds the new instance into the virtual
service?s server pool so that it can start serving the incoming requests.

Scaling - Cloud bursting

Cloud bursting is a mechanism to handle excess on-demand load for a temporary period. As an example, consider major US
shopping events such as Black Friday, Cyber Monday, or financial deadlines such as those for filing tax returns. In these cases,
the retailers? and the financial service providers? infrastructure, respectively, would encounter load that is tens to hundreds
of times greater.

Copyright © 2020 Avi Networks, Inc. Page 16 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

In this scenario, if the organization?s primary data center is on-premises, a secondary overflow cloud can be configured on
public cloud such as AWS.

When the load reaches a certain threshold, Avi Controller can trigger scripts to * Provision and enable the application and
infrastructure on AWS. * Re-configure DNS to prioritize a certain, user-defined amount of traffic to AWS using GSLB. *
Continue to monitor the load.

Once the load reaches the normal levels, the cloud infrastructure can be stopped to save costs.

This scenario can be provisioned to be triggered manually, or automatically without requiring operator intervention.

Operations and Troubleshooting

The following are the options available for debugging and operationalizing Avi Vantage: * Events * Alerts * Services * Traffic
Capture

Events

Events are used throughout Avi Vantage to provide a history of relevant changes that have occurred. Events are a permanent
record, and can be used to generate alerts which can take action on the event. In the UI, events may be viewed within the
context of specific objects, such as a virtual service, a pool, or a server. For more information, refer to Events Overview.

Alerts

In its most generic form, alerts are intended to inform administrators of significant events within Avi Vantage. In addition to
system events? triggers, alerts may also be triggered based on one or more of the 200+ metrics that Avi Vantage is tracking.
For more information, refer to Events Overview, Backup and Restore Avi Vantage Configuration.

Services

Avi Vantage provides alert actions using various mechanisms. You can configure remote syslog server, Splunk, email, SNMP
TRAP etc., to log appropriate events and logs into an external audit system.

Copyright © 2020 Avi Networks, Inc. Page 17 of 18

Avi Vantage Reference Architecture for Amazon Web Services Avi Networks — Technical Reference (18.1)

Traffic Capture

Most connection troubleshooting or traffic data may be done quickly using virtual services logs. However, some
troubleshooting may require full visibility into the packet transmission. Avi Vantage provides packet capture, which runs
TCPdump against a designated virtual service. The packet capture is done on all Service Engines that may be hosting the
virtual service and is then collated into a completed capture. For more information, refer to Traffic Capture.

Resources
1. Avi Knowledge Base: [Link]
2. Avi Vantage AWS Installation Guide: [Link]
services/
3. Avi SDK: [Link]
4. Avi Devops repository ? automation samples: [Link]

Document Revision History

Revision Avi Vantage Release Modification
1 17.2.1 This feature was introduced.

Copyright © 2020 Avi Networks, Inc. Page 18 of 18