Networking to the cloud

What the cloud looks like through the eyes of the network: the cloud as someone else’s datacenter behind the network and shared responsibility, an open bucket as an open zone, site-to-site and remote-access VPN into the cloud, publishing a service via a public IP and DNAT, a load balancer before a web farm, a cloud DMZ and security groups with default deny, and resilience through multi-WAN, backups and regions.

Lesson 1: The cloud is not magic

The cloud is a datacenter behind the network

The word ‘cloud’ sounds like something ethereal, but it is a very down-to-earth thing: someone else’s datacenter you reach over the network. When you open a cloud account with a provider, you get a slice of compute in their hall and, with it, a virtual network – in English a VPC (virtual private cloud). From the standpoint of your network design there is nothing new under the sun: it is simply another location behind a router, just like a branch in another city. It has its own subnets, its own IP addresses, and it is separated from you by a network you do not own – the internet. And that is exactly why the very rules you know from a physical network apply to it: for your computer to reach a server in the cloud, a usable path must exist (routing) and someone must permit it (a firewall). Nothing flows there by magic. People who know the cloud from the application side – they clicked ‘create a server’ and a minute later it ran – often skip this very layer and wonder why the database will not connect. The answer is almost always the same as in any other network: the path is missing, or the port is closed. In this course we look at the cloud through the eyes of the network, not the developer: where traffic flows, where it is checked and who is responsible for what.

Step by step

The cloud is someone else’s datacenter. Inside you have your own virtual network (VPC) with subnets and addresses – like a branch in another city.
From the company, traffic goes through the switch and firewall into the internet – exactly as with any other remote location.
You enter the VPC through the cloud gateway (CG). To reach a server, a path must exist and someone must permit it.
When nothing connects in the cloud, the cause is almost always the same as elsewhere: a missing path or a closed port.

Shared responsibility

The most important thing to sort out in your head about the cloud is not technical – it is a question of responsibility. When you build a server at home, you watch everything: the building, the power, the hardware, the operating system and the data. In the cloud that responsibility splits in two, with a line between the halves called shared responsibility. The provider watches what is below the line: the physical datacenter, the power, the hardware and the virtualization layer. You watch what is above the line: your data, your accounts and passwords, your servers’ settings and, above all, the network rules – who may connect where. Exactly where the line runs depends on the type of service – with a rented server (IaaS) you watch almost everything above the hardware, with a ready-made app (SaaS) only your data and access – but one thing always holds: you are responsible for your data and for who you expose it to. The provider gives you a solid vault, but if you leave the door open, that is on you. This is the most common source of misunderstanding: people hear ‘the cloud is secure’ and read it as ‘someone else handles security’. The provider really does handle it – but their half. The other half, on which most real trouble rests, is yours. And the good news is that it is exactly the half you already know: segments, rules, least privilege. The cloud invents nothing new here; it just puts the settings in your hand through a web interface.

Step by step

The provider watches what is below the line: the physical datacenter, power, hardware and virtualization. That is their half.
You watch what is above the line: your data, accounts and passwords, server settings and above all network rules – who may connect where.
‘The cloud is secure’ does not mean ‘someone else handles it’. The provider gives a vault – an open door to data is your mistake.
Your half is the one you already know: segments, rules, least privilege. The cloud just hands them to you through the web.

An open bucket = an open zone

Let us show the most common cloud mistake on a concrete case, because it repeats over and over and has already cost many companies a data leak. A bucket is cloud file storage – picture a shared folder into which an application saves backups, invoices or user photos. By default it is private: only those you allow can reach it. But during development this often happens: something does not work, the storage is switched to public ‘for a moment’ to get things going, and it stays that way. From then on the content is available to anyone on the internet who knows the address – and addresses can be guessed or found. From the network’s view it is exactly what you saw with zones in the Network security course: a publicly open bucket is an open zone. The only difference is that in the cloud you do not have to re-plug cables – one checkbox in a web interface is enough, which is why the mistake is made so easily and so quietly. Nothing glows red, nothing falls over, the application runs on. The lesson has two parts. First: leave the default private and make public only what truly must be public (lesson 4 is all about that). Second: ask about every store the very same question as about a firewall rule – who exactly should reach this and why? When you cannot answer, it belongs private.

