Your Cloud Consultant Probably Sucks

There is a disturbing consistency in the kinds of project requests I’m seeing these days. Organizations call me because they are in the midst of their first transition to cloud, and they are spending many months planning out their exact AWS environment and all the security controls “before we move any workloads up”. More often than not some consulting firm advised them they need to spend 4-9 months building out 1-2 virtual networks in their cloud provider and implementing all the security controls before they can actually start in cloud.

This is exactly what you don’t want to do.

As I discussed [in an earlier post on blast radius you most definitely don’t want just one big cloud account/network with everything shoved in. This sets you up for major failures down the road, and will slow down your cloud initiatives to a degree that you lose many of the advantages of cloud. Here is why:

• One big account means a bigger blast radius (note that “account” us the AWS designation, Azure and Google use different structures but you can achieve the same goals). If something bad happens, like someone getting cloud admin credentials, the damage is massive.
• Speaking of admins, it becomes very hard to write identity management policies to restrict admins to only their needed scope, especially as you add more and more projects. With multiple accounts/networks you have a better ability to segregate them out and limit entitlements.
• It becomes harder to adopt immutable infrastructure (using templates like CloudFormation or Terraform to define the infrastructure and built it on demand) since developers and admins will end up stepping on each other more often.
• IP address space management and subnet segregation become really hard. Virtual networks aren’t physical networks. They are fundamentally managed and secured differently. What I end up seeing most organizations trying to do is shove in existing security tools and controls until it eventually falls down. In one recent case it became harder and slower to deploy things into the company’s AWS account than to spend months provisioning a new physical box on the existing network. That’s like paying for Netflix and trying to record Luke Cage on your TiVo so you can watch it when you want.

Those are just the highlights and the short version is that while you can start this way, it won’t last. Unfortunately, I’ve found that this is a surprisingly dominant recommendation from third-party “cloud consultants”, especially ones coming from the big firms. I’ve also seen Amazon Solution Architects (I haven’t worked with any from the other cloud providers) not recommend this practice, but go along with it if the organization is already moving that way. I don’t blame them, their job is to reduce friction and get customer workloads on AWS and changing this mindset is extremely difficult even in the best of circumstances.

Here is where you should start instead:

• Accept that any given project will have multiple cloud accounts to reduce the blast radius. 2-4 is average, with dev/test/prod being separated and a shared services account. This allows developers incredible latitude to work with the tools and configurations they need while still protecting production environments and data as you pare down the number of people with administrative level privileges.
  • I usually use “scope of admin” to define where you need to draw the account boundaries.
• If you need to connect back into the datacenter you still don’t need one big cloud account — use what I call a “bastion” account (Amazon calls these transit VPCs). This is the pipe back to your data center and then you peer your other accounts off of it.
• You still might want/need one shared account for some workloads and that’s okay. Just don’t make it the center of your strategy.
• A common issue, especially in financial services clients, is that outbound SSH is restricted from the corporate network. Thus the organization assumes they need to have a direct/VPN connection to the cloud network to enable remote access. You can get around this with jump boxes, software VPNs, and those bastion accounts/networks.
• Another common concern is that you need a direct connection to manage security and other enterprise controls. In reality I find this is rarely the case since you shouldn’t be using all the same exact tools and technologies anyway. This is more than I can squeeze in this post but you should be adopting more cloud-native architectures and technologies. it isn’t that you are reducing security, on the contrary you are often improving it, but you do need to adjust your existing policies and approaches.

I’ll be writing a lot more on these issues and architectures in the coming weeks. In short if someone tells you to build out a big virtual network that extends your existing network before you move anything to cloud, run away. Fast.

- Rich (0) Comments Subscribe to our daily email digest

from Your Cloud Consultant Probably Sucks