Public cloud infrastructure-as-a-service (IaaS) providers, such as Amazon AWS, Microsoft Azure, Google GCP and Oracle OCI, allow organizations to use virtualized computing resources that are provisioned on-demand. Since Access Tiers can be deployed independent of the underlying network and managed via the Cloud Command Center, they can be integrated seamlessly into any IaaS environment.

Multiple VPCs - Isolated #

Since each IaaS account can have multiple Virtual Private Clouds (VPCs) and span multiple geographic regions, a common IaaS deployment model is to treat every VPC as an isolated network segment and deploy an Access Tier per VPC.

flowchart TB
    USERS["<img src='/img/icons/user.svg' width='16'/>Users"]
    subgraph VPCA [AWS Cloud &mdash; Applications VPC-A]
        direction TB
        ATA["<img src='/img/intro/cse-icon.svg' width='16'/>Access Tier<br/><span style='font-size:11px;color:#5F5E5A'>Public subnet</span>"]
        SA1["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet-1</span>"]
        SA2["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet-2</span>"]
    end
    subgraph VPCB [AWS Cloud &mdash; Applications VPC-B]
        direction TB
        ATB["<img src='/img/intro/cse-icon.svg' width='16'/>Access Tier<br/><span style='font-size:11px;color:#5F5E5A'>Public subnet</span>"]
        SB1["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet-1</span>"]
        SB2["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet-2</span>"]
    end
    USERS --> ATA
    USERS --> ATB
    ATA --> SA1
    ATA --> SA2
    ATB --> SB1
    ATB --> SB2

    style VPCA fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    style VPCB fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    classDef user fill:#F2F2F2,stroke:#BDBDBD,color:#1F2933;
    classDef cse fill:#E7F1FC,stroke:#0087F7,color:#1F2933;
    classDef resource fill:#EEF6E7,stroke:#89C765,color:#1F2933;
    class USERS user;
    class ATA,ATB cse;
    class SA1,SA2,SB1,SB2 resource;

In an Isolated VPCs deployment, we typically have:

1. 1 Access Tier per VPC; each Access Tier is assigned a unique descriptive wildcard site domain name (such as *.myapp.corp.example.com) that is used in the fully qualified domain name (FQDN) for services in that VPC. You can create specific DNS entries for services that cannot follow this FQDN convention.
2. Individual application teams or department groups are responsible for managing their Access Tiers and services. Administrative access and Policy/Role/Service management can be controlled and audited via Admin Profiles and Audit Logs API.

A key security benefit of Isolated VPCs deployments is that we can eliminate almost all East-West lateral movement. Even if an attacker were to establish a foothold inside a VPC, they could not move laterally into another VPC.

Multiple VPCs - Designated Ingress #

Another common IaaS deployment model is to designated a single VPC as an Ingress VPC and use VPC Peering to direct Internet traffic to other internal Application VPCs.

flowchart TB
    USERS["<img src='/img/icons/user.svg' width='16'/>Users"]
    subgraph ING [Ingress VPC]
        AT["<img src='/img/intro/cse-icon.svg' width='16'/>Access Tier<br/><span style='font-size:11px;color:#5F5E5A'>Public subnet</span>"]
    end
    subgraph VA [Applications VPC A]
        APPA["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet</span>"]
    end
    subgraph VB [Applications VPC B]
        APPB["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet</span>"]
    end
    subgraph VC [Applications VPC C]
        APPC["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet</span>"]
    end
    USERS --> AT
    AT --> APPA
    ING -. VPC Peering .-> VB
    ING -. VPC Peering .-> VC

    linkStyle 2,3 stroke:#5B54A4,stroke-width:2.5px;
    style ING fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    style VA fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    style VB fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    style VC fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    classDef user fill:#F2F2F2,stroke:#BDBDBD,color:#1F2933;
    classDef cse fill:#E7F1FC,stroke:#0087F7,color:#1F2933;
    classDef resource fill:#EEF6E7,stroke:#89C765,color:#1F2933;
    class USERS user;
    class AT cse;
    class APPA,APPB,APPC resource;

In a Designated Ingress VPC deployment, we typically have:

1. 1 Access Tier for the entire organizations; all service domain names map to this Access Tier.
2. A central IT team manages and controls the Access Tier, and is responsible for all services published.

Because the Ingress VPC is peered to all internal Application VPCs, it needs to be thoroughly secured.

