All articles
Inside the Hidden Labor Cost of Custom Cloud Security Architectures
Philip Asiala, a Senior Principal Enterprise Architect at SAIC, explains how company culture dictates cloud security architecture and its costs more often than technology.
Key Points
For most organizations today, the decision between managed cloud services and a custom DIY security build is a challenging one to make.
Philip Asiala, a Senior Principal Enterprise Architect at SAIC, explains why this decision is dictated almost entirely by company culture and risk tolerance, not technology.
By treating the decision as a business choice and planning for the high labor costs of custom work, leaders can avoid the unexpected expenses of a DIY approach.
In my experience, it's always about the customer's security perception. It isn't just influenced by culture. It's only culture.
*The views and opinions expressed by Philip Asiala are his own and do not necessarily represent those of any organization.
Perhaps unsurprisingly, perceptions of risk often determine the approach to cloud security. For most organizations today, the choice between managed cloud services and DIY is a strategic trade-off between cost, control, and convenience. But at the nexus of that decision is another, less visible influence: culture. Now, how comfortable a company feels with outsourcing its security to a third-party vendor is usually the determining factor.
For some experts, the solution is already apparent. According to Philip Asiala, a Senior Principal Enterprise Architect at SAIC, the situation demands a business-first approach to architecture. With over 15 years of experience in cloud architecture and cybersecurity, Asiala has a rich professional background, including roles as a Cloud Architect for the State of Tennessee and expertise in frameworks like NIST and TIC 3.0. Today, his perspective is informed by extensive work across government and commercial enterprise sectors.
According to Asiala, the choice between MSP and DIY for cloud almost always comes down to customer perceptions and organizational risk tolerance. "It isn't just influenced by culture. It's only culture. Risk tolerance belongs to the product owner—they weigh the risks," Asiala says. "But when they do that risk assessment, there's always a little bit of cultural hesitancy around outsourcing to the cloud vendor." Now, that difference in perception is creating a cultural divide that stands to impact key architectural choices.
A tale of two customers: For Asiala, the contrast is most apparent when comparing the commercial and government sectors. "In my experience, it's always about the customer's security perception. In the commercial space, you see your customers quite readily adopting all of the AWS things right off the shelf, and projects usually go a lot faster."
The choice to use a cloud-native tool is almost always secondary to customer security constraints, Asiala continues. If a bespoke solution is required, the primary consideration becomes a business one: planning for the additional human effort.
The people-powered tax: Most recently, his experience building a DIY solution, which he documented as an eight-part series on Zero Trust, served as a powerful reminder of the real-world labor involved. "My article would have been probably one-fourth the size if I had just integrated AWS Secrets into Kubernetes," Asiala says. "In the cases where the security constraints require rolling your own, we always plan for more labor, because the maintenance of those things can be quite a lift in FTE."
However, this cultural posture is not static, Asiala explains. As familiarity with cloud platforms grows, the benefits become increasingly hard to ignore. Now, the deep-seated reluctance is beginning to change. "Today, it's way better than it used to be. People in government are getting a lot more open to using more cloud-native products now, and, in my opinion, it's for the better."
Beyond these cultural factors, the growing volume of enterprise data has also become a driver of architectural decisions, Asiala says. Often, migration is complicated by legacy systems whose overly permissive, insecure architectures must be addressed with modern, data-driven principles before it is possible.
An inevitable pull: On the subject of "data gravity," Asiala describes a "tipping point where more data is in the cloud," where the mass of data begins to reshape workflows, processes, and integrations. "Once you get to that tipping point where more data is in the cloud than on-prem, then you really see a move to that. Your center of gravity is now the cloud, and it drags everything into it."
For Asiala, the more relevant conflict is the migration from one vendor ecosystem to an open-source-based cloud ecosystem. "The idea of running open source DIY on-prem where you maintain it is not something you see most people willing to do. Instead, enterprises usually use commercial products, and it's a commercial product versus the open-source cloud product."
Ultimately, the conversation landed on financial maturity. The early days of adoption were characterized by "lift and shift" migrations—a model now widely recognized as fast but prohibitively expensive. Today, enterprises understand cloud economics with more sophistication, prompting many leaders to treat cloud spend and security as ongoing responsibilities that require continuous optimization. "They threw their workloads up with lift and shift, and then reality set in that this is expensive," Asiala concludes. "The cloud, not done the cloud way, is always more expensive than on-prem."
