DEV Community: Zeke Sebulino

Create Basic Static website with AWS S3 and Terraform

Zeke Sebulino — Mon, 22 May 2023 04:58:37 +0000

variables.tf

variable "bucketName" {
  type    = string
  default = "example-web-app-terraform"
}

provider.tf

provider "aws" {
  region  = "ap-southeast-1"
  profile = "zeke"
}

main.tf

resource "aws_s3_bucket" "example" {
  bucket = var.bucketName
}

resource "aws_s3_bucket_public_access_block" "example" {
  bucket                  = aws_s3_bucket.example.id
  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

resource "aws_s3_bucket_policy" "example-policy" {
  bucket     = aws_s3_bucket.example.id
  policy     = templatefile("s3-policy.json", { bucket = var.bucketName })
  depends_on = [aws_s3_bucket_public_access_block.example]
}

resource "aws_s3_bucket_website_configuration" "example-config" {
  bucket = aws_s3_bucket.example.bucket
  index_document {
    suffix = "index.html"
  }
}

resource "aws_s3_object" "example-index" {
  bucket       = aws_s3_bucket.example.id
  key          = "index.html"
  source       = "./index.html"
  content_type = "text/html"
}

Why Docker?

Zeke Sebulino — Sat, 11 Mar 2023 16:29:07 +0000

Hello!

I've written this brief blog to introduce Docker to some developers in my small community of fellow developers.

What is Docker and Why Do You Need it?

If you're a software developer, you may have heard of Docker before, (I'm pretty sure you did already!). But what is Docker, exactly, and why is it such an important technology to learn?

In this blog, we'll explore the basics of Docker and show you how to get started using it. (Obviously theres a lot of existing youtube / blog that tackles what / why / how Docker is, but I'm glad if you stumbled upon this post and somehow this helped you get started with Docker)

At its core, Docker is a tool for containerizing applications. That might sound a bit technical, but it just means that Docker allows you to package up **all the code, dependencies, and configuration needed to run an application into a **single container. This container can then be run on any machine that has Docker installed, regardless of the underlying operating system or hardware.

Why Docker?

Consistent Environments:

With Docker, you can be sure that the environment in which your application runs is consistent, no matter where it's deployed. This makes it much easier to manage and troubleshoot applications, since you don't have to worry about differences in the underlying infrastructure / os. (Yup, this solves the "But It works on my machine" issue)

Portability:

Since Docker containers can be run on any machine with Docker installed, they can be easily moved between development, testing, and production environments. This makes it much easier to develop and test applications locally before deploying them to production.

Scalability:

Docker makes it easy to scale applications horizontally by running multiple containers in parallel. This allows you to handle more traffic or workload without having to invest in expensive hardware or infrastructure.

How to get started with Docker

If you're new to Docker, getting started can seem a bit daunting. But don't worry - Docker has a great getting started guide that walks you through the process step by step.

Here are the basic steps you'll need to follow:

Install Docker:

The first step is to install Docker on your machine. Docker has installation instructions for all major operating systems on their website. See HERE

Build Your First Image:

Once you have Docker installed, you can build your first Docker image. An image is basically a snapshot of your application and its dependencies at a particular point in time. To build an image, you'll need to create a Dockerfile, which is a script that tells Docker how to build the image. Once you have a Dockerfile, you can run the docker build command to build the image.

Run Your Container:

Once you have an image, you can run it in a container. A container is basically an instance of an image that's running on your machine. To run a container, you'll use the docker run command, which tells Docker to start a new container from the specified image.

And that's it! Of course, there's a lot more to Docker than just these basic steps, but they should be enough to get you started.

AWS Codebuild - List all projects and output into a file.

Zeke Sebulino — Mon, 06 Mar 2023 13:17:18 +0000

Hey there! So, I recently had to tackle the challenge of identifying all of our AWS CodeBuilds that were using soon-to-be-deprecated Linux images. Given the large number of builds in our project, manually sifting through each one would have taken forever.

To save time, I turned to the AWS CLI and crafted a command that would help me list out all of our CodeBuilds alongside their corresponding Linux images. This way, I could quickly identify the builds that needed updating.

