I enjoyed GameDay this year

AWS Summit Tokyo 2026 was held over two days starting on June 25, 2026. I joined the GameDay on Day 01. It was my first GameDay. I also want to thank the people I briefly teamed up with that day.

The theme was Frugal Architect: the idea that, in cloud architecture, cost should not be treated as something to optimize after the fact, but as a constraint and quality attribute to be considered from the beginning of design.

This is not a GameDay walkthrough

Let me be clear up front: this article is not a GameDay walkthrough.

I will not write about the specific quests, completion conditions, resource configurations, settings, solution steps, pitfalls, scoring, or tactical observations. That would go against the spirit of the participation terms and would also spoil the experience for future participants.

What I want to write about instead is how GameDay helped me put Frugal Architect into the language of SIers—systems integrators.

In short, Frugal Architect was not a collection of cloud cost-saving tricks.

It was a vocabulary for reconnecting things that often become separated in SI projects: architecture, estimation, operations, and continuous improvement.

Frugal Architect is not merely a “cheap architect”

The word “frugal” can easily sound like “cheap” or “cost-cutting.”

But a Frugal Architect is not simply someone who chooses the cheapest possible configuration.

Anyone can make something cheaper in the short term. Remove redundancy. Reduce monitoring. Reduce logs. Remove performance headroom. Let humans compensate through operations. The monthly bill might go down.

But that is not architecture. That is just endurance.

What Frugal Architect deals with, I think, is the relationship between cost and value.

  • Which business value does this cost support?
  • Which risk does this redundancy reduce?
  • Which decision does this monitoring make possible?
  • Which user experience does this performance headroom protect?
  • Whose time does this operational burden consume?

In other words, the point is not to erase spending, but to make spending accountable.

In SIer language, this is the practice of connecting cost to design rationale.

In SI projects, cost is often placed outside architecture

In SI projects, the word “cost” appears constantly.

Estimates, budgets, approvals, contracts, effort, maintenance fees, cloud usage fees. Cost is everywhere.

And yet, when it comes to architecture design, cost is not always treated as a real design requirement.

Performance requirements are written down.

Availability requirements are written down.

Security requirements are written down.

Backup requirements are written down.

But cost requirements often stop at vague phrases such as “keep it as low as possible,” “stay within budget,” or “be careful with pay-as-you-go pricing.”

That is not enough to support design decisions.

Just as “make it as fast as possible” is not a performance requirement, “make it as cheap as possible” is not a cost requirement.

At minimum, cost needs to be framed in ways that architecture can actually use:

  • expected monthly run cost under normal conditions
  • which cost items increase as usage grows, and how
  • under what conditions cost increases are acceptable
  • what can and cannot be sacrificed to reduce cost
  • why we pay for monitoring, logs, backups, and redundancy
  • when and by whom cost will be reviewed after release

This is not merely a cloud billing topic.

It is a non-functional requirement that makes design decisions explainable later.

Separating initial cost and run cost is not enough

In SI estimates, it is common to separate initial build cost from operation and maintenance cost.

That distinction is necessary.

But cloud architecture requires one more step.

Cloud cost is not something fixed at build time. It continues to change with usage patterns, data volume, access patterns, log volume, backup retention, and the granularity of operational monitoring.

In other words, cloud cost is not “an amount decided during estimation.” It is a variable to be observed and adjusted during operations.

If we treat it like a fixed cost, two types of failure occur.

The first is making the initial design excessively conservative.

The second is allowing something that looked cheap at first to quietly grow during operations.

Both are familiar in SI work.

The former is called “designing on the safe side.” The latter is called “unexpected usage growth.”

From the Frugal Architect perspective, both are failures of observation and control.

FinOps is the higher-level concept; Frugal Architect is the implementation language

On reflection, I think FinOps is a higher-level abstraction than Frugal Architect.

FinOps is a management discipline for continuously aligning cloud usage, cost, and value across technology, business, finance, and operations. Cost visibility, tagging, accountability, budget management, usage analysis, and organizational decision-making all belong clearly to the FinOps domain.

Frugal Architect, on the other hand, feels closer to an implementation language for bringing that thinking into architecture.

If FinOps is the operating philosophy for making cloud usage governable, Frugal Architect is the engineer’s language for turning that philosophy into design decisions.

Which components should be synchronous?

Where should processing become asynchronous?

Where should caching be placed?

How much should be delegated to managed services?

