{"id":21202462,"url":"https://github.com/infrablocks/terraform-aws-vpc-auto-peering-lambda","last_synced_at":"2025-10-11T04:16:41.215Z","repository":{"id":38339604,"uuid":"93499621","full_name":"infrablocks/terraform-aws-vpc-auto-peering-lambda","owner":"infrablocks","description":"Terraform module for automatically peering VPCs","archived":false,"fork":false,"pushed_at":"2025-04-22T18:56:17.000Z","size":632,"stargazers_count":8,"open_issues_count":5,"forks_count":2,"subscribers_count":12,"default_branch":"main","last_synced_at":"2025-08-11T14:43:53.430Z","etag":null,"topics":["aws","lambda","peering","terraform","terraform-modules","vpc"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/infrablocks.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2017-06-06T09:17:44.000Z","updated_at":"2025-02-12T10:04:10.000Z","dependencies_parsed_at":"2022-08-24T00:30:58.195Z","dependency_job_id":"fc22d17b-56e6-4831-9ebb-68355d7f8fa6","html_url":"https://github.com/infrablocks/terraform-aws-vpc-auto-peering-lambda","commit_stats":null,"previous_names":[],"tags_count":72,"template":false,"template_full_name":null,"purl":"pkg:github/infrablocks/terraform-aws-vpc-auto-peering-lambda","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infrablocks%2Fterraform-aws-vpc-auto-peering-lambda","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infrablocks%2Fterraform-aws-vpc-auto-peering-lambda/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infrablocks%2Fterraform-aws-vpc-auto-peering-lambda/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infrablocks%2Fterraform-aws-vpc-auto-peering-lambda/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/infrablocks","download_url":"https://codeload.github.com/infrablocks/terraform-aws-vpc-auto-peering-lambda/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infrablocks%2Fterraform-aws-vpc-auto-peering-lambda/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":279006247,"owners_count":26084060,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-11T02:00:06.511Z","response_time":55,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws","lambda","peering","terraform","terraform-modules","vpc"],"created_at":"2024-11-20T20:16:05.860Z","updated_at":"2025-10-11T04:16:41.188Z","avatar_url":"https://github.com/infrablocks.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"Terraform AWS VPC Auto Peering Lambda\n=====================================\n\n[![CircleCI](https://circleci.com/gh/infrablocks/terraform-aws-vpc-auto-peering-lambda.svg?style=svg)](https://circleci.com/gh/infrablocks/terraform-aws-vpc-auto-peering-lambda)\n\nA Terraform module for automatically peering VPCs based on dependency\ninformation stored in tags.\n\nThe VPC auto peering lambda requires:\n\n* An SNS topic which receives events whenever a VPC is created or destroyed\n* A role to assume in order to create or destroy the peering connection and\n  routes\n\nThe VPC auto peering lambda consists of:\n\n* A lambda function which responds to VPC lifecycle events on the SNS topic\n* A subscription to the SNS topic\n* IAM roles and policies allowing the lambda to function\n\nThe VPC auto peering lambda:\n\n* automatically configures VPC peering both within and across regions and both\n  within and across accounts; and\n* configures unidirectional or bidirectional routing between the peered VPCs, as\n  required.\n\nArchitecture\n------------\n\nThe VPC auto-peering lambda automatically creates peering connections and routes\nbetween VPCs based on relationships declared by each VPC via tags. In order to\nachieve this, the lambda needs to know when VPCs are provisioned and destroyed.\n\nSince AWS doesn't provide any built in events for VPC lifecycle, the lambda\nrelies on an alternative approach for such events, as provided by the\n[`terraform-aws-vpc-lifecycle-event`](https://github.com/infrablocks/terraform-aws-vpc-lifecycle-event)\nand\n[`terraform-aws-infrastructure-events`](https://github.com/infrablocks/terraform-aws-infrastructure-events)\nmodules.\n\nThe `terraform-aws-infrastructure-events` module uses S3 objects to represent\nprovisions and destroys of pieces of infrastructure, converting the\ncorresponding object creations and deletions into messages in an SNS topic. In\nthis way, Terraform configurations can signal changes to infrastructure by\ncreating or deleting an S3 object whose key includes information about that\ninfrastructure.\n\nThe `terraform-aws-vpc-lifecycle-event` module uses this mechanism to notify of\na VPC lifecycle change, such as when a VPC is provisioned or destroyed.\n\nThe diagram below shows how these modules work together:\n\n![Diagram of architecture used by this module](https://raw.githubusercontent.com/infrablocks/terraform-aws-vpc-auto-peering-lambda/main/docs/architecture.png)\n\nNote that for this to work, the `terraform-aws-infrastructure-events` and\n`terraform-aws-vpc-auto-peering-lambda` modules should be created in one\nTerraform configuration while the `terraform-aws-vpc-lifecycle-event` module\nshould be used in the configuration that manages the VPC.\n\nIn addition to the event infrastructure, the VPC auto peering lambda also needs\na role to be available in each of the accounts in which it should manage\npeering, with the same name. The\n[`terraform-aws-vpc-auto-peering-role`](https://github.com/infrablocks/terraform-aws-vpc-auto-peering-role)\nmodule can provision a role with the required policy.\n\nThe `terraform-aws-vpc-auto-peering-lambda` module additionally expects a\ncertain tag protocol to be followed on created VPCs and route tables as\ndescribed in the [Implementation](#implementation) section below. The\n[`terraform-aws-base-networking`](https://github.com/infrablocks/terraform-aws-base-networking)\nmodule implements this protocol and is designed to work with this module.\n\nImplementation\n--------------\n\n### Declaring dependencies\n\nThe dependents and dependencies of each VPC are defined in terms of the VPC's\n\"component deployment identifier\" which is the concatenation of the values of\nthe `Component` and `DeploymentIdentifier` tags on the VPC. For example, given a\nVPC with the following tags:\n\n```hcl\nresource \"aws_vpc\" \"vpc_1\" {\n  // ...\n\n  tags = {\n    Component            = \"application-network\"\n    DeploymentIdentifier = \"development-1\"\n    // ...\n  }\n}\n```\n\nthe component deployment identifier would be\n`\"application-network-development-1\"`.\n\nUsing these component deployment identifiers, VPC dependencies are then defined\nusing the `Dependencies` tag. For example, in the following, `vpc_1` is both\ndependent on `vpc_2` and `vpc_3` and is also a dependency of `vpc_3`:\n\n```hcl\nresource \"aws_vpc\" \"vpc_1\" {\n  // ...\n\n  tags = {\n    Component            = \"application-network\"\n    DeploymentIdentifier = \"development-1\"\n    Dependencies         = \"integration-network-development-1, connectivity-network-development-1\"\n    // ...\n  }\n}\n\nresource \"aws_vpc\" \"vpc_2\" {\n  // ...\n\n  tags = {\n    Component            = \"integration-network\"\n    DeploymentIdentifier = \"development-1\"\n    // ...\n  }\n}\n\nresource \"aws_vpc\" \"vpc_3\" {\n  // ...\n\n  tags = {\n    Component            = \"connectivity-network\"\n    DeploymentIdentifier = \"development-1\"\n    Dependencies         = \"application-network-development-1\"\n    // ...\n  }\n}\n```\n\nAs can be seen in the example above, the `Dependencies` tag value is a comma\nseparated string of component deployment identifiers (whitespace ignored),\nallowing more than one dependency to be defined.\n\n### On VPC provisioning\n\nUpon receiving an event indicating VPC creation, the VPC auto peering lambda\nlooks up both the created VPC based on the account ID and VPC ID in the VPC\nlifecycle event as well as all other VPCs within its search regions and\naccounts. Using the discovered VPCs, it determines the set of VPCs dependent on\nthe newly created VPC and the set of VPCs on which the newly created VPC\ndepends.\n\nOnce the set of dependencies and dependents has been determined, the auto\npeering lambda requests and accepts peering connections to satisfy the overall\ndependencies given the introduction of the new VPC. For the example given in\n[declaring dependencies](#declaring-dependencies) above, if `vpc_1` had just\nbeen created, peering connections would be established between `vpc_1` and\n`vpc_2` as well as between `vpc_1` and `vpc_3`.\n\nOnce peering connections have been established, the auto peering lambda creates\na route for each defined dependency in any route tables found in the dependent\nVPC that have a `Tier` tag with value `\"private\"`. When doing so, the auto\npeering lambda uses the full CIDR of each VPC within the route definition.\n\nIn this way, any routing between VPCs is only bidirectional if both VPCs declare\na dependency on each other, otherwise the routing is unidirectional. For the\nexample given in [declaring dependencies](#declaring-dependencies) above, a\nroute will be created in each of `vpc_1`'s private route tables to each of\n`vpc_2` and `vpc_3`'s CIDRs. A route will also be created in `vpc_3`'s private\nroute tables back to `vpc_1`'s CIDR. However, no route will be created in\n`vpc_2`'s private route tables.\n\n### On VPC destruction\n\nUpon receiving an event indicating VPC deletion, the VPC auto peering lambda\nperforms the reverse operation. It looks up both the deleted VPC based on the\naccount ID and VPC ID in the VPC lifecycle event as well as all other VPCs\nwithin its search regions and accounts. Using the discovered VPCs, it determines\nthe set of VPCs that were dependent on the newly deleted VPC and the set of VPCs\non which the deleted VPC depended.\n\nUsing this information, the auto peering lambda deletes the corresponding routes\nfrom the private route tables of any VPCs that previously had a relationship\nwith the deleted VPC, before deleting any peering connections.\n\nUsage\n-----\n\nTo use the module, include something like the following in your Terraform\nconfiguration:\n\n```hcl\nmodule \"vpc-auto-peering\" {\n  source  = \"infrablocks/vpc-auto-peering/aws\"\n  version = \"2.0.0\"\n\n  region                = \"eu-west-2\"\n  deployment_identifier = \"1bc5defe\"\n\n  search_regions    = [\"eu-west-2\", \"us-east-1\"]\n  search_accounts   = [\"554132201093\", \"554132201093\"]\n  peering_role_name = \"auto-peering-role\"\n\n  infrastructure_events_topic_arn = \"arn:aws:sns:eu-west-2:579878096224:infrastructure-events-topic-eu-west-2-335e1e54\"\n}\n```\n\nNote:\n* If the `search_regions` variable is not supplied, it defaults to the value of \n  the `region` variable, i.e., the region in which the lambda is deployed\n* If the `search_accounts` variable is not supplied, it defaults to the account\n  in which the lambda is deployed\n* If the `peering_role_name` variable is not supplied, it defaults to \n  `\"vpc-auto-peering-role\"` which is the name of the role created by the\n  [`terraform-aws-vpc-auto-peering-role`](https://github.com/infrablocks/terraform-aws-vpc-auto-peering-role)\n  module.\n\nSee the\n[Terraform registry entry](https://registry.terraform.io/modules/infrablocks/vpc-auto-peering-lambda/aws/latest)\nfor more details.\n\n### Inputs\n\n| Name                            | Description                                                                | Default | Required |\n|---------------------------------|----------------------------------------------------------------------------|:-------:|:--------:|\n| region                          | The region into which the VPC auto peering lambda is being deployed.       | -       | Yes      |\n| deployment_identifier           | An identifier for this instantiation.                                      | -       | Yes      |\n| infrastructure_events_topic_arn | The ARN of the SNS topic containing VPC events.                            | -       | Yes      |\n| search_regions                  | AWS regions to search for dependency and dependent VPCs.                   | `[]`    | No       |\n| search_accounts                 | IDs of AWS accounts to search for dependency and dependent VPCs.           | `[]`    | No       |\n| peering_role_name               | The name of the role to assume to create peering relationships and routes. | `\"\"`    | No       |\n\n### Outputs\n\n| Name                         | Description                                          |\n|------------------------------|------------------------------------------------------|\n| lambda_role_arn              | The ARN of the created lambda.                       |\n\n### Compatibility\n\nThis module is compatible with Terraform versions greater than or equal to \nTerraform 1.0.\n\nDevelopment\n-----------\n\n### Machine Requirements\n\nIn order for the build to run correctly, a few tools will need to be installed \non your development machine:\n\n* Ruby (3.1.1)\n* Bundler\n* git\n* git-crypt\n* gnupg\n* direnv\n* aws-vault\n\n#### Mac OS X Setup\n\nInstalling the required tools is best managed by [homebrew](http://brew.sh).\n\nTo install homebrew:\n\n```\nruby -e \"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)\"\n```\n\nThen, to install the required tools:\n\n```\n# ruby\nbrew install rbenv\nbrew install ruby-build\necho 'eval \"$(rbenv init - bash)\"' \u003e\u003e ~/.bash_profile\necho 'eval \"$(rbenv init - zsh)\"' \u003e\u003e ~/.zshrc\neval \"$(rbenv init -)\"\nrbenv install 3.1.1\nrbenv rehash\nrbenv local 3.1.1\ngem install bundler\n\n# git, git-crypt, gnupg\nbrew install git\nbrew install git-crypt\nbrew install gnupg\n\n# aws-vault\nbrew cask install\n\n# direnv\nbrew install direnv\necho \"$(direnv hook bash)\" \u003e\u003e ~/.bash_profile\necho \"$(direnv hook zsh)\" \u003e\u003e ~/.zshrc\neval \"$(direnv hook $SHELL)\"\n\ndirenv allow \u003crepository-directory\u003e\n```\n\n### Running the build\n\nRunning the build requires an AWS account and AWS credentials. You are free to \nconfigure credentials however you like as long as an access key ID and secret\naccess key are available. These instructions utilise \n[aws-vault](https://github.com/99designs/aws-vault) which makes credential\nmanagement easy and secure.\n\nTo provision module infrastructure, run tests and then destroy that \ninfrastructure, execute:\n\n```bash\naws-vault exec \u003cprofile\u003e -- ./go\n```\n\nTo provision the module prerequisites:\n\n```bash\naws-vault exec \u003cprofile\u003e -- ./go deployment:prerequisites:provision[\u003cdeployment_identifier\u003e]\n```\n\nTo provision the module contents:\n\n```bash\naws-vault exec \u003cprofile\u003e -- ./go deployment:root:provision[\u003cdeployment_identifier\u003e]\n```\n\nTo destroy the module contents:\n\n```bash\naws-vault exec \u003cprofile\u003e -- ./go deployment:root:destroy[\u003cdeployment_identifier\u003e]\n```\n\nTo destroy the module prerequisites:\n\n```bash\naws-vault exec \u003cprofile\u003e -- ./go deployment:prerequisites:destroy[\u003cdeployment_identifier\u003e]\n```\n\nConfiguration parameters can be overridden via environment variables:\n\n```bash\nDEPLOYMENT_IDENTIFIER=testing aws-vault exec \u003cprofile\u003e -- ./go\n```\n\nWhen a deployment identifier is provided via an environment variable, \ninfrastructure will not be destroyed at the end of test execution. This can\nbe useful during development to avoid lengthy provision and destroy cycles.\n\nBy default, providers will be downloaded for each terraform execution. To\ncache providers between calls:\n\n```bash\nTF_PLUGIN_CACHE_DIR=\"$HOME/.terraform.d/plugin-cache\" aws-vault exec \u003cprofile\u003e -- ./go\n```\n\n### Common Tasks\n\n#### Generating an SSH key pair\n\nTo generate an SSH key pair:\n\n```\nssh-keygen -m PEM -t rsa -b 4096 -C integration-test@example.com -N '' -f config/secrets/keys/bastion/ssh\n```\n\n#### Generating a self-signed certificate\n\nTo generate a self signed certificate:\n```\nopenssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365\n```\n\nTo decrypt the resulting key:\n\n```\nopenssl rsa -in key.pem -out ssl.key\n```\n\n#### Add a git-crypt user\n\nTo adding a user to git-crypt using their GPG key: \n\n```\ngpg --import ~/path/xxxx.pub\ngit-crypt add-gpg-user --trusted GPG-USER-ID\n\n```\n\n#### Managing CircleCI keys\n\nTo encrypt a GPG key for use by CircleCI:\n\n```bash\nopenssl aes-256-cbc \\\n  -e \\\n  -md sha1 \\\n  -in ./config/secrets/ci/gpg.private \\\n  -out ./.circleci/gpg.private.enc \\\n  -k \"\u003cpassphrase\u003e\"\n```\n\nTo check decryption is working correctly:\n\n```bash\nopenssl aes-256-cbc \\\n  -d \\\n  -md sha1 \\\n  -in ./.circleci/gpg.private.enc \\\n  -k \"\u003cpassphrase\u003e\"\n```\n\nContributing\n------------\n\nBug reports and pull requests are welcome on GitHub at\nhttps://github.com/infrablocks/terraform-aws-vpc-auto-peering-lambda. This\nproject is intended to be a safe, welcoming space for collaboration, and\ncontributors are expected to adhere to the \n[Contributor Covenant](http://contributor-covenant.org) code of conduct.\n\nLicense\n-------\n\nThe library is available as open source under the terms of the \n[MIT License](http://opensource.org/licenses/MIT).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Finfrablocks%2Fterraform-aws-vpc-auto-peering-lambda","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Finfrablocks%2Fterraform-aws-vpc-auto-peering-lambda","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Finfrablocks%2Fterraform-aws-vpc-auto-peering-lambda/lists"}