Here's the command I used:

aws codebuild list-projects | jq '.projects[]' | xargs -I{} sh -c 'aws codebuild batch-get-projects --names "$1" | jq -r "\"\(.projects[].name) : \(.projects[].environment.image)\"" ' _ {} >> list.txt

It's a bit of a mouthful, but essentially what it does is use the list-projects command to fetch all CodeBuild projects, pipe them to jq to extract the project names, and then use xargs to pass each project name to the batch-get-projects command, which fetches the full project details including the Linux image. Finally, I used jq again to format the output as "project name : Linux image", and wrote the results to a file called list.txt.

Hope this helps you save some time too!

Running Your Node.js Backend on an AWS EC2 Machine: Making it Production-Ready

Zeke Sebulino — Mon, 06 Mar 2023 12:21:07 +0000

Running Your Node.js Express Backend on an EC2 Machine: Making it Production-Ready

If you're looking to run your Node.js Express backend on an EC2 machine, then there are a few key concepts that you should know to make it production-ready. In this post, we'll cover the most important concepts you need to know to make your backend reliable, scalable, and secure.

Security

When running your Node.js Express backend on an EC2 instance, security should be your top priority. Here are a few best practices to follow:

Use SSH key pairs for secure remote access
Configure a firewall (Security Group) to restrict access to only the necessary ports
Use SSL/TLS certificates to encrypt traffic
Configure Identity and Access Management (IAM) roles to manage permissions for accessing AWS resources.

Scalability

Scalability is crucial for any production-ready backend. To make sure your backend can handle a growing number of requests and users, you can use the following techniques:

Use Elastic Load Balancing (ELB) to distribute incoming traffic to multiple EC2 instances running your Node.js Express app
Use Auto Scaling to automatically add or remove instances based on demand.

Monitoring

To ensure your backend is performing well, you should monitor key metrics such as CPU usage, memory usage, and network traffic. You can use AWS CloudWatch to collect and analyze these metrics and set up alerts for any abnormal behavior.

High Availability

To minimize downtime in case of failures, you should design your backend for high availability. Here are some ways to achieve this:

Use multiple Availability Zones (AZs) to host your EC2 instances
Configure Elastic IP addresses to ensure that your instances have a consistent IP address even if they are stopped or restarted.

Deployment / CICD

A well-defined and automated deployment process is crucial for making changes to your backend without causing downtime or introducing bugs. You can use tools such as AWS CodeDeploy / Jenkins / github actions / gitlab ci to automate your deployment process.

Logging

Proper logging is essential for debugging issues and investigating errors. You can use tools such as AWS CloudWatch Logs.

Performance

Optimizing your backend for performance is critical to ensuring a smooth user experience. Here are a few ways to improve performance:

Minimize database queries
Optimize code
Leverage caching solutions such as Redis or Memcached
Use Amazon CloudFront to cache static assets and improve the performance of your application.

Conclusion

By following these key concepts, you can ensure that your Node.js backend running on an EC2 machine is production-ready and can handle the demands of your users. Remember to prioritize security, scalability, monitoring, high availability, deployment, logging, and performance. With these key concepts in mind, you can be confident that your backend will be reliable, fast, and secure.

AWS CodePipeline - Codebuild Error - npm ERR! code EPIPE

Zeke Sebulino — Wed, 01 Mar 2023 12:48:57 +0000

Fixing the npm ERR! code EPIPE Error in AWS CodeBuild

You may have experienced the npm ERR! code EPIPE error while running npm ci in AWS CodeBuild. This error typically indicates an issue with writing data to a file or a stream. There are various reasons why this error can occur, such as network connectivity issues, file permission issues, or conflicts with other processes running on the same system.

One potential solution to fix the npm ERR! code EPIPE error in AWS CodeBuild is to invalidate the CodeBuild project cache. This can be done using the AWS Management Console, the AWS CLI, or the AWS SDKs.

Invalidate the CodeBuild Project Cache in AWS Management Console:

