A good answer from Gaurav, but I wanted to add a little more detail, since I think there might be a bit of confusion around web and work roles. Each role is a definition for a group of virtual machines that do the same thing that you built (you do not deal with the OS - you just run your application, and Azure takes care of the virtual machine itself).
When the cloud service is running, there will be at least one instance of each type of role. Thus, in your case, working as a web role role and a working role, you will have at least two virtual machines.
If you decide to reduce your web role to, say, 3 copies, and then decide to dial it up to 2 copies, you will not be able to choose which one to disable; it takes care of the azure fabric. Remember that each role instance has the same code, and Azure balances traffic with your role instances (through the external endpoints that you define). The only thing you need to worry about is shutting down. You have approx. 5 minutes to clear all running processes (and you can easily extract a specific instance from load balancing during shutdown, since you received the Stopping() event).
You cannot close the entire role (for example, all role instances) in the cloud service (so ... you cannot delete instances of the worker role, leaving instances of the web role). If this is a requirement, then you can always consider launching your web role in one cloud service and a working role in another cloud service. If they use queues for data transfer, everything will work as before. If web role instances need direct access to worker role instances, you can put both cloud services on a virtual network.
Another thing to consider: you do not need to have separate roles. If cost is a factor, you can run all of your code in your web role. Does a little work to deploy additional processes / threads in your web role, during OnStart() - remember that role instances are full Windows Server virtual machines; run whatever you want. With one definition of a role, scaling is a bit crude: everything scales together. With individual roles, you can fine-tune the scaling (which is much more important when building larger systems).
source share