Transit Gateway - Multi-Region & Hybrid Cloud #

In more complex IaaS deployments that involve multi-region or multi-account connectivity, organizations may choose to use a dedicated network router - such as AWS Transit Gateway - to enable peering and routing between different VPCs.

flowchart TB
    DNS["<img src='/img/icons/globe.svg' width='16'/>Public DNS<br/><span style='font-size:11px;color:#5F5E5A'>Geolocation &amp; Latency Routing</span>"]
    USW["<img src='/img/icons/user.svg' width='16'/>Users in US-West"]
    USE["<img src='/img/icons/user.svg' width='16'/>Users in US-East"]
    subgraph AWSW [AWS US-West]
        direction TB
        ATW["<img src='/img/intro/cse-icon.svg' width='16'/>Access Tier<br/><span style='font-size:11px;color:#5F5E5A'>Ingress VPC &middot; Public subnet</span>"]
        TGWW["Transit Gateway<br/>US-West"]
        ATW --> TGWW
    end
    subgraph AWSE [AWS US-East]
        direction TB
        ATE["<img src='/img/intro/cse-icon.svg' width='16'/>Access Tier<br/><span style='font-size:11px;color:#5F5E5A'>Ingress VPC &middot; Public subnet</span>"]
        TGWE["Transit Gateway<br/>US-East"]
        ATE --> TGWE
    end
    APPW["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Applications VPC US-West &middot; Private subnet</span>"]
    USW -. DNS lookup .-> DNS
    USE -. DNS lookup .-> DNS
    USW --> ATW
    USE --> ATE
    TGWW --> APPW
    TGWE -. Transit Gateway Peering .-> APPW

    linkStyle 7 stroke:#5B54A4,stroke-width:2.5px;
    style AWSW fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    style AWSE fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    classDef user fill:#F2F2F2,stroke:#BDBDBD,color:#1F2933;
    classDef cse fill:#E7F1FC,stroke:#0087F7,color:#1F2933;
    classDef resource fill:#EEF6E7,stroke:#89C765,color:#1F2933;
    classDef tgw fill:#ECEBF4,stroke:#5B54A4,color:#1F2933;
    class DNS,USW,USE user;
    class ATW,ATE cse;
    class APPW resource;
    class TGWW,TGWE tgw;

In IaaS deployments that involve hybrid cloud connectivity, organization also use network routers - such Cisco ASA and/or AWS Transit Gateway - to connect datacenters and IaaS VPCs.

flowchart TB
    USERS["<img src='/img/icons/user.svg' width='16'/>Users"]
    subgraph ING [Ingress VPC]
        AT["<img src='/img/intro/cse-icon.svg' width='16'/>Access Tier<br/><span style='font-size:11px;color:#5F5E5A'>Public subnet</span>"]
    end
    TGW["Transit Gateway"]
    subgraph VA [Applications VPC A]
        APPA["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet</span>"]
    end
    subgraph VB [Applications VPC B]
        APPB["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet</span>"]
    end
    subgraph VC [Applications VPC C]
        APPC["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet</span>"]
    end
    subgraph DC [Corporate Datacenter]
        DCAPP["<img src='/img/icons/server.svg' width='16'/>Application<br/><span style='font-size:11px;color:#5F5E5A'>Private subnet</span>"]
    end
    USERS --> AT
    AT --> TGW
    TGW --> APPA
    TGW -. VPC Peering .-> VB
    TGW -. VPC Peering .-> VC
    TGW -. Datacenter Gateway .-> DCAPP

    linkStyle 3,4,5 stroke:#5B54A4,stroke-width:2.5px;
    style ING fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    style VA fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    style VB fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    style VC fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    style DC fill:transparent,stroke:#BDBDBD,stroke-width:1.5px,stroke-dasharray:5 4;
    classDef user fill:#F2F2F2,stroke:#BDBDBD,color:#1F2933;
    classDef cse fill:#E7F1FC,stroke:#0087F7,color:#1F2933;
    classDef resource fill:#EEF6E7,stroke:#89C765,color:#1F2933;
    classDef tgw fill:#ECEBF4,stroke:#5B54A4,color:#1F2933;
    class USERS user;
    class AT cse;
    class APPA,APPB,APPC,DCAPP resource;
    class TGW tgw;

Access Tiers can be integrated seamlessly into these types of complex network topologies as well, because they run independent of the underlying network.