Open the AWS Management Console and navigate to the CodeBuild console.
Select the CodeBuild project that is encountering the npm ERR! code EPIPE error.
Click on the "Build History" tab and find the build that failed with the error.
Click on the build ID to open the build details.
Click on the "Invalidate Build Cache" button to invalidate the CodeBuild project cache.
Re-run the build and check if the npm ERR! code EPIPE error has been resolved.

Invalidate the CodeBuild Project Cache Using the AWS CLI:

Open a terminal or command prompt and install the AWS CLI if you haven't already done so.
Run the following command to invalidate the CodeBuild project cache:

aws codebuild invalidate-project-cache --project-name <project-name>

Replace with the name of the CodeBuild project that is encountering the npm ERR! code EPIPE error.
Re-run the build and check if the npm ERR! code EPIPE error has been resolved.

Error message example

[Container] 2023/03/01 12:13:31 Running command npm ci
npm ERR! code EPIPE
npm ERR! syscall write
npm ERR! errno -32
npm ERR! write EPIPE

NodeJs Backend Application - Folder Structure / Boilerplate

Zeke Sebulino — Sat, 25 Feb 2023 00:59:24 +0000

Building a Node.js backend service can be a challenging task, especially when it comes to organizing the codebase in a way that is easy to understand and maintain. In this post, we'll explore the best folder structure and setup for working with a Node.js application for a backend service.

Why is folder structure important?

Before we dive into the details of the folder structure, it's important to understand why it's so important. A well-organized folder structure can make it easier to:

Understand the overall structure of the application
Find specific files and code quickly
Maintain the codebase over time
Scale the application as it grows
Without a clear folder structure, the codebase can quickly become chaotic and difficult to work with.

The best folder structure for a Node.js backend service

So, what does the best folder structure for a Node.js backend service look like? While there's no one-size-fits-all answer to this question, there are some general principles that can guide the organization of the codebase.

src

First and foremost, it's important to keep the source code separate from other files and directories in the project. For this reason, we'll create a src directory to hold all the source code for the application.

config

Next, we'll create a config directory to hold configuration files for the application. This might include environment variables, database connection settings, and other configuration options.

controllers

Controllers are responsible for handling incoming requests and sending responses back to the client. For this reason, we'll create a controllers directory to hold all the controllers for the application.

models

Models represent the data structures used by the application. For example, if the application is interacting with a database, models might represent tables or collections in the database. We'll create a models directory to hold all the models for the application.

routes

Routes define the endpoints for the API. We'll create a routes directory to hold all the routes for the application.

services

Services encapsulate the business logic of the application. They might interact with models, controllers, and other parts of the codebase. We'll create a services directory to hold all the services for the application.

utils

Finally, we'll create a utils directory to hold utility functions that are used across the application. These might include functions for error handling, validation, and other common tasks.

Putting it all together

With these principles in mind, here's what the overall folder structure for a Node.js backend service might look like:

/
├── .env
├── .gitignore
├── package.json
├── tsconfig.json
├── src/
│   ├── app.ts
│   ├── config/
│   ├── controllers/
│   ├── models/
│   ├── routes/
│   ├── services/
│   └── utils/
└── ...

As you can see, this structure is designed to keep the code organized and modular, making it easier to maintain and scale the application over time. By separating concerns into different directories, it becomes easier to make changes to specific parts of the application without affecting other parts.

I would also love to recommend to you to check the following so you can start write off the bat without manually creating your own boilerplate + a lot of utility tools it provides!

nx.dev
lerna

Datadog - export more than 5000 records.

Zeke Sebulino — Tue, 21 Feb 2023 04:18:24 +0000

You can use the following code to fetch more than 5000 records from Datadog API.

import axios from 'axios';
import * as fs from 'fs';

interface RUMEvent {
  // Define the properties of a RUM event here
}

interface RUMResponse {
  data: RUMEvent[];
  links: {
    next: string;
  };
  meta: {
    page: {
      after: string;
    };
  };
}

