How Infrastructure as a Service works in practice, using Amazon Web Services as a case
study
Achu Ransom
October 30, 2026
Abstract
Infrastructure as a Service (IaaS) lets organisations rent computing, storage and networking over the
internet instead of buying and housing their own hardware. This article explains the model and then
uses Amazon Web Services (AWS) as a case study. It walks through how a typical web application is
assembled from AWS IaaS building blocks, examines Netflix’s migration as an example of the model
at scale, and closes with the operational lessons that teams tend to learn the hard way.
Keywords: IaaS, cloud computing, AWS, EC2, VPC, shared responsibility, Netflix

  1. Introduction Until the mid-2000s, launching a web service meant forecasting demand, ordering servers, waiting for delivery and paying for capacity whether or not customers showed up. IaaS changed that arrangement by turning infrastructure into something a developer can request through an API and release when it is no longer needed. The National Institute of Standards and Technology (NIST) describes the model as one in which the consumer provisions processing, storage and networks and can run arbitrary software, including operating systems and applications, without managing or controlling the underlying physical infrastructure [1]. This article has three goals: to define IaaS precisely, to show what building on it looks like using AWS, and to extract practical lessons from the experience of a company that adopted it at very large scale.
  2. Understanding the IaaS Model NIST identifies three service models: Software as a Service (SaaS), Platform as a Service (PaaS) and IaaS [1]. The difference between them is where the line of responsibility falls between the provider and the customer. IaaS sits at the bottom of the stack, which gives customers the most control and also leaves them the most work. Table 1 summarises the division. Achu Ransom | Page 1 IaaS Explained: Lessons from Amazon Web Services IaaS Explained: Lessons from Amazon Web Services Achu Ransom | Page 2 Table 1. Division of responsibility across the three cloud service models (after NIST [1]) Service model Customer manages Provider manages Typical examples IaaS Operating system, middleware, runtime, data and applications Data centres, physical servers, storage, networking and virtualisation Amazon EC2, Azure Virtual Machines, Google Compute Engine PaaS Applications and their data Everything in IaaS, plus the operating system, middleware and runtime Heroku, AWS Elastic Beanstalk SaaS Account configuration and day-to-day use The entire stack, including the application itself Gmail, Slack NIST also lists the essential characteristics that make a service “cloud” in the first place: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service [1]. The last of these is what produces the pay-for-what-you-use pricing that most teams associate with IaaS.
  3. AWS as a Case Study AWS is a useful subject because it is both the pioneer of modern IaaS and one of the most complete implementations of it. Amazon announced its Simple Storage Service (S3) on March 14, 2006 [2], and the Elastic Compute Cloud (EC2) followed in beta in August of that year [3]. Together they established the pattern the industry still follows: storage and compute offered as web services, billed by usage. Table 2 maps the core IaaS building blocks to their AWS counterparts. Table 2. Core IaaS building blocks and their AWS equivalents IaaS building block AWS service Role in a typical deployment Compute Amazon EC2 Virtual servers that run the application and, in this case study, the database Block storage Amazon EBS Persistent disks attached to EC2 instances Object storage Amazon S3 User uploads, static assets and backups Networking Amazon VPC, Elastic Load Balancing, Route 53 Private networks, traffic distribution and DNS Identity and access AWS IAM Permissions for people and for the servers themselves
  4. Reference Architecture: Hosting a Web Application Consider a small start-up launching a Node.js application backed by a PostgreSQL database. Figure 1 shows one reasonable way to host it using only IaaS components. The design is deliberately conventional: a load balancer in a public subnet, application servers and the database in private subnets, and object storage for files. Users (Internet) Application Load Balancer Auto Scaling Group EC2 app server (AZ-a) EC2 app server (AZ-b) Public subnet PostgreSQL on EC2 with EBS volume Private subnets (two Availability Zones) Virtual Private Cloud (VPC) Figure 1. Reference architecture for the case-study application on AWS 4.1 Network foundation Amazon S3 (uploads) Everything begins with a Virtual Private Cloud (VPC), a logically isolated network within AWS [4]. Public subnets hold only the load balancer. Application servers and the database sit in private subnets with no direct route from the internet, which shrinks the attack surface considerably. 4.2 Compute Application servers run on EC2 instances, which are virtual machines the customer launches and configures [5]. Because this is IaaS, the team owns everything above the hypervisor: installing Node.js, hardening the operating system, applying patches and configuring a process manager. Listing 1 shows an instance launch using the AWS Command Line Interface. Listing 1. Launching an EC2 instance with the AWS CLI aws ec2 run-instances \ --image-id ami-xxxxxxxx \ --instance-type t3.small \ --key-name my-key \ --security-group-ids sg-xxxxxxxx \ --subnet-id subnet-xxxxxxxx 4.3 Storage Each instance boots from an Elastic Block Store (EBS) volume, and the database keeps its data on a separate EBS volume that is snapshotted regularly. User uploads and static assets go to S3, which keeps large files off the application servers and lets them be replaced freely. Running PostgreSQL directly on EC2 is the pure-IaaS choice; teams that prefer not to manage database patching and backups can move to a managed service, at the price of giving up some control. 4.4 Security Security groups act as virtual firewalls attached to resources, and IAM roles let instances obtain temporary credentials so that no access keys need to be stored on disk. Listing 2 restricts the application tier so that it accepts HTTPS traffic only from the load balancer’s security group. IaaS Explained: Lessons from Amazon Web Services Achu Ransom | Page 3 Listing 2. Allowing HTTPS only from the load balancer aws ec2 authorize-security-group-ingress \ --group-id sg-app \ --protocol tcp --port 443 \ --source-group sg-alb 4.5 Scaling and availability An Auto Scaling group keeps a defined number of instances running and adds or removes them according to policies the team sets [6]. A policy might, for example, add capacity when average CPU utilisation exceeds 60 per cent. Spreading the group across two or more Availability Zones means the loss of a single data centre does not take the application offline.
  5. Industry Example: Netflix Netflix’s move to AWS is the best-known illustration of IaaS at scale. According to the company, its journey began in August 2008, when a major database corruption left it unable to ship DVDs to members for three days. That failure persuaded Netflix to move away from vertically scaled single points of failure in its own data centres and towards horizontally scalable, distributed systems in the cloud [7]. By December 2010 it was already running a large share of its customer-facing workload on AWS and had published its reasons for the choice [8]. The migration was neither quick nor trivial. Netflix reports that it took seven years, finishing in early January 2016 when the last remaining data-centre components supporting streaming were shut down. The company also states that cost reduction was not its main motivation, although cloud costs per streaming start ended up well below those of its data centres [7]. The experience of building highly reliable services from unreliable but redundant components later fed into the discipline of chaos engineering, in which teams deliberately inject failures to test resilience [9]. It is worth being precise about what this example shows. Netflix rebuilt its systems to be cloud-native rather than simply relocating servers, and it uses a wide range of AWS services beyond raw virtual machines. The lesson for IaaS adopters is that the model rewards architectures designed for elasticity and failure, not merely hardware replaced one-for-one.
  6. Benefits and Limitations Each advantage of IaaS carries a corresponding responsibility. Table 3 pairs them. Table 3. Benefits of IaaS and the responsibilities that accompany them Benefit Pay-as-you-go pricing turns capital expenditure into operating expenditure Elasticity allows capacity to follow demand within minutes Corresponding limitation Forgotten instances, idle volumes and data-transfer charges can inflate bills unnoticed Scaling policies must be designed and tested; poorly tuned rules can fail under real load Global regions place workloads close to users Full control over operating system, network and software stack Multi-region designs add complexity in data consistency, networking and cost Patching, monitoring, backup and incident response remain the customer’s job Achu Ransom | Page 4 IaaS Explained: Lessons from Amazon Web Services AWS formalises the second column as the shared responsibility model: AWS is responsible for the security of the cloud, meaning the facilities, hardware and virtualisation layer, while the customer is responsible for security in the cloud, meaning the guest operating system, applications, data and access configuration [10].
  7. Practical Lessons The AWS Well-Architected Framework codifies much of the accumulated experience of running workloads on the platform [11]. Six practices stand out for teams new to IaaS:
  8. Tag every resource by project and owner so that costs can be traced and orphaned resources found.
  9. Configure billing alerts on the first day, before the first unexpected invoice rather than after it.
  10. Define infrastructure as code with a tool such as Terraform or AWS CloudFormation, so environments are repeatable and reviewable instead of hand-built in a console.
  11. Design for failure by placing instances in multiple Availability Zones and testing recovery, as Netflix’s experience suggests [7][9].
  12. Right-size instances and review utilisation regularly, since the first choice is rarely the best one.
  13. Apply least-privilege IAM from the start; tightening permissions later is far harder than granting them carefully at the outset.
  14. When to Choose IaaS IaaS suits teams that need control over the operating system or network layout, workloads with unusual software requirements, and organisations moving existing applications to the cloud with minimal change. Teams that would rather not operate servers at all may be better served by PaaS offerings or by serverless compute, where the provider takes on more of the stack [1].
  15. Conclusion IaaS made infrastructure programmable. AWS demonstrates both halves of that proposition: extraordinary flexibility and scale on one side, and a clearly defined set of operational duties on the other. Netflix’s experience shows that the greatest gains come when applications are built to exploit elasticity and to tolerate failure. Teams that understand where the provider’s responsibility ends and their own begins are the ones best placed to benefit. References [1] P. Mell and T. Grance, “The NIST Definition of Cloud Computing,” National Institute of Standards and Technology, Gaithersburg, MD, USA, NIST Special Publication 800-145, Sep. 2011. doi: 10.6028/NIST.SP.800-145. [2] Amazon Web Services, “Amazon Web Services Launches ‘Amazon S3’,” press release, Amazon.com, Mar. 14,
  16. [Online]. Available: https://press.aboutamazon.com/news-releases/news-release-details/amazon-web-ser vices-launches-amazon-s3-simple-storage-service [3] Amazon Web Services, “Announcing Amazon Elastic Compute Cloud (Amazon EC2) – Beta,” What’s New at AWS, Aug. 24, 2006. [Online]. Available: https://aws.amazon.com/about-aws/whats-new/2006/08/24/announci ng-amazon-elastic-compute-cloud-amazon-ec2---beta/ [4] Amazon Web Services, “What is Amazon VPC?” Amazon VPC User Guide. [Online]. Available: https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html [5] Amazon Web Services, “Amazon EC2 instances,” Amazon EC2 User Guide. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Instances.html Achu Ransom | Page 5 IaaS Explained: Lessons from Amazon Web Services [6] Amazon Web Services, “What is Amazon EC2 Auto Scaling?” Amazon EC2 Auto Scaling User Guide. [Online]. Available: https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html [7] Y. Izrailevsky, “Completing the Netflix Cloud Migration,” Netflix, Feb. 2016. [Online]. Available: https://about.netflix.com/news/completing-the-netflix-cloud-migration [8] J. Ciancutti, “Four Reasons We Choose Amazon’s Cloud as Our Computing Platform,” The Netflix Tech Blog, Dec. 14, 2010. [Online]. Available: https://medium.com/netflix-techblog/four-reasons-we-choose-amazons-clo ud-as-our-computing-platform-4aceb692afec [9] A. Basiri et al., “Chaos Engineering,” IEEE Software, vol. 33, no. 3, pp. 35–41, May–Jun. 2016. doi: 10.1109/MS.2016.60. [10] Amazon Web Services, “Shared Responsibility Model.” [Online]. Available: https://aws.amazon.com/compliance/shared-responsibility-model/ [11] Amazon Web Services, “AWS Well-Architected Framework.” [Online]. Available: https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html Note: Web sources were last checked on October 30, 2026. Product features and documentation pages may change over time. Achu Ransom | Page 6