Home
Softono
a

awsfundamentals-hq

Professional software vendor delivering innovative solutions on the Softono platform. Specialized in both open-source and proprietary software development.

Total Products
6

Software by awsfundamentals-hq

cloudwatch-observability-access-manager
Open Source

cloudwatch-observability-access-manager

# How to configure CloudWatch Observability Access Manager (OAM) CloudWatch OAM empowers you to centralize and connect a region in multiple accounts (named Source accounts) into the same region in a destination account (named Monitoring account). For example: - Source account A us-east-1 => Monitoring account us-east-1 - Source account B us-east-1 => Monitoring account us-east-1 Using the CloudWatch dashboard in Monitoring account us-east-1, you can see logs, metrics, trances and insights from Source accounts A and B. - Source account A ap-southeast-2 => Monitoring account ap-southeast-2 - Source account B ap-southeast-2 => Monitoring account ap-southeast-2 Using the CloudWatch dashboard in Monitoring account ap-southeast-2, you can see logs, metrics, trances and insights from Source accounts A and B. ## CloudWatch OAM Constructs You work with 3 (three) components when configuring CloudWatch OAM: - **Sink**: A Sink represents a destination point where AWS accounts running workloads (named Source accounts) will send their logs, metrics, trace and insights to. You create Sinks in the Monitoring account. You can create a single Sink per region in the Monitoring account. A Monitoring account can be connected to as many as 100,000 Source accounts. - **Link**: A Link represents the connection between the Source account (AWS accounts running workloads) and the Monitoring account (the destination point). You create a Link in the AWS accounts running workloads where logs, metrics trace and insights are created. You can create multiple Links per region in the Source account, they must point and connect to a different Sink ARN. A Source account can be paired with up to 5 (five) monitoring accounts concurrently. - **Sink Policy**: A Sink Policy is similar to [Resource-based Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html). A Sink Policy grants permissions to Source accounts to connect their Links to the Monitoring account Sink. When you create a Sink Policy, you can grant permissions to all accounts in an AWS Organizations or to individual accounts via AWS Account Id. You can also use the Sink Policy to limit the types of data that is shared. The 4 (four) types that you can allow or deny are: - **Metrics**: Links in Source accounts can send [CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) to the Sink in the Monitoring account, enable it by adding the **AWS::CloudWatch::Metric** type to your Sink Policy. - **Log Groups**: Links in Source accounts can send [CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) to the Sink in the Monitoring account, enable it by adding the **AWS::Logs::LogGroup** type to your Sink Policy. - **Traces**: Links in Source accounts can send [AWS X-Ray Traces](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) to the Sink in the Monitoring account, enable it by adding the **AWS::XRay::Trace** type to your Sink Policy. - **Application Insights - Applications**: - Links in Source accounts can send [CloudWatch Application Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html) to the Sink in the Monitoring account, enable it by adding the **AWS::ApplicationInsights::Application** type to your Sink Policy. ## The example in this repository This repository shows how to configure [CloudWatch Observability Access Manager (OAM)](https://docs.aws.amazon.com/OAM/latest/APIReference/Welcome.html) for multi-account logs, metrics, traces and insights. We'll use the example described in the introduction above for our technical implementation. We are going to connect two regions from two Source accounts into the Monitoring account. ![Diagram showing CloudWatch OAM constructs, Sinks and Links, distributed between two Source accounts and the Monitoring account.](.docs/oam.png) ## Final results After deploying this example, you can generate logs, metrics, traces and insights in the Source accounts and they will be available for analysis and visualization in the Monitoring account. In the Monitoring account CloudWatch Logs dashboard in us-east-1, I can see logs from both Source accounts: ![Screenshot of CloudWatch Logs dashboard in us-east-1 in Monitoring account.](.docs/monitoring-us-east-1.png) In the Monitoring account CloudWatch Logs dashboard in ap-southeast-2, I can see logs from both Source accounts: ![Screenshot of CloudWatch Logs dashboard in ap-southeast-2 in Monitoring account.](.docs/monitoring-ap-southeast-2.png) In the Monitoring account CloudWatch Logs dashboard in us-east-1, I can use Log Insights to query log groups from both Source accounts and inspect my log events: ![Screenshot of CloudWatch Logs dashboard in us-east-1 in Monitoring account using Log Insights to query log groups from both Source accounts](.docs/monitoring-log-insights.png) ## How to find OAM Sink and Link in CloudWatch dashboard? You can find OAM Sink and Link configuration by clicking on "Settings" in the sidebar on the CloudWatch regional dashboard: - Link to us-east-1 regional dashboard: https://console.aws.amazon.com/cloudwatch/home?region=us-east-1 - Link to ap-southeast-2 regional dashboard: https://console.aws.amazon.com/cloudwatch/home?region=us-east-1 In the Monitoring account, you will see the "Monitoring account enabled" enable status and buttons to inspect the configuration of the Sink, connected Links and manual steps to connect Links (which we didn't used! We are using Terraform for the configuration). ![Screenshot showing CloudWatch regional dashboard for ap-southeast-2 in the Monitoring account](.docs/cloudwatch-dashboard-monitoring-account.png) ![Screenshot showing CloudWatch regional dashboard for ap-southeast-2 in the Monitoring account in the manage OAM Sink tab](.docs/cloudwatch-dashboard-monitoring-account-manage.png) However, in the Source account, you will see the "Linked" enable status and buttons to view the linked monitoring accounts and to connect manually to one (which we didn't used! We are using Terraform for the configuration). ![Screenshot showing CloudWatch regional dashboard for ap-southeast-2 in the Source account](.docs/cloudwatch-dashboard-source-account.png) ![Screenshot showing CloudWatch regional dashboard for ap-southeast-2 in the Source account in the manage OAM Link tab](.docs/cloudwatch-dashboard-source-account-manage.png)

