It needs to support processing all packets that will cross the backplane of the router. So, often you can just need to aggregate all the interface ingress rates.
It can be a bit complex when you start to deal with half-duplex links (rather rare, now a days) or where you have asymmetric interfaces bandwidths.
For example, consider you have a full duplex LAN gig interface and a full duplex WAN 100 Mbps interface. (Also assume all the LAN ingress becomes WAN egress and, the converse, i.e. all WAN ingress becomes LAN egress.)
As WAN ingress cannot exceed 100 Mbps, we only need to have a router capable of 100 Mbps, to support just that. Further, as WAN egress is also 100 Mbps, we need to allow/support LAN ingress of 100 Mbps. I.e. 200 Mbps, total forwarding. However, as the ingress is gig, it can burst above the WAN's egress capacity of 100 Mbps. In theory, then we need to support up to 1.1 gig of forwarding bandwidth. Practically, though, sustained LAN ingress gig will start to overflow WAN egress buffers, so do we really need 1.1 gig for forwarding bandwidth? Maybe, maybe not. We may need more than 200 Mbps capacity (which will never average above, because of the WAN interface's bandwidth), but may need some additional processing capacity beyond what the 200 Mbps average would require. Again, it's difficult to say how much, if any, bandwidth forwarding capacity you'll need beyond the bandwidth bottleneck, as much depends on how "big" the gig bursts are, whether we want to queue them, and the architecture of the router.
BTW, if we run the LAN interface at 100 Mbps, then we "know" router will never see more that 200 Mbps of ingress (100 possible from both LAN and WAN) bandwidth.
