{"id":30120248,"url":"https://github.com/stakater/blueprint-network-aws","last_synced_at":"2025-08-10T12:55:00.950Z","repository":{"id":53478612,"uuid":"66709197","full_name":"stakater/blueprint-network-aws","owner":"stakater","description":"Stakater Blueprint for creating best-practices network on AWS. Stakater is an Infrastructure-as-Code DevOps solution to automate the creation of web infrastructure stack on AWS. Stakater is based on Docker, CoreOS, Terraform, Packer, Docker Compose, GoCD, Fleet, ETCD, and more.","archived":false,"fork":false,"pushed_at":"2023-12-15T05:20:37.000Z","size":110,"stargazers_count":13,"open_issues_count":1,"forks_count":3,"subscribers_count":16,"default_branch":"master","last_synced_at":"2024-04-15T04:16:10.143Z","etag":null,"topics":["aws","bastion-host","blueprint","internet-gateway","nat-gateways","nat-instance","network","private-subnets","subnet","terraform","vpc"],"latest_commit_sha":null,"homepage":"","language":"HCL","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/stakater.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2016-08-27T10:31:02.000Z","updated_at":"2021-10-12T02:15:10.000Z","dependencies_parsed_at":"2022-08-23T16:30:27.075Z","dependency_job_id":null,"html_url":"https://github.com/stakater/blueprint-network-aws","commit_stats":null,"previous_names":[],"tags_count":4,"template":false,"template_full_name":null,"purl":"pkg:github/stakater/blueprint-network-aws","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stakater%2Fblueprint-network-aws","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stakater%2Fblueprint-network-aws/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stakater%2Fblueprint-network-aws/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stakater%2Fblueprint-network-aws/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/stakater","download_url":"https://codeload.github.com/stakater/blueprint-network-aws/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stakater%2Fblueprint-network-aws/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":269727090,"owners_count":24465398,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-08-10T02:00:08.965Z","response_time":71,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws","bastion-host","blueprint","internet-gateway","nat-gateways","nat-instance","network","private-subnets","subnet","terraform","vpc"],"created_at":"2025-08-10T12:54:11.001Z","updated_at":"2025-08-10T12:55:00.926Z","avatar_url":"https://github.com/stakater.png","language":"HCL","funding_links":[],"categories":[],"sub_categories":[],"readme":"# blueprint-network-aws\n\nThis *blueprint* contains modules that are used to set up a best practices network topology in your AWS account. This *blueprint* creates an isolated VPC for each environment (staging, production, mgmt), and within each environment, sets up multiple tiers of isolated subnets (public, private, persistence) network ACLs, security groups, NAT gateways, bastion host, and VPC peering connections.\n\n- Network\n  - VPC\n  - Public subnets\n  - Private subnets\n  _ Private persistence subnets\n  - NAT\n  - OpenVPN\n  - Bastion host\n\n## What is a blueprint?\n\nAt Stakater, we've taken the thousands of hours we spent building infrastructure on AWS and condensed all that experience and code into pre-built blueprints or packages or modules. Each blueprint is a battle-tested, best-practices definition of a piece of infrastructure, such as a VPC, ECS cluster, or an Auto Scaling Group. Modules are versioned using Semantic Versioning to allow Stakater clients to keep up to date with the latest infrastructure best practices in a systematic way.\n\n## Concepts\n\n### What's a VPC?\n\nA [VPC](https://aws.amazon.com/vpc/) or Virtual Private Cloud is a logically isolated section of your AWS cloud. Each\nVPC defines a virtual network within which you run your AWS resources, as well as rules for what can go in and out of\nthat network. This includes subnets, route tables that tell those subnets how to route inbound and outbound traffic,\nsecurity groups, firewalls for the subnet (known as \"Network ACLs\"), and any other network components such as VPN connections.\n\n#### Benefits of a VPC\n\nBefore VPCs existed in AWS, every EC2 Instance launched in AWS was addressable by the public Internet, or any other EC2\nInstance launched in AWS, even from different customers! You could block network access using security groups or OS-managed\nfirewalls, but this still represented a security step backward from traditional data center setups where a given server would be physically unreachable from the Internet.\n\nVPCs are fundamentally about isolating your resources so that they're only reachable by a limited set of other resources\nyou define. You can set granular isolation rules by defining Route Tables for each Subnet. You can allow a limited set\nof outsiders to connect to your VPC, for example, using VPN, or just by exposing a single host accessible to the public.\n\nThe general point is that you have an isolated environment you can use to lock down access.\n\nGiven all the above, an intuitive way to leverage a VPC is to make each VPC represent a unique environment by having,\nfor example, a prod VPC and stage VPC.\n\n### CIDR-Formatted IP Address Ranges\n\nBecause a VPC is an isolated world meant specially for your use, you can define a range of private IP addresses that the VPC\nwill allow. For example, we may wish to allow any IP address from 10.0.50.0 to 10.0.50.15.\n\nBut we need a more concise way to represent such an IP address range, and the de facto standard is the Classless Inter-\nDomain Routing (CIDR) standard. The name is confusing but as [Wikipedia](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) explains, the concept works as follows:\n\n1. Convert a base-10 IP like `10.0.50.0` to binary format: `00001010.00000000.00110010.00000000`\n\n2. Decide how many binary digits (or bits) we will allow to \"vary.\" For example, suppose I want the following range of IP\n   addresses: `00001010.00000000.00110010.00000000` to `00001010.00000000.00110010.11111111` (`10.0.50.0` to `10.0.50.255`).\n   Notice that the first three \"octets\" (group of 8 bits) are the same, but the last octet ranges from 0 to 255.\n\n3. Express the number of varying bits in CIDR format: `\u003cbase-10-ip\u003e/\u003cleading-number-of-bits-which-are-fixed\u003e`. For\n   example, if we use the range in the previous step, we'd have `10.0.50.0/24`. The first 24 bits are fixed so that the\n   remaining 8 bits can vary. In CIDR parlance, our \"IP Address\" is `10.0.50.0` and our \"Network Mask\" is `24`.\n\nSometimes CIDR Ranges are called CIDR Blocks. The CIDR Block `0.0.0.0/0` corresponds to any IP address. The CIDR Block\n`1.2.3.4/32` corresponds to only `1.2.3.4`.\n\nYou'll notice that every VPC has a CIDR Block, and indeed this represents the range of private IP addresses\nwhich can be assigned to resources in the VPC.\n\n### Subnets\n\nSubnets are \"sub-networks\", or a partition of the VPC. For example, a VPC might have the CIDR range `10.0.50.0/24`\n(`10.0.15.0` - `10.0.15.255`) and a subnet might allow just IP addresses in the range `10.0.50.0/28` (`10.0.15.0` -\n`10.0.15.16`). Note that subnets cannot have overlapping CIDR Ranges.\n\nIn addition, each subnet can have a unique Route Table.\n\n### Route Tables\n\nEach subnet needs a [Route Table](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html) so that\nit knows how to route traffic within that subnet. For example, a given subnet might route traffic destined for CIDR Block\n`10.0.20.0/24` to a VPC Peering Connection, traffic for `10.0.10.0/24` within the VPC, and all the rest (`0.0.0.0/0`) to\nto the Internet Gateway so it can reach the public Internet. The Route Table declares all this.\n\n### The Internet Gateway\n\nThe best way to think of an [Internet Gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html)\nis that it's the destination that VPC traffic destined for the public Internet gets routed to. This configuration is\nrecorded in a Route Table.\n\n### NAT Gateways\n\nIf you launch an EC2 Instance in one of the **Public Subnets** defined above, it will automatically be addressable from\nthe public Internet and have outbound Internet access itself.\n\nBut if you launch an EC2 Instance in one of the **Private Subnets** defined above, it will NOT be addressable from the\npublic Internet. This is a useful security property. For example, we generally don't want our databases directly addressable\non the public Internet.\n\nBut what if an EC2 Instance in a private subnet needs *outbound* Internet access? It could route its requests to the\nInternet, but there's no way for the Internet to return the response since, as we just explained, the EC2 Instance isn't\naddressable from the Internet.\n\nTo solve this problem, we need our private EC2 Instance to submit its public Internet requests through another EC2 Instance\nthat's located in a public subnet. That EC2 Instance should keep track of where it got its original request so that it\ncan redirect or \"translate\" the response it receives back to the original requestor.\n\nSuch an EC2 Instance is called a \"Network Address Translation\" instance, or NAT instance.\n\nBut what if the NAT Instance goes down? Now our private EC2 Instance can't reach the Internet at all. That's why it's\npreferable to have a highly available NAT Instance service, and that's what Amazon's [NAT Gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html)\nservice is. Amazon runs more than one EC2 Instance behind the scenes, and automatically handles failover if one instance dies.\n\n### VPC Endpoints\n\nBy default, when an EC2 Instance makes an AWS API call, that HTTPS request is still routed through the public Internet.\nAWS customers complained that they didn't want their AWS API requests traveling outside the VPC, so AWS released a\n[VPC Endpoint](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html) service.\n\nVPC Endpoints cost nothing and provide a new destination for a Route Table so that when certain AWS API requests are made\ninstead of being routed to the public AWS API endpoint, they are routed directly within the VPC. Unfortunately, as of\nJune 10, 2016, the only AWS service supported for VPC Endpoints is S3.\n\n### What's a Network ACL?\n\n[Network ACLs](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html) provide an extra layer of network\nsecurity, similar to a [security group](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html).\nWhereas a security group controls what inbound and outbound traffic is allowed for a specific resource (e.g. a single\nEC2 instance), a network ACL controls what inbound and outbound traffic is allowed for an entire subnet.\n\n### What's a bastion host?\n\n\n### What's VPC Peering?\n\n\n### Networking\n\n![](./diagrams/networking.png)\n\nBy default, the Stackater will create a VPC in a single region, amongst multiple availability zones (AZs). The default mask for this VPC is\n\n    10.30.0.0/16\n\nThe address was chosen to be internal, and to not conflict with other pieces of infrastructure you might run. But, it can also be configured with its own CIDR range.\n\nEach availability zone will get its own external and internal subnets. Most of our infrastructure will live in the *internal* subnet so that they are not externally accessible to the internet.\n\nIf you'd like to scale to multiple regions, simply add one to the second octet.\n\n    10.31.0.0/16 -- my new region\n\nTo span across availability zones, the regional 16-bit mask becomes 18-bits.\n\n    10.30.0.0/18 - AZ A\n    10.30.64.0/18 - AZ B\n    10.30.128.0/18 - AZ C\n    10.30.192.0/18 - Spare\n\nTo subdivide each availability zone into spaces for internal, external and to have spare room for growth; use a 19-bit mask for internal, and a 20-bit mask for external. The external space is smaller because only a few instances and load-balancers should be provisioned into it.\n\n    10.30.0.0/18 - AZ A\n\n      10.30.0.0/19 internal\n      10.30.32.0/20 external\n      10.30.48.0/20 spare\n\n    10.30.64.0/18 - AZ B\n\n      10.30.64.0/19 internal\n      10.30.96.0/20 external\n      10.30.112.0/20 spare\n\n    10.30.128.0/18 - AZ C\n\n      10.30.128.0/19 internal\n      10.30.160.0/20 external\n      10.30.176.0/20 spare\n\nThe VPC itself will contain a single network gateway to route traffic in and out of the different subnets. The Stackater terraform will automatically create separate [NAT Gateways][nat-gateway] in each of the different subnets.\n\nTraffic from each internal subnet to the outside world will run through the associated NAT gateway.\n\nFor further reading, check out these sources:\n\n- [Recommended Address Space](http://serverfault.com/questions/630022/what-is-the-recommended-cidr-when-creating-vpc-on-aws)\n- [Practical VPC Design](https://medium.com/aws-activate-startup-blog/practical-vpc-design-8412e1a18dcc)\n- [nat-gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html)\n\n## Developing a module\n\n### Versioning\n\nWe are following the principles of [Semantic Versioning](http://semver.org/). During initial development, the major\nversion is to 0 (e.g., `0.x.y`), which indicates the code does not yet have a stable API. Once we hit `1.0.0`, we will\nfollow these rules:\n\n1. Increment the patch version for backwards-compatible bug fixes (e.g., `v1.0.8 -\u003e v1.0.9`).\n2. Increment the minor version for new features that are backwards-compatible (e.g., `v1.0.8 -\u003e 1.1.0`).\n3. Increment the major version for any backwards-incompatible changes (e.g. `1.0.8 -\u003e 2.0.0`).\n\nThe version is defined using Git tags.  Use GitHub to create a release, which will have the effect of adding a git tag.\n\n## Credits\n\n1. https://github.com/terraform-community-modules/tf_aws_vpc\n2. https://github.com/gruntwork-io/module-vpc-public\n3. https://github.com/hashicorp/best-practices/tree/master/terraform/modules/aws/network\n4. https://github.com/hashicorp/atlas-examples/tree/master/infrastructures\n\n\n#### NOTE: \nAny changes made to this repository should also be reflected in its respective clone for kubernetes (https://github.com/stakater/blueprint-network-k8s-aws). \nBoth repositories should contain same code with the difference of kubernetes specific tags on resources of the clone repositroy `blueprint-network-k8s-aws`. \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstakater%2Fblueprint-network-aws","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fstakater%2Fblueprint-network-aws","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstakater%2Fblueprint-network-aws/lists"}