AWS Database Blog

Accessing Amazon Managed Blockchain services from blockchain applications running in shared Amazon VPCs

Many AWS customers use AWS Organizations and shared virtual private clouds (VPCs) to reduce operational costs and optimize the use of shared resources. For example, shared VPCs allow you to segregate ownership between systems management and application development teams. For more information, see VPC sharing: A new approach to multiple accounts and VPC management.

Using a shared VPC architecture with a single Amazon Managed Blockchain network allows customers who own multiple AWS accounts to optimize their costs by limiting the number of membership fees and total number of peers used. In this post we will review the problem with connecting to Managed Blockchain resources from a shared VPC, then will look at a solution and walk through the steps to set it up.

Use case: Connecting to Managed Blockchain resources from a shared VPC

An AWS account managing shared VPCs with associated resources is called a VPC owner. VPC participants are the other AWS accounts accessing shared subnets provisioned for them by VPC owners. The challenge arises when VPC participants have to access Managed Blockchain from a shared VPC. Managed Blockchain uses interface VPC endpoints (powered by AWS PrivateLink) to allow client applications to access the Managed Blockchain network. When a VPC participant attempts to create a VPC endpoint for Managed Blockchain in a shared VPC, the endpoint creation fails with an error message (see the following screenshot).

Provisioning a Managed Blockchain network in a blockchain member AWS account (which owns the application) creates an AWS service endpoint for that specific account. Because VPC participants can’t create VPC endpoints in a shared VPC, this is expected behavior and is by design.

One way to overcome this challenge is to host the Managed Blockchain network within a VPC owner AWS account. However, this approach isn’t ideal for the following reasons:

  • The customer can’t achieve proper segregation between commonly used split of networking infrastructure and application AWS accounts
  • Because Managed Blockchain network charges are billed to the networking AWS account, it becomes more difficult to match costs against networking and application budgets.

Solution overview

To solve this problem, you can create a standalone VPC within an application account, establish connectivity with a Managed Blockchain interface VPC endpoint from a shared VPC via VPC peering or AWS Transit Gateway, and resolve domain names of Managed Blockchain services with the help of a private hosted zone in Amazon Route53.

This involves the following steps for the foundational networking setup:

  • A VPC participant in a shared VPC that is a member of the Managed Blockchain network (Account B on the following screenshot) creates a new standalone VPC with a subnet for each Availability Zone in which your application requires connectivity.
  • The same account adds an interface VPC endpoint for the Managed Blockchain service in the VPC/subnets created.
  • The shared VPC participant (Account B) and shared VPC owner (Account A) connect standalone and shared VPCs directly with VPC peering or AWS Transit Gateway, in case you are using an AWS Transit Gateway-based hub and spoke network architecture. They also need to configure relevant routes for the subnets as required.
  • The VPC participant (Account B) configures domain name resolution for Managed Blockchain resources thorough its VPC endpoint with private hosted zones from Amazon Route53. This is needed to resolve fully qualified domain names of Managed Blockchain service components.

The following diagram shows an example architecture.

Setting up a private hosted zone and cross-VPC domain resolution

For this use case, we assume that the VPC owner (Account A) has shared the shared VPC with a member of the account of the Managed Blockchain network (Account B). We also assume Account B has created a standalone VPC and a Managed Blockchain VPC endpoint and both standalone and shared VPCs have layer-three connectivity through VPC peering or a transit gateway.

To configure private DNS name resolution for the services of Managed Blockchain for the shared VPC, you first disable private DNS on the Managed Blockchain VPC endpoint currently associated with the standalone VPC. For more information, see Integrating AWS Transit Gateway with AWS PrivateLink and Amazon Route 53 Resolver.

  1. On the Amazon Virtual Private Cloud (Amazon VPC) console, choose Endpoints.
  2. Choose the endpoint for your Managed Blockchain network with the service name com.amazonaws.us-east-1.managedblockchain.<YOUR_AMB_NETWORK_ID> .
  3. Deselect Enable Private DNS Name.
  4. Record the endpoint ID to use later.
    After you disable private DNS for the Managed Blockchain VPC endpoint, you create an Amazon Route53 private hosted zone.
  5. On the Amazon Route53 console, choose Hosted zones.
  6. Choose Create hosted zone.
  7. For Domain name, enter the domain name for your managed Blockchain network (<YOUR_AMB_NETWORK_ID>.managedblockchain.<AWS_REGION>.amazonaws.com).
  8. For Type, choose Private Hosted Zone for Amazon VPC.
  9. For VPC ID, enter your standalone VPC ID.
    Now you can add a shared VPC ID to the list of VPCs associated with the hosted zone you just created.
  10. Select the hosted zone from the list and enter a VPC ID for the shared VPC.
    You then create an alias record to resolve all Managed Blockchain resources to the Managed Blockchain VPC endpoint.
  11. For Name, enter *.
  12. For Alias, select Yes.
  13. For Alias Target, enter a full Managed Blockchain VPC endpoint URL (<VPC_ENDPOINT_ID>.<YOUR_AMB_NETWORK_ID>.managedblockchain.<AWS_REGION>.vpce.amazonaws.com).

Now all applications running in the shared VPC can resolve host names for certificate authority, nodes, and ordering service of Managed Blockchain. For instructions on testing connectivity if you’re using Hyperledger Fabric CLI, see Create an Amazon EC2 Instance and Set Up the Hyperledger Fabric Client.

Considerations

When implementing this solution, keep the following limits in mind:

  • 100 associated VPCs per private hosted zone (you can request this limit be increased)
  • 20 VPC endpoints per VPC (you can request this limit to be increased)
  • 10 Gbps throughput per interface VPC endpoint elastic network interface, although this can burst higher
  • For AWS Transit Gateway, maximum bandwidth (burst) per VPC connection is 50 Gbps

Conclusion

In this post, I’ve laid out an architecture for sharing access to Managed Blockchain with multiple AWS accounts belonging to the same organization. This architecture helps optimize costs according to Well-Architected principles. Hopefully you have found this post useful. I look forward to any comments, and happy building on AWS!

Further reading
  1. Well-Architected Framework White Paper
  2. The Cost Optimization pillar of Well-Architected Framework

 

 

About the Authors

 

Nikolay Vlasov is a Senior Blockchain Architect with AWS Professional Services. Being part of a Global Speciality Practice team, he helps clients worldwide to turn their ideas into Pilots, Minimally Viable Products, and Production-ready systems based on blockchain technology.

 

 

 

Johnny Fang is a Senior Cloud Architect with AWS Professional Services. As part of the ASEAN Public Sector team, he works closely with education and public sector customers in Singapore to help them move to Government Commercial Cloud (GCC) on AWS.