- 最新
- 最多得票
- 最多評論
Hi, as with any other AWS service you want to access from an EC2 instance, you need access to the service endpoint either via outbound internet access or via a VPC Interface Endpoint for the service. CodeArtifact does have endpoints defined - com.amazonaws.<region>.codeartifact.api and com.amazonaws.<region>.codeartifact.repositories as per https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html.
Note these endpoints each cost about 1c/hr per AZ, and you'll need 2 AZs if you want high availability.
If your private subnet isn't "fully private" and does have outbound internet access then your security group will need to allow https outbound on 0.0.0.0/0 to access codeartifact this way. Likewise your NACL outbound. NACL inbound will need to allow the ephemeral port range.
On the other hand if using an interface endpoint you only have to allow outbound to that endpoint.
相關內容
- 已提問 6 個月前
AWS 官方已更新 2 年前- AWS 官方已更新 3 年前
- AWS 官方已更新 3 年前
Thanks for your answer. Is there a way to restrict to a more limited CIRDR instead of 0.0.0.0/0? Do AWS public services have a known CIDR?
Some service ranges are published as managed prefix lists (see https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html#available-aws-managed-prefix-lists) and some in a JSON file (see https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) but not CodeArtifact. In theory you could use the AMAZON range in the latter but I wouldn't recommend it. You subscribe to the AmazonIpSpaceChanged topic and trigger a Lambda to process the updated JSON file, refreshing Security Groups with the ranges. You could limit it to just the region of interest but you still may have too many rules for one Security Group so may need several. I don't think it's worth the overhead for the minimal security uplift. VPC Interface Endpoints are a better option with additional benefits as it keeps traffic entirely on the Amazon network.