Think back to those days when you met the love of your life. The feeling was mutual. The world seemed like a better place, and you were on an exciting journey with your significant other. You were both “all-in” as you made plans for a life together. Life was amazing … until it wasn’t. When things don’t work out as planned, then you’ve got to do the hard work of unwinding the relationship. Communicating with each other, and with others. Sorting out shared purchases. Moving on. Bleh. Believe it or not, our relationship with technology isn’t all that different. Breaking Up With a Service There was a time when you decided to adopt a service—maybe it was a SaaS, a PaaS, or something more generic. Back in the day, did you make the decision while also considering the time when you would no longer plan to use the service anymore? Probably not. You were just thinking of all the wonderful possibilities for the future. But what happens when going with that service is no longer in your best interest? Now, you’re in for a challenge, and it’s called service abdication. While services can be shut down with a reasonable amount of effort, getting the underlying data can be problematic. This often depends on the kind of service and the volume of data owned by that service provider. Sometimes, the ideal unwinding looks like this: Stop paying for the service, but retain access to the data source for some period of time. Is this even a possibility? Yes, it is! The Power of VPC Peering Leading cloud providers have embraced the virtual private cloud (VPC) network as the de facto approach to establishing connectivity between resources. For example, an EC2 instance on AWS can access a data source using VPCs and VPC end-point services. Think of it as a point-to-point connection. VPCs allow us to grant access to other resources in the same cloud provider, but we can also use them to grant access to external services. Consider a service that was recently abdicated but with the original data source left in place. Here’s how it might look: This concept is called VPC peering, and it allows for a private connection to be established from another network. A Service Migration Example Let’s consider a more concrete example. In your organization, a business decision was made to streamline how it operates in the cloud. While continuing to leverage some AWS services, your organization wanted to optimize how it builds, deploys, and manages its applications by terminating a third-party, cloud-based service running on AWS. They ran the numbers and concluded that internal software engineers could stand up and support a new auto-scaled service on Heroku for a fraction of the cost that they had been paying the third-party provider. However, because of a long tenure with the service provider, migrating the data source is not an option anytime soon. You don’t want the service, and you can’t move the data, but you still want access to the data. Fortunately, the provider has agreed to a new contract to continue hosting the data and provide access—via VPC peering. Here’s how the new arrangement would look: VPC Peering With Heroku In order for your new service (a Heroku app) to access the original data source in AWS, you’ll first need to run your app within a Private Space. For more information, you can read about Secure Cloud adoption and my discovery of Heroku Private Spaces. Next, you’ll need to meet the following simple network requirements: The VPC must use a compatible IPv4 CIDR block in its network configuration. The VPC must use an RFC1918 CIDR block (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). The VPC’s CIDR block must not overlap with the CIDR ranges for your Private Space. The default ranges are 10.0.0.0/16, 10.1.0.0/16, and 172.17.0.0/16. With your Private Space up and running, you’ll need to retrieve its peering information: $ heroku spaces:peering:info our-new-app
=== our-new-app Peering Info
AWS Account ID:    647xxxxxx317
AWS Region:        us-east-1
AWS VPC ID:        vpc-e285ab73
AWS VPC CIDR:      10.0.0.0/16
Space CIDRs:       10.0.128.0/20, 10.0.144.0/20, 10.0.0.0/20, 10.0.16.0/20
Unavailable CIDRs: 10.1.0.0/16 Copy down the AWS Account ID (647xxxxxx317) and AWS VPC ID (vpc-e285ab73). You’ll need to give that information to the third-party provider who controls the AWS data source. From there, they can use either the AWS Console or CLI to create a peering connection. Their operation would look something like this: $ aws ec2 create-vpc-peering-connection \ 
  --vpc-id vpc-e527bb17 \
  --peer-vpc-id vpc-e285ab73 \
  --peer-owner-id 647xxxxxx317
{
    "VpcPeeringConnection": {
        "Status": {
            "Message": "Initiating Request to 647xxxxxx317",
            "Code": "initiating-request"
        },
        "Tags": [],
        "RequesterVpcInfo": {
            "OwnerId": "714xxxxxx214",
            "VpcId": "vpc-e527bb17",
            "CidrBlock": "10.100.0.0/16"
        },
        "VpcPeeringConnectionId": "pcx-123abc456",
        "ExpirationTime": "2025-04-23T22:05:27.000Z",
        "AccepterVpcInfo": {
            "OwnerId": "647xxxxxx317",
            "VpcId": "vpc-e285ab73"
        }
    }
} This creates a request to the peer. Once the provider has done this, you can view the pending request on the Heroku side: $ heroku spaces:peerings our-new-app In the screenshot below, we can see the pending acceptance status for the peering connection. From here, you can accept the peering connection request: $ heroku spaces:peerings:accept pcx-123abc456 --space our-new-app
Accepting and configuring peering connection pcx-123abc456 We check the request status a second time: $ heroku spaces:peerings our-new-app We see that the peer connection is active. At this point, the app running in our Heroku Private Space will be able to access the AWS data source without any issues. Conclusion An unfortunate truth in life is that relationships can be unsuccessful just as often as they can be long-lasting. This applies to people, and it applies to technology. When it comes to technology decisions, sometimes changing situations and needs drive us to move in different directions. Sometimes, things just don’t work out. And in these situations, the biggest challenge is often unwinding an existing implementation—without losing access to persistent data. Fortunately, Heroku provides a solution for slowly migrating away from existing cloud-based solutions while retaining access to externally hosted data. Its easy integration for VPC peering with AWS lets you access resources that still need to live in the legacy implementation, even if the rest of you have moved on. Taking this approach will allow your new service to thrive without an interruption in service to the consumer. Have a really great day! Think back to those days when you met the love of your life. The feeling was mutual. The world seemed like a better place, and you were on an exciting journey with your significant other. You were both “all-in” as you made plans for a life together. Life was amazing … until it wasn’t. When things don’t work out as planned, then you’ve got to do the hard work of unwinding the relationship. Communicating with each other, and with others. Sorting out shared purchases. Moving on. Bleh. Believe it or not, our relationship with technology isn’t all that different. Breaking Up With a Service There was a time when you decided to adopt a service—maybe it was a SaaS, a PaaS, or something more generic. Back in the day, did you make the decision while also considering the time when you would no longer plan to use the service anymore? Probably not. You were just thinking of all the wonderful possibilities for the future. But what happens when going with that service is no longer in your best interest? Now, you’re in for a challenge, and it’s called service abdication . While services can be shut down with a reasonable amount of effort, getting the underlying data can be problematic. This often depends on the kind of service and the volume of data owned by that service provider. service abdication Sometimes, the ideal unwinding looks like this: Stop paying for the service, but retain access to the data source for some period of time. Is this even a possibility? Yes, it is! The Power of VPC Peering Leading cloud providers have embraced the virtual private cloud (VPC) network as the de facto approach to establishing connectivity between resources. For example, an EC2 instance on AWS can access a data source using VPCs and VPC end-point services. Think of it as a point-to-point connection. VPCs allow us to grant access to other resources in the same cloud provider, but we can also use them to grant access to external services . Consider a service that was recently abdicated but with the original data source left in place. Here’s how it might look: grant access to external services This concept is called VPC peering, and it allows for a private connection to be established from another network. A Service Migration Example Let’s consider a more concrete example. In your organization, a business decision was made to streamline how it operates in the cloud. While continuing to leverage some AWS services, your organization wanted to optimize how it builds, deploys, and manages its applications by terminating a third-party, cloud-based service running on AWS. They ran the numbers and concluded that internal software engineers could stand up and support a new auto-scaled service on Heroku for a fraction of the cost that they had been paying the third-party provider. However, because of a long tenure with the service provider, migrating the data source is not an option anytime soon. You don’t want the service, and you can’t move the data, but you still want access to the data. Fortunately, the provider has agreed to a new contract to continue hosting the data and provide access—via VPC peering. You don’t want the service, and you can’t move the data, but you still want access to the data. Here’s how the new arrangement would look: VPC Peering With Heroku In order for your new service (a Heroku app) to access the original data source in AWS, you’ll first need to run your app within a Private Space. For more information, you can read about Secure Cloud adoption and my discovery of Heroku Private Spaces . Secure Cloud adoption and my discovery of Heroku Private Spaces Next, you’ll need to meet the following simple network requirements: The VPC must use a compatible IPv4 CIDR block in its network configuration. The VPC must use a compatible IPv4 CIDR block in its network configuration. The VPC must use an RFC1918 CIDR block (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). The VPC must use an RFC1918 CIDR block ( 10.0.0.0/8 , 172.16.0.0/12 , or 192.168.0.0/16 ). 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 The VPC’s CIDR block must not overlap with the CIDR ranges for your Private Space. The default ranges are 10.0.0.0/16, 10.1.0.0/16, and 172.17.0.0/16. The VPC’s CIDR block must not overlap with the CIDR ranges for your Private Space. The default ranges are 10.0.0.0/16 , 10.1.0.0/16 , and 172.17.0.0/16 . 10.0.0.0/16 10.1.0.0/16 172.17.0.0/16 With your Private Space up and running, you’ll need to retrieve its peering information: $ heroku spaces:peering:info our-new-app
=== our-new-app Peering Info
AWS Account ID:    647xxxxxx317
AWS Region:        us-east-1
AWS VPC ID:        vpc-e285ab73
AWS VPC CIDR:      10.0.0.0/16
Space CIDRs:       10.0.128.0/20, 10.0.144.0/20, 10.0.0.0/20, 10.0.16.0/20
Unavailable CIDRs: 10.1.0.0/16 $ heroku spaces:peering:info our-new-app
=== our-new-app Peering Info
AWS Account ID:    647xxxxxx317
AWS Region:        us-east-1
AWS VPC ID:        vpc-e285ab73
AWS VPC CIDR:      10.0.0.0/16
Space CIDRs:       10.0.128.0/20, 10.0.144.0/20, 10.0.0.0/20, 10.0.16.0/20
Unavailable CIDRs: 10.1.0.0/16 Copy down the AWS Account ID (647xxxxxx317) and AWS VPC ID (vpc-e285ab73). You’ll need to give that information to the third-party provider who controls the AWS data source. From there, they can use either the AWS Console or CLI to create a peering connection . Their operation would look something like this: AWS Account ID AWS VPC ID create a peering connection $ aws ec2 create-vpc-peering-connection \ 
  --vpc-id vpc-e527bb17 \
  --peer-vpc-id vpc-e285ab73 \
  --peer-owner-id 647xxxxxx317
{
    "VpcPeeringConnection": {
        "Status": {
            "Message": "Initiating Request to 647xxxxxx317",
            "Code": "initiating-request"
        },
        "Tags": [],
        "RequesterVpcInfo": {
            "OwnerId": "714xxxxxx214",
            "VpcId": "vpc-e527bb17",
            "CidrBlock": "10.100.0.0/16"
        },
        "VpcPeeringConnectionId": "pcx-123abc456",
        "ExpirationTime": "2025-04-23T22:05:27.000Z",
        "AccepterVpcInfo": {
            "OwnerId": "647xxxxxx317",
            "VpcId": "vpc-e285ab73"
        }
    }
} $ aws ec2 create-vpc-peering-connection \ 
  --vpc-id vpc-e527bb17 \
  --peer-vpc-id vpc-e285ab73 \
  --peer-owner-id 647xxxxxx317
{
    "VpcPeeringConnection": {
        "Status": {
            "Message": "Initiating Request to 647xxxxxx317",
            "Code": "initiating-request"
        },
        "Tags": [],
        "RequesterVpcInfo": {
            "OwnerId": "714xxxxxx214",
            "VpcId": "vpc-e527bb17",
            "CidrBlock": "10.100.0.0/16"
        },
        "VpcPeeringConnectionId": "pcx-123abc456",
        "ExpirationTime": "2025-04-23T22:05:27.000Z",
        "AccepterVpcInfo": {
            "OwnerId": "647xxxxxx317",
            "VpcId": "vpc-e285ab73"
        }
    }
} This creates a request to the peer. Once the provider has done this, you can view the pending request on the Heroku side: $ heroku spaces:peerings our-new-app $ heroku spaces:peerings our-new-app In the screenshot below, we can see the pending acceptance status for the peering connection. From here, you can accept the peering connection request: $ heroku spaces:peerings:accept pcx-123abc456 --space our-new-app
Accepting and configuring peering connection pcx-123abc456 $ heroku spaces:peerings:accept pcx-123abc456 --space our-new-app
Accepting and configuring peering connection pcx-123abc456 We check the request status a second time: $ heroku spaces:peerings our-new-app $ heroku spaces:peerings our-new-app We see that the peer connection is active. At this point, the app running in our Heroku Private Space will be able to access the AWS data source without any issues. Conclusion An unfortunate truth in life is that relationships can be unsuccessful just as often as they can be long-lasting. This applies to people, and it applies to technology. When it comes to technology decisions, sometimes changing situations and needs drive us to move in different directions. Sometimes, things just don’t work out. And in these situations, the biggest challenge is often unwinding an existing implementation—without losing access to persistent data. Fortunately, Heroku provides a solution for slowly migrating away from existing cloud-based solutions while retaining access to externally hosted data. Its easy integration for VPC peering with AWS lets you access resources that still need to live in the legacy implementation, even if the rest of you have moved on. Taking this approach will allow your new service to thrive without an interruption in service to the consumer. Have a really great day!

How to Test QR Codes in Your Applications

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

When (Tech Service) Relationships Don’t Work Out

When (Tech Service) Relationships Don’t Work Out

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 2)

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

101 Stories To Learn About Cloud Infrastructure

10 Things in Engineering We Don't Spend Enough Time On

10 Things I Did To Increase CloudTrail Logs Security

10 reasons to give cloud computing a go

10 Lessons from 10 Years of AWS (part 2)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps