https://letstalkaws.com/ Tue, 05 May 2026 02:03:25 +0000 MyBB https://letstalkaws.com/thread-92.html Tue, 10 Oct 2023 09:10:04 +0000 kiroval479]]> https://letstalkaws.com/thread-92.html
Current Setup:

Services: Predominantly AWS Lambda, API Gateway, and DynamoDB.
Architecture: Microservices pattern with each service exposed via API Gateway and business logic handled by Lambda.
Traffic: Our applications receive moderate to high traffic, with expected spikes during product launches and sales.
Concerns and Questions:

How should I handle authentication and authorization efficiently in a serverless pattern, especially considering the stateless nature of Lambda?
Are there specific security best practices or patterns when interfacing API Gateway with Lambda?
How can I ensure secure data transit between services, especially when integrating with other AWS services or external APIs?
What monitoring and alerting mechanisms should I put in place to detect and respond to potential security threats?
Are there any tools or AWS services specifically geared towards enhancing security in a serverless environment?
I've gone through the AWS Well-Architected Framework and have a basic understanding of security pillars. However, real-world experiences and nuanced insights from this community would be invaluable.

Thank you in advance for your guidance and sharing your expertise!]]>
Current Setup:

Services: Predominantly AWS Lambda, API Gateway, and DynamoDB.
Architecture: Microservices pattern with each service exposed via API Gateway and business logic handled by Lambda.
Traffic: Our applications receive moderate to high traffic, with expected spikes during product launches and sales.
Concerns and Questions:

How should I handle authentication and authorization efficiently in a serverless pattern, especially considering the stateless nature of Lambda?
Are there specific security best practices or patterns when interfacing API Gateway with Lambda?
How can I ensure secure data transit between services, especially when integrating with other AWS services or external APIs?
What monitoring and alerting mechanisms should I put in place to detect and respond to potential security threats?
Are there any tools or AWS services specifically geared towards enhancing security in a serverless environment?
I've gone through the AWS Well-Architected Framework and have a basic understanding of security pillars. However, real-world experiences and nuanced insights from this community would be invaluable.

Thank you in advance for your guidance and sharing your expertise!]]> https://letstalkaws.com/thread-87.html Fri, 17 Mar 2023 18:54:43 +0000 rnrstar]]> https://letstalkaws.com/thread-87.html https://letstalkaws.com/thread-85.html Sat, 04 Mar 2023 10:27:43 +0000 Tucix]]> https://letstalkaws.com/thread-85.html  
I totally disagree with the following sentence, because by definition a VPN provides a private connection based on FAI requirements (private IP addresses) :

"
a VPG is the AWS-side of an AWS VPN. A VPN does not provide a private connection and is not reliable as you can never guarantee the latency over the internet
"
 Is there something wrong in my reasoning ?

Thanks,]]>  
I totally disagree with the following sentence, because by definition a VPN provides a private connection based on FAI requirements (private IP addresses) :

"
a VPG is the AWS-side of an AWS VPN. A VPN does not provide a private connection and is not reliable as you can never guarantee the latency over the internet
"
 Is there something wrong in my reasoning ?

Thanks,]]> https://letstalkaws.com/thread-84.html Sat, 04 Mar 2023 09:04:52 +0000 Tucix]]> https://letstalkaws.com/thread-84.html
What is a session policy in the context of the IAM ?
 I know what Resource-based policy and Identity-based policy are, but not session policy.

Regards,]]>
What is a session policy in the context of the IAM ?
 I know what Resource-based policy and Identity-based policy are, but not session policy.

Regards,]]> https://letstalkaws.com/thread-83.html Thu, 02 Mar 2023 19:30:10 +0000 Tucix]]> https://letstalkaws.com/thread-83.html
Based on my knowledge, there are two types of scaling : the up/down scaling and the out/in scaling.

I'm a bit surprised to see that in AWS Courses (so as in AWS Solution Architects Exam Preparation Book) I missed the up/down scaling !

Indeed, I always found that typical example :

- in the "Increase Group Size" Window in the "Take the action" item the CAPACITY UNIT is activated (that is to say, this represents the instance number).

In case of a up/down scaling, we are supposed to modify the CPU and/or the RAM.

But I never see such information in the "Take action" item, is that normal ?

Regards,]]>
Based on my knowledge, there are two types of scaling : the up/down scaling and the out/in scaling.

I'm a bit surprised to see that in AWS Courses (so as in AWS Solution Architects Exam Preparation Book) I missed the up/down scaling !

Indeed, I always found that typical example :

- in the "Increase Group Size" Window in the "Take the action" item the CAPACITY UNIT is activated (that is to say, this represents the instance number).

In case of a up/down scaling, we are supposed to modify the CPU and/or the RAM.

But I never see such information in the "Take action" item, is that normal ?

Regards,]]> https://letstalkaws.com/thread-59.html Tue, 25 Aug 2020 21:05:39 +0000 fzs]]> https://letstalkaws.com/thread-59.html
1. Route53 Geolocation Policy

