Cloud deployment and service models

Hannah Weiss, Cascade Ridge's privacy and security lead, has one question for every new system: who is responsible when something goes wrong? When Gwen presents the migration plan, Hannah wants to know, for each system moving to AWS, which parts Cascade Ridge will still look after and which parts become AWS's job. Gwen says the answer depends on two choices that the exam calls the service model and the deployment model. She spends a long afternoon with Mateo and Hannah working through both, using every system Cascade Ridge runs as an example.

Service models

A service model describes how much of the technology stack the provider manages and how much the customer manages. Picture the stack as layers: the building and power at the bottom, then physical servers, storage and networking, then virtualization, then the operating system, then middleware and runtime, then the application, and at the top the data and the decisions about who can use it. The three classic service models draw the line between provider and customer at different heights.

Infrastructure as a service

With infrastructure as a service (IaaS), the provider supplies the basic building blocks: virtual servers, block storage, networks and the facilities they run in. The customer chooses an operating system, installs and patches it, installs the application, and configures firewalls, users and backups. IaaS gives the most control and is closest to running a physical server, which makes it the easiest home for existing applications.

On AWS, the most common IaaS service is Amazon EC2, which provides virtual servers called instances. Disks for those instances come from Amazon EBS (Elastic Block Store), and networking comes from Amazon VPC (Virtual Private Cloud). Cascade Ridge's VetLedger application servers will run on EC2 at first, because the vendor supports a specific version of Windows Server and wants the software installed in a particular way. Mateo will keep patching Windows, just as he does now; what disappears is the hardware, the room and the air conditioner.

Platform as a service

With platform as a service (PaaS), the provider also manages the operating system, the runtime and often the scaling. The customer supplies an application or data and settings, and the platform does the rest. PaaS removes routine work, such as patching and capacity planning, but asks the customer to work within the platform's rules.

On AWS, Amazon RDS is a managed relational database: AWS installs the database engine, patches it, takes automated backups and can keep a standby copy in another zone, while the customer manages the database schema, the data and who may connect. AWS Elastic Beanstalk runs web applications from uploaded code. Cascade Ridge will move VetLedger's SQL Server database to Amazon RDS for SQL Server, so the nightly backup job Mateo wrote in 2020 will be replaced by RDS automated backups.

Software as a service

With software as a service (SaaS), the customer uses a complete application delivered over the internet. The provider runs everything, including the application itself, and the customer manages users, settings and its own data. Cascade Ridge's email and office documents run on Microsoft 365, its phones run on a hosted voice service, and its payroll runs on a SaaS payroll platform. All three are SaaS, and none of them runs on Cascade Ridge's AWS account, which is a useful reminder that the cloud is broader than one provider.

Serverless

A newer term sits across the models: serverless. A serverless service has no servers for the customer to choose, size or patch. It scales automatically, often down to nothing when idle, and is billed for the work it does, such as each request or each second of computation. AWS Lambda runs code in response to events; Amazon S3 (Simple Storage Service) stores objects with no capacity to plan; Amazon DynamoDB is a serverless NoSQL database.

Kwame's longer-term plan for BookVet is serverless: the booking form would call Lambda functions that write to DynamoDB, and the whole app would cost almost nothing at three in the morning. That redesign is phase 2. For now, Gwen notes only that serverless pushes even more of the stack to AWS, so the customer's share of the work shrinks to code, configuration, data and access.

The shared responsibility model

Hannah's question has a formal answer that the exam treats as essential: the AWS shared responsibility model. AWS is responsible for security of the cloud, meaning the physical facilities, hardware, network and the software that runs AWS services. The customer is responsible for security in the cloud, meaning its data, its identities and permissions, its operating systems where it runs them, its network settings and its applications. The service model decides where the dividing line falls: on EC2 the customer patches the guest operating system; on RDS AWS patches the database engine; on Lambda AWS manages the whole runtime.

Gwen gives Hannah a sentence to remember: no matter the service, the customer always owns its data and decides who can reach it. AWS-102 covers the model in detail, including encryption, identity and compliance reports.

Deployment models

A deployment model describes where the cloud resources run and who they serve. The exam names three.

• Cloud (sometimes called public cloud or all-in cloud): applications run entirely in a provider's cloud, built either by migrating existing systems or by designing new ones for the cloud. A start-up that has never owned a server is fully cloud.
• On-premises (also called private cloud): resources run in the organization's own facilities using virtualization and management tools, sometimes with cloud-style self-service. It offers control but keeps all the costs and duties of running hardware.
• Hybrid: cloud resources are connected to on-premises infrastructure, so workloads and data can move or work together. A typical hybrid design keeps some systems on site for legal, latency or practical reasons and runs the rest in the cloud.

Related terms appear too. Multicloud means using more than one public cloud provider. A community cloud is shared by several organizations with common needs, such as a group of agencies. The exam focuses on cloud, on-premises and hybrid.

Cascade Ridge will be hybrid for the foreseeable future. Each clinic keeps its desktop computers, card terminals and printers; the emergency hospital keeps the pharmacy's automated dispensing cabinet, which is controlled by a small PC that must sit beside it. Everything else moves to AWS, connected to the clinics over encrypted internet links at first and possibly over a dedicated connection later. Lesson 9 shows how the team decided which systems move and how.

Shared responsibility by service

Hannah asks for one more table, showing exactly what Cascade Ridge must still do for each kind of service it will use. Gwen builds it on the whiteboard, and it becomes the page Hannah pins above her desk.

Reading down the right-hand column, Hannah sees the pattern Gwen described: the list gets shorter as services become more managed, but it never becomes empty. Every row ends with data and access. Her new cloud security policy therefore starts with two sections that apply to every service, data classification and access control, before it says anything about particular products.

Why the models matter for cost and skills

The service model also changes the kind of work Mateo will do and the way costs behave. On EC2, Cascade Ridge pays for every hour an instance runs, whether it is busy or idle, and Mateo spends time on patching and monitoring the operating system. On RDS, the hourly price is higher than a bare instance of the same size, but it includes work Mateo no longer does: backups, engine patching and failover. On Lambda, the bill depends on how many requests arrive and how long each takes, so an idle system costs almost nothing.

Gwen's rule of thumb for Cascade Ridge is to choose the most managed option that meets the requirement. A managed service may cost more per hour, but it usually costs less in total once staff time and risk are counted, a point lesson 10 develops. The exceptions are systems like VetLedger's application servers, where a vendor's support rules dictate a particular operating system setup and therefore IaaS.

A note on terminology

Exam questions sometimes describe a service rather than name a model. A question that mentions choosing the operating system and installing software points to IaaS. One that mentions uploading code while the provider manages servers and scaling points to PaaS or serverless. One that mentions using a finished application through a browser points to SaaS. Mateo practises by labelling every service he meets in the console with its model, and he finds that a few, such as Amazon RDS, sit comfortably between the textbook categories.

Hannah adds one practical step to her policy: every new AWS service the team wants to use must first be labelled with its model and its customer responsibilities, using the same table. The label tells the team what work it is signing up for before the service reaches production, and it gives Hannah a list to check during her quarterly reviews.

Hannah leaves with a one-page table for every system, and with a new phrase for her policy documents: security of the cloud and security in the cloud. Lesson 4 turns to where AWS's cloud physically lives.