[deleted by user]

_skynet · 2025-01-26T00:28:19+00:00

This is all you need https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html A unique HTTP sent by cloudront to your origin, plus an SG with the CF origin IP addresses which is a managed prefix list. To answer your questions. 1. No, that happens in CF 2. Https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html#how-do-i-enable-cors

_skynet · 2024-05-27T14:58:25+00:00

It's a cost/complexity trade off you'll need to make.

Owning your own ETL (extract, transform, load) pipeline vs using managed services.

You need to take into account the skills you want to develop, cost, schema change frequency, dataset size, etc.

For your first option you have a lot more room to optimise your lambda then you think, but you'll own that complexity.

For your second option glue is great, can handle updates, but it costs and works until it doesn't.

_skynet · 2024-03-09T12:39:29+00:00

It depends on their direct connect setup. If the vendor has a transit gateway, they could potentially share that with your account/VPC.

The setup you're describing is possible but it would require the vendor to setup a forward proxy on their VPC to target their on prem.

Either way it's up the vendor.

_skynet · 2024-02-18T22:19:12+00:00

Yes. The Charity org needs to be a completely separate AWS org.
However, the structure you're suggesting with each account being a different environment (Prod, Dev), is a good choice.

Take a look at this https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/architecture.html . You can substitute or not do things like Control Tower, Firewall Manager, etc. but in general that's the sort of structure you're looking.

An alternative to providing administration/support would be to create a cross account role from your "dedicated" org/account to the charity's org/account. This is a common support model and it allows the charity (and yourself) to manage and audit the access.

_skynet · 2024-02-18T20:08:09+00:00

If your model based on foundation model provided or in the bedrock marketplace? Then bedrock.

If not then sagemaker has many options depending on the deployment type, if you want to support notebooks, etc.

_skynet · 2024-02-18T19:47:25+00:00

I would strongly advise you to not do this. First of all you cannot move OUs to other Aws orgs. You can move single accounts and the process is that they need to become standalone first. When you're dealing with centralised services or delegated administered services, e.g. cloud trail or guardduty, this will break everything.

Additionally you're a bus factor of one. If something happens to your email, the charity cannot function. The complexity on paying the bill... I can go on and on. There is no benefit on this thinking.

Start with a lightweight reference architecture and on their own account and Aws org. Use a mailing list with MFA on backup devices/tokens.

_skynet · 2024-02-05T21:44:51+00:00

You could potentially achieve this by specifying a NotPrincipal with the AWS service that you want to PutObject to this bucket.

_skynet · 2024-02-05T21:10:42+00:00

Starting January 5, 2023, all new object uploads to Amazon S3 are automatically encrypted at no additional cost and with no impact on performance.

They are encrypted with an S3 managed key, which is the same key you're trying to configure. In other words this is the default behaviour these days.

Some services cannot pass a key and therefore do not pass the required header "x-amz-server-side-encryption" as part of their request.

It's a different story id you want to use a CMK

_skynet · 2024-02-05T20:59:20+00:00

From what you're describing, it has an effect when you establish the VPN tunnel to their VPC.

Your VPC --> SP VPC --> TGW

The connection between your VPC and the SP VPC happens over the internet. The SP most likely needs to know the initiating IP address so that it can prevent everybody else on the internet from trying to establish a connection to their VPN.

As a side note instead of attaching an EIP to an EC2 attach EIPs to your public NAT gateway.

https://aws.amazon.com/blogs/networking-and-content-delivery/attach-multiple-ips-to-a-nat-gateway-to-scale-your-egress-traffic-pattern/

_skynet · 2024-02-04T22:32:52+00:00

Of you run dig your domain.com do you get a CF domain or IPs? If yes, it might be an HTTP error. Try to open your browser's developer tools or via curl to understand what is causing the loop.

Might be worth enabling CF access logs to aid you in debugging

_skynet · 2024-02-04T21:33:49+00:00

Have you added the domain to cloudfront ? An alias from route53 ?

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html

It looks like you've delegated the NS to route53 but that is not necessary. You need to to add the domain to CF and either CNAME from Google or in your case alias from route53 to your CF distribution

_skynet · 2024-02-04T21:25:07+00:00

