Starting out in cloud can look simple from the outside: learn AWS, Azure or Google Cloud, understand a few services, and start deploying. But once you start working with real infrastructure, you discover that knowing how to use a platform is only part of the journey.
The hardest part usually isn't learning what each service does, but understanding why to choose one option over another, and what consequences that decision will have months or years down the line.
Cloud isn't just about moving servers to the internet
One of the first things that would have been useful to understand earlier is that cloud doesn't simply mean moving servers to the cloud. Behind every environment there are decisions about architecture, security, cost, scalability and maintenance.
At first it's easy to focus on getting an application to work: deploy it, connect it, see it running. But in real environments, much bigger questions come up: will it be able to grow without redoing the architecture?, what happens if a component fails?, how do we control access?, will the cost still be reasonable a year from now?
Over time you learn that designing well from the start avoids a lot of problems once the infrastructure starts to grow.
I wouldn't start by thinking only about "how do we get this running". I'd first define how we want it to evolve: which parts need to scale, what we need to monitor, and which decisions could limit the future.
Security doesn't start when a problem appears
When you're starting out, it's common to think security mainly means configuring permissions, firewalls and backups. The reality is that it has to be part of the entire infrastructure lifecycle.
One of the first lessons you learn is that many vulnerabilities don't come from a lack of tools, but from small decisions made too quickly: overly broad permissions, resources exposed unnecessarily, or configurations nobody reviews afterward.
Security in cloud isn't a final step before going to production. It's a way of designing from the start.
I'd treat security as part of the architecture, not as a review that comes afterward.
From day one I'd apply measures that often get left for later: correctly defining permissions for every user and service, applying the principle of least privilege, separating development and production environments, enabling activity logs to know what's happening in the infrastructure, and setting up periodic configuration reviews.
Cost is part of the architecture too
Another important lesson arrives when you discover that in cloud, it's not just about something working — it's about how much it costs to keep it working.
One of cloud's great advantages is being able to create resources quickly. But that same ease can lead to an accumulation of environments, services or capacity that stop making sense over time.
Optimizing cost isn't just about saving money. It's about understanding what resources you need, when you need them, and whether they're still delivering value.
That's why concepts like FinOps, monitoring and continuous review become just as important as the purely technical side.
I'd set up consumption alerts from day one, review active services periodically, and check whether each resource is still needed and still delivering value. In cloud it's easy to create resources for a one-off need and forget about them once they stop being useful.
Reviewing actual service usage every month lets you spot underused resources, adjust capacity, and make sure spending stays aligned with the business's needs. Optimizing cost doesn't mean using fewer resources — it means using the right resources for each need.
The mindset that changes with experience
If you're just starting out in cloud, it's normal to feel like there are too many tools, services and concepts to learn. But it's not about knowing everything from day one — it's about learning to make better decisions.
With experience you discover the question changes. At first you're trying to figure out "how can I do this". Later you start asking "what's the simplest, safest and most efficient way to do this".
A good infrastructure isn't just one that works: it's one that can be maintained, protected, scaled and optimized over time.
And that shift in mindset is often one of the most important parts of the journey.
Cloud isn't about knowing every available service. It's about learning to make good decisions with them.
If you ever need support designing, reviewing or optimizing your cloud environment, we'd be happy to help.