If you have deployed your resources in a VPC, you are already moving in the right direction. Here we are mostly going to concern ourselves with network security and the tools or features a VPC provides for enhancing it.
These represent our first layer of defense as stated in the AWS documentation. Security Groups (SG) get assigned to EC2 instances (generally speaking) and provide a type of stateful firewall, which supports allow rules only.
They are very flexible and an EC instance can have multiple such groups assigned to it. The rules can be based on host IP addresses, CIDRs or even on other Security Groups, for example, allow inbound HTTP:80 from group ID sg-12345.
Usually, within a VPC we would create an SG per role, such as web server, db, cache. Instances of the same component would then be assigned the respective SG, thus regulating traffic between the different components of a platform.
Tip
It is often tempting to allow traffic based on the VPC CIDR address, resting on the fact that the VPC is largely an isolated environment. Resist that as much as possible and limit access to components that actually need it.
The db SG should allow traffic from/to the web server SG, but possibly not from the cache one.
The second layer comes in the form of Network ACLs.
The ACLs are stateless, they apply to the underlying subnet that an instance lives in and their rules are evaluated based on priority, just like an old fashioned firewall. As a bonus, you can also set deny policies.
Overall, both types of traffic management have their place in our VPC security design. ACLs should store a set of broader, less frequently changing rules, complemented by flexible Security Groups for fine-grained control.
If it so happens that you are using a VPC as an extension to your on-premise infrastructure, it would make a lot of sense to have the two sides more tightly connected.
Instead of restricting external access via Security Groups or ACLs, you could create a secure VPN channel, benefiting from the implied encryption.
You can connect your VPC to your office network using either a hardware or a software VPN solution (ref: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpn-connections.html).
For more demanding use-cases, one could even route their VPN traffic over a high-speed direct link to AWS using the AWS Direct Connect service (ref: http://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html).
In a similar situation, where instead of your office network you have another VPC which needs to communicate with your, let us call it primary one, you could use VPC peering:
A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IP addresses. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account within a single region.
AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck.
ref: http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-overview.html
Your VPCs will be able to communicate directly (within the same region) so you will not need to expose any services that do not explicitly need to be exposed. In addition, you can conveniently keep using private addresses for communication.