const getRUMData = async (
  apiKey: string,
  rumApplicationID: string,
  startTime: number,
  endTime: number
): Promise<RUMEvent[]> => {
  let cursor: string | undefined = undefined;

  const query = {
    filter: {
      query:
        '@application.id:0070aef4-9021-4b1a-8af8-85682b7d3f68 @action.name:element_timing @action.type:custom @type:action',
      from: startTime,
      to: endTime,
    },
  };

  let rumData: RUMEvent[] = [];
  let hasMoreData = true;

  while (hasMoreData) {
    const response = await axios.post(
      'https://api.datadoghq.com/api/v2/rum/events/search',
      {
        ...query,
        page: {
          limit: 5000,
          cursor,
        },
      },
      {
        headers: {
          'DD-API-KEY': apiKey,
          'DD-APPLICATION-KEY': rumApplicationID,
        },
      }
    );

    const responseData: RUMResponse = response.data;

    if (responseData.data.length > 0) {
      rumData = rumData.concat(responseData.data);
      cursor = responseData.meta.page.after;
      console.log(`current page response count : ${responseData.data.length}`);
      console.log(`current collected : ${responseData.data.length}`);
    } else {
      hasMoreData = false;
    }
  }

  return rumData;
};

const writeRUMDataToFile = async (
  data: RUMEvent[],
  fileName: string
): Promise<void> => {
  return new Promise((resolve, reject) => {
    const stream = fs.createWriteStream(fileName);
    stream.once('open', () => {
      data.forEach((event) => {
        stream.write(`${JSON.stringify(event)}\n`);
      });
      stream.end();
      resolve();
    });
  });
};

// Example usage
const apiKey = '<YOUR_API_KEY>';
const rumApplicationID = '<YOUR_APPLICATION_KEY>';
const startTime = 1676949491156;
const endTime = 1676950331699;

getRUMData(apiKey, rumApplicationID, startTime, endTime)
  .then((data) => writeRUMDataToFile(data, 'rum_data.json'))
  .then(() => console.log('Data written to file'))
  .catch((err) => console.error(err));

Verify if your code is running in AWS Lambda / Serverless

Zeke Sebulino — Mon, 20 Feb 2023 14:19:20 +0000

Are you developing a Node.js app to be deployed on AWS Lambda? If so, you may need to detect whether your code is running in the AWS Lambda environment or not. One way to do this is by examining the LAMBDA_TASK_ROOT environment variable. In this post, we'll explore how you can use this variable to detect if your Node.js app code is running on AWS Lambda.

What is LAMBDA_TASK_ROOT?

LAMBDA_TASK_ROOT is an environment variable that is automatically set by AWS Lambda for all Node.js functions. This variable contains the path to the directory where the code for the Lambda function is located. In other words, it points to the root directory of the Lambda function.

How to detect if your code is running on AWS Lambda?

To check if your Node.js app code is running on AWS Lambda, you can examine the LAMBDA_TASK_ROOT environment variable. Here's an example:

if (process.env.LAMBDA_TASK_ROOT) {
  // Running on AWS Lambda
} else {
  // Not running on AWS Lambda
}

This code checks if the LAMBDA_TASK_ROOT environment variable is set. If it is, it assumes that the code is running on AWS Lambda. If it's not set, it assumes that the code is not running on AWS Lambda.

It's important to note that this method is not foolproof. In some cases, the LAMBDA_TASK_ROOT environment variable may not be set even if the code is running on AWS Lambda. However, for most cases, it should be reliable.

If you encounter any issues, you can explore other environment variables that are set by AWS Lambda, such as AWS_LAMBDA_FUNCTION_NAME, AWS_REGION, and AWS_EXECUTION_ENV, among others.

AWS SES - Core Concepts

Zeke Sebulino — Sun, 19 Feb 2023 19:32:04 +0000

Hello, everyone!

In this blog post, I'm going to give you a rundown of the core concepts you need to know about Amazon Web Services Simple Email Service (AWS SES). AWS SES is a cloud-based email service that allows you to send and receive email using your own email addresses and domains. Let's dive into the key concepts.

Verified Senders

