Citrix ADC VPX on AWS Deployment Guide 编辑

Overview

Citrix ADC is an application delivery and load balancing solution that provides a high-quality user experience for web, traditional, and cloud-native applications regardless of where they are hosted. It comes in a wide variety of form factors and deployment options without locking users into a single configuration or cloud. Pooled capacity licensing enables the movement of capacity among cloud deployments.

As an undisputed leader of service and application delivery, Citrix ADC is deployed in thousands of networks around the world to optimize, secure, and control the delivery of all enterprise and cloud services. Deployed directly in front of web and database servers, Citrix ADC combines high-speed load balancing and content switching, HTTP compression, content caching, SSL acceleration, application flow visibility, and a powerful application firewall into an integrated, easy-to-use platform. Meeting SLAs is greatly simplified with end-to-end monitoring that transforms network data into actionable business intelligence. Citrix ADC allows policies to be defined and managed using a simple declarative policy engine with no programming expertise required.

Citrix ADC VPX

The Citrix ADC VPX product is a virtual appliance that can be hosted on a wide variety of virtualization and cloud platforms.

This deployment guide focuses on Citrix ADC VPX on Amazon Web Services.

Amazon Web Services

Amazon Web Services (AWS) is a comprehensive, evolving cloud computing platform provided by Amazon that includes a mixture of infrastructure as a service (IaaS), platform as a service (PaaS) and packaged software as a service (SaaS) offerings. AWS services offer tools such as compute power, database storage, and content delivery services.

AWS offers the following essential services:

• AWS Compute Services

• Migration Services

• Storage

• Database Services

• Management Tools

• Security Services

• Analytics

• Networking

• Messaging

• Developer Tools

• Mobile Services

AWS Terminology

Here is a brief description of key terms used in this document that users must be familiar with:

• Elastic Network Interface (ENI) – A virtual network interface that users can attach to an instance in a Virtual Private Cloud (VPC).

• Elastic IP (EIP) address – A static, public IPv4 address that users have allocated in Amazon EC2 or Amazon VPC and then attached to an instance. Elastic IP addresses are associated with user accounts, not a specific instance. They are elastic because users can easily allocate, attach, detach, and free them as their needs change.

• Subnet – A segment of the IP address range of a VPC with which EC2 instances can be attached. Users can create subnets to group instances according to security and operational needs.

• Virtual Private Cloud (VPC) – A web service for provisioning a logically isolated section of the AWS cloud where users can launch AWS resources in a virtual network that they define.

Here is a brief description of other terms used in this document that users should be familiar with:

• Amazon Machine Image (AMI) – A machine image, which provides the information required to launch an instance, which is a virtual server in the cloud.

• Elastic Block Store – Provides persistent block storage volumes for use with Amazon EC2 instances in the AWS Cloud.

• Simple Storage Service (S3) – Storage for the Internet. It is designed to make web-scale computing easier for developers.

• Elastic Compute Cloud (EC2) – A web service that provides secure, resizable compute capacity in the cloud. It is designed to make web-scale cloud computing easier for developers.

• Elastic Kubernetes Service (EKS) – Amazon EKS is a managed service that makes it easy for users to run Kubernetes on AWS without needing to stand up or maintain their own Kubernetes control plane. … Amazon EKS runs Kubernetes control plane instances across multiple Availability Zones to ensure high availability. Amazon EKS is a managed service that makes it easy for users to run Kubernetes on AWS without needing to install and operate their own Kubernetes clusters.

• Application Load Balancing (ALB) – Amazon ALB operates at layer 7 of the OSI stack so it’s employed when users want to route or select traffic based on elements of the HTTP or HTTPS connection, whether host-based or path-based. The ALB connection is context-aware and can have direct requests based on any single variable. Applications are load balanced based on their peculiar behavior not solely on server (operating system or virtualization layer) information.

• Elastic Load Balancing (ALB/ELB/NLB) – Amazon ELB Distributes incoming application traffic across multiple EC2 instances, in multiple Availability Zones. This increases the fault tolerance of user applications.

• Network Load Balancing (NLB) – Amazon NLB operates at layer 4 of the OSI stack and below and is not designed to consider anything at the application layer such as content type, cookie data, custom headers, user location, or application behavior. It is context-less, caring only about the network-layer information contained within the packets it is directing. It distributes traffic based on network variables such as IP address and destination ports.

