Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tracking: VPC #30762

Open
shikha372 opened this issue Jul 5, 2024 · 0 comments
Open

Tracking: VPC #30762

shikha372 opened this issue Jul 5, 2024 · 0 comments
Assignees
@shikha372 @Leo10Gama
Labels
management/tracking Issues that track a subject or multiple issues p2

Comments

@shikha372
Copy link
Contributor

shikha372 commented Jul 5, 2024 •
edited
Loading

Overview

Full Control VPC provides feasibility to add custom route table and subnets to your network with the support of creating your VPC with Ipv6 Addresses.

The main components of this VPC construct is:

  • Add Secondary Address to the VPC
  • IP address allocation using AWS IPAM
  • Subnets With Custom IP range
  • Custom Routing Support with Gateways

Link to the service’s CDK Construct Library API reference page.

https://github.com/aws/aws-cdk-rfcs/blob/57fd92a7f20e242b96885264c12567493f5e867f/text/0507-subnets.md

Maturity: CloudFormation Resources Only

Experimental

Implementation

###Features and Support

VPC

Done Item Needed for Graduation Link to issue or docs
✔️ Support for Secondary Address Ipv4 ✔️
✔️ Support for Secondary Address Ipv6 ✔️
✔️ Provision IP address using IPAM IPv4 ✔️
✔️ Provision IP address using IPAM IPv6(Amazon-Owned) Addresses ✔️
✔️ Validation of Secondary Ipv4 address per RFC1918 range ✔️
Create VPC using BYOIP Ipv6
✔️ Import existing VPC to this construct ✔️
Add Tagging capabilites to VPC and its components

Subnet

Done Item Needed for Graduation Link to issue or docs
✔️ Support for custom Ipv4 range in subnet ✔️
✔️ Support for custom Ipv6 range in subnet ✔️
✔️ (Public Subnet) Construct Implementation of Nat and Internet Gateway ✔️
✔️ Validation for overlapping IP ranges ✔️
✔️ Validation for IP range lies within VPC range ✔️
Support for custom Ipv6 range(BYOIP) in subnet
Support for direct IPAM allocation in subnet

Routing

Done Item Needed for Graduation Link to issue or docs
✔️ Route L2 construct ✔️
✔️ RouteTable L2 construct ✔️
✔️ Egress-only internet gateway L2 construct ✔️
✔️ VPN gateway L2 construct ✔️
✔️ Internet gateway L2 construct ✔️
✔️ NAT gateway L2 construct ✔️
✔️ VPC peering connection L2 construct ✔️
Network interface L2 construct
✔️ Compatability with existing VPC endpoint constructs ✔️
Transit gateway L2 construct
Carrier gateway L2 construct