Before you can start sending email with AWS SES, you need to verify your email addresses and domains. This involves proving that you own the email address or domain you want to use. Once you've verified your email address or domain, you'll be able to send email from that address or domain using AWS SES.

Email Sending Limits

AWS SES has limits on how much email you can send. These limits are in place to ensure the service remains reliable and available for all users. There are two types of limits you need to be aware of:

Sending Limits: The maximum number of emails you can send per 24-hour period.
Sending Rate Limits: The maximum number of emails you can send per second.
It's important to monitor your usage and stay within these limits to avoid any interruptions in your email service.

Email Receiving

In addition to sending email, AWS SES also allows you to receive email. When you receive an email, AWS SES can store the email in an Amazon S3 bucket or deliver the email to an Amazon SNS topic. You can also configure AWS Lambda to process incoming emails.

Bounce and Complaint Handling

When you send email using AWS SES, there's a chance that some of your emails may bounce or be marked as spam by the recipient. AWS SES provides mechanisms for handling these bounces and complaints. You can configure AWS SES to send bounce and complaint notifications to an Amazon SNS topic or an email address of your choice.

DKIM and SPF Authentication

To ensure your emails aren't marked as spam, it's important to configure DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) authentication. DKIM and SPF help verify that the email is coming from a trusted source and can help improve deliverability.

Reputation Management

Maintaining a good reputation is critical when it comes to email deliverability. AWS SES provides tools for managing your email reputation, such as the ability to view your sending statistics and feedback loops. You can use this information to identify any issues and improve your email deliverability.

That's a brief overview of the core concepts of AWS SES. I hope this post has been helpful in getting you started with AWS SES. If you have any questions or comments, feel free to leave them below. And as always, happy coding!

AWS SQS Core Concepts: A Beginner's Guide

Zeke Sebulino — Sat, 18 Feb 2023 23:44:09 +0000

Introduction

AWS SQS (Simple Queue Service) is a fully managed message queuing service that enables you to decouple and scale your distributed microservices and serverless applications. SQS eliminates the complexity and overhead associated with managing and operating message oriented middleware, while providing a highly scalable, reliable, and secure messaging service.

In this blog post, we will explore the core concepts of AWS SQS and their uses.

Queues

Queues are the foundation of AWS SQS. They provide a way to store messages that are waiting to be processed by your application. A queue is a logical grouping of messages that can be processed by one or more consumers. Messages are stored in the queue until they are consumed by a consumer or until they expire. AWS SQS provides two types of queues: standard and FIFO.

Standard Queues

Standard queues provide a highly scalable and durable messaging system for distributed systems that do not require the exact ordering of messages. Messages are stored in the order they are received, but are not guaranteed to be delivered in the same order. Standard queues provide at-least-once delivery, which means that messages can be delivered more than once, but never lost.

FIFO Queues

FIFO (First-In-First-Out) queues provide the exact ordering of messages that is required by many applications. Messages are processed in the order in which they are received and are delivered exactly once. FIFO queues provide exactly-once processing, which means that messages are processed only once and are never duplicated.

Messages

Messages are the payloads of data that are sent between producers and consumers. They can be any string, up to 256KB in size. Messages can contain structured data in JSON, XML, or other formats, and can also contain metadata in the form of message attributes.

Producers

Producers are applications that send messages to a queue. A producer can be any application that has access to AWS SQS, including EC2 instances, Lambda functions, and external applications. When a producer sends a message, it specifies the queue to which the message is sent.

Consumers

Consumers are applications that retrieve messages from a queue and process them. A consumer can be any application that has access to AWS SQS, including EC2 instances, Lambda functions, and external applications. When a consumer retrieves a message, it specifies the queue from which the message is retrieved. A queue can have one or more consumers, and each consumer retrieves and processes messages independently.

Visibility Timeout

When a consumer retrieves a message from a queue, the message becomes invisible to other consumers for a certain period of time, called the visibility timeout. This ensures that the message is not processed by multiple consumers at the same time. If the consumer does not delete the message within the visibility timeout period, the message becomes visible to other consumers again.

Dead-Letter Queues