Step by step

A bucket is cloud file storage: backups, invoices, photos. By default it is private – only those you allow can reach it.
In development the store is switched to public ‘for a moment’ to get something going – and it stays. One checkbox in the web.
From then on anyone on the internet who knows the address reaches the content. Nothing glows red, the app runs on.
A public bucket is an open zone. Leave the default private and ask, as with a rule: who exactly should reach this and why?

▶ Open in the simulator

Lesson 2: Site-to-site VPN into the cloud

A permanent tunnel between company and cloud

When a company has servers in the cloud that should stay private – a database, an internal application, shared drives – it does not want to expose them to the internet. It needs only itself to reach them, and to do so securely. That is exactly what a site-to-site VPN is for: a permanent encrypted tunnel between the company network and the cloud network (VPC). ‘Site-to-site’ means ‘network to network’ – it does not connect one user, but a whole location to a whole location. It is built once, between the company firewall and the cloud gateway, and then it runs all the time: a powered-on office computer sees the cloud database as if it stood in the next room. The key is to grasp what the tunnel actually does. Traffic from the company to the cloud still physically goes over the internet – there is no other way, you do not own the provider. But the tunnel wraps and encrypts it, so on the way across foreign networks anyone sees only an unintelligible bundle, not the content. In terms of addresses and routing the cloud behaves like an ordinary remote subnet: company computers aim at it just as they would at a branch on a leased line. This is the basic building block of cloud connectivity, and in the simulator you build it in the task ‘Site-to-site VPN’. What a VPN is and how it encrypts in detail is covered by the Network security course; here we care about its role in the design: how to join the company to the cloud so the private stays private.

Step by step

The database and internal servers in the cloud should stay private. You will not expose them, yet you must reach them.
A site-to-site VPN is a permanent tunnel between the company firewall and the cloud gateway. Built once, it runs all the time.
A powered-on office computer then sees the cloud database as if it stood next door – the cloud is an ordinary remote subnet.
Traffic physically goes over the internet, but the tunnel wraps and encrypts it – along the way anyone sees only an unreadable bundle.

What flows through the tunnel and what not

The tunnel to the cloud stands; now comes a question people underestimate: what should actually flow through it? The tempting answer is ‘everything’ – I join the company to the cloud and I am done. But a tunnel is still only a path, not a permission. The fact that a usable connection exists between the company and the cloud does not mean everyone should reach everyone through it. The very same rule applies as inside a network: least privilege. Only the traffic you truly need for work should flow through the tunnel – the accounting app to the database, the backup server to the storage – and nothing more. The rest is denied at both ends of the tunnel, exactly as between two segments. The second thing to sort out: not everything must go to the cloud through the tunnel. When an employee opens a public website or a third-party service, there is no reason to push that traffic into the cloud first and out from there – it goes straight to the internet over the company link. Which destinations are sent through the tunnel and which directly is called split tunneling: only cloud addresses into the cloud, the rest directly. The opposite – driving everything through one end – is sometimes done on purpose (so all traffic passes company inspection), but it costs performance and is a choice you should make deliberately. The takeaway: the tunnel handles a secure connection, but what may flow through it is still your decision – and you make it with rules, not by simply opening the tunnel.

Step by step

It is tempting to let everything flow through the tunnel. But a tunnel is only a path, not a permission – ‘everything’ is a disabled check.
Least privilege applies: only necessary traffic flows – accounting to the database, backup to storage. The rest is denied.
Split tunneling: a public website need not go through the cloud – it goes directly to the internet. Only cloud addresses into the tunnel.
The tunnel handles a secure connection, but what may flow is still your decision – made with rules, not by opening the tunnel.

When the tunnel drops