Which logs need to be immediately searchable, and which can be retained more cheaply for later use?

Which risks are worth paying for, and which risks should be accepted operationally?

These decisions are often too late if they begin only after the invoice arrives.

At the same time, in many organizations, FinOps still seems to remain at the level of slogans and calls to action.

“Let’s optimize cloud cost.”

“Let’s make each department cost-aware.”

“Let’s add tags.”

None of these are wrong. But unless they connect to actual design decisions, FinOps ends as a slogan.

In SIer language, Frugal Architect is architecture design that includes operating cost. It is also non-functional design for bringing FinOps down into design, build, and maintenance work.

Cost is a non-functional requirement

I understand the first message of Frugal Architect as this: cost must be treated as a non-functional requirement.

For SIers, that is an important translation.

Once cost enters the category of non-functional requirements, it is no longer merely a topic for procurement, contracts, or billing.

It becomes something that can be handled in:

  • requirements definition
  • design reviews
  • test perspectives
  • operations design
  • acceptance criteria
  • improvement cycles

Simply saying “cost matters” is weak.

Saying “cost is a non-functional requirement” gives it a place in design artifacts.

For example, we can bring questions like these into non-functional requirements:

  • What is the unit cost of this system?
  • If usage doubles, does cost also double, or does it grow faster?
  • Who detects cost anomalies, how often, and with which metrics?
  • Which SLOs must be preserved when reducing cost?
  • Does the system need the same configuration during normal and peak periods?
  • For audit, investigation, and incident response, which data must be retained and at what granularity?

These questions cannot be answered by cloud architects alone.

They must be decided together with business teams, operations teams, security teams, and contract stakeholders.

That is exactly the kind of consensus-building that SIers are supposed to be good at.

Not “expensive or cheap,” but “explainable or not”

In SI work, cost reviews often become discussions about whether something is expensive or cheap.

Of course, budgets matter.

But I think the more essential question is whether the cost can be explained.

Some costs are high but explainable.

Some cost reductions are cheap but dangerous.

For example, if a redundant architecture adds cost but reduces business continuity risk, that cost can be explained. On the other hand, if unused resources or purposeless log retention continue to generate cost, even small amounts become hard to justify.

A Frugal Architect-style design review asks questions such as:

  • Which risk does this cost reduce?
  • Which customer experience does this cost protect?
  • Which operational task does this cost reduce?
  • Does this cost contribute to future changeability?
  • If this cost increases, can we trace why it increased?

The starting point for cloud cost design is not the amount itself, but whether the causal relationship can be traced.

Is “we cannot let the system go down” becoming an excuse for overspecification?

There is another question SIers cannot avoid.

Is the phrase “we cannot let the system go down” becoming an excuse to justify overspecification?

Of course, some systems really must not go down.

Social infrastructure, payments, healthcare, security, core business systems, customer-facing systems. If downtime would have major business or social consequences, investing in availability is absolutely reasonable.

The problem begins when “must not go down” remains undifferentiated and every component is given the same level of strength.

  • Which functions would truly cause business impact if they stopped?
  • At what time of day would downtime be most harmful?
  • How many minutes of downtime are tolerable?
  • Is degraded operation or manual fallback possible?
  • Would read-only operation be enough?
  • Which matters more: recovery time or data loss?
  • Does every function need the same availability level?

If these questions are not broken down, the design naturally shifts toward the safe side.

Designing on the safe side is not evil. But the cost is transferred somewhere.

It appears as infrastructure cost. It appears as operation cost. It appears as maintenance cost. Eventually, it appears in service pricing or customer burden.

In other words, unexplained availability leads to unexplained price increases.

What Frugal Architect asks is not “do not make systems highly available.”

It asks:

“What business value does this availability protect?”

“How much is the business, or the user, willing to pay for it?”

“Can the same purpose be met through a cheaper architecture, operation model, or graceful degradation design?”

Availability is not sacred. It is a non-functional requirement, and therefore a trade-off.

That is why we need to distinguish between availability that must not be cut and availability that has simply been overbuilt.

It takes courage to cut, and courage not to cut

Observability is important.

But before observability, we need the attitude to decide what to cut and what not to cut.

It takes courage to cut.

Review a configuration that has been running for a long time. Reduce resources that had extra headroom. Stop excessive retention or excessive redundancy. Delete things that are no longer used. These are not merely cost-reduction tasks. They are acts of questioning things that had quietly become sources of reassurance: “Do we really need this?”

