NetScaler ADC and Amazon Web Services Validated Reference Design Part 3

September 21, 2022

Author:  Luis Ugarte, Beth Pollack, Dave Potter

Continued from Part 2

Use cases

Compared to alternative solutions that require each service to be deployed as a separate virtual appliance, NetScaler ADC on AWS combines L4 load balancing, L7 traffic management, server offload, application acceleration, application security, and other essential application delivery capabilities in a single VPX instance, conveniently available via the AWS Marketplace. Furthermore, everything is governed by a single policy framework and managed with the same, powerful set of tools used to administer on-premises NetScaler ADC deployments. The net result is that NetScaler ADC on AWS enables several compelling use cases that not only support the immediate needs of today’s enterprises, but also the ongoing evolution from legacy computing infrastructures to enterprise cloud data centers.

Production delivery for Web and Virtual Apps and Desktops applications

Enterprises actively embracing AWS as an infrastructure-as-a-service (IaaS) offering for production delivery of applications can now front-end those applications with the same cloud networking platform used by the largest websites and cloud service providers in the world. Extensive offload, acceleration, and security capabilities can be leveraged to enhance performance and reduce costs.

Citrix Desktops as as Service is a cloud ready solution for delivering any Windows application or desktop into a cloud service delivered across any network, to any device. By deploying this expanded app and desktop delivery platform today, you are positioned to leverage any virtual infrastructure or cloud management platform. This gives you the ability to take advantage of the automation and orchestration capabilities of cloud computing.

Hybrid Cloud designs

Enterprise IT organizations that follow a hybrid cloud strategy get the best of both worlds by selecting which applications and which usage scenarios fit best in their private cloud and which fit best in a public cloud enabling them to flex, grow and transform to meet the demands of the modern workplace.

With NetScaler ADC on AWS, hybrid clouds that span enterprise data centers and extend into AWS can benefit from the same cloud networking platform. NetScaler ADC significantly eases the transition of applications and workloads back and forth between a private data center and AWS. The full suite of capabilities, ranging from intelligent database load balancing with DataStream to unprecedented application visibility with AppFlow®, and real-time monitoring and response with Action Analytics, can be leveraged with NetScaler ADC on AWS.

Business continuity

Enterprises looking to use AWS as part of their disaster recovery and business continuity plans can rely upon NetScaler ADC global server load balancing running both on-premises and within AWS to continuously monitor availability and performance of both enterprise data centers and AWS environments, ensuring users are always sent to the optimal location.

When you configure GSLB on NetScaler ADC appliances and enable Metric Exchange Protocol (MEP), the appliances use the DNS infrastructure to connect the client to the data center that best meets the criteria that you set. The criteria can designate the least loaded data center, the closest data center, the data center that responds most quickly to requests from the client’s location, a combination of those metrics, and SNMP metrics. An appliance keeps track of the location, performance, load, and availability of each data center and uses these factors to select the data center to which to send a client request. A GSLB configuration consists of a group of GSLB entities on each appliance in the configuration. These entities include GSLB sites, GSLB services, GSLB virtual servers, load balancing and/or content switching servers, and ADNS services.

Development and testing

Enterprises run production delivery on-premises, but using AWS for development and testing can now include NetScaler ADC within their AWS test environments, speeding time-to-production due to better mimicry of the production implementation within their test environments.

In each use case, network architects can also leverage Citrix CloudBridge—-configured either as a standalone instance or as feature of a NetScaler ADC platinum edition instance—-to secure and optimize the connection between one or more enterprise data centers and the AWS Cloud, thereby speeding data transfer/synchronization and minimizing network cost.

AWS Network architecture – ENI and EIP

NetScaler ADC instances launched into a VPC can have up to eight elastic network interfaces (ENIs). In turn, each ENI can be assigned one or more private IP addresses, with each of these optionally being mapped to an elastic IP address that is publicly routable.

What makes the network interfaces and IP addresses “elastic” in this case is the ability to programmatically remap them to other instances — a feature that enables recovery from instance or Availability Zone failures without having to wait for hardware replacements, or for DNS changes to fully propagate to all of your customers.

Other details to account for include the following:

• An instance can have different ENIs in different subnets (but not in different Availability Zones).
• Each ENI must have at least one IP address assigned to it, and must be assigned to a Security Group (see below).
• Addresses 1–4 for each subnet (that is, 10.x.x.1-4) are reserved for use by Amazon.
• NetScaler ADC is only aware of private IP addresses. Any EIPs that are assigned, do not show up within the NetScaler ADC CLI or any related management tools.

EC2 versus VPC