• Instance type – Amazon EC2 provides a wide selection of instance types optimized to fit different use cases. Instance types comprise varying combinations of CPU, memory, storage, and networking capacity and give users the flexibility to choose the appropriate mix of resources for their applications.

• Identity and Access Management (IAM) – An AWS identity with permission policies that determine what the identity can and cannot do in AWS. Users can use an IAM role to enable applications running on an EC2 instance to securely access their AWS resources. IAM role is required for deploying VPX instances in a high-availability setup.

• Internet Gateway – Connects a network to the Internet. Users can route traffic for IP addresses outside their VPC to the Internet gateway.

• Key pair – A set of security credentials with which users prove their identity electronically. A key pair consists of a private key and a public key.

• Route table – A set of routing rules that controls the traffic leaving any subnet that is associated with the route table. Users can associate multiple subnets with a single route table, but a subnet can be associated with only one route table at a time.

• Auto Scale Groups – A web service to launch or terminate Amazon EC2 instances automatically based on user-defined policies, schedules, and health checks.

• CloudFormation – A service for writing or changing templates that creates and deletes related AWS resources together as a unit.

• Web Application Firewall (WAF) – WAF is defined as a security solution protecting the web application layer in the OSI network model. A WAF does not depend on the application it is protecting. This document focuses on the exposition and evaluation of the security methods and functions provided specifically by Citrix WAF.

• Bot – Bot is defined as an autonomous device, program, or piece of software on a network (especially the internet) that can interact with computer systems or users to run commands, reply to messages, or perform routine tasks. A bot is a software program on the internet that performs repetitive tasks. Some bots can be good, while others can have a huge negative impact on a website or application.

Sample Citrix WAF on AWS Architecture

The preceding image shows a virtual private cloud (VPC) with default parameters that builds a Citrix WAF environment in the AWS Cloud.

In a production deployment, the following parameters are set up for the Citrix WAF environment:

• This architecture assumes the use of an AWS CloudFormation Template and an AWS Quick Start Guide, which can be found here: GitHub/AWS-Quickstart/Quickstart-Citrix-ADC-VPX.

• A VPC that spans two Availability Zones, configured with two public and four private subnets, according to AWS best practices, to provide you with your own virtual network on AWS with a /16 Classless Inter-Domain Routing (CIDR) block (a network with 65,536 private IP addresses). *

• Two instances of Citrix WAF (Primary and Secondary), one in each Availability Zone.

• Three security groups, one for each network interface (Management, Client, Server), that acts as virtual firewalls to control the traffic for their associated instances.

• Three subnets, for each instance- one for management, one for client, and one for back-end server.

• An internet gateway attached to the VPC, and a Public Subnets route table which is associated with public subnets so as to allow access to the internet. This gateway is used by the WAF host to send and receive traffic. For more information on Internet Gateways, see: Internet Gateways. *

• 5 Route tables-one public route table associated with client subnets of both primary and secondary WAF. The remaining 4 route tables link to each of the 4 private subnets (management and server-side subnets of primary and secondary WAF). *

• AWS Lambda in WAF takes care of the following:

  • Configuring two WAF in each availability zone of HA mode

  • Creating a sample WAF Profile and thus pushing this configuration with respect to WAF

• AWS Identity and Access Management (IAM) to securely control access to AWS services and resources for your users. By default, the CloudFormation Template (CFT) creates the required IAM role. However, users can provide their own IAM role for Citrix ADC instances.

• In the public subnets, two managed Network Address Translation (NAT) gateways to allow outbound internet access for resources in public subnets.

Note:

The CFT WAF template that deploys the Citrix WAF into an existing VPC skips the components marked by asterisks and prompts users for their existing VPC configuration.

Backend servers are not deployed by the CFT.

Logical Flow of Citrix WAF on AWS

Logical Flow

The Web Application Firewall can be installed as either a Layer 3 network device or a Layer 2 network bridge between customer servers and customer users, usually behind the customer company’s router or firewall. It must be installed in a location where it can intercept traffic between the web servers that users want to protect and the hub or switch through which users access those web servers. Users then configure the network to send requests to the Web Application Firewall instead of directly to their web servers, and responses to the Web Application Firewall instead of directly to their users. The Web Application Firewall filters that traffic before forwarding it to its final destination, using both its internal rule set and the user additions and modifications. It blocks or renders harmless any activity that it detects as harmful, and then forwards the remaining traffic to the web server. The preceding image provides an overview of the filtering process.

