FIT5225 · Cloud Computing And Security
AWS and Infrastructure-as-Code
This is the chapter that powers the build projects: how to provision real cloud infrastructure repeatably, and the AWS catalogue you provision. Infrastructure-as-Code (IaC) replaces manual console clicks with machine-readable definition files, so infrastructure is versioned, reviewable and reproducible. FIT5225 classifies every IaC tool on the same axes — the headline one is declarative (describe the desired end state: Terraform, CloudFormation) vs imperative (describe the steps: Ansible) — with idempotency the property that lets you safely re-run a declaration. The other half of the chapter is the AWS catalogue mapped to need: global infrastructure (Regions, Availability Zones, Edge locations) and the core services for compute (EC2, Auto Scaling, ELB), storage (S3, EBS, EFS, CloudFront), and databases & networking (RDS, DynamoDB, VPC). Quizzes test classifying a tool, matching a need to a service, and reading a reference architecture.
What this chapter covers
- 01Why IaC — repeatable, versioned, reviewable infrastructure
- 02The four axes: declarative vs imperative (+ idempotency)
- 03The IaC tool catalogue — Terraform, CloudFormation, Ansible, Pulumi…
- 04AWS global infrastructure: Regions, Availability Zones, Edge locations
- 05The AWS catalogue: compute (EC2/ASG/ELB), storage (S3/EBS/EFS), databases & networking (RDS/DynamoDB/VPC)
- 06A reference architecture — matching services to a need
Worked example: classify the tool, then match services to a need
- +1(a) Declarative: the file describes the desired end state, not the steps, and the tool computes the diff — the model used by Terraform and CloudFormation.
- +1(a) The safe-re-apply property is idempotency: applying the same declaration again converges to the same state with no further change, so re-runs are safe.
- +1(b) Compute: run the web tier on EC2 instances.
- +1(b) Scaling: put them in an Auto Scaling group so capacity tracks the spiky demand, spread across multiple Availability Zones for AZ-failure survival.
- +1(b) Fronting: place an Elastic Load Balancer (ELB) in front to distribute traffic across the healthy instances in both AZs.
- +0Conclude: declarative IaC provisions it reproducibly; EC2 + Auto Scaling across AZs + ELB is the canonical elastic, fault-tolerant web tier.
Key terms
- Infrastructure-as-Code (IaC)
- Defining and provisioning infrastructure with machine-readable files instead of manual console clicks. The payoff is repeatability, version control, peer review and idempotent re-runs. FIT5225 classifies every IaC tool on the same axes, the headline being declarative vs imperative.
- Declarative vs imperative
- Declarative IaC (Terraform, CloudFormation) describes the desired end state and lets the tool compute the steps; imperative IaC (Ansible playbooks, scripts) describes the steps to perform. Declarative tools are naturally idempotent — re-applying converges to the same state — which is why they dominate cloud provisioning.
- Region / Availability Zone / Edge location
- AWS global infrastructure. A Region is a geographic area (e.g. ap-southeast-2) containing multiple isolated Availability Zones (separate data-centre clusters) for fault tolerance; Edge locations are many smaller points-of-presence used by CloudFront to cache content close to users. Spreading across AZs is how you survive a single-AZ failure.
- EC2 / Auto Scaling / ELB
- The core AWS compute trio. EC2 provides virtual machines (IaaS compute); an Auto Scaling group adds or removes EC2 instances to match demand; an Elastic Load Balancer distributes incoming traffic across healthy instances. Together they form an elastic, fault-tolerant web tier — the canonical reference architecture.
- S3 vs EBS vs EFS
- Three AWS storage types for different shapes of data. S3 is object storage for files/blobs over HTTP, highly durable and internet-addressable; EBS is block storage attached to a single EC2 instance (like a disk); EFS is a shared file system mountable by many instances at once. Matching the storage type to the access pattern is a recurring quiz task.
AWS and Infrastructure-as-Code FAQ
How do I tell a declarative IaC tool from an imperative one?
Ask whether the file describes the end state or the steps. Declarative tools (Terraform, CloudFormation) say 'I want this final infrastructure' and compute the diff to get there, so re-applying is idempotent and safe. Imperative tools (Ansible, shell scripts) say 'do step 1, then step 2'. The quiz wants you to classify a tool you may not have seen by which axis it sits on.
Is IaC free of downsides?
No — and pretending it is loses marks. IaC adds a learning curve, tooling and state-management complexity (a Terraform state file can drift or be corrupted), and a bad declaration can destroy real infrastructure quickly. The benefits (repeatability, versioning, review, idempotency) outweigh this at scale, but the trade-off is real and the quiz expects you to name both sides.
How do I match an AWS service to a need in a project?
Work from the requirement. Need raw VMs you control? EC2. Need elastic capacity? An Auto Scaling group. Need to spread traffic? ELB. Need durable object storage over HTTP? S3. Need a relational database without running the server? RDS; a managed key/value store at scale? DynamoDB. Need network isolation? a VPC. Justifying the choice against the requirement is exactly what the build projects mark.
Why spread a deployment across Availability Zones?
Because a single Availability Zone can fail. AZs within a Region are physically isolated data-centre clusters, so running instances in two or more AZs (behind a load balancer, in an Auto Scaling group) means a one-AZ outage does not take your application down. This is the standard fault-tolerance pattern AWS questions reward.
Exam move
Split your prep in two. For IaC, memorise the axes — especially declarative vs imperative and idempotency — so you can classify any tool by description, and be ready to name both the pros (repeatable, versioned, reviewable) and the cons (complexity, state management, blast radius). For the AWS catalogue, build a need → service lookup: compute (EC2 / Auto Scaling / ELB), storage (S3 / EBS / EFS / CloudFront), database (RDS / DynamoDB) and networking (VPC), and practise reading a reference architecture and explaining why each box is there. This is also your project reference: the marks in A1 and A2 come from matching services to requirements and justifying the design, so the same knowledge serves both the quiz and the builds.
