maniish_jaiin

I am Manish and I am a Software Engineer by profession. I have been writing on Medium for a year now. I write majorly because it fulfills my desire to share my knowledge and gives me a creativity boost. 
I write on a variety of topics like Software Engineering, Tech, Programming, Developer Productivity, Apple Products, and a few more. I have worked at ThoughtWorks and BCG Digital Ventures and I am currently living in Berlin.

Software Engineer

Manish Jain

Learn how to simulate AWS services locally using LocalStack with a Spring Boot application.

**TL;DR:** This article demonstrates the use of LocalStack and how it can simulate many of the AWS services locally. We will use Spring Cloud Messaging to create a publisher-subscriber sample application. We will use Amazon SNS and SQS to do that.

The sample app can be found [here](https://github.com/maniish-jaiin/spring-cloud-messaging-sample).

## Spring Cloud Messaging With AWS and LocalStack

### Introduction

With an ever-growing demand for cloud services, Spring provides amazing support to integrate with Cloud providers and relevant services. [Spring Cloud for Amazon Web Services](https://spring.io/projects/spring-cloud-aws) is one such project that makes it easy to integrate with AWS services using familiar Spring APIs.

In this article, we will look into a simple application that acts as a message producer and a consumer using Amazon SNS and SQS. On top of that, we will not create an AWS account or use AWS services directly from AWS. We will instead use LocalStack, which will allow us to create AWS resources locally.

The sample app can be found [here](https://github.com/maniish-jaiin/spring-cloud-messaging-sample).

### Pre-requisites:

1. Basic knowledge of AWS, [AWS CLI](https://github.com/aws/aws-cli), and related services like Amazon SQS.
2. Basic knowledge of [Java 11](https://docs.oracle.com/en/java/javase/11/docs/api/index.html) and Spring Boot `2.4.7`.
3. [Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/) for the setup.

## Introduction to Amazon SNS and SQS

### Amazon SNS

[Amazon SNS](https://aws.amazon.com/sns/) is an acronym for Simple Notification Service. It provides developers with the highly scalable, cost-effective, and flexible capability to publish messages from an application and send them to other applications. It follows the pub-sub architecture to deliver messages from publishers to the subscribers. It is a highly decoupled service that can be linked to a variety of sources. It can be used to publish emails, messages to SQS, SMS, etc.

The Publisher (e.g., CloudWatch Alarm, S3 events, SNS, Micro-service) publishes the message on a Topic which is then published to all the Subscribers (web servers, email addresses, Amazon SQS queues, AWS Lambda) of that particular topic.

![SNS Architecture](https://images.ctfassets.net/23aumh6u8s0i/35P87aEWHIcpTOQxYTGWbz/03840ff6c13fdc4a94552ec8188c131e/sns_architecture.jpg)

### Amazon SQS

[Amazon SQS](https://aws.amazon.com/sqs/) is an acronym for Simple Queue Service, and the names convey a lot as it is really simple to use as it is a fully managed service from AWS. It follows similar messaging semantics of the producer putting a message on the queue and consumer reading from it.

Once consumed, the message has to be deleted from the queue. Deleting is important because SQS assumes that processing can fail. To prevent that, after the consumer receives a message, it is hidden from the queue for a defined period of time, and after that, if it is not deleted, the message shows up in the queue again.

Both SNS and SQS are fully managed lightweight, easy-to-use APIs. You can use Amazon SQS and SNS to decouple and scale microservices, distributed systems, and serverless applications and improve reliability.

### Introduction to LocalStack

[LocalStack](https://github.com/localstack/localstack) is an open-source mock of the real AWS services. It provides a testing environment on our local machine with the same APIs as the real AWS services. We switch to using the real AWS services only in the integration environment and beyond. There are plenty of reasons to use LocalStack, few out of which are more important than others, such as:

1. The ability to play with AWS services without interacting with AWS. All developers love to get their hands dirty, and what better way to learn something than to try. Localstack allows you to play with S3, SQS, DynamoDB, SNS, and the list goes on.
2. The ability to test the applications in the local dev environment. You can write integration tests for your application using LocalStack, driving down your costs and increasing the confidence in your code.

### Spring Cloud Messaging app linked to LocalStack

Spring Cloud AWS provides [Amazon SQS](https://aws.amazon.com/sqs/) and [Amazon SNS](https://aws.amazon.com/sns/) integration that simplifies the publication and consumption of messages. It reduces a lot of boilerplate code and does the heavy lifting for configuring and SNS and SQS. Let's set up a Spring boot project with support for SNS and SQS.

#### Setting up Spring Boot app

Let us first create a Spring Boot project with the help of the [Spring boot Initializr](https://start.spring.io/#!type=maven-project&language=java&platformVersion=2.4.5.RELEASE&packaging=jar&jvmVersion=11&groupId=io.pratik&artifactId=springcloudsqs&name=springcloudsqs&description=Demo%20project%20for%20Spring%20cloud%20sqs&packageName=io.pratik.springcloudsqs&dependencies=web,lombok), and then open the project in our favorite IDE. Select Maven project and Java language. Last but not least, select Spring boot version `2.4.7`. Fill in the project metadata and click generate.

For Spring Cloud, We need to configure Spring Cloud AWS BOM in our `pom.xml` file using this dependencyManagement block:

```xml
<dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>io.awspring.cloud</groupId>
 <artifactId>spring-cloud-aws-dependencies</artifactId>
 <version>2.3.1</version>
 <type>pom</type>
 <scope>import</scope>
 </dependency>
 </dependencies>
</dependencyManagement>
```

For adding the support for messaging, we need to include the module dependency for Spring Cloud AWS Messaging into our Maven configuration. We do this by adding the starter module `spring-cloud-starter-aws-messaging`:

```xml
<dependency>
 <groupId>io.awspring.cloud</groupId>
 <artifactId>spring-cloud-starter-aws-messaging</artifactId>
</dependency>
```

These are the dependencies required for Spring Cloud AWS. Next, we add some other dependencies such as Spring boot starter web and [Lombok](https://projectlombok.org/).

```xml
<dependencies>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 <version>2.4.7</version>
 </dependency>
 <dependency>
 <groupId>org.projectlombok</groupId>
 <artifactId>lombok</artifactId>
 <version>1.18.20</version>
 <scope>provided</scope>
 </dependency>
</dependencies>
```

This completes our setup process for the Spring boot project.

Let's jump into adding the SNS and SQS configs and start publishing our first message.

Amazon SNS Config:

```java
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;
import com.amazonaws.services.sns.AmazonSNS;
import com.amazonaws.services.sns.AmazonSNSClientBuilder;
import io.awspring.cloud.messaging.core.NotificationMessagingTemplate;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;

import static com.authga.springcloudaws.config.AWSConfigConstants.ACCESS_KEY;
import static com.authga.springcloudaws.config.AWSConfigConstants.SECRET_KEY;

@Configuration
public class SnsConfig {

 @Bean
 public NotificationMessagingTemplate notificationMessagingTemplate(AmazonSNS amazonSNS) {
 return new NotificationMessagingTemplate(amazonSNS);
 }

 @Bean
 @Primary
 public AmazonSNS amazonSNS(final AwsClientBuilder.EndpointConfiguration endpointConfiguration) {
 BasicAWSCredentials credentials = new BasicAWSCredentials(ACCESS_KEY, SECRET_KEY);
 return AmazonSNSClientBuilder
 .standard()
 .withEndpointConfiguration(endpointConfiguration)
 .withCredentials(new AWSStaticCredentialsProvider(credentials))
 .build();
 }
}
```

Here, we create a simple `AmazonSNSClient` with a custom endpoint and credentials. Spring has an auto-configured `AmazonSNSClient`, but that requires valid AWS credentials and actual resources. We instead want to run our service locally with AWS resources using LocalStack. More on this later. Let's finish this setup.

Amazon SQS Config:

```java
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.client.builder.AwsClientBuilder;
import com.amazonaws.services.sqs.AmazonSQSAsync;
import com.amazonaws.services.sqs.AmazonSQSAsyncClientBuilder;
import io.awspring.cloud.messaging.config.QueueMessageHandlerFactory;
import io.awspring.cloud.messaging.support.NotificationMessageArgumentResolver;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;
import org.springframework.messaging.converter.MappingJackson2MessageConverter;
import org.springframework.messaging.converter.MessageConverter;

import java.util.List;

import static com.authga.springcloudaws.config.AWSConfigConstants.*;

@Configuration
public class SqsConfig {

 @Bean
 public AwsClientBuilder.EndpointConfiguration endpointConfiguration() {
 return new AwsClientBuilder.EndpointConfiguration(ENDPOINT, EU_CENTRAL_1);
 }

 @Bean
 @Primary
 public AmazonSQSAsync amazonSQSAsync(final AwsClientBuilder.EndpointConfiguration endpointConfiguration) {
 BasicAWSCredentials credentials = new BasicAWSCredentials(ACCESS_KEY, SECRET_KEY);
 return AmazonSQSAsyncClientBuilder
 .standard()
 .withEndpointConfiguration(endpointConfiguration)
 .withCredentials(new AWSStaticCredentialsProvider(credentials))
 .build();
 }

 @Bean
 public QueueMessageHandlerFactory queueMessageHandlerFactory(MessageConverter messageConverter) {
 var factory = new QueueMessageHandlerFactory();
 factory.setArgumentResolvers(List.of(new NotificationMessageArgumentResolver(messageConverter)));
 return factory;
 }

 @Bean
 protected MessageConverter messageConverter() {
 var converter = new MappingJackson2MessageConverter();
 converter.setSerializedPayloadClass(String.class);
 converter.setStrictContentTypeMatch(false);
 return converter;
 }
}
```

In the code above, we did the following:

- Similar to the `AmazonSNSClient`, we create the `AmazonSQSClient` with a custom endpoint and credentials.
- Setup `QueueMessageHandlerFactory` so it can convert incoming messages from SQS as String to the actual object we want, in this case, `Event`, using a `MessageConverter`.
- The converter will take care of converting the `String` message to the actual `Event` object.

The `Event` model is described below. I am using [Lombok](https://projectlombok.org/) to reduce the boilerplate code.

`Event.java`

```java
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class Event implements Comparable<Event> {
 private String eventId;
 private String version;
 private String occurredAt;
 private EventData data;

 @Override
 public int compareTo(Event o) {
 int otherVersion = Integer.parseInt(o.getVersion());
 int thisVersion = Integer.parseInt(this.getVersion());
 return Integer.compare(thisVersion, otherVersion);
 }
}
```

`EventData.java`

```java
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class EventData {
 private String orderId;
 private String owner;
 private EventType eventType;
}
```

`EventType.java`

```java
import java.io.Serializable;

public enum EventType implements Serializable {
 ORDER_CREATED, ORDER_CANCELLED
}
```

Producer code:

```java
import com.authga.springcloudaws.model.Event;
import io.awspring.cloud.messaging.core.NotificationMessagingTemplate;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import static com.authga.springcloudaws.config.AWSConfigConstants.ORDER_CREATED_TOPIC;

@Slf4j
@Service
public class SimpleMessageProducer {

 @Autowired
 private NotificationMessagingTemplate notificationMessagingTemplate;

 public void publish(Event event) {
 notificationMessagingTemplate.convertAndSend(ORDER_CREATED_TOPIC, event);
 }
}
```

- We use the `NotificationMessagingTemplate` created in the config above. It gives us several methods to send messages on an SNS topic. We will use the default `convertAndSend()` method that takes care of converting our object to a Message using the `MessageConverter` that we provide in the `SqsConfig` class.

Consumer code:

```java
import com.authga.springcloudaws.model.Event;
import io.awspring.cloud.messaging.config.annotation.NotificationMessage;
import io.awspring.cloud.messaging.listener.SqsMessageDeletionPolicy;
import io.awspring.cloud.messaging.listener.annotation.SqsListener;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Controller;

import static com.authga.springcloudaws.config.AWSConfigConstants.ORDER_QUEUE;

@Slf4j
@Controller
public class SimpleMessageConsumer implements MessageConsumer {

 @Override
 @SqsListener(value = ORDER_QUEUE, deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
 public void consume(@NotificationMessage Event event) {
 if (event != null) {
 log.info("Received order event for consumer 1: " + event);
 }
 }
}
```

- We only need `@SqsListener` annotation that automatically makes our consume method get the messages from the queue.
- We also add `@NotificationMessage` annotation to have the correct deserialization and extract our Event from the SNS message because the SNS message is wrapped inside a `Message` object.

### Setup LocalStack and create resources

Setting up LocalStack is dead simple; you just need to use the docker-compose file below, and it will start SNS and SQS services locally. Add the `docker compose.yml` to the repository's root directory. Start the LocalStack using: `docker-compose up`.

```yaml
version: '3.0'

services:

 localstack:
 image: localstack/localstack:latest
 environment:
 - AWS_DEFAULT_REGION=eu-central-1
 - EDGE_PORT=4566
 - SERVICES=sqs,sns
 ports:
 - '4566:4566'
```

Once it is up and running, we can create the required AWS resources. We will create one SNS topic to which two SQS queues will be listening. The code to or publishing and listening is simple. Go to your command line, e.g., terminal, and execute the following commands.

To create the topic:

```shell
aws --endpoint-url=http://localhost:4566 sns create-topic --name order-created-topic
```

To create the queues:

```shell
aws --endpoint-url=http://localhost:4566 sqs create-queue --queue-name order-queue
aws --endpoint-url=http://localhost:4566 sqs create-queue --queue-name order-queue-2
```

To subscribe the queues to the topic:

```shell
aws --endpoint-url=http://localhost:4566 sns subscribe
--topic-arn arn:aws:sns:eu-central-1:000000000000:order-created-topic
--protocol sqs
--notification-endpoint arn:aws:sqs:eu-central-1:000000000000:order-queue

aws --endpoint-url=http://localhost:4566 sns subscribe
--topic-arn arn:aws:sns:eu-central-1:000000000000:order-created-topic
--protocol sqs
--notification-endpoint arn:aws:sqs:eu-central-1:000000000000:order-queue-2
```

To verify you can list queues and subscriptions:

```shell
aws --endpoint-url=http://localhost:4566 sqs list-queues
aws --endpoint-url=http://localhost:4566 sns list-subscriptions
```
That's it!

### Verify sending and receiving of events

Run the Spring Boot app:

1. Clone the sample code from the repo. Go to the root directory.
2. Use Maven plugin to run your Spring Boot app using the command in the project directory.

```shell 
mvn spring-boot:run
```

The groundwork is complete now. With the app running, we can send messages to the Amazon SNS Topic and read those messages from the queues. In the repo, I have created a controller to trigger the publishing of events. If you download the sample app, you should be able to run it, and going to [http://localhost:8080/create-order](http://localhost:8080/create-order) will trigger the publisher, which in turn will trigger the consumers. In the application logs, you should be able to see. This means that our producer code publishes the code to the SNS topic. The two queues that are subscribed to the topic receive those messages, and finally, the consumer receives those messages and prints the event.

```
Received order event for consumer 1:
Event{eventId='386cca76-3669-4d36-b2db-01f388bbce5f', version='0',
occurredAt='2021-06-19T13:42:32.946781Z', data=EventData(orderId=9a002b95-f10b-428e-8d39-cae90d1e631d,
owner=SampleProducer, eventType=ORDER_CREATED)}

Received order event for consumer 2:
Event{eventId='386cca76-3669-4d36-b2db-01f388bbce5f', version='0', occurredAt='2021-06-19T13:42:32.946781Z',
data=EventData(orderId=9a002b95-f10b-428e-8d39-cae90d1e631d, owner=SampleProducer, eventType=ORDER_CREATED)}
```

## Conclusion

LocalStack provides a simple and convenient way to simulate AWS services without having an actual AWS account. You can build applications using various AWS services like Amazon SNS, SQS, S3 DynamoDB, and many more.

In this article, we have learned how to build a Spring Cloud Messaging app that utilizes LocalStack. We saw how Spring Cloud Messaging provides a layer of abstraction to create an Amazon SQS listener and SNS publisher with just a few lines of code. Furthermore, we saw how to use Amazon SNS and SQS to create an event-driven application.

You can refer to the repository used in the article on [Github](https://github.com/maniish-jaiin/spring-cloud-messaging-sample).

Spring Cloud Messaging With AWS and LocalStack

auziros:jeana-tahnk

Jeana has been in the tech industry for 15+ years, both as a communications professional and writer. As Director of Global Communications at Auth0, she works with her internal team and external agencies to amplify the company's visibility worldwide and establish its leadership in the identity industry. When she is not working, she can most likely be found on a field watching one of her three kids playing sports, or cleaning up after her one-year-old retriever who chews everything.

Senior Director, Global Communications

Jeana Tahnk

Global identity management provider one of the first AWS Partners to give AWS customers seamless access to professional services in AWS Marketplace

**BELLEVUE, Wash. – December 3, 2020** – The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced that it is participating in the launch of Professional Services in AWS Marketplace. Amazon Web Services (AWS) customers can now find and purchase professional services from Auth0 in AWS Marketplace, a curated digital catalog of software, data, and services that makes it easy to find, test, buy, and deploy software and data products that run on AWS. As a participant in the launch, Auth0 is one of the first independent software vendors to quote and contract services in AWS Marketplace to help customers implement, support, and manage their software on AWS. [Click here](https://aws.amazon.com/marketplace/seller-profile?id=0079abaf-bc2f-481c-9543-d2bfedb81003) for more information. 

As organizations migrate to the cloud, they want to use their preferred software solutions on AWS. AWS customers often utilize professional services from Auth0 to help implement the Auth0 platform and enable interoperability with their applications. Until now, AWS customers had to find and contract professional services outside of AWS Marketplace and could not acquire an identity platform solution and associated professional services in a single procurement experience. With professional services from Auth0 available in AWS Marketplace, customers have a simplified way to purchase and pay for both their subscription to the Auth0 platform and related professional services in a centralized place. 

“Auth0 is proud to offer professional services in AWS Marketplace and provide AWS customers with additional support they may need for any identity implementation,” said Bill Lapcevic, VP of Business Development at Auth0. “We are excited to be one of the first independent software vendors to offer professional services as part of this launch and look forward to providing an even more comprehensive identity offering for AWS customers.”

Auth0 is an AWS Advanced Technology Partner that is participating in AWS re:Invent 2020, taking place November 30 - December 18, 2020. To learn more, visit: [https://info.auth0.com/auth0-at-aws.html](https://info.auth0.com/auth0-at-aws.html). 

<include src="asides/AboutAuth0" />

### Media Contacts
Global Communications 
Auth0 
[press@auth0.com](mailto:press@auth0.com) 

Matter for Auth0 
[auth0@matternow.com](mailto:auth0@matternow.com)

Auth0 Supports the Launch of Professional Services in AWS Marketplace

andrew-akers

I'm a product marketing manager who loves learning about technology, information security, and identity. My goal is to turn that knowledge into positive outcomes for our customers. Before Auth0, I was a product marketing manager at Cisco in the network security division. In my spare time, you can find me spending time with my family, reading, writing, and working on endless home improvement projects.

Product Marketing Manager

Andrew Akers

cami-cano

I am a product manager, and I am passionate about building great tools for software engineers. I am always looking to learn more about my customers in order to develop sustainable solutions for them. This approach to product management is always pushing me to collaborate with people across the entire company, which is my favorite part of the job. Before joining Auth0, I worked at GitHub, where I was a product manager on GitHub Enterprise. In my spare time, I enjoy spending time with my family, running, and reading non-fiction.

Product Manager

Cami Cano

This new integration connects Auth0 event logs to a variety of AWS services in near real time

At _AWS re:Invent 2019_, Auth0's integration with [Amazon EventBridge](https://aws.amazon.com/eventbridge/) was announced. This new integration connects Auth0 event logs to a variety of AWS services in near real time, unlocking a variety of new use cases that support [event-driven](https://aws.amazon.com/event-driven-architecture/) and [microservices](https://aws.amazon.com/microservices/) application architectures.

## What is Amazon EventBridge?

Amazon EventBridge is a serverless event bus that makes it easy to connect real-time data from your applications, SaaS applications, and AWS Services. It delivers a stream of data from event sources like Auth0 to targets such as AWS Lambda. You can set up routing rules to determine where to send your data to build application architectures that react in real time to all of your data sources. 
With EventBridge, you can use data from SaaS apps like Auth0 to trigger workflows for customer support, business operations and more. It simplifies the process of building [event-driven architectures](https://aws.amazon.com/event-driven-architecture/) that are loosely coupled and distributed, improving developer agility and application resiliency.

## Auth0 and EventBridge

The integration with EventBridge is Auth0’s first release of our log streaming capabilities. Auth0 log events are pushed automatically and continuously to EventBridge, which can then be connected to various AWS services.
Here is a quick overview of some of the use cases this integration unlocks:

![Auth0 Amazon EventBridge use cases](https://images.ctfassets.net/23aumh6u8s0i/3vNAjtRGyWWYNajUgZrE8g/57e662e6f3630cd4bf4b19fa16415597/auth0-eventbridge)

## Engage with Your Users

Delivering a strong user experience is critical to reducing churn and retaining users. Using Auth0 events and services like AWS Lambda, you can deliver more customized application experiences. For example, use this integration to create a product onboarding flow for first-time logins. Or increase user engagement by highlighting product areas that would be of interest to them based on their login behavior.

## Understand User Behavior

Understanding when users access your product, where they are signed in from, and what devices they use are important pieces of information that can drive your product development. By keeping track of these signals, via the events emitted by Auth0, you can develop an understanding of the product areas that you should be paying attention to. These signals can help you determine what browsers and devices to support, what languages to consider localizing your app in, and when your peak application traffic times are.
Use services like AWS QuickSight to uncover business intelligence, create dashboards, and utilize ML Insights.

## Manage User Data

Retaining and auditing user actions is crucial for maintaining security and complying with industry regulations. Besides, the ability to edit, remove, or export user data upon request is becoming increasingly important to comply with various data privacy laws, such as the European Union’s General Data Protection Regulation (GDPR).
By sending Auth0 logs to EventBridge, it is easy to develop the appropriate workflows and automation to retain audit trails and remain compliant. For example, you can store your audit trail in S3 buckets and interact or investigate it using AWS Athena.

## Learn More
Using Amazon EventBridge with Auth0 unlocks a variety of use cases. Learn how to set up the integration [here](https://auth0.com/docs/integrations/aws-eventbridge), or [sign up for a free Auth0 trial](https://auth0.com/signup).

<include src="asides/AboutAuth0" />

Get More Out of Your Auth0 Logs with Amazon EventBridge

99c4080f412ccf46b9b564db7f482907?s=200 avatar

99c4080f412ccf46b9b564db7f482907?s=200

I'm currently a Senior Developer Advocate at MongoDB. I'm also a Google Developer Expert for Web Technologies and spend most my time giving talks at conferences and meetups, mentoring developers and running workshops, and creating online content to help technology professionals.

Former Auth0 Employee

Ado Kukic

The annual Amazon Web Services (AWS) re:Invent conference kicks off this week. Here's a TL;DR of all the big announcements as well as our observations and things we learned.

The AWS re:Invent conference is back in Las Vegas this week and with it comes **five** days of awesome talks, deep-dives, and of course, huge announcements that promise to boost developer productivity, make DevOps simpler, and help companies grow and scale. This year the conference is spread across five hotels on the Las Vegas Strip and features over 1,500 different talks. I would love to be able to attend each one, but since I can't be in 100 places at once, I will share what I learned at the talks I could attend as well as the general announcements that Amazon will have when they host their keynotes on Wednesday and Thursday this week.

![AWS Registration](https://images.ctfassets.net/23aumh6u8s0i/5NswEp40XSF5NMaDbrEIna/c7bf213ba0f229c022ccf629149dd3dc/registration)

At Auth0, we deeply care about **security, compliance, and identity**, and as luck would have it, re:Invent features 117 sessions on just that. The other topic that I focused on today was **serverless** computing and I learned a ton. Since there was no keynote today, below are things I learned at the breakout sessions.

## Session: IAM for Enterprises: How Vanguard Strikes the Balance Between Agility, Governance, and Security

This session was hosted by AWS Security Consultant Reef Dsouza and Senior Security Architect for [Vanguard](https://investor.vanguard.com/corporate-portal/), Rajeev Sharma. Reef set the stage by sharing some best practices when it comes to Identity and Access Management (IAM) and how AWS can help. Some general tips shared include:

* **Defense in Depth** - multiple layers of security.
* **Separation of Duties** - well-defined roles and permissions.
* **Principle of Least Privilege** - users should only have access to what they absolutely need.

Rajeev went on to explain how Vanguard, one of the largest investment companies in the world, applied these guidelines when moving their architecture to the AWS cloud and the numerous benefits that it brought them. 

Many of the best practices that Reef shared, we at [Auth0](https://auth0.com) have been very vocal about as well. [Read our five tips on how you can make your app more secure in less than 20 minutes](https://auth0.com/blog/5-ways-to-make-your-app-more-secure-in-less-than-20-minutes/). 

## Session: Serverless for Security Officers: Paradigm Walkthrough and Comprehensive Security Best Practices

This session, hosted by Jonathan Desrocher, Eugene Yu, and Henrik Johansson, focused on best security practices as they pertain to serverless applications. Serverless applications are gaining more and more momentum, and whether you go with [AWS Lambda](https://aws.amazon.com/lambda/), [Auth0 Webtask](https://webtask.io), or another serverless platform, you are sure to have questions on the various security considerations that arise when using these platforms.

![Serverless Security Paradigm](https://images.ctfassets.net/23aumh6u8s0i/27UjOgJJ8Gih7xp17BIOfq/559e2161bf0b8c9dae07d92e3a127477/security)

The good news is that essentially all the best security practices that pertain to traditional applications also apply to serverless applications as well. The bad news is that each function is a potential attack vector, so they require a bit more effort and attention to properly secure. Additionally, with serverless, the platform provider takes on a much larger role when it comes to securing the application, but at the end of the day, security is everyone's responsibility.

## Session: Credentials, Credentials, Credentials, Oh My!

Quint Van Deman of AWS hosted this **chalk talk**, which consisted of a 10-15 minute presentation on best practices when it comes to managing the various credentials in the AWS ecosystem, and then a 45 minute Q&A session where he asked the audience for use cases and worked out best practices for those use cases. We covered many complex use cases involving the various AWS credential services including Cognito, Secure Token Service (STS), and various forms of credential exchanges whether internal at AWS or exchanging credentials from a third party service like Auth0.

![AWS Credentials](https://images.ctfassets.net/23aumh6u8s0i/CAUKsPAy7O2OV0cO9Jfe3/2203138d67defc488c9607cacbc09869/credentials)

One of the key takeaways from this session was that having a centralized source of truth and federating that identity throughout your infrastructure was superior to having multiple identity stores for the different applications in your infrastructure. [Learn more about Single Sign On](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/) and [how you can call AWS APIs with Auth0 tokens](https://auth0.com/docs/integrations/aws).

## Session: Evolution of Serverless Architectures Through the Lens of Community

Serverless is taking the development world by storm. This was a very enlightening talk by Peter Sbarski and Sam Kroonenburg of [A Cloud Guru](https://acloud.guru/), one of the early adopters of serverless technology. Sam, the founder of A Cloud Guru, even showed that their production account had no active Amazon EC2 instances. This session focused on the growth of serverless architectures over the last three years and highlighted some of the providers as well as consumers of serverless technologies. Sam also covered the growing community around serverless which included quotes from many prominent members of the community, serverless meetups around the world, and even a conference!

![Auth0 at AWS](https://images.ctfassets.net/23aumh6u8s0i/4qb5L0Fhet60RmV251mY6q/5faffafb398bea2c0e0208a102f311e4/auth0)

Auth0's [Webtask](https://webtask.io) also got a shout-out, as did [Auth0's identity solution](https://auth0.com). Sam closed out his talk by sharing some emerging patterns in the serverless community, especially [application modernization and microservices, which you can learn much more about here](https://auth0.com/blog/getting-a-competitive-edge-with-a-microservices-based-architecture/).

Finally, Hernan Garcia of [CityWallet](https://www.citywallet.net/) gave a real-world example of how he and his team achieved success with a serverless architecture when their more traditional methods failed and put their startup at risk.

## Session: Compliance and Top Security Threats in the Cloud—Are You Protected?

We closed out the day with a very informational session on top security threats that organizations face by Teri Radichel of [WatchGuard Technologies](https://www.watchguard.com/) and Boyan Dimitrov of [Sixt](https://www.sixt.com/). The top threats included were:

* **Unprotected keys and credentials.**
* **Broad permissions for engineers.**
* **Unpatched software.**
* **Malicious software updates.**
* **Open network ports.**
* **Flat network design.**
* **Broad permissions for applications.**
* **Bad configuration management.**
* and **Data Exfiltration.**

Teri discussed how these threats led to large data breaches such as the [Equifax Data Breach](https://auth0.com/blog/equifax-data-breach/) that leaked the Social Security Numbers of almost all Americans and the [WannaCry Ransomware](https://auth0.com/blog/a-massive-ransomware-attack-targets-organizations-around-the-globe/) which locked out banks, airlines, and even hospitals. 

Boyan discussed strategies on how to mitigate risk and the key takeaway was that compliance does not equal security. Many of the companies that experienced data breaches were compliant with many standards and organizations but were still breached. Security is something that must be constantly monitored to be effective.

## Aside: Auth0 and AWS

If you are using AWS to manage your infrastructure, whether it be traditional, serverless, or a mix, and are looking to better manage identity in your applications, Auth0 can help you to:

* Add authentication through traditional username/password databases.
* Add support for linking different user accounts with the same user.
* Support for generating signed JSON Web Tokens to call your APIs and flow the user identity securely.
* Analytics of how, when, and where users are logging in.
* Pull data from other sources and add it to the user profile, through [JavaScript rules](https://docs.auth0.com/rules).
* Achieve [SSO (Single Sign-On)](https://auth0.com/docs/sso) seamlessly.

<a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up</a> for a free account today and enjoy fast, seamless, and hassle-free authentication in your apps.

## Summary

Day 1 of the re:Invent was very eventful. I wish I could have attended more talks, but the talks I could make it to were very insightful and left me wanting more. Tune in the rest of the week as I cover more in-depth sessions as well as the keynotes. I hope you find this TL;DR useful.

"AWS services"