This routing policy is specifically used if you always want users from a certain location i.e a country, continent or in the case of US, a specific state to be always given an IP of the same environment/region, everytime. This is used for content localization, for example if you want people from Europe to only access an environment/region that hosts content that is local/relevant to that region. Think of this like when you open youtube from different parts in the world, you see content related to that region on the home page.


  geo-location_1.JPG (Size: 83.18 KB / Downloads: 1123)

This means that unless you have setup a failover route as well for the same FQDN using traffic policy inside Route53, then if that region fails, the users will get failure screens with 4xx errors. Also, if your DNS record TTL values are high i.e >300, then there is a possibility that even though your environment might have recovered from a failure using new endpoint IPs, existing users who might already have a failed environment IP will still get the failure as DNS changes can take a long time to propogate fully.


2. Cloudfront

This is specifically used only for speeding up the delivery of your content. It caches your content on the global edge locations, and it does not route repeated requests to your environment, which means if you make changes, then you have to wait till you invalidate the cache across the globe for the new content to replace old one. Also, the source is a single point, so in cases of that environment failing or a region failing, no new content can be delivered to users while your env is down. The advantage is ofcourse that you do not need to run high capacity servers because lesser requests are hitting your origin servers or lesser API requests hitting your S3 buckets. CloudFront supports only HTTP & HTTPS requests.


  cf_1.JPG (Size: 53.83 KB / Downloads: 979)


3. Global accelerator

This service does not cache your content like CloudFront. It basically wants your users from anywhere in the world to jump onto the AWS network at their closest point and then get shot through the AWS global network to reach the closest environment/region where you have running resources. This is much faster than traversing the normal submarine cables which offer no guaranteed QoS and are plagued by bandwidth throttling courtesy telcos. The only similarity with CloudFront is that it makes use of edge locations to let your customers into the AWS global network.

Unlike cloudfront, you can use a wide range of TCP & UDP listener ports and you can have multiple regions behind your GlobalAccelerator which means higher availability. Also, since it provides anycast IPs, all your environments regardless of region and number of environments will have 2 global IPs which means any third party provider integration, you do not need to be hassled with multiple IPs and also whitelisting on firewalls by others becomes a breeze. Also, failovers are much more quicker since there is no DNS propagation to wait for. All in all, this will greatly reduce latency without need for caching any content. Super useful for use-cases like live gaming.



Global Accelerator Image source: https://aws.amazon.com/blogs/networking-...celerator/]]>
1. Route53 Geolocation Policy

This routing policy is specifically used if you always want users from a certain location i.e a country, continent or in the case of US, a specific state to be always given an IP of the same environment/region, everytime. This is used for content localization, for example if you want people from Europe to only access an environment/region that hosts content that is local/relevant to that region. Think of this like when you open youtube from different parts in the world, you see content related to that region on the home page.


  geo-location_1.JPG (Size: 83.18 KB / Downloads: 1123)

This means that unless you have setup a failover route as well for the same FQDN using traffic policy inside Route53, then if that region fails, the users will get failure screens with 4xx errors. Also, if your DNS record TTL values are high i.e >300, then there is a possibility that even though your environment might have recovered from a failure using new endpoint IPs, existing users who might already have a failed environment IP will still get the failure as DNS changes can take a long time to propogate fully.


2. Cloudfront

This is specifically used only for speeding up the delivery of your content. It caches your content on the global edge locations, and it does not route repeated requests to your environment, which means if you make changes, then you have to wait till you invalidate the cache across the globe for the new content to replace old one. Also, the source is a single point, so in cases of that environment failing or a region failing, no new content can be delivered to users while your env is down. The advantage is ofcourse that you do not need to run high capacity servers because lesser requests are hitting your origin servers or lesser API requests hitting your S3 buckets. CloudFront supports only HTTP & HTTPS requests.


  cf_1.JPG (Size: 53.83 KB / Downloads: 979)


3. Global accelerator

This service does not cache your content like CloudFront. It basically wants your users from anywhere in the world to jump onto the AWS network at their closest point and then get shot through the AWS global network to reach the closest environment/region where you have running resources. This is much faster than traversing the normal submarine cables which offer no guaranteed QoS and are plagued by bandwidth throttling courtesy telcos. The only similarity with CloudFront is that it makes use of edge locations to let your customers into the AWS global network.

Unlike cloudfront, you can use a wide range of TCP & UDP listener ports and you can have multiple regions behind your GlobalAccelerator which means higher availability. Also, since it provides anycast IPs, all your environments regardless of region and number of environments will have 2 global IPs which means any third party provider integration, you do not need to be hassled with multiple IPs and also whitelisting on firewalls by others becomes a breeze. Also, failovers are much more quicker since there is no DNS propagation to wait for. All in all, this will greatly reduce latency without need for caching any content. Super useful for use-cases like live gaming.



Global Accelerator Image source: https://aws.amazon.com/blogs/networking-...celerator/]]>