Note:

The diagram omits the application of a policy to incoming traffic. It illustrates a security configuration in which the policy is to process all requests. Also, in this configuration, a signatures object has been configured and associated with the profile, and security checks have been configured in the profile.

As the diagram shows, when a user requests a URL on a protected website, the Web Application Firewall first examines the request to ensure that it does not match a signature. If the request matches a signature, the Web Application Firewall either displays the error object (a webpage that is located on the Web Application Firewall appliance and which users can configure by using the imports feature) or forwards the request to the designated error URL (the error page).

If a request passes signature inspection, the Web Application Firewall applies the request security checks that have been enabled. The request security checks verify that the request is appropriate for the user website or web service and does not contain material that might pose a threat. For example, security checks examine the request for signs indicating that it might be of an unexpected type, request unexpected content, or contain unexpected and possibly malicious web form data, SQL commands, or scripts. If the request fails a security check, the Web Application Firewall either sanitizes the request and then sends it back to the Citrix ADC appliance (or Citrix ADC virtual appliance), or displays the error object. If the request passes the security checks, it is sent back to the Citrix ADC appliance, which completes any other processing and forwards the request to the protected web server.

When the website or web service sends a response to the user, the Web Application Firewall applies the response security checks that have been enabled. The response security checks examine the response for leaks of sensitive private information, signs of website defacement, or other content that should not be present. If the response fails a security check, the Web Application Firewall either removes the content that should not be present or blocks the response. If the response passes the security checks, it is sent back to the Citrix ADC appliance, which forwards it to the user.

Cost and Licensing

Users are responsible for the cost of the AWS services used while running AWS deployments. The AWS CloudFormation templates that can be used for this deployment include configuration parameters that users can customize as necessary. Some of those settings, such as instance type, affect the cost of deployment. For cost estimates, users should refer to the pricing pages for each AWS service they are using. Prices are subject to change.

A Citrix ADC WAF on AWS requires a license. To license Citrix WAF, users must place the license key in an S3 bucket and specify its location when they launch the deployment.

Note:

When users elect the Bring your own license (BYOL) licensing model, they should ensure that they have an AppFlow feature enabled. For more information on BYOL licensing, see: AWS Marketplace/Citrix ADC VPX - Customer Licensed.

The following licensing options are available for Citrix ADC WAF running on AWS. Users can choose an AMI (Amazon Machine Image) based on a single factor such as throughput.

• License model: Pay as You Go (PAYG, for the production licenses) or Bring Your Own License (BYOL, for the Customer Licensed AMI - Citrix ADC Pooled Capacity). For more information on Citrix ADC Pooled Capacity, see: Citrix ADC Pooled Capacity.

  • For BYOL, there are 3 licensing modes:

    • Configure Citrix ADC Pooled Capacity: Configure Citrix ADC Pooled Capacity

    • Citrix ADC VPX Check-in and Check-out Licensing (CICO): Citrix ADC VPX Check-in and Check-out Licensing

    Tip:

    If users elect CICO Licensing with VPX-200, VPX-1000, VPX-3000, VPX-5000, or VPX-8000 application platform type, they should ensure that they have the same throughput license present in their ADM licensing server.

    • Citrix ADC virtual CPU Licensing: Citrix ADC virtual CPU Licensing

Note:

If users want to dynamically modify the bandwidth of a VPX instance, they should elect a BYOL option, for example Citrix ADC pooled capacity where they can allocate the licenses from Citrix ADM, or they can check out the licenses from Citrix ADC instances according to the minimum and maximum capacity of the instance on demand and without a restart. A restart is required only if users want to change the license edition.

• Throughput: 200 Mbps or 1 Gbps

• Bundle: Premium

Deployment Options

This deployment guide provides two deployment options:

• The first option is to deploy using a Quick Start Guide format and the following options:

  • Deploy Citrix WAF into a new VPC (end-to-end deployment). This option builds a new AWS environment consisting of the VPC, subnets, security groups, and other infrastructure components, and then deploys Citrix WAF into this new VPC.

  • Deploy Citrix WAF into an existing VPC. This option provisions Citrix WAF in the user existing AWS infrastructure.

• The second option is to deploy using WAF StyleBooks using Citrix ADM

Deployment Steps using a Quick Start Guide

Step 1: Sign in to the User AWS Account

