"EU" is the generic term for Execution Unit. The ALU is one example of an execution unit. FADD and FMUL, i.e. the floating point adder or multiplier, are other examples - as, for that matter are (is) the memory unit, for loads and stores.
The EUs relevant to LEA instructions are the ALU (add, subtract, AND/OR, etc.) and the AGU (Address Generation Unit). The AGU is coupled to the memory pipelines, TLB, data cache, etc.
A typical Intel x86 CPU back when I wrote the first codegen guide had 2 ALUs, 1 load pipeline tied to an AGU, a store address pipeline tied to a second AGU, and a store data pipeline. As of 2016 most have 3 or 4 ALUs and more than one load pipe.
LEA is a 3 input instruction - BaseReg+IndexReg*Scale+Offset. Just like the memory addressing mode of x86, which actually has a 4th input, the segment base, that is not part of the LEA calculation. 3 inputs necessarily costs more than the 2 inputs needed for ADD.
On some machines, the ALU can only do 2 input operations. LEA therefore can only execute on an AGU, specifically the AGU used for load (because the store ALU doesn't write a register). This may mean that you cannot do LEA at the same time as Load, or two LEAs at the same time, whereas you can two Adds and a load in the same cycle.
On other machines, LEA can be done by one, or two or three, of the ALUs. Possibly instead of the AGU - possibly as well as the ALU. This proves more flexibility.
Or, the simple LEAs, eg regscale+offset, can be done on the ALUs, whereas the biggest LEAs, eg breg+iregscale+offset, may be restricted, or possibly even broken into two uops.
So, the question comes down to: which EU (Execution Unit) handles which LEAs? The ALU or the AGU? The answer depends on the machine.
Generic text in an optimization guide may simply say "EU" rather than "AGU or ALU, depending on the model" or "whichever EU is capable of handling that particular LEA".