A permanent tunnel has one property forgotten in the excitement of getting it working: it is the only path to the private servers in the cloud – and one day it drops. Not maybe, but certainly. The internet link fails, the provider does maintenance, the cloud gateway reboots. And the moment the tunnel is gone, exactly this happens: the cloud database is completely unreachable, because you – correctly – did not expose it to the internet, so no other path to it exists. The applications resting on it stop, even though they themselves keep running. This is a single point of failure and it is solved as anywhere else in a network (in detail in the Network resilience and scaling course): by doubling. Either you build a second tunnel over another internet link, or through a second cloud gateway – ideally both, so that a failure of one link or one gateway does not cut the company off from its data. Providers plan for this and offer the gateway in two pieces; you must have two links on your end and configure traffic to switch to the backup tunnel on failure. The second thing to think through in advance: what does the application do when the data is gone? It should clearly say ‘currently unavailable’, not freeze or silently lose orders. A sober conclusion: cloud connectivity is not finished when the tunnel first comes up. It is finished when you know what happens when it drops – and have a second path ready for it.

Step by step

While the tunnel runs, the office computer reaches the cloud database through it. So far all is well.
One day the link fails and the tunnel drops. It was the only path – you rightly did not expose the database to the internet.
The database is completely unreachable and the apps above it stop, even though they keep running. That is a single point of failure.
The fix is doubling: a second tunnel over another link or gateway. And plan what the app does when the data is gone.

▶ Open in the simulator

Lesson 3: Remote access into the cloud

Remote-access vs. site-to-site

A site-to-site tunnel joins the whole company to the cloud – useful when servers and applications should talk permanently. But you often need something else: to get one person into the cloud, someone sitting at home or in a hotel. For that there is remote-access VPN. The difference is in who is at the ends. With site-to-site, networks are at both ends and the tunnel holds permanently between two boxes (a firewall and a cloud gateway). With remote-access, at one end is a single user with their laptop and the tunnel arises for a while when they log in and disappears when they finish. The user starts a VPN client, logs in – ideally with multi-factor authentication – and for the duration their laptop behaves as if it were inside the cloud network. The second difference is in numbers: you build site-to-site once for a whole branch, remote-access handles dozens or hundreds of individuals connecting and disconnecting through the day. So it deals with things that make no sense for a permanent tunnel: strong verification of each person separately, removing access when an employee leaves and, above all, how far a logged-in user can reach. The last is the most common mistake and we cover it in the third module. Remember the simple distinction: site-to-site joins places, remote-access joins people. Both end in the same cloud, but solve a different problem – and in the simulator you build remote-access in the task ‘Remote-access VPN’.

Step by step

Site-to-site: networks at both ends and the tunnel holds permanently between the firewall and the cloud gateway. It joins places.
Remote-access: at one end is a single user with a laptop. The tunnel arises on login and vanishes on logout.
After login – ideally with multi-factor authentication – the laptop behaves as if it were inside the cloud network.
A simple distinction: site-to-site joins places, remote-access joins people. Both end in the same cloud.

A user from the internet into the cloud

Let us walk step by step through what happens when a remote user connects into the cloud – because there are a few places to go wrong. The user is somewhere on the internet: at home, in a café, on foreign Wi-Fi you know nothing about. They start a VPN client and it reaches out to the public address of the cloud gateway – the one point of the cloud that must be visible from the internet so a login is possible at all. Then comes identity verification: the user proves who they are (a password and a second factor), and only then does the gateway open the tunnel. Until that moment nothing but the login itself gets through the gateway – which matters, because the gateway’s public address is a target someone keeps probing. After a successful login the laptop gets an address from the cloud network and from then on moves in it like a local device: it can reach the servers it is permitted to. And here lurks the trap we will see in detail in the next module: which servers is it actually permitted to? When it reaches everything after login, you have just turned convenient remote access into a wide entrance into the whole cloud. Take two things from this walk. First: only the gateway is public, not the servers – the database and internal apps never have their own public address; you reach them only through the tunnel. Second: a tunnel without verification is just an open door – with remote access, strong verification of each person is what holds the whole model together.

Step by step

