README
¶
Terraform AWS Module - Subnet
Overview
Creates and configures a single AWS subnet, including IPv4 and IPv6 addressing, DNS options, public IP assignment, Outpost settings, and resource tags.
Examples
See the basic example for a working configuration.
Requirements
| Name | Version |
|---|---|
| terraform | ~> 1.5 |
| aws | >= 5.14 |
Modules
No modules.
Resources
| Name | Type |
|---|---|
| aws_subnet.subnet | resource |
Inputs
| Name | Description | Type | Default | Required |
|---|---|---|---|---|
| assign_ipv6_address_on_creation | (Optional) Specify true to indicate that network interfaces created in the specified subnet should be assigned an IPv6 address. | bool |
false |
no |
| availability_zone | (Optional) AZ for the subnet. | string |
null |
no |
| availability_zone_id | (Optional) AZ ID of the subnet. This argument is not supported in all regions or partitions. If necessary, use availability_zone instead. |
string |
null |
no |
| cidr_block | (Optional) The IPv4 CIDR block for the subnet. | string |
null |
no |
| customer_owned_ipv4_pool | (Optional) The customer owned IPv4 address pool. Typically used with the map_customer_owned_ip_on_launch argument. The outpost_arn argument must be specified when configured. |
string |
null |
no |
| enable_dns64 | (Optional) Indicates whether DNS queries made to the Amazon-provided DNS Resolver in this subnet should return synthetic IPv6 addresses for IPv4-only destinations. | bool |
false |
no |
| enable_lni_at_device_index | (Optional) Indicates whether DNS queries made to the Amazon-provided DNS Resolver in this subnet should return synthetic IPv6 addresses for IPv4-only destinations. | number |
null |
no |
| enable_resource_name_dns_a_record_on_launch | (Optional) Indicates whether to respond to DNS queries for instance hostnames with DNS A records. | bool |
false |
no |
| enable_resource_name_dns_aaaa_record_on_launch | (Optional) Indicates whether to respond to DNS queries for instance hostnames with DNS AAAA records. | bool |
false |
no |
| ipv6_cidr_block | (Optional) The IPv6 network range for the subnet, in CIDR notation. The subnet size must use a /64 prefix length. | string |
null |
no |
| ipv6_native | (Optional) Indicates whether to create an IPv6-only subnet. | bool |
false |
no |
| map_customer_owned_ip_on_launch | (Optional) Specify true to indicate that network interfaces created in the subnet should be assigned a customer owned IP address. The customer_owned_ipv4_pool and outpost_arn arguments must be specified when set to true. |
bool |
null |
no |
| map_public_ip_on_launch | (Optional) Specify true to indicate that instances launched into the subnet should be assigned a public IP address. | bool |
false |
no |
| outpost_arn | (Optional) The Amazon Resource Name (ARN) of the Outpost. | string |
null |
no |
| private_dns_hostname_type_on_launch | (Optional) The type of hostnames to assign to instances in the subnet at launch. For IPv6-only subnets, an instance DNS name must be based on the instance ID. For dual-stack and IPv4-only subnets, you can specify whether DNS names use the instance IPv4 address or the instance ID. Valid values: ip-name, resource-name. |
string |
null |
no |
| tags | (Optional) A map of tags to assign to the resource. | map(string) |
{} |
no |
| vpc_id | (Required) The VPC ID. | string |
n/a | yes |
Outputs
| Name | Description |
|---|---|
| subnet_arn | n/a |
| subnet_availibility_zone | n/a |
| subnet_cidr_block | n/a |
| subnet_id | n/a |
Module Development
Pre-Requisites
The following commands should be available on your system:
asdformisemakepython3(for pre-commit)
Additionally, your git user and email must be configured. Run the make configure command from the root of the repository to ensure that you meet these requirements.
Pre-Commit hooks
The .pre-commit-config.yaml file defines certain pre-commit hooks that are relevant to Terraform and Golang, as well as some common linting tasks. These will be configured for you when you run make configure.
Local Validation
You should validate the changes you make to any module locally, prior to pushing your changes in a branch to GitHub.
-
Ensure that you have run
make configuresuccessfully. -
Ensure you are signed into the appropriate cloud provider (e.g. AWS or Azure) for the module under test in your current console session.
-
Run the Terraform and Golang linters with the following command:
make lint
- Once you have satisfied the linters, the following command will build example infrastructure in your configured cloud, run the tests, and then tear down the infrastructure it created:
make test
The pre-commit validations, as well as the make lint and make test targets, will all be performed in CI. Running these validations locally prior to opening a PR helps ensure a smooth review and merge process.
Review & Merge Process
Once your change has been tested locally and your branch pushed up, open a new Pull Request for your branch to the default (main) branch of this repository.
The title of your Pull Request will determine the version bump for this change, and the title must be in Conventional Commits format in order to merge. A breaking change will trigger a major version bump, a feature will trigger a minor version bump, and all other types will trigger a patch version bump.
Ensure your CI workflows are passing; seek approval from teammates and address any feedback; seek any explicit approvals required by the CODEOWNERS file. You may merge the PR as soon as all requirements are met, and a new release and tag will be automatically created for you.
Automatic Updates
The shared configuration and workflow files in this repository are largely managed through the launch-terraform-skeleton repository. Outside of perhaps the .gitignore to account for specific files being generated by certain Terraform modules (e.g. Lambda functions), there should not be much cause to update these files on a per-repo basis, and making changes to them individually is discouraged.
If desired, you can check for and run these updates locally in a branch if you have the copier tool installed. Some example commands are included below:
# Check for updates, optionally checking prerelease versions
copier check-update [--prereleases]
# Run an update, using default answers if there are any. We use tasks, which requires --trust to be set.
copier update --defaults --trust [--prereleases]
# Recopy from the source, and --overwrite all templated files in the process
copier recopy --defaults --trust --overwrite [--prereleases]
Automatic updates will run through a scheduled workflow, and if the post-update tests are successful, the Pull Request created will automatically merge. Conflicts in the update or failures to test may leave a Pull Request outstanding, which needs to be addressed by a Launch Engineer.
Directories