Issue list
@shikha372 shikha372 added the management/tracking Issues that track a subject or multiple issues label Jul 5, 2024
@shikha372 shikha372 mentioned this issue Jul 5, 2024
Merged
1 task
This was referenced Jul 8, 2024
Closed
Closed
@shikha372 shikha372 changed the title Tracking: VPC [WIP] Tracking: VPC Jul 8, 2024
@github-actions github-actions bot mentioned this issue Aug 1, 2024
Closed
mergify bot pushed a commit that referenced this issue Aug 7, 2024
@shikha372
feat(vpc): support custom route and subnet (#30538)
e17fdd7 
### Issue # (if applicable)

Closes [RFC#507](https://github.com/aws/aws-cdk-rfcs/blob/57fd92a7f20e242b96885264c12567493f5e867f/text/0507-subnets.md).

Issue#[5927](#5927)

Tracking Ticket #30762

### Reason for this change

This PR implements below RFC for Full Control VPC configuration
Implementing RFC [Full Control VPC](https://github.com/aws/aws-cdk-rfcs/blob/57fd92a7f20e242b96885264c12567493f5e867f/text/0507-subnets.md)


### Description of changes



Experimental API for VPC
Lifecycle Doc: https://github.com/cdklabs/team-internal/blob/main/docs/construct-library-lifecycle.md

- Introduced a new alpha module for VPCV2
- Both new class VPCV2 and SubnetV2 implement IVPC and ISubnet for compatibility with other constructs
- Introduced a new IPAM class to support IP address alllocation through IPAM pool.
- Validations of IP ranges assigned to subnet.
- L2 class(Route) to define custom routes under the subnet
- L2s for gateways like Egress only IGW and NATGW.

### Next Steps: 
Iterate on the API with the feedback from community and team to make it ergonomic.
Close on the features listed in [tracking ticket](#30762)  

Will follow the exit criteria for this experimental API as outlined in below doc: 
https://github.com/cdklabs/team-internal/blob/main/docs/construct-library-lifecycle.md

### Description of how you validated changes

Added unit tests with current coverage ~70% 

Added integration tests for subnet, vpc and routing features.




### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@shikha372 shikha372 mentioned this issue Aug 29, 2024
Merged
1 task
mergify bot pushed a commit that referenced this issue Sep 12, 2024
@shikha372
feat(vpcv2): implementation of add gateway method (#31224)
4b90bfc 
### Issue # (if applicable)

Tracking  #[30762](#30762).

### Reason for this change

implementing below methods for vpcV2.
`routeTable.addroute(destination, target)`:   Adds a new route to the existing route table of the subnet.

`vpc.enableVpnGatewayV2()`:  added a new function for the customer to add VPNGateway to their VPC. In the options, user can specify list of subnets for VPNRoutePropogation. This is similar to previous implementation, only difference is with VPNGateway L2, it is now creating VPNGatewayV2 which implements IRouteTarget and hence can be used a destination to be set up in route tables.

`addInternetGateway` : adds internetGW to the VPC. 
**Default behaviour:**  add default route with destination set to ‘0.0.0.0’ and ‘::0’(in case of subnet with ipv6). Also a check in place to verify SubnetType is set to public as IGW is meant to be added to public subnets.

`addNatGateway`:  NatGateways are subnet specific and are usually associated with PRIVATE_WITH_EGRESS or PUBLIC subnet. Also, one can’t attach NGW(Public) to subnet if VPC doesn’t have an IGW attached to it. This is validated in method implementation to prevent runtime deployment error.

**No default behaviour** for the routes, it takes in the single subnet option and associates a NATGW with it. 

`vpc.addEgressOnlyInternetGateway()`: Egress Only internet GW are meant for outbound ipv6 traffic which can be custom or all ipv6(::/0).

**Default behaviour:** Associates a EIGW to the vpc and takes optional input for subnets to define a default route in associated route Table, if a destination is not provided, then it is defined as all outbound ipv6 in subnet’s route table.

**Additional changes:**
-> Modify Readme
-> Separate ipam related Tests

### Use Case


Allows user to define gateways in their vpc with a simple method and an optional default route setup on provided subnets.


Note: Breaking change since previously VPNGateway was released under route class,  we’ve modified it to VPNGatewayV2.
`vpc.enableVpnGateway` is marked as deprecated in vpcv2 base class.

### Description of how you validated changes

Added unit tests and integration tests.

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This was referenced Oct 10, 2024
Merged
Merged
mergify bot added a commit that referenced this issue Oct 29, 2024
@mergify
feat(ec2-alpha): adding imports for SubnetV2 and VpcV2(WIP) (#31765)
d108a80 
### Issue # (if applicable)

Tracking #30762.

### Reason for this change

Allow users to define imports for a VPC or subnet defined outside current stack definition.

### Description of changes

- Added new methods under VpcV2 and Subnet
`VpcV2.fromVpcV2Attributes()` and `SubnetV2.fromSubnetV2Attributes()` 

- Added new L2 for VPCCidrBlock to allow import of secondary addresses.
`VPCCidrBlock`

- Added new integration test and unit test file to check import related functionality.

- Updated Readme.

- Fixed an earlier issue with subnet range check, fixed to include IPAM defined IPv4 address as well

### Description of how you validated changes

Deployed and tested for below scenarios in account: 

1. Import a VPC with primary IPv4 
2. Import a subnet with primary IPv4 
3. Import a VPC with multiple secondary IPv4 
4. Import a VPC with Amazon provided IPV6 
5. Import a VPC with Ipam provided IPv6/IPv4 
7. Import subnet individually using fromSubnetV2attributes
8. Imported different type of multiple subnets
9. Add gateways/endpoint to imported vpc

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)



BREAKING CHANGE: The new `VpcCidrBlock` L2 construct replaces `CfnVPCCidrBlock`. This change alters the logical ID of `AWS::EC2::VPCCidrBlock` resources in CloudFormation templates. Existing deployments will see errors like `CIDR range conflicts with x.xx.xx.xx/xx with association ID vpc-cidr-assoc-ABCD`. To resolve this, you must recreate your existing stacks to use the new module.

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@nick-kang nick-kang mentioned this issue Nov 7, 2024
Open
2 tasks
mergify bot pushed a commit that referenced this issue Nov 21, 2024
@1kaileychen
feat(vpcv2): vpc peering connection construct (#31645)
e1195f9 
### Issue # (if applicable)

Contributes to closing [RFC#507](https://github.com/aws/aws-cdk-rfcs/blob/57fd92a7f20e242b96885264c12567493f5e867f/text/0507-subnets.md?plain=1#L252)

Tracking: #30762

### Reason for this change

This PR implements a new L2 construct to setup VPC Peering Connection.

### Description of changes

- L2 class(VPCPeeringConnection)
- Function `validateVpcCidrOverlap` to ensure IPv4 CIDR blocks don't overlap for subnets in the VPCs

### Description of how you validated changes

- Unit tests to test combination of accounts (cross account & cross region, default same account & same region)
- Unit tests to see simulate when CIDR blocks overlap
  - Primary CIDR block overlaps
  - Secondary CIDR block overlaps
  - Primary and secondary CIDR block overlaps
- Integration test for peering connection

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@shikha372 shikha372

@Leo10Gama Leo10Gama

Labels
management/tracking Issues that track a subject or multiple issues p2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@shikha372 @Leo10Gama @ashishdhingra