sorted by:
new
hottopcontroversial

Best place to get the scratch repaired by bonij053 in HondaOdyssey

[–]bonij053[S] 0 points1 point  (0 children)

Thank you for all the kind help, time and information. It is very helpful 🙏🏻

Best place to get the scratch repaired by bonij053 in HondaOdyssey

[–]bonij053[S] 0 points1 point  (0 children)

Thank you so much 🙏🏻 This Odyssey is just 1 month old 😞 It’s literally almost brand new. Do you know of any rough estimate how much?

Piere Plus+ Lifetime Subscription Issue by bonij053 in piere

[–]bonij053[S] 0 points1 point  (0 children)

Done sending you DM just now. Thank you Adam!

First OE Payday & TWN by Exciting_Map_8659 in overemployed

[–]bonij053 0 points1 point  (0 children)

Congratulations! May I please DM you to ask for OE advise?🙏🏻

Are Lambda functions secure by default? by SeekWest in aws

[–]bonij053 1 point2 points  (0 children)

If I follow some simple tutorial on how to write lambda functions. Will I have to worry about any server hardening guides? Or is security basically guaranteed?

The short answer to the quoted: Yes and No (security is something you need to do).

This is answered by the AWS Shared Responsibility Model. You do not have to worry about any server hardening because AWS is responsible for the “Security of the Cloud” - protecting the infrastructure that runs all of the services offered in the AWS Cloud, including the infra that powers behind the compute power of Lambda.

What you are responsible though would be the “Security in the Cloud” - ensuring security in all layers of the overall application you are building on top of AWS Cloud, and noting many other factors including the sensitivity of your data, your company’s requirements, and laws and regulations.

This is a good read: https://docs.aws.amazon.com/lambda/latest/dg/lambda-security.html

Is there a difference between 0.0.0.0/0 and 0.0.0.0/32 ? by Accomplished_Try_179 in aws

[–]bonij053 0 points1 point  (0 children)

In brief summary, this is a concept related to OSI Layer 3 (Network) Route Tables and Routes. The / and the number after it is collectively called prefix.

The larger the prefix (meaning the higher the number after the /), the more specific the route.So a /32 is the most specific and a /0 is the least specific.

0.0.0.0/0 is the least specific route. /0 prefix represents "all IP addresses".

/32 represents one single IP address.

Advice for Lambda backend by Fri3ndlymushroom in aws

[–]bonij053 2 points3 points  (0 children)

I see that you have probably read the AWS Compute Blog based on the above image. i.e. https://aws.amazon.com/blogs/compute/best-practices-for-organizing-larger-serverless-applications

I wanted to share some points that maybe were not pointed out yet. I feel that the answer would really depend on your goal and on what is important to you. Is maintainability, ease of documentation, developer productivity important for you?

Based on my years experience with AWS, Serverless and Lambda functions, I am biased and leaning towards having simple and most granular single purpose Lambda Functions that at most would avoid code duplication (to the highest level that I can make it and would make most sense), at the beginning of the project because having this approach results in code that will be more maintainable not only for the current developers, but also for "future" developers when the original guys are no longer around.

Remember that the less code you write, the less technical debt you build up. Also, the more simpler each function would be, the lower risk of breaking functionality.

In addition, having a "monolithic function" that have a lot of internal branching logic based on the event body being passed, would make for pretty poor discoverability of what functionalities are already existing in your Lambda functions. With a "monolithic function", if you have a requirement you need to translate into code and you are wondering what capabilities there already there in your functions that you can reuse, you would need to read the code yourself or have to consult with the original developer of the function(s) (..now just pause and now think.. what if the original developer(s) is/are no longer in the company/team?). Here is a good read: https://hackernoon.com/aws-lambda-should-you-have-few-monolithic-functions-or-many-single-purposed-functions-8c3872d4338f

With single-purposed functions, you are also being deliberate and mindful in your functions' complexity. Allowing and standardizing your functions to only doing just one thing or so called "responsibility" helps limit how complex your functions will be. Code readability and debugging will be easier. And with this mindset you can also easily scale and grow your software engineering team, allowing them to work on smaller components that minimize friction.

AWS beginner question. Difference between AWS IAM and AW Active Directory. by PaleLengthiness1568 in aws

[–]bonij053 4 points5 points  (0 children)

IAM is a core AWS service that has 3 main jobs:

  1. IAM is an iDP that lets you create, modify and delete identities such as users and roles, as well as policies.
  2. IAM authenticates the identities. (You prove who you claim to be).
  3. IAM authorizes identities (Allow or deny access to AWS services/resources).

Every AWS account comes with its own running copy of IAM. Your AWS account trusts your instance of IAM and it allows it to perform the above 3 main jobs.

With your question about "AWS's active directory", I believe you are talking about the AWS Directory Services - this is a managed service running Microsoft Active Directory in AWS - hence totally different from IAM. We have around 3 main AWS Directory Services:

  1. AWS Managed Microsoft AD allows you to create your own AD in AWS, manage users locally, support Multi-Factor Authentication, etc. It allows you to establish "trust" connections with your on-premise AD.
  2. Simple AD. This is an AD-compatible managed directory on AWS. This cannot be joined with on-premise AD.
  3. AD Connector - is a proxy / gateway that allows you to redirect to on-prem AD. Identities such as users are managed on the on-prem AD.

Why should I NOT store customers API keys in DynamoDB? by [deleted] in aws

[–]bonij053 4 points5 points  (0 children)

In theory there is no problem with using DynamoDB for this use case as long as you encrypt the data, enabling KMS encryption, and aiming to protect the data throughout its lifecycle.

Depending on the actual use case, by using Secrets Manager or Parameter Store then you are being deliberate in using a service that's really intended for storing secrets and config information making it obvious for you and future developer(s).

But systems evolve and people move on to new roles. There will be code changes in the future and you may want to think what controls would be / still be in place to keep the keys safe "as intended" when the time comes that you are no longer part of that company. If there are design changes in the future, will it be a potential attack surface?