AWS Cost Estimation: What a Diagram Can Tell You

A box labelled “PostgreSQL” is not a budget. It says almost nothing about the instance, storage, redundancy or traffic you are going to pay for. Yet architecture conversations often end before anyone fills in those blanks.

That is why I put a cost view in Codelit. The useful part is not a precise-looking total. It is making someone ask, “What did we assume to get that number?”

Codelit's architecture estimator matches a node's label and type against a cost table, returns an indicative service and monthly amount, then totals the architecture. The implementation is intentionally small. It gives a design conversation a starting point without pretending the diagram specifies a deployment.

The current code follows this shape:

// Simplified from the architecture estimator.
const estimates = nodes.map((node) => ({
  nodeId: node.id,
  ...estimateNodeCost(node.label, node.type),
}));

const total = estimates.reduce((sum, node) => sum + node.cost, 0);

There are mappings for databases, caches, queues, compute, storage and other common node types. An unmatched label falls back to its node type. The cost view then shows the total and a breakdown.

That description matters because the previous version of this article went further than the implementation: it described a weekly AWS pricing feed, traffic tiers, reserved-pricing controls and topology-aware transfer calculations. Those are not supported by the current estimator code. They should not have been presented as shipped behavior.

The same boundary applies to infrastructure export. Turning a diagram into a useful starting point is not the same as producing a deployment that needs no engineering review.

A diagram leaves out most of the inputs that determine an actual cloud bill. Labels describe responsibilities, not resource consumption. Before using an estimate for a budget, name the configuration and workload assumptions that could change its largest line items.

A highly connected database is not automatically a heavily loaded database. Ten low-volume services can generate less traffic than one busy worker. Connection count can prompt a question; it should not masquerade as a sizing measurement.

This is the judgement gap behind learning system design: knowing the component name is easier than knowing what requirement justifies its configuration.

Build a range by varying explicit workload assumptions while keeping the service configuration visible. Separate the capacity you keep running from the usage you expect to consume. Low, expected and high scenarios are useful only if someone can explain what changes between them.

I would write the worksheet like this:

Daily active users are not a substitute for these inputs. Two applications with the same user count can have very different storage and compute requirements.

For a simple illustrative calculation, a resource assumed to cost $0.20 per hour contributes $146 in a 730-hour planning month. Two continuously running copies contribute $292 before storage, networking or tax. The rate is invented; the point is to make the multiplier visible.

Networking, storage performance, retention and managed-service add-ons deserve a separate pass because a high-level diagram rarely makes them explicit. Review the path and configuration before assigning a rate. Otherwise an estimator can invent charges as easily as it can omit them.

Cross-AZ traffic is a good example. Charging depends on the services and endpoints involved; replication and load-balancer paths can follow different rules. Do not multiply every arrow by one generic “cross-AZ” price. Use the relevant EC2 transfer pricing and RDS pricing documentation for the actual path.

The cost table also assigns zero to some external or payment nodes because their usage is unknown. Zero in that calculation does not mean free. It means the architecture total is incomplete until you add those charges.

Chaos exercises on a diagram are useful here: they make the consequence of removing a replica visible. They do not replace a recovery test against the deployed system.

A small application does not need Kubernetes merely because it uses containers. The choice should follow operational requirements, team experience and portability needs. Compare the complete deployment and the work to maintain it, rather than treating the control-plane fee as the whole decision.

On September 7, 2026, AWS lists EKS standard Kubernetes support at $0.10 per cluster-hour, or $73 using 730 hours. Extended support is $0.60 per cluster-hour. Worker resources and optional features are additional charges.

AWS's ECS pricing page distinguishes the EC2 launch type, which has no additional ECS charge, from other capabilities that can have their own fees. “ECS is free” is too broad to be useful.

The question I would ask is: what Kubernetes capability does this application need, and who will own it? If there is a clear answer, price it. If there is not, compare a simpler container deployment before adding the cluster.

Commitment discounts belong in the budget after you understand the baseline capacity you expect to keep. Price the on-demand design first, then evaluate the term, coverage and flexibility of a commitment. A discount on capacity you stop needing is not automatically a saving.

I would keep the following decisions separate:

• Right-sizing: how much capacity does the workload need?
• Availability: how much must remain when something fails?
• Purchasing: which usage can the business confidently commit to?

Combining all three into a single “optimised” total hides the trade-offs. The patterns behind reference architectures help with the first two. Purchasing terms require their own review.

The design review should end with a cost range, a short assumptions list and an owner for the largest unknown. That is a stronger result than an exact-looking total with no region, workload or recovery requirement attached.

Use Codelit's estimate to ask the first questions. Use the AWS Pricing Calculator when the configuration is concrete. After launch, compare the actual bill and workload with the assumptions that produced the estimate.

The outcome I want is straightforward: see the expensive decision while changing it is still a discussion, not a migration.