Are you prepared for the upcoming AWS region in Switzerland?

I am an independent AWS consultant providing services through my company 1way2cloud GmbH. If you would like to engage me on your project, feel free to contact me directly at nemanja@1way2cloud.com.

A new AWS region is coming to Switzerland sometime next year. For all Swiss companies that are battling data residency laws this can come as a relief. Similarly, to all non-Swiss based companies that perceive Switzerland as a safe haven location for their data and/or applications, this becomes an interesting proposition.

There are few things to consider before deciding to put your company through the journey of going to new AWS region in Switzerland. In this post I will try to cover important topics that can have the biggest impact on your decision. There are plenty of smaller ones as well, but let’s try to tackle the biggies first.

Choosing a right region to start with is a much bigger decision than you might think. There are many factors to consider, such as region cost, distance to majority of your target users and the region maturity itself. Once you put your data/applications in a certain region, they won’t move out so easily. It requires a significant migration effort to change the region.

So, let’s see what you should take care of before you start an AWS journey.

Step 1: Preparing your IT teams

First and foremost, have your internal IT team ready. Managing cloud services is not the same like managing e-mail servers or Windows operating system for your company. A significant investment in training and education is needed as many things can go wrong. Cloud makes it easy for things to go wrong as it puts loads of power in your hands.

Your cloud team (sometimes you might also hear the term Cloud Center of Excellency) should at minimum have these three roles:

• Platform Team
  Members of platform team understand how to operate AWS environment. They would evaluate new services, create infrastructure components required by application owners, configure networking elements (VPN connections, Transit Gateways, Direct Connects etc.), provide Workspaces environment for developers, set up CI/CD pipelines and similar activities. Usually you would source members of this team from your existing infrastructure operations and networking IT teams. They would report to the Head of IT Infrastructure.
  
  
• Security Team
  Members of security team are observing security maturity of the AWS environment. They would use AWS services such as GuardDuty, Security Hub, Detective, Config, Access Analyzer, Credentials Report and would inspect logs coming from WAF, CloudFront, S3 Access, CloudTrail, VPC Flow. They would run inspection tools to analyze logs and setup automated response actions. Also, they would run intrusion detection and prevention systems to detect and stop potential incidents. Usually you would source members of this team from your existing security teams and they would report to CISO.
  
  
• Identity Team
  Members of identity team are managing access to AWS. They create and manage IAM roles and policies that are used by federated access to AWS, by Organizations SCP’s, by technical accounts and by different AWS services (Lambda, EC2 etc.). They would also develop tagging strategy and enforce usage of tags across the organization so that they could use attribute based access control later on (ABAC). Usually you wouldn’t find similar roles in your existing organization as the AWS policies are quite AWS specific. You would need to hire or train someone internally to own the identity topic for your organization. This team would report your CISO as well.

These are the teams that will manage your AWS environment but you still need different development teams to develop the applications that will run in AWS. The structure of those teams will vary depending on the type of applications you are developing. If your internal application development team is already using containers for example to package and deploy their applications, not much will change for them. Their containers will still work as before but just they will be executed on some of the AWS orchestration services such as ECS, EKS, Elastic Beanstalk etc.

Without having in-house knowledge of AWS, your company will always depend on external partners and consultants. That is great for us consultants but it’s not great for you. You will end up paying more and will be at mercy of those external parties. My experience shows that any team can be successfully trained in 6 months. When working with customers, my goal is to make myself obsolete within 6 months. Then I know I did my job well and can be confident that the customer is ready to take on management of their AWS environment themselves.

Step 2: Baselining of AWS services

I wish I could tell you that all AWS services are perfect. But they are not. When a new AWS service is released, it is an MVP (Minimum Viable Product). It doesn’t have all functionalities you would expect. Example, when managed Kafka service was released it only had some basic functionality of the open-source Apache Kafka solution. Generally that is a good way how AWS is developing their services. They release an MVP and wait for customer feedback to drive the future roadmap of the service. You can’t go wrong like that, as you will always be releasing features that customers actually need. But until all features are implemented, we need to live with half-baked services that often have few bugs here and there.

