3

I currently have each VPC per cluster (stg, prd, tst, misc) and the standard clusters (stg, prd) have these subnets:

  • elb: for public elb(s) that will received direct public traffic
  • elb-int: for internal elb(s) that will received service to service comm
  • svc: for application service
  • db: for database
  • dmz: for nat gateway(s), proxy, etc
VPC (stg, prd)
├10.100.0.0/16 az-1
|  ├10.100.0.0/20  elb
|  ├10.100.16.0/20 elb-int
|  ├10.100.32.0/20 svc
|  ├10.100.48.0/20 svc
|  ├10.100.64.0/20 db
|  ├10.100.80.0/20 dmz
|  ├10.100.96.0/20 <reserved>
|  ├ ...
|  └10.1-0.240.0/20 <reserved>
├10.101.0.0/16 az-2
|  ├10.101.0.0/20  elb
|  ├10.101.16.0/20 elb-int
|  ├10.101.32.0/20 svc
|  ├10.101.48.0/20 svc
|  ├10.101.64.0/20 db
|  ├10.101.80.0/20 dmz
|  ├10.101.96.0/20 <reserved>
|  ├ ...
|  └10.101.240.0/20 <reserved>
└10.102.0.0/16 az-3
   ├10.102.0.0/20  elb
   ├10.102.16.0/20 elb-int
   ├10.102.32.0/20 svc
   ├10.102.48.0/20 svc
   ├10.102.64.0/20 db
   ├10.102.80.0/20 dmz
   ├10.102.96.0/20 <reserved>
   ├ ...
   └10.102.240.0/20 <reserved>

I know this question is broad, like "it depends on the situation" kinda question. But I've searched the internet and found no sensible guideline on this.

So I asked this question to find out how sysadmins choose a strategy for their subnet(s). Please share yours, and, if you can, place a small statement explaining why you choose that approach.

tu4n
  • 131
  • 4

1 Answers1

5

I'm afraid ServerFault isn't a place for conducting surveys or soliciting opinion-based answers.

Anyway your setup seems to be way over-complicated.

Because in AWS security and firewalling is done predominantly using Security Groups it doesn't really matter if you've got 6 subnet layers like you describe in the question or just 2 per VPC - Public and Private.

  • Resources in the Public subnets have public/elastic IPs and can be accessed from the internet, if SG rules permit

    For example - public ELB/ALB, jump hosts, etc

  • Resources in the Private subnets can't be accessed from outside and use NAT to talk out

    For example - RDS clusters, ECS clusters, web servers (hidden behind ELB), etc.

  • Optionally you can have Private subnets without internet access - that's sometimes used for databases (RDS) but almost as often they are simply put into the normal Private subnets.

Of course your Public and Private subnet layers should span across a few AZs to achieve high availability but don't go overboard. Use 2 or 3 AZs max, that's usually enough even if in some regions you can have a lot more.

Technically of course you can't span a subnet across AZs but you can have priv-a 172.31.0.0/24 in AZ "a" and priv-b 172.31.1.0/24 in AZ "b" and deploy ELBs and ASGs across both and treat it like one.

Note that all the above applies per VPC - typically you'll have multiple VPCs, eg. one per stage (dev, test, ..) and even multiple AWS accounts per project (e.g. dev and prod) for a greater separation between production and development / testing workloads.

None of this these are hard rules of course. Some clients require more subnet layers or more AZs per VPC but those are exceptions.

For the majority of VPCs the Public + Private subnets across 3 AZs are perfectly fine.

And remember - Security Groups are your friends :)

Community
  • 1
MLu
  • 26,247