<div style="text-align: justify"> # AWS Lambda best practices Best practice rules for AWS Lambda https://www.trendmicro.com/cloudoneconformity/knowledge-base/aws/Lambda/ also best practices, has some advices https://aws.plainenglish.io/aws-lambda-best-practices-7454da49314d --> Since serverless computing has its own set of disadvantages, it may not be appropriate for everyone or every use case. When it comes to developing Lambda code, knowing how a lambda function works may help us identify some of the best practices to follow when utilizing lambda functions, as well as the value of each best practice. Function code and dependencies, function configuration, logging and monitoring are among the key practices described below. ### 1. The lambda handler should be separated from service logic It is recommended that the business logic be written in a separate service layer rather than in the handler function itself. It's because it makes it much simpler to write more readable and intelligible code, as well as unit-testable code for the business logic. For example, the handler function will be an entry point for a lambda function and let's say that multiple variables are passed into the mentioned handler function. It may get problematic if each lambda triggers an event with the first parameter containing all information about the triggering event. ### 2. The execution environment should be reused Lambda workers will be utilized as long as they are up and operating, even if they terminate after a certain length of time. As a result, ensuring that the most of this reusability is taken may result in significantly reduced execution times. It is crucial not to save any sensitive data in the execution environment when reusing it. If these settings or environments are reused, there is a risk of data leakage, which can cause plenty of issues. ### 3. Environment variables should be used to manage operational parameters Other operational parameters can be managed using variables whose values are set outside of the program. A name for an S3 bucket, for example, may be an environment variable rather than a hard-coded value. Lambda functions may be deployed into diverse environments without modifying the code by using env variables. *SSM Parameter Store* is an AWS service that saves variables and makes managing parameters for various environments or serverless architectures easier. ### 4. Common code should be deployed to a lambda layer A Lambda layer represents an archive that contains any additional code, such as libraries, dependencies, or custom runtimes. [reference](https://aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/) Lambda will extract archive's data in the layer to the execution environment's `/opt` directory when setting up the exec. environment. Code and dependencies may be readily shared across numerous functions using lambda layers. The lambda function package size may also be lowered by adding heavy dependencies like AWS SDK, which will likely be reused in multiple lambda functions, resulting in faster deployments. ### 5. Pay attention to the package size The size of lambda packages is expected to rise in conjunction with the expansion of the company, applications, and their logic. As package size rises, it has an impact on deployment time and, more critically, it can significantly increase the lambda function's cold start time. The cold start refers to the time it takes to set up the execution environment (extracting or installing dependencies, etc.). In short, the time required rises as the package size grows larger; thus it's critical to keep the package size under control. ### 6. Recursive code should be avoided When code is written to recursively call the lambda function until a condition is met, it might result in a huge number of function calls and increased expenses. When compared to an EC2 instance for simple REST API use cases, lambda functions are far less expensive. However, when faced with extended execution periods, lambda functions may be very expensive. ### 7. One lambda should use one IAM role 1:1 mapping should be maintained between lambda and Identity and Access Management (IAM) roles at all times. When one function is allowed access to an AWS KMS key using IAM roles, any other function that utilizes the same IAM role will have access to the Key Management Systems (KMS) rule as well, possibly opening it up to exploitation. Also, while defining lambda roles, the least privilege model should be used at all times, and no lambda should have more permissions than it needs. ### 8. VPC access for lambda should be controlled Lambda functions operate in a shared Virtual Private Cloud (VPC) at all times and may send network requests to any address on the internet, including other AWS APIs. Private VPCs are also used to ensure that specific resources are operated in a secure manner and that other services may access these private resources in a restricted way. As a result, it's critical to ensure that only lambda functions that require access to these resources have VPC access enabled. It's also worth noting that once the function is VPC enabled, any traffic generated by the lambda function is subject to the VPC's routing rules. ### 9. Concurrency for critical functions should be reserved The default concurrent execution limit for Lambda functions is 1000 across all functions in a particular region, which is a soft limit and can be adjusted. If this limit is reached, lambda functions will begin to reject inbound requests. And this can lead to the failure of certain extremely important company functions, resulting in revenue loss. Consequently, reserved concurrency can be a good way to ensure that crucial functions don't fail because of the concurrent limit. To ensure that a set amount of concurrent requests is reserved for a wanted business-critical Lambda function, a specific quantity of concurrent requests may be stored for a specific Lambda function. The reserved limit will not be utilized by other function invocations and will be accessible for the chosen business-critical function even if the concurrent limit is reached. ### 10. The right balance between memory and execution time should be found The CPU for Lambda is proportionately given to the RAM allocated to the lambda function. As a result, giving extra memory to a function might generally help it run quicker and save money. However, as memory grows, so do expenses, and it's crucial to notice that at a certain point, the reduction in execution becomes significantly less significant in comparison to cost growth. Therefore, finding the right balance between memory and execution time is essential to ensuring lambda runs in the highest suitable environment. ### 11. AWS CloudWatch logs could be useful Although this is arguable when it comes to best practices, application logs are often created and accessed on the application server on which the application is deployed. This is not feasible with lambda since the application developers do not have access to a server. As a result, AWS has put up a method for lambda functions to store logs to [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/), and application developers must ensure that lambda functions have the required permissions to save logs to CloudWatch. This may be further improved by utilizing CloudWatch triggers to set up alerts for any essential logs, such as production errors. ### 12. Setting up cloud watch alarms for concurrent requests Lambda functions are set up to automatically scale to handle incoming requests. While concurrency limitations may have an impact on the application's availability, the large number of invocations can also result in greater expenses. As a result, it's critical to keep a watch on when a large number of concurrent invocations is received, as this might indicate a malicious operation. Therefore, configuring cloud watch alerts to monitor ConcurrentExecutions can substantially aid in early detection of such threats, as well as monitoring lambda costs. ### 13. AWS X-Ray When enabled, AWS X-Ray may provide an end-to-end view of requests as they move through the application, allowing lambda-based apps to be analyzed and debugged. As a consequence, performance issues and errors may be identified, which can assist considerably in the long term to ensure lambda is working in an optimum environment. ### 14. AWS Config AWS Config may or may not immediately improve the performance or security of a lambda function. However, AWS Config can log changes to a lambda function's settings, such as runtime environment data, handler name, code size, security groups, IAM roles, and so on. <br> Using the best practices stated above when setting application logic should result in a business application environment that is optimized and safe. <hr> [reference](https://aws.plainenglish.io/aws-lambda-best-practices-7454da49314d) ## Use cases https://www.techmagic.co/blog/14-use-cases-for-aws-lambda-how-to-make-the-most-of-it/ https://www.simform.com/blog/serverless-examples-aws-lambda-use-cases/ 7 companies that use serverless/aws lambda https://www.techmagic.co/blog/7-top-companies-using-serverless/ Customer case studies for AWS Lambda (AWS documentation) https://aws.amazon.com/lambda/resources/customer-case-studies/ </div>
Last changed by  
 
