aws-cdk.aws-ec2-alpha 2.177.0a0__tar.gz → 2.178.1a0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Potentially problematic release.
This version of aws-cdk.aws-ec2-alpha might be problematic. Click here for more details.
- {aws_cdk_aws_ec2_alpha-2.177.0a0/src/aws_cdk.aws_ec2_alpha.egg-info → aws_cdk_aws_ec2_alpha-2.178.1a0}/PKG-INFO +245 -16
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/README.md +243 -14
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/setup.py +3 -3
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/src/aws_cdk/aws_ec2_alpha/__init__.py +5919 -2640
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/src/aws_cdk/aws_ec2_alpha/_jsii/__init__.py +2 -2
- aws_cdk_aws_ec2_alpha-2.178.1a0/src/aws_cdk/aws_ec2_alpha/_jsii/aws-ec2-alpha@2.178.1-alpha.0.jsii.tgz +0 -0
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0/src/aws_cdk.aws_ec2_alpha.egg-info}/PKG-INFO +245 -16
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/src/aws_cdk.aws_ec2_alpha.egg-info/SOURCES.txt +1 -1
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/src/aws_cdk.aws_ec2_alpha.egg-info/requires.txt +1 -1
- aws_cdk_aws_ec2_alpha-2.177.0a0/src/aws_cdk/aws_ec2_alpha/_jsii/aws-ec2-alpha@2.177.0-alpha.0.jsii.tgz +0 -0
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/LICENSE +0 -0
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/MANIFEST.in +0 -0
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/NOTICE +0 -0
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/pyproject.toml +0 -0
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/setup.cfg +0 -0
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/src/aws_cdk/aws_ec2_alpha/py.typed +0 -0
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/src/aws_cdk.aws_ec2_alpha.egg-info/dependency_links.txt +0 -0
- {aws_cdk_aws_ec2_alpha-2.177.0a0 → aws_cdk_aws_ec2_alpha-2.178.1a0}/src/aws_cdk.aws_ec2_alpha.egg-info/top_level.txt +0 -0
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.1
|
|
2
2
|
Name: aws-cdk.aws-ec2-alpha
|
|
3
|
-
Version: 2.
|
|
3
|
+
Version: 2.178.1a0
|
|
4
4
|
Summary: The CDK construct library for VPC V2
|
|
5
5
|
Home-page: https://github.com/aws/aws-cdk
|
|
6
6
|
Author: Amazon Web Services
|
|
@@ -23,7 +23,7 @@ Requires-Python: ~=3.8
|
|
|
23
23
|
Description-Content-Type: text/markdown
|
|
24
24
|
License-File: LICENSE
|
|
25
25
|
License-File: NOTICE
|
|
26
|
-
Requires-Dist: aws-cdk-lib<3.0.0,>=2.
|
|
26
|
+
Requires-Dist: aws-cdk-lib<3.0.0,>=2.178.1
|
|
27
27
|
Requires-Dist: constructs<11.0.0,>=10.0.0
|
|
28
28
|
Requires-Dist: jsii<2.0.0,>=1.106.0
|
|
29
29
|
Requires-Dist: publication>=0.0.3
|
|
@@ -34,13 +34,13 @@ Requires-Dist: typeguard<4.3.0,>=2.13.3
|
|
|
34
34
|
<!--BEGIN STABILITY BANNER-->---
|
|
35
35
|
|
|
36
36
|
|
|
37
|
-

