Simple DoS-attacks use up the bandwidth.
But more sophisticated attacks use up other resources such as CPU time and memory. A SYN flood is targeted at using up memory, (and in some cases CPU-time on hardware firewalls).
For an attacker, however, it is easier to flood a victim with SYN-packets, if the victim has a huge bandwidth.
How is a TCP connection established?
TCP uses a three way hand shake:
Client --------- SYN -------> Server
Client <------ SYN,ACK ------ Server
Client ------- ACK,... -----> Server
The traditional way to handle the creation of a connection is this:
After the Server received a SYN packet, it has to allocate some memory to store the information about the connection (e. g. client IP, client port, server IP, server port). It acknowledges the SYN packet by sending a SYN ACK back to the source IP-address specified in the initial packet.
A SYN flood consists of lots of SYN packet for which the server has to allocate memory. The client can just send and forget about them. Furthermore the source IP-address can be set to anything (unless the ISP of the attacker has filters).
Why does the server have to remember the half opened connection?
The server needs to verify that the sender of the ACK-packet in step 3 is the one who sent the SYN-packet and received the SYN-ACK packet. This is the way TCP tried to protect against forged IP-addresses and packet injections.
(The protection does not work against an attacker who has access to a router through which the packets travel).
How to protect against SYN-floods?
Instead of allocation memory and store the information about the half opened connection, the server sends the required information back in the TCP-sequence number field in a cryptographic save way.
So when the final ACK-packet is received, it can extract the required information, verify it and establish the connection.
Wikipedia has a good article on SYN cookies.