ana
anas work
136

Read more

The Twelve-Factor App

The twelve-factor methodology is used for building software-as-a-service (SAAS) applications using any kind of programming language together with different backing services. Following this approach, it is possible to deploy an app that has minimum deviations between production and development, can be scaled and deployed to most cloud platforms without the need for system administrators or servers, and has a great connection with the base operating system. In general, these cloud-friendly applications do not only operate in the cloud — they also adopt elastic scalability, ephemeral file systems and statelessness. It is common for them to approach everything as a service which makes them easy to scale and deploy swiftly together with fast delivery of features and other changes. There are particular rules, guidelines and recommendations to follow for each factor/aspect of this methodology in order to develop a cloud-native application. Codebase The first and priority of the twelve factors is the codebase and it represents a single repository or a set of them sharing a root commit. An application must have only one codebase which is consistent across all application deployments and monitored in a version control system. One codebase is thought to have multiple deploys if the developers and their code are well organized. On the other hand, if an application is made up of a couple or more source code repositories, automating the build and deployment phases of the app's life cycle is practically impossible. Having several development teams working on a single codebase can lead to considerable problems. As a conclusion, good developer expertise, coordination and structure among the teams enable the application to have a functioning and well-organized codebase. It is certainly possible to share code across many applications using the one code, one app approach. It's also crucial to determine if shared code should be treated as a microservice or as a standalone product. If shared code is a different product, it could be included as a dependency in the app. Dependencies Modern dependency management includes an integrated server that contains everything an application needs to run in a single build artifact. Applications should always bring their dependencies to the cloud in order to be self-contained and have an embedded server. The majority of programming languages have facilities that empower developers to define dependencies and delegate duty to make sure that those dependencies are fulfilled with a certain tool. Declared dependencies must be isolated at all times. Isolation might be accomplished by examining the specified dependencies and grouping them into a sub-structure beneath or inside the application's artifact. The code can't rely on dependencies already being present on the deployment destination. Furthermore, a cloud-native application never assumes the presence of system-wide packages. Possible failures can bring down a whole server or cost a corporation a financial loss due to undetected data corruption if dependencies are not adequately isolated. The idea of repeated deployments is important to properly manage an application's dependencies, thus no assumption should be made that the runtime into which an application is deployed is not automated. If dependencies are maintained with control and consistency, applications will be one level closer to being able to operate in cloud environments. Configuration The safest approach to save and maintain an application's configuration is to use env vars, which implies externalizing and storing the config in the environment. Non-changeable components do not belong in the configuration since it comprises of components that are variable throughout different deploys. Internal information that is part of the app must not be included in configuration. To clarify, if a value is consistent across all deploys, it isn't configuration. According to twelve-factor rules, configuration should be kept distinct from code, because code doesn't vary across different deploys, but configuration often does. With this separation, it is easier to alter environment variables as no code is being affected. It's extremely important to be cautious while keeping security credentials - they should never be kept in the codebase. Bundled assets remain part of the codebase even if security credentials are stored in some properties files or retrieved from the source code. Since environment variables are maintained individually for each deploy, the application concept that contains them scales efficiently.