• Sign in to the user account at AWS: AWS with an IAM (Identity and Access Management) user role that has the necessary permissions to create an Amazon Account (if necessary) or sign in to an Amazon Account.

• Use the region selector in the navigation bar to choose the AWS Region where users want to deploy High Availability across AWS Availability Zones.

• Ensure that the user AWS account is configured correctly, refer to the Technical Requirements section of this document for more information.

Step 2: Subscribe to the Citrix WAF AMI

• This deployment requires a subscription to the AMI for Citrix WAF in the AWS Marketplace.

• Sign in to the user AWS account.

• Open the page for the Citrix WAF offering by choosing one of the links in the following table.

  • When users launch the Quick Start Guide in to deploy Citrix WAF in Step 3 below, they use the Citrix WAF Image parameter to select the bundle and throughput option that matches their AMI subscription. The following list shows the AMI options and corresponding parameter settings. The VPX AMI instance requires a minimum of 2 virtual CPUs and 2 GB of memory.

Note:

To retrieve the AMI ID, refer to the Citrix Products on AWS Marketplace page on GitHub: Citrix Products on AWS Marketplace.

• AWS Marketplace AMI

  • Citrix Web Application Firewall (WAF) - 200 Mbps: Citrix Web App Firewall (WAF) - 200 Mbps

  • Citrix Web Application Firewall (WAF) - 1000 Mbps: Citrix Web App Firewall (WAF) - 1000 Mbps

• On the AMI page, choose Continue to Subscribe.

• Review the terms and conditions for software usage, and then choose Accept Terms.

Note:

Users receive a confirmation page, and an email confirmation is sent to the account owner. For detailed subscription instructions, see Getting Started in the AWS Marketplace Documentation: Getting Started.

• When the subscription process is complete, exit out of AWS Marketplace without further action. Do not provision the software from AWS Marketplace—users will deploy the AMI with the Quick Start Guide.

Step 3: Launch the Quick Start Guide to Deploy the AMI

• Sign in to the user AWS account, and choose one of the following options to launch the AWS CloudFormation template. For help with choosing an option, see deployment options earlier in this guide.

  • Deploy Citrix VPX into a new VPC on AWS using one of the AWS CloudFormation Templates located here:

    • Citrix/Citrix-ADC-AWS-CloudFormation/Templates/High-Availability/Across-Availability-Zone

    • Citrix/Citrix-ADC-AWS-CloudFormation/Templates/High-Availability/Same-Availability-Zone

  • Deploy Citrix WAF into a new or existing VPC on AWS using the AWS Quickstart template located here: AWS-Quickstart/Quickstart-Citrix-ADC- WAF

Important:

If users are deploying Citrix WAF into an existing VPC, they must ensure that their VPC spans across two Availability Zones, with one public and two private subnets in each Availability Zone for the workload instances, and that the subnets are not shared. This deployment guide does not support shared subnets, see Working with Shared VPCs: Working with Shared VPCs. These subnets require NAT Gateways in their route tables to allow the instances to download packages and software without exposing them to the internet. For more information about NAT Gateways, see: NAT Gateways. Configure the subnets so there is no overlapping of subnets.

Also, users should ensure that the domain name option in the DHCP options is configured as explained in the Amazon VPC documentation found here: DHCP Options Sets: DHCP Options Sets. Users are prompted for their VPC settings when they launch the Quick Start Guide.

• Each deployment takes about 15 minutes to complete.

• Check the AWS Region that is displayed in the upper-right corner of the navigation bar, and change it if necessary. This is where the network infrastructure for Citrix WAF will be built. The template is launched in the US East (Ohio) Region by default.

Note:

This deployment includes Citrix WAF, which isn’t currently supported in all AWS Regions. For a current list of supported Regions, see the AWS Service Endpoints: AWS Service Endpoints.

• On the Select Template page, keep the default setting for the template URL, and then choose Next.

• On the Specify Details page, specify the stack name as per user convenience. Review the parameters for the template. Provide values for the parameters that require input. For all other parameters, review the default settings and customize them as necessary.

• In the following table, parameters are listed by category and described separately for the deployment option:

• Parameters for deploying Citrix WAF into a new or existing VPC (Deployment Option 1)

• When users finish reviewing and customizing the parameters, they should choose Next.

Parameters for Deploying Citrix WAF into a new VPC

VPC Network Configuration

