04Service line
Cloud services: architecture, migration, engineering, security and operations
Onion Infosec plans, builds, secures and runs cloud environments on Azure, AWS and Google Cloud. Landing zones, platforms and migrations are delivered as code, with identity guardrails, policy as code and control-plane logging in place before the first production workload arrives.
- Line
- 04 of 07 · Cloud
- Shape
- Strategy → Migrate → Engineer → Secure → Operate
- Delivery
- Project, retainer or managed service
01Context
What the cloud service line covers
The line covers cloud work from the first architecture decision to daily operations: strategy and landing zone design, workload migration, Kubernetes and platform engineering, infrastructure as code, monitoring, cost management, and backup and disaster recovery.
Cloud security is part of the same line. The team that designs a landing zone also designs its identity model, guardrails and logging, and the team that assesses a cloud estate can also remediate it. Work is carried out on Azure, AWS and Google Cloud, in single-cloud, multi-cloud and hybrid estates.
- Hand-built environments cannot be reviewed or rebuilt
- Infrastructure defined as code can be reviewed, tested and recreated. Infrastructure built in a console depends on memory, and it drifts from whatever was documented.
- Most cloud security failures are configuration and identity failures
- Over-privileged identities, public storage, exposed keys and unmonitored control planes are the common causes. They are prevented by guardrails and monitoring that run continuously. An annual review does not keep pace with daily change.
- Cost is an engineering output
- Spend follows architecture, sizing and scheduling decisions. Without tagging, budgets and regular review, the bill grows faster than usage.
Architecture
A platform engineered in layers.
A migration moves workloads. A platform is what they land on. Each layer is designed, delivered as code and operated, and three concerns run through all of them from the first day.
A cloud platform drawn as six layers: applications and APIs, platform services such as Kubernetes, containers and serverless, data, identity and access, network and landing zone, and the cloud platform itself on Azure, AWS or Google Cloud. Infrastructure as code and CI/CD deliver into every layer. Security, observability and operations run through every layer. Architecture covers platform services, identity, network and the cloud platform. Engineering covers delivery, applications and platform services. Security covers the security pillar, data, identity and network. Operations covers observability, operations and data.
Infrastructure as code
CI/CD pipelines deliver every layer from reviewed code.
- Applications and APIsWeb, mobile and SaaS workloads
- Platform servicesKubernetes · containers · serverless
- DataDatabases · storage · backup and disaster recovery
- Identity and accessLeast-privilege IAM · Entra ID
- NetworkLanding zone · segmentation · connectivity
- Cloud platformAzure · AWS · Google Cloud
Security
- Guardrails
- Policy as code
- Posture management
- Cloud detection
Observability
- Logging
- Monitoring
- Alerting
Operations
- Patching
- Cost optimization
- Recovery testing
02Approach
How we work in the cloud
Every engagement starts from the current state: workloads, dependencies, identities, data, cost and constraints. The target design models security, resilience and cost before anything moves. Guardrails come first. Identity architecture, policy as code and control-plane logging are deployed before production workloads arrive.
Everything is delivered as code in your repositories, through pipelines, with changes reviewed in pull requests. Migrations run in waves, each with validation and a rollback plan. At the end you can take full handover, or keep us for operations under a managed service.
01
Everything as code
Landing zones, networks, policies, clusters and dashboards are defined in Terraform, Bicep or an equivalent, versioned and deployed by pipeline.
02
Guardrails before workloads
Preventive policies, least-privilege roles and audit logging are in place before teams deploy, so the secure configuration is also the default one.
03
Identity is the perimeter
Human and workload identities are federated, short-lived and scoped. Long-lived keys are removed wherever the platform offers an alternative.
04
Design for operation and cost
Tagging, budgets, service-level objectives and runbooks are part of the build. A platform that nobody can operate or afford is not finished.
03Capabilities
How cloud work is organized.
Strategy
Decide what moves, where it lands and why.
Migrate
Move workloads in validated waves.
Engineer
Build platforms as code.
Secure
Guardrails, identity and posture from the first workload.
Operate
Run, observe, optimize and recover.
Cloud strategy and architecture
Decisions that are expensive to reverse: platform choice, account structure, network topology and identity model. Output is a design that engineers can build from and auditors can read.
- Cloud readiness assessmentReview of applications, infrastructure, skills, contracts and compliance constraints. Produces a readiness rating per workload and a list of blockers.
- Cloud strategy and business casePlatform selection, operating model and a cost model that compares current and target run costs, with the assumptions stated.
- Landing zone designAccount, subscription or project hierarchy, network topology, identity integration, policy baseline and logging design, aligned with the provider’s reference architecture.
- Cloud network architectureHub-and-spoke or mesh topologies, private connectivity, DNS, egress control and hybrid links to data centers and branch sites.
- Multi-cloud and hybrid architecturePatterns for organizations that run more than one cloud or keep workloads on premises, covering identity, networking, observability and governance across them.
- Well-architected reviewAssessment of an existing workload against the provider’s well-architected framework, with findings ranked by risk and effort.
Cloud migration
Planned movement of workloads and data, in waves, with validation at each step. Rehost where it is sensible, re-architect where it pays back.
- Discovery and dependency mappingInventory of servers, applications, databases and the connections between them, used to group workloads into migration waves.
- Migration planningA wave plan that assigns each workload a strategy (rehost, replatform, refactor, replace or retire) with cutover windows, owners and rollback criteria.
- Workload migrationExecution of server, application and storage moves using native migration services, with testing and sign-off for each wave.
- Database migrationHomogeneous and heterogeneous database moves to managed services, with schema conversion, replication, reconciliation and a rehearsed cutover.
- Data center exitProgram management and engineering for a full exit from a hosting facility, including network cutover, decommissioning and alignment with contract end dates.
- Post-migration validationPerformance, security posture and cost review after each wave. Issues are remediated before the next wave begins.
Cloud-native and platform engineering
Platforms that let development teams deploy on their own inside safe boundaries. Built on containers, serverless services and infrastructure as code.
- Infrastructure as codeTerraform, Bicep, CloudFormation or Pulumi implementations with module standards, remote state, drift detection and pipeline deployment.
- Kubernetes platform engineeringDesign, build and upgrade of AKS, EKS and GKE clusters, including node strategy, ingress, autoscaling, GitOps deployment and multi-tenancy.
- ContainerizationPackaging of applications as container images with minimal base images, reproducible builds, registry management and image scanning.
- Serverless and event-driven architectureFunctions, managed queues, event buses and workflow services, used to build systems that scale with demand and carry no idle compute.
- Internal developer platformSelf-service templates, golden paths and a service catalog that let teams create compliant environments and pipelines without raising tickets.
- CI/CD for infrastructure and applicationsPipelines that plan, test, scan and apply changes, with approvals, environment promotion and rollback.
- Managed data and integration servicesProvisioning and configuration of managed databases, caches, messaging and API gateways, including network isolation, backup and scaling settings.
Cloud security
Assessment, architecture and ongoing defense for cloud environments. Findings are prioritized by attack path, and remediation is carried out with your platform team.
- Cloud security assessmentFull-environment review of Azure, AWS or Google Cloud against CIS Benchmarks and provider security guidance, prioritized by exploitability.
- Cloud IAM and entitlementsMapping of effective permissions and privilege-escalation paths for human and workload identities, followed by least-privilege remediation.
- CSPM implementationSelection, deployment and tuning of cloud security posture management, with ownership routing so that findings reach the team that can fix them.
- CNAPP and workload protectionProtection for virtual machines, containers and serverless workloads: vulnerability management, runtime controls, and correlation of posture, identity and workload findings.
- Container and Kubernetes securityCluster hardening, RBAC, admission control, network policy, secrets handling and image supply chain controls.
- Guardrails and policy as codePreventive controls using Azure Policy, AWS service control policies, Google Cloud organization policies and Open Policy Agent, plus infrastructure code checks in the pipeline.
- Cloud logging and detectionAudit and telemetry architecture for the control plane, and detection content for identity abuse, control-plane changes and data exfiltration.
Cloud operations and monitoring
Day-to-day running of cloud environments, by runbook and by automation. Available as a project that sets up operations for your team, or as a managed service with 24×7 support.
- Managed cloud operationsProvisioning, patching, scaling, access requests and change management for cloud environments under an agreed operating model.
- Monitoring and observabilityMetrics, logs and traces collected with native services or OpenTelemetry, with dashboards and alerting tied to service-level objectives.
- Site reliability engineeringService-level objectives, error budgets, incident review and toil reduction for services that need defined reliability targets.
- Patch and configuration managementScheduled patching of operating systems and managed services, configuration baselines and drift correction.
- Operations automationScripts, runbook automation and scheduled jobs that remove repetitive operational work and produce compliance evidence as a by-product.
- Cloud governanceTagging standards, naming, resource lifecycle, access reviews and policy exceptions, with reports for resource owners.
Cloud cost optimization
FinOps practice applied by engineers who can make the changes. Every recommendation states its expected effect on cost, performance and risk.
- Cost visibility and allocationTagging, account structure and showback or chargeback reports that attribute spend to teams, products and environments.
- Rightsizing and schedulingUtilization analysis used to resize or remove resources and to shut down non-production environments outside working hours.
- Commitment planningModeling of reserved instances, savings plans and committed use discounts against actual usage patterns, with a purchase recommendation and a review cadence.
- Architecture-led optimizationChanges to storage tiers, data transfer paths, autoscaling and service choices where the design itself drives cost.
- Budgets and anomaly alertsBudgets, forecasts and anomaly detection configured per owner, so that unexpected spend is noticed before the invoice arrives.
- Kubernetes cost managementTuning of requests and limits, node pool strategy, spot capacity and per-namespace cost reporting for clusters.
Backup and disaster recovery
Recovery designed from business requirements and proven by test. Backups are protected against the same credentials and failures that threaten production.
- Recovery objectives and impact analysisWorkshops that set recovery time and recovery point objectives per application. Those objectives then drive design and cost.
- Backup architectureBackup policy, retention, encryption and cross-region or cross-account copies for virtual machines, databases, file stores and SaaS data.
- Immutable and isolated backupsWrite-once storage, separate accounts and restricted roles that keep backups recoverable after ransomware or compromise of an administrator account.
- Disaster recovery designPilot light, warm standby or active-active patterns selected per workload, with infrastructure code that can rebuild the environment in a second region.
- Recovery testingPlanned restore and failover exercises with measured recovery times, a written report and fixes for whatever did not work.
- Resilience reviewAssessment of single points of failure, zone and region dependencies, service quotas and third-party dependencies for critical services.
04Process
How a cloud engagement runs.
Assess
Review workloads, dependencies, identities, data, costs and constraints in the current environment.
Architect
Produce the target design, with security, resilience and cost modeled before anything moves.
Build guardrails and platform
Deliver the landing zone, identity model, policy as code, logging and pipelines as code.
Migrate or deploy
Move workloads in waves, or deploy new ones, with validation and a rollback plan at each step.
Operate
Run the environment by runbook and automation, with monitoring tied to service-level objectives.
Optimize
Review cost, posture, performance and resilience on a fixed cadence, and feed changes back into code.
What you receive
- Current-state assessment and target architecture
- Migration wave plan with cutover and rollback runbooks
- Landing zone, network and platform delivered as reviewable code
- Identity design, guardrail policies and control-plane logging configuration
- CI/CD pipelines with infrastructure security checks
- Observability dashboards and alerting tied to service-level objectives
- Cost allocation model and optimization report
- Backup and disaster recovery design with recovery test results
05Technical depth
Typical cloud engagements, technology and methods.
Cloud readiness and architecture assessment
A short, fixed-scope review that ends with a target architecture, a migration approach and a cost model.
Landing zone build
A project that delivers account structure, networking, identity, guardrails, logging and pipelines as code, ready for the first workload.
Migration program
A multi-phase program run in waves. Each wave has its own plan, validation and rollback, and the program ends with decommissioning of the source environment.
Cloud security assessment and remediation
A fixed-scope assessment followed by a remediation phase carried out with your platform team. Ends with guardrails that stop the findings from recurring.
Cost optimization review
A time-boxed analysis of spend and architecture with a ranked list of changes. Implementation can follow as a separate phase.
Managed cloud operations
An ongoing managed service covering operations, monitoring, patching, cost review and security posture, with 24×7 support.
Technology areas
Platforms
Infrastructure as code
Containers and platform
Security and policy
Observability
Backup and cost
Technologies are named to describe the work. Naming a product does not indicate a commercial partnership.
Frameworks and methods
Provider well-architected frameworks
Azure, AWS and Google Cloud well-architected guidance, used as the review structure for reliability, security, cost, operations and performance.
Cloud adoption frameworks
Provider adoption frameworks and landing zone reference architectures, used as the starting point for account structure and governance design.
CIS Benchmarks
Configuration baselines for cloud accounts, operating systems and Kubernetes, used in assessments and encoded as policy.
CSA Cloud Controls Matrix
Control framework for cloud, used to map shared responsibility and to answer customer assurance questionnaires.
NIST SP 800-53 and NIST CSF
Control catalog and outcome framework, used where a cloud estate must map to an enterprise control set.
ISO/IEC 27017 and ISO/IEC 27018
Cloud-specific guidance on security controls and protection of personal data, applied alongside ISO/IEC 27001 readiness work.
FinOps Framework
Practice model for cloud cost management across the inform, optimize and operate phases.
MITRE ATT&CK Cloud Matrix
Reference for cloud detection coverage and for prioritizing assessment findings by attack technique.
06Across lines
Guardrails, policy as code and logging are in place from day one.
Cloud engineering at Onion Infosec is done together with the cloud security team instead of being reviewed by it afterwards. Landing zones ship with least-privilege identity, preventive policies and control-plane logging. Infrastructure code is scanned in the pipeline before it is applied. Logs can feed your security operations or our 24×7 monitoring, and our cloud security specialists can assess and remediate an estate we did not build.
07Questions
Cloud: questions we are asked
The one that fits your workloads, team skills, existing licenses and regulatory constraints. We work on Azure, AWS and Google Cloud, and the strategy engagement compares them against your requirements with the assumptions stated. Often the deciding factor is which platform your team can operate well.
Many can move with little or no downtime using replication, phased cutover and rollback plans. The migration assessment identifies the systems that need a maintenance window or special handling before any dates are committed.
Either. Everything is delivered as code and documentation in your repositories. You can take full handover with training, or keep us for operations under managed services.
Yes. Reviewing Terraform, Bicep or CloudFormation finds misconfigurations before deployment and is often the fastest way to remove a whole class of issues. Checks can then be added to the pipeline so that the same issue does not return.
Yes. Each platform is designed and assessed on its own terms, with identity, networking, logging and governance patterns that work across them. Where workloads stay on premises, our IT team covers the data center and network side.