Dead-letter queues are queues that receive messages that could not be processed by the main queue. These messages are called "dead-letter messages" and can be analyzed to diagnose and fix the issues that caused them to be rejected. Dead-letter queues are useful for ensuring that messages are not lost, and for troubleshooting issues in your application.

Conclusion

In this blog post, we've covered the core concepts of AWS SQS and their uses. Queues are the foundation of AWS SQS, and messages are the payloads of data that are sent between producers and consumers. Producers send messages to a queue, and consumers retrieve messages from a queue and process them. Visibility timeouts ensure that messages are not processed by multiple consumers at the same time, and dead-letter queues are useful for troubleshooting issues in your application.

AWS IAM Core Concepts: Understanding Identity and Access Management

Zeke Sebulino — Sat, 18 Feb 2023 23:28:12 +0000

AWS IAM Core Concepts

AWS Identity and Access Management (IAM) is a service that allows you to manage access to AWS resources. It enables you to create and manage AWS users and groups, as well as define permissions that allow or deny access to specific resources.

Key Concepts

Users

An IAM user is an identity within your AWS account that you can use to securely access your resources. You can create and manage multiple users within your account and control their access to resources.

Groups

An IAM group is a collection of IAM users. You can use groups to specify permissions for a set of users, making it easier to manage their access to resources.

Roles

An IAM role is an AWS identity that you can create in your account that has specific permissions. You can assume a role to temporarily take on the permissions assigned to the role. This is useful for granting access to resources to services or applications that run on AWS.

Policies

An IAM policy is a set of permissions that you can attach to an IAM user, group, or role. A policy defines what actions are allowed or denied on specific resources.

Best Practices

Here are some best practices to follow when working with AWS IAM:

Use unique and strong passwords for IAM users.
Use IAM groups to manage permissions for multiple users.
Follow the principle of least privilege, giving users only the permissions they need to perform their tasks.
Use IAM roles to grant access to resources for services or applications.
Regularly review and rotate access keys for IAM users to ensure security.

Analogies to help you more understand things.

Imagine you are the owner of a company with multiple departments, and each department has specific job roles with different levels of access to company resources.

IAM users can be thought of as individual employees, each with their own unique login credentials and permissions. Users have access to only the resources that the owner has explicitly granted them access to.

IAM roles can be thought of as job titles that define a set of responsibilities and permissions that are necessary to perform a particular job function. For example, a "manager" role might have access to all employee files, while a "salesperson" role might have access only to customer data.

IAM groups can be thought of as teams of employees who have similar job functions or permissions. For example, a "marketing" group might have access to marketing materials, while an "engineering" group might have access to source code.

Managed policies can be thought of as company policies that are standardized across all departments. These policies define rules for access to company resources and are managed centrally by the owner. For example, a "security" policy might require that all users enable multi-factor authentication, while a "compliance" policy might require that all employees complete regular training.

In summary, IAM roles, users, groups, and managed policies work together to ensure that employees have access only to the resources they need to do their jobs, while the owner maintains control and oversight over all company resources.

Imagine a university with various buildings and rooms, and each room has a different level of access control. The university's security team needs to manage who has access to each room.

IAM Users are like individual students, each with their own unique ID and access to certain rooms. Users have their own login credentials and can be granted access to specific resources, such as EC2 instances or S3 buckets.

IAM Groups are like student clubs, with multiple users who share similar access needs. The security team can create groups based on specific permissions or job roles, and then assign users to those groups. This makes it easier to manage permissions for multiple users at once, rather than having to manage them individually.

IAM Roles are like temporary visitor badges. They are created to provide temporary access to resources to users or AWS services without the need to create an IAM user. For example, an EC2 instance can be assigned an IAM role, which allows it to access specific resources for a set amount of time.

Managed Policies are like the university's access control policy, which is defined by the security team. The policy determines which rooms can be accessed by which users or groups, and what actions they can take within those rooms. Similarly, a managed policy in IAM is a set of permissions that can be assigned to multiple users, groups, or roles. It simplifies permission management and ensures consistent access control across your organization.

Conclusion

