AWS PrivateLink banner

AWS PrivateLink connecting systems in complex environments

Overview

CMD Solutions design and implement connectivity for highly secure and complex client networks as part of CMD’s Cloud consulting project engagements, and as a Managed Services provider. Traditionally AWS Direct Connect and VPNs are used however, in November 2017 AWS announced AWS PrivateLink as a new way to provide private connectivity to AWS hosted services without the need for traditional network connections.

AWS PrivateLink uses a combination of DNS (Route53), ENI’s (Elastic Network Interfaces) and NLBs (Network Load Balancers) to provide a secure, highly available and cost efficient way to achieve one way connectivity to services in disconnected networks.

PrivateLink in plain English can be broken into two main components a Provider (Service), and one too many Consumers (Endpoints).

Provider (Service)

AWS VPC Endpoint Service (Provider) is the service being exposed to one too many consumers as a highly available TCP endpoint. E.G. An AutoScaling group of EC2 instances running a web service which is to be exposed privately to B2B consumers.

VPCE Endpoint Service Components

  • Network Load Balancer (backed by 1-n EC2 Instances or IP addresses)
  • Endpoint Service Permissions (list of accounts to share/provide access)

 

---
Description: "VPCE Endpoint Service (CMD Solutions)"
Parameters:
  NetworkLoadBalancerArn:
    Type: String
    Description: Network Load Balancer ARN to exposed VPCE Service
  AllowedPrincipals:
    Type: CommaDelimitedList
    Description: Account ID's to allow access to VPCE Service: "arn:aws:iam::12345678890:root", "arn:aws:iam::987654210:root" ]    
Resources:
  VPCESERVICE:
    Type: "AWS::EC2::VPCEndpointService"
    Properties:
      NetworkLoadBalancerArn:
        - !Ref NetworkLoadBalancerArn
      AcceptanceRequired: False
  VPCESERVICEPERM:
    Type: "AWS::EC2::VPCEndpointServicePermissions"
    Properties:
      AllowedPrincipals: !Ref AllowedPrincipals
      ServiceId: !Ref VPCESERVICE
Outputs:
  OUTPUTVPCESERVICEID:
      Description: VPC Endpoint Service Id
      Value: !Ref VPCESERVICE
      Export:
          Name: !Sub ${AWS::StackName}-VPCESERVICE-ID

Consumer (Endpoint)

AWS VPC Endpoint (Consumer) provides a logical endpoint within the consumer VPC / Subnet(s) to provide secure one way connectivity to a VPC Endpoint Service running in a different AWS Account/VPC without the need to establish Peering or VPNs.

VPCE Endpoint Service Components

  • Managed AWS Elastic Network Interfaces which can be addressed by a single DNS address
  • Security group(s) to control access to the Endpoint
  • VPC / Subnet Id(s) for the VPC Endpoint to be deployed into
---
Description: "VPCE Endpoint (CMD Solutions)"
Parameters:
  VPCEServiceName:
    Type: String
    Description: VPC Endpoint ServiceName: "com.amazonaws.vpce.<REGION>.vpce-svc-XXXXXXXXXXX"
  VpcId:
    Type: AWS::EC2::VPC::Id
    Description: VPC Id
  SubnetIds:
    Type: List<AWS::EC2::Subnet::Id>
    Description: VPC Endpoint Subnet Id(s)
  SecurityGroupIds:
    Type: List<AWS::EC2::SecurityGroup::Id>
    Description: VPC Endpoint Security Group Id(s)
Resources:
  VPCEENDPOINT:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcId: !Ref VpcId
      ServiceName: !Ref VPCEServiceName
      VpcEndpointType: "Interface"
      SubnetIds: !Ref SubnetIds
      SecurityGroupIds: !Ref SecurityGroupIds
Outputs:
  OUTPUTVPCEENDPOINTID:
      Description: VPC Endpoint Id
      Value: !Ref VPCEENDPOINT
      Export:
          Name: !Sub ${AWS::StackName}-ENDPOINT-ID

Use case examples

Use case 1: Shared infrastructure services

Often large AWS environments will implement one or many shared service accounts / VPCs to provide a shared service capability to a number of application accounts. The implementation of a shared service zone helps customers reduce cost and improve manageability by reducing the need to duplicate shared / core services such as forward proxies and antivirus management servers.

Customer Implementation

CMD Solutions have worked with leading Fintech solution provider to implement a secure managed platform to host its mobile banking and lending services. A central Rancher 2.0 environment was configured to allow the platform to be managed using centralised standardisation of the managed Kubernetes clusters. This has simplified the ongoing management of the platform for both the CMD and Sandstone teams.

The platform requires the complete network isolation of all customer accounts and networks. To achieve full isolation, the CMD Solutions team implemented a master Rancher 2.0 environment which had one way connectivity to the child nodes via AWS PrivateLink. The use of PrivateLink enabled Sandstone to scale the number of client environments managed by a single master Rancher cluster while maintaining full customer network isolation.

Use case 1: Shared infrastructure services diagram

Use case 2: Providing SaaS services privately

SaaS is a cost effective and efficient way to consume services provided by third parties without the cost and overhead of managing the underlying service. Typically SaaS services are exposed over the internet or require the setup of complex and costly VPN’s or Direct Connects.

The complexity of being able to provide simple and cost effective private connectivity has led to the majority of SaaS services being exposed to clients over the internet. In some use cases the exposure of the service to the internet may not be appropriate for the type of data and it may not provide the required level of security.

Customer Implementation

CMD Solutions created a managed Tableau BI environment for a leading Australian Health Insurer to access a hosted analytics environment as a service. The hosted BI environment allows nib to consume Tableau as a service without nib incurring the overhead of implementing and managing the environment.

The Tableau environment needed private connectivity from a CMD owned/managed AWS account to databases within the nib internal network to provide nib with the required BI functionality. AWS PrivateLink was used to provide secure one-way connectivity from AWS to the nib network without the need to expose additional networks and services across the public internet or use VPN’s and Direct Connects.

Use case 2: Providing SaaS services privately diagram

Use case 3:  Secure on way connectivity to on premise services

Often customers require connectivity from their AWS environment to applications and services hosted on premise i.e. web applications to backend internal API’s. Traditionally this was achieved via a AWS Direct Connect or VPN in every network requiring connectivity which is costly and complex to manage.

Customer Implementation

CMD Solutions built a managed secure health claim payment processing environment. The payment platform required private connectivity to health record data hosted in a Co-Lo datacentre. The connectivity to the health systems from AWS is via Direct Connect however due to overlapping networks and restriction of CIDR range size, the use of Direct Connect was not possible without complex NATing. To overcome the overlapping CIDR ranges a small non-overlapping transient VPC was created to provide a secure connection point for direct connect and AWS private link used to expose the on-premise service to the payment system in AWS.

Use case 3: Secure on way connectivity to on premise services diagram

Conclusion

AWS PrivateLink provides a solution to connecting systems in complex overlapping networks securely with ease.

To learn more about this new functionality visit AWS PrivateLink or contact CMD Solutions.

References

AWS PrivateLink
AWS VPC Endpoint CloudFormation
AWS VPC Endpoint Services CloudFormation
AWS VPC Endpoint Permissions CloudFormation
Enabling New SaaS Strategies with AWS PrivateLink

No Comments

Sorry, the comment form is closed at this time.