Where Can I See All Running Aws Servic

Y'all're building a new application or migrating an existing application to the cloud. If you're considering AWS, you lot want to choice the right components to power your awarding.

But before you lot start cartoon nice AWS architecture diagrams, it's very important that yous follow the steps described in this commodity.

With more than 100 services available today, how practice you lot choose an AWS service with confidence? How do yous identify advantages and disadvantages of a particular AWS service? How do you know if a particular service will support all the permission scenarios your awarding requires? How do you know information technology volition integrate nicely with other applications running in a particular AWS region? Is a particular AWS service even bachelor in your AWS region? Do you lot know how does AWS pricing work for this service? Will information technology handle your application's failure scenarios and hereafter growth?

Those are questions you want to respond every bit early as possible, before you start designing or coding anything. Choosing the right AWS services gets yous 1 step closer to running reliable applications that don't put at risk your business organisation revenue.

So let's become started…

Business First

This is the most important step in the whole process. Before yous choose any AWS service, you should know how it volition impact your business. I recommend to start with the post-obit:

What are the business flows this awarding will back up? (i.e. submit society, customer sign-up, etc.)
Who executes those business organization flows and where from? (i.east. customers, other systems)
What is the frequency of each concern flow? (i.e. 1000 orders per 60 minutes, 100 sign-ups per hour, etc.)
What volition happen to your business -in quantifiable terms, such equally lost revenue or number of negative mentions- if any of these flows stops working for: 1 minute, five minutes, 1 hour, 8 hours, 24 hours?

Having answers to those questions will give y'all the right context to brand important system decisions.

AWS Regions

Not all services are available in all AWS regions. Some services take a long time before they're released in certain regions (similar 500 days or more in some cases, if they become available at all).

Brand sure the service you're because is available in your chosen AWS region.
Evaluate the toll of all services your are considering in all AWS regions. Depending on the AWS region, some price dimensions tin toll as much as 177% more, compared to the cheapest region (i.e. outbound internet data transfer in Sao Paulo vs. N. Virginia).
For a more consummate analysis on AWS regions, take a look at this article.

Performance and Scalability

