While both a Scan with a FilterExpression and a Query with KeyConditionExpression may return the same results, there is a big difference in the way this is done, its performance, and the cost to you. In your case, it is strongly preferrable to use a Query, not a Scan. Let me explain:

A Scan always scans the entire table. It may filter out things according to FilterExpression, but DynamoDB still needs to read all the items in table, and you will pay for these reads. Doing a scan with a very selective FilterExpression (which only returns a small subset of the table) is almost always a bad idea. It will be very slow and cost you a lot, relative to the amount of data you are trying to read.

On the other hand, Query can efficiently skip directly to the partition you asked for (the KeyConditionExpression can only specify a single partition key), and inside this partition, read only the sort-key range which you specified in KeyConditionExpression. The time it takes to do that, and the cost to you, will only be proportional to the number of items you actually read - even if those are only a small subset of the entire table.

Query can do this efficiently because of the way DynamoDB partition keys and sort keys work: The partition key is also called a "hash key" because it allows DynamoDB to find the specific partition efficiently, as in a hash table, without scanning the entire table. Then, inside one partition, items are sorted by the sort key, so to find a contiguous range of sort keys (as KeyConditionExpression allows to specify), DynamoDB does not need to scan all the items in the partition - it can find the requested range efficiently in O(logN).

You are right about using an expression attribute names

If an attribute name begins with a number, contains a space or contains a reserved word, you must use an expression attribute name to replace that attribute's name in the expression.

aws dynamodb scan --table-name cc_career --return-consumed-capacity "TOTAL" --projection-expression "#fn,#dt" --expression-attribute-names '{\"#fn\":\"Email\",\"#dt\":\"Full Name\"}'

The problem here is that you are missing filter expression https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Scan.html#Scan.FilterExpression

Considering the table design with ID as PK and Full Name and Phone Number using below command I was able to scan Data based on Full Name

aws dynamodb scan --table-name stack_overflow --filter-expression "#fn = :t" --expression-attribute-values '{":t":{"S":"Jatin Mehrotra"}}' --expression-attribute-name '{"#fn":"Full Name"}

My results after running above command

{
    "Items": [
        {
            "ID": {
                "N": "1"
            },
            "Full Name": {
                "S": "Jatin Mehrotra"
            },
            "Phone Number": {
                "S": "123456789"
            }
        }
    ],
    "Count": 1,
    "ScannedCount": 1,
    "ConsumedCapacity": null
}

There is no limit to the number of attributes but the total item size is limited to 400kb.

Items

Item Size

The maximum item size in DynamoDB is 400 KB, which includes both attribute name binary length (UTF-8 length) and attribute value lengths (again binary length). The attribute name counts towards the size limit.

For example, consider an item with two attributes: one attribute named "shirt-color" with value "R" and another attribute named "shirt-size" with value "M". The total size of that item is 23 bytes.

Attributes

Attribute Name-Value Pairs Per Item

The cumulative size of attributes per item must fit within the maximum DynamoDB item size (400 KB).

Number of Values in List, Map, or Set

There is no limit on the number of values in a List, a Map, or a Set, as long as the item containing the values fits within the 400 KB item size limit.

Docs

That’s allowed. Only the partition and sort keys require fixed type definitions, the rest are flexible.

Just don’t expect to later build a GSI using the attribute of mixed type.