Considering AES-256 encryption, what is the maximum amount of data should be encrypted with one key? Does Block cipher modes/IV/counters also governs the limit?
If say the maximum amount is 50GB, does it mean the one file of 50GB has limit or 5 files of 10GB?
A block cipher is a Pseudorandom permutation: the key selects the function seemingly at random in the set of possible permutations of the space of block values (that space has size 2128 for the AES, since it has 128-bit blocks). Most usages of a PRP are fine as long as it looks like a Pseudorandom function. The difference between a PRP and a PRF is that the PRP will never give you two identical outputs for two distinct inputs, whereas the PRF may do so. However, a randomly selected function will give you such a collision only out of random, and it will require a lot of invocations: on average, 2N/2 invocations if processing blocks of size N.
Translation: when you encrypt more than 264 blocks with AES (i.e. 268 bytes, since an AES block is 16 bytes), AES begins to look more like a PRP than a PRF, and that's the point where you should stop. That's more than 250 millions of terabytes, which is quite a substantial amount.
It does not matter whether the said amount of data was processed as one, ten or 42 billions of whatever you may elect to call a "file". The AES processes blocks of 16 bytes and knows nothing else. On the other hand, it does not matter at all, since you will not practically reach that 268 bytes limit: AES was defined with 128-bit blocks precisely so that we could encrypt terabytes of data without worrying about a key running out of juice. When AES was specified, it was meant to replace 3DES, whose 64-bit block size was indeed worrying (232 blocks of 8 bytes, that's 32 gigabytes, which can be reached quite easily on today's machines).
Key size has nothing to do whatsoever with that matter. It is all about block size, and that's 128 bits for AES (regardless of key size).
Thomas Pornin (the other bear) posted an excellent explanation of how encryption modes affect this aspect of your cipher. The short answer is that if you use the output of the previous block to set the state for the next block, then you run the risk of repeating yourself.
And in OFB mode in particular, you get into a loop when the pattern repeats itself. This could be a very tight loop, or there's a chance that the loop won't repeat at all until all possible values are explored. The average loop size is at N/2 bits. Specifically, with 2N total possible states, on the average, you'll run through 2N/2 of those states before repeating. Since your state counter is typically the same size as your block, then with a block size of 128 bits, on the average you'll cycle through 264 blocks (not bits, not bytes) before repeating.
Conversely, "counter mode" ("CTR") operation uses a simple counter as the cipher state. This means you're guaranteed to cycle through the entire possible space before repeating. So if your state is 128 bits, then you'll cycle through all 2128 states before repeating.
It's worth pointing out that a space that size is effectively infinite. That's about 5,000,000,000,000,000,000,000,000,000,000,000,000,000 bytes before you have to change keys. And that's with a 128-bit block; with a 256-bit block, you double the number of zeroes.
CBC mode (probably the most common) uses the output of a given cipher block to set the state for the next block, which means that state is heavily affected by the content of the previous block encrypted. This means that the presence and size of cycles (if any) would be partly determined by the plaintext being encrypted. This makes the math a little less exact, but you should expest no worse performance than with OFB mode.
TL;DR: Use CTR mode and don't bother switching keys.
