Moving infrastructure to the cloud is no longer an unusual technology decision. The more difficult question is what the resulting environment should actually look like.
An organisation might use public cloud infrastructure for new applications while retaining legacy workloads elsewhere. It might favour managed platform services over virtual machines, operate across more than one cloud provider or maintain a hybrid environment connecting cloud and on-premises systems.
There is no single architecture that represents “being in the cloud”.
And simply reproducing an existing data-centre environment on cloud infrastructure can miss many of the benefits the model is capable of providing.
The National Cyber Security Centre (NCSC), for example, recommends adapting security and architecture to the cloud rather than treating a cloud platform like another traditional data centre. It specifically encourages organisations to consider managed services and cloud-native approaches where appropriate.
That gives IT teams a useful starting question: What infrastructure does each workload actually need?
The answer should drive architecture, security, resilience, performance and cost – rather than forcing every application into the same cloud model.
Start with Workloads, Not Cloud Providers
Selecting a major cloud platform can feel like the first infrastructure decision. It should usually come later.
Begin by understanding the applications, services and data that the infrastructure needs to support.
Some workloads may be relatively straightforward to migrate. Others might have dependencies on legacy applications, databases, hardware or networking. Some may benefit from redesigning around cloud-native services rather than being transferred largely unchanged.
Dorset Software provides architecture, migration and software-development capabilities across AWS, Microsoft Azure and Google Cloud, and describes its approach as identifying what works for the client’s individual situation rather than promoting one particular technology.
That workload-first approach helps prevent the cloud platform becoming the strategy.
The platform is infrastructure. The workload determines what infrastructure is appropriate.
Understand IaaS, PaaS and Managed Services
Infrastructure as a Service gives organisations access to fundamental computing, storage and networking resources without owning the underlying physical infrastructure.
But it can still leave considerable responsibility with the customer.
The NCSC’s shared responsibility guidance explains that IaaS users can remain responsible for areas including operating systems and the applications they run, depending on the service. It recommends identifying components that can appropriately be replaced with managed services, including storage, identity, logging and monitoring.
Platform as a Service and serverless technologies can move more operational responsibility towards the cloud provider.
That can reduce the infrastructure an internal IT team needs to patch, maintain and monitor.
But greater abstraction can also create different dependencies and potentially greater technical lock-in.
The objective should not therefore be to maximise or minimise IaaS.
It should be to place operational responsibility where it can be managed most effectively.
Don’t Simply Lift and Shift Everything
Migration can sometimes mean moving an existing workload to cloud infrastructure with relatively limited architectural change.
There are legitimate reasons to do this.
It may accelerate a data-centre exit, reduce immediate migration complexity or provide an intermediate stage in a longer modernisation programme.
But lift-and-shift should be a conscious decision rather than the default definition of cloud migration.
The NCSC specifically warns that using a cloud platform like another data centre can create security problems and recommends adapting architecture to make use of cloud-native capabilities.
For each workload, IT teams can consider whether to retain, migrate, re-platform, refactor, replace or retire it.
Sometimes the best cloud migration is deciding that an application should not be migrated at all.
Design for Resilience
Cloud infrastructure does not automatically make an application resilient.
Availability depends on how the service is designed.
IT teams should understand what happens if an individual component, availability zone, network connection or wider service becomes unavailable.
Critical workloads may require redundancy across different locations or other architectural measures appropriate to their recovery requirements.
But resilience has a cost.
Not every application requires the same recovery time, recovery point or level of redundancy.
The architecture should therefore reflect business impact.
Ask: How long can this service realistically be unavailable, and how much data could the organisation afford to lose?
Those answers are more useful than simply specifying “high availability”.
Understand Shared Security Responsibility
Moving infrastructure to a cloud provider transfers some security responsibilities. It does not transfer all of them.
The NCSC describes cloud security as a shared responsibility between customer and provider, with the balance changing according to the service and deployment model. Customers remain responsible for ensuring the service meets their security needs, configuring the services they use securely and deciding what data they place within them.
That distinction should be explicit during procurement and architecture design.
Who patches the operating system?
Who configures identity?
Who monitors suspicious activity?
Who protects data?
Who responds to an incident?
Who maintains backups?
Who is responsible for each network and application control?
Protrona specialises in cybersecurity and managed services and holds Microsoft’s Cloud Security Specialization alongside wider security and compliance accreditations. Its proposition combines continuous monitoring, threat protection, security operations and governance designed to strengthen resilience across digital environments.
The important principle is simple:
Never assume the provider is responsible for something because the workload is in the cloud.
Know where the responsibility sits.
Make Identity Part of the Infrastructure
Traditional infrastructure security often placed considerable emphasis on the network perimeter.
Cloud environments make identity increasingly important. Users, administrators, applications and automated services may all require access to cloud resources.
The NCSC’s Cloud Security Principles say access to service interfaces should be constrained to securely authenticated and authorised identities and that providers should support secure user management and role-based access controls.
IT teams should consider least-privilege access, strong authentication, privileged administration, service identities and how access is removed when it is no longer required.
Identity is not simply an application-layer concern.
In cloud environments, it is part of the infrastructure architecture.
Protect Data by Design
Where will data be stored?
Where will it be processed?
How will it move between services?
Who can access it?
How is it encrypted?
How long will it be retained?
The NCSC recommends protecting cloud data both at rest and in transit, understanding where it is stored and processed, and using retention policies to remove data when it is no longer required.
Those questions become particularly important where workloads process personal, commercially sensitive or regulated information.
Security requirements should therefore be mapped to workloads and data before migration rather than applied as a generic layer afterwards.
Plan Connectivity Carefully
Cloud applications still need networks.
Users may need to access services. Cloud workloads may need to communicate with one another. Hybrid environments may require reliable connections between cloud platforms and existing sites or data centres.
Poor network design can undermine an otherwise well-designed cloud architecture.
IT teams should consider bandwidth, latency, redundancy, routing and security alongside the compute and storage environment.
They should also understand what happens to business-critical services if connectivity between the organisation and its cloud environment is interrupted.
A workload may be resilient inside the cloud platform while remaining inaccessible to the people who need it.
Build Observability In
Traditional infrastructure teams may monitor servers, storage and networks.
Cloud environments can contain considerably more dynamic resources.
Effective observability can therefore require infrastructure metrics, application telemetry, logs, security events and cost information to be brought together.
The NCSC’s Cloud Security Principles specifically identify audit information and security alerting as capabilities customers should expect from cloud services.
Monitoring should answer practical questions.
Is the service available?
Is it performing normally?
Is capacity becoming constrained?
Has something changed unexpectedly?
Is suspicious activity occurring?
Are costs moving outside expectations?
The goal is not to collect every possible metric.
It is to make abnormal behaviour visible quickly enough to act.
Design for Scalability – But Control It
One of cloud infrastructure’s major advantages is the ability to increase and decrease resources without buying physical hardware each time demand changes.
That can support rapid growth and variable workloads.
But scalability works in both technical and financial terms.
Infrastructure that can expand automatically can also increase expenditure automatically.
IT teams should understand what triggers scaling, what limits are in place and whether applications actually benefit from additional resources.
A badly designed application does not necessarily become efficient simply because more cloud capacity can be assigned to it.
Cloud scalability should respond to useful demand rather than conceal inefficient architecture.
Treat Cost as an Architectural Metric
The cost model for cloud infrastructure is different from buying servers and depreciating them over several years.
Compute, storage, networking, managed services and data movement can all contribute to ongoing consumption.
That means architecture decisions can have direct financial consequences.
IT teams should therefore make cost visible alongside availability, performance and security.
Which workloads consume the most?
Are resources running when they are not required?
Is storage being retained unnecessarily?
Are services appropriately sized?
Would a more managed architecture reduce operational effort enough to justify a different consumption cost?
Cloud optimisation should not mean simply making everything cheaper.
It means ensuring expenditure reflects the value and requirements of the workloads being supported.
Consider Portability Without Designing for an Imaginary Future
Vendor lock-in is frequently raised during cloud procurement.
It is a legitimate consideration, but avoiding every provider-specific service can also prevent organisations from taking advantage of capabilities that make cloud worthwhile.
The NCSC notes that cloud-native services such as SaaS and serverless technologies can involve greater technical lock-in, but also points out that IaaS and container-based architectures are not free from lock-in either. Its recommendation is to understand the value received in exchange for that dependency.
For each workload, ask how important portability genuinely is.
A system expected to move between providers regularly may justify a different architecture from a stable workload for which managed cloud services substantially reduce operational burden.
Don’t pay permanently for portability that the organisation is unlikely ever to use.
Decide Who Will Operate the Environment
Cloud infrastructure still needs people.
Architecture needs to evolve. Configurations need to be controlled. Security events need investigation. Costs need monitoring. Applications need supporting.
Some organisations will retain those capabilities internally. Others may use specialist partners, while many will adopt a co-managed model.
Protrona’s managed-services and cybersecurity capabilities focus particularly on ongoing security, monitoring, compliance and resilience.
Dorset Software provides architecture, software engineering, infrastructure and workflow automation, migration and ongoing technical support, including experience across AWS, Azure and Google Cloud.
The key procurement question is not simply who builds the environment.
It is who will be responsible for keeping it effective six months, two years and five years later.
Plan Migration as a Business Change
Infrastructure migration can affect applications, users, integrations, security controls and operating processes.
Moving workloads therefore requires more than copying data.
Dependencies need to be identified. Testing needs to demonstrate that services continue working as intended. Users and support teams may need new processes, and rollback arrangements should exist where migration does not proceed as expected.
Dorset Software’s cloud migration services include migration analysis and architecture alongside implementation, reflecting the need to understand the existing environment before moving it.
The most technically elegant target architecture is of little value if the organisation cannot reach it safely.
Questions to Ask Cloud Infrastructure Providers
IT teams should consider asking:
- How will you assess which workloads are suitable for migration?
- Which workloads should be retained, re-platformed, refactored or replaced?
- Which cloud service and deployment models do you recommend, and why?
- How will resilience requirements be translated into architecture?
- What responsibilities remain with our internal IT team?
- How will identities and privileged access be managed?
- How will data be protected at rest and in transit?
- Where will our data be stored and processed?
- How will cloud resources connect to existing systems and locations?
- Which monitoring, logging and alerting capabilities are included?
- How will infrastructure costs be monitored and controlled?
- How will the environment scale with demand?
- What provider-specific dependencies will the architecture create?
- How will migration be tested and validated?
- What ongoing management and optimisation will be required?
- How would workloads be recovered following a significant outage?
- How will the architecture evolve as our requirements change?
Frequently Asked Questions
What is cloud infrastructure?
Cloud infrastructure refers to computing, storage, networking and associated platform resources delivered through cloud services rather than infrastructure owned and operated entirely within an organisation’s own data centre.
What is the difference between IaaS and PaaS?
Infrastructure as a Service provides fundamental resources such as compute, storage and networking while leaving customers responsible for more of the software stack. Platform as a Service typically transfers more infrastructure and platform management to the provider. Exact responsibilities vary between services.
Is cloud infrastructure more secure than on-premises infrastructure?
Neither model is automatically secure. Cloud providers can offer significant security capabilities, but customers remain responsible for areas including choosing appropriate services and configuring their environment correctly. The NCSC recommends assessing providers against security requirements and understanding the shared responsibility model.
What is hybrid cloud infrastructure?
A hybrid environment combines cloud services with infrastructure or workloads operating elsewhere, such as an organisation’s own data centre. The different environments need appropriate connectivity, security, identity and operational management.
Should businesses use more than one cloud provider?
Multi-cloud can be appropriate where there is a clear business, technical or resilience requirement, but it can also increase operational complexity. Organisations should establish what problem using multiple providers solves rather than treating multi-cloud as an objective in itself.
Product & Services Guide
Protrona
Cybersecurity and managed-services provider focused on helping organisations protect and manage digital environments. Protrona holds Microsoft Partner accreditations including Cloud Security Specialization and provides capabilities spanning managed services, security operations and testing, continuous monitoring, governance and compliance.
Website: https://www.protrona.com/
Dorset Software
UK software engineering and technology consultancy supporting public and private-sector organisations. Its capabilities include cloud architecture and migration, software development, infrastructure and workflow automation and technical support, with experience across AWS, Microsoft Azure and Google Cloud.
Website: https://www.dorsetsoftware.com/
Build Around the Workload
The strongest cloud infrastructure strategy does not begin with a provider logo or a declaration that everything must move to the cloud.
It follows a more useful sequence: workload → requirements → architecture → responsibility → operation → optimisation
- Understand the workload.
- Define its security, availability, performance and data requirements.
- Choose an architecture capable of meeting them.
- Make responsibility explicit.
- Operate the environment effectively.
- Then keep optimising it as technology and business requirements change.
Cloud infrastructure should remove constraints where possible, not simply relocate them.
The Cyber Secure Forum and Elevate.Tech Summit events connect senior IT and cybersecurity decision-makers with relevant solution providers through pre-arranged one-to-one meetings, providing an opportunity to explore cloud infrastructure, cybersecurity, managed services and other technologies shaping modern enterprise IT.
Related Reading
This is the first article in our October Cloud Infrastructure series.
Last month’s standalone feature examined the broader managed cloud hosting versus in-house infrastructure decision. This October series starts from the next stage: assuming cloud forms part of the organisation’s infrastructure strategy, how should that environment be designed and operated?
The follow-up will focus on cloud infrastructure optimisation – how IT teams can improve performance, resilience, security and cost once workloads are running in the cloud.
Sources
- NCSC – Cloud Security Guidance – https://www.ncsc.gov.uk/collection/cloud
- NCSC – Cloud Security Shared Responsibility Model – https://www.ncsc.gov.uk/collection/cloud/understanding-cloud-services/cloud-security-shared-responsibility-model
- NCSC – Using a Cloud Platform Securely – https://www.ncsc.gov.uk/collection/cloud/using-cloud-services-securely/using-a-cloud-platform-securely
- NCSC – Cloud Security Principles – https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles
- NCSC – Choosing a Cloud Provider – https://www.ncsc.gov.uk/collection/cloud/choosing-a-cloud-provider
- Protrona – https://www.protrona.com/
- Dorset Software – https://www.dorsetsoftware.com/
Image credit: https://unsplash.com/photos/woman-in-blue-shirt-sitting-on-chair-in-front-of-computer-8KXcmwGg8CU