Web Analytics Hosting Panels
24 Github Stars
bedrock-openai-experiments-chat
Open Source

bedrock-openai-experiments-chat

# Serverless Chat Application with Amazon Bedrock and OpenAI Repository for the accompanying [blog post]([url](https://blog.awsfundamentals.com/amazon-bedrock-the-openai-api-and-sst)) and [newsletter](https://newsletter.awsfundamentals.com). ![image](https://github.com/awsfundamentals-hq/bedrock-openai-experiments-chat/assets/19362086/6d73a989-93e0-486b-8366-ea1aae0cc552) This project is a serverless chat application that leverages Amazon Bedrock and the OpenAI API to enhance chat functionalities with advanced AI-driven contextual understanding. Built using Serverless Stack (SST), NextJS, AWS Lambda, and DynamoDB, it offers a robust platform for real-time messaging enriched with AI capabilities. ## Architecture Below is the architecture diagram of the application, illustrating how different components interact within the AWS environment: ![Architecture Diagram](docs/architecture.png) ## Features - Real-time chat messaging. - Contextual note integration for smarter responses. - Use of Amazon Bedrock and OpenAI for natural language understanding. - Fully serverless backend with AWS Lambda and DynamoDB. ## Prerequisites - AWS CLI installed and configured with AWS account credentials. - Access to Amazon Bedrock and OpenAI APIs. - Node.js and NPM installed. ## Providing your OpenAI API key to SST To provide your OpenAI API key to SST, use the following command: ```bash npx sst secrets set OPENAI_API_KEY sk-Yj...BcZ ``` ## Deploying with SST To deploy the application, ensure you are in the project's root directory and then use the SST commands: ```bash npx sst deploy ``` ## Running Locally To run the application locally, use the following command: ```bash npx sst dev ``` Start the frontend by navigating to the `packages/app` directory and running: ```bash npm run dev ```

LLM Tools & Chat UIs Backend as a Service
24 Github Stars
cloudwatch-application-signals-otel
Open Source

cloudwatch-application-signals-otel