One of the well-nigh expensive errors often made is ignoring operation and scalability from mean solar day-1 of design. Your application volition somewhen grow (that'due south the whole point of building things, right?) and you don't want to find the limits of a particular application or AWS configuration when your customers are frustrated past ho-hum times or frequent outages.

To avoid expensive and embarrassing situations, I recommend you evaluate the post-obit:

Service limits

AWS sometimes seems like this infinite source of calculating ability, but at that place are limits. Particularly limits applied to your account.

Here are examples of some service limit dimensions:

Number of provisioned resource (i.east. EC2 instances, SQS queues, CloudWatch Alarms, IAM Roles/Users, S3 Buckets, VPCs)
Data memory periods (i.east. CloudWatch metrics, Kinesis streams, SQS message retention)
Throughput (i.eastward. concurrent Lambda executions, CloudWatch List/Describe/Put requests, SNS messages per second, Dynamo DB capacity units, EFS throughput in Gb/s)
Payload size (i.e. SQS messages, Dynamo DB items, Kinesis records, IoT messages, IAM policy size)
Storage size (i.e. EBS volume size)

Note that some limits can be increased (for instance, number of EC2 instances y'all can launch), while others cannot (for case, metric retentivity in CloudWatch). Make sure there are no deal breakers for your application in the "cannot be increased" category.

Here is a consummate list of AWS Service Limits

What tin can exist scaled in that detail AWS service

When evaluating a particular service, I recommend identifying those AWS resources or configurations that drive scale for your applications. This will allow you lot to start with the right capacity for each AWS service and have a strategy in place to scale your AWS components equally your awarding'due south usage grows.

Examples: provisioned EC2 instances, Dynamo DB capacity units, Lambda function concurrency, RDS read replicas, Rubberband Load Balancers, ElastiCache cluster size.

Who does the scaling for that AWS service and how?

In one case y'all place the AWS resources and configurations that bulldoze scale, y'all have to identify WHO does the scaling and HOW information technology is done, and so you can have a solid strategy in identify. I've identified the following categories:

Client does the scaling. There are mechanisms to increase scale, but they have to exist triggered explicitly by you.
- Examples: DynamoDB chapters units (if not using DynamoDB Machine Scaling), Kinesis number of shards, EC2 instance types, RDS read replicas, RDS storage increase, AWS Elasticsearch node count.
AWS does the scaling. Y'all don't have to worry nigh managing scale at all.
- Examples: Lambda function executions, S3 saucepan size and number of objects, Dynamo DB table size, SQS messages per second
Shared responsibility. AWS offers automatic mechanisms, but yous take to configure them.
- Examples: EC2/ECS Auto Scaling, Rubberband Load Balancer (configuration and pre-warming), DynamoDB Auto Scaling, RDS Aurora Read Replica Auto Scaling.

Scaling scenarios for the service under review

Once you lot identify the scaling mechanisms for a detail AWS service, I likewise recommend to evaluate and to design scaling strategies for the following usage scenarios:

Depression usage. How are you going to ensure that the AWS service nether review is not over-provisioned during periods of depression usage (i.e. at night or weekends, for some applications).
Steady growth. How is the service going to handle a gradual growth in usage over time.
Spikes. How is the service going to handle sudden spikes in usage, such as 1x, 3x, 5x, 10x.

After you place how to manage calibration, the next step is to include scaling strategies into your architecture and application pattern and implementation, as well as your capacity planning.

Availability

AWS has an army of extremely talented engineers ready to preclude and resolve all sorts of failure scenarios. Yet, failures in the AWS service under review will occur from fourth dimension to time. If yous want to minimize the take chances of lost revenue for your business, y'all have to consider the options a particular AWS service gives y'all in order to handle failure. Information technology's also worth considering how difficult it is to ready those mechanisms.

Failure scenarios (what tin become wrong)

Hither are some high level categories of error situations you might encounter for a particular AWS service:

Failure to access existing AWS resources.
- Examples: cannot describe EC2 instances, GET API failures and elevated latencies
Failure to create new AWS resource.
- Examples: increased errors and increased latency when launching EC2 instances
Connectivity failure inside and betwixt Availability Zones.
- Examples: increased errors and latency between RDS master and read replicas, connectivity errors and increased latency between EC2 instances in the aforementioned, or different, AZs.

I highly recommend assessing the common error scenarios for a particular service and beginning the design of your failure recovery strategies from in that location. A peachy starting point is going to the AWS Service Health Dashboard page and taking a look at the status history for a particular service, in all AWS regions. This will give you an idea of the blazon of failures that have occurred in the past.

Redundancy options

Redundancy is having extra AWS resources that volition accept over, in case of failure.

Examples: having actress EC2 instances prepare to immediately take traffic in case of failure, data replication in S3, Dynamo DB cantankerous-region data replication, RDS read replicas.

Consider:

AWS Cost (remember toll varies significantly between AWS regions)
Is it built into this AWS service, or do I take to implement it?
- If y'all have to implement it, how expensive volition information technology be to practise so?

Failover mechanisms

Failover mechanisms are the systems in place to bring those redundant AWS resources online.

Examples: Route 53 DNS failover that sends traffic to a backup region, EC2 Auto Scaling, ELB Health Checks.

Similarly to Redundancy options, evaluate if Failover mechanisms are built into AWS or if yous have to implement them yourself, likewise equally the cost of doing so.

AWS has multiple mechanisms to give you lot command and to ensure your AWS resources and data are accessed and stored deeply. Identity and Access Direction is the fundamental and global mechanism for authentication and permissions management in AWS. There are, notwithstanding, additional mechanisms and tools that vary past service.

Resource-based policies

A resource-based policy is assigned to a specific AWS resources, such every bit an S3 saucepan, SNS topic or SQS queue. This type of policy declares specific AWS accounts that tin access that resource and the operations that tin can be executed against it.

Resource-based policies are different from IAM Roles and provide a different model by which you lot can grant a third-political party access to your AWS resource. Non all AWS services support resource-based policies, therefore information technology's relevant to run across if a particular service supports them.

For more on resource-based policies, click hither.

CloudTrail support

CloudTrail is AWS auditing mechanism. It aggregates API activity for your AWS services, giving yous information such as: API functioning, who called it, when, where from and many other pieces of information.

While CloudTrail supports almost, if not all, AWS services, it doesn't necessarily back up all API operations for a particular AWS service. Therefore, it is important to evaluate which operations will exist bachelor in CloudTrail for the AWS service you're considering.

For more than on supported services by CloudTrail, click here.

Encryption at residuum

AWS has been gradually introducing encryption at rest for many services, including S3, EBS, Glacier, EMR, RDS, Redshift and DynamoDB. When assessing a particular AWS service, I recommend you consider the different options you become for encrypting data at rest, including using Key Management Service.

The following AWS whitepaper has skilful information on alternatives for encrypting data at balance (it'due south a bit dated, but nevertheless has good information).

Supported programming languages

AWS offers a wide range of programming languages in its Software Development Kits (SDKs) and all services are included in each SDK package. However, non all awarding lawmaking is implemented using SDKs.

Some examples:

API Gateway generates client SDKs for Javascript, Android and iOS clients.
Lambda functions can only be written in Python, NodeJS, Java, C# and Go.
Uncomplicated Workflow (SWF) only offers the Menstruum framework in Java and Scarlet.

My recommendation is that you look beyond the SDK and make sure all code components in your application are supported by the AWS service you lot're evaluating.

Integration with other AWS services

If you're evaluating a particular AWS service, most likely y'all won't use that service in isolation. You will have other architecture components, implemented using other AWS services, talking to each other.

I recommend that when evaluating a particular AWS service, you take a look at how easily yous tin integrate it with other services.

AWS congenital-in integrations

This is one of the coolest trends I've seen in AWS. In that location is a growing number of features that brand AWS service integrations very unproblematic. These features often deliver "out of the box", result-driven functionality that would accept taken customers a lot of work to develop and operate.

Here are some examples:

Origin	Target
CloudWatch Events	Lambda, SNS, SQS, Kinesis
CloudWatch Logs Subscriptions	Kinesis, Lambda
S3 Events	SNS, SQS, Lambda
Dynamo DB streams	Kinesis, Lambda
Kinesis	Lambda
IoT	CloudWatch Alarms and Metrics, DynamoDB, Elasticsearch, Kinesis, Lambda, S3, SNS, SQS
CloudWatch Alarms	EC2 Actions, SNS
EC2	CloudWatch Events
KMS	CloudWatch Events
SES	Lambda
Cognito	Lambda
CloudFormation	Lambda
API Gateway	Lambda
SQS	Lambda
CodeDeploy	CloudWatch Events
Auto Scaling	CloudWatch Events, SNS

A common pattern hither is that most integrations include AWS Lambda, which is great because Lambda functions give y'all the flexibility to implement custom code in response to those events.

Custom integrations

If you lot take whatever AWS cross-service integrations that are not built-in, then this is a good time to identify them and retrieve nigh the attempt information technology volition take to implement them.

Bachelor services in your chosen AWS region

Continue in mind that non all services are available in all regions. When you evaluate a particular AWS service and its integrations (built-in or not), it will exist much easier if all involved AWS services are bachelor in the same region.

Operations - Monitoring

Early design of operational procedures is extremely valuable. If y'all're considering a particular AWS service, evaluating its features in this area will help you identify architecture and awarding components that volition make your operations easier. The earlier you do this, the ameliorate. Since monitoring is an essential part of operational procedures, I highly recommend knowing which metrics are available for a item AWS service.

Bachelor CloudWatch metrics

CloudWatch is AWS metric aggregation service. All AWS services publish metrics to CloudWatch, which allow you monitor system health and take activity when things are non going as expected.

Here is the official list of supported CloudWatch metrics and dimensions.

In improver to metrics and dimensions, information technology is important to understand how often metrics are published (i-minute or 5-minute intervals). For example, while API Gateway publishes metrics every minute, EMR does and so every 5 minutes. EC2 gives you the option to publish one-minute metrics at an additional cost. Make certain metric intervals make sense for your application.

Consider using CloudWatch features such equally dashboards, metric percentiles, metric math and metric filters.

Missing CloudWatch metrics

The next natural pace is to place which metrics are Not bachelor in CloudWatch for a particular service, so you can pattern a strategy to capture all those additional metrics. For example, CloudWatch doesn't publish metrics for memory or disk utilization in an EC2 instance.

Once yous identify which metrics are not available in CloudWatch, a skilful culling is to await into third-party products similar New Relic, DataDog or open source solutions, such as collectd. You lot can also implement your ain custom metrics.

In any instance, identifying metric collection strategies should be part of any AWS service cess.

Operations - Incident direction

The main question to answer in this section is: "if I use this particular AWS service, how easy will information technology be to deal with incidents?"

Alarms and Notifications

All CloudWatch alarms accept the option to trigger an SNS notification. But one time CloudWatch sends a notification to SNS, you accept a number of options, such as calling an HTTP/HTTPS endpoint (useful for 3rd political party tools such as PagerDuty or VictorOps), invoking a Lambda office, sending a message to an SQS queue or sending an electronic mail.

Some questions to inquire are: if you use this AWS service, how volition you know when something is not right? Are the existing metrics for this service plenty to create a meaningful alert? Are i-minute or v-infinitesimal data points the correct window to determine if an alarm should be triggered? Exercise you demand something more than responsive than that? In one case a CloudWatch Alarm triggers an SNS notification, are my existing mechanisms enough to initiate prompt and constructive remediation? Do I need to create/suit response mechanisms if I utilise this particular AWS service?

Automatic remediation

Based on the failure scenarios you accept identified before, the master question hither is: "if I choose this AWS service, how can I fix issues automatically ?"

Consider options such every bit Machine Scaling, EC2 Deportment (Recover, Reboot), Lambda functions or custom remediation processes that can be triggered after an alarm is notified to SNS.

Operations - deployment and management

An oftentimes overlooked aspect when evaluating an AWS service is deployment automation. How are you going to automate setup and deployments to applications that are powered past this service?

Using CloudFormation

CloudFormation is ane of those AWS services that can relieve you a lot of pain and hours (even days) of transmission, irksome work. Using CloudFormation you can define your AWS infrastructure components and configuration using JSON or YAML templates. CloudFormation interprets these templates and orchestrates the creation and configuration of AWS resource. Information technology does accept a learning curve and it takes some time to get started - just once you create your start templates, it delivers great returns.

Fifty-fifty though well-nigh (if non all) AWS services and resources types are supported by CloudFormation, information technology'southward always a expert practice to double check. I recommend taking a await at CloudFormation's documentation and making sure it supports the AWS service you are considering and the resource types you need.

It'southward also important to place any automated processes that you need to run before, during or after resource creation for the AWS service under cess.

AWS Deployment Automation options

AWS offers a number of services geared towards deployment automation: CodeBuild, CodeDeploy, Code Pipeline, Elastic Beanstalk, OpsWorks. If none of these AWS services are a good fit, and then it'southward a good idea to evaluate third-party tools such as Ansible, Chef or Puppet.

Deployment rollback

How tin can you execute deployment rollbacks in this service? For example, can you apply Road 53 or ELB exercise to Blue/Green deployments? In the case of Lambda, versions and aliases are a great option for lawmaking rollbacks. How quickly (from incident detection to resolution) tin y'all rollback code if your application uses a particular AWS service?

Automation using CloudWatch Events

CloudWatch Events is a great AWS service that allows you to create rules that become automatically triggered based on pre-configured weather (i.due east. schedules, starting an EC2 instance, calling an API, Auto Scaling life wheel events, etc.) You can then do something equally a response to those events, such as executing a Lambda function or sending a message to an SQS queue, or SNS notification.

The question here is: "tin you use CloudWatch Events with this service?"

Level of commitment from your application's blueprint and lawmaking (will my application be "locked-in"?)

Whether you're building a new awarding or migrating an existing ane to AWS, in that location volition be design and coding considerations your application has to follow before you can use a particular AWS service.

At that place are some AWS services that you tin can use without doing whatever design or code updates. But there are some services that are deeply embedded into how you blueprint and implement your application. The more your pattern and lawmaking is geared towards a particular AWS service, the more difficult it volition be come to migrate your application out of AWS (a.k.a "lock-in"). Given the advantages that many AWS services offer, this is a very reasonable trade-off, simply you should be aware of it.

I've identified the following categories:

No, or minimal, blueprint or lawmaking considerations - just configure AWS components. Examples: CloudFront, Road 53, EC2, RDS, CloudWatch(built-in metrics), CloudFormation, Road 53, CloudWatch Logs
Design considerations are required, merely there are no AWS APIs required in your application code. As long equally your pattern is compatible, all you have to do is configure the AWS service. Examples: Auto Scaling, ELB, VPC, EMR.
Full general design considerations and AWS APIs are required in your application code. Examples: S3, SQS, CloudWatch (custom metrics), ElastiCache, SNS.
Fundamental design and lawmaking considerations. Your application is designed and built, from day-one, for these services. Examples: Lambda, Dynamo DB, Simple Workflow, IoT, Kinesis

The level of lock-in volition vary depending on your application and destination, just the following diagram shows a general starting signal:

Quadrant

In add-on to design and code implications, you should consider the cost of eventually migrating your data OUT of AWS. For example, transferring one Atomic number 82 of data out of S3 would cost you around $55K, while 100TB would cost approximately $8K. Most likely you would have to use AWS Snowball, or a lot of parallel processes on your end (unless you want to spend months exporting your data).

Migration

If you're migrating an existing application to AWS, y'all will need a detailed migration plan with very specific steps. Although AWS migration steps are beyond the telescopic of this commodity, I recommend you lot consider the following, when evaluating an AWS service:

Application updates required for migrating to AWS

Volition your application require significant updates to both design and awarding lawmaking? How significant are those changes? Is a migration as simple every bit but deploying your lawmaking on EC2 and configuring your AWS infrastructure? Practise yous even have to deploy application code? Have a await at the Lock-in diagram in this article for some examples.

AWS migration tools for the service nether review

If you'll be migrating an existing application, run across if in that location are AWS services that can help. Some examples are:

AWS Server Migration Service.
AWS Database Migration Service.
AWS Schema Conversion Tool.
AWS Management Portal for vCenter.
AWS Data Pipeline.
AWS Storage Gateway.
AWS Direct Connect.
AWS S3 Transfer Acceleration.
AWS Kinesis Firehose.
AWS Straight Connect.

Toll

Identify AWS price dimensions relevant to your application and AWS service

It is common to encounter some AWS customers ignoring very important price dimensions for their applications. For case, estimating EC2 cost only based on instance types and ignoring data transfer or storage.

Let's say yous're running a file server using a t2.Large instance and y'all only focus on hourly compute charges for that example blazon. The compute charges for one t2.Large instance would be around $68/month in N. Virginia. But if your application transfers one TB/ month out to the internet, you would pay $90/month on information transfer lone. i TB of EBS SSD storage (gp2) would cost yous $100/month.

Make this mistake at calibration and you're looking at thousands of dollars in unforeseen cost per month for your called AWS service.

Calculate price at scale

Yous build applications with success in listen, correct? When evaluating an AWS service, I recommend that you calculate pricing for low and high usage of your application.

Some AWS services cost less when usage grows. One instance is S3 storage, which has different price brackets depending on usage.

In a previous commodity near operating Lambda functions, I pointed out that a detail Lambda function can exist more expensive at 100TPS compared to a cluster consisting of 10 M3.big EC2 instances. The instance I gave includes a function that consumes 1000ms and requires 512MB of memory in each execution. The cost difference is $14,500 per year. If this function had depression book, Lambda would be a articulate winner in terms of price.

Compare pricing in ALL AWS Regions for a detail AWS service

Not all AWS services cost the aforementioned in all regions. There are cases with extreme price differences. When evaluating an AWS service, I recommend considering not just service availability in a item region, but besides price.

For example, 1TB of EC2 data transfer out to the cyberspace costs $250 in Sao Paulo, compared to $90 in N. Virginia (a 177% difference!)

Data Transfer out by region

Or take a t2.big EC2 instance. If you lot launched ane in Sao Paolo, yous would pay 60% more than compared to Northward. Virginia. If you thought N. California would exist the same price as Due north. Virginia, you lot would actually pay 19% more.

I wrote this article where I take a look at key differences in AWS regions.

Training

Skill Gaps Cess

At some betoken, someone volition have to work with the AWS service nether review. There are three principal areas to identify: 1)Current AWS knowledge in your team, 2)Required knowledge, 3)How to address cognition gaps.