For reference information on this deployment refer to the CFT template here: AWS-Quickstart/Quickstart-Citrix-ADC-WAF/Templates.

Bastion host configuration

Citrix WAF Configuration

Pooled Licensing configuration

• Configure Citrix ADC Pooled Capacity: Configure Citrix ADC Pooled Capacity
• Citrix ADC VPX Check-in and Check-out Licensing (CICO): Citrix ADC VPX Check-in and Check-out Licensing

• Citrix ADC virtual CPU Licensing: Citrix ADC virtual CPU Licensing
  	License Bandwidth in Mbps	0 Mbps	Only if the licensing mode is Pooled-Licensing, then this field comes into the picture. It allocates an initial bandwidth of the license in Mbps to be allocated after BYOL ADCs are created. It should be a multiple of 10 Mbps.
  	License Edition	Premium	License Edition for Pooled Capacity Licensing Mode is Premium
  	Appliance Platform Type	Optional	Choose the required Appliance Platform Type, only if users opt for CICO licensing mode. Users get the options listed: VPX-200, VPX-1000, VPX-3000, VPX-5000, VPX-8000
  	License Edition	Premium	License Edition for vCPU based Licensing is Premium.

AWS Quick Start Guide Configuration

Note:

We recommend that users keep the default settings for the following two parameters, unless they are customizing the Quick Start Guide templates for their own deployment projects. Changing the settings of these parameters will automatically update code references to point to a new Quick Start Guide location. For more details, see the AWS Quick Start Guide Contributor’s Guide located here: AWS Quick Starts/Option 1 - Adopt a Quick Start.

• On the Options page, users can specify a Resource Tag or key-value pair for resources in your stack and set advanced options. For more information on Resource Tags, see: Resource Tag. For more information on setting AWS CloudFormation Stack Options, see: Setting AWS CloudFormation Stack Options. When users are done, they should choose Next.

• On the Review page, review and confirm the template settings. Under Capabilities, select the two check boxes to acknowledge that the template creates IAM resources and that it might require the capability to auto-expand macros.

• Choose Create to deploy the stack.

• Monitor the status of the stack. When the status is CREATE_COMPLETE, the Citrix WAF instance is ready.

• Use the URLs displayed in the Outputs tab for the stack to view the resources that were created.

Step 4: Test the Deployment

We refer to the instances in this deployment as primary and secondary. Each instance has different IP addresses associated with it. When the Quick Start has been deployed successfully, traffic goes through the primary Citrix WAF instance configured in Availability Zone 1. During failover conditions, when the primary instance does not respond to client requests, the secondary WAF instance takes over.

The Elastic IP address of the virtual IP address of the primary instance migrates to the secondary instance, which takes over as the new primary instance.

In the failover process, Citrix WAF does the following:

• Citrix WAF checks the virtual servers that have IP sets attached to them.

• Citrix WAF finds the IP address that has an associated public IP address from the two IP addresses that the virtual server is listening on. One that is directly attached to the virtual server, and one that is attached through the IP set.

• Citrix WAF reassociates the public Elastic IP address to the private IP address that belongs to the new primary virtual IP address.

To validate the deployment, perform the following:

• Connect to the primary instance

For example, with a proxy server, jump host (a Linux/Windows/FW instance running in AWS, or the bastion host), or another device reachable to that VPC or a Direct Connect if dealing with on-prem connectivity.

• Perform a trigger action to force failover and check whether the secondary instance takes over.

Tip:

To further validate the configuration with respect to Citrix WAF, run the following command after connecting to the Primary Citrix WAF instance:

Sh appfw profile QS-Profile

Connect to Citrix WAF HA Pair using Bastion Host

If users are opting for Sandbox deployment (for example, as part of CFT, users opt for configuring a Bastion Host), a Linux bastion host deployed in a public subnet will be configured to access the WAF interfaces.

In the AWS CloudFormation console, which is accessed by signing in here: Sign in, choose the master stack, and on the Outputs tab, find the value of LinuxBastionHostEIP1.

• PrivateManagementPrivateNSIP and PrimaryADCInstanceID key’s value to be used in the later steps to SSH into the ADC.

• Choose Services.

• On the Compute tab, select EC2.

  • Under Resources, choose Running Instances.

  • On the Description tab of the primary WAF instance, note the IPv4 public IP address. Users need that IP address to construct the SSH command.

• To store the key in the user keychain, run the command ssh-add -K [your-key-pair].pem

