Please, consider a system (composed of many microservices and BFFs) that:
Each Microservice and BFF has its own AWS Account (as part of an organization - Control Tower). In fact, each has TWO Accounts, one for PRD and another one for NON PROD environments.
External Services: Lumigo for Monitoring, GitLab CI/CD (SaaS), Salesforce, Stripe, Twilio, Some Banks (API based)
Multi-region deployment (For DR only). So DynamoDB and Aurora Serverless (V2) are synched to another region, and the application is always deployed in both regions (Queues and other temporary states/data are not synched).
and knowing that it’s now 2022 (Lambda will turn 10 in a couple of years) would we need VPC (VPCes?) for this solution for maximum security (regarding Infrastructure alone)? . It always looked to me that good governance, automatic rotation of IAM credentials, a strong CI/CD pipeline, and continuous and external security checks would be enough for Serverless Architecture, so that developers or DevOps wouldn’t need to invest a lot of energy setting up and maintaining Network and VPC
Server less architecture can be ran completely on shared infrastructure with low latency and high availability without paying for resources inside a vpc.
This is an aspect that makes the architecture really powerful. With the exception of configuring services like you mentioned lambda functions can just be pushed up to aws and become immediately available.
For security lambdas can have authorizers. Authorizers act as an authentication and authorization layer around lambdas. Out of the box aws supports cognito authorizers and identity federation through several formats such as oauth and saml.
Lambdas can also have IAM roles with policies that provide access to other resources inside aws. By default Lammas have limited access to other resources. Roles are needed to explicitly grant access to other resources.
This is all much easier to setup using serverless framework.
I forgot to mention authorizers are part of api gateway not lambda. You will need api gateway to expose lambdas to the public net. All of which is easy to setup with serverless framework vs writing your own cloud formation templates or manually creating all this in aws by hand.
In my opinion it’s always a good thing to expose only things to the internet that actually need to be publicly exposed. So if any of those services you mention are internal-use only it would make sense to me to hide them in a VPC so they physically can’t be accessed from the outside. You can’t hack something if you can’t reach it, or at least you’d need to do something to reach it first, creating an additional hurdle.
So it pretty much depends on how things are set up. If everything should be publicly available I don’t really see any added benefit with a VPC.
I believe that if you wall off lambdas inside a vpc but need internet access to them a vpc end-point will be needed. Each vpc end-point is charged hourly. This can create significant cost which could be circumvented by using authorizers instead. I learned this the hard way after paying for a vpc end point for months that wasn’t even being used. It was about a dollar a day for me.
When I searched whether lambdas inside vpc are safer this is the first thing that came up.
Don’t put your Lambda function in a VPC unless you have to** . There is no benefit outside of using this to access resources you cannot expose publicly, like a private Amazon Relational Database instance.
Which makes sense since no access to resources implicitly exists unless explicitly granted via roles through policies.
I do not know if I understand correctly, but some VPS services have two IP-addresses. One public and one intern. You can make one server unreachable from outside. Only reachable from another VPS with extern IP-address communicating with other VPS using the intern IP-address. I interpret this as simpler VPC sort of.