Regarding required knowledge, consider areas you'll need for each of the sections covered in this article: AWS fundamentals (regions, Availability zones, available services, etc.), the AWS service under evaluation, IAM and other AWS security services (CloudTrail, Inspector, WAF, Cloud HSM, KMS, etc.), AWS services your application will integrate with, operations and deployment in AWS, price management in AWS too as migrating to AWS.

You tin can accost gaps through training, hiring, or by partnering with an AWS proficient.

Here is an article I wrote with some tips on what to wait for when hiring cloud engineers.

Considering alternatives

So, you analyzed a lot of factors and are not convinced a detail AWS service is a good fit. What to do adjacent?

EC2-hosted alternatives to AWS-managed services

This is non my favorite pick, but sometimes it's a valid one.

Let's say you lot're evaluating Dynamo DB or SQS, which are services 100% managed by AWS. It might be the example that you a find a deal breaker for your application and make up one's mind these services are not a good fit. One last step is to consider EC2-hosted alternatives. For example, Cassandra or MongoDB running on EC2. Or RabbitMQ running on EC2 instead of SQS. Mayhap Kafka running on EC2 instead of Kinesis.

I always recommend evaluating AWS-managed services get-go, since I really like to avoid managing infrastructure. Merely there are valid cases where an EC2-hosted solution could be a better alternative.

