Terraform Module that defines a VPC with public/private subnets across multiple AZs with Internet Gateways
This PR adds support for Network Address Usage Metrics on the VPC. AWS documentation : https://docs.aws.amazon.com/vpc/latest/userguide/network-address-usage.html Terraform documentation : https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/vpc#enable_network_address_usage_metrics
Network Address Usage metrics can help monitor the growth of a VPC and would be useful for any user. Enable this after creating a VPC does not trigger recreation of the VPC.
closes #115
Rebuild github dir from the template
Breaking changes: See migration notes for details.
This will be released as version 2.0.0-rc1 and possibly as 2.0.0 without changes. See migration notes for details.
modules/vpc-endpoints
)Breaking changes: See migration notes for details.
This will be released as version 2.0.0-rc1 and possibly as 2.0.0 without changes. See migration notes for details.
modules/vpc-endpoints
)aws_vpc
resource automatically.Change all references to git.io/build-harness
into cloudposse.tools/build-harness
, since git.io
redirects will stop working on April 29th, 2022.
Fixes a syntax error in the "Full example with terraform-aws-dynamic-subnets" code that results in a terraform plan
failure.
dynamic-subnets
generates a syntax error during terraform plan
This release brings full support for IPv6 and initial support of IPAM. It contains a minor breaking change:
ipv6_cidr_block
has been renamed vpc_ipv6_cidr_block
to be consistent with other output namesThese changes should be backward compatible. However, 3 variables were deprecated and replaced, and use of the new variables is encouraged.
ipv6_enabled
deprecated in favor of assign_generated_ipv6_cidr_block
In PR #99 released in version v0.28.0, we deprecated assign_generated_ipv6_cidr_block
in favor of ipv6_enabled
as part of a more general renaming of inputs to follow Cloud Posse's convention of naming boolean flags with _enabled
at the end. However, now that we have IPAM, the name ipv6_enabled
is misleading: it only means assign_generated_ipv6_cidr_block
and you have to set that to false
in order to assign an IPv6 address from IPAM. We do not want require you to set ipv6_enabled = false
in order to use IPv6 IPAM, so we are reversing course on this variable, deprecating ipv6_enabled
and reviving assign_generated_ipv6_cidr_block
.
cidr_block
deprecated in favor of ipv4_primary_cidr_block
Now that a VPC can have multiple IPv4 CIDR blocks along with multiple IPv6 CIDR blocks, the name cidr_block
is just too vague. Use ipv4_primary_cidr_block
instead to set the primary IPv4 CIDR block for the VPC.
additional_cidr_blocks
deprecated in favor of ipv4_additional_cidr_block_associations
As with cidr_block
, additional_cidr_blocks
is now too vague given that the module supports both IPv4 and IPv6 CIDR blocks. Also, you now have the option of having these CIDR blocks allocated by IPAM rather than being specified directly, requiring additional input parameters. So we created the new ipv4_additional_cidr_block_associations
and the parallel ipv6_additional_cidr_block_associations
to replace additional_cidr_blocks
(which, while deprecated, remains supported for now).
Note that the new variables take maps of configurations rather than lists of configurations. This is because each configuration is deployed as a separate Terraform resource, and the resources are not easily deleted and recreated. If you supply a list and then later remove the first element of the list, Terraform will deleted and recreate all the resources because Terraform tracks them by their list index and does not detect that they have simply moved. It sees that configuration 1 has changed (it is now what used to be configuration 2) so it deletes the old 1 and creates the old 2 as the new 1. This annoying at best, and with CIDR blocks being deleted and recreated it will likely fail at worst.
By providing the configurations as maps, you give each configuration a stable label, so that when you make a change, only the affected configuration changes. Removing a configuration does not affect the other configurations. The labels you assign are arbitrary and for your own benefit; the only requirement is that they be known at "plan time", meaning they cannot be generated by the Terraform code itself.
Due to the difficulty of configuring and testing the AWS VPC IP Address Manager, this feature has not been tested and support for it should be considered preliminary. Please report issues as you discover them.
Some inputs have been deprecated. New inputs typically take a map rather than a list so that we can use for_each
(for stability as the set of inputs changes) without relying on the values in the list (which can cause Terraform to complain that the results depend on values not available at "plan" time).
Supersedes and closes #103
ipv4_ipam_pool_id
& ipv4_netmask_length
variablescidr_block
with default value of null
cidr_block
is mutually exclusive to using ipv4_ipam_pool_id
and ipv4_netmask_length
cidr_block
auto-assignment for a VPC provided from an AWS VPC IPAM poolInitial release with production Semantic Versioning, part of Cloud Posse's general policy to convert to production versioning as we make updates to relatively mature modules, especially those where we see breaking changes coming in the near future. This release is exactly the same as v0.28.1.
We anticipate breaking changes (or at least changes that may cause resources to be moved from one Terraform "address" to another) in the near future (to be released as v2.0.0) as we add additional IPv6 support and support for AWS IP Address Manager (IPAM) along with additional changes for robustness.