The smart way of centralizing VPC endpoints with Route 53 Profiles

#aws #dns #route53 #awscommunitybuilders

How to Centralize Endpoints Smartly

A few months ago in April, AWS introduced a new feature to the Route 53 arsenal: Route 53 Profiles. One would think—ah, another AWS feature to manage DNS centrally. But there's much more to it than that.

Basically, Amazon realized that managing DNS across multiple environments is about as organized as a toddler's toy box or socks after laundry day (one of them falls victim to the sock-eating monster). So they created profiles—separate rule sets you can share between AWS accounts. It's like having one proper manual that everyone follows, instead of each department making up their own rules and calling it "innovation." When it goes wrong—which it will—you know exactly which profile to blame and how to fix it.

At a high level, the design allows you to, for example, share VPC endpoints and centralize them.

You create a central VPC with all of the VPC interface endpoints. Why interface? Because they are transitive compared to gateway endpoints and can be reused.
You can keep private DNS enabled on your centralized endpoints. No need to manually create hosted zones or resolver rules.
Create a Route 53 profile.
Simply associate endpoints with a Route 53 profile in the hub account and the hub VPC.
Share the profile via AWS Resource Access Manager.
Associate spoke VPCs to the profile—done.

Reality Check

This will save you between 84-87% of costs per hour by centralizing the endpoints according to my previous article. In reality, after one month living with this centralization technique, the savings were around 70%, mainly because I forgot to account for the attachment costs between accounts and the traffic.

Other Benefits

Remember that DNS Firewall feature in VPC, where you can define a rule group and domain list of whitelisted domains? Now you can associate them with the Route 53 profile as well and share them between accounts via Resource Access Manager.
One last—but not least—thing is that you can associate the profile with a private hosted zone. Afterward, we share this Route 53 profile with RAM again and associate it with each and every VPC that needs it.

Summary

Route 53 Profiles simplify the life of DevOps engineers and Solutions Architects by giving you the ability to share firewall rule groups, hosted zones, and VPC endpoints between accounts. Why does this matter? Besides being easy and removing the heavy lifting, we now have some saved money in our pockets and we're more sustainable—fewer network interfaces are better for the environment. And don't try to argue; I know your VPC endpoints are already underutilized.

Now you would ask: "Is there Terraform for it?"
Of course there is!

Terraform Code

resource "aws_route53profiles_profile" "primorsko" {
  name = "dtpl-r53-profiles"
  tags = {
    Environment = "ProbkoTestov testva surfa na primorsko"
  }
}

resource "aws_route53profiles_association" "spoke" {
  name        = "spoke"
  profile_id  = aws_route53profiles_profile.primorsko.id
  resource_id = var.hub_vpc_id
}

resource "aws_route53profiles_association" "hub" {
  name        = "hub"
  profile_id  = aws_route53profiles_profile.primorsko.id
  resource_id = var.spoke_vpc_id
}

resource "aws_route53profiles_resource_association" "ssm" {
  name         = "ssm"
  profile_id   = aws_route53profiles_profile.primorsko.id
  resource_arn = var.vpc_endpoint_ec2
}

resource "aws_route53profiles_resource_association" "ssmmessages" {
  name         = "ssmmessages"
  profile_id   = aws_route53profiles_profile.primorsko.id
  resource_arn = var.vpc_endpoint_ssmmessages
}

resource "aws_route53profiles_resource_association" "ec2messages" {
  name         = "ec2messages"
  profile_id   = aws_route53profiles_profile.primorsko.id
  resource_arn = var.vpc_endpoint_ec2messages # This is legacy; you can go without it
}

DEV Community