AWS encompasses multiple different services, such as Amazon Simple Storage Services (S3), Amazon Elastic Compute Cloud (EC2), and Amazon Virtual Private Cloud (VPC). The distinction between the latter two is important in this case. In particular, with EC2, virtual machine instances are limited to a single networking interface and single IP address. Furthermore, there are minimal networking features and controls. This precludes the use of EC2 for NetScaler ADC—-which requires a minimum of three IP addresses—-and is why NetScaler ADC instances can only be launched within an AWS VPC.

VPCs not only support virtual machines with multiple interfaces and multiple private and public IP addresses, but also allow you to create and control an isolated virtual networking environment, with its own IP address range, subnets, routing tables, and network gateways.

Regions and availability zones

Within the AWS Cloud, Regions refer to a specific geographic location, such as US East. Within each Region there are at least two Availability Zones, each of which can be thought of as an independent cloud data center that has been engineered to be insulated from failures in other Availability Zones and to provide inexpensive, low-latency network connectivity to other Availability Zones within the same Region.

By implementing instances in separate Availability Zones, you can protect your applications from failures that impact a single location.

Limitations and dependencies for network architects to be aware of at this level include the following:

• Although a Virtual Private Cloud can span multiple Availability Zones, it cannot span multiple Regions.
• Individual subnets within a VPC cannot span multiple Availability Zones.
• All traffic entering or leaving a VPC must be routed via a corresponding default Internet gateway

Configure VPX on AWS

In this exercise, you’ll create a VPC and subnet, and launch a public-facing instance into your subnet. Your instance will be able to communicate with the Internet, and you’ll be able to access your instance from your local computer using SSH (if it’s a Linux instance) or Remote Desktop (if it’s a Windows instance). In your real world environment, you can use this scenario to create a public-facing web server; for example, to host a blog.

Note:

This exercise is intended to help you set up your own nondefault VPC quickly. If you already have a default VPC and you want to get started launching instances into it (and not creating or configuring a new VPC), see Launching an EC2 Instance into Your Default VPC.

To complete this exercise, you’ll do the following:

• Create a nondefault VPC with a single public subnet. Subnets enable you to group instances based on your security and operational needs. A public subnet is a subnet that has access to the Internet through an Internet gateway.
• Create a security group for your instance that allows traffic only through specific ports.
• Launch an Amazon EC2 instance into your subnet.
• Associate an Elastic IP address with your instance. This allows your instance to access the Internet.

Before you can use Amazon VPC for the first time, you must sign up for AWS. When you sign up, your AWS account is automatically signed up for all services in AWS, including Amazon VPC. If you haven’t created an AWS account already, go to http://aws.amazon.com, and then choose Create a Free Account.

Step 1: Create the VPC

In this step, you’ll use the Amazon VPC wizard in the Amazon VPC console to create a VPC. The wizard performs the following steps for you:

• Creates a VPC with a /16 CIDR block (a network with 65,536 private IP addresses). For more information about CIDR notation and the sizing of a VPC, see Your VPC.
• Attaches an Internet gateway to the VPC. For more information about Internet gateways, see Internet Gateways.
• Creates a size /24 subnet (a range of 256 private IP addresses) in the VPC.
• Creates a custom route table, and associates it with your subnet, so that traffic can flow between the subnet and the Internet gateway. For more information about route tables, see Route Tables.

The following diagram represents the architecture of your VPC after you’ve completed this step.

Create a VPC using the Amazon VPC Wizard

1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

    

2. In the navigation bar, on the top-right, take note of the region in which you’ll be creating the VPC. Ensure that you continue working in the same region for the rest of this exercise, as you cannot launch an instance into your VPC from a different region. For more information about regions, see Regions and Availability Zones.

    

3. In the navigation pane, choose VPC dashboard, and then choose Start VPC Wizard.

    

   

    

    

   Note:

    

   Do not choose Your VPCs in the navigation pane; you cannot access the VPC wizard from this page.

    

    

4. Choose the first option, VPC with a Single Public Subnet, and then choose Select.

    

5. On the configuration page, enter a name for your VPC in the VPC name field; for example, my-vpc, and enter a name for your subnet in the Subnet name field. This helps you to identify the VPC and subnet in the Amazon VPC console after you’ve created them. For this exercise, you can leave the rest of the configuration settings on the page, and choose Create VPC.

    

   (Optional) If you prefer, you can modify the configuration settings as follows, and then choose Create VPC.

    

   • The IP CIDR block displays the IP address range that you’ll use for your VPC (10.0.0.0/16), and the Public subnet field displays the IP address range you’ll use for the subnet (10.0.0.0/24). If you don’t want to use the default CIDR ranges, you can specify your own. For more information, see VPC and Subnet Sizing.

      

   • The Availability Zone list enables you to select the Availability Zone in which to create the subnet. You can leave No Preference to let AWS choose an Availability Zone for you. For more information, see Regions and Availability Zones.

      

   • In the Add endpoints for S3 to your subnets section, you can select a subnet in which to create a VPC endpoint to Amazon S3 in the same region. For more information, see VPC Endpoints.

      

   • The Enable DNS hostnames option, when set to Yes, ensures that instances that are launched into your VPC receive a DNS hostname. For more information, see Using DNS with Your VPC.

      

   • The Hardware tenancy option enables you to select whether instances launched into your VPC are run on shared or dedicated hardware. Selecting a dedicated tenancy incurs additional costs. For more information about hardware tenancy, see Dedicated Instances.

      

