No, AES is a block cipher that encrypts precisely one block of plaintext and results in a block of ciphertext.
The amount of overhead depends on the mode, but it is usually limited to one block for the IV and one block of padding at most. When an authenticated mode is used such as GCM then you may have one block of authentication tag as well.
Adding to that is any kind of meta data to keep the structure intact, salt for password based key derivation etc. You would not expect an overhead more than 100 bytes or so, where AES and it mode only takes 32 bytes max (as padding and an authentication tag usually aren't used together).
So what can cause this overhead? The most likely culprit is encoding of the bytes. Many libraries output base64 instead of bytes if "raw" output is not specified. Base 64 adds an overhead of about 33% (4 characters for each 3 byte, plus one or two padding characters). This would be in line with your result.
Note that "hex" encoding is not the same as "raw" encoding of the bytes. Hexadecimals is a direct representation of each byte value in text using two hexadecimal digits 0-9 and A-F per byte. If you save these two characters they become a byte each, doubling the size in bytes of the ciphertext. Or, if you are unlucky and save in UTF-16 (the braindead default of .NET) you get a quadrupling in size.
It is of course also possible to wrongly implement the AES, even given a high level API. For instance you could read the input data in blocks and then encrypt each block separately. This could in principle more than triple the size (IV and padding or IV and authentication tag). Instead it is wise to look for a streaming option or update function in the library.