When the Windows Engineers were working initially on AWE for 32-bit processes they implemented it with a different API call so that only apps which knew how to handle the higher address spaces could use it, and because it's not going through the virtual memory manager, memory allocated with that API couldn't be paged out. So any memory allocated with the AWE APIs was locked in memory and required a special permission before an app could use it (you're bypassing some of Window's memory management, that's something which has to be explicitly granted to a process)

Later on, that 'can't be paged out' became a feature in itself and so the AWE memory allocation mechanism became use for preventing paging out, rather than it's original usage of allowing access to memory above the 4GB limit of 32-bit process address space and after the switch to 64-bit happened, there was no longer a need to accessing memory above what the process's address space could map (it's a ridiculously large number for a 64-bit process) and so the AWE APIs became solely for allocating memory which can't be paged out.

When you grant a process 'locked pages in memory', it uses the AWE APIs to allocate memory. It's not a dependency, the two are intricately linked. One is the API used, one is a permission required to use that API.