This works for me:

sum(increase(http_request_duration_seconds_count{ecs_cluster=~"$ecs_cluster", instance_id=~"$instance_id"}[$__range]))

Activated instant query and set calculation to last not null

Here is the pane JSON:

{
  "cacheTimeout": null,
  "datasource": "Prometheus",
  "description": "",
  "fieldConfig": {
    "defaults": {
      "custom": {},
      "unit": " requests",
      "decimals": 0,
      "thresholds": {
        "mode": "absolute",
        "steps": [
          {
            "color": "blue",
            "value": null
          }
        ]
      },
      "mappings": [],
      "nullValueMode": "connected"
    },
    "overrides": []
  },
  "gridPos": {
    "h": 2,
    "w": 5,
    "x": 0,
    "y": 4
  },
  "id": 4,
  "interval": null,
  "links": [],
  "maxDataPoints": 100,
  "options": {
    "reduceOptions": {
      "values": false,
      "calcs": [
        "lastNotNull"
      ],
      "fields": ""
    },
    "orientation": "horizontal",
    "textMode": "auto",
    "colorMode": "value",
    "graphMode": "none",
    "justifyMode": "auto",
    "fieldOptions": {
      "calcs": [
        "lastNotNull"
      ]
    }
  },
  "pluginVersion": "7.1.0",
  "targets": [
    {
      "expr": "sum(increase(http_request_duration_seconds_count{ecs_cluster=~\"$ecs_cluster\", instance_id=~\"$instance_id\"}[$__range]))",
      "hide": false,
      "instant": true,
      "interval": "",
      "intervalFactor": 1,
      "legendFormat": "",
      "refId": "A"
    }
  ],
  "timeFrom": null,
  "timeShift": null,
  "title": "",
  "type": "stat"
}

That's a correct way to do it. You can also use increase() which is syntactic sugar for using rate() that way.

Can someone explain how the range selector

This is only used by Prometheus, and indicates what data to work over.

the Step and Resolution settings in grafana influence each other?

This is used on the Grafana side, it affects how many time slices it'll request from Prometheus.

These settings do not directly influence each other. However the resolution should work out to be smaller than the range, or you'll be undersampling and miss information.

Counter 101

why does the short time-range fluctuates when the counter goes only up?

Counter indeed only goes up. But this is of little use on its own - if a value only goes up why do you care about exact value? Today it's 1, tomorrow it's 42, and in a week it's 100500. What we really want is to know how quickly a counter is increasing over time (if it's of value 42 afer the first day, why is it 100500 in just a week and not near 294?).

If you really care about the actual value the Gauge should be used, which also might go down.

increase()

The increase() function in PromQL does exactly what you want to do with counters - it takes the history of metrics over a time frame and calculates how fast value is increasing.

Could a counter be increased by 10 during the first minute, and by 3 during the next minute? Sure, that's why increase graph goes up and down ("fluctuates"). When you set a small range interval like on the 2nd graph it's visible, when you set a large range interval like on the 1st graph - it's not (how much my_metric was increased over 4 month period at 08/14?, at 08/20?, .., at 11/30? always bigger and bigger since the range is a huge).

The details how exactly it's calculated and nuances (such as "why increase might return floating point number") are already described, f.e. see the answers at this post.

Aggregations

So my question is do I have the right approach for what I am trying to do?

Since you don't use labels, the query might be simplified:

sum(increase(my_metric[$__range])) ---> increase(my_metric[$__range]).

sum as an aggregation operator is especially useful with without and by optional clauses.

F.e. if you have my_metric being reported by several machines, labeled with instance label and you want the aggregate it away in a query (i.e. you don't care about each instance results but want them as a whole), you might want to use:

sum without (instance) (increase(my_metric[$__range]))