Amazon Web Services
I find Amazon’s documentation utterly undigestable and dry. These are some notes on Amazon Web Services in my own words.
Fun fact: Amazon Web Services (AWS) has only three partitions in the world.
aws- the AWS we know, the main one used almost everywhere in the world.
aws-cn- for the China Mainland market.
aws-us-gov- for the US government.
VPC = Virtual Private Cloud
Amazon VPC is a private internal network unique to your account. There is only one per account, that spans across all regions. One AWS account = one VPC.
The documentation’s claim of “Setting up a simple website or blog” as a primary use case of VPC is laughably off-the-mark. Virtual Private Cloud is for applications that require complex cross-region networking capabilities, such as database availability across regions, or applications that scale up and down based on different locations in the world.
AWS Lambda is Amazon’s “serverless” offering. Think of Lambda as pre-configured on-demand server-side runtimes. You can deploy almost any backend runtime onto a Lambda, and it will run and scale automatically as needed.
The advantage of doing this:
- Lambda is cheaper - you only pay for it when it’s running, it stops running when it’s not being used
- No maintenance cost for you, less dealing with server configuration/devops shit
The disadvantages of Lambda:
- Cold start times can be slow
- No shell access for debugging
Serverless is a different paradigm altogether from a traditional backend server application architecture, so you often need to structure your application from the ground-up in a way for it to work on Lambda. OR you find perfect sweet-spots for Lambda, like image resizing, etc.
Elastic Cloud Compute
EC2 is simple: this service provides stable Virtual Private Servers. They are usually quite lightweight, easily/quick to provision, and can support an entire Linux operating system on the image. They can be configured to have disk space, but these are not for storing stuff. They are for running stuff.
Generally, if you run a backend application on AWS, the EC2 is the main unit for backend compute power. Scale up = add more EC2 instances.
Elastic Container Service
ECS is not to be confused with EC2, but it is tightly related to EC2. This is a container orchestration service native to AWS, for managing/scaling your EC2 images.
In a way, it can be compared to Kubernetes or Docker Swarm, but specific/unique to AWS.
Simple Email Service
Useful Video: Amazon SES Tutorial | How To Send Emails Using AWS SES
Side note: Edureka is generally a good Youtube channel for videos on AWS topics.
Regardless, though, SES is a email sending service. For sending emails from your application, like marketing or transactional emails. I haven’t used it yet, though, so I’m not sure how good it is and what it’s limitations are. It seems like people still use something like Mandrill or Sendgrid for this stuff.
Simple Notification Service
This one is indeed very simple. It’s a lightweight publish & subscribe (pub-sub) message broker. You set up a topic, and create subscribers to those topics. A topic can have 1 or many subscribers. Messages get pushed out to subscribers.
The order of messages is not important. It’s an “at least once” message bus.
Simple Queue Service
SQS is a more legitimate message queue, not a pub-sub pattern. It cares about the ordering of the messages, and instead of pushing messages to consumers, it depends on consumers to pull (or poll) for messages.
The order (queuing) of messages is important — it’s usually configured as a First In First Out (FIFO) queue. It’s an “exactly once” message queue. Each message is only received by one subscriber.
People often use SNS and SQS together — use SNS to “fan out” events, publishing the same event to many subscribers. Then SQS for asynchronous processing, to decouple and leveling/flattening out the spike of whatever heavy events were piped through to SNS.