|
|
38
38
|
|
|
39
|
-
> The APIs of higher level constructs in this module are
|
|
40
|
-
>
|
|
41
|
-
> not subject to
|
|
42
|
-
> announced in
|
|
43
|
-
> your source code when upgrading to a newer version of this package.
|
|
39
|
+
> The APIs of higher level constructs in this module are in **developer preview** before they
|
|
40
|
+
> become stable. We will only make breaking changes to address unforeseen API issues. Therefore,
|
|
41
|
+
> these APIs are not subject to [Semantic Versioning](https://semver.org/), and breaking changes
|
|
42
|
+
> will be announced in release notes. This means that while you may use them, you may need to
|
|
43
|
+
> update your source code when upgrading to a newer version of this package.
|
|
44
44
|
|
|
45
45
|
---
|
|
46
46
|
<!--END STABILITY BANNER-->
|
|
@@ -51,7 +51,10 @@ Requires-Dist: typeguard<4.3.0,>=2.13.3
|
|
|
51
51
|
on the VPC being created. `VpcV2` implements the existing [`IVpc`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.IVpc.html), therefore,
|
|
52
52
|
`VpcV2` is compatible with other constructs that accepts `IVpc` (e.g. [`ApplicationLoadBalancer`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationLoadBalancer.html#construct-props)).
|
|
53
53
|
|
|
54
|
-
|
|
54
|
+
`VpcV2` supports the addition of both primary and secondary addresses. The primary address must be an IPv4 address, which can be specified as a CIDR string or assigned from an IPAM pool. Secondary addresses can be either IPv4 or IPv6.
|
|
55
|
+
By default, `VpcV2` assigns `10.0.0.0/16` as the primary CIDR if no other CIDR is specified.
|
|
56
|
+
|
|
57
|
+
Below is an example of creating a VPC with both IPv4 and IPv6 support:
|
|
55
58
|
|
|
56
59
|
```python
|
|
57
60
|
stack = Stack()
|
|
@@ -69,6 +72,7 @@ VpcV2(self, "Vpc",
|
|
|
69
72
|
|
|
70
73
|
`SubnetV2` is a re-write of the [`ec2.Subnet`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.Subnet.html) construct.
|
|
71
74
|
This new construct can be used to add subnets to a `VpcV2` instance:
|
|
75
|
+
Note: When defining a subnet with `SubnetV2`, CDK automatically creates a new route table, unless a route table is explicitly provided as an input to the construct.
|
|
72
76
|
|
|
73
77
|
```python
|
|
74
78
|
stack = Stack()
|
|
@@ -87,16 +91,25 @@ SubnetV2(self, "subnetA",
|
|
|
87
91
|
)
|
|
88
92
|
```
|
|
89
93
|
|
|
94
|
+
Since `VpcV2` does not create subnets automatically, users have full control over IP addresses allocation across subnets.
|
|
95
|
+
|
|
90
96
|
## IP Addresses Management
|
|
91
97
|
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
98
|
+
Additional CIDRs can be added to the VPC via the `secondaryAddressBlocks` property.
|
|
99
|
+
The following example illustrates the options of defining these secondary address blocks using `IPAM`:
|
|
100
|
+
|
|
101
|
+
Note: There’s currently an issue with IPAM pool deletion that may affect the `cdk --destroy` command. This is because IPAM takes time to detect when the IP address pool has been deallocated after the VPC is deleted. The current workaround is to wait until the IP address is fully deallocated from the pool before retrying the deletion. Below command can be used to check allocations for a pool using CLI
|
|
102
|
+
|
|
103
|
+
```shell
|
|
104
|
+
aws ec2 get-ipam-pool-allocations --ipam-pool-id <ipam-pool-id>
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
Ref: https://docs.aws.amazon.com/cli/latest/reference/ec2/get-ipam-pool-allocations.html
|
|
95
108
|
|
|
96
109
|
```python
|
|
97
110
|
stack = Stack()
|
|
98
111
|
ipam = Ipam(self, "Ipam",
|
|
99
|
-
|
|
112
|
+
operating_regions=["us-west-1"]
|
|
100
113
|
)
|
|
101
114
|
ipam_public_pool = ipam.public_scope.add_pool("PublicPoolA",
|
|
102
115
|
address_family=AddressFamily.IP_V6,
|
|
@@ -129,8 +142,6 @@ VpcV2(self, "Vpc",
|
|
|
129
142
|
)
|
|
130
143
|
```
|
|
131
144
|
|
|
132
|
-
Since `VpcV2` does not create subnets automatically, users have full control over IP addresses allocation across subnets.
|
|
133
|
-
|
|
134
145
|
### Bring your own IPv6 addresses (BYOIP)
|
|
135
146
|
|
|
136
147
|
If you have your own IP address that you would like to use with EC2, you can set up an IPv6 pool via the AWS CLI, and use that pool ID in your application.
|
|
@@ -166,7 +177,8 @@ my_vpc = VpcV2(self, "Vpc",
|
|
|
166
177
|
|
|
167
178
|
## Routing
|
|
168
179
|
|
|
169
|
-
`RouteTable` is a new construct that allows for route tables to be customized in a variety of ways.
|
|
180
|
+
`RouteTable` is a new construct that allows for route tables to be customized in a variety of ways. Using this construct, a customized route table can be added to the subnets defined using `SubnetV2`.
|
|
181
|
+
For instance, the following example shows how a custom route table can be created and appended to a `SubnetV2`:
|
|
170
182
|
|
|
171
183
|
```python
|
|
172
184
|
my_vpc = VpcV2(self, "Vpc")
|
|
@@ -549,6 +561,7 @@ For more information, see [Enable VPC internet access using internet gateways](h
|
|
|
549
561
|
|
|
550
562
|
You can add an internet gateway to a VPC using `addInternetGateway` method. By default, this method creates a route in all Public Subnets with outbound destination set to `0.0.0.0` for IPv4 and `::0` for IPv6 enabled VPC.
|
|
551
563
|
Instead of using the default settings, you can configure a custom destination range by providing an optional input `destination` to the method.
|
|
564
|
+
In addition to the custom IP range, you can also choose to filter subnets where default routes should be created.
|
|
552
565
|
|
|
553
566
|
The code example below shows how to add an internet gateway with a custom outbound destination IP range:
|
|
554
567
|
|
|
@@ -568,6 +581,35 @@ my_vpc.add_internet_gateway(
|
|
|
568
581
|
)
|
|
569
582
|
```
|
|
570
583
|
|
|
584
|
+
The following code examples demonstrates how to add an internet gateway with a custom outbound destination IP range for specific subnets:
|
|
585
|
+
|
|
586
|
+
```python
|
|
587
|
+
stack = Stack()
|
|
588
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
589
|
+
|
|
590
|
+
my_subnet = SubnetV2(self, "Subnet",
|
|
591
|
+
vpc=my_vpc,
|
|
592
|
+
availability_zone="eu-west-2a",
|
|
593
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
594
|
+
subnet_type=SubnetType.PUBLIC
|
|
595
|
+
)
|
|
596
|
+
|
|
597
|
+
my_vpc.add_internet_gateway(
|
|
598
|
+
ipv4_destination="192.168.0.0/16",
|
|
599
|
+
subnets=[my_subnet]
|
|
600
|
+
)
|
|
601
|
+
```
|
|
602
|
+
|
|
603
|
+
```python
|
|
604
|
+
stack = Stack()
|
|
605
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
606
|
+
|
|
607
|
+
my_vpc.add_internet_gateway(
|
|
608
|
+
ipv4_destination="192.168.0.0/16",
|
|
609
|
+
subnets=[ec2.SubnetSelection(subnet_type=SubnetType.PRIVATE_WITH_EGRESS)]
|
|
610
|
+
)
|
|
611
|
+
```
|
|
612
|
+
|
|
571
613
|
## Importing an existing VPC
|
|
572
614
|
|
|
573
615
|
You can import an existing VPC and its subnets using the `VpcV2.fromVpcV2Attributes()` method or an individual subnet using `SubnetV2.fromSubnetV2Attributes()` method.
|
|
@@ -706,3 +748,190 @@ vpc = VpcV2(self, "VPC-integ-test-tag",
|
|
|
706
748
|
# Add custom tags if needed
|
|
707
749
|
Tags.of(vpc).add("Environment", "Production")
|
|
708
750
|
```
|
|
751
|
+
|
|
752
|
+
## Transit Gateway
|
|
753
|
+
|
|
754
|
+
The AWS Transit Gateway construct library allows you to create and configure Transit Gateway resources using AWS CDK.
|
|
755
|
+
|
|
756
|
+
See [AWS Transit Gateway Docs](docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) for more info.
|
|
757
|
+
|
|
758
|
+
### Overview
|
|
759
|
+
|
|
760
|
+
The Transit Gateway construct (`TransitGateway`) is the main entry point for creating and managing your Transit Gateway infrastructure. It provides methods to create route tables, attach VPCs, and configure cross-account access.
|
|
761
|
+
|
|
762
|
+
The Transit Gateway construct library provides four main constructs:
|
|
763
|
+
|
|
764
|
+
* `TransitGateway`: The central hub for your network connections
|
|
765
|
+
* `TransitGatewayRouteTable`: Manages routing between attached networks
|
|
766
|
+
* `TransitGatewayVpcAttachment`: Connects VPCs to the Transit Gateway
|
|
767
|
+
* `TransitGatewayRoute`: Defines routing rules within your Transit Gateway
|
|
768
|
+
|
|
769
|
+
### Basic Usage
|
|
770
|
+
|
|
771
|
+
To create a minimal deployable `TransitGateway`:
|
|
772
|
+
|
|
773
|
+
```python
|
|
774
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
775
|
+
```
|
|
776
|
+
|
|
777
|
+
### Default Transit Gateway Route Table
|
|
778
|
+
|
|
779
|
+
By default, `TransitGateway` is created with a default `TransitGatewayRouteTable`, for which automatic Associations and automatic Propagations are enabled.
|
|
780
|
+
|
|
781
|
+
> Note: When you create a default Transit Gateway in AWS Console, a default Transit Gateway Route Table is automatically created by AWS. However, when using the CDK Transit Gateway L2 construct, the underlying L1 construct is configured with `defaultRouteTableAssociation` and `defaultRouteTablePropagation` explicitly disabled. This ensures that AWS does not create the default route table, allowing the CDK to define a custom default route table instead.
|
|
782
|
+
>
|
|
783
|
+
> As a result, in the AWS Console, the **Default association route table** and **Default propagation route table** settings will appear as disabled. Despite this, the CDK still provides automatic association and propagation functionality through its internal implementation, which can be controlled using the `defaultRouteTableAssociation` and `defaultRouteTablePropagation` properties within the CDK.
|
|
784
|
+
|
|
785
|
+
You can disable the automatic Association/Propagation on the default `TransitGatewayRouteTable` via the `TransitGateway` properties. This will still create a default route table for you:
|
|
786
|
+
|
|
787
|
+
```python
|
|
788
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway",
|
|
789
|
+
default_route_table_association=False,
|
|
790
|
+
default_route_table_propagation=False
|
|
791
|
+
)
|
|
792
|
+
```
|
|
793
|
+
|
|
794
|
+
### Transit Gateway Route Table Management
|
|
795
|
+
|
|
796
|
+
Add additional Transit Gateway Route Tables using the `addRouteTable()` method:
|
|
797
|
+
|
|
798
|
+
```python
|
|
799
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
800
|
+
|
|
801
|
+
route_table = transit_gateway.add_route_table("CustomRouteTable")
|
|
802
|
+
```
|
|
803
|
+
|
|
804
|
+
### Attaching VPCs to the Transit Gateway
|
|
805
|
+
|
|
806
|
+
Currently only VPC to Transit Gateway attachments are supported.
|
|
807
|
+
|
|
808
|
+
Create an attachment from a VPC to the Transit Gateway using the `attachVpc()` method:
|
|
809
|
+
|
|
810
|
+
```python
|
|
811
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
812
|
+
subnet1 = SubnetV2(self, "Subnet",
|
|
813
|
+
vpc=my_vpc,
|
|
814
|
+
availability_zone="eu-west-2a",
|
|
815
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
816
|
+
subnet_type=SubnetType.PUBLIC
|
|
817
|
+
)
|
|
818
|
+
|
|
819
|
+
subnet2 = SubnetV2(self, "Subnet",
|
|
820
|
+
vpc=my_vpc,
|
|
821
|
+
availability_zone="eu-west-2a",
|
|
822
|
+
ipv4_cidr_block=IpCidr("10.0.1.0/24"),
|
|
823
|
+
subnet_type=SubnetType.PUBLIC
|
|
824
|
+
)
|
|
825
|
+
|
|
826
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
827
|
+
|
|
828
|
+
# Create a basic attachment
|
|
829
|
+
attachment = transit_gateway.attach_vpc("VpcAttachment",
|
|
830
|
+
vpc=my_vpc,
|
|
831
|
+
subnets=[subnet1, subnet2]
|
|
832
|
+
)
|
|
833
|
+
|
|
834
|
+
# Create an attachment with optional parameters
|
|
835
|
+
attachment_with_options = transit_gateway.attach_vpc("VpcAttachmentWithOptions",
|
|
836
|
+
vpc=my_vpc,
|
|
837
|
+
subnets=[subnet1],
|
|
838
|
+
vpc_attachment_options={
|
|
839
|
+
"dns_support": True,
|
|
840
|
+
"appliance_mode_support": True,
|
|
841
|
+
"ipv6_support": True,
|
|
842
|
+
"security_group_referencing_support": True
|
|
843
|
+
}
|
|
844
|
+
)
|
|
845
|
+
```
|
|
846
|
+
|
|
847
|
+
If you want to automatically associate and propagate routes with transit gateway route tables, you can pass the `associationRouteTable` and `propagationRouteTables` parameters. This will automatically create the necessary associations and propagations based on the provided route tables.
|
|
848
|
+
|
|
849
|
+
```python
|
|
850
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
851
|
+
subnet1 = SubnetV2(self, "Subnet",
|
|
852
|
+
vpc=my_vpc,
|
|
853
|
+
availability_zone="eu-west-2a",
|
|
854
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
855
|
+
subnet_type=SubnetType.PUBLIC
|
|
856
|
+
)
|
|
857
|
+
|
|
858
|
+
subnet2 = SubnetV2(self, "Subnet",
|
|
859
|
+
vpc=my_vpc,
|
|
860
|
+
availability_zone="eu-west-2a",
|
|
861
|
+
ipv4_cidr_block=IpCidr("10.0.1.0/24"),
|
|
862
|
+
subnet_type=SubnetType.PUBLIC
|
|
863
|
+
)
|
|
864
|
+
|
|
865
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
866
|
+
association_route_table = transit_gateway.add_route_table("AssociationRouteTable")
|
|
867
|
+
propagation_route_table1 = transit_gateway.add_route_table("PropagationRouteTable1")
|
|
868
|
+
propagation_route_table2 = transit_gateway.add_route_table("PropagationRouteTable2")
|
|
869
|
+
|
|
870
|
+
# Create an attachment with automatically created association + propagations
|
|
871
|
+
attachment_with_routes = transit_gateway.attach_vpc("VpcAttachment",
|
|
872
|
+
vpc=my_vpc,
|
|
873
|
+
subnets=[subnet1, subnet2],
|
|
874
|
+
association_route_table=association_route_table,
|
|
875
|
+
propagation_route_tables=[propagation_route_table1, propagation_route_table2]
|
|
876
|
+
)
|
|
877
|
+
```
|
|
878
|
+
|
|
879
|
+
In this example, the `associationRouteTable` is set to `associationRouteTable`, and `propagationRouteTables` is set to an array containing `propagationRouteTable1` and `propagationRouteTable2`. This triggers the automatic creation of route table associations and route propagations between the Transit Gateway and the specified route tables.
|
|
880
|
+
|
|
881
|
+
### Adding static routes to the route table
|
|
882
|
+
|
|
883
|
+
Add static routes using either the `addRoute()` method to add an active route or `addBlackholeRoute()` to add a blackhole route:
|
|
884
|
+
|
|
885
|
+
```python
|
|
886
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
887
|
+
route_table = transit_gateway.add_route_table("CustomRouteTable")
|
|
888
|
+
|
|
889
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
890
|
+
subnet = SubnetV2(self, "Subnet",
|
|
891
|
+
vpc=my_vpc,
|
|
892
|
+
availability_zone="eu-west-2a",
|
|
893
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
894
|
+
subnet_type=SubnetType.PUBLIC
|
|
895
|
+
)
|
|
896
|
+
|
|
897
|
+
attachment = transit_gateway.attach_vpc("VpcAttachment",
|
|
898
|
+
vpc=my_vpc,
|
|
899
|
+
subnets=[subnet]
|
|
900
|
+
)
|
|
901
|
+
|
|
902
|
+
# Add a static route to direct traffic
|
|
903
|
+
route_table.add_route("StaticRoute", attachment, "10.0.0.0/16")
|
|
904
|
+
|
|
905
|
+
# Block unwanted traffic with a blackhole route
|
|
906
|
+
route_table.add_blackhole_route("BlackholeRoute", "172.16.0.0/16")
|
|
907
|
+
```
|
|
908
|
+
|
|
909
|
+
### Route Table Associations and Propagations
|
|
910
|
+
|
|
911
|
+
Configure route table associations and enable route propagation:
|
|
912
|
+
|
|
913
|
+
```python
|
|
914
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
915
|
+
route_table = transit_gateway.add_route_table("CustomRouteTable")
|
|
916
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
917
|
+
subnet = SubnetV2(self, "Subnet",
|
|
918
|
+
vpc=my_vpc,
|
|
919
|
+
availability_zone="eu-west-2a",
|
|
920
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
921
|
+
subnet_type=SubnetType.PUBLIC
|
|
922
|
+
)
|
|
923
|
+
attachment = transit_gateway.attach_vpc("VpcAttachment",
|
|
924
|
+
vpc=my_vpc,
|
|
925
|
+
subnets=[subnet]
|
|
926
|
+
)
|
|
927
|
+
|
|
928
|
+
# Associate an attachment with a route table
|
|
929
|
+
route_table.add_association("Association", attachment)
|
|
930
|
+
|
|
931
|
+
# Enable route propagation for an attachment
|
|
932
|
+
route_table.enable_propagation("Propagation", attachment)
|
|
933
|
+
```
|
|
934
|
+
|
|
935
|
+
**Associations** — The linking of a Transit Gateway attachment to a specific route table, which determines which routes that attachment will use for routing decisions.
|
|
936
|
+
|
|
937
|
+
**Propagation** — The automatic advertisement of routes from an attachment to a route table, allowing the route table to learn about available network destinations.
|
|
@@ -3,13 +3,13 @@
|
|
|
3
3
|
<!--BEGIN STABILITY BANNER-->---
|
|
4
4
|
|
|
5
5
|
|
|
6
|
-

|
|
7
7
|
|
|
8
|
-
> The APIs of higher level constructs in this module are
|
|
9
|
-
>
|
|
10
|
-
> not subject to
|
|
11
|
-
> announced in
|
|
12
|
-
> your source code when upgrading to a newer version of this package.
|
|
8
|
+
> The APIs of higher level constructs in this module are in **developer preview** before they
|
|
9
|
+
> become stable. We will only make breaking changes to address unforeseen API issues. Therefore,
|
|
10
|
+
> these APIs are not subject to [Semantic Versioning](https://semver.org/), and breaking changes
|
|
11
|
+
> will be announced in release notes. This means that while you may use them, you may need to
|
|
12
|
+
> update your source code when upgrading to a newer version of this package.
|
|
13
13
|
|
|
14
14
|
---
|
|
15
15
|
<!--END STABILITY BANNER-->
|
|
@@ -20,7 +20,10 @@
|
|
|
20
20
|
on the VPC being created. `VpcV2` implements the existing [`IVpc`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.IVpc.html), therefore,
|
|
21
21
|
`VpcV2` is compatible with other constructs that accepts `IVpc` (e.g. [`ApplicationLoadBalancer`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.ApplicationLoadBalancer.html#construct-props)).
|
|
22
22
|
|
|
23
|
-
|
|
23
|
+
`VpcV2` supports the addition of both primary and secondary addresses. The primary address must be an IPv4 address, which can be specified as a CIDR string or assigned from an IPAM pool. Secondary addresses can be either IPv4 or IPv6.
|
|
24
|
+
By default, `VpcV2` assigns `10.0.0.0/16` as the primary CIDR if no other CIDR is specified.
|
|
25
|
+
|
|
26
|
+
Below is an example of creating a VPC with both IPv4 and IPv6 support:
|
|
24
27
|
|
|
25
28
|
```python
|
|
26
29
|
stack = Stack()
|
|
@@ -38,6 +41,7 @@ VpcV2(self, "Vpc",
|
|
|
38
41
|
|
|
39
42
|
`SubnetV2` is a re-write of the [`ec2.Subnet`](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ec2.Subnet.html) construct.
|
|
40
43
|
This new construct can be used to add subnets to a `VpcV2` instance:
|
|
44
|
+
Note: When defining a subnet with `SubnetV2`, CDK automatically creates a new route table, unless a route table is explicitly provided as an input to the construct.
|
|
41
45
|
|
|
42
46
|
```python
|
|
43
47
|
stack = Stack()
|
|
@@ -56,16 +60,25 @@ SubnetV2(self, "subnetA",
|
|
|
56
60
|
)
|
|
57
61
|
```
|
|
58
62
|
|
|
63
|
+
Since `VpcV2` does not create subnets automatically, users have full control over IP addresses allocation across subnets.
|
|
64
|
+
|
|
59
65
|
## IP Addresses Management
|
|
60
66
|
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
67
|
+
Additional CIDRs can be added to the VPC via the `secondaryAddressBlocks` property.
|
|
68
|
+
The following example illustrates the options of defining these secondary address blocks using `IPAM`:
|
|
69
|
+
|
|
70
|
+
Note: There’s currently an issue with IPAM pool deletion that may affect the `cdk --destroy` command. This is because IPAM takes time to detect when the IP address pool has been deallocated after the VPC is deleted. The current workaround is to wait until the IP address is fully deallocated from the pool before retrying the deletion. Below command can be used to check allocations for a pool using CLI
|
|
71
|
+
|
|
72
|
+
```shell
|
|
73
|
+
aws ec2 get-ipam-pool-allocations --ipam-pool-id <ipam-pool-id>
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
Ref: https://docs.aws.amazon.com/cli/latest/reference/ec2/get-ipam-pool-allocations.html
|
|
64
77
|
|
|
65
78
|
```python
|
|
66
79
|
stack = Stack()
|
|
67
80
|
ipam = Ipam(self, "Ipam",
|
|
68
|
-
|
|
81
|
+
operating_regions=["us-west-1"]
|
|
69
82
|
)
|
|
70
83
|
ipam_public_pool = ipam.public_scope.add_pool("PublicPoolA",
|
|
71
84
|
address_family=AddressFamily.IP_V6,
|
|
@@ -98,8 +111,6 @@ VpcV2(self, "Vpc",
|
|
|
98
111
|
)
|
|
99
112
|
```
|
|
100
113
|
|
|
101
|
-
Since `VpcV2` does not create subnets automatically, users have full control over IP addresses allocation across subnets.
|
|
102
|
-
|
|
103
114
|
### Bring your own IPv6 addresses (BYOIP)
|
|
104
115
|
|
|
105
116
|
If you have your own IP address that you would like to use with EC2, you can set up an IPv6 pool via the AWS CLI, and use that pool ID in your application.
|
|
@@ -135,7 +146,8 @@ my_vpc = VpcV2(self, "Vpc",
|
|
|
135
146
|
|
|
136
147
|
## Routing
|
|
137
148
|
|
|
138
|
-
`RouteTable` is a new construct that allows for route tables to be customized in a variety of ways.
|
|
149
|
+
`RouteTable` is a new construct that allows for route tables to be customized in a variety of ways. Using this construct, a customized route table can be added to the subnets defined using `SubnetV2`.
|
|
150
|
+
For instance, the following example shows how a custom route table can be created and appended to a `SubnetV2`:
|
|
139
151
|
|
|
140
152
|
```python
|
|
141
153
|
my_vpc = VpcV2(self, "Vpc")
|
|
@@ -518,6 +530,7 @@ For more information, see [Enable VPC internet access using internet gateways](h
|
|
|
518
530
|
|
|
519
531
|
You can add an internet gateway to a VPC using `addInternetGateway` method. By default, this method creates a route in all Public Subnets with outbound destination set to `0.0.0.0` for IPv4 and `::0` for IPv6 enabled VPC.
|
|
520
532
|
Instead of using the default settings, you can configure a custom destination range by providing an optional input `destination` to the method.
|
|
533
|
+
In addition to the custom IP range, you can also choose to filter subnets where default routes should be created.
|
|
521
534
|
|
|
522
535
|
The code example below shows how to add an internet gateway with a custom outbound destination IP range:
|
|
523
536
|
|
|
@@ -537,6 +550,35 @@ my_vpc.add_internet_gateway(
|
|
|
537
550
|
)
|
|
538
551
|
```
|
|
539
552
|
|
|
553
|
+
The following code examples demonstrates how to add an internet gateway with a custom outbound destination IP range for specific subnets:
|
|
554
|
+
|
|
555
|
+
```python
|
|
556
|
+
stack = Stack()
|
|
557
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
558
|
+
|
|
559
|
+
my_subnet = SubnetV2(self, "Subnet",
|
|
560
|
+
vpc=my_vpc,
|
|
561
|
+
availability_zone="eu-west-2a",
|
|
562
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
563
|
+
subnet_type=SubnetType.PUBLIC
|
|
564
|
+
)
|
|
565
|
+
|
|
566
|
+
my_vpc.add_internet_gateway(
|
|
567
|
+
ipv4_destination="192.168.0.0/16",
|
|
568
|
+
subnets=[my_subnet]
|
|
569
|
+
)
|
|
570
|
+
```
|
|
571
|
+
|
|
572
|
+
```python
|
|
573
|
+
stack = Stack()
|
|
574
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
575
|
+
|
|
576
|
+
my_vpc.add_internet_gateway(
|
|
577
|
+
ipv4_destination="192.168.0.0/16",
|
|
578
|
+
subnets=[ec2.SubnetSelection(subnet_type=SubnetType.PRIVATE_WITH_EGRESS)]
|
|
579
|
+
)
|
|
580
|
+
```
|
|
581
|
+
|
|
540
582
|
## Importing an existing VPC
|
|
541
583
|
|
|
542
584
|
You can import an existing VPC and its subnets using the `VpcV2.fromVpcV2Attributes()` method or an individual subnet using `SubnetV2.fromSubnetV2Attributes()` method.
|
|
@@ -675,3 +717,190 @@ vpc = VpcV2(self, "VPC-integ-test-tag",
|
|
|
675
717
|
# Add custom tags if needed
|
|
676
718
|
Tags.of(vpc).add("Environment", "Production")
|
|
677
719
|
```
|
|
720
|
+
|
|
721
|
+
## Transit Gateway
|
|
722
|
+
|
|
723
|
+
The AWS Transit Gateway construct library allows you to create and configure Transit Gateway resources using AWS CDK.
|
|
724
|
+
|
|
725
|
+
See [AWS Transit Gateway Docs](docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) for more info.
|
|
726
|
+
|
|
727
|
+
### Overview
|
|
728
|
+
|
|
729
|
+
The Transit Gateway construct (`TransitGateway`) is the main entry point for creating and managing your Transit Gateway infrastructure. It provides methods to create route tables, attach VPCs, and configure cross-account access.
|
|
730
|
+
|
|
731
|
+
The Transit Gateway construct library provides four main constructs:
|
|
732
|
+
|
|
733
|
+
* `TransitGateway`: The central hub for your network connections
|
|
734
|
+
* `TransitGatewayRouteTable`: Manages routing between attached networks
|
|
735
|
+
* `TransitGatewayVpcAttachment`: Connects VPCs to the Transit Gateway
|
|
736
|
+
* `TransitGatewayRoute`: Defines routing rules within your Transit Gateway
|
|
737
|
+
|
|
738
|
+
### Basic Usage
|
|
739
|
+
|
|
740
|
+
To create a minimal deployable `TransitGateway`:
|
|
741
|
+
|
|
742
|
+
```python
|
|
743
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
744
|
+
```
|
|
745
|
+
|
|
746
|
+
### Default Transit Gateway Route Table
|
|
747
|
+
|
|
748
|
+
By default, `TransitGateway` is created with a default `TransitGatewayRouteTable`, for which automatic Associations and automatic Propagations are enabled.
|
|
749
|
+
|
|
750
|
+
> Note: When you create a default Transit Gateway in AWS Console, a default Transit Gateway Route Table is automatically created by AWS. However, when using the CDK Transit Gateway L2 construct, the underlying L1 construct is configured with `defaultRouteTableAssociation` and `defaultRouteTablePropagation` explicitly disabled. This ensures that AWS does not create the default route table, allowing the CDK to define a custom default route table instead.
|
|
751
|
+
>
|
|
752
|
+
> As a result, in the AWS Console, the **Default association route table** and **Default propagation route table** settings will appear as disabled. Despite this, the CDK still provides automatic association and propagation functionality through its internal implementation, which can be controlled using the `defaultRouteTableAssociation` and `defaultRouteTablePropagation` properties within the CDK.
|
|
753
|
+
|
|
754
|
+
You can disable the automatic Association/Propagation on the default `TransitGatewayRouteTable` via the `TransitGateway` properties. This will still create a default route table for you:
|
|
755
|
+
|
|
756
|
+
```python
|
|
757
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway",
|
|
758
|
+
default_route_table_association=False,
|
|
759
|
+
default_route_table_propagation=False
|
|
760
|
+
)
|
|
761
|
+
```
|
|
762
|
+
|
|
763
|
+
### Transit Gateway Route Table Management
|
|
764
|
+
|
|
765
|
+
Add additional Transit Gateway Route Tables using the `addRouteTable()` method:
|
|
766
|
+
|
|
767
|
+
```python
|
|
768
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
769
|
+
|
|
770
|
+
route_table = transit_gateway.add_route_table("CustomRouteTable")
|
|
771
|
+
```
|
|
772
|
+
|
|
773
|
+
### Attaching VPCs to the Transit Gateway
|
|
774
|
+
|
|
775
|
+
Currently only VPC to Transit Gateway attachments are supported.
|
|
776
|
+
|
|
777
|
+
Create an attachment from a VPC to the Transit Gateway using the `attachVpc()` method:
|
|
778
|
+
|
|
779
|
+
```python
|
|
780
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
781
|
+
subnet1 = SubnetV2(self, "Subnet",
|
|
782
|
+
vpc=my_vpc,
|
|
783
|
+
availability_zone="eu-west-2a",
|
|
784
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
785
|
+
subnet_type=SubnetType.PUBLIC
|
|
786
|
+
)
|
|
787
|
+
|
|
788
|
+
subnet2 = SubnetV2(self, "Subnet",
|
|
789
|
+
vpc=my_vpc,
|
|
790
|
+
availability_zone="eu-west-2a",
|
|
791
|
+
ipv4_cidr_block=IpCidr("10.0.1.0/24"),
|
|
792
|
+
subnet_type=SubnetType.PUBLIC
|
|
793
|
+
)
|
|
794
|
+
|
|
795
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
796
|
+
|
|
797
|
+
# Create a basic attachment
|
|
798
|
+
attachment = transit_gateway.attach_vpc("VpcAttachment",
|
|
799
|
+
vpc=my_vpc,
|
|
800
|
+
subnets=[subnet1, subnet2]
|
|
801
|
+
)
|
|
802
|
+
|
|
803
|
+
# Create an attachment with optional parameters
|
|
804
|
+
attachment_with_options = transit_gateway.attach_vpc("VpcAttachmentWithOptions",
|
|
805
|
+
vpc=my_vpc,
|
|
806
|
+
subnets=[subnet1],
|
|
807
|
+
vpc_attachment_options={
|
|
808
|
+
"dns_support": True,
|
|
809
|
+
"appliance_mode_support": True,
|
|
810
|
+
"ipv6_support": True,
|
|
811
|
+
"security_group_referencing_support": True
|
|
812
|
+
}
|
|
813
|
+
)
|
|
814
|
+
```
|
|
815
|
+
|
|
816
|
+
If you want to automatically associate and propagate routes with transit gateway route tables, you can pass the `associationRouteTable` and `propagationRouteTables` parameters. This will automatically create the necessary associations and propagations based on the provided route tables.
|
|
817
|
+
|
|
818
|
+
```python
|
|
819
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
820
|
+
subnet1 = SubnetV2(self, "Subnet",
|
|
821
|
+
vpc=my_vpc,
|
|
822
|
+
availability_zone="eu-west-2a",
|
|
823
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
824
|
+
subnet_type=SubnetType.PUBLIC
|
|
825
|
+
)
|
|
826
|
+
|
|
827
|
+
subnet2 = SubnetV2(self, "Subnet",
|
|
828
|
+
vpc=my_vpc,
|
|
829
|
+
availability_zone="eu-west-2a",
|
|
830
|
+
ipv4_cidr_block=IpCidr("10.0.1.0/24"),
|
|
831
|
+
subnet_type=SubnetType.PUBLIC
|
|
832
|
+
)
|
|
833
|
+
|
|
834
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
835
|
+
association_route_table = transit_gateway.add_route_table("AssociationRouteTable")
|
|
836
|
+
propagation_route_table1 = transit_gateway.add_route_table("PropagationRouteTable1")
|
|
837
|
+
propagation_route_table2 = transit_gateway.add_route_table("PropagationRouteTable2")
|
|
838
|
+
|
|
839
|
+
# Create an attachment with automatically created association + propagations
|
|
840
|
+
attachment_with_routes = transit_gateway.attach_vpc("VpcAttachment",
|
|
841
|
+
vpc=my_vpc,
|
|
842
|
+
subnets=[subnet1, subnet2],
|
|
843
|
+
association_route_table=association_route_table,
|
|
844
|
+
propagation_route_tables=[propagation_route_table1, propagation_route_table2]
|
|
845
|
+
)
|
|
846
|
+
```
|
|
847
|
+
|
|
848
|
+
In this example, the `associationRouteTable` is set to `associationRouteTable`, and `propagationRouteTables` is set to an array containing `propagationRouteTable1` and `propagationRouteTable2`. This triggers the automatic creation of route table associations and route propagations between the Transit Gateway and the specified route tables.
|
|
849
|
+
|
|
850
|
+
### Adding static routes to the route table
|
|
851
|
+
|
|
852
|
+
Add static routes using either the `addRoute()` method to add an active route or `addBlackholeRoute()` to add a blackhole route:
|
|
853
|
+
|
|
854
|
+
```python
|
|
855
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
856
|
+
route_table = transit_gateway.add_route_table("CustomRouteTable")
|
|
857
|
+
|
|
858
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
859
|
+
subnet = SubnetV2(self, "Subnet",
|
|
860
|
+
vpc=my_vpc,
|
|
861
|
+
availability_zone="eu-west-2a",
|
|
862
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
863
|
+
subnet_type=SubnetType.PUBLIC
|
|
864
|
+
)
|
|
865
|
+
|
|
866
|
+
attachment = transit_gateway.attach_vpc("VpcAttachment",
|
|
867
|
+
vpc=my_vpc,
|
|
868
|
+
subnets=[subnet]
|
|
869
|
+
)
|
|
870
|
+
|
|
871
|
+
# Add a static route to direct traffic
|
|
872
|
+
route_table.add_route("StaticRoute", attachment, "10.0.0.0/16")
|
|
873
|
+
|
|
874
|
+
# Block unwanted traffic with a blackhole route
|
|
875
|
+
route_table.add_blackhole_route("BlackholeRoute", "172.16.0.0/16")
|
|
876
|
+
```
|
|
877
|
+
|
|
878
|
+
### Route Table Associations and Propagations
|
|
879
|
+
|
|
880
|
+
Configure route table associations and enable route propagation:
|
|
881
|
+
|
|
882
|
+
```python
|
|
883
|
+
transit_gateway = TransitGateway(self, "MyTransitGateway")
|
|
884
|
+
route_table = transit_gateway.add_route_table("CustomRouteTable")
|
|
885
|
+
my_vpc = VpcV2(self, "Vpc")
|
|
886
|
+
subnet = SubnetV2(self, "Subnet",
|
|
887
|
+
vpc=my_vpc,
|
|
888
|
+
availability_zone="eu-west-2a",
|
|
889
|
+
ipv4_cidr_block=IpCidr("10.0.0.0/24"),
|
|
890
|
+
subnet_type=SubnetType.PUBLIC
|
|
891
|
+
)
|
|
892
|
+
attachment = transit_gateway.attach_vpc("VpcAttachment",
|
|
893
|
+
vpc=my_vpc,
|
|
894
|
+
subnets=[subnet]
|
|
895
|
+
)
|
|
896
|
+
|
|
897
|
+
# Associate an attachment with a route table
|
|
898
|
+
route_table.add_association("Association", attachment)
|
|
899
|
+
|
|
900
|
+
# Enable route propagation for an attachment
|
|
901
|
+
route_table.enable_propagation("Propagation", attachment)
|
|
902
|
+
```
|
|
903
|
+
|
|
904
|
+
**Associations** — The linking of a Transit Gateway attachment to a specific route table, which determines which routes that attachment will use for routing decisions.
|
|
905
|
+
|
|
906
|
+
**Propagation** — The automatic advertisement of routes from an attachment to a route table, allowing the route table to learn about available network destinations.
|