Another thing to consider is that AWS services are gradually rolled out to regions. Not all the regions have all the services available. Sometimes it can even take years from the moment a service had been released until it shows up in a certain region. Generally N. Virginia (us-east-1) is the region where new services and features are being released. It is also the oldest and the biggest region (with 6 availability zones). That doesn’t mean you should use that region by default. I would personally recommend to keep away from N. Virginia. It is the region where half of the Internet is being hosted on and probably other half is using it as a disaster recovery site. That means the load on that region is huge. Most of outages in the past years have been in us-east-1.

There are other points that contribute to the service maturity. Ask yourself if the service you want to use is supporting:

1. tagging
2. resource based policies
3. private links (AWS PrivateLink)
4. CloudWatch logs
5. CloudTrail logging
6. AWS Config rules
7. CloudFormation or CDK
8. cross-account invocation
9. cross-region invocation

Based on that, make your own baseline of services that you want to allow to be used in your organization. All services above that line, can be used. All other, below the line, should be denied. You can easily control which services are allowed/denied by using AWS Organization SCP’s. Re-evaluate the baseline every 6 months and modify if anything changes.

At this moment, there is no information on what services will be available in the Swiss region next year. I suppose when we get closer to the launch data some things might be announced.

Step 3: Think about the region cost

Not all regions are priced the same. There is some logic in that, as the land, human work force and utilities (power, water) have different cost in different countries.

In their blog post, Concurrency Labs did a nice exercise of comparing cost of different services among regions. The calculation is fresh, from February this year. Here is example of a monthly cost for a solution that uses 5 EC2 instances with 20GB of storage and 1 load balancer, where each instance receives 100GB/month from the ELB and sends 1TB/month back.

At this moment nobody really knows how much the Swiss region will cost. Will it be a premium region with prices that are 30% – 50% above all the others? It would be reasonable to expect that as the Switzerland costs are among the highest in the world. But then again, why is Sao Paulo so expensive? I don’t think Latin America is the most expensive area on the planet. So, we just need to wait and see what the prices will be in the Swiss region next year.

Step 4: Account Setup

When you decide on the region you want to use, and hopefully upcoming Swiss region fulfills all your requirements, it’s time to start spinning up resources in that region. Remember from the beginning of this blog post, once you create resources in one region there is no easy way to move them to another region. Ideally you would use infrastructure as code (e.g. CDK, Terraform, Pulumi) from day 1 and for *all* of your resources. That can help with eventual migration to a new region some day, if you ever decide to do so.

Major mistake I see customers doing is to jump straight into creating EC2 instances, VPCs etc. in some account. These temporary activities tend to become permanent, so best is to avoid them and start doing things properly from the beginning.

It is worth spending time in organizing your accounts via AWS Organizations. Creating dedicated sub-accounts that will be used just for security, networking, application production etc. is an effort in the beginning, but the one that will pay off on the long run.

An AWS Organizations setup that I usually like to start with is the following:

Master Account is the parent container for all the accounts for your organization. If you apply a policy to the root, it applies to all organizational units (OUs) and accounts in the organization. Master account must be carefully protected by IAM best practices. It is the most privileged account that should not be used to create any resources, but only to create sub-accounts. The master account is the account that creates the organization. From the organization’s master account, you can do the following:
– Create accounts in the organization
– Invite other existing accounts to the organization
– Remove accounts from the organization
– Manage invitations
– Apply policies to entities (roots, OUs, or accounts) within the organization

The master account has the responsibilities of a payer account and is responsible for paying all charges that are accrued by the member accounts. You can’t change an organization’s master account later on.

Organization unit (OU) is a container for accounts within a root. An OU also can contain other OUs, enabling you to create a hierarchy with a root at the top and branches of OUs that reach down. When you attach a policy to one of the nodes in the hierarchy, it flows down and affects all the branches (OUs) and leaves (accounts) beneath it. An OU can have exactly one parent, and currently each account can be a member of exactly one OU.

Here I have suggested four OU’s:

• Foundational OU – a shared organisational unit that other accounts can use. It contains Security and Network OU’s. Both Security and Network OU’s have SDLC OU and Prod OU. SDLC (Software Development LifeCycle) contains accounts used for testing tools and services before they are moved to the production account in Prod OU. Security account would have security services configured such as GuardDuty, Security Hub and Detective that would inspect all other accounts under the Master Organization. Log account would receive CloudTrail and Config logs from all other accounts. Network account would keep networking services such as VPN access for example.

