In general, iterators are distinct data structures than the primary struct that owns the data, in part due to issues like this, but also due to concerns around iterator invalidation and the need to carry around iteration state more generally.
For example, if you can call next on the a: A<'_>, then you can create a &mut a (exclusive and mutable access to a and all its fields), so you could also do
a.some_number.clear();
a.sum_number.shrink_to_fit();
Which would invalidate a.iter -- in this particular case it would also be UB if allowed, as iter would contain a dangling pointer that reads freed memory (which demonstrates that it must not be allowed).
Instead you could create a separte struct that borrows from A. With use of -> impl Trait, you might not even need to do the grunt work defining a wrapper struct or implementing Iterator.
The rest of this comment might only make sense for your reduced example and not your actual use case.
If you don't need access to the iterated fields except for iteration, then the iterator as presented is useless once iteration completes. Vecs have a cheap "default value", so you could consume the iterated fields in order to create the iter field.
iter is no longer any borrowing, so there's no need for a lifetime. But then, there's no reason to delaying creation of iter, either. (Also no need erase the iterator type in this particular example.)