Overview: Requirements and Architecture for the Task Management SaaS "Tasuku"
You can only talk about infrastructure design decisions once you've settled the requirements for what will run on it. The number of subnets, database redundancy, and how permissions get handed out all come down, in the end, to answering one question: what do you want to run, at what scale, and with how little downtime? So this series begins by defining a single subject that we'll keep using across every chapter.
In this chapter, we pin down the requirements for our subject, the task management SaaS "Tasuku", and lay out how they map onto 7 AWS services in a single diagram. We also explain, based on the dependencies between resources, why the build order from Chapter 2 onward follows the sequence it does. No code appears in this chapter.
1.1. Subject: task management SaaS "Tasuku"
Tasuku is a fictional SaaS for managing tasks as a team. We narrow its features down to the following four.
| # | Feature | Impact on infrastructure |
|---|---|---|
| 1 | User registration and login via email address and password | Handles sessions and credentials, so all communication must be HTTPS end to end |
| 2 | Creating, editing, and deleting projects and tasks (assignee, due date, status) | Requires a relational database. Tenant isolation happens at the row level in the DB |
| 3 | Attaching files to tasks | Needs a place to store unstructured data like images and PDFs. Not a good fit for the DB |
| 4 | Inviting team members and managing permissions | An application-side concern. No additional infrastructure requirements |
We narrow the features down to four because this series is about infrastructure, not the application. Even so, these four bring together the typical elements of a production web service: a web app and API, a relational database, and object storage.
We don't cover email notifications, full-text search, or CDN-accelerated delivery. These are all features you'd consider for a real service, but the additional services they'd require (SES, OpenSearch, CloudFront) aren't essential to understanding the 7 leading services, so they're out of scope for this series.
1.2. Non-functional requirements and assumed scale
A list of features alone doesn't yet determine the shape of the infrastructure. Even for the same task management tool, the design differs between one used by 10 people in-house and one used by tens of thousands. For Tasuku, we assume the following.
- Scale: A few dozen tenants, with a few hundred concurrent users. This models the launch phase of an indie project or small SaaS
- Region: A single Tokyo region (ap-northeast-1). We assume users are based domestically
- Availability: Distributed across two Availability Zones (AZs), so the service keeps running even if one AZ goes down
- Security: Only the HTTPS entry point is exposed to the internet; the application and database sit where they can't be reached directly from outside. Secrets like the database password are never written directly into code or config files
- Data protection: The database takes daily backups so it can be restored to a specific point in time if something goes wrong
This assumed scale becomes the baseline whenever later chapters need to decide on instance sizes or redundancy. We keep coming back to it in the form of "here's what you'd do for millions of users, but at Tasuku's scale, this is enough."
1.3. The boundary between application and infrastructure
This series doesn't write a single line of application code. We assume the Tasuku application is "already built and delivered as container images." Specifically, we treat the following two images as existing.
- web: A container that serves the browser-facing screens. Listens on port 3000
- api: A container for the REST API that returns JSON. Listens on port 8080
The only assumptions we make about the application are that it "listens over HTTP" and that it "has an endpoint that returns 200 for GET /healthz." We assume a health-check endpoint because later chapters have the ALB use it to judge which containers are healthy. The image name and port number are Terraform variables, so when you try this yourself, you can swap in a public image like nginx.
If application code gets mixed into an infrastructure article, readers end up having to figure out, as they read, whether a given setting is specific to the application or required by any application. Treating the application as a finished product settles the question: every setting that appears is an infrastructure concern.
1.4. Overall architecture and request flow
Here's what the finished form of Tasuku looks like.
Let's walk through this diagram once, using the example of a user attaching an image to a task.
- The browser queries Route 53 for the IP address of
tasuku.exampleand learns where the ALB is - The browser connects to the ALB over HTTPS. TLS is terminated here
- The ALB looks at the request's hostname and routes it to the web containers for
tasuku.exampleor the api containers forapi.tasuku.example. It only routes to healthy containers that are responding to health checks1 - The api reads and writes task metadata (title, assignee, due date) to PostgreSQL on RDS
- The attachment file itself is stored in S3. The DB only records where it's located in S3
ECR, CloudWatch Logs, and Secrets Manager, drawn with dotted lines, don't appear in the request path, but they support container startup and operation behind the scenes. Container images are pulled from ECR, application logs go to CloudWatch Logs, and the DB password is injected from Secrets Manager at startup.
1.5. The 7 leading services and 4 supporting services
Let's organize the services that appeared in the diagram, along with how this series treats each one. First, the 7 leading services.
| Service | Role in Tasuku | Chapter |
|---|---|---|
| VPC | Creates a logically isolated virtual network space within AWS2, and uses subnets to divide exposure into layers | Chapter 4 |
| IAM | Defines authentication and authorization for "who can do what to which resource" | Chapter 3 |
| S3 | Stores attachments, and also holds ALB access logs and the Terraform state file | Chapter 5 |
| ALB | A load balancer that operates at layer 7 (the application layer) of the OSI reference model3. Handles HTTPS termination and routes to container groups based on hostname | Chapter 6 |
| Route 53 | Manages DNS for tasuku.example and directs traffic on the custom domain to the ALB | Chapter 7 |
| ECS | The container runtime foundation. Uses the Fargate launch type to run containers without managing EC2 servers4 | Chapters 8 and 10 |
| RDS | A managed service for PostgreSQL. Provides automated backups and point-in-time recovery as a built-in AWS feature5 | Chapter 9 |
Next, the 4 supporting services. We don't dedicate a chapter to any of them; instead, we cover their design and implementation together within whichever chapter needs them.
| Service | Role | Chapter |
|---|---|---|
| ECR | Storage for container images (registry) | Chapter 8 |
| ACM | Issuing and managing TLS certificates | Chapter 7 |
| CloudWatch Logs | Aggregation point for container logs | Chapter 8 |
| Secrets Manager | Storing and injecting secrets such as the DB password | Chapters 9 and 10 |
The line between leading and supporting services comes down to whether this series treats them as something worth digging into for design decisions. The supporting services do have design choices of their own, but for Tasuku, we adopt the standard usage as-is and concentrate any comparison of options on the 7 leading services.
1.6. Build order: why start with the network
From Chapter 2 onward, we build up resources in the following order.
This order follows the "dependencies you must specify at creation time" that AWS resources carry. For example, ALB, ECS, and RDS all require you to specify "which subnet to place them in" when you create them. None of them can be created unless the subnet that houses them already exists. That's why VPC comes early.
That said, not every placement is determined by dependencies alone. In this series, we deliberately chose the following three.
- Placing IAM in Chapter 3: You don't actually need IAM roles until ECS shows up in Chapter 8. Still, we put it near the front because reading and writing policy JSON appears throughout every later chapter, and if you can't read it, the permission settings in each chapter turn into gibberish. Chapter 3 focuses narrowly on the "grammar of the permission model," and we create individual roles in whichever chapter uses them
- Building the ALB before ECS: Since no containers exist yet by Chapter 6, we have the ALB return a fixed maintenance response and get as far as exposing it to the internet over HTTP. In Chapter 7, we make this entry point HTTPS, and in Chapter 10, we switch its target over to real containers
- Splitting ECS into Part 1 and Part 2: Of the 7 services, ECS has the most associated resources, and cramming it into a single chapter would turn each design decision into an assembly line. In Part 1 (Chapter 8), we run a one-off task to confirm the foundation; then, after the DB (Chapter 9), we publish it as a long-running service in Part 2 (Chapter 10)
In other words, this series' infrastructure doesn't reach its final form in one shot. It grows in stages: from an HTTP release to HTTPS, and from a fixed response to a real application. In real-world work, too, making small changes while keeping things in a working state narrows down where to look when something goes wrong.
1.7. Prerequisites for trying this yourself
Here are the prerequisites for running this series' code yourself. You don't need any of this if you're just reading.
- AWS account: An account you can operate with administrator-equivalent permissions. We cover how to narrow down permissions in Chapter 3
- Terraform: Verified on the v1.13 series. Follow the official installation instructions
- AWS CLI: Used for setting up credentials and for verification commands
- A custom domain: Used from Chapter 7 onward. You don't need one through Chapter 6. The domain used in the text is
tasuku.example, a reserved TLD meant for examples, so you can't register it as-is. The Terraform side uses a variable so you can substitute your own domain
Actually building this series' setup incurs charges for time-billed resources (NAT Gateway, ALB, RDS, and so on). Each chapter states up front which charges start where. In Chapter 2's first apply, we set up a budget alert so you notice unexpected charges early.
Summary
- Our subject, Tasuku, is a small-scale SaaS with "web and API containers," "PostgreSQL," and "file attachments" — and this configuration alone brings in all 7 leading services
- We treat the application as a finished container image, and keep this series' scope limited to infrastructure concerns
- We limit the exposed entry point to the ALB's HTTPS only, and place the application and DB in private subnets
- The build order has parts determined by resource dependencies (VPC comes first) and parts decided by learning and operational judgment (putting IAM first, releasing the ALB early, and splitting ECS in two)
Next steps
- Chapter 2: Terraform Basics: Write a minimal Terraform configuration and create a budget alert with your first apply
- Series table of contents: The full 12-chapter structure and how to work through it
- Infrastructure and operations domain: The top page of the domain this series belongs to