What if an AWS service is not the best choice?

Afterward yous take a look at all relevant factors, it might be the example that AWS doesn't offer the best solution for your application. Comparison other cloud providers or on-premise alternatives is beyond the scope of this article, only I encourage you to consider all options. At the cease of the day, you lot want to brand the most informed determination.

Just brand sure that when evaluating other services, yous consider the same factors that you did for AWS.

Create a deject implementation plan

Evaluating a particular AWS service is but the showtime. I recommend following the steps in this article each time y'all're designing or migrating an awarding. Each case is different and just because a particular AWS service was a skilful fit for previous implementations, doesn't mean information technology will exist for your next application.

Afterwards you've evaluated an AWS service, nigh likely you'll find gaps and areas that need to be addressed. All these gaps should be action items in your cloud implementation plan or backlog.

Conclusions

Whether you're designing, edifice or migrating an application, you should know as early as possible which AWS services it'southward going to use and be sure they're a skillful fit.
I highly recommend that you follow a systematic arroyo when evaluating AWS services. The number of services and variables to wait at arrive very easy to make critical mistakes.
These are the areas I recommend to focus on when evaluating a item AWS service:
- Identify and measure the business flows your systems and AWS services volition support.
- Programming language restrictions.
- Which AWS region you'll choose for this AWS service.
- Service limits, latency and how are yous going to calibration your application using this AWS service.
- Failure scenarios for that AWS service as well as redundancy options and failover mechanisms.
- Authentication, dominance, auditing and encryption options for this AWS service.
- How that AWS service integrates with other AWS services (built-in and custom integrations) and which AWS services are available to integrate with in the AWS region y'all've chosen.
- If you choose that AWS service, how are you going to monitor your application (built-in and custom metrics).
- If you choose that AWS service, how are yous going to operate your application (alarms, notifications,
  automatic remediation).
- What deployment automation options are available for that AWS service.
- How piece of cake it is to automate other processes if you cull that AWS service.
- Level of lock-in for that AWS service
- Cost at unlike levels of usage (depression to high).
- Migration options for that AWS service.

Exercise you lot need assistance with choosing the right AWS services for your applications?

I'd be glad to hear about information technology in a Free 30-infinitesimal consultation. I can certainly assist you lot take a successful product launch. Just click on the button below to schedule ane. Or send me a message using the contact form.