├── .github └── PULL_REQUEST_TEMPLATE.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE ├── README.md ├── Transit-Gateway-Overview.png ├── Transit-Gateway-setup.png ├── VPC-setup.png └── tgw-lab.yaml /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | *Issue #, if available:* 2 | 3 | *Description of changes:* 4 | 5 | 6 | By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice. 7 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | ## Code of Conduct 2 | This project has adopted the [Amazon Open Source Code of Conduct](https://aws.github.io/code-of-conduct). 3 | For more information see the [Code of Conduct FAQ](https://aws.github.io/code-of-conduct-faq) or contact 4 | opensource-codeofconduct@amazon.com with any additional questions or comments. 5 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing Guidelines 2 | 3 | Thank you for your interest in contributing to our project. Whether it's a bug report, new feature, correction, or additional 4 | documentation, we greatly value feedback and contributions from our community. 5 | 6 | Please read through this document before submitting any issues or pull requests to ensure we have all the necessary 7 | information to effectively respond to your bug report or contribution. 8 | 9 | 10 | ## Reporting Bugs/Feature Requests 11 | 12 | We welcome you to use the GitHub issue tracker to report bugs or suggest features. 13 | 14 | When filing an issue, please check [existing open](https://github.com/aws-samples/aws-transit-gateway-routing-lab/issues), or [recently closed](https://github.com/aws-samples/aws-transit-gateway-routing-lab/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aclosed%20), issues to make sure somebody else hasn't already 15 | reported the issue. Please try to include as much information as you can. Details like these are incredibly useful: 16 | 17 | * A reproducible test case or series of steps 18 | * The version of our code being used 19 | * Any modifications you've made relevant to the bug 20 | * Anything unusual about your environment or deployment 21 | 22 | 23 | ## Contributing via Pull Requests 24 | Contributions via pull requests are much appreciated. Before sending us a pull request, please ensure that: 25 | 26 | 1. You are working against the latest source on the *master* branch. 27 | 2. You check existing open, and recently merged, pull requests to make sure someone else hasn't addressed the problem already. 28 | 3. You open an issue to discuss any significant work - we would hate for your time to be wasted. 29 | 30 | To send us a pull request, please: 31 | 32 | 1. Fork the repository. 33 | 2. Modify the source; please focus on the specific change you are contributing. If you also reformat all the code, it will be hard for us to focus on your change. 34 | 3. Ensure local tests pass. 35 | 4. Commit to your fork using clear commit messages. 36 | 5. Send us a pull request, answering any default questions in the pull request interface. 37 | 6. Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation. 38 | 39 | GitHub provides additional document on [forking a repository](https://help.github.com/articles/fork-a-repo/) and 40 | [creating a pull request](https://help.github.com/articles/creating-a-pull-request/). 41 | 42 | 43 | ## Finding contributions to work on 44 | Looking at the existing issues is a great way to find something to contribute on. As our projects, by default, use the default GitHub issue labels (enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at any ['help wanted'](https://github.com/aws-samples/aws-transit-gateway-routing-lab/labels/help%20wanted) issues is a great place to start. 45 | 46 | 47 | ## Code of Conduct 48 | This project has adopted the [Amazon Open Source Code of Conduct](https://aws.github.io/code-of-conduct). 49 | For more information see the [Code of Conduct FAQ](https://aws.github.io/code-of-conduct-faq) or contact 50 | opensource-codeofconduct@amazon.com with any additional questions or comments. 51 | 52 | 53 | ## Security issue notifications 54 | If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/). Please do **not** create a public github issue. 55 | 56 | 57 | ## Licensing 58 | 59 | See the [LICENSE](https://github.com/aws-samples/aws-transit-gateway-routing-lab/blob/master/LICENSE) file for our project's licensing. We will ask you to confirm the licensing of your contribution. 60 | 61 | We may ask you to sign a [Contributor License Agreement (CLA)](http://en.wikipedia.org/wiki/Contributor_License_Agreement) for larger changes. 62 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved. 2 | 3 | Permission is hereby granted, free of charge, to any person obtaining a copy of 4 | this software and associated documentation files (the "Software"), to deal in 5 | the Software without restriction, including without limitation the rights to 6 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of 7 | the Software, and to permit persons to whom the Software is furnished to do so. 8 | 9 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 10 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 11 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 12 | COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 13 | IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 14 | CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 15 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## AWS Transit Gateway Routing Lab 2 | 3 | This is a short lab covering [Transit Gateway](https://aws.amazon.com/transit-gateway/). You'll use Transit Gateway to link four VPCs together in a few different ways to see how the various components within the service can provide you with flexible ways of performing networking within AWS. 4 | 5 | This lab should take about an hour to complete. 6 | 7 | ## License Summary 8 | 9 | This sample code is made available under the MIT-0 license. See the LICENSE file. 10 | 11 | ## Requirements 12 | You will need an AWS account to run this lab. You will need a tool that allows you to SSH to EC2 instances in order to test connectivity between your VPCs. You must also have an existing SSH key pair in the region you are going to operate in. 13 | 14 | This lab will result in charges to your AWS account. The instances launced are all t3.nano so it won't break the bank but there are still some costs. There are also charges associated with Transit Gateway. Ensure that you delete the lab template at the end to prevent further charges - there are instructions for how to do this at the end of the lab. 15 | 16 | ## Lab Instructions 17 | ### Setup 18 | Using the [CloudFormation template](tgw-lab.yaml) in this repo, launch a stack in the region of your choice that supports Transit Gateway. 19 | 20 | The template creates four VPCs and four EC2 hosts (one in each region) as per the following diagram. 21 | 22 | ![VPC Setup](VPC-setup.png) 23 | 24 | You must select a SSH key pair in the region you are using. If you haven't already done so, create a key pair before launching the template. 25 | 26 | VPC 1 and VPC 3 have Internet access. You will be able to directly SSH to those instances using the key pair you choose. The public and private IP addresses for all of the instances will be in the Outputs section of the CloudFormation stack in the console. You may also see that information in the EC2 console. 27 | 28 | Each instance has a security group that allows SSH and ICMP from anywhere so you can perform connectivity checks and troubleshooting. 29 | 30 | ### Task 1: Check Public and Private Connectivity 31 | SSH to the instances in VPC 1 and VPC 3 using their public IP addresses. 32 | 33 | Try and ping the private IP addresses of all the other instances. This currently won't work because there is (deliberately) no connectivity between the VPCs. 34 | 35 | In order to make troubleshooting easier in the next few steps, copy the SSH key you have to the instances in VPC 1 and VPC 3. On a Mac or Linux desktop you can use scp: 36 | ``` 37 | scp -i ec2-user@: 38 | ``` 39 | 40 | On a Windows desktop you should use a tool like PSCP (Putty SCP). 41 | 42 | ### Task 2: Create Transit Gateway and Enable VPC Communication 43 | Open the VPC console and go to the "Transit Gateways" section and create a new transit gateway. During creation, disable the "Default route table association" and "Default route table propagation" options. These options automatically associate a route table to a VPC and propagate their routes. You're going to do this manually so that you can see the processes necessary to create more complex routing topologies. 44 | 45 | In the "Transit Gateway Attachments" section attach each of the four VPCs to the Transit Gateway. Note that each VPC only has a single subnet but in a production environment you would normally attach all subnets to the Transit Gateway. A subnet without an attachment can only reach the Transit Gateway through another subnet which would be acceptable if the subnets were in the same availability zone. If they weren't, there would be cross-AZ traffic so it is generally best to attach all subnets to the Transit Gateway. 46 | 47 | Conceptually, what you've created is the following network: 48 | 49 | ![Transit Gateway setup](Transit-Gateway-setup.png) 50 | 51 | Now SSH back to the instances in VPC 1 and VPC 3. Try and ping the private addresses of the other instances. This doesn't work because attaching the VPCs to the Transit Gateway doesn't automatically create a routing topology - in this case because the automatic association and propagation was disabled in the Transit Gateway creation above. 52 | 53 | ### Task 3: Associate VPCs with Transit Gateway 54 | Inn the "Transit Gateway Route Tables" section of the console create a route table. Then associate each of the four VPCs with that route table. 55 | 56 | The association process tells Transit Gateway which route table to use when packets leave a VPC. There can only be a single Transit Gateway route table associated with the VPC. Note that if "Default route table association" was enabled during the Transit Gateway creation then this would have automatically happened when you attached the VPC to the Transit Gateway. 57 | 58 | SSH to the instances in VPC 1 and VPC 3 again then try and ping the other instances. This still doesn't work. Even though the Transit Gateway now knows which route table to use when packets are coming from those VPCs you haven't given the route table any routes - that is, where to send the packets next. You can verify this by looking at the "Routes" tab in the console for the Transit Gateway Route Table - there are none there. This means that Transit Gateway will drop those packets once they leave the VPC and come into the Transit Gateway because there is no valid destination. 59 | 60 | ### Task 4: Enable Route Propagation in the Route Table 61 | The "Propagations" tab in the Transit Gateway Route Table instructs Transit Gateway where to send packets next. 62 | 63 | When "Default route table propagation" is enabled it means that VPCs that are attached to the Transit Gateway will automatically have their routes added to the default route table. You've disabled this otherwise this would be a really boring lab... 64 | 65 | Manually add a propagation to the Transit Gateway Route Table for each VPC. 66 | 67 | Once again, SSH to the instances and try to ping the other instances. You've pretty much completely configured Transit Gateway but this still doesn't work. The reason is that the VPCs don't know how to route to the Transit Gateway. Even though you have attached the VPC to the Transit Gateway and associated a Transit Gateway route table to each VPC you haven't modified the VPC route tables at all. Unlike VPN and Direct Connect, Transit Gateway does not automatically add routes to the VPC route tables. 68 | 69 | You can confirm this by looking at the VPC route tables for each VPC. They only have their own internal routes (172.17.x.0/24) and a default route (0.0.0.0/0) in VPC 1 and VPC 3 going to their respective Internet Gateways. 70 | 71 | ### Task 5: Adding Transit Gateway Routes to the VPC Route Tables 72 | In the VPC console, open the route table for VPC 1. Add a route where the destination network is "172.16.0.0/16" and the target (where the packets should go) is the Transit Gateway. This tells the VPC that all packets for any 172.16.x.x network are via the Transit Gateway. 73 | 74 | Note that if you wanted all traffic to go via the Transit Gateway you would use a default route (0.0.0.0/0) but you can't do that in this case because there is already a default route to the VPC Internet Gateway. 75 | 76 | SSH to the host in VPC 1 and try to ping the other instances. Note that this still doesn't work because routing is a two-way process and it has to happen at every step of the way. VPC 1 knows how to route to the other VPCs but they don't know how to route back. If you were running a packet debug on the host in VPC 3 and you were pinging the internal address you would see the ICMP packets hitting the host and the replies being sent - but they would never reach VPC 1 because there is no route in VPC 3 back to VPC 1. 77 | 78 | So, go back to the VPC console and open the route table for VPC 3. Here again, add a route for network "172.16.0.0/16" where the target is the Transit Gateway. 79 | 80 | In the route tables for VPC 2 and VPC 4, add a route for network "0.0.0.0/0" where the target is your Transit Gateway. In these two VPCs you can use a default route because you do want all traffic to go to the Transit Gateway - there is no Internet Gateway route to worry about. Note that using a route of "172.16.0.0/16" in these VPCs would work just as well. 81 | 82 | If you now SSH to the instance you can ping and SSH between their private addresses. You have full connectivity between all of the VPCs via Transit Gateway. 83 | 84 | ### Task 6: Internet Connectivity Check 85 | Now that you have a working network let's see if Internet connectivity is available from VPC 2 via VPC 1 - after all, VPC 1 has an Internet Gateway. 86 | 87 | Add a default route to the Transit Gateway Route Table. The CIDR (the destination network) is "0.0.0.0/0" and VPC 1 is the attachment you want it to use. That's all you have to do because there is a default route in VPC 2 that is sending all traffic to the Transit Gateway and once the traffic is routed to VPC 1 there is a default route there sending all traffic to the Internet Gateway. 88 | 89 | SSH to the instance in VPC 1 and verify you can ping something on the internet like www.amazon.com. 90 | 91 | Then SSH to the instance in VPC 2. Can you ping www.amazon.com? 92 | 93 | Spoiler: No, you can't. This same scenario will also fail if the VPCs are peered together and there is no Transit Gateway in the mix. In both situations, the non-transitive routing attribute of VPCs takes over - traffic that enters a VPC from another VPC can't then exit. 94 | 95 | But can you use a VPC as your Internet transit for all other VPCs? Absolutely. The most common way of doing this is to put a proxy server farm in VPC 1 and direct all Internet traffic to it. You can see an example of this [on our security blog](https://aws.amazon.com/blogs/security/how-to-set-up-an-outbound-vpc-proxy-with-domain-whitelisting-and-content-filtering/). 96 | 97 | ### Task 7: Isolate VPCs and Reconnect 98 | In this exercise, you're going to create a network where VPC 1 and VPC 2 can communicate; VPC 3 and VPC 4 can communicate; but the two pairs (1 and 2; 3 and 4) can't communicate with each other. 99 | 100 | In the Transit Gateway Route Table, remove all references to VPC 3 and VPC 4. You will need to delete the propagations and associations for those VPCs to the route table. This will mean that VPC 1 and VPC 2 can still communicate via the route table but VPC 3 and VPC 4 will be totally isolated. Confirm that you've removed all references by checking the "Routes" tab in the Transit Gateway Route Table and ensuring there are no routes for VPC 3 (172.16.3.0/24) and VPC 4 (172.16.4.0/24). 101 | 102 | Create a new Transit Gateway Route Table. Associate VPC 3 and VPC 4 to the new route table and then propagate the routes from VPC 3 and VPC 4 to the route table as well. Again, confirmm that the routes for those VPCs are in the "Routes" tab. 103 | 104 | SSH to the instance in VPC 1. From it you can connect to the instance in VPC 2 but not the instances in VPC 3 or VPC 4. Similarly, from the instance in VPC 3 you can connect to VPC 4 but not VPC 1 nor VPC 2. 105 | 106 | ### Task 8: Establish Partial Connectivity 107 | Next, you'll set up Transit Gateway so that only the two private VPCs (VPC 2 and VPC 4) can communicate. 108 | 109 | In the original Transit Gateway Route Table add a propatagion for VPC 4. In the second Transit Gateway Route Table that you created in the previous exercise, add a propagation for VPC 2. 110 | 111 | Check the "Routes" tab in both route tables to ensure that you have routes to the VPCs that are "in" the other route table. 112 | 113 | SSH to the instance in VPC 2 (which you'll need to do via the instance in VPC 1). You should be able to communicate with the instance in VPC 4 using the private IP address. This is because the route table associated with VPC 2 knows a route to VPC 4. And the route table associated with VPC 4 knows a route to VPC 2. 114 | 115 | From the instance in VPC 2 try and communicate with the instance in VPC 3. This will not work because there is no route in the Transit Gateway Route Table associated with VPC 2 going to VPC 3. Packets simply cannot get there. 116 | 117 | Alternately, SSH to the instance in VPC 3 and try and connect to the instance in VPC 2. This will not work for exactly the same reason. Even though there is a route in the Transit Gateway Route Table associated with VPC 3 that allows packets to go to VPC 2 there is no return route to VPC 3. There must be routes in both directions for communications to occur. 118 | 119 | ### Teardown 120 | When you're finished, delete the Transit Gateway Attachments for each VPC to the Transit Gateway. 121 | 122 | Once they're deleted, delete the Transit Gateway. 123 | 124 | When done, delete the CloudFormation stack. 125 | 126 | ### Conclusion 127 | In this lab you've seen how Transit Gateway can be used to connect VPCs together in a few different ways. 128 | 129 | One final diagram as a reference to the way VPCs are attached, associated and propagated within Transit Gateway. 130 | 131 | ![Transit Gateway concepts](Transit-Gateway-Overview.png) 132 | -------------------------------------------------------------------------------- /Transit-Gateway-Overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/aws-samples/aws-transit-gateway-routing-lab/590c54d04b8524244201ac89df125f0a705d498a/Transit-Gateway-Overview.png -------------------------------------------------------------------------------- /Transit-Gateway-setup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/aws-samples/aws-transit-gateway-routing-lab/590c54d04b8524244201ac89df125f0a705d498a/Transit-Gateway-setup.png -------------------------------------------------------------------------------- /VPC-setup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/aws-samples/aws-transit-gateway-routing-lab/590c54d04b8524244201ac89df125f0a705d498a/VPC-setup.png -------------------------------------------------------------------------------- /tgw-lab.yaml: -------------------------------------------------------------------------------- 1 | AWSTemplateFormatVersion: "2010-09-09" 2 | 3 | Description: Create four VPCs and hosts for a Transit Gateway lab 4 | 5 | Parameters: 6 | SSHKeyName: 7 | Type: AWS::EC2::KeyPair::KeyName 8 | Description: Choose a SSH key for the instances 9 | LatestAMIId: 10 | Type: AWS::SSM::Parameter::Value 11 | Default: "/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2" 12 | 13 | Outputs: 14 | FirstHostPublicIP: 15 | Value: !GetAtt FirstHost.PublicIp 16 | ThirdHostPublicIP: 17 | Value: !GetAtt ThirdHost.PublicIp 18 | FirstHostPrivateIP: 19 | Value: !GetAtt FirstHost.PrivateIp 20 | SecondHostPrivateIP: 21 | Value: !GetAtt SecondHost.PrivateIp 22 | ThirdHostPrivateIP: 23 | Value: !GetAtt ThirdHost.PrivateIp 24 | FourthHostPrivateIP: 25 | Value: !GetAtt FourthHost.PrivateIp 26 | 27 | Resources: 28 | FirstVPC: 29 | Type: AWS::EC2::VPC 30 | Properties: 31 | CidrBlock: 172.16.1.0/24 32 | Tags: 33 | - Key: Name 34 | Value: "First VPC" 35 | 36 | FirstSubnet: 37 | Type: AWS::EC2::Subnet 38 | Properties: 39 | AvailabilityZone: !Sub "${AWS::Region}a" 40 | CidrBlock: 172.16.1.0/28 41 | MapPublicIpOnLaunch: true 42 | Tags: 43 | - Key: Name 44 | Value: "First VPC First Subnet" 45 | VpcId: !Ref FirstVPC 46 | 47 | FirstSecurityGroup: 48 | Type: AWS::EC2::SecurityGroup 49 | Properties: 50 | GroupName: "First VPC inbound SSH only" 51 | GroupDescription: "Allow SSH from anywhere" 52 | VpcId: !Ref FirstVPC 53 | SecurityGroupIngress: 54 | - IpProtocol: tcp 55 | ToPort: 22 56 | FromPort: 0 57 | CidrIp: 0.0.0.0/0 58 | - IpProtocol: icmp 59 | ToPort: -1 60 | FromPort: -1 61 | CidrIp: 0.0.0.0/0 62 | 63 | FirstInternetGateway: 64 | Type: AWS::EC2::InternetGateway 65 | Properties: 66 | Tags: 67 | - Key: "Name" 68 | Value: "First VPC IGW" 69 | 70 | FirstAttachGateway: 71 | Type: AWS::EC2::VPCGatewayAttachment 72 | Properties: 73 | InternetGatewayId: !Ref FirstInternetGateway 74 | VpcId: !Ref FirstVPC 75 | 76 | FirstSubnetRouteTableAssociation: 77 | Type: AWS::EC2::SubnetRouteTableAssociation 78 | Properties: 79 | RouteTableId: !Ref FirstRouteTable 80 | SubnetId: !Ref FirstSubnet 81 | 82 | FirstRoute: 83 | Type: AWS::EC2::Route 84 | Properties: 85 | DestinationCidrBlock: 0.0.0.0/0 86 | GatewayId: !Ref FirstInternetGateway 87 | RouteTableId: !Ref FirstRouteTable 88 | 89 | FirstRouteTable: 90 | Type: AWS::EC2::RouteTable 91 | Properties: 92 | VpcId: !Ref FirstVPC 93 | Tags: 94 | - Key: Name 95 | Value: "First VPC Main Route Table" 96 | 97 | SecondVPC: 98 | Type: AWS::EC2::VPC 99 | Properties: 100 | CidrBlock: 172.16.2.0/24 101 | Tags: 102 | - Key: Name 103 | Value: "Second VPC" 104 | 105 | SecondSubnet: 106 | Type: AWS::EC2::Subnet 107 | Properties: 108 | AvailabilityZone: !Sub "${AWS::Region}a" 109 | CidrBlock: 172.16.2.0/28 110 | Tags: 111 | - Key: Name 112 | Value: "Second VPC First Subnet" 113 | VpcId: !Ref SecondVPC 114 | 115 | SecondSecurityGroup: 116 | Type: AWS::EC2::SecurityGroup 117 | Properties: 118 | GroupName: "Second VPC inbound SSH only" 119 | GroupDescription: "Allow SSH from anywhere" 120 | VpcId: !Ref SecondVPC 121 | SecurityGroupIngress: 122 | - IpProtocol: tcp 123 | ToPort: 22 124 | FromPort: 0 125 | CidrIp: 0.0.0.0/0 126 | - IpProtocol: icmp 127 | ToPort: -1 128 | FromPort: -1 129 | CidrIp: 0.0.0.0/0 130 | 131 | SecondSubnetRouteTableAssociation: 132 | Type: AWS::EC2::SubnetRouteTableAssociation 133 | Properties: 134 | RouteTableId: !Ref SecondRouteTable 135 | SubnetId: !Ref SecondSubnet 136 | 137 | SecondRouteTable: 138 | Type: AWS::EC2::RouteTable 139 | Properties: 140 | VpcId: !Ref SecondVPC 141 | Tags: 142 | - Key: Name 143 | Value: "Second VPC Main Route Table" 144 | 145 | ThirdVPC: 146 | Type: AWS::EC2::VPC 147 | Properties: 148 | CidrBlock: 172.16.3.0/24 149 | Tags: 150 | - Key: Name 151 | Value: "Third VPC" 152 | 153 | ThirdSubnet: 154 | Type: AWS::EC2::Subnet 155 | Properties: 156 | AvailabilityZone: !Sub "${AWS::Region}a" 157 | CidrBlock: 172.16.3.0/28 158 | MapPublicIpOnLaunch: true 159 | Tags: 160 | - Key: Name 161 | Value: "Third VPC First Subnet" 162 | VpcId: !Ref ThirdVPC 163 | 164 | ThirdSecurityGroup: 165 | Type: AWS::EC2::SecurityGroup 166 | Properties: 167 | GroupName: "Third VPC inbound SSH only" 168 | GroupDescription: "Allow SSH from anywhere" 169 | VpcId: !Ref ThirdVPC 170 | SecurityGroupIngress: 171 | - IpProtocol: tcp 172 | ToPort: 22 173 | FromPort: 0 174 | CidrIp: 0.0.0.0/0 175 | - IpProtocol: icmp 176 | ToPort: -1 177 | FromPort: -1 178 | CidrIp: 0.0.0.0/0 179 | 180 | ThirdInternetGateway: 181 | Type: AWS::EC2::InternetGateway 182 | Properties: 183 | Tags: 184 | - Key: "Name" 185 | Value: "Third VPC IGW" 186 | 187 | ThirdAttachGateway: 188 | Type: AWS::EC2::VPCGatewayAttachment 189 | Properties: 190 | InternetGatewayId: !Ref ThirdInternetGateway 191 | VpcId: !Ref ThirdVPC 192 | 193 | ThirdRoute: 194 | Type: AWS::EC2::Route 195 | Properties: 196 | DestinationCidrBlock: 0.0.0.0/0 197 | GatewayId: !Ref ThirdInternetGateway 198 | RouteTableId: !Ref ThirdRouteTable 199 | 200 | ThirdSubnetRouteTableAssociation: 201 | Type: AWS::EC2::SubnetRouteTableAssociation 202 | Properties: 203 | RouteTableId: !Ref ThirdRouteTable 204 | SubnetId: !Ref ThirdSubnet 205 | 206 | ThirdRouteTable: 207 | Type: AWS::EC2::RouteTable 208 | Properties: 209 | VpcId: !Ref ThirdVPC 210 | Tags: 211 | - Key: Name 212 | Value: "Third VPC Main Route Table" 213 | 214 | FourthVPC: 215 | Type: AWS::EC2::VPC 216 | Properties: 217 | CidrBlock: 172.16.4.0/24 218 | Tags: 219 | - Key: Name 220 | Value: "Fourth VPC" 221 | 222 | FourthSubnet: 223 | Type: AWS::EC2::Subnet 224 | Properties: 225 | AvailabilityZone: !Sub "${AWS::Region}a" 226 | CidrBlock: 172.16.4.0/28 227 | Tags: 228 | - Key: Name 229 | Value: "Fourth VPC First Subnet" 230 | VpcId: !Ref FourthVPC 231 | 232 | FourthSecurityGroup: 233 | Type: AWS::EC2::SecurityGroup 234 | Properties: 235 | GroupName: "Fourth VPC inbound SSH only" 236 | GroupDescription: "Allow SSH from anywhere" 237 | VpcId: !Ref FourthVPC 238 | SecurityGroupIngress: 239 | - IpProtocol: tcp 240 | ToPort: 22 241 | FromPort: 0 242 | CidrIp: 0.0.0.0/0 243 | - IpProtocol: icmp 244 | ToPort: -1 245 | FromPort: -1 246 | CidrIp: 0.0.0.0/0 247 | 248 | FourthSubnetRouteTableAssociation: 249 | Type: AWS::EC2::SubnetRouteTableAssociation 250 | Properties: 251 | RouteTableId: !Ref FourthRouteTable 252 | SubnetId: !Ref FourthSubnet 253 | 254 | FourthRouteTable: 255 | Type: AWS::EC2::RouteTable 256 | Properties: 257 | VpcId: !Ref FourthVPC 258 | Tags: 259 | - Key: Name 260 | Value: "Fourth VPC Main Route Table" 261 | 262 | FirstHost: 263 | Type: AWS::EC2::Instance 264 | Properties: 265 | ImageId: !Ref LatestAMIId 266 | InstanceType: t3.nano 267 | SubnetId: !Ref FirstSubnet 268 | KeyName: !Ref SSHKeyName 269 | SecurityGroupIds: 270 | - !Ref FirstSecurityGroup 271 | Tags: 272 | - Key: Name 273 | Value: "First EC2 host" 274 | 275 | SecondHost: 276 | Type: AWS::EC2::Instance 277 | Properties: 278 | ImageId: !Ref LatestAMIId 279 | InstanceType: t3.nano 280 | SubnetId: !Ref SecondSubnet 281 | KeyName: !Ref SSHKeyName 282 | SecurityGroupIds: 283 | - !Ref SecondSecurityGroup 284 | Tags: 285 | - Key: Name 286 | Value: "Second EC2 host" 287 | 288 | ThirdHost: 289 | Type: AWS::EC2::Instance 290 | Properties: 291 | ImageId: !Ref LatestAMIId 292 | InstanceType: t3.nano 293 | SubnetId: !Ref ThirdSubnet 294 | KeyName: !Ref SSHKeyName 295 | SecurityGroupIds: 296 | - !Ref ThirdSecurityGroup 297 | Tags: 298 | - Key: Name 299 | Value: "Third EC2 host" 300 | 301 | FourthHost: 302 | Type: AWS::EC2::Instance 303 | Properties: 304 | ImageId: !Ref LatestAMIId 305 | InstanceType: t3.nano 306 | SubnetId: !Ref FourthSubnet 307 | KeyName: !Ref SSHKeyName 308 | SecurityGroupIds: 309 | - !Ref FourthSecurityGroup 310 | Tags: 311 | - Key: Name 312 | Value: "Fourth EC2 host" 313 | --------------------------------------------------------------------------------