# CloudWatch Application Signals via OpenTelemetry on Fargate and Lambda This project demonstrates how to run two simple Node.js apps using [Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html) via ECS and [AWS Lambda](https://docs.aws.amazon.com/lambda/) with [SST](https://sst.dev) v3 to showcase [CloudWatch's Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html). ## Getting Started To run this application, follow these steps: 1. Ensure you have Node.js installed on your system. 2. Clone this repository to your local machine. 3. Install the dependencies by running `pnpm i` in the project root directory. 4. Provision the infrastructure via `pnpm run sst:deploy:dev`. 5. Invoke either ECS or Lambda via the provided NX commands, e.g. `INVOKE_PATH=/lambda pnpm run invoke:ecs:dev` 6. Open the CloudWatch console to explore your Application Map! ## Important: Cost Considerations ⚠️ **Warning:** This project spins up Fargate tasks that remain running and will incur ongoing costs (approximately $7-$10 per month, not including CloudWatch charges). To avoid unexpected charges, remove all resources when done by running: ```bash pnpm run sst:remove:dev ``` ## Learn More For more AWS fundamentals content and resources: - Visit our blog at [awsfundamentals.com/blog](https://awsfundamentals.com/blog) - Check out our other projects on GitHub at [awsfundamentals-hq](https://github.com/awsfundamentals-hq)

Monitoring & Observability
21 Github Stars
sfn-wait-for-callback
Open Source

sfn-wait-for-callback

# sfn-wait-for-callback Welcome to the `sfn-wait-for-callback` repository! This project complements our [blog post](https://blog.awsfundamentals.com/building-a-real-world-use-case-with-step-functions-and-the-callback-pattern), demonstrating a real-world application of AWS Step Functions using the callback pattern. We implement a basic UI that starts a Step Function, let's it wait for a specific input (title forbidden), and continues it only on user input. ![Step Function Workflow](https://github.com/awsfundamentals-hq/sfn-wait-for-callback/assets/19362086/08606338-9b90-4b63-99b9-7955c8601067) ## Deploy You can use any package manager, we've used pnpm. Follow these commands to deploy the project to your AWS default profile: ``` pnpm install pnpm run deploy:prod ``` ## Running Locally To run the project on your local machine: 1. Install dependencies: ``` pnpm install ``` 2. Start the development server: ``` pnpm run dev ``` 3. For the frontend, navigate to the `packages/frontend` directory and start its development server: ``` cd packages/frontend pnpm run dev ``` ## Components ### Frontend **Technology**: Next.js **Submit Articles**: We've implemented a mock form that submits new articles. We only send new article titles. If you send the title `forbidden` a step Function will halt. ![Content Moderation System UI](https://github.com/awsfundamentals-hq/sfn-wait-for-callback/assets/19362086/4033ce8e-a4fb-41fc-a506-01cdb0f60648) **Admin Page**: In `/admin` we've built an admin page that shows you all waiting step functions. On `approve` or `reject` you will continue the Step Function with the respective decision. ![image](https://github.com/awsfundamentals-hq/sfn-wait-for-callback/assets/19362086/3d3b3a20-a982-42ff-a55f-077d087e580e) More details are available in our [blog post](https://blog.awsfundamentals.com/building-a-real-world-use-case-with-step-functions-and-the-callback-pattern). ### Backend Resources - **Step Function**: Built using AWS CDK, employing the chain syntax for state management. ![Step Function](https://github.com/awsfundamentals-hq/sfn-wait-for-callback/assets/19362086/7e72e40e-586a-4508-a925-eebea9368316) - **Lambda Functions**: - REST API: Starts Step Functions and retrieves items from DynamoDB. - Approval Receiver: Handles decision and task token reception. - Manual Approval Request: Records Step Functions awaiting approval in DynamoDB. - **DynamoDB**: Stores active Step Functions and related metadata. ## Costs This project is serverless, meaning it is 100% usage-based. Testing should be free under the AWS Free Tier. For larger-scale operations, be mindful of DynamoDB scan costs and Step Function state changes. ## Contributions Interested in contributing? Great! 🚀 Simply create an issue or a pull request, and we'll take a look.