It also takes courage not to cut.

When a cost-reduction mandate becomes strong, it is tempting to cut whatever produces visible short-term savings: monitoring, logs, backups, redundancy, security, test environments. But if those things support incident response, auditability, recovery, or customer trust, then the decision not to cut them also needs accountability.

In other words, a Frugal Architect is not “someone who cuts.”

A Frugal Architect cuts what should be cut and keeps what should be kept.

Observability is needed to support that judgment.

It is not that we cannot cut because we cannot see. Cutting while blind is dangerous.

It is not that we should keep things because we cannot see. Keeping things while blind preserves overspecification.

Observability is not the goal. It is the prerequisite that supports the courage to cut and the courage not to cut.

Practice means making small improvements repeatable

One thing GameDay made very clear to me was that cost optimization is never a one-shot activity.

We should not try to guess the perfect architecture from the beginning.

Observe. Form a hypothesis. Make a small change. Watch the impact. Move to the next improvement.

That loop matters.

In SI projects, the center of gravity changes after release.

The build team leaves, and the operations and maintenance team takes over. The original design intent fades. Even when there is room for improvement, the system can fall into a state of “it is stable, so do not touch it.”

But in the cloud, “running stably” and “running at an appropriate cost” are different things.

This is where operations and maintenance can create new value.

Not merely preventing incidents, but continuously improving the cost efficiency of systems that keep running.

This can be incorporated into monthly reports and regular meetings:

  • major cost changes from the previous month
  • relationship between usage and cost
  • review of unused or underused resources
  • validity of log, backup, and data retention policies
  • small optimization experiments for the next month
  • costs that were intentionally not reduced, and why

When these items become part of regular operational reporting, maintenance changes from “keeping the system from stopping” to “improving cost per value.”

Practices SIers can take back to real projects

Without touching specific GameDay content, I think SIers can bring the following practices back to real projects.

1. Add a cost section to non-functional requirements

Cost should not live only in a separate estimate sheet. It should be part of non-functional requirements.

What needs to be written is not only the amount.

Write the unit cost, growth factors, monitoring method, qualities that must be preserved during cost reduction, and review frequency.

2. Record cost rationale in architecture decision records

In ADRs, record not only performance, availability, and security rationale, but also cost rationale.

If we leave behind why this architecture was chosen, why this headroom was included, or why we intentionally did not optimize something yet, we can revisit those decisions later.

3. Treat tagging as accountability design, not billing management

Tags are not only for splitting invoices.

They are a design for accountability: who will look at this, who will fix it, and which service, environment, or role it belongs to.

4. Do not decide logging and monitoring by “more is safer”

More logs and metrics are not automatically better.

Define the required visibility and retention period. Separate what must be queryable immediately from what only needs to be available later.

5. Include continuous cost improvement in operations and maintenance

Do not treat cloud cost review as a special task after an incident or budget problem.

Make it part of monthly or quarterly operations.

6. Make both “costs to cut” and “costs not to cut” explicit

Cost optimization is not only about deciding what to cut. It is also about deciding what not to cut.

It takes courage to cut, and courage not to cut.

Costs that support security, auditability, availability, recoverability, and other business-critical qualities should be explained as investments, not treated as automatic reduction targets.

My biggest takeaway

My biggest takeaway was that Frugal Architect is not merely a set of optimization techniques for cloud engineers. It is a language of design responsibility.

SIers stand in a position where they must handle the customer’s business, budget, risk, operations model, contracts, and future changes together.

In that sense, Frugal Architect fits SI work very well.

But if we reduce it to “we can lower your AWS cost,” it becomes shallow.

The real value lies in being able to discuss these questions with the customer:

  • How much are we willing to pay for each quality attribute?
  • How much are we willing to pay for each risk reduction?
  • How should we prepare for future growth?
  • Which costs should we reduce now?
  • Which costs should we keep for future flexibility?

Making these questions a shared language across design, estimation, and operations is, to me, the SIer-style practice of Frugal Architect.

Closing

AWS GameDay was a place where I could experience architectural thinking by actually doing things with my hands.

But its value was not in learning “what to configure and how.” It was in physically understanding why certain decisions matter.

Treat cost as a non-functional requirement.

Connect cost to business value.

Observe, explain, and continuously adjust cost.

This is not a bag of cloud tricks. It is a design attitude that SI work will increasingly need.