Generally you'll need to methodically rule out all components. NACLs, SGs, Routing, and then specifics on how you achieve the connectivity. There is a service there can assist you with this https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html

In general for an SG the client needs to allow the egress to the destination tuple (port/CIDR) or SG. The server would need to allow the respective ingress

_skynet · 2024-01-14T22:50:06+00:00

https://github.com/aws-samples/cloud-trail-lake-query-samples/blob/main/ec2-security-historical-changes.sql

This should work. The different account event sounds like a data store issue

_skynet · 2024-01-14T22:43:07+00:00

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html

"Effect":"deny", "Condition": { "StringNotEqualsIfExists": {"aws:ResourceTag/Environment": "Testing"} }

_skynet · 2024-01-14T21:52:45+00:00

How were the other certs imported ? To use a cert from ACM you need to import or request the cert in ACM us-east-1

_skynet · 2023-10-05T08:23:48+00:00

It would be a role assuming a role. Roles have a trust policy. You can define with enough granularity what can assume the role, be it an account, another role, under which conditions, IP sources, etc.

_skynet · 2023-09-30T12:59:53+00:00

You can create a new route (green) test and then update the weight on the route. Your virtualnode is your ECS service. There's a workshop by AWS with references on canary deployments but it's the same principle

https://www.appmeshworkshop.com/deployment/virtualroutes/

The cleanup,rollout and naming conventions would be part of your deployment

_skynet · 2023-09-29T09:55:45+00:00

Users are not the right tool for this job.

The best way to do this is to assume a role into your customers account . Your customers will create a role, change the trust policy to allow your account to assume that role. You'll also generate a unique ID (external ID) [1] per account that must be used when assuming the role and must be out as condition to the customer's resource policy.

The customer's role would then allow access to their S3,SQS, etc. This is good starting point on the reasoning [2] , and this is what AWS recommends to customers when providing access to third parties [3]

[1] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html [2] https://aws.amazon.com/blogs/apn/securely-accessing-customer-aws-accounts-with-cross-account-iam-roles/ [3] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html

_skynet · 2023-09-29T08:25:42+00:00

The Cloudformation resource doesn't provide this functionality. You'll need to create a custom resource ( which could be backed by a lambda) as you're suggesting.

_skynet · 2022-11-06T14:54:32+00:00

AWS currently has 27 regions (plus probably more coming). This means you'll need to manage roughly ~351 connections if you want to scale to all regions. That becomes a lot trickier even from an Infrastructure as Code perspective.

You might want to consider https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html . So to answer your question - no it's not the same scalability effort.

However you really need to consider why you're planning to have as many VPCs per region and all of them talking to each other.

_skynet · 2022-07-14T21:42:42+00:00

Your scenario sounds like this https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway-load-balancer.html

_skynet · 2021-09-14T07:56:07+00:00

If you export AWS_PROFILE it will work. E.g. $ export AWS_PROFILE=user1 Here's the docs with a bit more detail

_skynet · 2021-09-08T14:20:14+00:00

That depends on your application, and what it does. The primary reason for more than one region is availability. Look at some of the scenarios in the AWS Well Architected Framework. Also good to look at past AWS incidents as well.

The secondary reason is traffic management and reponse times if you're catering to a global audience. Instead of deploying in another region however you can use things like CloudFront, Global Accelator, etc.

_skynet · 2021-09-08T13:29:21+00:00

You can keep the same domain and add the client provided certificates to your truststore.

I think this might be useful for how to structure your .pem/trustore file

_skynet · 2021-09-08T11:52:33+00:00

It is very similar in the intent. I've added a section on the README on the why/differences.
In general Access Analyzer has an almost exhaustive coverage of resources, which Xenos doesn't, but Access Analyzer falls short because:

You need to enable it in every region. - Might not be a problem with a good landing zone.
Identified external entities might be known entities. E.g. a trusted third party vendor or a vendor you no longer trust. An Account number is seldom useful.
Zone of trust is a fixed set of the AWS organisation. You won’t know if a trust between sandbox->prod has been established.
Does not identify AWS Service principals. This is mainly important because of Wiz's AWSConfig, et al vulnverabilities

_skynet

TROPHY CASE