The user is somewhere on the internet and the VPN client reaches the gateway’s public address – the one point of the cloud visible from outside.
Then identity verification: a password and a second factor. Only then does the gateway open the tunnel – until then nothing else gets through.
After login the laptop gets a cloud address and reaches the servers it is permitted to. But which ones, exactly?
Take two things away: only the gateway is public, not the servers, and a tunnel without verification is just an open door.

The difference between the approaches

Now let us put both kinds of VPN side by side and say when to use which – and what mistakes are made with them. Choose site-to-site when systems should talk permanently: a company app with a cloud database, backups into the cloud, joining a branch. It is built once, runs without human intervention and nobody logs in to it. Choose remote-access when people need to reach the cloud (or the company) from somewhere other than the office. Both share a core – an encrypted tunnel – but differ in what you must watch. With site-to-site the main risk is that you let more through the tunnel than needed; so you watch the rules at both ends. With remote-access the main risk is with people: a weak password, a missing second factor, access not revoked after an employee leaves and, above all, too broad privileges after login. Here holds exactly what Zero Trust says and what you know from the Network security course: a VPN by itself is not security. When the tunnel delivers a user into a network where they may reach everything, you have merely extended the attacker’s cable to their home. A remote user should have privileges just as narrow as in the office, not wider – the tunnel handles only the secure entry, not what you may do inside. A practical summary: first sort out whether you are joining places or people; pick the kind of VPN accordingly; and in both cases remember that a secure connection must still be followed by a rule that says where.

Step by step

Choose site-to-site when systems should talk permanently. Main risk: letting more through the tunnel than needed.
Choose remote-access for people from outside the office. The main risk is with people: weak verification and too broad privileges.
A VPN alone is not security: if the tunnel ends where you may reach everything, you only extended the attacker’s cable home.
A remote user should have privileges just as narrow as in the office. The connection must be followed by a rule saying where.

▶ Open in the simulator

Lesson 4: Publishing a service

A public IP and DNAT

So far we have handled how you get into the cloud. Now the reverse: you have a website in the cloud that the whole world should see – customers, anyone. Here a VPN does not help; the site is meant to be public. How does it work? A cloud server has an internal address from your VPC that nobody sees from outside – a private address like any other in an internal network. For someone from the internet to reach it, you assign the service a public IP address: one address visible to the whole world, which you write into DNS under a name (say shop.company.com). When a visitor now comes, they aim at this public address – and at the cloud’s edge the translation you know from the Network security course happens: DNAT (destination address translation). The cloud gateway takes a packet aimed at the public address and rewrites the destination to the web server’s internal address – the same principle as the port forwarding you know from The router in depth course, just at the cloud edge; the reply is translated back on the way out. The visitor never knows the internal address and the web server never knows the public one – each talks to its own side. Two things are key here. First: a public IP and DNAT protect nothing on their own – they only open a path inward. What is reachable behind them is decided by a rule (lesson 5 is about that), and a badly set DNAT can expose what was not meant to be seen. Second: a public address goes only to the service that should be outside. The database behind the web has no public address and must not – it is reached only from inside. That is exactly what a healthy ratio looks like: one public face, the rest hidden.

Step by step

The web server has an internal address from your VPC – private, as in an internal network. Nobody sees it from outside.
So the world can reach the site, you assign the service a public IP and put it in DNS under a name (shop.company.com).
The visitor aims at the public address; at the edge DNAT rewrites the target to the web’s internal address. Each talks to its own side.
A public address goes only to the service that should be outside. The database behind the web has none and must not.

A load balancer before a web farm

One web server handles only so many visitors at once – and when it falls over, the site is gone. Both are solved by a load balancer: a device or service that stands in front of several identical servers and distributes incoming requests among them. That group of servers is called a web farm. It works like this: the public IP and the DNS name belong not to an individual server but to the load balancer. A visitor arrives at it and it sends the request to one of the web servers behind it – the next visitor goes to another, and so it alternates. This gives you two things at once that are especially valuable in the cloud. First, scaling (scale-out, from the Network resilience and scaling course): when visitors grow, you add another server to the farm and the load balancer starts using it – no need to buy one bigger machine. Second, resilience: the load balancer keeps checking whether the servers behind it are alive (a health check) and simply skips a fallen one. A visitor does not notice one server’s failure at all, because the others serve them. You build exactly this setup in the simulator in the task ‘Load balancer’: you see how traffic flows through the balancer to several backends and how it behaves when one drops. Two catches to close. The load balancer can itself become a single point of failure – so in real operation it too is usually doubled. And it distributes only what behind it is truly identical: the servers in the farm must handle any request, otherwise a visitor gets this one time and something else the next.