On Linux, users might need to omit the -K flag.

• Log in to the bastion host using the following command, using the value for LinuxBastionHostEIP1 that users noted in step 1.

ssh -A ubuntu@[LinuxBastionHostEIP1]

• From the bastion host, users can connect to the primary WAF instance by using SSH.

ssh nsroot@[Primary Management Private NSIP]

Password: [Primary ADC Instance ID]

Now users are connected to the primary Citrix WAF instance. To see the available commands, users can run the help command. To view the current HA configuration, users can run the show HA node command.

Citrix Application Delivery Management

Citrix Application Delivery Management Service (Citrix ADM) provides an easy and scalable solution to manage Citrix ADC deployments that include Citrix ADC MPX, Citrix ADC VPX, Citrix Gateway, Citrix Secure Web Gateway, Citrix ADC SDX, Citrix ADC CPX, and Citrix SD-WAN appliances that are deployed on-premises or on the cloud.

Users can use this cloud solution to manage, monitor, and troubleshoot the entire global application delivery infrastructure from a single, unified, and centralized cloud-based console. Citrix ADM Service provides all the capabilities required to quickly set up, deploy, and manage application delivery in Citrix ADC deployments and with rich analytics of application health, performance, and security.

Citrix ADM Service provides the following benefits:

• Agile – Easy to operate, update, and consume. The service model of Citrix ADM Service is available over the cloud, making it easy to operate, update, and use the features provided by Citrix ADM Service. The frequency of updates, combined with the automated update feature, quickly enhances user Citrix ADC deployment.

• Faster time to value – Quicker business goals achievement. Unlike with the traditional on-premises deployment, users can use their Citrix ADM Service with a few clicks. Users not only save the installation and configuration time, but also avoid wasting time and resources on potential errors.

• Multi-Site Management – Single Pane of Glass for instances across Multi-Site data centers. With the Citrix ADM Service, users can manage and monitor Citrix ADCs that are in various types of deployments. Users have one-stop management for Citrix ADCs deployed on-premises and in the cloud.

• Operational Efficiency – Optimized and automated way to achieve higher operational productivity. With the Citrix ADM Service, user operational costs are reduced by saving user time, money, and resources on maintaining and upgrading the traditional hardware deployments.

How Citrix ADM Service Works

Citrix ADM Service is available as a service on the Citrix Cloud. After users sign up for Citrix Cloud and start using the service, install agents in the user network environment or initiate the built-in agent in the instances. Then, add the instances users want to manage to the service.

An agent enables communication between the Citrix ADM Service and the managed instances in the user data center. The agent collects data from the managed instances in the user network and sends it to the Citrix ADM Service.

When users add an instance to the Citrix ADM Service, it implicitly adds itself as a trap destination and collects an inventory of the instance.

The service collects instance details such as:

• Host name

• Software version

• Running and saved configuration

• Certificates

• Entities configured on the instance, and so on.

Citrix ADM Service periodically polls managed instances to collect information.

The following image illustrates the communication between the service, the agents, and the instances:

Documentation Guide

The Citrix ADM Service documentation includes information about how to get started with the service, a list of features supported on the service, and configuration specific to this service solution.

Deploying Citrix ADC VPX Instances on AWS using Citrix ADM

When customers move their applications to the cloud, the components that are part of their application increase, become more distributed, and need to be dynamically managed.

With Citrix ADC VPX instances on AWS, users can seamlessly extend their L4-L7 network stack to AWS. With Citrix ADC VPX, AWS becomes a natural extension of their on-premises IT infrastructure. Customers can use Citrix ADC VPX on AWS to combine the elasticity and flexibility of the cloud, with the same optimization, security, and control features that support the most demanding websites and applications in the world.

With Citrix Application Delivery Management (ADM) monitoring their Citrix ADC instances, users gain visibility into the health, performance, and security of their applications. They can automate the setup, deployment, and management of their application delivery infrastructure across hybrid multi-cloud environments.

Architecture Diagram

The following image provides an overview of how Citrix ADM connects with AWS to provision Citrix ADC VPX instances in AWS.

Configuration Tasks

Perform the following tasks on AWS before provisioning Citrix ADC VPX instances in Citrix ADM:

• Create subnets

• Create security groups

• Create an IAM role and define a policy

Perform the following tasks on Citrix ADM to provision the instances on AWS:

• Create site

• Provision Citrix ADC VPX instance on AWS