10/10/2022
possible sections to write

1 monolithic architectures and their problems 2 microservices and why both 1&2: http://aws-de-media.s3.amazonaws.com/images/AWS_Summit_Berlin_2016/sessions/pushing_the_boundaries_1300_microservices_on_aws.pdf

8/15/2022
PACKER OUTPUT

ana@DESKTOP-U0ULQ81:/mnt/c/Users/it/cloudana_git/LDM_GIT/ldm/ldm$ packer build -force -var "latest_ldm=$latest_ldm" -var-file="marketplace.pkrvars.hcl" test.pkr.hcl amazon-ebs.example: output will be in this color. azure-arm.example: output will be in this color. ==> azure-arm.example: Running builder ... ==> azure-arm.example: Getting tokens using device flow ==> azure-arm.example: Getting token for https://management.azure.com/ ==> azure-arm.example: Loading auth token from file: /home/ana/.azure/packer/oauth-184a7bbc-05d1-4814-acdb-8647136eff21mgmt.json ==> azure-arm.example: Auth token found in file: /home/ana/.azure/packer/oauth-184a7bbc-05d1-4814-acdb-8647136eff21mgmt.json ==> amazon-ebs.example: Force Deregister flag found, skipping prevalidating AMI Name

3/11/2022
AWS Lambda use cases

AWS Lambda has over 100,000 monthly active users, does billions of monthly executions, and is available in 22 worldwide locations. Many organizations have chosen to use the Function-as-a-Service (FaaS) model to enhance their business operations while saving both time and money. AWS Lambda has a variety of fascinating use cases, and few of them will be briefly covered in this chapter. Mass Emailing Each year, many huge corporations, for example, The New York Times, must send billions of transactional emails, as well as newsletters, and other publications. Mass emailing demands technological skill and is highly expensive, but it has become a vital aspect of any marketing campaign. Simple Email Service (SES) and AWS Lambda can work together to provide a cost-effective email flow, while the email list is safely stored in Simple Storage Service (S3). General steps are: Upload CSV file A CSV file is a trigger for an S3 event That S3 event invokes a Lambda Function Lambda function adds the CSV file to DynamoDB database

12/17/2021
Read more from ana
Published on HackMD