Step by step

One web server handles only so many visitors – and when it falls over, the site is gone. That is what you want to fix.
A load balancer stands before a web farm. The public IP and DNS name belong to it, not to the servers behind it.
It alternates requests among the farm’s servers (WEB, WEB2). More visitors? Add a server – that is scale-out.
Health check: the balancer watches which servers are alive and skips a fallen one. A visitor does not notice one server’s failure.

Only what should be public

The lesson on publishing has one main takeaway, important enough to deserve its own module: expose only what truly must be public – and nothing more. It sounds obvious, but in practice it is broken all the time, because exposing a service is easy in the cloud and hiding it takes a bit more work. A typical story: you need to reach a server’s management, so you assign it a public address ‘for a moment’ and open a port for remote administration. It works, you reach the management – and at the same time you exposed it to the whole internet, where automated scanners find it within minutes and start trying passwords. Server management should never have a public face; you reach it through a tunnel (lessons 2 and 3), which is exactly why we built one. The same rule applies to databases, internal APIs, admin interfaces: internal things stay internal. A practical test to take to every public address and open port: does a stranger on the internet have to see this for my service to work? For a web shop the answer for port 443 is ‘yes’. For a database, for SSH to a server, for administration it is ‘no’ – and when the answer is ‘no’, it does not belong outside. And a final reminder that ties the whole lesson to the bucket from lesson 1: it is not only storage that becomes public by mistake, but also servers and ports. The ratio at stake is always the same: the smallest possible public surface. Every public address and every open port is a door you must watch – and the doors easiest to watch are the ones that do not exist at all.

Step by step

The web on port 443 should be public – that is its job. For it, ‘must the world see this?’ is a clear yes.
You expose server management ‘briefly’ to the public – and within minutes scanners find it and start trying passwords.
Management, the database and admin are reached through the tunnel – that is why we built it. Internal things stay internal.
The goal is the smallest public surface. Every public address and port is a door – the easiest to watch are those that do not exist.

▶ Open in the simulator

Lesson 5: A cloud DMZ and security groups

A security group = a zone firewall

In the cloud you will nowhere see a box labeled firewall – and yet a firewall is there, just under another name: a security group. It is a set of rules you attach to a server (or a group of servers) that says who may connect to it and on which port. Nothing more, nothing less – exactly what a zone firewall from the Network security course does, only written in a web interface instead of a box’s configuration. A rule in a security group has the same parts you already know: from where (the source – a specific address, a range, or even another security group), where and to what (a port and protocol) and permit. Two things differ from a physical firewall and are worth remembering. First: a security group is not one central box that traffic passes on the way – it is attached directly to the server, so it applies wherever the traffic comes from, even from a neighbor in the same subnet. That is essentially microsegmentation for free. Second – and this is the most important difference from physical-network habits: a security group has a default deny for inbound traffic. Until you add a permitting rule, nobody reaches the server, and that is good. So you cannot make the ‘I forgot to close it’ mistake; you can only make the ‘I opened more than needed’ one. And it is exactly the second you must guard against: permit narrowly (a specific source, a specific port), not ‘from anywhere to everything’ – that would put you back at the leaky firewall from the first security lesson.

Step by step

A security group is a rule set attached directly to a server. It is the cloud equivalent of a zone firewall.
A rule has the same parts as always: from where (source), to which port and permit. Written in the web, not a box.
The group is attached to the server, so it applies even to traffic from a neighbor in the same subnet. Microsegmentation for free.
A security group has a default deny: until you add a permit, nobody gets in. The only mistake is ‘I opened too much’.

