Enterprise Cloud Architectural Patterns

Part 1

4 min readOct 19, 2023

Enterprises transitioning to the cloud face several challenges due to their existing on-premise systems and the need to integrate with cloud-based systems. In this article, we will explore two architectural patterns that can help enterprises navigate and manage the complexities of the hybrid ecosystem. We use AWS technologies to illustrate the concepts, but these ideas can be applied to other major clouds.

1. Centralized Hybrid DNS Management

In this pattern, we explore a hybrid DNS solution that allows applications to resolve other applications hosted in AWS and on-prem and vice versa. We also enable centralized access to AWS services via private links and VPC interface endpoints and one with cross-region access.

To illustrate how different configurations can be supported, we list a few requirements for our setup.

Every AWS application can resolve other AWS applications.
On-prem EU and US can resolve AWS applications in the eu-west-2 and us-west-2, respectively.
AWS applications in eu-west-2 and us-west-2 can resolve addresses in onprem.eu.example.com and onprem.us.example.com, respectively.
On-prem EU and US can resolve private CloudWatch addresses in eu-west-2 and us-west-2, respectively.
AWS applications in us-west-2 and eu-west-2 can resolve private CloudWatch addresses in eu-west-2 and us-west-2, respectively.
Both on-prem EU and US can resolve the private S3 address in eu-west-2. Note, in this case, cross-region interface endpoint resolution.
AWS applications in us-west-2 and eu-west-2 can resolve the private S3 address in eu-west-2.

While there are multiple strategies, due to benefits such as more scalable and resilient, minimal forwarding hops, and lower cost, we choose the “share and associate” strategy, where resolver rules are centrally created and shared/associated with other VPCs and private hosted zones are also shared and associated with other VPCs for unified DNS view.

The diagram below shows the architecture that satisfies the requirements:

A few additional points to note:

Transit Gateway (TGW) peering between Shared Services VPCs and workload VPCs is not needed for DNS query resolution but for connectivity of the applications and interface endpoints.
Inbound and outbound Route53 Resolver endpoints are only used for resolutions between AWS and on-prem.
Private hosted zones (PHZs) and forwarding rules associations allow consistent DNS views for all VPCs.
With this model, no extra hops are needed to resolve internal or external addresses.

2. Centralized User Access

Another pattern is to provide a single portal where the workforce can access the AWS Console and existing business applications. We are leveraging AWS Single Sign-on (SSO) for this. A trust relationship between an on-prem identity provider and AWS SSO allows user federation. Business applications can also be added using SAML 2.0.

Users initially authenticate with the enterprise identity provider and see a list of profiles that are assigned applications and accounts/roles. After SSO auth is completed, a token is used to orchestrate the access to these profiles. If the user chooses console access, the AWS login is initiated with the token, and they are redirected to the sign-in URL that allows them to assume the role in the account chosen. On the other hand, if the user selects an application from the portal, a SAMLResponse is posted to the configured consumer URL with the attributes defined. The user is then redirected to the application with, for example, the JWT token to authorize access via the API Gateway.

The diagram below shows the architecture for these two paths.

Additional things to note:

Depending on where in the flow, the AWS SSO portal can act as the Service Provider(SP) or Identity Provider (IdP). When authenticating the user with the remote IdP, it acts as SP; while initiating the custom SAML application, it presents the SAMLResponse for the authenticated user to the consumer URL as IdP.
For console access, the AWS sign-in endpoint calls STS to assume the role with SAML assertion. This, in turn, uses an IAM identity provider with a trust relation for the role that will be assumed.
The SAMLResponse needs to be validated with the metadata provided in the SSO configuration for the custom application. The extracted user information will have the attributes defined and can be used to generate an authorization token.

Recap

We looked at two patterns that can help enterprises transition to the cloud in maintaining a hybrid environment. We hope you find this article helpful in your cloud journey.