• Sandbox OU – this OU is for AWS accounts of individual users, in which they can learn and dive deep into AWS services. These accounts will have budget restrictions (limited to say $50 per month) and will be detached from the rest of organizational accounts.
  
• Suspended OU – if an account needs to be deleted (let’s say Developer XYZ leaves the company) then this account should be moved to suspended OU. It takes 90 days to permanently delete an account. During that time, the account is in suspended state and a “deny-all” policy is applied to the account so that no services can be consumed. After 90 days, the account is removed from the Organization automatically.
  
• Workloads OU – this is main OU for your applications. This is where you have Production account for each of the applications you are running in AWS (under Prod OU) as well as set of Dev/SIT/UAT/Test/Pre-Prod/etc. accounts under SDLC OU.

It takes some time to set up and get used to managing all these different accounts. However, separation of duties is worth the effort and there are also services, such as AWS Control Tower, that help with the initial setup.

Step 5: Network

Many companies already have some on-premise infrastructure. Moving to cloud is not an overnight step, so it is realistic to expect a co-existence of both on-premise and cloud infrastructure for a while. This kind of hybrid approach requires thinking about some of AWS networking services that can be used to connect on-premise data center with AWS cloud.

Direct Connect is a dedicated link to AWS, but it takes usually few months to set it up as it involves working with local Direct Connect partners and local Telco operators to provide “last-mile” optic fiber connectivity between Direct Connect partners and your data center.

A typical network setup would look like this. On premise data center connecting to AWS over Direct Connect. Then using Direct Connect Gateway to reach other regions if needed. Inside each region, Transit Gateway routes connectivity between VPC’s.

Your platform team will need to get on top of these hybrid connectivity services such as: Direct Connect, Site2Site VPN, Transit Gateway and Direct Connect Gateway.

Often, it’s not just one cloud that companies are using. Azure AD is a popular identity directory that companies are using for managing access of their thousands of employees. Office365 is also popular tool set seen in all of the companies. With some other workloads in Azure or GCP, the platform team needs to think about inter-cloud connectivity as well.

Step 6: Backups and Disaster Recovery

Choosing a region is a difficult enough decision, now try doing that for two regions. And you do need two regions.

The second region is used for storing backups of your data and as a disaster recovery region for you applications. You might choose to run the second disaster recovery region in an active-pasive or active-active mode, but in either case the due diligence for the second region needs to be done as well. You need to make sure that services that are used in your active region are supported in the second region as well.

Step 7: Think about Serverless services

You won’t see the real power of cloud until you start building serverless applications. The promise of the cloud benefits such as low cost, high scalability & availability & reliability and performance, all of that comes with the usage of serverless services.

However, the application design is a bit different to the traditional monolithic approach of building applications. There is a learning curve involved and you need to train your internal development teams for the serverless thinking.

Here is what a usual serverless application looks like:

Probably 80% of all applications in use today can be designed like this. There is some UI (mobile/web), some global delivery layer (DNS + CDN), authentication (JWT), static layer (HTML, JS, CSS, images), dynamic layer (API’s), backend business logic and database logic. Often you need some data ingestion and data processing layers. To automate development you would also use CI/CD pipelines.

There are variations in these blocks where you can use one or more services for data ingestion, API’s and databases for example. The business layer itself can be as simple as having just few Lambda functions, or it can contain some more complex synchronous/asynchronous orchestration within.

The point of this step is to make you aware that there are approximately 30 serverless AWS services that your development teams should be aware of. AWS offers many more and they fit in those 20% of more specialized cases that you might not see in everyday usage.

This step brings us back to step 2 where we need to do baselining of services we can use in a region. Serverless services have somehow traditionally been the very last to be rolled out in regions (especially machine learning ones).

Conclusion

The point of this post is to show you what are all the caveats to consider when starting AWS journey in of the available regions. The upcoming Swiss region is very exciting for all FinServ companies that were hesitant to use AWS due to the different Swiss regulations (data residency, FINMA, etc.). They will now be able to finally level the playing field with other FinTech startups from abroad who have been taking pieces of their cake for years. However, the journey to AWS cloud is not trivial. The above 7 steps require time to master. Start now.

If you are interested in more visual explanation of what a cloud journey looks like, take a look at our Cloud Couch videos and the 4 episodes of Cloud Journey series in there: