On the subject of optimization, we shall start from the top, that is to say the earliest stage: the design stage.
Imagine iterating over your architecture plan time and time again, until you have convinced yourself and your colleagues that this is the best you can do with the information available at that time. Now imagine that, unless you have a very unusual use case, other people have already done similar iterations and have kindly shared the outcome.
Back to reality and fortunately, we were not far off. There is indeed a collective AWS knowledge base in the form of blog posts, case studies, and white papers available to anybody embarking on their first cloud deployment.
We are going to take a distilled sample of that knowledge base and apply it to a common architecture example, in an attempt to achieve maximum scalability, whilst remaining cost efficient.
The example is going to be one of a typical frontend (NGINX nodes), backend (DB cluster) and a storage layer deployment within a VPC:
Whilst, technically, our whole deployment is on the Internet, the visual segregation above is to emphasize the network isolation properties of a VPC.
Let us now examine this deployment one component at a time, starting with the VPC itself.
I am proceeding under the assumption that if you are still holding this book, you have likely accepted the way of the VPC.
How many VPCs are you foreseeing having? Would they be linked (VPC peering) or would you be bridging other networks in (VPN)?
The answers to these questions play a role when choosing the CIDR for a VPC. As a general rule it is recommended to avoid common (household router) network addresses such as 192.168.1.0 or 10.0.0.0.
Keep track of and assign different CIDRs if you have more than one VPC, even if you don't have an immediate need to peer them.
Consider a CIDR that will allow for large enough subnets to accommodate potential instance scaling with minimal fragmentation (number of subnets).
Availability Zones (AZs) are how we add resilience to a deployment, so we should have at least two of those. There might be configurations in which you have to use three, for example where a cluster quorum is needed, such as ZooKeeper. In that case, it is advisable to keep quorum members in separate zones in order to handle network partitions better. To accommodate this and to keep charges low, we could create subnets in three zones, deploy quorum clusters in all three, and other components (say NGINX hosts) in only two of those.
Let us illustrate an example where we have a Zookeeper and a web server (NGINX) component within our VPC. We have decided to use three AZs and maintain two sets of subnets: public and private. The former routing through the IGW, the latter via NAT:
Here we have the ELB spanning across all three AZs and public subnets respectively. In the private subnet space, we find two web servers plus our cluster of three ZooKeeper nodes giving us a good balance of resilience at optimal cost.
AWS enforces certain initial limits on every account, which might catch you by surprise when your environment starts scaling up. Important ones to check are: Instances, EBS and Networking limits found on the EC2 dashboard:
When requesting an increase, select a number that is high enough to provide a buffer for scaling, but not inadequately high as after all the limits are there to protect against accidental/erroneous overprovisioning.