How often do I need to rotate AES 256 keys I'm trying to design a protocol for a resource constrained environment. The device has to communicate with a server through an insecure node. My plan is to use AES 256 end to end for all communications. From what I understand, keys carry a risk factor that increases with use and time. 

From reading this post: How much data can I encrypt with AES before I need to change the key in CBC mode? there is an equation for determining the maximum amount of data it is safe to send given an acceptable risk factor.

My question is two fold:


Is it necessary to factor time into this equation for devices that communicate infrequently with the same key?
How does one determine an acceptable risk factor?
Is it necessary to factor time into this equation for devices that communicate infrequently with the same key?
  


No. Time would only matter for attacks that require a lot of processing by the attacker. Basically, key recovery attacks, through either brute force (impossible with AES key size) or maybe weaknesses in the cipher (even known related key attacks aren't feasible either).

In comparison, the attack here only needs to store all the used ciphertext in a data structure so that duplicates are detected. If you use a hash table, that's $O(1)$ time per block.


  
  How does one determine an acceptable risk factor?
  


You have to understand the risk first.

The attack here is related to the block size of AES, i.e. 128 bits (even with your 256-bit keys the block size is 128). The risk factor essentially indicates the probability that a duplicate would be observed with a PRF after that many blocks. The advantage gained by the adversary is some information about the plaintext of some encrypted blocks. It does not allow key recovery.

What it means depends on the cipher mode used. For example:


If you are using CBC, like in the linked question, the risk is that two blocks of ciphertext are equal, leaking the xor of the corresponding plaintext blocks.
With CFB, if two ciphertext blocks are equal, it leaks the xor of the blocks following them.
With CTR, if counters remain unique, the risk is that two ciphertext blocks are equal. Here it only leaks the fact that the two plaintext blocks are different.
With OFB, a collision results in the rest of the key stream being equal, leaking the xor of the rest of the messages.


You have to decide how important it is that the attacker not learn that information.