Cloud terminology can be a perplexing thing for the uninitiated. Yet the cloud is increasingly pervasive. Eventually, unless you are a dinosaur, you will engage with the cloud, if not be tasked with making business decisions about it. As a result, it is ever more important to understand the basic concepts and ideas.
Last month we introduced some common terms and acronyms to help demystify industry speak. It’s a good primer before reading this post, if you’re curious about types of cloud and thinking about how to best manage them.
Here, we take these introductory concepts further.
Where does my stuff live?
In the public cloud, a certain number of resources are shared across users, bringing down costs and allowing for efficiency of provision. But what does this mean for security and privacy? How is the cloud segmented, exactly? Tenants and subscriptions are two of the high-level delineations.
A tenant is a dedicated space with a secure boundary, used exclusively by an entity. The tenant lives in a larger space offered by a cloud provider. This allows for resource sharing, which reduces the cost of provision.
Think of the tenant as a house, surrounded by other houses, but which share roads and water lines. Or, think of it as a suite in an apartment. The suite’s walls provide a security boundary, and although those walls might be shared with neighbours, they are themselves impassable.
Similarly in the cloud, one must have the key to be able to enter a tenant. Entry rules can be applied, and areas within the tenant may be further secured. In Azure, it is akin to a directory.
A subscription is akin to “folders” in a directory, and these folders in turn store resources. Subscriptions are tied to a tenant; a tenant can have multiple subscriptions, but the subscription belongs to only one tenant.
Within your home, to extend the metaphor, rooms represent areas for specific purposes. Sleep takes place in the bedroom, showering in the bathroom. Different strategies apply for resourcing within subscriptions – for instance, subscriptions can be segmented internally based on cost accountability, and interact internally with no extra egress charges – but that is a topic for another post.
What about security?
Tenant and subscription boundaries are important for containing and organizing your personal data. Yet keeping your tenant safe requires additional protections
Network Security Groups (NSGs) are used in the Azure context, but their concept is universal. It is a security boundary and helps to protect your virtual network. However, it is not a firewall, and does not provide the same level or type of protection.
NSGs can be a useful tool to partition the network. For instance, a front-end network with customer-facing web servers might only “talk” to a back-end database using a strict port limited to one server. This provides a control point that protects the system. This kind of control can also be outward facing, controlling entry at the port level or IP address level.
However, with up to 200 rules allowed in an NSG, and some of those with multiple IP addresses and ports associated, it can quickly become unmanageable. There is no logging capability, so mistakes can be difficult to see. A mistake within those rules without a firewall in place opens the virtual network to vulnerabilities.
The firewall is a necessary backstop, adding another protective layer behind NSGs. It provides a barrier between internal trusted networks, and external untrusted ones. It also monitors, logs, and controls traffic based on predetermined security rules.
Firewalls can provide further capabilities such as machine learning. Behind the scenes, for instance, Microsoft is looking for common threats across the world, recognizing things that are coming into their data centers, and triggering responses based on what they observe. This helps the firewall to stay ahead of trends and developments as much as possible.
Understanding subscription costs
Pay as you go. Just as it sounds, this is a model for purchasing cloud resource at the retail price, the MSRP (manufacturer’s suggested retail pricing). Public cloud vendors offer retail price lists and pricing calculators. These help you understand the cost to run a specific resource, usually on a ‘per minute, per second’ basis.
Purchasing a $50,000 server is a commitment. With pay as you go, you can stop or change service as you like. There is no commitment, and therefore, little risk in testing different levels of use. With pay as you go, you only pay for what you need.
Reserved instances. Cloud providers offer the ability to reserve a SQL database for one- or three-years’ consumption, with substantial cost savings in exchange for prepayment. This reservation of space reduces the providers’ costs enough to pass on the savings.
Microsoft recently announced the ability to purchase reserved instances with monthly payments. Early cancellation incurs a 12% penalty on the balance of the contract. In some cases, it is still worth taking advantage of the overall savings.
Elasticity. Elasticity is a system’s ability to automatically adjust resources against workload changes. For instance, a Black Friday sale in the old days would require the purchase of numerous servers that would sit idle most of the year. When a traffic spike occurs at the time of the sale, there is enough capacity to handle demand – after which, the servers return to being idle.
Elasticity allows for scaling on demand. There are two ways in which this occurs:
- Vertically – scaling out, adding more of the same compute systems. This adds power (CPU, RAM) as a resource.
- Horizontally – scaling up, going to a larger instance size to meet the demand. This adds more machines as resources.
Scalability refers to a system’s ability to add resources as needed. In the cloud, scalability is infinite; on-premises it is constrained by the physical limitations of the server.
Planning for two-way traffic
Elasticity and scalability are important in responding to fluctuating demand, whether short- or long-term. However, traffic can affect security and cost, too. Each direction has its own considerations.
Ingress. Ingress is simply inbound traffic. It has many variations, like a web server on the front end of a system, or people connecting to a network through a remote desktop connection. Each connection type calls for a style-appropriate solution.
It is important to protect ingress traffic. Left open to the world, ingress is an easy target for hacking. Solutions can include a firewall, web application, and network security groups.
Egress. Conversely, egress is outbound traffic. It, too, should be controlled, but for a different reason than ingress. There are two main reasons why:
- In the public cloud, ingress traffic is free. The cloud provider is happy to accept your data. However, outbound traffic to the Internet has a cost attached, and this can escalate quickly, left unattended.
- Egress control is important to protect your system against being compromised. Without restraints in place, a server may ‘talk’ to information that is detrimental and bring that traffic into your system.
Cloud terminology can seem baffling, or even overwhelming, at times. When concepts are flying fast, or there is pressure to decide a new way forward, it can seem easier to avoid it. Don’t become the dinosaur of the future: get empowered by getting to know the cloud.
If you want to learn more about the cloud and digital transformation, check out our Podcast Azure for the Win.