AWS Instance Type Recommendations and AWS AMI

Not applicable

I am working on building a robust APIGEE environment within AWS. I noticed first there are no APIGEE ami's to be found in the market place. First, will this change soon? Most vendors seem to offer pre-built AMIs.

Second, are there some sizing recommendations for AWS instance types? I've read through much of the on-premise installation and I can loosely translate the requirements into AWS EC2 instance types but I am looking for some solid guidance.

Meaning, we are considering leveraging the low-cost T2 instance types to begin with and user Cloud Watch monitoring to help determine how we need to adjust EC2 servers per work load moving forward. Should be avoid T2 in production? Should we look at the general purpose "M" instances or "C" compute instances?

Thanks in advance.

Solved Solved
1 3 838
1 ACCEPTED SOLUTION

Hi -

We do not have plans to deliver AMIs for the Apigee Edge product. It should be pretty easy to automate the generation of an AMI for your own purposes, if you have credentials to download the Edge bits. I know that many vendors offer AMIs, but Apigee does not, and has no plans to distribute software in that format.

As for sizing - we don't recommend specific instances. When we run Edge ourselves on EC2, we have used various node types. Currently the c3.large and c3.xlarge nodes look attractive to us, for Message Processors. The load profile on these MP machines typically is compute heavy. Depending on what the API Proxies do, and the concurrency, you may want more memory to be able to handle more buffers for outstanding requests. We've arrived at this approach through empirical observations. Your load profile may be different than the typical Edge SaaS customer.

For other node types - management server, analytics server, datastore (Cassandra) server, and so on, the optimal node type is different, and we use M for those. Analytics servers might benefit from m3.xlarge, if you have high traffic. If you have low traffic, then you won't need as powerful a machine. Similar reasoning applies to the datastore nodes.

Sorry to say, I cannot make a recommendation for or against using T2 in production systems. The Apigee Edge software will run just fine on a T2 node, and with appropriate distributed system architecture, it will be reliable. This instance type may be completely adequate for your purposes, depending on your load profile.

I like your approach of monitoring the system to determine which instance type is optimal. This is the approach we have taken. It's important to keep in mind the stakes. If you are deploying hundreds of similar nodes, then it becomes important to optimize the instance type, because the savings is multiplied by the number of nodes. If you are deploying 2-3 nodes for message processors, and the difference in cost between instance types is $15/month, your net total potential savings is $45/month. In this case, it does not make sense to spend much time performing the economic analysis, unless your time is worthless.

View solution in original post

3 REPLIES 3

Hi -

We do not have plans to deliver AMIs for the Apigee Edge product. It should be pretty easy to automate the generation of an AMI for your own purposes, if you have credentials to download the Edge bits. I know that many vendors offer AMIs, but Apigee does not, and has no plans to distribute software in that format.

As for sizing - we don't recommend specific instances. When we run Edge ourselves on EC2, we have used various node types. Currently the c3.large and c3.xlarge nodes look attractive to us, for Message Processors. The load profile on these MP machines typically is compute heavy. Depending on what the API Proxies do, and the concurrency, you may want more memory to be able to handle more buffers for outstanding requests. We've arrived at this approach through empirical observations. Your load profile may be different than the typical Edge SaaS customer.

For other node types - management server, analytics server, datastore (Cassandra) server, and so on, the optimal node type is different, and we use M for those. Analytics servers might benefit from m3.xlarge, if you have high traffic. If you have low traffic, then you won't need as powerful a machine. Similar reasoning applies to the datastore nodes.

Sorry to say, I cannot make a recommendation for or against using T2 in production systems. The Apigee Edge software will run just fine on a T2 node, and with appropriate distributed system architecture, it will be reliable. This instance type may be completely adequate for your purposes, depending on your load profile.

I like your approach of monitoring the system to determine which instance type is optimal. This is the approach we have taken. It's important to keep in mind the stakes. If you are deploying hundreds of similar nodes, then it becomes important to optimize the instance type, because the savings is multiplied by the number of nodes. If you are deploying 2-3 nodes for message processors, and the difference in cost between instance types is $15/month, your net total potential savings is $45/month. In this case, it does not make sense to spend much time performing the economic analysis, unless your time is worthless.

Thanks for relating your experience. I had an idea an answer would be along these lines but this helps confirm some ideas I had in my head. We will start out with T2 instances and ideally expand horizontally at first and I will take a look at going vertical with certain systems you referred to with likely higher compute requirements (but I should be able to see that at any rate using Cloud Watch and other tools we are using). Thanks for your response, as I learn I will update my progress and experience for others.

Michael, that will be very valuable for the community. I'd appreciate if you share back what you learn.