You can do this:

<ng-template ngFor let-user [ngForOf]="users$ | async" *ngIf="(users$ | async)?.length > 1 && (users$ | async)?.length < 5">
  <div>{{ user | json }}</div>
</ng-template>

Keep in mind that when using a subscription from a http-request, this would trigger the request twice. So you should use some state-management pattern or library, to not make that happen.

Here is a stackblitz.

I hit the same issue of needing an *ngIf + async variable with multiple checks.

This ended up working well for me.

<div *ngIf="(users$ | async)?.length > 0 && (users$ | async) as users"> ... </div>

or if you prefer

<div *ngIf="(users$ | async)?.length > 0 && (users$ | async); let users"> ... </div>

Explanation

Since the result of the if expression is assigned to the local variable you specify, simply ending your check with ... && (users$ | async) as users allows you to specify multiple conditions and specify what value you want the local variable to hold when all your conditions succeed.

Note

I was initially worried that using multiple async pipes in the same expression may create multiple subscriptions, but after some light testing (I could be wrong) it seems like only one subscription is actually made.

I see everyone using *ngFor and *ngIf together in one tag and similar work-arounds, but I think that is an anti-pattern. In most regular coding languages, you don't do an if statement and a for loop on the same line do you? IMHO if you have to work around because they specifically don't want you to, you're not supposed to do that. Don't practice what's not "best practice."

✅✅✅ Keep it simple, if you don't need to declare the $implicit value from users$ | async as users:

<!-- readability is your friend -->
<div *ngIf="(users$ | async).length > 1"> ... </div>

But if you do need to declare as user, wrap it.

✅ For Complex Use Case; mind you, the generated markup will not even have an HTML tag, that's the beauty of ng-templates & ng-containers!

@alsami's accepted, edited answer works because *ngFor with asterisk is a shorthand for ng-template with ngFor (no asterisk), not to mention the double async pipe 🙏. The code really smells of inconsistency when you combine a no-asterisk ngFor with a *ngIf; you get the gist. The *ngIf takes precedence so why not just wrap it in a ng-container/ng-template? It won't wrap your inner elements using an HTML tag in the generated markup.

<div *ngIf="users$ | async as prods; then thenB; else elseB"></div>

<ng-template #thenB>
  <!-- inner logic -->
  <div *ngIf="prods?.length > 1 && users?.length < 5; else noMatchB">
    Loaded and inbound
  </div>
  <ng-template #noMatchB>Loaded and out of bound</ng-template>
</ng-template>

<ng-template #elseB>Content to render when condition is false.</ng-template>

❌ Don't do this

<!-- Big NO NO -->
<div *ngIf="(users$ | async)?.length > 1 && (users$ | async)?.length < 5"> ... </div>

Pipes are a bit daunting after you know about their sensitivity to life cycles; they update like mad. That's why Angular do NOT have SortPipe nor FilterPipe. So, erm, don't do this; you're basically creating 2 Observables that sometimes update frantically and may cause long-term data mismatch in its children if I'm correct.