6. A status window shows the work in progress. When the work completes, choose OK to close the status window.

    

7. The Your VPCs page displays your default VPC and the VPC that you just created. The VPC that you created is a nondefault VPC, therefore the Default VPC column displays No.

    

View information about your VPC

After you’ve created the VPC, you can view information about the subnet, the Internet gateway, and the route tables. The VPC that you created has two route tables — a main route table that all VPCs have by default, and a custom route table that was created by the wizard. The custom route table is associated with your subnet, which means that the routes in that table determine how the traffic for the subnet flows. If you add a new subnet to your VPC, it uses the main route table by default.

To view information about your VPC

1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
2. In the navigation pane, choose Your VPCs. Take note of the name and the ID of the VPC that you created (look in the Name and VPC ID columns). You will use this information to identify the components that are associated with your VPC.
3. In the navigation pane, choose Subnets. The console displays the subnet that was created when you created your VPC. You can identify the subnet by its name in Name column, or you can use the VPC information that you obtained in the previous step and look in the VPC column.
4. In the navigation pane, choose Internet Gateways. You can find the Internet gateway that’s attached to your VPC by looking at the VPC column, which displays the ID and the name (if applicable) of the VPC.
5. In the navigation pane, choose Route Tables. There are two route tables associated with the VPC. Select the custom route table (the Main column displays No), and then choose the Routes tab to display the route information in the details pane:
   • The first row in the table is the local route, which enables instances within the VPC to communicate. This route is present in every route table by default, and you can’t remove it.
   • The second row shows the route that the Amazon VPC wizard added to enable traffic destined for an IP address outside the VPC (0.0.0.0/0) to flow from the subnet to the Internet gateway.
6. Select the main route table. The main route table has a local route, but no other routes.

Step 2: Create a security group 12

A security group acts as a virtual firewall to control the traffic for its associated instances. To use a security group, you add the inbound rules to control incoming traffic to the instance, and outbound rules to control the outgoing traffic from your instance. To associate a security group with an instance, you specify the security group when you launch the instance. If you add and remove rules from the security group, we apply those changes to the instances associated with the security group automatically.

Your VPC comes with a default security group. Any instance not associated with another security group during launch is associated with the default security group. In this exercise, you’ll create a new security group, WebServerSG, and specify this security group when you launch an instance into your VPC.

Topics

• Creating Your WebServerSG Security Group
• Rules for the WebServerSG Security Group

Creating Your WebServerSG Security Group

You can create your security group using the Amazon VPC console.

Rules for the WebServerSG Security Group

The following table describes the inbound and outbound rules for the WebServerSG security group. You’ll add the inbound rules yourself. The outbound rule is a default rule that allows all outbound communication to anywhere — you do not need to add this rule yourself.

To create the WebServerSG security group and add rules

1. Open the Amazon VPC console at https://aws.amazon.com/console/.
2. In the navigation pane, choose Security Groups.
3. Choose Create Security Group.
4. In the Group name field, enter WebServerSG as the name of the security group, and provide a description. You can optionally use the Name tag field to create a tag for the security group with a key of Name and a value that you specify.
5. Select the ID of your VPC from the VPC menu, and then choose Yes, Create.
6. Select the WebServerSG security group that you just created (you can view its name in the Group Name column).
7. On the Inbound Rules tab, choose Edit and add rules for inbound traffic as follows, and then choose Save when you’re done:
   • Select HTTP from the Type list, and enter 0.0.0.0/0 in the Source field.
   • Choose Add another rule, then select HTTPS from the Type list, and enter 0.0.0.0/0 in the Source field.
   • Choose Add another rule. If you’re launching a Linux instance, select SSH from the Type list, or if you’re launching a Windows instance, select RDP from the Type list. Enter your network’s public IP address range in the Source field. If you don’t know this address range, you can use 0.0.0.0/0 for this exercise.

Caution:

If you use 0.0.0.0/0, you enable all IP addresses to access your instance using SSH or RDP. This is acceptable for the short exercise, but it’s unsafe for production environments. In production, you’ll authorize only a specific IP address or range of addresses to access your instance.

Continued on Part 4