Cloud Security Architecture Best Practices | NILUS

⏱ 5 min read

Cloud has fundamentally transformed enterprise IT and risk management. Traditional perimeter-based security models are insufficient in distributed, API-driven, multi-region cloud environments. Security must evolve from network-centric defense to identity-centric, policy-driven, observable, and automated architecture. Cloud security is not a collection of tools — it is a structural design discipline. enterprise cloud architecture patterns

Security as a design principle

Figure 1: Security architecture across layers — Business, Application, Data, Infrastructure, with Security as cross-cutting concern — **Figure 1:** Security architecture across layers — Business, Application, Data, Infrastructure, with Security as cross-cutting concern

Security must be embedded into business capability models, application architectures, data classification frameworks, infrastructure topologies, and CI/CD pipelines. Security must shape architecture rather than validate it after deployment. When security is a design afterthought, the cost of remediation is 10-100x higher than building it in from the start.

Identity-first architecture (Zero Trust)

Figure 2: Zero Trust identity flow — User to Identity Provider to Policy Engine to Application to Data Store — **Figure 2:** Zero Trust identity flow — User to Identity Provider to Policy Engine to Application to Data Store

Zero Trust means: never trust, always verify. Best practices include centralized identity federation (one IdP, not per-application), MFA enforcement for all human access, RBAC and ABAC authorization, just-in-time privilege elevation (no standing admin access), continuous session validation (not just login-time), and short-lived credentials (tokens expire in minutes, not days). Identity becomes the new perimeter. TOGAF roadmap template

Network segmentation and micro-segmentation

Figure 3: Network segmentation — Internet to WAF to Public Subnet to App Subnet to Data Subnet — **Figure 3:** Network segmentation — Internet to WAF to Public Subnet to App Subnet to Data Subnet

Separate public and private subnets with default-deny network policies. Implement micro-segmentation so that compromising one service does not grant access to adjacent services. Encrypt east-west traffic (service-to-service within the same network). Use software-defined networking controls rather than physical network boundaries. Segmentation reduces breach blast radius — the difference between losing one service and losing the entire platform.

API security architecture

Figure 4: API security — Client to API Gateway to Auth Validation to backend services — **Figure 4:** API security — Client to API Gateway to Auth Validation to backend services

APIs are the new attack surface and must be centrally governed. Implement a centralized API Gateway that handles OAuth2/OIDC token validation, rate limiting and throttling, schema validation (reject malformed requests before they reach services), and logging and monitoring. Every API request must be authenticated, authorized, and logged. The API Gateway becomes both a security enforcement point and a compliance evidence source. modeling integration architecture with ArchiMate

Data protection strategy

Figure 5: Data protection — classification, encryption at rest and in transit, key management, access policies — **Figure 5:** Data protection — classification, encryption at rest and in transit, key management, access policies

Encrypt data at rest and in transit. Use managed key services (AWS KMS, Azure Key Vault, Google Cloud KMS) rather than application-managed keys. Automate key rotation. Separate key storage from data storage. Implement data classification policies that tag every data asset with its sensitivity level — and enforce different protection controls based on classification. Security must follow the data lifecycle from creation through processing, storage, and eventual deletion. hybrid cloud architecture

DevSecOps integration

Figure 6: DevSecOps pipeline — Code Commit to SAST, Dependency Scan, Container Scan, Deployment, Runtime Monitoring — **Figure 6:** DevSecOps pipeline — Code Commit to SAST, Dependency Scan, Container Scan, Deployment, Runtime Monitoring

Security must shift left into development workflows. Every code commit triggers SAST (static analysis for vulnerabilities), dependency scanning (known vulnerabilities in libraries), and container image scanning (vulnerable base images). Infrastructure-as-code and policy-as-code are validated in the pipeline before deployment. Automated security gates block deployment of non-compliant artifacts. Runtime monitoring closes the loop — detecting in production what static analysis missed.

Observability and monitoring

Figure 7: Observability architecture — Applications emitting Logs, Metrics, Traces to SIEM, Monitoring, and APM platforms — **Figure 7:** Observability architecture — Applications emitting Logs, Metrics, Traces to SIEM, Monitoring, and APM platforms

You cannot secure what you cannot observe. The three observability pillars — logs, metrics, and traces — must be designed into every service from the start. Centralized log aggregation with immutable storage prevents tampering. Real-time alerting on security events (failed authentication spikes, unusual access patterns, data exfiltration indicators) enables rapid response. Threat intelligence integration enriches alerts with context about known attack patterns. integration architecture diagram

Incident response architecture

Figure 8: Incident response — Alert to SOC Triage to Containment to Remediation to Lessons Learned — **Figure 8:** Incident response — Alert to SOC Triage to Containment to Remediation to Lessons Learned

Incident response must be architected, not improvised. Predefined response playbooks for common incident types (credential compromise, data breach, DDoS, ransomware) ensure consistent, rapid action. Automated isolation capabilities (revoke credentials, block network segments, quarantine containers) reduce response time from hours to minutes. Immutable infrastructure enables remediation by redeployment rather than forensic cleanup. Post-incident reviews feed improvements back into the security architecture.

Multi-region resilience and IaC governance

Figure 9: Multi-region architecture — Global DNS routing to Region A and Region B with secure VPCs — **Figure 9:** Multi-region architecture — Global DNS routing to Region A and Region B with secure VPCs

Multi-region deployment provides resilience against regional outages and supports data residency requirements. Cross-region replication with encrypted backups ensures recoverability. Defined RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets drive architecture decisions: active-active multi-region for critical services, active-passive for less critical ones.

Figure 10: Infrastructure as Code governance — Developer to Git to CI Pipeline to Policy Check to Cloud Provisioning — **Figure 10:** Infrastructure as Code governance — Developer to Git to CI Pipeline to Policy Check to Cloud Provisioning

All infrastructure must be defined as code, stored in version control, reviewed through pull requests, and deployed through automated pipelines with policy checks. Drift detection identifies when running infrastructure diverges from the code definition. Least-privilege IAM roles ensure that deployment pipelines have only the permissions they need. Infrastructure as Code makes every environment change auditable, reviewable, and reproducible.

Frequently Asked Questions

How is ArchiMate used in cloud architecture?

ArchiMate models cloud architecture using the Technology layer — cloud platforms appear as Technology Services, virtual machines and containers as Technology Nodes, and networks as Communication Networks. The Application layer shows how workloads depend on cloud infrastructure, enabling migration impact analysis.

What is the difference between hybrid cloud and multi-cloud architecture?

Hybrid cloud combines private on-premises infrastructure with public cloud services, typically connected through dedicated networking. Multi-cloud uses services from multiple public cloud providers (AWS, Azure, GCP) to avoid vendor lock-in and optimise workload placement.

How do you model microservices in enterprise architecture?

Microservices are modeled in ArchiMate as Application Components in the Application layer, each exposing Application Services through interfaces. Dependencies between services are shown as Serving relationships, and deployment to containers or cloud platforms is modeled through Assignment to Technology Nodes.