ACI/Cloud Extension Usage Primer (AWS)-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 enabled services to connect from on-premises to the cloud site while each site has it’s own VRF within a tenant. Currently, the Shared Services provider needs to be on the onPremise side.  

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.

Please see:  Use-case scenarios on CCO

In this short blog, I’ll point out the details of how to configure Shared services between OnPrem and AWS Site using MSO.

As always, before we proceed let’s make sure we know the guidelines and limitations for shared services between OnPrem and AWS site.

Guidelines and Limitations

  1. Inter-Tenant shared services are not supported in the current release.
  2. Inter-VRF services are supported within the same Tenant only.
  3. For shared services across different VRFs, each on-premises site can have no more than one VRF stretched to one or more cloud sites.
  4. Multiple VRFs can be stretched between cloud sites only.
  5. When creating the shared services contract between the cloud EPG and on-premises EPG across different VRFs within same tenant, the Contract’s scope must be set to tenant.
  6. There is a one to one mapping of AWS Account to a Cloud ACI tenant. Hence, one MUST use only one AWS Account to deploy a Cloud ACI tenant.

Going back to our discussion…

I’ll keep this blog short and only point out the details to make the shared services / route leaking configuration work.   I’m not going to go through every detail of other configuration step by step because I show that in the previous ACI/AWS posts.

To start off with, let’s follow the advise from the previous post on Templates

  • Draw out a logical diagram
  • Make a list of  what objects to put in what template

The Logical diagram is shown below:

Figure 1

In the diagram above you will notice the following:

  • We stretch the Tenant across both OnPrem and AWS sites
  • each site has it’s own VRF
  • OnPrem Site has it’s own BD with default gateway of
  • AWS Site has defined in the AZ
  • OnPrem site has “epg-shared-svc”.
  • AWS Site has epg-web
  • OnPrem site has a VM with IP
  • AWS Site has an EC2 with IP of
  • AWS site has an IGW (Internet Gateway — external EPG in ACI talk)
  • AWS site has a contract between it’s epg (epg-web) to the IGW (Aws-extEPG1)
  • A contract “web-2-sharedSvc-contract” exists between AWS EPG “epg-web” and OnSite EPg “epg-shared-svc”


Let’s now make a list of what object goes in what Template:

If you think about it we will have to make 3 templates in our schema:

  • OnPrem+AWS template  — for shared objects going to both sites
  • AWS-Only template — for AWS site only
  • OnPrem-Only template — for OnPrem site Only

Now let’s list out what goes in each of these templates:

OnPrem+AWS Shared Template:

  • web-2-sharedSvc contract  — since this contract needs to be applied between the epgs and need to be on both sites
  • Contract Filter associated with the above contract

AWS-Only Template:

  • app1 — this App Profile belongs to AWS site only
  • epg-web — this epg goes on only the AWS site
  • aws-vrf1 — this VRF goes only on AWS site
  • AWS-ExtEPG-Contract and it’s associated filter
  • AWS-ExtEPG1 — this external EPG goes on AWS site only

OnPrem-Only Template:

  • app-sharedSvc – this App Profile belongs to onPerm site only
  • epg-shared-svc — this epg goes only on onPrem site
  • bd-sharedSvc – since this bd goes only on onPrem site
  • VRF onPrem-sharedSvc — this VRF goes only on onPrem site

If you follow the above list, and refer to the diagram you could easily build this tenant.  From the knowledge gained from the previous posts on how to configure, this should be a breeze.

The only thing thats new here is the route leaking configuration needed between the VRFs of the OnPrem site and AWS Site.

Route Leaking configuation:

If you are used to operating ACI you will probably already have guessed what needs to be done for route leaking between the VRFs.  

The only item that you need to know is that for this to work, when you attach the contract, the cloud EPG side needs to be the consumer.  The OnPrem site needs to be the provider.

Below are the steps to enable route Leaking:

  • Make the Contract (in the shared template) that needs to go between the epgs from the AWS site and the OnPrem site.  Ensure that the scope of the Contract is Tenant.
Figure 2
  • apply the contract between the AWS EPG and OnPrem EPG.  Make sure that the AWS side is the consumer and OnPrem epg is the provider
  • when defining the BD Default Gateway on the OnPrem site, make sure to have “Advertise Extenally” checked as shown below
Figure 3
Figure 4
  • On the site local for OnPrem-Only template, click on the EPG and make sure to put a IP from the BD subnet on the EPG.  Make sure that this IP is not the same as the BD default gateway IP.   In this case the BD default gateway is   So, we ware using on the EPG. 
  • Make sure that the following boxes are checked on the IP that you define:
    • Advertise Externally
    • Shared Between VRF’s
    • No Default SVI Gateway
Figure 5
Figure 6

That’s all !

Let’s quickly test this out in the lab setup

Test Results

ssh into the EC2 instance and try to ping the VM on the shared services side.  In our case the contract had filter as “unspecified” so ping should work.  “ping”

Figure 7


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.