0

I can't seem to find any specific guidance on what constitutes good practice with regards to the use of one VPC vs. many for application hosting. This link touches on the subject, but is quite old and doesn't really provide an answer.

I'm currently working on a migration of a traditionally hosted environment that consists of around 50 apps plus two database farms (SQL Server and Oracle) to AWS; total estate is around 250 Windows servers. Currently each app essentially sits on its own /24 subnet.

I've been given a steer that each app and database farm should sit both within its own AWS account and VPC, and I'm not sure of the wisdom of this approach; especially the part of seperating the apps from their databases.

The accounts I'm less worried about, as that is more of a billing question. But as far as the VPCs are concerned I'm trying to understand the difference between say:

  1. Replicating the whole environment within 1 VPC, vs.
  2. Introducing 50 VPCs to host the same number of apps / servers.

What should be taken into consideration when deciding between (1) and (2), or some compromise in the middle. I've looked at the AWS docs and can't really find any clear advice on this topic.

The key differences, as I see it, is between the network traffic all being intra-VPC vs. inter-VPC. This means:

  • there is now an additional cost because inter-VPC traffic costs and intra-VPC traffic doesn't.
  • There is some additional complexity in that an Inter-VPC mechanism such as Peering or Transit Gateways need to be selected, set-up and managed.

But neither of the above are a clear reason to do things one way or the other; while 50 VPCs is quite a lot, the numbers in question are well within the limits of Peering, for example.

Is there anything else I should be taking into consideration?

  • What about the performance characteristics for Intra vs. Inter VPC traffic, etc.?

Other considerations:

  • CIDR blocks have to be managed across the VPCs to avoid a clash.
  • Peering's max MTU is 1500 bytes
  • by default Inter-VPC traffic is not encrypted.
  • DNS complications.

Thanks for any help.

P Burke
  • 183
  • 3
  • 12

2 Answers2

1

Look at AWS Landing Zone and AWS Control Tower for best practice.

I've designed a few enterprise AWS networks, and here's my general recommendations when you have many workloads for the area you're asking (the full recommendations for landing zone design is a two day workshop I run for customers)

  • One account per application, per environment (eg app1 has accounts for dev, pre-prod, and prod, app2 has it's own accounts, etc)
  • All resources for each application such as app server, database server, etc, go in that account. Splitting you app server and database across accounts increases the cost without any real benefit.
  • Shared services account can be used for things that most applications need - AD,
  • Security Account should master guard duty, security appliances, etc
  • Transit gateway for communications, plus on-premise connectivity (that addresses your network questions)
  • Federate to a directory server of your choice - on premise, AD service, Azure AD, etc
  • Use AWS Organisations, with Service Control Policies for high level permissions, and IAM roles to allow users to do only what you want - ie don't let them disable security services, change boundary stuff like internet gateway or VPN, etc
  • Consider using shared VPCs to reduce bandwidth costs - but be careful, it's a someone tricky subject

This gives you good isolation and lowers your blast radius, but you need decent automation as you'd have 150 accounts. An account is just a container for billing and VPCs. Yes, you pay more for bandwidth.

The alternative, to reduce bandwidth costs, is everything in one VPC. That makes isolation, control, and blast radius a problem.

Tim
  • 31,888
  • 7
  • 52
  • 78
0

Additionally, for my product, I use a separate, highly lockdown account for backups of prod env. (RDS, S3, etc.) and in a different region from which prod is running. Disaster recovery testing in the lockdown account happens every 15 days to ensure backups work!

dy10
  • 41
  • 5