Cisco Cloud ACI On AWS: White Paper
Cisco Cloud ACI On AWS: White Paper
Cisco Cloud ACI On AWS: White Paper
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 28
Contents
Cisco Cloud Application Centric Infrastructure (Cisco Cloud ACI) overview .................................................... 3
Challenges in hybrid cloud environments............................................................................................................. 4
High-level architecture of Cisco Cloud ACI on AWS ............................................................................................ 5
Cisco ACI Multi-Site Orchestrator (MSO) .............................................................................................................. 6
Cisco Cloud APIC on AWS ................................................................................................................................... 6
Key benefits of using Cisco Cloud ACI.................................................................................................................. 7
Automation of on-premises to cloud interconnect ................................................................................................. 7
Universal policy model .......................................................................................................................................... 7
Unified network management and operations ..................................................................................................... 10
Consumption of cloud-native services ................................................................................................................ 10
Digging further: looking inside an ACI cloud site ............................................................................................... 10
Hub-and-spoke topology with an infra VPC ........................................................................................................ 10
An ACI cloud site across multiple AWS regions .................................................................................................. 11
Traffic flows inside the cloud site ........................................................................................................................ 12
Intersite connectivity ............................................................................................................................................. 13
The underlay network between on-premises and cloud sites ............................................................................. 13
The overlay network between on-premises and cloud sites ................................................................................ 13
Use-case scenarios ............................................................................................................................................... 14
High Availability of applications across on-premises and cloud sites .................................................................. 14
Cloud bursting: stretch an application tier (EPG) to cloud with consistent segmentation .................................... 15
Shared services across hybrid cloud .................................................................................................................. 17
External connectivity to the internet via the cloud or on-premises ...................................................................... 18
Cloud-native and on-premises services .............................................................................................................. 20
How to deploy the solution ................................................................................................................................... 21
Deploying Cisco Cloud APIC and the Infra VPC ................................................................................................. 21
Cisco Cloud APIC’s First Time Setup wizard ...................................................................................................... 23
Registering a Cisco ACI cloud site in MSO ......................................................................................................... 24
Deploying a multi-tier application in a hybrid scenario ........................................................................................ 26
Summary ................................................................................................................................................................ 28
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 28
Cisco Cloud Application Centric Infrastructure (Cisco Cloud ACI) overview
In today’s world, enterprises are undergoing increasing pressure to innovate rapidly, to keep up with competition
and to increase IT agility to meet customer demands. To achieve these goals, businesses are choosing different
infrastructure environments for deploying different types of applications. Some applications may be best suited to
be hosted on-premises, whereas other applications may be best suited to be hosted in a public cloud, and yet
others may benefit from hybrid deployments. In fact, hybrid cloud is becoming the new normal for many
businesses.
However, in a hybrid cloud environment it is becoming more and more challenging to maintain a homogeneous
enterprise operational model, comply with corporate security policies, and gain visibility across hybrid
environments. Cisco Cloud Application Centric Infrastructure (Cisco Cloud ACI) is a comprehensive solution that
provides simplified operations, consistent policy management and visibility across multiple on-premises data
centers and public clouds or hybrid cloud environments. Cisco Cloud ACI allows customers running Cisco ACI™ in
their on-premises data centers to extend their Cisco ACI policies to public clouds.
In an on-premises Cisco ACI datacenter, Cisco Application Policy Infrastructure Controller (APIC) is the single
point of policy configuration and management for all the Cisco ACI switches deployed in the data center. When
there is a need to seamlessly interconnect multiple Cisco ACI–powered data centers and selectively extend Cisco
ACI constructs and policies across sites, Cisco ACI Multi-Site Orchestrator (MSO) enters the scene. MSO is a
software solution that represents a single point of policy orchestration and visibility across multiple geographically
dispersed ACI sites.
With the new Cisco Cloud ACI capabilities delivered in Cisco ACI Release 4.1, MSO can manage policies across
multiple on-premises Cisco ACI data centers as well as public clouds. The policies configured from MSO can be
pushed to different on-premises Cisco ACI sites and cloud sites. Cisco APIC controllers running on premises
receive this policy from MSO, then render and enforce it locally. When extending Cisco ACI to the public cloud, a
similar model applies. But there is a twist. Public cloud vendors do not speak Cisco ACI natively. Things such as
endpoint groups (EPGs) or contracts are not familiar concepts there. MSO policies therefore need to be translated
into cloud-native policy constructs. For example, contracts between Cisco ACI EPGs need to be translated into
security groups on AWS first, then applied to AWS cloud instances. This policy translation and programming of the
cloud environment is performed using a new component of the Cisco Cloud ACI solution called Cisco Cloud
Application Policy Infrastructure Controller (Cisco Cloud APIC or Cloud APIC).
Cisco Cloud APIC runs natively on supported public clouds1 to provide automated connectivity, policy translation
and enhanced visibility of workloads in the public cloud. Cisco Cloud APIC translates all the policies received from
MSO and programs them into cloud-native constructs such as VPCs (virtual private cloud), security groups,
security group rules, etc.
This new solution brings a suite of capabilities to extend your on-premises data center into true hybrid cloud
architectures, helping drive policy and operational consistency regardless of where your applications reside. It
provides a single point of policy orchestration across hybrid environments, operational consistency, and visibility
across clouds.
1
See the data sheet and release notes for public cloud environment support information.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 28
Figure 1. High-level architecture of Cisco Cloud ACI
Figure 1 shows the overall high-level architecture of Cisco Cloud ACI with Cisco ACI Multi-Site Orchestrator acting
as a central policy controller, managing policies across multiple on-premises Cisco ACI data centers as well as
hybrid environments, with each cloud site being abstracted by its own Cloud APICs. The rest of this white paper
discusses the architecture, benefits, use cases, and deployment of Cisco Cloud ACI on AWS.
The main challenges in building and operating a hybrid cloud environment are:
1. Automating the creation of secure interconnects between on-premises and public clouds
2. Dealing with the diverse and disjoint capabilities across on-premises private cloud and public cloud
3. Multiple panes of glass to manage, monitor, and operate hybrid cloud instances
4. Inconsistent security segmentation capabilities between on-premises and public clouds
5. Facing the learning curve associated with operating public cloud environment
6. Inability to leverage a consistent L4–L7 services integration in hybrid cloud deployments
Cisco ACI has delivered on the Software-Defined Networking (SDN) promise of intent-based network configuration
and automation and further simplified operations by delivering control and visibility based on network policies that
closely mimic your applications. The next phase of Cisco ACI must now address extending this policy-driven
automation to hybrid environments. The Cisco Cloud ACI solution offers a coherent hybrid cloud strategy delivering
on the key pillars of automation, security, and simplicity.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 28
High-level architecture of Cisco Cloud ACI on AWS
As briefly explained above and further depicted in Figure 2, an instance of MSO orchestrates multiple independent
sites using a consistent policy model and provides a single pane of glass for centralized management and visibility.
The sites can be on-premises Cisco ACI fabric sites with their own site-local APIC clusters, or cloud sites in AWS
with Cloud APIC to manage the cloud site. Just as with a normal Cisco ACI multi-site architecture, all the sites are
interconnected via a “plain” IP network. No need for IP multicast or Dynamic Host Configuration Protocol (DHCP)
relay here. Just take care of providing IP connectivity, and MSO will be responsible for setting up the intersite
overlay connectivity.
For more details on the Cisco ACI multi-site solution, refer to the following white paper:
https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-
paper-c11-739609.pdf
The key building blocks of the Cisco Cloud ACI architecture include the following: an on-premises Cisco ACI site
running Cisco ACI Release 4.1 software and equipped with at least one second-generation spine model (EX or
FX), Cisco ACI Multi-Site Orchestrator (MSO), Cisco Cloud APIC, intersite connectivity between the on-premises
and cloud sites, and network policy mapping between the Cisco ACI on-premises and cloud sites.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 28
Cisco ACI Multi-Site Orchestrator (MSO)
In a Cisco ACI multi-site architecture, the Cisco ACI Multi-Site Orchestrator (MSO) is the single pane of glass for
management of all the interconnected sites. It is a centralized place to define all the inter-site policies that can then
be published to the individual Cisco ACI sites where the site-local APICs render them on the physical switches that
build those fabrics.
With the Cisco Cloud ACI, MSO’s orchestration functions expand to the cloud sites. It is responsible for site
registration of both on-premises Cisco ACI data center sites and the cloud sites. It automates the creation of
overlay connectivity between all the sites (on-premises and cloud). Continuing to be the central orchestrator of
intersite policies, MSO now can not only publish policies to on-premises Cisco ACI data center sites, but also push
the same policies to cloud site in AWS. It is also capable of instrumenting the policy deployment among different
sites by selectively distributing the policies to only the relevant sites. For instance, MSO can deploy the web front
tier of an application into the cloud site in AWS while keeping its compute and database tiers in the on-premises
site. Through the MSO interface, network administrators can also regulate the communication flow between the on-
premises site and AWS as required by applications.
Cisco Cloud APIC is a microservices-based software deployment of APIC controller. Cisco Cloud APIC on AWS is
deployed and runs as an Amazon Elastic Compute Cloud (Amazon EC2) instance using persistent block storage
volumes in Amazon Elastic Block Store (Amazon EBS). The Amazon Machine for Cisco Cloud APIC are available
at AWS marketplace, and use Bring Your Own License (BYOL) model for licensing.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 28
As ACI APIC for an on-premises ACI fabric, ACI Cloud APIC contains only policies and is not in the data
forwarding path. Any downtime of the Cloud APIC will not impact network forwarding functionality or performance
in the cloud site. The Amazon EC2 instance of the Cloud APIC takes advantage of Amazon EBS built-in storage
volume redundancy, high availability and durability. Upon a failure in the Amazon EC2 instance, it can always
relaunch or restore to the previous state by rebuilding configuration and states from persistent storage and provide
seamless Cloud APIC functionalities. Therefore, for simplicity and cost effectiveness, Cloud APIC is deployed as a
single Amazon EC2 instance in the initial release of Cisco Cloud ACI on AWS. In the future, clustering of multiple
virtual instances will be introduced for Cloud APIC to achieve higher scalability and instance level redundancy.
2
You are responsible for providing that device. At FCS, only the Cisco CSR 1000V is qualified.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 28
Figure 4. AWS SG-based network model
*This figure is quoted from the AWS white paper “Web Application Hosting in the AWS Cloud”.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 28
Granular and accurate mapping between these two network policy models is crucial to ensure the correct
deployment of network policies across Cisco ACI and AWS. Figure 5 shows how Cloud APIC handles this policy
mapping.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 28
Unified network management and operations
Cisco ACI Multi-Site Orchestrator (MSO) provides end-to-end visibility and health of all the endpoints managed by
it across on-premises and public cloud environments, giving a single place to monitor the health, performance, and
operational status of hybrid cloud environments. MSO being the single point of policy configuration and
orchestration, this highly reduces the operational complexity of operating across hybrid environments.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 28
The infra VPC carries the logical role of the on-premises Cisco ACI infra VRF. It is where Cloud APIC is deployed
and running. It is automatically created during the deployment of Cloud APIC. Cloud APIC then deploys a pair of
Cisco CSR 1000V Series routers in this infra VPC as cloud routers responsible for providing the virtual underlay
connectivity, including the internal connectivity within the cloud site and the intersite connectivity to the on-premises
Cisco ACI sites.
A user VPC is equivalent to a tenant VRF in the Cisco ACI network policy model. Cloud APIC creates a user VPC
when an ACI tenant VRF needs to be deployed or extended to the cloud site. Within the user VPC, Cloud APIC
provisions an AWS Virtual Private Gateway (VGW) or Cisco CSR1000V Series router3 to connect to the infra VPC
to ensure proper end-to-end connectivity.
IPsec tunnels are automatically provisioned and established between the infra VPC Cisco CSR 1000V Series
routers and the user VPC routers (either an AWS VGW or Cisco CSR 1000V Series router so that the infra VPC
can function as a transit VPC4 to allow route exchanges between user VPCs through the overlay IPsec tunnels.
3
In the first release of this solution, AWS VGW is the only supported option as the cloud router in user VPCs. The support of
Cisco CSR 1000V Series routers will be added in future releases.
4
In the first release of this solution, AWS Transit Gateway (https://aws.amazon.com/transit-gateway/) is not yet supported.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 28
Figure 7. Cisco Cloud ACI AWS multi-region site
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 28
Intersite connectivity
The underlay network between on-premises and cloud sites
The on-premises Cisco ACI sites and the ACI cloud site in AWS are connected through an IP network that can be
IPsec VPN over the Internet, or through AWS Direct Connect5. In case of IPsec VPN, the Cloud Cisco CSR 1000V
Series routers in the Infra VPC need to be programmed to establish IPsec peering with the IPsec device located on
premises (at the physical Cisco ACI site). This underlay network provides IP reachability for the overlay control
plane and data plane between the two sites. This is represented in Figure 8:
BGP EVPN sessions are established between the on-premises Cisco ACI spine switches and the Cisco CSR
1000V Series cloud routers in the Infra VPC of the cloud site. Tenant host routes and prefix routes are exchanged
between the two sites as BGP EVPN route type-2 (host) and type-5 (prefix). The provisioning of this overlay
network connectivity is automated by MSO.
5
The initial release of this solution does not support AWS Direct Connect. It will be added in a future release.
6
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/2-
x/L3_config/b_Cisco_APIC_Layer_3_Configuration_Guide/b_Cisco_APIC_Layer_3_Configuration_Guide_chapter_010010.html
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 28
Figure 9 zooms in on this logical/physical architecture. On-premises spines connect to an intersite network (called
ISN or IPN for inter-pod network). That IPN layer then connects to an on-premises IPsec router that initiates IPsec
tunnels to the Cisco CSR 1000V Series routers in the AWS Infra VPC. MP-BGP EVPN sessions are established
between the ACI spine switches and the Cisco CSR 1000V series routers in the AWS Infra VPC over the IPN
network and the IPsec tunnels.
Use-case scenarios
Cisco Cloud ACI enables customers to achieve the following scenarios:
Customers having application tiers deployed on an on-premises Cisco ACI site can now add new application tiers
in an cloud site interacting with the on-premises tiers using consistent policies.
Applications can fail over between the on-premises Cisco ACI site and the ACI cloud site during a disaster
recovery, or the application can be deployed in an active/active mode, where both on-premises application tiers
and cloud tiers are active. A Global Load Balancer can be configured to distribute traffic between the two sites.
For example, the web and application tiers of an application (two EPGs) in the same VRF running in the on-
premises Cisco ACI data center. By stretching the same VRF to the cloud site, we can deploy web and application
tiers in the cloud site, and can be configured as an active/active between the on-premises and cloud sites. You can
also deploy the on-premises web and application tiers as active, and the cloud tiers can act as standby, and can
fail over to a cloud tier in case of a disaster recovery.
7
Note: Extending a broadcast domain between an on-premises site and the cloud is not possible. Cloud vendors typically do not
run broadcast or multicast and never face unknown unicast situations.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 28
All of this can be achieved by using MSO as a single point of orchestration; you can configure contracts between
these tiers spread across the hybrid cloud environment. Simply publishing this policy from MSO to both sites
programs the end-to-end constructs required to implement the workload segmentation policy. This is shown in
Figure 10.
Figure 10. An example of stretched application between on-premises Cisco ACI and cloud sites
Cloud bursting: stretch an application tier (EPG) to cloud with consistent segmentation
Cisco Cloud ACI enables customers to stretch an application tier across the on-premises and cloud sites in AWS,
which means that an ACI EPG can be stretched across the on-premises and AWS sites. This enables customers to
burst a tier to AWS Cloud during times of peak load and access other tiers of the application on premises via
secure segmentation policies. Even multiple tiers can be burst to the cloud site in AWS and still maintain the same
level of policy and consistent segmentation irrespective of where the workloads are deployed.
From MSO, you can either create a new EPG that can then be stretched or import an existing EPG from the on-
premises site and stretch it to AWS. This is achieved just as you would with regular Cisco ACI Multi-Site, using
templates and schemas. Once that is done, configure the site-local properties that define how the EPG should
classify its member endpoints.
When associating an EPG with an on-premises ACI site, you can either associate the EPG to a Virtual Machine
Manager (VMM) domain, or to static ports or a VLAN/port combination to classify endpoints on premises. When the
same EPG is associated with an cloud site in AWS through MSO, EPG membership classification criteria can then
be based on AWS tags, or AWS IP subnets or IP addresses, or AWS regions.
Stretching an EPG does not mean extending a broadcast domain from an on-premises site to the cloud, though; it
simply means that you can create an EPG with members on premises and in the cloud, using different subnets.
Once two or more endpoints are in the same EPG, communication flows freely inside that EPG.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 28
Example: Let’s say you have an application with web and application tiers deployed in an on-premises ACI site.
During a peak load time, you burst either web tier or both web and application tiers to the cloud site in AWS. You
can do that seamlessly with just a couple of button clicks from Cisco ACI MSO, and stretch the tiers to AWS with
the same level of security and segmentation as their on-premises workloads. Now, contracts between stretched
Web EPG and on-premises EPGs or Cloud EPGs can be configured as you normally would with an on-premises
ACI. Cloud-bursting doesn’t get any easier. This is shown in Figures 11.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 28
Shared services across hybrid cloud
Shared services such as DNS, Active Directory (AD), or other authentication services deployed in a tenant in an
on-premises ACI site can be securely consumed by endpoints in other tenants spread across other Cisco ACI and
AWS sites. This enables services from a single on-premises provider tenant to be consumed by multiple consumer
tenants spread across the on-premises ACI site and cloud sites in AWS.*
This makes it easier to deploy new applications in the cloud, and consume shared services from the brownfield
network on premises, without having to redeploy them for applications hosted in the cloud.
*
Provider Tenant of services shared in the cloud, and consumer Tenants on premises will be supported in future releases.
Example: Let’s say there are DNS servers deployed in Tenant-1, an on-premises ACI site. Workloads that are
part of the Web-EPG deployed on the cloud site in AWS in Tenant-2 can access these DNS shared services from
the on-premises ACI site via an Inter-VRF contract between the DNS-EPG and the Web-EPG. This is shown in
Figure 12.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 28
External connectivity to the internet via the cloud or on-premises
External connectivity to the Internet for workloads in AWS Cloud can be configured in two ways:
1. Cloud L3Out: A cloud-local Internet connection (also called L3Out in Cisco ACI terminology) can be defined for
workloads deployed on AWS. It is achieved by configuring a cloud-External EPG in MSO for the cloud site in
AWS. A Cloud-External EPG will create an Internet Gateway (IGW) and attach it to every VPC in the AWS site
and appropriate routes will be programmed into the VPC route tables.
2. On-premises L3Out: Some customer environments require all the traffic from a VPC in AWS to transit to an
on-premises site and be inspected through an on-premises firewall/IDS/IPS before the traffic exits to, or enters
from, the Internet. This can also be achieved by defining an on-premises L3Out as the Internet exit for traffic
and associating the cloud endpoints to that EPG via a contract.
Customers have full control over external network connectivity options for workloads deployed in the cloud and can
choose to redirect the traffic for inspection by various services deployed on premises by using Cisco ACI service
graphs. All this can be done through a single policy, and end-to-end connectivity can be automated and
orchestrated by Cisco ACI Multi-Site Orchestrator, greatly simplifying the operational workflows.
Example: When an administrator configures a cloud-local L3Out in the AWS environment (as shown in Figure 13),
each AWS VPC will have an AWS internet gateway (IGW) attached to it, and the Amazon EC2 instances in the
VPC can directly communicate with the Internet based on the policies defined.
If the administrator defines an on-premises Cisco ACI L3Out (as shown in Figure 14) and forces cloud instances to
use that L3Out, then all traffic from Amazon EC2 instances reaches the Cisco CSR 1000V Series router via the
VPN tunnels, and will be sent on premises over the VXLAN tunnel running over the IPsec tunnel. Traffic can then
exit via the on-premises Cisco ACI L3Out instead of using the AWS Internet gateway directly.
Once traffic reaches the on-premises Cisco ACI site, the administrator may choose to subject this traffic to various
inspections using the service chain options in Cisco ACI and then let the traffic exit to the Internet.8
8
Please verify the release notes of your chosen ACI software version and Cisco Cloud APIC version to ensure this feature is
available.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 28
Figure 13. An example of Cloud L3-out
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 28
Figure 14. An example of On-Premises L3-Out for cloud endpoints
1. AWS Application Load Balancer: Using service graph concepts similar to those for on-premises ACI, you can
seamlessly integrate cloud-native services such as AWS Application Load Balancer (ALB) with your
application stack. This can be fully configured from MSO, and the Cloud APIC will automate end-to-end
deployment and configuration of ALB in the VPC and associate it with endpoints in a given endpoint group.
2. On-premises services: For application tiers that are split across on-premises and AWS sites, you can
seamlessly insert on-premises services (such as load balancer or firewall). This can be achieved by
configuring ACI service graphs from MSO.
Example: Let’s say we need an east-west firewall between the database tier deployed on premises and a web tier
that is stretched across the hybrid cloud environment. As shown in Figure 15, this can be configured with much
ease using ACI Service graphs from MSO, and the traffic between the database and web tiers always passes
through this firewall irrespective of where the endpoints of the web tier are located across the hybrid cloud.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 28
Figure 15. On-premises service chaining for a stretched application tier
The first step to deploy Cisco Cloud ACI is to configure the Infra VPC and to launch Cisco Cloud APIC in AWS.
Those steps are all performed by using a Cisco-provided AWS CloudFormation template, which allows you to
create automation workflows called stacks that will execute a series of steps on your behalf.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 28
CloudFormation uses a JSON or YAML template to describe the automation workflows. Cisco provides a
CloudFormation template to execute the necessary steps to configure Cisco Cloud ACI integration. The
CloudFormation template is available in AWS marketplace and can be executed from there. Alternatively, it can be
downloaded from Cisco public website and used to initiate a CloudFormation stack as shown in Figure 16. This
stack will prompt the user for the required parameters defined in the template and will run the tasks defined
in the workflow.
Figure 16. Create CloudFormation stack to launch Cisco Cloud APIC on AWS
Once the CloudFormation template is deployed successfully, your Cisco Cloud APIC becomes accessible via its
Web UI and API. As shown in Figure 17, you can find the public IP address of Cisco Cloud APIC by viewing the
CloudFormation template outputs or by consulting the elastic IP address assigned to the Cloud APIC Amazon EC2
instance. Connect to the Cisco Cloud APIC UI to complete the installation through the getting-started wizard.
Figure 17. CloudFormation template output with Cisco Cloud APIC Public IP address
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 28
Cisco Cloud APIC’s First Time Setup wizard
The first time you connect to Cisco Cloud APIC UI, the First Time Setup wizard (shown in Figure 18) automatically
kicks off. This wizard helps you configure some of the Cisco Cloud APIC required settings, such as DNS, the TEP
pool, the regions to be managed, and IPsec connectivity options. At the end of the First Time Setup wizard, Cisco
Cloud APIC configures the AWS infrastructure needed to become fully operational, such as the pair of Cisco CSR
1000V Series routers. The provisioning of the AWS infrastructure is fully automated and carried out by Cisco Cloud
APIC. After this step, you will be able to start deploying your Cisco ACI policy on AWS.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 28
Registering a Cisco ACI cloud site in MSO
Each Cisco Cloud APIC represents a Cisco ACI site. To extend policy across sites, Cisco ACI uses the Cisco ACI
Multi-Site Orchestrator (MSO). As shown in Figure 19, when you register a Cisco Cloud APIC in MSO, it will
appear as a new site and will allow you to deploy existing or new schemas to AWS. MSO ensures that you specify
the required site-specific options, such as subnets and EPG membership classification criteria, which are different
for each site.
Cisco Cloud APIC lets you create networks on AWS using the Cisco ACI object model representation. In the
backend, Cisco Cloud APIC translates Cisco ACI objects into AWS-native constructs. This means that Cisco Cloud
ACI adheres to AWS networking specifications. As those differ slightly from what you might be used to with Cisco
ACI, they are detailed below.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 28
As shown in Figure 20, In AWS, a subnet is bound to an Availability Zone (AZ) of a VPC, which itself is bound to a
region.
This means that, between AZs, VPCs, or regions, the traffic is routed. There is no concept of extending L2 from
one VPC to another VPC or from the on-premises site to a VPC in AWS. To respect this design philosophy, Cisco
Cloud ACI extends on-premises networks using L3 only.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 28
Cisco Cloud APIC also provides a view of the AWS-native constructs used to represent the Cisco ACI policy. This
allows network administrators to slowly familiarize themselves with AWS networking constructs. Figure 21 below
demonstrates the native cloud resources view on the Cloud APIC UI. As an example, it shows the display of the
provisioned AWS VPCs in a cloud site.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 28
The schema can then be associated with the on-premises site and the Cisco Cloud ACI site. Once the association
is made, you then define the subnets to be used for the VRF on AWS. Cisco Cloud APIC model associates
subnets to VRF because, in AWS, VRFs are mapped to VPCs and subnets are mapped to an Availability Zone
(AZ) inside a VPC. This means that you need to define a separate subnet for the Web EPG that only exists in the
AWS cloud. You will also define the membership criteria for cloud instances to join the Web EPG. As shown in
Figure 23, once you are satisfied with the MSO schema and you have completed the required site-specific
configuration steps, you can deploy the configuration to both Cisco ACI sites using the MSO one-click deployment
button.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 28
Cisco Cloud ACI ensures that the AWS cloud and on-premises ACI are configured appropriately to allow
communication between the App EPG and the Web EPG residing on AWS, as shown in Figure 24.
Figure 24. Three-tier application deployed across on-premises and cloud sites in AWS
You can now deploy new Web instances on AWS to accommodate your needs.
Summary
The new Cisco Cloud ACI capabilities delivered in Cisco ACI Release 4.1 make it easy for network administrators
to quickly tailor the infrastructure to adapt to constantly evolving business requirements. The solution provides
ultimate IT agility by greatly facilitating the configuration and day-2 operation of hybrid cloud environments. Cisco
Cloud ACI lets you architect complex network topologies and security policies that encompass on-premises
locations and public cloud sites. Cross-site orchestration of network connectivity and workload segmentation
policies is achieved by Cisco ACI Multi-Site Orchestrator working in tandem with Cisco Cloud APIC and on-
premises APIC.
© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 28