Segmentation in the cloud

A security group handles one server. Now one floor up: how to split the whole cloud network so an attacker does not spread everywhere after the first breach. The answer is the same as in a physical network and you know it from the Network security course: segmentation. In a VPC you do it with two tools that work together. First, subnets: you split the cloud network into compartments and place servers by role – a public subnet for what the world should see (the web, the load balancer) and a private subnet for what should stay hidden (the database, internal apps). The key is that the private subnet has no path in from the internet for inbound connections; a server in it can call out (say for updates), but nobody from outside addresses it. Second, the security groups from the previous module: they decide who exactly may talk between subnets. A typical healthy design looks like this: the load balancer in the public subnet accepts internet traffic on 443; the web servers accept only from the load balancer; the database in the private subnet accepts only from the web servers on its port – and from nobody else. A chain emerges in which each link talks only to the neighbor it needs for work. The public subnet is thus the cloud form of the DMZ you know from the Network security course – just subnets split by role instead of one zone in front of the firewall. Now when an attacker takes a web server (it is most exposed, because it is visible from outside), at the database they hit a group that lets them onto only one port – and onto the rest of the cloud not at all. That is the blast radius in the cloud: you will not stop the first breach, but you decide whether it becomes an incident on one server or on the whole VPC.

Step by step

A public subnet: the load balancer and web servers – what the world should see. It accepts internet traffic.
A private subnet: the database and internal apps. No path from outside – a server can call out, but nobody addresses it.
A chain emerges: the balancer permits the web, the web permits the database on its port – and nobody else. Each talks only to its neighbor.
When an attacker takes the web, at the database they hit a group allowing only one port. That is the blast radius in the cloud.

Default deny in the cloud too

The cloud does one thing better than most physical networks: security groups start with a default deny. A new server is closed by default – nobody from the internet reaches it until you explicitly permit who and to what. That is exactly the stance you laboriously click your way to in a physical network (the Network security course), and in the cloud you get it for free. The bad news is that it can be thrown away just as easily – and people do it all the time. The most common way is a rule that permits ‘from anywhere’ (0.0.0.0/0) to a management port. It is born of the best intentions: something does not work, so the source is ‘temporarily’ widened to the whole internet to see whether the problem is in the rule – and then it stays. From then on your default deny is buried for good under one broad permit that lets the whole world in. The second common error is permitting a whole group of ports ‘so I do not have to do them one by one’. The cure is still the same trio you know from firewall rules: a narrow source (a specific address or security group, never 0.0.0.0/0 to management), a narrow port (only what the service needs) and a description (why the rule exists, so someone dares delete it a year later). And since the cloud also makes checking easy, add a habit: walk the rules that permit from anywhere and ask of each whether it really belongs. Usually you find half of them have been ‘temporary’ for half a year. The summary of the whole lesson: the cloud gives you a better starting point than a physical network – but a default deny is only as strong as the rules you punch through it.

Step by step

The cloud starts with a default deny: a new server is closed until you permit who and to what. A better start than a physical network.
The most common mistake: a rule ‘from anywhere’ (0.0.0.0/0) to a management port. One broad permit lets the whole world in.
The cure is the same trio: a narrow source, a narrow port and a description of why the rule exists – so someone dares delete it later.
A habit: walk the rules that permit from anywhere. Half the ‘temporary’ ones have been there for months. The default deny is only as strong as the rules.

▶ Open in the simulator

Lesson 6: Resilience and design

Redundant connectivity (multi-WAN)

The last lesson is about making the whole thing last. We start at the weakest spot people do not realize with the cloud: the connection to it. Everything we built – the tunnel, the published web, access to the database – stands or falls on whether you can reach the internet from the company at all. With one internet link you have one cable on which the connection to the whole cloud hangs. When a digger cuts it or the provider goes down, the company is cut off from its cloud servers – no matter how well those servers are designed inside. The answer is called multi-WAN (several internet connections) and it is exactly the resilience from the Network resilience and scaling course, just applied to the gateway into the cloud. You have two links from two different providers – ideally routed physically differently too, so the same digger does not cut both – and the firewall is set so that when the primary fails, traffic switches to the backup. That switch is called failover. Two things are done wrong here. First: two links from the same provider along the same route are not two links – they are one link that fails at once. Independence is the whole point. Second: a failover nobody ever tested usually does not work at the right moment – the switch must be rehearsed, not tried for the first time during a real outage. That is exactly what you try in the simulator in the task ‘Multi-WAN failover’: you drop the primary link and see whether traffic moves to the backup on its own.

