Cloud Architect Nodir Safarov, who leads migration and infrastructure automation for thousands of global clients at SOTI Inc., identifies the architectural failures behind the most common cloud security gaps and the design principles that prevent them.
Enterprise cloud adoption has accelerated faster than enterprise cloud security. As organizations migrate critical workloads to AWS, Azure, and multi-cloud environments, many are discovering that speed and scale have outpaced their security architecture. The result is a growing gap between what companies assume is protected and what actually is.
Most cloud platforms already offer robust native security features. The problem is not the tooling. The problem is architectural: how and when security gets integrated into cloud infrastructure design. In too many organizations, security is layered on after deployments are already running in production, creating vulnerabilities that are expensive to remediate and easy to miss.
We spoke with Nodir Safarov, a Cloud Architect Expert at SOTI Inc., where he leads cloud migration and infrastructure automation initiatives supporting enterprise environments across North America, Europe, and Asia. Drawing on experience from large-scale deployments across multiple industries, Safarov said he repeatedly sees the same architectural missteps create avoidable cloud security gaps, often long before teams recognize the risk. He is known for designing security controls directly into infrastructure-as-code and CI/CD workflows, so teams can enforce consistent guardrails by default rather than relying on post-deployment fixes. In our conversation, Safarov emphasized repeatable design patterns, segmentation, least-privilege access, and audit-ready logging, as the foundations of resilient cloud programs. He added that standardization through code and automation is what makes security sustainable at enterprise scale.
“The patterns repeat across organizations of every size,” Safarov said. “These are systemic issues, and they require architectural solutions. They cannot be patched after the fact.”
The 💜 of EU tech
The latest rumblings from the EU tech scene, a story from our wise ol’ founder Boris, and some questionable AI art. It’s free, every week, in your inbox. Sign up now!
Based on what he has observed across large-scale deployments, here are the five most common cloud security mistakes Safarov encounters, and the design-level approaches he recommends to prevent them before deployment.
1. Treating Security as a Post-Deployment Layer
This is the mistake that enables all the others. Organizations frequently build their cloud infrastructure first and attempt to secure it second. By the time security teams assess a production environment, the architecture has already been designed around assumptions incompatible with a strong security posture: overly permissive access controls, unencrypted data stores, and open network configurations that were intended to be temporary but never got locked down.
The cost of this approach compounds quickly. Retrofitting security onto an existing architecture means modifying live systems, and every modification introduces risk to production stability. In one enterprise environment Safarov assessed, a temporary open access rule created during initial deployment had persisted for months, quietly exposing internal APIs to the public internet. The configuration appeared healthy by every standard monitoring metric. It was only caught during a manual security review that happened to occur before an incident did.
“The best time to implement cloud security best practices is before the first deployment,” Safarov said. “Build it into your blueprints from day one.”
In practice, this means embedding security controls directly into infrastructure-as-code templates. When Safarov designs Terraform modules and CI/CD pipelines, security policies, network segmentation, encryption standards, access controls, and logging configurations are written into the code itself. Every deployment that uses those templates automatically inherits the security posture, reducing the burden on engineering teams while ensuring consistency. Security becomes a default rather than an afterthought.
2. Underinvesting in Disaster Recovery Architecture
High availability and disaster recovery are among the most critical aspects of cloud architecture, yet they are routinely treated as secondary concerns during the initial build phase. Organizations assume that running in the cloud inherently provides resilience. It does, but only if the architecture is deliberately designed to take advantage of it.
The assumption is understandable. Cloud providers offer availability zones, redundancy, and failover capabilities. But those features require intentional architectural decisions to activate. Without deliberate DR planning, a single infrastructure failure can take critical systems offline with no clear recovery path. The business impact ranges from lost revenue to regulatory penalties, depending on the industry and the duration of the outage.
Safarov has encountered organizations that documented disaster recovery plans but never tested them against their actual infrastructure. When an incident occurred, the recovery procedures assumed configurations that had drifted months earlier, and the recovery plan failed at the first step.
“Every company needs a Plan B for disaster recovery,” Safarov said. “Cloud architects are the ones who oversee that planning and execute it before the first incident occurs. The middle of an outage is the worst time to discover your recovery strategy exists only on paper.”
His approach treats DR as an architectural requirement on par with performance and scalability. Recovery capabilities are built into the foundation and validated through regular testing, not documented once in a compliance checklist and forgotten.
3. Ignoring Cost as an Architectural Constraint
Cloud cost optimization is often siloed as a finance concern, separate from architecture decisions. In reality, cost is architecture. When engineering teams over-provision resources to maintain generous safety margins, or spin up instances without lifecycle policies, waste compounds rapidly across an enterprise. At scale, those margins become one of the highest hidden costs in a cloud program.
The financial impact is significant and self-reinforcing. Organizations that treat cost optimization as an afterthought find themselves locked into architectures that are expensive to maintain and difficult to restructure. Right-sizing resources after the fact means rearchitecting production systems, a far more expensive and disruptive process than designing for efficiency from the start.
Safarov’s experience in enterprise finance before transitioning to cloud architecture gives him a distinctive vantage point on this problem. He approaches resource allocation as a design constraint, not an operational cleanup task.
“Architectures must be high-performing and resilient, but also financially efficient,” Safarov said. “Optimizing resource allocation is a design principle. Ignoring it leads to waste that compounds at enterprise scale, and by the time organizations notice, the cost of correction is significant.”
The fix starts at the design phase. When cost efficiency is treated as a core architectural requirement alongside performance and resilience, every resource decision is intentional. Assets are right-sized from the start, monitored continuously, and justified by the workload they support.
4. Allowing Configuration Drift Through Manual Changes
When cloud infrastructure is configured manually, through console clicks, ad hoc scripts, or undocumented changes, environments inevitably drift from their intended state. What starts as a minor deviation becomes a significant security vulnerability over time, as production configurations diverge from the security baselines they were designed to meet.
Configuration drift is particularly dangerous because it is invisible. Standard monitoring tools track uptime and performance, not whether a security group rule matches the original Terraform specification. The environment may appear healthy by every dashboard metric while harboring misconfigurations that weaken security boundaries or grant unintended access. In multi-tenant enterprise environments, where hundreds of client deployments share underlying infrastructure patterns, a single drifted configuration can cascade across environments before anyone notices.
The solution is infrastructure-as-code and automated CI/CD pipelines that enforce consistency and auditability across every environment. When all infrastructure changes flow through version-controlled Terraform configurations, every modification is documented, reviewed, and reproducible. Drift becomes detectable, and unauthorized changes trigger automated alerts.
Safarov implements this approach through standardized IaC templates and pipeline automation that eliminate manual intervention in production environments. The result is infrastructure that matches its documented design at all times: consistent, auditable, and reliable across every deployment.
5. Relying on Point-in-Time Security Assessments
The final mistake is assuming that a secure deployment remains secure. Cloud environments are dynamic: workloads scale, configurations update, new services are added, and threat landscapes evolve. A security posture assessed at deployment time degrades steadily unless it is actively maintained through continuous monitoring.
Many enterprises rely on periodic security audits or quarterly assessments. These provide valuable snapshots but miss the threats that emerge between assessments: temporary access permissions that become permanent, test configurations that reach production unchanged, and incremental changes that quietly weaken the original security design. In fast-moving enterprise environments where deployments happen daily, quarterly assessments leave months of unmonitored exposure.
Safarov designs cloud systems with continuous monitoring and automated detection built into the architecture. Rather than relying on periodic human review, his systems use automated alerting to detect configuration anomalies, access pattern changes, and policy violations as they occur. When a new resource is deployed outside the approved IaC pipeline, the monitoring layer flags it immediately rather than waiting for the next scheduled audit.
“Security is a continuous process, and the architecture should enforce that,” Safarov said. “If your monitoring only tells you what happened last quarter, you are always reacting to problems that have already caused damage.”
The Common Thread
Across all five of these mistakes, the root cause is the same: treating security as a layer rather than a principle. When security is a layer, it can be skipped, deferred, or underfunded. When security is an architectural principle, it is embedded in every template, every pipeline, and every design decision from the first line of code.
Reliability, security, and cost efficiency are not competing priorities. They are interdependent, and the strongest cloud architectures treat them as a single design challenge. The organizations that get this right build security into their foundations. The organizations that get it wrong spend years and significant resources trying to retrofit what should have been there from the start.