AWS IAM is a powerful service that allows you to manage access to your AWS resources. By following the key concepts and best practices outlined above, you can ensure that your resources are secure and your users have the appropriate level of access.

Understanding AWS SNS

Zeke Sebulino — Sat, 18 Feb 2023 17:26:14 +0000

Amazon Simple Notification Service (SNS) is a fully managed messaging service provided by Amazon Web Services (AWS) that enables you to publish messages to a variety of endpoints or subscribers, such as email, SMS, mobile push notifications, and HTTP endpoints.

SNS is designed to be highly available, durable, and scalable, making it suitable for sending large volumes of messages, including high-velocity events and notifications. SNS offers a pay-as-you-go pricing model, so you only pay for what you use.

SNS works by allowing you to create topics, which are essentially channels for sending messages. You can then subscribe endpoints or subscribers to these topics, which will receive any messages that are published to the topic.

SNS offers several features, including:

Message filtering: allows you to set up subscription filter policies, so subscribers only receive messages that match their interests.
Message encryption: allows you to encrypt messages using AWS Key Management Service (KMS) for enhanced security.
Message fan-out: allows you to send the same message to multiple endpoints or subscribers simultaneously.
Delivery status tracking: allows you to track the delivery status of messages and receive notifications when messages are successfully delivered or when delivery fails.

Here are some key features of AWS SNS:

Topics: A topic is a logical access point for sending and receiving messages. You can create a topic for a specific use case and then publish messages to the topic. Subscribers can then receive messages from the topic.

Subscriptions: A subscription is a connection between a topic and a subscriber. You can subscribe to a topic using email, SMS, mobile push notifications, HTTP/S endpoints, or AWS Lambda functions.

Publish: You can publish a message to a topic using the AWS Management Console, AWS CLI, or API. SNS will then deliver the message to all subscribed endpoints.

Filtering: SNS supports message filtering based on message attributes. This allows you to deliver messages to specific subscribers based on their interests or preferences.

Encryption: SNS supports message encryption using AWS Key Management Service (KMS) to encrypt messages in transit and at rest.

Mobile push notifications: SNS supports mobile push notifications for Android, iOS, and Amazon devices. You can use SNS to send notifications to mobile app users in real-time.

Cost-effective: SNS is a pay-as-you-go service, meaning you only pay for what you use. There are no upfront costs or minimum fees.

In summary, AWS SNS is a flexible and scalable messaging service that enables you to send messages to a large number of subscribers or endpoints. It's a cost-effective way to deliver notifications, alerts, or messages in real-time across different channels.

Overall, AWS SNS is a powerful and flexible messaging service that can help you to send notifications and messages to your users or customers through multiple channels.

Analogies that can help you understand more about this service.

1. Think of AWS SNS as a news broadcasting system. Just like how a news broadcaster delivers breaking news to a large number of viewers, AWS SNS delivers messages to a large number of subscribers or endpoints.

In this analogy, the news broadcaster is the publisher, the viewers are the subscribers, and the breaking news is the message. Just as the news broadcaster can send breaking news to a large number of viewers across different channels (TV, radio, internet), AWS SNS can send messages to a large number of subscribers across different endpoints (mobile devices, email, SMS, HTTP endpoints, and more).

Moreover, just as the news broadcaster can customize the breaking news based on viewer preferences (e.g. sports news, weather news, politics news), AWS SNS can customize the message based on subscriber preferences using message filtering based on message attributes.

2. Think of AWS SNS as a megaphone that you can use to broadcast messages to a large group of people. Just like a megaphone amplifies your voice so that it can be heard by a crowd, SNS allows you to send messages to a large number of subscribers across various channels.

Imagine you are the organizer of a music festival, and you need to make an announcement to all festival-goers at once. Instead of shouting the announcement to the crowd, you could use a megaphone to amplify your message and ensure that everyone can hear it. Similarly, you could use AWS SNS to send a message to all festival attendees via SMS, email, or push notifications.

In this analogy, the festival attendees represent the subscribers, and the megaphone represents AWS SNS. By using SNS, you can quickly and easily send messages to all subscribers in one go, without having to manually contact each individual separately.