Step by step

The tunnel, the web and the database all rest on reaching the internet from the company at all. That link is the weakest spot.
With one link the whole cloud hangs on one cable. A digger cuts it – and the company is cut off from its servers.
Multi-WAN: a second link from another provider, routed physically differently. When the primary fails, traffic switches (failover).
Two links from the same provider along one route are one link. And failover must be rehearsed, not tried during an outage.

Where to put data: backups and regions

Connection resilience is one half; the other is the fate of the data. The cloud tempts a dangerous comfort: ‘the data is in the cloud, so surely it is safe’. It is not – or more precisely, it is safe only from what the provider committed to protect it from, and that is not everything. Two things must be thought through. The first is backups. The provider looks after their hardware, but will not delete your data by accident for you and will not protect it from your mistake: when someone deletes the database, runs the wrong script or ransomware encrypts you, the cloud dutifully stores that change. So a backup must exist and be separate – another account, another place, ideally such that it cannot be deleted by the same access that deleted the data. The classic rule is to keep several copies in several places and at least one out of reach of everyday operations. And a backup you never tried to restore is not a backup – it is a hope. The second thing is regions. The provider has datacenters in various parts of the world and your data physically sits in the one you chose (or was chosen for you). This has two impacts. Security: a whole region can have an outage, so truly critical services are spread across two regions so one disaster does not sink them. And legal: where the data sits, the local laws apply – for personal data the region is a decision, not a detail. Conceptually take away this: the cloud moves where the data sits, but it does not take from you the responsibility that it survives.

Step by step

The cloud tempts the comfort ‘data is in the cloud, so it is safe’. But it does not protect you from your own mistake.
When someone deletes the database or ransomware encrypts you, the cloud dutifully stores that change. A backup must exist.
A backup must be separate – another place and account, out of reach of everyday operations. And an untested restore is a hope, not a backup.
Regions: a whole region can fail, so spread critical services across two. And where data sits, local laws apply.

A cloud network checklist

To close, a checklist to take to every cloud network design – it sums up the whole course into questions you must be able to answer. Connection: How does the company reach the private servers – through a tunnel, not over the internet? Is the tunnel doubled and do you know what happens when it drops? Do you have more than one internet link and have you tested failover? People’s entry: Do remote users come over a remote-access VPN with strong verification? Is access removed on departure? Do they have privileges just as narrow as in the office after login? Publishing: Does only what should be public have a public address? For every open port, answer: must a stranger on the internet see this? Is there a load balancer before the web farm? Segmentation: Are public and private subnets separated? Is the database in the private one, with no path from outside? Do servers have a default deny and are the rules narrow and described? Is anything permitting ‘from anywhere’ to management? Data: Is there a separate backup and have you tried to restore it? Did you consciously decide on the region? And the last, connecting question you know from security: if I captured the web server, where would I get from here? When the answer is ‘to one database port and nothing more’, your cloud is well designed. A final tip: pick the one answer that hurt most today and fix it. The cloud is not secured at once – it is secured by making that list one missing boundary shorter next time. Congratulations on finishing; now try it in the simulator on the multi-WAN failover task.

Step by step

Connection: to private servers via a tunnel, not the internet. Is it doubled? Do you have several links and tested failover?
People’s entry: remote-access with strong verification, access removed on departure, narrow privileges after login.
Publishing and segmentation: only the web is public, a load balancer before the farm, the database in a private subnet with no path from outside.
The connecting question: if I took the web, where would I reach? One database port and no more = a good design. Pick one thing and fix it.

▶ Open in the simulator