Cron & Job Scheduling FaaS & Serverless
18 Github Stars
aurora-dsql
Open Source

aurora-dsql

# Amazon Aurora DSQL Demo This project demonstrates how to easily bootstrap & use a Amazon Aurora DSQL database using SST (Serverless Stack) v3. ## Getting Started To run this application, follow these steps: 1. Ensure you have Node.js installed on your system. 2. Clone this repository to your local machine. 3. Install the dependencies by running `pnpm i` in the project root directory. 4. Run `pnpm run db:bootstrap` to set up our database. 5. Run `pnpm run db:schema:migrate` to create the migration. 6. Run `pnpm run db:schema:push` to push your migration to the database. 7. Run `pnpm run db:schema:studio` run the Drizzle studio to view the database in your browser. 8. Start the development server by running: ``` npx sst dev ``` This command will deploy the application to your AWS account and start the local development environment. ## About the Project This application is built using SST v3, which provides a powerful framework for building serverless applications. It showcases a simple notes app that uses Amazon Aurora DSQL as the database. The app allows you to create, read, update, and delete notes. ## Project Structure - `sst.config.ts`: SST configuration file - `app/page.tsx`: Main Next.js page for the frontend - `lambda/api.ts`: Function that handles the API requests - `lambda/db/schema.ts`: Database schema with [Drizzle](https://github.com/drizzle-team/drizzle-orm) - `bootstrap-db.sh`: Script to bootstrap the database (there's no IaC support yet) - `drizzle-wrapper.sh`: Script to get the database host and token before running Drizzle ## Learn More To learn more about SST and how to use it for serverless development, check out the [SST documentation](https://docs.sst.dev/).

Backend as a Service Relational Databases
17 Github Stars
cognito-federated-auth
Open Source

cognito-federated-auth

# Amazon Cognito Federated Authentication Demo This project demonstrates how to implement federated authentication with Amazon Cognito and Google OAuth using Next.js and SST (Serverless Stack) v3. ## Getting Started To run this application, follow these steps: 1. Ensure you have Node.js installed on your system. 2. Clone this repository to your local machine. 3. Install the dependencies by running `pnpm i` in the project root directory. 4. Create a `.env` file in the root directory with the following variables: ``` COGNITO_USER_POOL_DOMAIN=your-domain-prefix GOOGLE_OAUTH_CLIENT_ID=your-google-client-id GOOGLE_OAUTH_CLIENT_SECRET=your-google-client-secret ``` 5. Start the development server by running: ``` npx sst dev ``` This command will deploy the application to your AWS account and start the local development environment. ## About the Project This application is built using SST v3, which provides a powerful framework for building serverless applications on AWS. It showcases a simple authentication flow that uses Amazon Cognito as the identity provider with Google OAuth integration. The app allows users to: - Sign in with their Google account - View their authentication details - Sign out ## Project Structure - `sst.config.ts`: SST configuration file - `infra/index.ts`: Infrastructure setup with AWS Cognito resources - `app/page.tsx`: Main Next.js page for the frontend - `app/auth/page.tsx`: Authentication callback page - `app/components/GoogleSignInButton.tsx`: Component for Google sign-in functionality - `app/components/AuthProviderWrapper.tsx`: OIDC authentication provider wrapper - `app/lib/types.ts`: TypeScript type definitions - `app/lib/utils.ts`: Utility functions ## AWS Resources This project sets up the following AWS resources: - Amazon Cognito User Pool: Manages user authentication and identity - Cognito User Pool Domain: Provides a hosted UI for authentication - Cognito Identity Provider: Configures Google as a federated identity provider - Cognito User Pool Client: Configures the application client for authentication ## Learn More To learn more about the technologies used in this project: - [SST documentation](https://docs.sst.dev/) - [Amazon Cognito documentation](https://docs.aws.amazon.com/cognito/) - [Next.js documentation](https://nextjs.org/docs) - [React OIDC Context](https://github.com/authts/react-oidc-context)

Code Editors & IDEs SSO & Authentication
11 Github Stars