- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
for that scenario, it's really just an architectural decision..there isn't necessarily a 'shared services' service at AWS..other than vpc interface gateway.
for a single customer/mutliple accounts or vpc...it's just a matter of isolating the particular service (e.g. rds database) in a subnet or subnets and allowing access to that from other vpcs via routes and security groups.
the transit gateway really functions as the next generation vpc peering, so that, I think, is the better option...but it's a region-specific construct, so if you can across accounts or vpcs, use the same region in all places..it should perform better as well.
Shared services can be many things and have different advantages depending on the particular need.
You should review vpc endpoints:
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html
As well as understand vpc peering/Transit Gateway
Generally speaking, if you are talking about across-customer shared servics, looking at vpc endpoints is a secure way to manage access to specific services. if it's just for a single customer, having a dedicated vpc using shared services and then using vpc peering or transit gateway help keep things secure and manageable. Having it in a separate account entirely can help simplify the cost tier as well.
Sorry, is it same as shared VPC then? I'm having tough time to get around this shared service concept.
same customer different accounts/vpc.
Thanks
Edited by: sali on Mar 2, 2019 8:40 AM
Relevanter Inhalt
AWS OFFICIALAktualisiert vor 3 Jahren- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 7 Monaten