To Create Subnets

Create three subnets in a VPC. The three subnets that are required to provision Citrix ADC VPX instances in a VPC - are management, client, and server. Specify an IPv4 CIDR block from the range that is defined in the VPC for each of the subnets. Specify the availability zone in which the subnet is to reside. Create all the three subnets in the same availability zone. The following image illustrates the three subnets created in the customer region and their connectivity to the client system.

For more information on VPC and subnets, see VPCs and Subnets.

To Create Security Groups

Create a security group to control inbound and outbound traffic in the Citrix ADC VPX instance. A security group acts as a virtual firewall for a user instance. Create security groups at the instance level, and not at the subnet level. It is possible to assign each instance in a subnet in the user VPC to a different set of security groups. Add rules for each security group to control the inbound traffic that is passing through the client subnet to instances. Users can also add a separate set of rules that control the outbound traffic that passes through the server subnet to the application servers. Although users can use the default security group for their instances, they might want to create their own groups. Create three security groups - one for each subnet. Create rules for both incoming and outgoing traffic that users want to control. Users can add as many rules as they want.

For more information on security groups, see: Security Groups for your VPC.

To Create an IAM Role and Define a Policy

Create an IAM role so that customers can establish a trust relationship between their users and the Citrix trusted AWS account and create a policy with Citrix permissions.

1. In AWS, click Services. In the left side navigation pane, select IAM > Roles, and click Create role.

2. Users are connecting their AWS account with the AWS account in Citrix ADM. So, select Another AWS account to allow Citrix ADM to perform actions in the AWS account.

Type in the 12-digit Citrix ADM AWS account ID. The Citrix ID is 835822366011. Users can also find the Citrix ID in Citrix ADM when they create the cloud access profile.

1. Enable Require external ID to connect to a third-party account. Users can increase the security of their roles by requiring an optional external identifier. Type an ID that can be a combination of any characters.

2. Click Permissions.

3. In Attach permissions policies page, click Create policy.

4. Users can create and edit a policy in the visual editor or by using JSON.

The list of permissions from Citrix is provided in the following box:

{
"Version": "2012-10-17",
"Statement":
[
    {
         "Effect": "Allow",
        "Action": [
            "ec2:DescribeInstances",
            "ec2:DescribeImageAttribute",
            "ec2:DescribeInstanceAttribute",
            "ec2:DescribeRegions",
            "ec2:DescribeDhcpOptions",
            "ec2:DescribeSecurityGroups",
            "ec2:DescribeHosts",
            "ec2:DescribeImages",
            "ec2:DescribeVpcs",
            "ec2:DescribeSubnets",
            "ec2:DescribeNetworkInterfaces",
            "ec2:DescribeAvailabilityZones",
            "ec2:DescribeNetworkInterfaceAttribute",
            "ec2:DescribeInstanceStatus",
            "ec2:DescribeAddresses",
            "ec2:DescribeKeyPairs",
            "ec2:DescribeTags",
            "ec2:DescribeVolumeStatus",
            "ec2:DescribeVolumes",
            "ec2:DescribeVolumeAttribute",
            "ec2:CreateTags",
            "ec2:DeleteTags",
            "ec2:CreateKeyPair",
            "ec2:DeleteKeyPair",
            "ec2:ResetInstanceAttribute",
            "ec2:RunScheduledInstances",
            "ec2:ReportInstanceStatus",
            "ec2:StartInstances",
            "ec2:RunInstances",
            "ec2:StopInstances",
            "ec2:UnmonitorInstances",
            "ec2:MonitorInstances",
            "ec2:RebootInstances",
            "ec2:TerminateInstances",
            "ec2:ModifyInstanceAttribute",
            "ec2:AssignPrivateIpAddresses",
            "ec2:UnassignPrivateIpAddresses",
            "ec2:CreateNetworkInterface",
            "ec2:AttachNetworkInterface",
            "ec2:DetachNetworkInterface",
            "ec2:DeleteNetworkInterface",
            "ec2:ResetNetworkInterfaceAttribute",
            "ec2:ModifyNetworkInterfaceAttribute",
            "ec2:AssociateAddress",
            "ec2:AllocateAddress",
            "ec2:ReleaseAddress",
            "ec2:DisassociateAddress",
            "ec2:GetConsoleOutput"
        ],
            "Resource": "*"
    }
]
}
<!--NeedCopy-->